[ghemical-devel] Re: Bond Length Constraints

[Tommi Hassinen]

Hello.

I understood that you have taken a similar approach that I also would do 
in this distance constraint feature.

First an user interface is needed where the constraints can be added 
(basically atom pairs, the distances and how strong the constraints should 
be). Then this information should be stored somewhere, probably into the 
"model" class.

Later then when the user starts, say geometry optimization, an "engine" 
class is created for that operation. At that point, I think it should be 
the task of the "engine"-object to see from the "model"-object if any 
distance constraints are set, and then either show a warning message 
saying "I can't handle these distance constraints now", or just go on 
and use the constraints.

It is important to note that there are many such "engine" classes, and the 
distance constraint code therefore must be made on several different 
places.

Regards,

 	Tommi


On Tue, 7 Mar 2006, Donald Ephraim Curtis wrote:

> I was wondering in what way i could implement bond length constraints
> that would satisfy the ghemical community (code and interface).  I
> realize this is a much more complex issue as it effects other areas of
> calculating certain properties, however, I believe we can implement the
> interface changes in much the same we way did the frozen atom support.
> However, my main concern is the libghemical changes which I believe in
> this case require changes to the engines.  The way we handled this
> previously was when we calculated the bondlength we raised that constant
> and introduced our own properties about the bond that would set the
> specific length.
>
> Basically, we created a constraint list that included the two atoms
> which were constrained.  We did this because we wanted both bonded and
> non-bonded atoms to be able to constrained.  This alleviated the problem
> of having to bother with angles and torsions (is that right in chemistry
> terms?).  Also in that previous case we also made it so non-bonded
> constrained atoms were treated as though they WERE bonded.  It was just
> a work around since the non-bonded code got in the way.
>
> In the end we simply had a check in the ComputeBT1 function that would
> set the optimum distance to the value set by the user.  Since angles and
> torsions have a lighter effect on the bond lengths we didn't even have
> to bother with the constant.
>
> Thanks in advance,
>
> Donald Ephraim Curtis