Sorry about my mistake. I wrote that email based on my analysis of ff.dat. <br><br>Below I show you two lines from my ff.dat<br><br><ol><li>ffG53a6 GROMOS96 53a6 force field (JCC 2004 vol 25 pag 1656) </li><li>ffoplsaa OPLS-AA/L all-atom force field (2001 aminoacid dihedrals)</li>
</ol>I understood that your subdirectory names will be ffG53a6 and ffoplsaa. But I thought if OPLS has a newer version, I must work with them. So I'll need two subdirectory for OPLS force field. <br><br>Thanks in advanced.<br>
<br>--<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 2:47 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;">
I don't understand exactly what you are trying to say.<br>
<br>
Force fields are currently all stored in the same directory.<br>
All files in the same force field have the same name, but different<br>
extension ff<name>.???<br>
<br>
In the new setup all force fields are stored in separate directories<br>
called <name>.ff<br>
Inside this directory the base file names are completely free except for<br>
the files<br>
forcefield.itp and forcefield.doc (optional).<br>
<br>
Force file versioning doesn't really change, except that the naming<br>
moves from all forcefield file<br>
to the dir name only.<br>
<br>
Berk<br>
<div class="im"><br>
Rodrigo faccioli wrote:<br>
> I think this is a good idea. But, I have a question. How do I work<br>
> with releases of force fields? Imagine, I work with release A and the<br>
> force field is updated. However, I need to make tests before I update<br>
> my simulations with newer release.<br>
><br>
> So, I have my subdirectory forcefield_Version. When I'll work with its<br>
> newer release, Must I change the directory name only and put them the<br>
> new files?<br>
><br>
> So, if I understood correctly I suggest the subdirectory name to<br>
> contain the version of force field. If you have already this idea,<br>
> sorry about this email.<br>
><br>
> Thanks in advanced.<br>
><br>
> --<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" target="_blank">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" target="_blank">http://lattes.cnpq.br/1025157978990218</a><br>
><br>
><br>
> On Mon, Jan 25, 2010 at 1:23 PM, Berk Hess <<a href="mailto:hess@cbr.su.se">hess@cbr.su.se</a><br>
</div><div><div></div><div class="h5">> <mailto:<a href="mailto:hess@cbr.su.se">hess@cbr.su.se</a>>> wrote:<br>
><br>
> 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<br>
> directory<br>
> will<br>
> have its own water model files.<br>
><br>
> Berk<br>
><br>
> Justin A. Lemkul wrote:<br>
> ><br>
> > I assume it will also still be relatively easy to implement new<br>
> force<br>
> > fields? In the past, it was as easy as copying the necessary<br>
> 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<br>
> 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<br>
> 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<br>
> ligands, as<br>
> >>> it would only require to put a ligand.rtp to the directory,<br>
> without<br>
> >>> editing the original files? But what will happen if a certain<br>
> residue<br>
> >>> is defined in different files? Will it issue a warning, or an<br>
> 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><br>
</div></div><div><div></div><div class="h5">> <mailto:<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<br>
> 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,<br>
> .tdb, .hdb,<br>
> >>>> both from the force field directory and the current working<br>
> 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<br>
> 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<br>
> make tdb<br>
> >>>> files.<br>
> >>>> pdb2gmx checks if there are no dangling bonds due to missing<br>
> 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>
</div></div>> >>>> <a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a> <mailto:<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a>><br>
<div class="im">> >>>> <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<br>
> <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a><br>
</div>> <mailto:<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> <mailto:<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a>><br>
<div class="im">> <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>> <mailto:<a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>>.<br>
<div><div></div><div class="h5">><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>