[gmx-developers] file headers & nblists

[Vishal Vaidyanathan]

On Tue, 11 Jun 2002, Erik Lindahl wrote:

> Vishal Vaidyanathan wrote:
> > Hi All!
> >
> >   To the gmx developers: gmx is AMAZING! Thank you SO MUCH for this
> > fantastic program!!
> >
> >   I'm in the process of implementing SASA based implicit solvent models in
> > gromacs and have a few questions:
> >
> > 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.
>
> I don't see any problem with adding it, the only question is which way
> is smartest; assume the official distribution is 'A', and there are two
> groups using derived versions 'B' and 'C'. I don't see any obvious way
> for group C to use files from group B without having their gromacs
> version too?
>
> The easiest approach would of course be to add two fiels; one
> description string and an email adress. If the description strings don't
> match we simply echo out the email adress and recommend you get in touch
> with this person to find a version of grompp that supports your file...
>
> It might not be a big problem though; we are planning to get rid of
> grompp and let mdrun read XML input/data/coordinate files automatically.


Well yes, group C would anyway not be able to use group B's files, only
now there will be a way to check and warn them in the code. Also, it would
be possible if group B and C independently kept up to date with A (but not
with each other), that official gromacs files would always work for end
user D whether D uses B's extensions or C's extensions and if D screwed up
with the combinations, he would know about it! :-)

But yes, with XML in the works, it may not be worth adding this in right
now. I don't know how many groups are actively in the process of
developing additions to gromacs. If not too many, it would always be
possible to add contributions into official gromacs through CVS I suppose.


>
> >
> > 3) Is a gmx "builder" in the works by any chance? For design work, I am
> > going to implement (after the implicit solvent models are done and tested)
> > a program to generate/mutate structures on the fly. Any suggestions or
> > comments are welcome.
>
> Sounds interesting. By 'on the fly' I guess you mean 100% automated -
> could you expand the idea a bit?
>
> Cheers,
>
> Erik

  Yep - the code would be something like this:

     1)   Choose initial structure and evaluate energy
     2)   Mutate
     3)   Evaluate energy
     4)   Accept or reject using Metropolis or similar criterion
     5)   Go to step 2 unless you're done.

  Of course the code to mutate might as well be given a nice user
interface so that people could construct (interactively or through
scripts) various molecules from a library of building blocks or tweak
structures on existing PDB's. Currently users need a separate modelling
program if they want to cap the protein before simulating in gromacs for
example, or if they want to start with a specific conformation in mind,
not from the PDB. I think many people might find this a useful tool
within gromacs.

  Thanks,
								Vishal