[gmx-developers] dynamic topology

Jason DeJoannis jdejoan at emory.edu
Mon Nov 10 18:30:15 CET 2003


Hi,
  I've got the mutation stuff running. For some reason, 
atoms2md() was not always doing its job. Sometimes the
mdatoms->type distribution would revert to the initial 
distribution. Because of the mismatch between 
top->atoms.atom[i].type and mdatoms->typeA[i] the program
crashed after 30 to 100 thousand steps. Interestingly (and 
annoyingly) it crashed my Linux as well. I am using Suse 8.2 
(kernel 2.4.20, i686, SMP). The full linux crash was reproducible 
under several conditions: with/without MPI, MPI serial/parallel, 
on another computer with the same linux. It was probably memory
-related as the memory usage was over 400MB. There must be a bug in 
this kernel or in this Linux-distro because the simulation crashed 
gracefully on the most recent Debian-distro (kernel 2.2.22).
 
  Instead of using atoms2md() now I change the mdatoms explicitely
and there are no more problems.
 
  If anyone wants to look at the MC/MD mutation algorithm I used 
you can simply replace your sim_util.c with mine (request by email
- too big to attach). Right now it accepts the MC mutation based 
on a chemical potential. The chemical potential is read from the 
unused tau_p parameter. It is written for monatomic lennard-jones 
systems and might not work for more than two species.
 
Best regards,
 
   -Jason DeJoannis
 
 
 
 
 Jason DeJoannis wrote:
 
 > Hi,
 > 
 >   Good, that worked. In fact I took advantage of 
 > the *mdatoms=atoms2md() to copy top->atoms to mdatoms. 
 > It would be more efficient to copy only the atoms that 
 > change but I am not worried about that right now.
 > 
 >   Do you have any remarks about a more complex topology
 > change? For example, what if I wanted to simulate mutation 
 > in an O2/Argon mixture (I'll stay away from charged groups 
 > for now). I am not sure how to proceed with polyatomic
 > molecules in other words. I am thinking that maybe I
 > have to delve into top->blocks[1] somehow.
 > 
 >   Another thing. How can I access basic properties for a
 > specific atom-type? I have looked and looked for a structure
 > that does this. Perhaps I should make my own. top->symtab is 
 > not easy to understand. For example, lets say I wish to know 
 > the standard mass and atomname for atom-type 'i'. For the 
 > atomname I would need a formula which converts i into an 
 > address for the corresponding string inside top->symtab.
 
 These things are in top->atoms, but IIRC not in mdatoms (for
 performance reasons). Mass is in mdatoms, though.
 
 symtab is a construction mainly to preserve memory, so that
 each atom- or residuename is stored only once. So, all entries
 in top->atomname (check exact structure syntax) and top->resname
 refer to symtab instead of having each a separately allocated
 area of memory for the name info.
 
 
 -- 
 Groetjes,
 
 Anton
   _____________ _______________________________________________________
 |             |                                                       |
 |  _   _  ___,| K. Anton Feenstra                                     |
 | / \ / \'| | | Dept. of Pharmacochem. - Vrije Universiteit Amsterdam |
 |(   |   )| | | De Boelelaan 1083 - 1081 HV Amsterdam - Netherlands   |
 | \_/ \_/ | | | Tel: +31 20 44 47608 - Fax: +31 20 44 47610           |
 |             | Feenstra at chem.vu.nl - www.chem.vu.nl/~feenstra/       |
 |             | "If You See Me Getting High, Knock Me Down"           |
 |             | (Red Hot Chili Peppers)                               |
 |_____________|_______________________________________________________|
 
 


---
Jason de Joannis, Ph.D.
Chemistry Department, Emory University
1515 Pierce Dr. NE, Atlanta, GA 30322
Phone: (404) 712-2983
Email: jdejoan at emory.edu
http://userwww.service.emory.edu/~jdejoan






More information about the gromacs.org_gmx-developers mailing list