From: Jérôme Hénin (jerome.henin_at_ibpc.fr)
Date: Fri Sep 01 2017 - 11:23:23 CDT
This line was added when Jim added constraint forces to the reported total
forces:
https://charm.cs.illinois.edu/gerrit/gitweb?p=namd.git;a=commit;h=1dbc071abfd9f1a2fb9acd23bb25f401cdd1ea80
https://charm.cs.illinois.edu/gerrit/gitweb?p=namd.git;a=commit;h=fa661858dc516c885bf4c85be4bc46fe874ec82a
https://charm.cs.illinois.edu/gerrit/gitweb?p=namd.git;a=commit;h=e3d77040ee48715e4d6c0f2b8d4f0ba3e995b505
(git made finding this so much easier...)
On the one hand, having zero force on fixed atoms is physically consistent.
On the other hand, if a user explicitly requests the force on a fixed atom,
they are probably after some information that is not zero. So if we were to
disable this, it would have to come with a warning in the doc: if you want
the *true* total force on a fixed atom, constraints included, just don't
query it. You know it's zero.
Jerome
On 1 September 2017 at 18:02, Jérôme Hénin <jerome.henin_at_ibpc.fr> wrote:
> Actually, looking into the code behind this, I think there is a way. The
> force gets zeroed out arbitrarily in ComputeGlobal.C, line 374:
> if ( fixedAtomsOn && atoms[i].atomFixed ) f_sum = 0.;
>
> Commenting out that line and rebuilding NAMD seems to do the job for me.
> Please test this, and if the force values you obtain seem correct, I'll
> submit a patch.
>
> Jerome
>
> On 1 September 2017 at 18:01, Ben Adams <benny.adams1993_at_gmail.com> wrote:
>
>> Is there any way to out put the constraint force separately?
>>
>> On Fri, Sep 1, 2017 at 10:48 AM, Jérôme Hénin <jerome.henin_at_ibpc.fr>
>> wrote:
>>
>>> Indeed... What I suspect might be happening here is that the constraint
>>> force gets included in the reported total force, which adds up to zero.
>>>
>>> Jerome
>>>
>>> On 1 September 2017 at 17:36, Ben Adams <benny.adams1993_at_gmail.com>
>>> wrote:
>>>
>>>>
>>>> Thanks but even when I use fixedAtomsForces it still returns zeros.
>>>> For example here atom 2431 is frozen but the force output is zeros:
>>>>
>>>>
>>>> fixedAtoms on
>>>>
>>>> fixedAtomsForces on
>>>>
>>>> fixedAtomsFile fix.pdb
>>>>
>>>> fixedAtomsCol B
>>>>
>>>> tclForces on
>>>>
>>>> tclForcesScript {
>>>>
>>>>
>>>> set nter [addgroup {1}]
>>>>
>>>> set cter [addgroup {2431}]
>>>>
>>>> proc calcforces {} {
>>>>
>>>> global cter
>>>>
>>>> loadcoords coor
>>>>
>>>> enabletotalforces
>>>>
>>>> if {[getstep] > 0} {
>>>>
>>>> loadtotalforces forces
>>>>
>>>> print $forces($nter)
>>>>
>>>> # print cter= $forces(cter)
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> On Thu, Aug 31, 2017 at 5:36 PM, Jérôme Hénin <jerome.henin_at_ibpc.fr> w
>>>> rote:
>>>>
>>>>> I've been told of a certain command named fixedAtomsForces that sounds
>>>>> just like what you need :-)
>>>>>
>>>>> Jerome
>>>>>
>>>>> On 1 September 2017 at 00:03, Ben Adams <benny.adams1993_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Dear NAMD users,
>>>>>>
>>>>>> I want to calculate forces on a few constrained atoms while I'm doing
>>>>>> merely energy minimization. I used colvars with harmonic restraints and
>>>>>> obtained force based on the distance of the atom of interest to a specified
>>>>>> Center value. But the minimization causes dramatic fluctuations on
>>>>>> calculation of force. Changing the force constant, minimization options
>>>>>> mentioned in tutorial don't help that much. and the results are not even
>>>>>> reproducible.
>>>>>> An alternative way would be to freeze that atom and calculate the
>>>>>> force directly. But using the 'fixedAtoms' option leaves the force at the
>>>>>> atom equal to zero and do not allow to extract its value.
>>>>>> Is there any other way to freeze an atom while the force on it is
>>>>>> being calculated?
>>>>>> Or is there anyway to make minimization more stable when a colvar
>>>>>> constraint is present?
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>
This archive was generated by hypermail 2.1.6 : Mon Dec 31 2018 - 23:20:34 CST