[MMTK] Update Re: NetCDF convention

Jay Billings jayjaybillings at gmail.com
Fri Sep 5 14:45:45 UTC 2008


Thanks for your response! I'll give this a try and see how it goes.

In reference to the Scientific thing, it was as simple as copying the files
over and I only mention it in case someone else needs it. RedHat-based
systems split the libraries into /usr/lib and /usr/lib64. It's a bit
ridiculous because it even splits the python2.5 install in half! I have
found that this can cause a whole suite of problems when compiling things
from source instead of installing by rpm. However, since numpy.test() works
and all of the tests in Scientific and MMTK worked, I assume the install is


On Fri, Sep 5, 2008 at 10:31 AM, Konrad Hinsen <hinsen at cnrs-orleans.fr>wrote:

> On Sep 4, 2008, at 21:57, Jay Billings wrote:
>  There's a bit of a problem with the output though. I tried opening "
>> rotation.nc" in nMoldyn and received an error that "This trajectory does
>> not include time information" and "This is most probably not a trajectory
>> file".
> That trajectory does indeed have no time information. Since it is not the
> result of any dynamics, this is quite appropriate. nMOLDYN calculates
> dynamical correlation functions and thus requires time-dependent input data.
> However, it should better produce only the first error message, not the
> second one. It is perfectly fine to have trajectories without time stamps of
> course.
>  universe.time = 0
>> ....
>> for i in range(20):
>>     ....
>>     universe.time = i
> Try this:
> for i in range(20):
>        ...
>        snapshot(data = {'time': 10.*i})
> An example you can look at for inspiration is the DCD-to-netCDF converter
> that comes with nMOLDYN. It writes trajectories with time stamps.
>  On a happier note, I can report that MMTK-2.5.23 and nMoldyn-2.2.5 work on
>> x86_64 Fedora 9 with numpy. I couldn't get ScientificPython to work with
>> Numeric and I had to copy the numpy include files to /usr/include/numpy, but
>> other than that, everything works fine and all tests were successful. :)
> Numeric is known to have problems on 64-bit machines, so your choice of
> NumPy is the right one. If ScientificPython did not find the NumPy header
> files, there is probably something wrong with the Python or NumPy
> installation in that machine. ScientificPython looks for the header files in
> the directory defined by
> os.path.join(sys.prefix, "lib/python%s.%s/site-packages/numpy/core/include"
> % sys.version_info [:2])
> This is the recommended strategy for NumPy-dependend modules. It is
> possible that your NumPy is somewhere else if Fedora modified the directory
> setup for Python, as some Linux distributions unfortunately do. In that
> case, there isn't much that I can do about it.
> 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
> Web: http://dirac.cnrs-orleans.fr/~hinsen/<http://dirac.cnrs-orleans.fr/%7Ehinsen/>
> ---------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://starship.python.net/pipermail/mmtk/attachments/20080905/27b0e4b1/attachment.htm>

More information about the mmtk mailing list