From: Peter Freddolino (petefred_at_ks.uiuc.edu)
Date: Thu Nov 15 2007 - 09:46:47 CST
Hi Vlad,
no worries; glad to hear that things are working now.
Peter
Vlad Cojocaru wrote:
> Hi Peter,
>
> I think I need to applogise about this .... I really hope you didnt
> spend too much time on it .... In my scripts I assigned by mistake the
> same name to the velocity .dcd file and the coordinates .dcd file
> ..Therefore, the .dcd file contains velocities while the .dcd.bak
> contains coordinates ....
>
> I was running many different simulations, I built a script which was
> changing parameters and producing different trajectories and since I
> always got a trajectory (.dcd.bak) I concentrated on the results .. I
> didnt check anymore that part of the script assigning output file
> names ... ...
>
> I am sorry for taking your time on this .....
>
> Well, actually its very nice that NAMD still produced this .dcd.bak
> file .... Otherwise I wouldnt have had the trajectories .... (on the
> other hand I would have noticed the mistake earlier ;-) )
>
> Sorry ....
>
> Best
> vlad
>
>
>
> Peter Freddolino wrote:
>> Hi Vlad,
>> could you try using catdcd on one of the corrupted dcds to see whether
>> the whole file is corrupted or just the last frame? It should throw an
>> error if you're reading bad sections of the file, so by specifying -last
>> to be one before the end you can see where problems occurred. I haven't
>> been able to reproduce this on my setup, though... has anyone else on
>> the list seen anything like this?
>>
>> Peter
>>
>> Vlad Cojocaru wrote:
>>
>>> Dear Peter,
>>>
>>> I am running on our internal x86_64 Linux cluster (2*Dual Core AMD
>>> opteron 2218, 4 procs per node, each proc 2600 Mhz), on 4 (1 node) or
>>> 8 procs (2 nodes).
>>> The NAMD version is: NAMD_2.6_Linux-amd64-TCP
>>>
>>> There is absolutely no error message (maybe next run I could run it
>>> with strace and see if I can find out more) ... The job looks as if it
>>> finished normally ... All output is complete (well except for the dcd
>>> file) ....
>>>
>>> The problem appears either with SMD or TclForces enabled and it is
>>> independent on whether the job runs on 1 node or on 2 different nodes
>>> . The problem doesnt appear neither with standard simulations, nor
>>> with ABF simulations.
>>>
>>> It is not a dramatic issue since the .bak file is OK but I was just
>>> wondering whether anybody else noticed such a problem ...
>>>
>>> Cheers
>>> vlad
>>>
>>> Peter Freddolino wrote:
>>>
>>>
>>>> Hi Vlad,
>>>> I certainly have not noticed this behavior in any of the SMD
>>>> trajectories that I've run recently. Could you give a little more
>>>> information on where you're running? Also, could you check whether your
>>>> jobs are ending in the middle of a write to the dcd? The dcd.bak file
>>>> should just contain the same information as the dcd from the previous
>>>> timestep...
>>>>
>>>> Best,
>>>> Peter
>>>>
>>>> Vlad Cojocaru wrote:
>>>>
>>>>
>>>>
>>>>> Dear NAMD community,
>>>>>
>>>>> I noticed that the DCD trajectories produced by SMD simulation in NAMD
>>>>> 2.6 are corrupted (they cannot be loaded properly in VMD 1.8.6).
>>>>> Luckily, NAMD creates also a DCD.BAK backup which can be properly
>>>>> visualized. This problem is independednt of the trajectory size.
>>>>>
>>>>> Is there a fix for this problem ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Best wishes
>>>>> vlad
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
> --
> ----------------------------------------------------------------------------
> Dr. Vlad Cojocaru
>
> EML Research gGmbH
> Schloss-Wolfsbrunnenweg 33
> 69118 Heidelberg
>
> Tel: ++49-6221-533266
> Fax: ++49-6221-533298
>
> e-mail:Vlad.Cojocaru[at]eml-r.villa-bosch.de
>
> http://projects.villa-bosch.de/mcm/people/cojocaru/
>
> ----------------------------------------------------------------------------
> EML Research gGmbH
> Amtgericht Mannheim / HRB 337446
> Managing Partner: Dr. h.c. Klaus Tschira
> Scientific and Managing Director: Prof. Dr.-Ing. Andreas Reuter
> http://www.eml-r.org
> ----------------------------------------------------------------------------
>
>
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:45:32 CST