[gmx-developers] file headers & nblists

[Vishal Vaidyanathan]

On Tue, 11 Jun 2002, Anton Feenstra wrote:

> Vishal Vaidyanathan wrote:
> >
> >   I'm in the process of implementing SASA based implicit solvent models in
> > gromacs and have a few questions:
>
> Great! Although I am not a believer in implicit solvents, it would
> be nice to have them as comparison, or for certain cases where they
> do work.
>

There are two reasons for my wanting implicit solvent models in gromacs:

1) With the speed of gromacs and with the infrastructure of Folding at Home
at Pandelab, it would be possible to extensively sample conformation space
(we're talking about milli seconds to seconds of simulation) and arrive at
a conclusion about the use of such models without wondering if sampling
was the reason the model did not work. In a sense we'd be able to push
implicit solvents to their limit. And who knows? What if they work??  :-)



2) I hope this answers Erik's question of what I mean by generating
structures on the fly:
   With implicit solvent support, I would like to eventually make it
possible to keep a fixed conformation (or atomistic environment) and
mutate structures or sequences in, for example a Monte Carlo fashion, to
arrive at structures with a minimum energy for a given conformation.
Clearly such a process would be too hard if we had to use explicit solvent
MD for a short time after each mutation, since adequate sampling of
protein sequence space is really very hard. Even a crude pre-screening as
may be afforded by implicit solvent models would be well worth the effort
in my opinion and then screened structures can be studied more carefully
with explicit solvent simulations.


> > 1) Would it be possible (useful?) for the official gromacs file headers to
> > include an extra string field besides the version number that can be used
> > by different groups working on gromacs to identify their own specific file
> > types? That would make it possible for groups to develop and distribute
> > gromacs mods that may not be included in the official gromacs distrib, but
> > still be compatible with official gromacs files or atleast warn the user
> > that they are using the wrong file/program combo?
> >    I am not sure using large version numbers for this purpose will be as
> > straightforward as using a small string id.
>
> That sounds like official support for officially unsupported versions
> ;-)
>
> Somehow, I don't like the idea. Additional features shouldn't interfere
> with the 'basics' in such a way that things get incompatible. (Also for
> your own sake I would advise against it, it gets very confusing!) So
> as long as additions and/or modifications are compatible with what's
> already there, it shouldn't matter which version (official, or local
> hack or whatever) you use; same input -> same output. (Unless you turn
> on something new by default ofcourse, but there you should also be
> very conservative, imho.)

My reasoning goes like this: I started modifying official tpx version 21.
By the time I added parameters to my tpx file, the original developers
moved on to version 24. Clearly my tpx and the latest official tpx would
not work compatibly, although my tpx readers would work with version<=21.
As long as I maintain my code up to date with the cvs, there would be no
problem, but if I were to contribute a gromacs mod that did not become
part of official gromacs (maybe because it's untested or whatever) and no
longer develop it, it would not be possible for people to use my mod
without updating code themselves. Since most file formats have a string
descriptor of the format, I thought it would not be unreasonable for us to
have the same in gromacs.

Anyhow this question is redundant if XML will be used in the future. I
shall continue developing with large version numbers at present.

> > 2) I have to implement a cut-off based calculation for the SASA (solvent
> > accessible surface area). Could someone explain how I can use the
> > neighbour list code to make two neighbour lists - one consisting of
> > covalently bonded neighbours and one consisting of everything but
> > covalently bonded neighbours, but within a certain cutoff. A very brief
> > explanation of the nblist data structures (or even a quick ascii pointer
> > diagram) would help me a long way here. I don't need to understand the
> > details of the neighbour search, just the basic idea behind how the info
> > is stored and how I should call init_nblist() or search_neighbours() in
> > ns.c
>
> g_hbond uses the nblist code for finding h-bonds, so you could
> look into the g_hbond code and see how it's done. At least that
> would be easier to read than the mdrun code... ;-)
>
> --
> Groetjes,
>
> Anton


Thank you very much! Now I can finish my work and my advisor will be
happy... :-)

Thanks!!
								Vishal