[gmx-developers] force field reorganization

Berk Hess hess at cbr.su.se
Tue Jan 26 09:30:52 CET 2010


The directory names are completely free (except for the extension).
So they could be:
G53a6.ff
oplsaa.ff
Then if there would be a new opls forcefield in 2010, we could add:
oplsaa2010.ff

But again, I don't see how my change affect this. Currently you have
to add new file names, in the new scheme you have to add a directory name.

Berk

Rodrigo faccioli wrote:
> Sorry about my mistake. I wrote that email based on my analysis of
> ff.dat.
>
> Below I show you two lines from my ff.dat
>
>    1. ffG53a6    GROMOS96 53a6 force field (JCC 2004 vol 25 pag 1656)
>    2. ffoplsaa   OPLS-AA/L all-atom force field (2001 aminoacid dihedrals)
>
> 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. 
>
> Thanks in advanced.
>
> --
> Rodrigo Antonio Faccioli
> Ph.D Student in Electrical Engineering
> University of Sao Paulo - USP
> Engineering School of Sao Carlos - EESC
> Department of Electrical Engineering - SEL
> Intelligent System in Structure Bioinformatics
> http://laips.sel.eesc.usp.br
> Phone: 55 (16) 3373-9366 Ext 229
> Curriculum Lattes - http://lattes.cnpq.br/1025157978990218
>
>
> On Mon, Jan 25, 2010 at 2:47 PM, Berk Hess <hess at cbr.su.se
> <mailto:hess at cbr.su.se>> wrote:
>
>     I don't understand exactly what you are trying to say.
>
>     Force fields are currently all stored in the same directory.
>     All files in the same force field have the same name, but different
>     extension ff<name>.???
>
>     In the new setup all force fields are stored in separate directories
>     called <name>.ff
>     Inside this directory the base file names are completely free
>     except for
>     the files
>     forcefield.itp and forcefield.doc (optional).
>
>     Force file versioning doesn't really change, except that the naming
>     moves from all forcefield file
>     to the dir name only.
>
>     Berk
>
>     Rodrigo faccioli wrote:
>     > 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.
>     >
>     > 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?
>     >
>     > 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.
>     >
>     > Thanks in advanced.
>     >
>     > --
>     > Rodrigo Antonio Faccioli
>     > Ph.D Student in Electrical Engineering
>     > University of Sao Paulo - USP
>     > Engineering School of Sao Carlos - EESC
>     > Department of Electrical Engineering - SEL
>     > Intelligent System in Structure Bioinformatics
>     > http://laips.sel.eesc.usp.br
>     > Phone: 55 (16) 3373-9366 Ext 229
>     > Curriculum Lattes - http://lattes.cnpq.br/1025157978990218
>     >
>     >
>     > On Mon, Jan 25, 2010 at 1:23 PM, Berk Hess <hess at cbr.su.se
>     <mailto:hess at cbr.su.se>
>     > <mailto:hess at cbr.su.se <mailto:hess at cbr.su.se>>> wrote:
>     >
>     >     Exactly.
>     >     It should be easier now, since you no longer need an FF.dat file
>     >     and you can also have a forcefield as a subdirectory of your
>     working
>     >     directory
>     >     without having to set env.vars.
>     >
>     >     Also water model management is simpler, since each force field
>     >     directory
>     >     will
>     >     have its own water model files.
>     >
>     >     Berk
>     >
>     >     Justin A. Lemkul wrote:
>     >     >
>     >     > I assume it will also still be relatively easy to
>     implement new
>     >     force
>     >     > fields? In the past, it was as easy as copying the necessary
>     >     files to
>     >     > $GMXLIB and updating FF.dat.  Now I assume one can simply
>     add a new
>     >     > <something>.ff directory containing all the appropriate
>     files and
>     >     > pdb2gmx can process them?
>     >     >
>     >     > -Justin
>     >     >
>     >     > Berk Hess wrote:
>     >     >> Ah, good that you mention this.
>     >     >> I thought about this, but forgot about it.
>     >     >> I will add a check such that is always uses the first
>     entry and
>     >     warns
>     >     >> you
>     >     >> when it ignores are second one.
>     >     >> Your working dir will always be read first.
>     >     >>
>     >     >> Another feature is that you can now have different bonded
>     settings
>     >     >> (bond, angle, dihedral types, nrexcl, etc.) for rtp
>     entries in
>     >     different
>     >     >> files.
>     >     >> But within each moleculetype only one setting can be
>     used, pdb2gmx
>     >     >> checks this.
>     >     >>
>     >     >> Berk
>     >     >>
>     >     >> Tsjerk Wassenaar wrote:
>     >     >>> Hi Berk,
>     >     >>>
>     >     >>> Sounds like a good idea. So it would also be easy to add
>     >     ligands, as
>     >     >>> it would only require to put a ligand.rtp to the directory,
>     >     without
>     >     >>> editing the original files? But what will happen if a
>     certain
>     >     residue
>     >     >>> is defined in different files? Will it issue a warning,
>     or an
>     >     error,
>     >     >>> something else?
>     >     >>>
>     >     >>>
>     >     >>> Cheers,
>     >     >>>
>     >     >>> Tsjerk
>     >     >>>
>     >     >>> On Mon, Jan 25, 2010 at 3:34 PM, Berk Hess
>     <hess at cbr.su.se <mailto:hess at cbr.su.se>
>     >     <mailto:hess at cbr.su.se <mailto:hess at cbr.su.se>>> wrote:
>     >     >>>
>     >     >>>> Hi,
>     >     >>>>
>     >     >>>> I have made some changes in pdb2gmx to better organize all
>     >     the force
>     >     >>>> field files.
>     >     >>>> But before I commit, I would like to have some feedback
>     from the
>     >     >>>> GROMACS
>     >     >>>> community.
>     >     >>>>
>     >     >>>> If have now made it such that force fields are all in
>     separate
>     >     >>>> directories and there is
>     >     >>>> no longer an FF.dat file.
>     >     >>>> Force fields are now detected by pdb2gmx by a filename in a
>     >     >>>> subdirectory
>     >     >>>> as follows:
>     >     >>>> <ffname>.ff/forcefield.itp
>     >     >>>> For example for OPLS:
>     >     >>>> oplsaa.ff/forcefield.itp
>     >     >>>> If the directory also contains a file forcefield.doc,
>     the first
>     >     >>>> line of
>     >     >>>> this file is assumed
>     >     >>>> to be a short description of the force field and this
>     is printed
>     >     >>>> (previously this was in FF.dat).
>     >     >>>>
>     >     >>>> pdb2gmx then reads any files ending on .atp, .r2b, .rtp,
>     >     .tdb, .hdb,
>     >     >>>> both from the force field directory and the current working
>     >     directory.
>     >     >>>> The only mandatory files are one .atp file and one .rtp
>     file.
>     >     >>>> Termini from .tdb files are only applied to rtp entries
>     from .rtp
>     >     >>>> files
>     >     >>>> with the same base file name.
>     >     >>>> The general idea is to have, for instance:
>     >     >>>> atomtypes.atp
>     >     >>>> aminoacids.rtp
>     >     >>>> aminoacids.n.tdb
>     >     >>>> aminoacids.c.tdb
>     >     >>>> aminoacids.hdb
>     >     >>>> dna.rtp
>     >     >>>> dna.n.tdb
>     >     >>>> dna.c.tdb
>     >     >>>> dna.hdb
>     >     >>>>
>     >     >>>> Especially useful for AMBER, you can have .r2b files to map
>     >     residue
>     >     >>>> names to building block names,
>     >     >>>> depending on the protonation state and if in termini or
>     not.
>     >     >>>> Also useful for AMBER, you would not longer be required to
>     >     make tdb
>     >     >>>> files.
>     >     >>>> pdb2gmx checks if there are no dangling bonds due to
>     missing
>     >     termini.
>     >     >>>>
>     >     >>>> For backward compatibility of grompp there would still
>     be a file
>     >     >>>> such as
>     >     >>>> ffoplsaa.itp
>     >     >>>> in the lib dir, which would simply #include
>     >     >>>> ffoplsaa.ff/forcefield.itp,
>     >     >>>> similarly there will
>     >     >>>> be spc.itp, tip3p.tip, ions.itp etc.
>     >     >>>>
>     >     >>>> Are there any objections or comments?
>     >     >>>>
>     >     >>>> Berk
>     >     >>>>
>     >     >>>> --
>     >     >>>> gmx-developers mailing list
>     >     >>>> gmx-developers at gromacs.org
>     <mailto:gmx-developers at gromacs.org>
>     <mailto:gmx-developers at gromacs.org
>     <mailto:gmx-developers at gromacs.org>>
>     >     >>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>     >     >>>> Please don't post (un)subscribe requests to the list.
>     Use the
>     >     >>>> www interface or send it to
>     >     gmx-developers-request at gromacs.org
>     <mailto:gmx-developers-request at gromacs.org>
>     >     <mailto:gmx-developers-request at gromacs.org
>     <mailto:gmx-developers-request at gromacs.org>>.
>     >     >>>>
>     >     >>>>
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>
>     >     >
>     >
>     >     --
>     >     gmx-developers mailing list
>     >     gmx-developers at gromacs.org
>     <mailto:gmx-developers at gromacs.org>
>     <mailto:gmx-developers at gromacs.org
>     <mailto:gmx-developers at gromacs.org>>
>     >     http://lists.gromacs.org/mailman/listinfo/gmx-developers
>     >     Please don't post (un)subscribe requests to the list. Use the
>     >     www interface or send it to
>     gmx-developers-request at gromacs.org
>     <mailto:gmx-developers-request at gromacs.org>
>     >     <mailto:gmx-developers-request at gromacs.org
>     <mailto:gmx-developers-request at gromacs.org>>.
>     >
>     >
>
>     --
>     gmx-developers mailing list
>     gmx-developers at gromacs.org <mailto:gmx-developers at gromacs.org>
>     http://lists.gromacs.org/mailman/listinfo/gmx-developers
>     Please don't post (un)subscribe requests to the list. Use the
>     www interface or send it to gmx-developers-request at gromacs.org
>     <mailto:gmx-developers-request at gromacs.org>.
>
>




More information about the gromacs.org_gmx-developers mailing list