[ghemical-devel] Constraint View Patch

[Tommi Hassinen]

On Mon, 27 Mar 2006, Donald Ephraim Curtis wrote:

> Here it is and it's huge!
>
> Added editing options to the constraints menu.  This will need to be
> tweaked a bit I would guess.  I would like to clean the code up a bit
> but if we're still shooting for an April release this will have to do.

Ok, thanks. My opinion is that the "project view" is more or less OK now 
for v2.0, and I would spend more time with the cvs HEAD version so that it 
would be easier to work with in the future.

> I'd like to propose that we change the units on the popup to Angstroms
> instead of nanometers?  The constraint tab is setup this way.  I need to
> correct the formatting too, conversion from float to str should probably
> be cleaned a bit to cut some precision and allow exponential notation.

I would prefer the nanometer, since it is used both internally (in 
libghemical) and in the current user interface (the measure tool prints 
out distances in nm). Using different units at different places is 
confusing, and it would be also a good practice to print the units for 
force constants as well (currently units are missing at project view). For 
example if we have a force constant that is nm-based :

 	5.00 kJ/(mol * nm^2)

it is expressed in Ångström units this way :

 	5.00 kJ/(mol * (10.0 Å)^2) = 0.05 kJ/(mol * Å^2)

This is to show you that using different units at different places really 
makes things complicated.

On the other hand, I understand that you might have preferred the Å unit 
in the Gamess program earlier. Does the nm unit cause you trouble with the 
gamess program interface?

> I don't do any checking to make sure that my min is less than my max,
> probably should add that at some point.

This check would be important to add ; also the force constants should be 
always positive values.

> Also, what does it mean if you say that the type of constraint is
> disabled.

The "disabled constraint" feature is not really used, but it should not 
cause any trouble if it's used. The dialog interface does not create them, 
and I mostly made the whole feature for consistency.

The min. and max. distance constraints are handled separately from each 
other, so one really can use any combinations of them (min+max, min, max, 
none).

> I had a problem where i had 3 molecules bonded in a chain and
> constrained two connected, set the constraint min to like 10 angs,
> optimized, and then disabled the constraint yet it didn't go back to
> normal.  Just something to check out maybe?  Besides that everything is
> working out great.

I think this issue is about how the model and engine classes work.

When new constraints are added, those are stored into a model object. When 
something needs to be computed (say, a geometry optimization needs to be 
run), then a new engine object is created using the model object, and 
information (including atoms, bonds and constraints) are copied from the 
model object to the new engine object.

So, when atoms or bonds are added or removed, or their properties are 
changed otherwise, this change really invalidates all engine objects that 
were created using the model object. This is why the following code 
exists:

void model::AddAtom(atom & p1)
{
 	SystemWasModified();

So, when a new atom is added, model::SystemWasModified() is immediately 
called:

void model::SystemWasModified(void)
{
 	// if atoms/bonds added/removed, all engine-objects have to be discarded.
 	// also if element is changed, the MOPAC/MPQC QM engine-objects (at least) must be discarded.

 	DiscardCurrEng();

 	// in the setup object, all atom/bond tables must be discarded for the same reasons as above...

 	current_setup->DiscardSetupInfo();

 	// the resonance_structures object must be invalidated, if there is one...

 	if (rs != NULL)
 	{
 		delete rs;
 		rs = NULL;
 	}

 	// any change that might lead to change in detected sequences must invalidate the SF engine objects...

 	if (dynamic_cast<setup1_sf *>(current_setup) != NULL)
 	{
 	//	delete current_setup;
 	//	current_setup = new setup1_mm(this);
 		ReplaceCurrentSetup(new setup1_mm(this));
 	}

 	// any addition/removal of atoms/bonds will invalidate information about molecules.

 	InvalidateGroups();
}

The call will invalidate, or mark obsoleted, many kinds of dynamic 
information.

You should also call model::SystemWasModified() if constraints are added, 
removed or modified. I think this will solve the problem you found. When 
you set the constraint "disabled", the change was saved into the model 
object but it was not passed to the engine object, nor the engine object 
was invalidated ; therefore the change did not affect anything in the 
calculations and the bond length did not go back to normal.

> I'll be doing minor cleanup but for the most part i'm trying to do the
> Mac Port and add the final gamess changes.  Let me know if you need
> anything.
>
> PS: I also updated the ghemical title to include the version number,
> seemed useful.  your call.

This is useful, thanks.

 	Tommi