[gmx-developers] force field reorganization

[Rodrigo faccioli]

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> 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> 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
> >>>> 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.
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
>
> --
> 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/3aba7caf/attachment.html>