[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