[MMTK] pMoldyn scripting problems

ALEJANDRO MAXIMILIAN SUAREZ ams751 at psu.edu
Fri Aug 18 00:49:14 CEST 2006


Thank you for the quick insight regarding the default units for the nMoldyn
calculations. However, in my testing I found some very strange behavior with
rerunning incoherent scattering function generation for the same trajectory
multiple times. 

The first inconsistency I found actually involved similarity between my results.
I tried generating incoherent scattering spectra for a single trajectory twice:
once setting the q_units variable to be inverse Angstroms, and once for inverse
nanometers. I assumed it would merely scale the graph accordingly, however it
gave me almost identical results. This leads me to believe that either i'm
mistaken in the naming standard for the units module (I used Units.Ang and
Units.nm) or that q_units is not being parsed by the input file reader. Looking
through misc.py I wasn't able to find any reference to q_units and i'm not sure
where else it may reside. The strangest thing I found came later, though, when
I started looking closer at the individual values within the scattering
functions.

Here is a sample of the dsf array within the ISF_SPECT nc file (viewed using
ncdump) run 4 different times using the same input trajectory 
run 1:
dsf =
  0.0511211562359633, 0.0486652853999429, 0.0419837438399086, 
    0.0328251317217751, 0.0232614240903453, 0.0149433680260456, 
    0.00870549118511677, 0.00460232931529301, 0.00221148637017216, 
    0.000969608575987971, 0.000392057095797885, 0.000150932702618646, 
    6.06651857767353e-05, 3.08340324613577e-05, 2.28042719791237e-05, 
    2.18393507785073e-05, 2.27795082948315e-05, 2.3881139502136e-05, 
    2.45430771270616e-05, 2.45693884764705e-05, 2.39434208058076e-05, 
.....

run 2:
 dsf =
  0.0511102627287317, 0.0486552674041973, 0.0419760411377893, 
    0.0328204281804472, 0.0232595996697107, 0.0149437844717377, 
    0.0087073673703633, 0.00460499667565476, 0.00221447160999604, 
    0.000972609728146944, 0.000394893590731331, 0.000153505376824944, 
    6.29263403358671e-05, 3.27633079937934e-05, 2.43945890814717e-05, 
    2.30974365674436e-05, 2.37359122495266e-05, 2.45965540206332e-05, 
    2.51001149816233e-05, 2.50502715202397e-05, 2.44053704203698e-05, 
......

run 3:
 dsf =
  0.0511211562359633, 0.0486652853999429, 0.0419837438399086, 
    0.0328251317217751, 0.0232614240903453, 0.0149433680260456, 
    0.00870549118511677, 0.00460232931529301, 0.00221148637017216, 
    0.000969608575987972, 0.000392057095797885, 0.000150932702618646, 
    6.06651857767351e-05, 3.08340324613577e-05, 2.28042719791236e-05, 
    2.18393507785077e-05, 2.27795082948311e-05, 2.3881139502136e-05, 
    2.45430771270628e-05, 2.45693884764711e-05, 2.39434208058082e-05, 
.......

run 4:
 dsf =
  0.0511102627287317, 0.0486552674041973, 0.0419760411377893, 
    0.0328204281804472, 0.0232595996697107, 0.0149437844717377, 
    0.0087073673703633, 0.00460499667565476, 0.00221447160999604, 
    0.000972609728146945, 0.000394893590731331, 0.000153505376824944, 
    6.2926340335867e-05, 3.27633079937933e-05, 2.43945890814712e-05, 
    2.30974365674443e-05, 2.37359122495272e-05, 2.45965540206339e-05, 
    2.51001149816222e-05, 2.50502715202409e-05, 2.44053704203708e-05,

Other than some extraneous errors in the last couple digits, there seems to be a
rather enormous run dependant error which seems to follow some form of pattern.
I'm completely at a loss as to why runs 1 & 3 are so different from 2 & 4 yet
so similar to eachother. Timewise, I ran runs 1 & 2 independently at separate
times, while runs 3 & 4 were run simultaneously. I was beginning to think that
this may just be an error in how I was constructing my trajectory, so I decided
to experiment with some example code. 

I took the test simulation for argon from MolecularDynamics/argon.py within the
MMTK example codes to get a "control" trajectory to run some more tests on. I
generated the ISF spectrum for this trajectory 4 times however I used coherent
weights instead of incoherent due to the exception:

Traceback (most recent call last):
  File "/usr/bin/pMoldyn", line 39, in ?
    data = inputFileRead(input)
  File "/usr/lib/python2.4/site-packages/nMoldyn/misc.py", line 231, in
inputFileRead
    weightsList = BincohList(traj.universe, input.atoms)
  File "/usr/lib/python2.4/site-packages/nMoldyn/misc.py", line 30, in
BincohList
    return bincoh/bincoh.sumOverParticles()
  File "/usr/lib/python2.4/site-packages/MMTK/ParticleProperties.py", line 111,
in __div__
    return self._arithmetic(other, Numeric.divide, 1)
  File "/usr/lib/python2.4/site-packages/MMTK/ParticleProperties.py", line 92,
in _arithmetic
    return return_class(self.universe, op(a1, a2))
OverflowError: math range error

which seems to have to do with the incoherent scattering length for Ar within
the database, but I didn't want to deal with looking into this at the time)

A quick skim over the data showed that these were much closer together, however
I found a startling difference once I reached the second Q value:
(following data is for the second Q value in the system)
run1:
  127.135117093488, 121.839545590859, 107.300583652982, 86.9959595442594, 
  65.1627529863602, 45.3633731511734, 29.6411783776838, 18.4666271886917, 
  11.231778215714, 6.88443085463697, 4.401510625763, 3.01013925288102, 
  2.21503508844328, 1.7344549521823, 1.42084124534149, 1.20017167936291, 
  1.03519826931949, 0.906270504326271, 0.802267348530896, 
  0.716472946577483, 0.644611399135158, 0.583793439837614,  
......

run2:
 126.851761065779, 121.57708714719, 107.094466323894, 86.865461397554, 
 65.1081049113367, 45.3699293597302, 29.6873864337722, 18.5316589495013, 
 11.3001569062799, 6.9472420265208, 4.45530840045578, 3.0549838897402, 
 2.25265394843172, 1.7669410913476, 1.44993152643913, 1.22698852431976, 
 1.06028939502272, 0.929779290612181, 0.824107423183125, 
 0.736452454017902, 0.662515644944618, 0.599454528262245, 
......

run3:
  127.060076967295, 121.768269270312, 107.23975416833, 86.9499956637677, 
  65.1331055348381, 45.3487194153, 29.6383417004451, 18.4717792040864, 
  11.2414550782022, 6.89610094592067, 4.41369498539373, 3.02223841070136, 
  2.22702734188087, 1.74657957848985, 1.43333630829283, 1.21310870279863, 
  1.04842619081193, 0.919447997289548, 0.814943196107408, 
  0.728177948997832, 0.654941902270778, 0.592478845408457, 
......

run4:
  127.210555496728, 121.905812719269, 107.342814292469, 87.0078559984181, 
  65.147370670383, 45.3299449478884, 29.6004138812759, 18.427042892071, 
  11.1982372976655, 6.85856465565667, 4.38299206995048, 2.99790187672186, 
  2.20800657259908, 1.73179130808232, 1.42185712650712, 1.20418690381054, 
  1.04144076792064, 0.913874471335044, 0.810340306949464, 
  0.724190477130516, 0.65131033488295, 0.589045404084245, 0.53555673141089, 
......



 
So i'm stumped... Granted, i'm just now only beginning to study neutron
scattering theory and am pretty rusty at how fourier transform algorithms can
be implemented, but how am I getting such wild random error fluctuations for
these runs? Any help on the matter would  be greatly appreciated.

Thank you,




On Thu, 17 Aug 2006 15:50:42 +0200, Konrad Hinsen wrote:

> On Aug 16, 2006, at 17:20, ALEJANDRO MAXIMILIAN SUAREZ wrote:
> 
> > I'm not sure if this is the correct mailing list for a problem like  
> > this,
> > however it seems some of your have worked on both codes. Please  
> > disgregard this
> > if it is not a relevent topic.
> 
> This list is as good a place as any for such questions...
> 
> > However, I am running into a few problems finding documentation on  
> > constructing
> > pMoldyn scripts. I am having trouble in extracting units from the  
> > nc files that
> > are produced (ncdump shows no units for frequency or Q). Looking  
> > through the
> 
> After a quick check of nMOLDYN-generated files on my disk, it seems  
> that nMOLDYN does not create unit attributes for its output files.
> 
> > nMoldyn source I haven't been able to find the "units_q" variable  
> > that is set
> > within the xMoldyn GUI when preparing a simulation. I haven't been  
> > able to sift
> > through it all too well as I am relatively new at Python, but I  
> > also am at a
> > loss as to why the frequency units are not being set as well.
> 
> There are units_length and units_frequency as well.
> 
> > I have been using the default input file generated by xMoldyn as a  
> > stepping stone to figuring out these problems, but can not find any  
> > other documentation on how to construct these input files other  
> > than some small examples.
> 
> There isn't much documentation yet, unfortunately. It is being worked  
> on, but won't be ready very soon.
> 
> > My second issue arises from filtering the data so I see the  
> > contribution of only
> > certain specific atoms to the spectra, however I feel it more  
> > pertinent to get
> > accurate scale on my data before specifying more complicated  
> > specifications.
> 
> Unless you explicitly specify different units, the default units are:
> 
> - nm for lengths
> - 1/nm for wave vectors
> - 1/ps for frequencies
> 
> These are in fact the default units of MMTK.
> 
> As for atom selections, there are three approaches:
> 
> 1) Use the atom selection dialog in xMoldyn. This is the easiest  
> solution, but it is limited to the predefined selections.
> 
> 2) Write a Python function that returns the selected atoms as an MMTK  
> object (usually a collection). The function must be called  
> atoms_code, and the line starting with "atoms=" must be removed from  
> the input file. I should have an example for this somewhere, but I  
> cannot access my compute machines at the moment...
> 
> 3) Mark the atoms to be selected in a hand-edited PDB file. I just  
> know that this option exists, but I don't know how it works precisely.
> 
> Konrad.
> --
> ---------------------------------------------------------------------
> Konrad Hinsen
> Centre de Biophysique Moléculaire, CNRS Orléans
> Synchrotron Soleil - Division Expériences
> Saint Aubin - BP 48
> 91192 Gif sur Yvette Cedex, France
> Tel. +33-1 69 35 97 15
> E-Mail: hinsen at cnrs-orleans.fr
> ---------------------------------------------------------------------
> 
> 
> 
> 
> 




More information about the mmtk mailing list