[gmx-users] Reading XTC files from fortran90
Jones de Andrade
johannesrs at gmail.com
Mon Oct 1 17:53:45 CEST 2007
First of all, I would really want want to apologize if I somehow
missunderstood any previous message from anyone, and made myself a bit
annoying because of this fact.
Second, I would like to say thanks again to eferybody for all help in these
On 10/1/07, Tsjerk Wassenaar <tsjerkw at gmail.com> wrote:
> I'd say the easiest is to get into gmx_editconf and look at the option
> "-grasp" or "-mead" which put the atomic charge and vdw radius in the
> b-factor and occupancy field of a .pdb file when given a .tpr file.
> It's trivial to make it write charges and masses instead. Would also
> be a good first exercise for C/Gromacs :p
Good idea! Even I don't choose to sitck with many file type conversions for
the sake of the disk space, that specific program now seems to be a good
start to learn explicitly how all the topology data is passed from one place
to the other. And that would help me to learn how to read the topology files
(since it seems to be only a matter now of reading atomic charges and
I'm not sure what you mean with "shape" and "that integer". There's
> nothing much redundant in the .xtc file and there are no integers
> having to do with box shape. In fact, there is no "shape"...
Well, by "shape" I meant "cubic" and "truncated octahedral", for example.
But the integer was my mistake (old dlpoly adaptions that just came to my
mind, together with the first integer in the header of all xdrf files and
that I could not find a proper meaning at time), thought for a moment that
the first integer in the .xtc header mean the "shape of the box". Just
played a bit later with the manual and recorded that it's only the 9 box
parameters that are important to define that within gromacs. Sorry for that
> > So, I would have atom names,
>From .gro or .pdb file in the standard way.
> number of molecules types,
> > number of molecules of each type,
> > number of atoms of each molecule type,
I think those three can become yes in a really easy way: some kind of "state
machine" would easily do the trick and "count" them properly.
>From .xtc or .pdb file.
> Yes, if you use the right editconf option
> and masses on a .pdb file, correct?
Only modifying editconf to print those in a adapted .pdb file, throw a file
conversion and much disk space "wasted". Or I can learn exactly from
editconf how to read it from .tpr or .top (I guess it takes from these files
the atomic charges when needed) and adapt into my codes.
> But, still, where could I then easilly get the box type and sizes, as
> > well as simulation times?
> The .xtc file, the .edr file...
So .xtc, since its already under control. ;)
Fine :-) That's the sort of reason that you'd want to have to keep
> Fortran for the present problem.
So we agree here. Three ways so: converting the trajectories to another
format (ugly for my taste, and too much disk space needed), linking to a
library (like done in reading .xtc files) or linking to an object. ;)
Like I said, the masses are easy to infer from the atom names. You don't
> need to read them... you know anything starting with N has mass 14.011
> (or whatever it is). Or you can read share/gromacs/top/atommass.dat to
> do the lookups.
That is the kind of stuff I really don't like. For instance, all codes I
written for all this time long aimed at being abolutelly general. So, if
anything starting by N means nitrogen, how to deal when someone using the
same program (even in the group) chooses to say that Nb is a "different type
of nitrogen" while another says it is "niobium"? The program must be able to
deal with such problems that arise (and believe, I've already got locked at
this one once, and that's why I don't go such a way anymore), and the only
way I see it doing so is directly reading the topologies, instead of
"knowing" it in advance. ;)
> Sorry for not noticing the box shape in the .xtc file. I passed over
> > that integer in the reading, dismissing it as only some kind of old
> > feature useless now. Really sorry for that point.
> > Which files should I look for in order to get the proper way of reading
> > masses and atomic charges from a .tpr file? And which objects will need
> > to be included in the linking stage? Is there any "outsider" program
> > (fortran would be perfect, but I don't think it will be too common too)
> > that works directly with the .tpr files?
> tpxio.c will have relevant functions. Or, follow the execution of mdrun
> until it reads the .tpr file and see how it handles these things.
Thanks a lot! That final information will be really usefull for me to sort
out how to properly link those routines in my codes. :)
If you use the editconf suggestion to get charges, you don't need to
> read a .tpr file.
But then or I get locked into the problem of generality of having too much
disk usage. But that idea will be also usefull to learn how to read the
masses and charges from .tpr files.
> Thanks a lot everybody for all the help, and sorry for taking so much of
> > your time,
> Help is fine, but repeating myself is tiresome :-)
> > Wait a second, you mean that editconf would allow me to have both
> > charges and masses on a .pdb file directly from command line (having
> > other matters asking for my presence absolutelly now, so please forgive
> > me if this message becomes somehow strange)
> No, nobody said that. Please read free advice carefully, since there's
> no better way to annoy the giver than to not be understood when they've
> expressed an idea clearly.
I'm absolutelly really sorry for that. I can only apologize myself that I
commited such a reading mistake on your email message. Please forgive me for
being so boring at that moment.
Thanks a lot to everybody for all help with this matter, and really sorry
for taking so much of your time with these matters.
If and when everything goes smoothly here, I'll probably post something
related, in order to help others that come with the same question. Possibly
a small test program to read those from .tpr files and print them on screen.
Again, thanks a lot for all help.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gromacs.org_gmx-users