[gmx-developers] force field reorganization done

[Berk Hess]

Berk Hess wrote:
> David van der Spoel wrote:
>   
>> On 1/28/10 10:08 AM, Berk Hess wrote:
>>     
>>> David van der Spoel wrote:
>>>       
>>>> On 1/28/10 9:52 AM, Berk Hess wrote:
>>>>         
>>>>> David van der Spoel wrote:
>>>>>           
>>>>>> Another small thing:
>>>>>>
>>>>>> pdb2gmx now generates topologies with the full path to the forcefield
>>>>>> files, e.g.:
>>>>>>
>>>>>> ; Include forcefield parameters
>>>>>> #include
>>>>>> "/home/spoel/software-5.0b/share/gromacs/top/oplsaa.ff/forcefield.itp"
>>>>>>
>>>>>>
>>>>>> Is that what we want?
>>>>>> If I remove the path in
>>>>>> [anfinsen:water/tip4p] % echo $GMXDATA
>>>>>> /home/spoel/software-5.0b/share
>>>>>>
>>>>>> to get
>>>>>> ; Include forcefield parameters
>>>>>> #include "gromacs/top/oplsaa.ff/forcefield.itp"
>>>>>>
>>>>>> grompp does not find the include files anymore.
>>>>>>
>>>>>> We probably need to update some code in gmxcpp.c to fix it, such that
>>>>>> paths relative to $GMXDATA are still recognized.
>>>>>>
>>>>>>             
>>>>> I noticed this full path thing as well.
>>>>> I can probably fix that in pdb2gmx.
>>>>>
>>>>> The question is if we always want to
>>>>> include<ffname>.ff/forcefield.itp,
>>>>> even when you have explicitly set the GMXLIB env var.
>>>>> I guess that in that case you do want the full path.
>>>>>
>>>>> GMXDATA is set but currently not used by any Gromacs program.
>>>>> So I think we should currently not rely on that, unless we decide
>>>>> to do
>>>>> so and check it thoroughly.
>>>>>
>>>>> Berk
>>>>>
>>>>>           
>>>> It is more a grompp problem, if you write topologies yourself you have
>>>> to give the full path to the force field files.
>>>>
>>>>         
>>> No, when I fix pdb2gmx things will be as before.
>>> Or is gmxcpp (and cpp?) not capable of finding files in a subdirectory
>>> of the share/top dir?
>>> In that case this functionality needs to be implemented in gmxcpp.c.
>>>       
>>>> Maybe we should kick out both GMXDATA and GMXLIB variables, and rely
>>>> on the installation information?
>>>>
>>>>         
>>> Currently GMXDATA is never used and GMXLIB is never set.
>>> The GMXLIB functionality is very useful and should stay there, but
>>> GMXLIB is not by default.
>>> By default all programs locate share/top from the binary location.
>>>
>>> Berk
>>>
>>>       
>> But if I have:
>> [anfinsen:water/tip4p] % cat topol.top
>> #include "oplsaa.ff/forcefield.itp"
>> #include "oplsaa.ff/tip4p.itp"
>>
>> [ system ]
>> 512 TIP/4P
>>
>> [ molecules ]
>> SOL    512
>>
>> grompp tells me
>>
>> Program grompp, VERSION 4.0.99_development_20090927
>> Source code file: /home/spoel/GG/gromacs/src/gmxlib/gmxcpp.c, line: 232
>>
>> Fatal error:
>> Can not chdir to oplsaa.ff when processing topology. Reason: No such
>> file or directory
>>
>>
>> This has nothing to do with pdb2gmx.
>>
>>
>>     
> Is this with a completely installed Gromacs system?
> The share/top dir location has to be inferred from the path of the binary.
> For me it works after a make install and calling pdb2gmx from the
> installed directory.
>
> Berk
>
>   
Ah, I must have made a mistake in my testing.
I now get the same error.

So gmxcpp needs to search in the libpath for the force field directory.
It already searches in libpath for plain files without subdir, right?
So this is standard cpp functionality that is missing from gmxcpp.
While searching in the path gmxcpp should check if it is searching for a
file
or a file in a subdir and take this into account.

Berk