Re: FATAL ERROR: Due to a design error, GlobalMasterServer does not support individual atom requests from multiple global force clients on parallel runs.

From: dhacademic (dhacademic_at_gmail.com)
Date: Wed Sep 08 2010 - 17:07:09 CDT

I have checked the number by using VMD. There is no problem.

My files are very big (psf file ~60M, coor file ~10M). How can I send these
big files to Jerome and you?

On Wed, Sep 8, 2010 at 5:28 PM, Giacomo Fiorin <giacomo.fiorin_at_temple.edu>wrote:

> OK: I assumed that since you acknowledged that 2.7b1 was buggy, you were
> using 2.7b2 now, which should work. If it still doesn't with 2.7b2, there
> may be a mismatch with the topology, or some bug we don't know of.
>
> What about trying the following in VMD?
>
> [atomselect top "(segid A) and (resid 386 to 485)"] get serial
> [atomselect top "(segid A) and (resid 628 to 673)"] get serial
> ... (and similar ones for B, C, and D) ...
>
> If the atom numbers you get are less than expected, then there is something
> wrong with the topology. Otherwise, you should send to me and Jérôme the
> files, so that we investigate the error. In the meantime, you can use the
> numbers provided by those VMD commands as an argument to atomNumbers in
> NAMD. Does that work for you?
>
>
> Giacomo
>
>
> ---- ----
> Dr. Giacomo Fiorin
> ICMS - Institute for Computational Molecular Science - Temple University
> 1900 N 12 th Street, Philadelphia, PA 19122
> giacomo.fiorin_at_temple.edu
> ---- ----
>
>
>
> On Tue, Sep 7, 2010 at 4:31 PM, dhacademic <dhacademic_at_gmail.com> wrote:
>
>> Actually I had tried different combinations in atom definition part. None
>> of them work well.
>>
>> (1) "psfSegID A A B B C C D D" and then 8 instances of
>> "atomNameResidueRange".
>> (2) "psfSegID A A B B C C D D" and then 2 instances of
>> "atomNameResidueRange".
>> (3) 8 instances of "atomNameResidueRange" and then "psfSegID A A B B C C
>> D D".
>> (4) 2 instances of "atomNameResidueRange""psfSegID A A B B C C D D".
>>
>> If I just specify 2 instances of atomNameResidueRange, 236 atoms can be
>> selected (that is the number of atoms on each segment). But when 8 instances
>> of atomNameResidueRange is assigned, then 237 atoms will be defined. I do
>> not know where does this additional atoms come from.
>>
>>
>>
>>
>>
>> On Tue, Sep 7, 2010 at 12:23 PM, Giacomo Fiorin <
>> giacomo.fiorin_at_temple.edu> wrote:
>>
>>> Did you specify only two instances of atomNameResidueRange? If that's
>>> case, no wonder that segments B, C and D were ignored.
>>>
>>>
>>> Giacomo
>>>
>>> ---- ----
>>> Dr. Giacomo Fiorin
>>> ICMS - Institute for Computational Molecular Science - Temple
>>> University
>>> 1900 N 12 th Street, Philadelphia, PA 19122
>>> giacomo.fiorin_at_temple.edu
>>> ---- ----
>>>
>>>
>>>
>>>
>>
>>> On Mon, Sep 6, 2010 at 6:26 PM, dhacademic <dhacademic_at_gmail.com> wrote:
>>>
>>>> Hi Jerome and Giacomo,
>>>>
>>>> I have tried the following syntax (in colvars.conf file) according to
>>>> the reply:
>>>> atoms {
>>>>
>>>> psfSegID A A B B C C D D
>>>> atomNameResidueRange CA 386-485
>>>> atomNameResidueRange CA 628-763
>>>> }
>>>> And I still meet a similar output shown as follow. This time 236 atoms
>>>> on segment A can be selected. However, the rest atoms on segment B, C, D are
>>>> still ignored. It looks like that this atom definition error comes from to
>>>> the bug of the version 2.7b1.
>>>>
>>>> #### my output file ####
>>>> ....
>>>> colvars: Initializing atom group "atoms".
>>>> colvars: Warning: found more than one instance of "psfSegID".
>>>> colvars: Atom group "atoms" defined, 236 atoms, total mass =
>>>> 2834.6.
>>>>
>>>> colvars: # refPositionsFile = colvarb.pdb
>>>> colvars: # refPositionsCol = B
>>>> colvars: # refPositionsColValue = 1
>>>> colvars: Error: the PDB file "colvarb.pdb" contains coordinates for
>>>> only 87342 atoms, but 236 are needed.
>>>> .....
>>>>
>>>> Best,
>>>>
>>>> Hao
>>>>
>>>>
>>>>
>>>> On Mon, Sep 6, 2010 at 3:10 PM, Giacomo Fiorin <
>>>> giacomo.fiorin_at_temple.edu> wrote:
>>>>
>>>>> It would be best to use 2.7b2 or 2.7b3, in general.
>>>>>
>>>>> In the specific example, you used four psfSegID values but you
>>>>> specified them separately: the correct syntax is to put them on the same
>>>>> line (one psfSegID keyword with multiple values).
>>>>>
>>>>> Also, there may be only one atomNameResidueRange option for each
>>>>> psfSegID value, not two of them as in your case. You should use something
>>>>> like "psfSegID A A B B C C D D" to fix this.
>>>>>
>>>>> Giacomo
>>>>>
>>>>>
>>>>> ---- ----
>>>>> Dr. Giacomo Fiorin
>>>>> ICMS - Institute for Computational Molecular Science - Temple
>>>>> University
>>>>> 1900 N 12 th Street, Philadelphia, PA 19122
>>>>> giacomo.fiorin_at_temple.edu
>>>>> ---- ----
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 6, 2010 at 11:29 AM, dhacademic <dhacademic_at_gmail.com>wrote:
>>>>>
>>>>>> my version is NAMD 2.7b1
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 6, 2010 at 11:14 AM, Jérôme Hénin <
>>>>>> jhenin_at_ifr88.cnrs-mrs.fr> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> First, for TMD, you probably need the restraint force, so you should
>>>>>>> request outputAppliedForce, not outputSystemForce.
>>>>>>>
>>>>>>>
>>>>>>> > (1) Do the "centers" and "targets" keywords mean the initial and
>>>>>>> final RMSD
>>>>>>> > of the system? I feel confused by reading the related part of the
>>>>>>> > user-manual.
>>>>>>>
>>>>>>> They are the initial and final values of the center of the restraint
>>>>>>> potential. If all goes well, the RMSD should follow.
>>>>>>>
>>>>>>>
>>>>>>> > (2) I want to define 4 (segments) * 236 (per segment) = 944 atoms
>>>>>>> in the
>>>>>>> > input. However, only 237 atoms are defined according to the output
>>>>>>> > file. Someone else used a similar way to define atoms within
>>>>>>> different
>>>>>>> > segments
>>>>>>> > (
>>>>>>> http://www.ks.uiuc.edu/Research/namd/mailing_list/namd-l/12359.html).
>>>>>>> What
>>>>>>> > is wrong with my syntax?
>>>>>>>
>>>>>>> Not sure. What version of NAMD are you using? I wonder if this could
>>>>>>> be an old bug that is now fixed.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jerome
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:56:07 CST