[gmx-developers] force field reorganization
Berk Hess
hess at cbr.su.se
Mon Jan 25 17:47:36 CET 2010
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>.
>
>
More information about the gromacs.org_gmx-developers
mailing list