[gmx-developers] force field reorganization

Rodrigo faccioli rodrigo_faccioli at uol.com.br
Mon Jan 25 18:38:07 CET 2010


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> 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>> 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>> 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>
> >     >>>> 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>.
> >     >>>>
> >     >>>>
> >     >>>
> >     >>>
> >     >>>
> >     >>
> >     >
> >
> >     --
> >     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>.
> >
> >
>
> --
> gmx-developers mailing list
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20100125/6faee34e/attachment.html>


More information about the gromacs.org_gmx-developers mailing list