[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