VMD-L Mailing List
From: Alexander Balaeff (abalaeff_at_gmail.com)
Date: Fri Jan 27 2017 - 12:59:17 CST
- Next message: Alexander Balaeff: "Re: Running out of memory due to multiple mol addfile's (?)"
- Previous message: Vlad Cojocaru: "reading rst7 files generated by cpptraj"
- In reply to: Ashar Malik: "Re: Running out of memory due to multiple mol addfile's (?)"
- Next in thread: Alexander Balaeff: "Re: Running out of memory due to multiple mol addfile's (?)"
- Reply: Alexander Balaeff: "Re: Running out of memory due to multiple mol addfile's (?)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Ashar:
Thanks for your comments. Yes, I have taken the basic precautions :)
1) Solvent deleted (and yet trajectory is long and not loadable in its
entirety); 2) No, I am not creating atomselects within my loops; only
12 selections at the beginning which I keep using throughout the
script; 3) yes, I am exactly loading the trajectory by smaller pieces
= 1 frame at a time (more precisely, two frames: one into each created
molecule).
Yet, the end result is an apparent memory leak and crash.
Again, I am aware of the solution of breaking the trajectory into,
say, 10 pieces each of which would be readable all at once. Which will
create 10x10 = 100 pieces of my RMSD map which will then need to be
stitched together... doable, again. But I wanted to avoid all that
hassle by simply keeping 1 frame of a trajectory in memory at a time.
Which appears to result in a memory leak. Must have something to do
with how VMD TcL engine deals with multiple reading from the files.
Specifically: does 'mol addfile' *open the file anew and creating a
new file TcL handle every time it is called* or keeps referring to the
same handle once created? The former behavior would certainly result
in the memory crash observed. If that is the case, would 'animate
read' behave differently? If VMD gurus on the list could clarify these
questions that would be very instructive and much appreciated :)
Thanks a ton,
Alexander.
=====================================================
Prof. Alexander Balaeff
University of Central Florida
NanoScience Technology Center
12424 Research Parkway, Suite 400
Orlando, FL 32826
Phone: (407) 823-4576
FAX: (407) 882-2819
E-mail: abalaeff_at_gmail.com
On Fri, Jan 27, 2017 at 3:01 AM, Ashar Malik <asharjm_at_gmail.com> wrote:
> Hi Alexander,
>
> I am not sure about the two lines of code you are using as in their
> objective.
>
> From the post script what I get is that you couldn't load the entire
> trajectory in one go because of memory issues.
> A workaround to do that is to load lesser frames from your trajectory -- or
> maybe think about deleting the solvent. If you don't load the solvent, you
> trajectory should become manageble (unless its not tooooo long). Another
> workaround is to load specific frames. e.g. if you trajectory has 100 frames
> you can load every 3rd frame and end up with say 33 frames equally spaced
> along the length of the trajectory. Usually consecutive frames are too
> related anyway to infer useful information (my take). Loading frames with a
> little gap can give you a workaround.
>
> If stripping the trajectory of waters works for you (assuming you system has
> waters - or anything unnecessary) and your trajectory remains big - you can
> then load frames at intervals.
>
> to jump frames -- use
>
> first ?? step ?? last ?? waitfor all 0
>
> to strip the trajectory of something -- use catdcd available here :
> http://www.ks.uiuc.edu/Development/MDTools/catdcd/
>
> Looking at your code again -
>
> I wonder if you are making selections ... if you make selections in VMD
> using atomselect - are you deleting those selections?
> VMD/TCL has this thing where a selection keeps occupying the memory and
> doesn't release it.
>
> to do this if you make a selection like
>
> set sel [atomselect top all]
> --- do something with selection "sel" ---
> $sel delete
>
> by using delete - you should be able to free the space. (just throwing this
> in there if this is the issue).
>
> Hope one of these works for you. If it doesn't write back.
>
> Best,
> /A
>
>
>
>
> On Fri, Jan 27, 2017 at 11:03 AM, Alexander Balaeff <abalaeff_at_gmail.com>
> wrote:
>>
>> Dear VMD community:
>>
>> Could anyone possibly suggest a workaround of VMD running out of
>> memory due to (suspected) multiple file opening? In the attached
>> script, I am repeatedly reading frames from a DCD file(*) using mol
>> addfile; basically, with this sequence repeated in two nested loops:
>>
>> animate delete all 0
>> mol addfile $dcd_file(0) first $i last $i waitfor all 0
>>
>> End result: VMD (LINUXAMD64 version 1.9.2beta1) runs out of memory. I
>> see nothing else in the script that could cause it and suspect the
>> issue is VMD running afoul of the TcL file handling: opening the same
>> file multiple times, growing some intrinsic buffers for file reading,
>> etc., etc.
>>
>> Has anyone encountered similar issues? Would using animate read
>> instead of mol addfile work better? Any suggestion would be greatly
>> appreciated.
>>
>> Best,
>>
>> Alexander.
>>
>> (*) The reason I am doing so is that the whole DCD file wouldn't fit
>> to the memory and I want to avoid reading it by pieces and then
>> stitching the results together.
>>
>> =====================================================
>>
>> Prof. Alexander Balaeff
>>
>> University of Central Florida
>> NanoScience Technology Center
>> 12424 Research Parkway, Suite 400
>> Orlando, FL 32826
>>
>> Phone: (407) 823-4576
>> FAX: (407) 882-2819
>> E-mail: abalaeff_at_gmail.com
>
>
>
>
> --
> Best,
> /A
- Next message: Alexander Balaeff: "Re: Running out of memory due to multiple mol addfile's (?)"
- Previous message: Vlad Cojocaru: "reading rst7 files generated by cpptraj"
- In reply to: Ashar Malik: "Re: Running out of memory due to multiple mol addfile's (?)"
- Next in thread: Alexander Balaeff: "Re: Running out of memory due to multiple mol addfile's (?)"
- Reply: Alexander Balaeff: "Re: Running out of memory due to multiple mol addfile's (?)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]