I think this is a good idea. But, I have a question. How do I work with releases of force fields? Imagine, I work with release A and the force field is updated. However, I need to make tests before I update my simulations with newer release.<br>
<br>So, I have my subdirectory forcefield_Version. When I'll work with its newer release, Must I change the directory name only and put them the new files?<br><br>So, if I understood correctly I suggest the subdirectory name to contain the version of force field. If you have already this idea, sorry about this email.<br>
<br>Thanks in advanced.<br><br clear="all">--<br>Rodrigo Antonio Faccioli<br>Ph.D Student in Electrical Engineering<br>University of Sao Paulo - USP<br>Engineering School of Sao Carlos - EESC<br>Department of Electrical Engineering - SEL<br>
Intelligent System in Structure Bioinformatics<br><a href="http://laips.sel.eesc.usp.br">http://laips.sel.eesc.usp.br</a><br>Phone: 55 (16) 3373-9366 Ext 229<br>Curriculum Lattes - <a href="http://lattes.cnpq.br/1025157978990218">http://lattes.cnpq.br/1025157978990218</a><br>
<br><br><div class="gmail_quote">On Mon, Jan 25, 2010 at 1:23 PM, Berk Hess <span dir="ltr"><<a href="mailto:hess@cbr.su.se">hess@cbr.su.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Exactly.<br>
It should be easier now, since you no longer need an FF.dat file<br>
and you can also have a forcefield as a subdirectory of your working<br>
directory<br>
without having to set env.vars.<br>
<br>
Also water model management is simpler, since each force field directory<br>
will<br>
have its own water model files.<br>
<font color="#888888"><br>
Berk<br>
</font><div><div></div><div class="h5"><br>
Justin A. Lemkul wrote:<br>
><br>
> I assume it will also still be relatively easy to implement new force<br>
> fields? In the past, it was as easy as copying the necessary files to<br>
> $GMXLIB and updating FF.dat. Now I assume one can simply add a new<br>
> <something>.ff directory containing all the appropriate files and<br>
> pdb2gmx can process them?<br>
><br>
> -Justin<br>
><br>
> Berk Hess wrote:<br>
>> Ah, good that you mention this.<br>
>> I thought about this, but forgot about it.<br>
>> I will add a check such that is always uses the first entry and warns<br>
>> you<br>
>> when it ignores are second one.<br>
>> Your working dir will always be read first.<br>
>><br>
>> Another feature is that you can now have different bonded settings<br>
>> (bond, angle, dihedral types, nrexcl, etc.) for rtp entries in different<br>
>> files.<br>
>> But within each moleculetype only one setting can be used, pdb2gmx<br>
>> checks this.<br>
>><br>
>> Berk<br>
>><br>
>> Tsjerk Wassenaar wrote:<br>
>>> Hi Berk,<br>
>>><br>
>>> Sounds like a good idea. So it would also be easy to add ligands, as<br>
>>> it would only require to put a ligand.rtp to the directory, without<br>
>>> editing the original files? But what will happen if a certain residue<br>
>>> is defined in different files? Will it issue a warning, or an error,<br>
>>> something else?<br>
>>><br>
>>><br>
>>> Cheers,<br>
>>><br>
>>> Tsjerk<br>
>>><br>
>>> On Mon, Jan 25, 2010 at 3:34 PM, Berk Hess <<a href="mailto:hess@cbr.su.se">hess@cbr.su.se</a>> wrote:<br>
>>><br>
>>>> Hi,<br>
>>>><br>
>>>> I have made some changes in pdb2gmx to better organize all the force<br>
>>>> field files.<br>
>>>> But before I commit, I would like to have some feedback from the<br>
>>>> GROMACS<br>
>>>> community.<br>
>>>><br>
>>>> If have now made it such that force fields are all in separate<br>
>>>> directories and there is<br>
>>>> no longer an FF.dat file.<br>
>>>> Force fields are now detected by pdb2gmx by a filename in a<br>
>>>> subdirectory<br>
>>>> as follows:<br>
>>>> <ffname>.ff/forcefield.itp<br>
>>>> For example for OPLS:<br>
>>>> oplsaa.ff/forcefield.itp<br>
>>>> If the directory also contains a file forcefield.doc, the first<br>
>>>> line of<br>
>>>> this file is assumed<br>
>>>> to be a short description of the force field and this is printed<br>
>>>> (previously this was in FF.dat).<br>
>>>><br>
>>>> pdb2gmx then reads any files ending on .atp, .r2b, .rtp, .tdb, .hdb,<br>
>>>> both from the force field directory and the current working directory.<br>
>>>> The only mandatory files are one .atp file and one .rtp file.<br>
>>>> Termini from .tdb files are only applied to rtp entries from .rtp<br>
>>>> files<br>
>>>> with the same base file name.<br>
>>>> The general idea is to have, for instance:<br>
>>>> atomtypes.atp<br>
>>>> aminoacids.rtp<br>
>>>> aminoacids.n.tdb<br>
>>>> aminoacids.c.tdb<br>
>>>> aminoacids.hdb<br>
>>>> dna.rtp<br>
>>>> dna.n.tdb<br>
>>>> dna.c.tdb<br>
>>>> dna.hdb<br>
>>>><br>
>>>> Especially useful for AMBER, you can have .r2b files to map residue<br>
>>>> names to building block names,<br>
>>>> depending on the protonation state and if in termini or not.<br>
>>>> Also useful for AMBER, you would not longer be required to make tdb<br>
>>>> files.<br>
>>>> pdb2gmx checks if there are no dangling bonds due to missing termini.<br>
>>>><br>
>>>> For backward compatibility of grompp there would still be a file<br>
>>>> such as<br>
>>>> ffoplsaa.itp<br>
>>>> in the lib dir, which would simply #include<br>
>>>> ffoplsaa.ff/forcefield.itp,<br>
>>>> similarly there will<br>
>>>> be spc.itp, tip3p.tip, ions.itp etc.<br>
>>>><br>
>>>> Are there any objections or comments?<br>
>>>><br>
>>>> Berk<br>
>>>><br>
>>>> --<br>
>>>> gmx-developers mailing list<br>
>>>> <a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
>>>> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
>>>> Please don't post (un)subscribe requests to the list. Use the<br>
>>>> www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>><br>
><br>
<br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
</div></div></blockquote></div><br>