Re: [gmx-users] Segmentation Fault (Address not mapped)

Mon, 03 Aug 2009 19:15:47 -0700 

Darrell Koskinen wrote:

Hi Justin,
I just want to use the most appropriate force field and associated parameters for my simulation of graphene in ammonia gas. Is OPLS an appropriate force field to use? 


It seems fairly unlikely that it is appropriate. Force fields are 
parameterized to reproduce a range of behaviour of a certain classes of 
chemicals. To understand what these are, you need to read the primary 
literature for that force field. There is no reason to suppose that a 
force field parameterized to reproduce (say) condensed-phase properties 
of peptides should be effective at modelling either infinite graphene, 
or gas-phase ammonia. It might work, and similar things might have been 
shown to work, but that's your job to prove and/or read about.



I have searched for force fields for gas simulations but have not yet 
been able to find one specific to graphene and ammonia gas. Since 
graphene is in a condensed phase and ammonia is in a gas phase and I 
understand that I need to use the same force field for both graphene and 
ammonia, I will have to use a force field for either gas-phase MD or 
condensed-phase MD. Since I am finding it difficult to locate gas-phase 
MD force fields, is it acceptable to use a condensed-phase MD force 
field, which I believe is the case for OPLS (please confirm)?



Only if you can demonstrate that it's doing a good job. For starters, 
does a simulation of gas-phase ammonia using these parameters reproduce 
density and diffusion constants? Is an infinite graphene lattice in 
vacuum stable? Otherwise any paper you wrote might be rejected out-of-hand.



If it is acceptable to use OPLS, then I am assuming that I am to use the 
parameters in the ffoplsaabon.itp and ffoplsaanb.itp as is and not 
modify them (i.e. not create frankenstein force fields), correct? Am I 
correct in my understanding that the only item that requires 
modification is the .n2t file?


I can't say.


And, by the way, I have resolved the segmentation fault problem. It was 
being caused by the freezing of the graphene lattice. When I removed the 
freezing, I saw the graphene structure curl upward and am thinking that 
by freezing the atoms in place it was creating great forces between the 
atoms as they were kept from moving into their preferred orientation.



Yep, that's right. The segfault was probably indirectly a consequence of 
integrating large opposing forces on these atoms. A small perturbation 
in a position might now result in a large change in net force, a large 
displacement on a frozen atom, and the whole thing goes up in 
silicaceous smoke.



I subsequently tried to restrain the atoms via position restraints, but 
I still see the graphene structure moving. Could you please let me know 
why the position restraints do not appear to be working? Do I need to 
use greater restraint parameters? I created a position restaint file for 



Yes and no. Position restraints are good for giving things a gentle 
nudge to stay where you've put them. The textbook usage is that while 
equilibrating a starting structure into an ensemble, you don't want it 
to move much. Then once you're happy with your equilibrium ensemble, 
then you remove the restraints and see what really happens. However, if 
you're using them to smash something flat that really doesn't want to be 
flat, then you run the risk of integration problems as above. The fact 
of not wanting to be flat indicates that the model physics is severely 
broken, as Dallas has observed. You need to work out how and why it is 
broken, and once you fix the real problem, restraints or freezing might 
not prove to be needed.


Mark


the graphene structure posre.itp using "genpr -f graphene.gro -n 
index.ndx -o posre.itp -fc 0 0 1000" (note that genrestr is not 
recognized in my version of GROMACS) to restrain the graphene lattice to 
the x-y plane and submitted 2 runs with the following in my run.mdp file:


Run 1:
define =-DPOSRES
constraints =none

Run 2:
define =-DPOSRES
constraints =all-bonds


Run 1 with constraints=none appears to restrain the graphene lattice 
better than the Run 2 with constraints=all-bonds.


Here is an extract from posre.itp for the first few atoms:

******************************************
; position restraints for Grph of Ãzú^K^Q+

[ position_restraints ]
; i funct fcx fcy fcz
1 1 0 0 1000
2 1 0 0 1000
3 1 0 0 1000
******************************************

Again, I thank you very much for your assistance.

Darrell


Date: Mon, 27 Jul 2009 17:48:02 -0400
From: "Justin A. Lemkul" <jalem...@vt.edu>
Subject: Re: [gmx-users] Segmentation Fault (Address not mapped)
To: Discussion list for GROMACS users <gmx-users@gromacs.org>
Message-ID: <4a6e2092....@vt.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed



Darrell Koskinen wrote:

 

Hi Justin,

With regard to your comment about using other force fields for my 
simulation of graphene surrounded by ammonia gas, are referring to 
the force fields for both graphene and ammonia or only to the force 
field for graphene?



    



The "force field" should be one in the same.  The parameters should be 
suitably derived using the same scheme as the original work.



 

I reviewed my selection of the force field parameters for graphene 
and see that I selected the parameters from the paper by Cornell et 
al. since a paper on deformation of carbon nanotubes ("A structural 
mechanics approach for the analysis of carbon nanotubes" by Chunyu 
Li, Tsu-Wei Chou in International Journal of Solids and Structures 40 
(2003) 2487–2499) used parameters from the paper by Cornell et al. Is 
this sufficient to justify the use of these parameters? I also 
thought that graphene and ammonia would be considered organic since 
they are comprised of carbon, nitrogen, and hydrogen, which are all 
common elements found in organic matter.



    



If you feel that precedent is sufficient, then I guess go ahead.  But 
realize that the paper by Cornell et al. refers to parameters suitable 
for simulations of proteins and nucleic acids, as well as a few 
organic functional groups. Parameterization was based on peptide 
backbone geometry, as well as other parameters, likely none of which 
involved graphene and gaseous ammonia (they were doing liquid 
simulations).



 

With regard to the parameters for ammonia, is it acceptable to use 
the parameters from the paper by Cornell et al. or do I need to find 
papers specifically related to ammonia gas molecular dynamics 
simulations?



    



I would seriously consider finding parameters (if they exist) that 
have been derived for use with gas-phase simulations.



 

With regard to dihedral selection, I looked at the .top file and see 
that the function type is listed as 3 in the dihedrals section, which 
I believe indicates that my simulation is using a Ryckaert-Bellemans 
function. It appears to me that if I am using the OPLS force field 
that the Ryckaert-Bellemans dihedral type is automatically selected. 
I do see in the ffoplsaabon.itp file that there is an improper 
dihedral definition which think I could potentially use in my 
simulation "improper_Z_CA_X_Y", but how do I cause my simulation to 
use this definition? Do I need to add the following line to my .top 
file?

"#define improper_Z_CA_X_Y"


    



No, you would have to use a special dihedrals section, that specifies 
the four atoms involved (function type 1), followed by the 
specification of that particular improper ("improper_Z_CA_X_Y").  See 
the manual for more details, and/or generate a topology for a protein 
with pdb2gmx with OPLS-AA and see how they're defined.



 

Further, I thought that I could simply modify the appropriate lines 
of the ffoplsaanb.itp and ffoplsaabon.itp to enter in the parameters 
found in the paper by Cornell et al. so that they will be used in my 
simulation. Am I correct in my assumption?



    



Modifying ffoplsaa files to parameters that are not OPLS-AA is 
probably a bad choice.  If you're dead-set on using these parameters, 
download the ffamber ports and use the ffamber94 force field, not some 
Frankensteined-OPLS.  Besides, all of the parameters in the Cornell 
paper are in kcal/mol/A^2, which will require conversion to Gromacs 
standard units.  If you've printed them directly in your previous 
attempts, I can guarantee you you're not getting the values you think 
you are.


-Justin


 

Thanks again for your help.

Darrell


 >Date: Fri, 17 Jul 2009 22:11:07 -0400
 >From: "Justin A. Lemkul" <jalem...@vt.edu>
 >Subject: Re: [gmx-users] Segmentation Fault (Address not mapped)
 >To: Discussion list for GROMACS users <gmx-users@gromacs.org>
 >Message-ID: <4a612f3b.7060...@vt.edu>
 >Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 >
 >
 >
 >darre...@ece.ubc.ca wrote:
 >> Hi Justin,
 >> I am using the ffoplsaabon.itp parameters for:
 >> bonds (CA-CA, CA-CT, CA-HA, CT-HC, H-N3)
 >> angles (CA-CA-CA, CA-CA-HA, CA-CT-HC, H-N3-H)
 >> dihedrals (X-CA-CA-X, X-CA-CT-X)
 >>
 >> I am using the ffolpsaanb.itp VdW parameters for H & N3
 >>
 >> And I am using the VdW parameters found in the paper "A Second

 >> Generation Force Field for the Simulation of Proteins, Nucleic 
Acids,
 >> and Organic Molecules" for CA, HA, CT, & HC doing the conversion 
from
 >> Angstroms (paper units) to nm (ffoplsaanb.itp units) for sigma 
and from
 >> kcal/mol (paper units) to kJ/mol (ffoplsaanb.itp units) for 
epsilon. The

 >> converted parameters for sigma were different by only +/-2% to +/-8%
 >> from the values in ffoplsaanb.itp, but the converted parameters for
 >> epsilon were different by +/-23% to +/-66% from the values in

 >> ffoplsaanb.itp. Is this a valid paper to use for selection of 
parameters?

 >>
 >

 >If memory serves, that paper is the derivation by Cornell, et al. 
for the
 >AMBER94 parameter set, so no, you are not going to find those same 
parameters in

 >ffoplsaanb.itp.
 >

 >Furthermore, the title of the paper indicates that the parameters 
are for

 >proteins, nucleic acids, and organic molecules. Has anyone else in the

 >literature used these parameters for graphene lattices? I would 
suggest using a
 >force field that others have used for such solid materials, like 
nanotubes or
 >other graphene surfaces. Otherwise, you will have to somehow 
demonstrate that a
 >force field designed for use with condensed phase biomolecules is 
applicable to

 >your gas-phase graphene lattice.
 >

 >> The graphene lattice is only vibrating slightly and looks like a 
bunch of

 >> travelling waves.
 >>

 >> I believe I am using proper dihedrals and not improper dihedrals 
in my

 >> model.
 >>
 >

 >It would seem. Consider if impropers might be necessary to keep 
your planar

 >groups planar. That's what they are there for.
 >

 >> Since the graphene structure will be connected to electrodes at 
both ends

 >> and will be mounted above a substrate, I assume the atoms in the

 >> structure are not completely free and thus I need to model them 
being

 >> restricted in their movement. Maybe position restraints are more
 >> appropriate than freezing to model such a situation.
 >>

 >> I do not see anything in the trajectory that provides clues as to 
what

 >> might be causing the segmentation fault.
 >>
 >
 >Then it will be very difficult to get any more remote help ;) If you

 >consistently get the crash between step 20,000 and 30,000, then 
perhaps split
 >your simulation into shorter sections, and during the time when you 
expect the
 >crash to occur, set nstxtcout = (some small value, like 1 or 10) to 
obtain the
 >most detail possible. At some point, something is going to go 
careening off

 >into infinity.
 >
 >-Justin
 >
 >> Thanks again for your help.
 >>
 >> Darrell
 >>
 >>> Date: Fri, 17 Jul 2009 19:08:38 -0400
 >>> From: "Justin A. Lemkul" <jalem...@vt.edu>
 >>> Subject: Re: [gmx-users] Segmentation Fault (Address not mapped)
 >>> To: Discussion list for GROMACS users <gmx-users@gromacs.org>
 >>> Message-ID: <4a610476.2090...@vt.edu>
 >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 >>>
 >>>
 >>>
 >>> darre...@ece.ubc.ca wrote:
 >>>> Hi Justin,

 >>>> I froze the graphene sheet because, prior to freezing it, I 
noticed that
 >>>> it was vibrating and thought that maybe its vibration was not 
allowing

 >>>> the NH3 molecules to adsorb (bond) to it. But after freezing the

 >>>> graphene sheet, I see that see that NH3 molecules are still not 
bonding
 >>>> to it. Physical experiments of NH3 and a graphene lattice 
connected to
 >>>> electrodes have shown that NH3 does adsorb to graphene, but all 
I see
 >>>> are NH3 molecules coming close to the graphene surface and then 
bouncing
 >>>> away which I am assuming is a result of repulsion between the 
negatively

 >>>> charged N atom in the ammonia molecule and the pi electrons in the

 >>>> graphene lattice. So I am not sure why experiments have shown 
adsorption
 >>>> unless adsoption is occurring as a result of a current flowing 
through
 >>>> the graphene structure or as a result of edge effects at the 
interface

 >>>> between the electrodes and the graphene lattice.
 >>>>

 >>> What parameters are you using for the species involved? Could be 
that there's

 >>> something wrong with your model.
 >>>

 >>>> Could you tell me how freezing is different that position 
restraining as

 >>>> this is not completely clear to me?
 >>>>

 >>> Freezing means positions are absolutely fixed and never updated. 
Position
 >>> restraining means there is an energy penalty to movement, but 
positions can
 >>> adjust slightly. I was thinking that if you have some strange 
interaction
 >>> happening, and freezing was preventing any reaction to the 
force, then you'd see
 >>> an explosion. I don't necessarily see why you need to apply 
either, but that
 >>> will depend on the extent of "vibration" that you see in the 
graphene sheet.
 >>> Are you applying improper dihedrals appropriately? Are the rings 
puckering, or

 >>> just vibrating slightly (which could be normal)?
 >>>

 >>>> I will try position restraining the graphene structure and see 
if that

 >>>> resolves my problem.
 >>>>

 >>>> I have been able to view a trajectory for simulations of fewer 
than

 >>>> 20,000 time steps and see the frozen graphene lattice and the NH3
 >>>> molecules floating through space.
 >>>>

 >>>> Note that the segmentation fault only occurs sometime between 
20,000 and
 >>>> 30,000 time steps. Could it be that the "funky" behaviour 
associated
 >>>> with freezing would take 20,000+ time steps to cause a 
segmentation

 >>>> fault?
 >>>>

 >>> Depends entirely upon what's causing the explosion. Any clues 
from the trajectory?

 >>>
 >>> -Justin
 >>>
 >>>> Thanks again for your help.
 >>>>
 >>>> Darrell
 >>>>
 >>>>> Date: Thu, 16 Jul 2009 16:20:04 -0400
 >>>>> From: "Justin A. Lemkul" <jalem...@vt.edu>
 >>>>> Subject: Re: [gmx-users] Segmentation Fault (Address not mapped)
 >>>>> To: Discussion list for GROMACS users <gmx-users@gromacs.org>
 >>>>> Message-ID: <4a5f8b74.6070...@vt.edu>
 >>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 >>>>>
 >>>>>
 >>>>>
 >>>>> darre...@ece.ubc.ca wrote:
 >>>>>> Hi Justin,

 >>>>>> Thanks for the explanation of the difference between EM & 
equilibration.
 >>>>>> Since in my model, I: (i) only have the graphene sheet and 
ammonia

 >>>>>> molecules spaced reasonably far apart from each other (1332 NH3

 >>>>>> molecules in a 38x38x38 box) and from the graphene sheet 
(distance
 >>>>>> between the closest ammonia molecule and the graphene sheet 
is greater
 >>>>>> than the molecular diameter of ammonia - maybe this is too 
close and
 >>>>>> could be causing my problem?); (ii) freeze the graphene 
sheet; I am
 >>>>>> thinking equilibration is not required in my model. Please 
let me know

 >>>>>> if you think I still need to perform equilibration.
 >>>>>>

 >>>>>> Yes, the EM did converge satisfactorily. Here is the output 
from EM:

 >>>>>> Steepest Descents converged to Fmax < 250 in 61 steps
 >>>>>> Potential Energy = 4.6094102e+04
 >>>>>> Maximum force = 2.4543298e+02 on atom 1
 >>>>>> Norm of force = 7.5803179e+03
 >>>>>>
 >>>>>> Is this a reasonable value for FMax?
 >>>>>>

 >>>>> Your Fmax looks fine. Why is it necessary to freeze the 
graphene sheet? Why
 >>>>> not use position restraints (to rule out funky behavior of 
being frozen)?

 >>>>>

 >>>>> Did you ever obtain a trajectory with enough frames that you 
could watch? What

 >>>>> happened?
 >>>>>
 >>>>> -Justin
 >>>>>
 >>>>>> Thanks again for your help.
 >>>>>>
 >>>>>> Darrell
 >>>>>>
 >>>>>>
 >>>>>>> Date: Thu, 16 Jul 2009 07:15:12 -0400
 >>>>>>> From: "Justin A. Lemkul" <jalem...@vt.edu>

 >>>>>>> Subject: Re: [gmx-users] Segmentation Fault (Address not 
mapped)

 >>>>>>> To: Discussion list for GROMACS users <gmx-users@gromacs.org>
 >>>>>>> Message-ID: <4a5f0bc0.4020...@vt.edu>
 >>>>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 >>>>>>>
 >>>>>>>
 >>>>>>>
 >>>>>>> darre...@ece.ubc.ca wrote:
 >>>>>>>> Hi Mark,

 >>>>>>>> I do not do any equilibration, I only do energy 
minimization as in the
 >>>>>>>> "GROMACS Tutorial for Solvation Study of Spider Toxin 
Peptide". Please
 >>>>>>>> let me know if I need to do equilibration and what is the 
difference
 >>>>>>>> between energy minimization and equilibration as this is 
not clear to me.

 >>>>>>>>
 >>>>>>> Did the EM converge satisfactorily? What was Fmax?
 >>>>>>>

 >>>>>>> Unlike EM, equilibration is an MD process; for a protein 
system, one generally
 >>>>>>> position-restrains the protein and allows the surrounding 
solvent to optimize

 >>>>>>> around the structure.
 >>>>>>>
 >>>>>>> -Justin
 >>>>>>>

 >>>>>>>> Here is an mdp file for a run that actually completed 
successfully:

 >>>>>>>> title =Graphene
 >>>>>>>> ;warnings =10
 >>>>>>>> cpp =cpp
 >>>>>>>> ;define =-DPOSRES
 >>>>>>>> constraints =none
 >>>>>>>> integrator =md
 >>>>>>>> dt =0.002 ; ps
 >>>>>>>> nsteps =10000
 >>>>>>>> nstcomm =100
 >>>>>>>> nstxout =100
 >>>>>>>> ;nstvout =1000
 >>>>>>>> nstfout =0
 >>>>>>>> nstlog =100
 >>>>>>>> nstenergy =100
 >>>>>>>> nstlist =100
 >>>>>>>> ns_type =grid
 >>>>>>>> rlist =2.0
 >>>>>>>> coulombtype =PME
 >>>>>>>> rcoulomb =2.0
 >>>>>>>> vdwtype =cut-off
 >>>>>>>> rvdw =5.0
 >>>>>>>> fourierspacing =0.12
 >>>>>>>> fourier_nx =0
 >>>>>>>> fourier_ny =0
 >>>>>>>> fourier_nz =0
 >>>>>>>> pme_order =4
 >>>>>>>> ewald_rtol =1e-5
 >>>>>>>> optimize_fft =yes
 >>>>>>>>
 >>>>>>>> ; This section freezes graphene lattice
 >>>>>>>> energygrps = Grph NH3
 >>>>>>>> energygrp_excl = Grph Grph
 >>>>>>>> freezegrps = Grph ; Freeze graphene lattice
 >>>>>>>> freezedim = Y Y Y; in all directions
 >>>>>>>>
 >>>>>>>> Tcoupl =berendsen
 >>>>>>>> tau_t =0.5 0.5
 >>>>>>>> tc-grps =NH3 Grph
 >>>>>>>> ref_t =300 300
 >>>>>>>>
 >>>>>>>> ;coupl = parrinello-rahman
 >>>>>>>> ;tau_p = 1.5
 >>>>>>>> ;compressibility = 1.3
 >>>>>>>> ;ref_p = 0.061
 >>>>>>>>
 >>>>>>>> gen_vel = yes
 >>>>>>>> gen_temp = 300.0
 >>>>>>>> gen_seed = 173529
 >>>>>>>>

 >>>>>>>> And here is a copy of an mdp file for a run that did not 
complete

 >>>>>>>> successfully:
 >>>>>>>>
 >>>>>>>> title =Graphene
 >>>>>>>> ;warnings =10
 >>>>>>>> cpp =cpp
 >>>>>>>> ;define =-DPOSRES
 >>>>>>>> constraints =none
 >>>>>>>> integrator =md
 >>>>>>>> dt =0.002 ; ps
 >>>>>>>> nsteps =30000
 >>>>>>>> nstcomm =500
 >>>>>>>> nstxout =500
 >>>>>>>> ;nstvout =1000
 >>>>>>>> nstfout =0
 >>>>>>>> nstlog =500
 >>>>>>>> nstenergy =500
 >>>>>>>> nstlist =500
 >>>>>>>> ns_type =grid
 >>>>>>>> rlist =2.0
 >>>>>>>> coulombtype =PME
 >>>>>>>> rcoulomb =2.0
 >>>>>>>> vdwtype =cut-off
 >>>>>>>> rvdw =5.0
 >>>>>>>> fourierspacing =0.12
 >>>>>>>> fourier_nx =0
 >>>>>>>> fourier_ny =0
 >>>>>>>> fourier_nz =0
 >>>>>>>> pme_order =4
 >>>>>>>> ewald_rtol =1e-5
 >>>>>>>> optimize_fft =yes
 >>>>>>>>
 >>>>>>>> ; This section freezes graphene lattice
 >>>>>>>> energygrps = Grph NH3
 >>>>>>>> energygrp_excl = Grph Grph
 >>>>>>>> freezegrps = Grph ; Freeze graphene lattice
 >>>>>>>> freezedim = Y Y Y; in all directions
 >>>>>>>>
 >>>>>>>> Tcoupl =berendsen
 >>>>>>>> tau_t =0.5 0.5
 >>>>>>>> tc-grps =NH3 Grph
 >>>>>>>> ref_t =300 300
 >>>>>>>>
 >>>>>>>> ;coupl = parrinello-rahman
 >>>>>>>> ;tau_p = 1.5
 >>>>>>>> ;compressibility = 1.3
 >>>>>>>> ;ref_p = 0.061
 >>>>>>>>
 >>>>>>>> gen_vel = yes
 >>>>>>>> gen_temp = 300.0
 >>>>>>>> gen_seed = 173529
 >>>>>>>>
 >>>>>>>> Please let me know what you think might be the problem.
 >>>>>>>>
 >>>>>>>> Thanks
 >>>>>>>>
 >>>>>>>> Darrell
 >>>>>>>>
 >>>>>>>>> Date: Thu, 16 Jul 2009 09:47:49 +1000
 >>>>>>>>> From: Mark Abraham <mark.abra...@anu.edu.au>

 >>>>>>>>> Subject: Re: [gmx-users] Segmentation Fault (Address not 
mapped)

 >>>>>>>>> To: Discussion list for GROMACS users <gmx-users@gromacs.org>
 >>>>>>>>> Message-ID: <4a5e6aa5.4040...@anu.edu.au>
 >>>>>>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 >>>>>>>>>
 >>>>>>>>> darre...@ece.ubc.ca wrote:
 >>>>>>>>>> Hi Mark,

 >>>>>>>>>> Yes, I know that the box dimensions are defined in the 
last line of the
 >>>>>>>>>> .gro file and I have defined these dimensions as 38 nm x 
38 nm x 38 nm

 >>>>>>>>>> in the .gro file.
 >>>>>>>>> OK.
 >>>>>>>>>

 >>>>>>>>>> I looked through my .gro file to ensure none of the atoms 
had coordinates
 >>>>>>>>>> outside the 38x38x38 box. While I was reviewing the file 
I did notice
 >>>>>>>>>> that some coordinates had negative values, slightly 
negative, but
 >>>>>>>>>> negative none the less. Could this be causing the 
segmentation fault
 >>>>>>>>>> between time step 10,000 and time step 30,000? Why 
wouldn't the
 >>>>>>>>>> negative coordinates cause a segmentation fault much 
earlier?

 >>>>>>>>> The absolute value of the coordinates is irrelevant.
 >>>>>>>>>

 >>>>>>>>> Your choice of 2.0 for rcoulomb is likely suboptimal for 
PME. Some
 >>>>>>>>> smaller value is probably more efficient, but this will 
not be the cause

 >>>>>>>>> of your problem.
 >>>>>>>>>

 >>>>>>>>> What is your system preparation regime? (i.e. EM + 
equilibration)

 >>>>>>>>>
 >>>>>>>>> Can you post a corrected and current .mdp file?
 >>>>>>>>>
 >>>>>>>>> Mark
 >>>>>>>>>
 >>>>>>>>>>> Date: Wed, 15 Jul 2009 16:59:21 +1000
 >>>>>>>>>>> From: Mark Abraham <mark.abra...@anu.edu.au>

 >>>>>>>>>>> Subject: Re: [gmx-users] Segmentation Fault (Address not 
mapped)
 >>>>>>>>>>> To: Discussion list for GROMACS users 
<gmx-users@gromacs.org>

 >>>>>>>>>>> Message-ID: <4a5d7e49.9020...@anu.edu.au>
 >>>>>>>>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 >>>>>>>>>>>
 >>>>>>>>>>> darre...@ece.ubc.ca wrote:
 >>>>>>>>>>>> Hi Justin,

 >>>>>>>>>>>> I was experiencing the problem before someone suggested 
using editconf so
 >>>>>>>>>>>> I do not think the problem is being caused by editconf. 
But anyway here
 >>>>>>>>>>>> is my editconf command. Let me know if you a source of 
error in this

 >>>>>>>>>>>> command line.
 >>>>>>>>>>>>
 >>>>>>>>>>>> editconf -f graphene.gro -n index.ndx -o graphene_ec.gro
 >>>>>>>>>>>>

 >>>>>>>>>>>> I did not want to add in additional space between the 
solvent and the box
 >>>>>>>>>>>> as I saw no reason for doing so. And hence that is why 
I originally did

 >>>>>>>>>>>> not use editconf.
 >>>>>>>>>>>>
 >>>>>>>>>>>> My box dimensions are 38nm x 38nm x 38nm.

 >>>>>>>>>>> The box dimensions are defined in the bottom line of the 
.gro file, and
 >>>>>>>>>>> not by the positions of the atoms in that file. If you 
haven't ever set
 >>>>>>>>>>> them to be suitable for your coordinates with editconf, 
then they might

 >>>>>>>>>>> not be.
 >>>>>>>>>>>
 >>>>>>>>>>> Mark
 >>>>>>>>>>>
 >>>>>>>>>>> I used cutoffs of 2 nm & 5 nm

 >>>>>>>>>>>> for my system so ensure the cutoff occured at a 
distance where the
 >>>>>>>>>>>> potentials were stabalized (not changing). I guess I 
could use shorter
 >>>>>>>>>>>> cutoffs such as 1.5 nm & 2 nm and this may decrease my 
computation time.
 >>>>>>>>>>>> I also thought that I needed to use larger cut-offs 
since I am dealing
 >>>>>>>>>>>> in the gas phase and there is greater ditance between 
the atoms in my

 >>>>>>>>>>>> simulation than in liquid-based simulations.
 >>>>>>>>>>>>

 >>>>>>>>>>>> In the .log files, I do not see any LINCS warnings or 
neighborlist

 >>>>>>>>>>>> errors.
 >>>>>>>>>>>>

 >>>>>>>>>>>> I ran gmxcheck on a .trr file and was presented with 
the following

 >>>>>>>>>>>> output:
 >>>>>>>>>>>> *********************************************
 >>>>>>>>>>>> Checking file mdtraj.trr
 >>>>>>>>>>>> trn version: GMX_trn_file (single precision)
 >>>>>>>>>>>> Reading frame 0 time 0.000
 >>>>>>>>>>>> # Atoms 10482
 >>>>>>>>>>>> Last frame 5 time 1.000
 >>>>>>>>>>>>
 >>>>>>>>>>>>
 >>>>>>>>>>>> Item #frames Timestep (ps)
 >>>>>>>>>>>> Step 6 0.2
 >>>>>>>>>>>> Time 6 0.2
 >>>>>>>>>>>> Lambda 6 0.2
 >>>>>>>>>>>> Coords 6 0.2
 >>>>>>>>>>>> Velocities 6 0.2
 >>>>>>>>>>>> Forces 0
 >>>>>>>>>>>> Box 6 0.2
 >>>>>>>>>>>> *********************************************
 >>>>>>>>>>>>

 >>>>>>>>>>>> I ran two additional simulations with different values 
for nsteps and

 >>>>>>>>>>>> nstxxxx paramaters and have the following to report:
 >>>>>>>>>>>>

 >>>>>>>>>>>> When I run a simulation with the following parameters 
it completes
 >>>>>>>>>>>> successfully and I see, in the log file, the system 
output every 100

 >>>>>>>>>>>> time steps.
 >>>>>>>>>>>> nsteps =10000
 >>>>>>>>>>>> nstcomm =100
 >>>>>>>>>>>> nstxout =100
 >>>>>>>>>>>> nstfout =0
 >>>>>>>>>>>> nstlog =100
 >>>>>>>>>>>> nstenergy =100
 >>>>>>>>>>>> nstlist =100
 >>>>>>>>>>>>

 >>>>>>>>>>>> When I run a simulation with the following parameters 
it fails with a
 >>>>>>>>>>>> sementation fault and, in the log file, I do not see 
system output every

 >>>>>>>>>>>> 500 time steps.
 >>>>>>>>>>>> nsteps =30000
 >>>>>>>>>>>> nstcomm =500
 >>>>>>>>>>>> nstxout =500
 >>>>>>>>>>>> nstfout =0
 >>>>>>>>>>>> nstlog =500
 >>>>>>>>>>>> nstenergy =500
 >>>>>>>>>>>> nstlist =500
 >>>>>>>>>>>>
 >>>>>>>>>>>> Please let me know what you think might be the problem.
 >>>>>>>>>>>>
 >>>>>>>>>>>> Thank you very much.
 >>>>>>>>>>>>
 >>>>>>>>>>>> Darrell
 >>>>>>>>>>>>
 >>>>>>>>>>>>
 >>>>>>>>>>>>> Date: Mon, 13 Jul 2009 15:37:15 -0400
 >>>>>>>>>>>>> From: "Justin A. Lemkul" <jalem...@vt.edu>

 >>>>>>>>>>>>> Subject: Re: [gmx-users] Segmentation Fault (Address 
not mapped)
 >>>>>>>>>>>>> To: Discussion list for GROMACS users 
<gmx-users@gromacs.org>

 >>>>>>>>>>>>> Message-ID: <4a5b8ceb.4020...@vt.edu>

 >>>>>>>>>>>>> Content-Type: text/plain; charset=ISO-8859-1; 
format=flowed

 >>>>>>>>>>>>>
 >>>>>>>>>>>>>
 >>>>>>>>>>>>>
 >>>>>>>>>>>>> darre...@ece.ubc.ca wrote:
 >>>>>>>>>>>>>> Hi Mark,

 >>>>>>>>>>>>>> I used editconf on my .gro file with zero space 
between my solvent and
 >>>>>>>>>>>>>> the box and the resulting box had the exact same 
dimension as the
 >>>>>>>>>>>>>> initial box. I also performed a number of simulation 
runs with different
 >>>>>>>>>>>>> If you're using editconf to define zero space, what's 
the point? I only ask
 >>>>>>>>>>>>> because it is a potential source of error if you think 
you're adding zero space,
 >>>>>>>>>>>>> but something else might be going on. Maybe you can 
post your editconf command

 >>>>>>>>>>>>> line.
 >>>>>>>>>>>>>

 >>>>>>>>>>>>> What are your box dimensions? Are cut-off lengths of 
2.0 and 5.0 nm appropriate
 >>>>>>>>>>>>> for your system? How did you determine that these 
cut-off's should be used?

 >>>>>>>>>>>>>

 >>>>>>>>>>>>>> mdp parameters hoping this would provide me some 
indication of the cause
 >>>>>>>>>>>>>> of the fault but to no avail. I looked through the 
log files, error
 >>>>>>>>>>>>>> files, and output files and could not find any output 
to help me

 >>>>>>>>>>>>>> identify the source of my error.
 >>>>>>>>>>>>>>

 >>>>>>>>>>>>> It is very odd that Gromacs isn't report anything at 
all. No LINCS warnings?

 >>>>>>>>>>>>> No neighborlist errors? These would be in the .log file.
 >>>>>>>>>>>>>

 >>>>>>>>>>>>>> Could you please let me know how I can look at my 
structure at each point
 >>>>>>>>>>>>>> as you indicate below as I do not see any files 
output that provide me
 >>>>>>>>>>>>>> to do so? I tried to look at the .trr file but when I 
try to load it
 >>>>>>>>>>>>>> into VMD, it causes an error. I am assuming this 
error is caused because
 >>>>>>>>>>>>>> the .trr file did not complete correctly due to the 
segmentation fault.

 >>>>>>>>>>>>>> Please advise.
 >>>>>>>>>>>>>>

 >>>>>>>>>>>>> How early is the segmentation fault occurring? I have 
found it useful sometimes
 >>>>>>>>>>>>> to set nstxout (or nstxtcout) = 1 to try to catch the 
first few frames if the
 >>>>>>>>>>>>> explosion is occurring early. In any case, gmxcheck 
will help determine how
 >>>>>>>>>>>>> many frames are present, as well as the integrity of 
the file (broken frames, etc).

 >>>>>>>>>>>>>
 >>>>>>>>>>>>> -Justin
 >>>>>>>>>>>>>
 >>>>>>>>>>>>>> Thanks.
 >>>>>>>>>>>>>>
 >>>>>>>>>>>>>> Darrell
 >>>>>>>>>>>>>>
 >>>>>>>>>>>>>>> Date: Tue, 07 Jul 2009 09:19:42 +1000
 >>>>>>>>>>>>>>> From: Mark Abraham <mark.abra...@anu.edu.au>

 >>>>>>>>>>>>>>> Subject: Re: [gmx-users] Segmentation Fault (Address 
not mapped)
 >>>>>>>>>>>>>>> To: Discussion list for GROMACS users 
<gmx-users@gromacs.org>

 >>>>>>>>>>>>>>> Message-ID: <4a52868e.6010...@anu.edu.au>

 >>>>>>>>>>>>>>> Content-Type: text/plain; charset=ISO-8859-1; 
format=flowed

 >>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>> darre...@ece.ubc.ca wrote:
 >>>>>>>>>>>>>>>> Hi Mark,

 >>>>>>>>>>>>>>>> I added the energy group exclusions as indicated in 
your previous
 >>>>>>>>>>>>>>>> response but am still experiencing the same 
problem. I looked at the
 >>>>>>>>>>>>>>>> .log files and see that in one log file it tells me 
that my box is
 >>>>>>>>>>>>>>>> exploding. However, I do not have many molecules in 
my simulation and
 >>>>>>>>>>>>>>>> therefore do not think that it is possible that my 
box is exploding from

 >>>>>>>>>>>>>>>> pressure.

 >>>>>>>>>>>>>>> Sure, but if there's something malformed with your 
model physics or
 >>>>>>>>>>>>>>> starting configuration, then large forces can make 
anything explode.

 >>>>>>>>>>>>>>>

 >>>>>>>>>>>>>>> Look at your structures at each point and see where 
things start to go
 >>>>>>>>>>>>>>> wrong. Make sure you've used editconf on your 
starting structure to

 >>>>>>>>>>>>>>> provide the right box dimensions.
 >>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>> Mark
 >>>>>>>>>>>>>>>

 >>>>>>>>>>>>>>>> Maybe if I re-state my simulation it will help you 
in providing me
 >>>>>>>>>>>>>>>> direction on what might be causing the problem. My 
simulation consists
 >>>>>>>>>>>>>>>> of a graphene lattice with a layer of ammonia 
molecules above it. The
 >>>>>>>>>>>>>>>> box is very large and there is lots of empty space 
in the box. So I am a

 >>>>>>>>>>>>>>>> little confused as to how the box could be exploding.
 >>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>> Thanks again in advance for your help.
 >>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>> Darrell Koskinen
 >>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>>> Date: Fri, 03 Jul 2009 11:41:45 +1000
 >>>>>>>>>>>>>>>>> From: Mark Abraham <mark.abra...@anu.edu.au>

 >>>>>>>>>>>>>>>>> Subject: Re: [gmx-users] Segmentation Fault 
(Address not mapped)
 >>>>>>>>>>>>>>>>> To: Discussion list for GROMACS users 
<gmx-users@gromacs.org>

 >>>>>>>>>>>>>>>>> Message-ID: <4a4d61d9.6080...@anu.edu.au>

 >>>>>>>>>>>>>>>>> Content-Type: text/plain; charset=ISO-8859-1; 
format=flowed

 >>>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>>> darre...@ece.ubc.ca wrote:
 >>>>>>>>>>>>>>>>>> Dear GROMACS Gurus,

 >>>>>>>>>>>>>>>>>> I am experiencing a segmentation fault when mdrun 
executes. My simulation
 >>>>>>>>>>>>>>>>>> has a graphene lattice with an array (layer) of 
ammonia molecules above
 >>>>>>>>>>>>>>>>>> it. The box is three times the width of the 
graphene lattice, three
 >>>>>>>>>>>>>>>>>> times the length of the graphene lattice, and 
three times the height
 >>>>>>>>>>>>>>>>>> between the graphene lattice and the ammonia 
molecules. I am including

 >>>>>>>>>>>>>>>>>> the mdp file and the error message.

 >>>>>>>>>>>>>>>>> Probably your system is exploding when integration 
fails with excessive
 >>>>>>>>>>>>>>>>> forces. You should look at the bottom of stdout, 
stderr, *and* the .log
 >>>>>>>>>>>>>>>>> file to diagnose. The error message you give below 
is merely the
 >>>>>>>>>>>>>>>>> diagnostic trace from the MPI library, and it not 
useful for finding out
 >>>>>>>>>>>>>>>>> what GROMACS thinks the problem might be. Further 
advice below.

 >>>>>>>>>>>>>>>>>

 >>>>>>>>>>>>>>>>>> 
*************************************************************************** 


 >>>>>>>>>>>>>>>>>> .mdp file
 >>>>>>>>>>>>>>>>>> title =FWS
 >>>>>>>>>>>>>>>>>> ;warnings =10
 >>>>>>>>>>>>>>>>>> cpp =cpp
 >>>>>>>>>>>>>>>>>> ;define =-DPOSRES
 >>>>>>>>>>>>>>>>>> ;constraints =all-bonds
 >>>>>>>>>>>>>>>>>> integrator =md
 >>>>>>>>>>>>>>>>>> dt =0.002 ; ps
 >>>>>>>>>>>>>>>>>> nsteps =100000
 >>>>>>>>>>>>>>>>>> nstcomm =1000
 >>>>>>>>>>>>>>>>>> nstxout =1000
 >>>>>>>>>>>>>>>>>> ;nstvout =1000
 >>>>>>>>>>>>>>>>>> nstfout =0
 >>>>>>>>>>>>>>>>>> nstlog =1000
 >>>>>>>>>>>>>>>>>> nstenergy =1000
 >>>>>>>>>>>>>>>>>> nstlist =1000
 >>>>>>>>>>>>>>>>>> ns_type =grid
 >>>>>>>>>>>>>>>>>> rlist =2.0
 >>>>>>>>>>>>>>>>>> coulombtype =PME
 >>>>>>>>>>>>>>>>>> rcoulomb =2.0
 >>>>>>>>>>>>>>>>>> vdwtype =cut-off
 >>>>>>>>>>>>>>>>>> rvdw =5.0
 >>>>>>>>>>>>>>>>>> fourierspacing =0.12
 >>>>>>>>>>>>>>>>>> fourier_nx =0
 >>>>>>>>>>>>>>>>>> fourier_ny =0
 >>>>>>>>>>>>>>>>>> fourier_nz =0
 >>>>>>>>>>>>>>>>>> pme_order =4
 >>>>>>>>>>>>>>>>>> ewald_rtol =1e-5
 >>>>>>>>>>>>>>>>>> optimize_fft =yes
 >>>>>>>>>>>>>>>>>>

 >>>>>>>>>>>>>>>>>> ; This section added in to freeze hydrogen atoms 
at edge of graphene

 >>>>>>>>>>>>>>>>>> lattice to prevent movement of lattice
 >>>>>>>>>>>>>>>>>> ;energygrp_excl = Edge Edge Edge Grph Grph Grph

 >>>>>>>>>>>>>>>>>> freezegrps = Edge Grph ; Hydrogen atoms in 
graphene lattice are

 >>>>>>>>>>>>>>>>>> associated with the residue Edge

 >>>>>>>>>>>>>>>>> See comments in 7.3.24 of manual. You need the 
energy group exclusions.

 >>>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>>> Mark
 >>>>>>>>>>>>>>>>>

 >>>>>>>>>>>>>>>>>> freezedim = Y Y Y Y Y Y; Freeze hydrogen atoms in 
all directions

 >>>>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>>>> ;Tcoupl =berendsen
 >>>>>>>>>>>>>>>>>> ;tau_t =0.1 0.1
 >>>>>>>>>>>>>>>>>> ;tc-grps =protein non-protein
 >>>>>>>>>>>>>>>>>> ;ref_t = 300 300
 >>>>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>>>> ;Pcoupl = parrinello-rahman
 >>>>>>>>>>>>>>>>>> ;tau_p = 0.5
 >>>>>>>>>>>>>>>>>> ;compressibility = 4.5e-5
 >>>>>>>>>>>>>>>>>> ;ref_p = 1.0
 >>>>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>>>> ;gen_vel = yes
 >>>>>>>>>>>>>>>>>> ;gen_temp = 300.0
 >>>>>>>>>>>>>>>>>> ;gen_seed = 173529

 >>>>>>>>>>>>>>>>>> 
*************************************************************************** 


 >>>>>>>>>>>>>>>>>>

 >>>>>>>>>>>>>>>>>> 
*************************************************************************** 


 >>>>>>>>>>>>>>>>>> ERROR IN OUTPUT FILE
 >>>>>>>>>>>>>>>>>> [node16:25758] *** Process received signal ***
 >>>>>>>>>>>>>>>>>> [node16:25758] Signal: Segmentation fault (11)
 >>>>>>>>>>>>>>>>>> [node16:25758] Signal code: Address not mapped (1)

 >>>>>>>>>>>>>>>>>> [node16:25758] Failing at address: 
0xfffffffe1233e230
 >>>>>>>>>>>>>>>>>> [node16:25758] [ 0] /lib64/libpthread.so.0 
[0x3834a0de80]
 >>>>>>>>>>>>>>>>>> [node16:25758] [ 1] 
/usr/lib64/libmd_mpi.so.4(pme_calc_pidx+0xd6)

 >>>>>>>>>>>>>>>>>> [0x2ba295dd0606]

 >>>>>>>>>>>>>>>>>> [node16:25758] [ 2] 
/usr/lib64/libmd_mpi.so.4(do_pme+0x808)

 >>>>>>>>>>>>>>>>>> [0x2ba295dd4058]

 >>>>>>>>>>>>>>>>>> [node16:25758] [ 3] 
/usr/lib64/libmd_mpi.so.4(force+0x8de)

 >>>>>>>>>>>>>>>>>> [0x2ba295dba5be]

 >>>>>>>>>>>>>>>>>> [node16:25758] [ 4] 
/usr/lib64/libmd_mpi.so.4(do_force+0x5ef)

 >>>>>>>>>>>>>>>>>> [0x2ba295ddeaff]

 >>>>>>>>>>>>>>>>>> [node16:25758] [ 5] mdrun_mpi(do_md+0xe23) 
[0x411193]
 >>>>>>>>>>>>>>>>>> [node16:25758] [ 6] mdrun_mpi(mdrunner+0xd40) 
[0x4142f0]

 >>>>>>>>>>>>>>>>>> [node16:25758] [ 7] mdrun_mpi(main+0x239) [0x4146f9]

 >>>>>>>>>>>>>>>>>> [node16:25758] [ 8] 
/lib64/libc.so.6(__libc_start_main+0xf4)

 >>>>>>>>>>>>>>>>>> [0x3833e1d8b4]
 >>>>>>>>>>>>>>>>>> [node16:25758] [ 9] mdrun_mpi [0x40429a]
 >>>>>>>>>>>>>>>>>> [node16:25758] *** End of error message ***

 >>>>>>>>>>>>>>>>>> mpirun noticed that job rank 7 with PID 25758 on 
node node16 exited on

 >>>>>>>>>>>>>>>>>> signal 11 (Segmentation fault).
 >>>>>>>>>>>>>>>>>> 7 processes killed (possibly by Open MPI)

 >>>>>>>>>>>>>>>>>> 
*************************************************************************** 


 >>>>>>>>>>>>>>>>>>

 >>>>>>>>>>>>>>>>>> Could you please let me know what you think may 
be causing the fault?

 >>>>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>>>> Much thanks in advance.
 >>>>>>>>>>>>>>>>>>
 >>>>>>>>>>>>>>>>>> Darrell Koskinen
 >>>>>>>>>>>>>> _______________________________________________
 >>>>>>>>>>>>>> gmx-users mailing list gmx-users@gromacs.org
 >>>>>>>>>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >>>>>>>>>>>>>> Please search the archive at 
http://www.gromacs.org/search before posting!
 >>>>>>>>>>>>>> Please don't post (un)subscribe requests to the list. 
Use the
 >>>>>>>>>>>>>> www interface or send it to 
gmx-users-requ...@gromacs.org.
 >>>>>>>>>>>>>> Can't post? Read 
http://www.gromacs.org/mailing_lists/users.php

 >>>>>>>>>>>>>>
 >>>>>>>>>>>>> --
 >>>>>>>>>>>>> ========================================
 >>>>>>>>>>>>>
 >>>>>>>>>>>>> Justin A. Lemkul
 >>>>>>>>>>>>> Ph.D. Candidate
 >>>>>>>>>>>>> ICTAS Doctoral Scholar
 >>>>>>>>>>>>> Department of Biochemistry
 >>>>>>>>>>>>> Virginia Tech
 >>>>>>>>>>>>> Blacksburg, VA
 >>>>>>>>>>>>> jalemkul[at]vt.edu | (540) 231-9080
 >>>>>>>>>>>>> http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
 >>>>>>>>>>>>>
 >>>>>>>>>>>>> ========================================
 >>>>>>>>>>>> _______________________________________________
 >>>>>>>>>>>> gmx-users mailing list gmx-users@gromacs.org
 >>>>>>>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >>>>>>>>>>>> Please search the archive at 
http://www.gromacs.org/search before posting!
 >>>>>>>>>>>> Please don't post (un)subscribe requests to the list. 
Use the

 >>>>>>>>>>>> www interface or send it to gmx-users-requ...@gromacs.org.

 >>>>>>>>>>>> Can't post? Read 
http://www.gromacs.org/mailing_lists/users.php

 >>>>>>>>>>>>
 >>>>>>>>>>> ------------------------------
 >>>>>>>>>>>
 >>>>>>>>>>> _______________________________________________
 >>>>>>>>>>> gmx-users mailing list
 >>>>>>>>>>> gmx-users@gromacs.org
 >>>>>>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >>>>>>>>>>> Please search the archive at 
http://www.gromacs.org/search before posting!

 >>>>>>>>>>>
 >>>>>>>>>>> End of gmx-users Digest, Vol 63, Issue 61
 >>>>>>>>>>> *****************************************
 >>>>>>>>>>>
 >>>>>>>>>> _______________________________________________
 >>>>>>>>>> gmx-users mailing list gmx-users@gromacs.org
 >>>>>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >>>>>>>>>> Please search the archive at 
http://www.gromacs.org/search before posting!
 >>>>>>>>>> Please don't post (un)subscribe requests to the list. Use 
the

 >>>>>>>>>> www interface or send it to gmx-users-requ...@gromacs.org.

 >>>>>>>>>> Can't post? Read 
http://www.gromacs.org/mailing_lists/users.php

 >>>>>>>>>>
 >>>>>>>> _______________________________________________
 >>>>>>>> gmx-users mailing list gmx-users@gromacs.org
 >>>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >>>>>>>> Please search the archive at http://www.gromacs.org/search 
before posting!

 >>>>>>>> Please don't post (un)subscribe requests to the list. Use the
 >>>>>>>> www interface or send it to gmx-users-requ...@gromacs.org.

 >>>>>>>> Can't post? Read 
http://www.gromacs.org/mailing_lists/users.php

 >>>>>>>>
 >>>>>>> --
 >>>>>>> ========================================
 >>>>>>>
 >>>>>>> Justin A. Lemkul
 >>>>>>> Ph.D. Candidate
 >>>>>>> ICTAS Doctoral Scholar
 >>>>>>> Department of Biochemistry
 >>>>>>> Virginia Tech
 >>>>>>> Blacksburg, VA
 >>>>>>> jalemkul[at]vt.edu | (540) 231-9080
 >>>>>>> http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
 >>>>>>>
 >>>>>>> ========================================
 >>>>>>>
 >>>>>>>
 >>>>>>> ------------------------------
 >>>>>>>
 >>>>>>> _______________________________________________
 >>>>>>> gmx-users mailing list
 >>>>>>> gmx-users@gromacs.org
 >>>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >>>>>>> Please search the archive at http://www.gromacs.org/search 
before posting!

 >>>>>>>
 >>>>>>> End of gmx-users Digest, Vol 63, Issue 74
 >>>>>>> *****************************************
 >>>>>>>
 >>>>>> _______________________________________________
 >>>>>> gmx-users mailing list gmx-users@gromacs.org
 >>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >>>>>> Please search the archive at http://www.gromacs.org/search 
before posting!

 >>>>>> Please don't post (un)subscribe requests to the list. Use the
 >>>>>> www interface or send it to gmx-users-requ...@gromacs.org.
 >>>>>> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
 >>>>>>
 >>>>> --
 >>>>> ========================================
 >>>>>
 >>>>> Justin A. Lemkul
 >>>>> Ph.D. Candidate
 >>>>> ICTAS Doctoral Scholar
 >>>>> Department of Biochemistry
 >>>>> Virginia Tech
 >>>>> Blacksburg, VA
 >>>>> jalemkul[at]vt.edu | (540) 231-9080
 >>>>> http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
 >>>>>
 >>>>> ========================================
 >>>>>
 >>>>>
 >>>>> ------------------------------
 >>>>>
 >>>>> _______________________________________________
 >>>>> gmx-users mailing list
 >>>>> gmx-users@gromacs.org
 >>>>> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >>>>> Please search the archive at http://www.gromacs.org/search 
before posting!

 >>>>>
 >>>>> End of gmx-users Digest, Vol 63, Issue 79
 >>>>> *****************************************
 >>>>>
 >>>> _______________________________________________
 >>>> gmx-users mailing list gmx-users@gromacs.org
 >>>> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >>>> Please search the archive at http://www.gromacs.org/search 
before posting!

 >>>> Please don't post (un)subscribe requests to the list. Use the
 >>>> www interface or send it to gmx-users-requ...@gromacs.org.
 >>>> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
 >>>>
 >>> --
 >>> ========================================
 >>>
 >>> Justin A. Lemkul
 >>> Ph.D. Candidate
 >>> ICTAS Doctoral Scholar
 >>> Department of Biochemistry
 >>> Virginia Tech
 >>> Blacksburg, VA
 >>> jalemkul[at]vt.edu | (540) 231-9080
 >>> http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
 >>>
 >>> ========================================
 >>>
 >>>
 >>> ------------------------------
 >>>
 >>> _______________________________________________
 >>> gmx-users mailing list
 >>> gmx-users@gromacs.org
 >>> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >>> Please search the archive at http://www.gromacs.org/search 
before posting!

 >>>
 >>> End of gmx-users Digest, Vol 63, Issue 85
 >>> *****************************************
 >>>
 >> _______________________________________________
 >> gmx-users mailing list gmx-users@gromacs.org
 >> http://lists.gromacs.org/mailman/listinfo/gmx-users

 >> Please search the archive at http://www.gromacs.org/search before 
posting!

 >> Please don't post (un)subscribe requests to the list. Use the
 >> www interface or send it to gmx-users-requ...@gromacs.org.
 >> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
 >>
 >
 >--
 >========================================
 >
 >Justin A. Lemkul
 >Ph.D. Candidate
 >ICTAS Doctoral Scholar
 >Department of Biochemistry
 >Virginia Tech
 >Blacksburg, VA
 >jalemkul[at]vt.edu | (540) 231-9080
 >http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
_______________________________________________
gmx-users mailing list    gmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users

Please search the archive at http://www.gromacs.org/search before 
posting!
Please don't post (un)subscribe requests to the list. Use the www 
interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/mailing_lists/users.php


    



  

_______________________________________________
gmx-users mailing list    gmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!

Please don't post (un)subscribe requests to the list. Use the www 
interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/mailing_lists/users.php


_______________________________________________
gmx-users mailing list    gmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php























					Reply via email to