From: Robin Betz (robin_at_robinbetz.com)
Date: Fri Feb 10 2017 - 17:25:01 CST

If you're on Linux, and don't want to bother with recompiling, you can
always use tmpfs to store your data file. It's a partition type that acts
like the hard disk but is actually located in memory. Usually /tmp is
mounted as tmpfs for example. More here: https://wiki.archlinux.
org/index.php/Tmpfs

Then you can write out your intermediate file to a tmpfs mount and load it
in again with VMD, and it will reside in memory the whole time. This is
more of an approach for a one time thing and wouldn't be super useful for
plugin design though, unless you assume /tmp is always available... For a
general solution you'll probably have to get into the VMD source.

Best,
Robin

On Fri, Feb 10, 2017 at 2:17 PM, Vermaas, Joshua <Joshua.Vermaas_at_nrel.gov>
wrote:

> In terms of fully compiled builds, I'm afraid the answer is no, and those
> aren't even useful if they need to link into python, since the system
> pythons are probably different. Compiling VMD from source is not as easy as
> it could be, but its also not impossible (although it definitely feels that
> way the first time)! The two best sources that explain the process in all
> the gory detail that is required to get python-enabled VMD working that
> I've found are http://robinbetz.com/blog/2015/01/08/compiling-vmd-with-
> python-support/ (for linux) or http://nuweb5.neu.edu/bardhan/?p=104 (for
> mac).
>
> In terms of the data itself, volmap gives you a bunch of voxel values, 1
> value per voxel. The value of the voxel depends on what analysis you asked
> for. Here it would probably be informative to look at what a dx file looks
> like, just for a small synthetic test set. The data is fundamentally stored
> the same way.
>
> -Josh
>
> On 02/10/2017 02:51 PM, Karl Decker wrote:
> Thank you for including that command in the VMD CVS, Joshua Vermaas. I've
> gotten an account, checked out VMD through CVS, and found the py_molecule.C
> source file that contains the definition of the python object
> mol_get_volumetric(). I'm in the process of assessing how I would use the
> mol_get_volumetric in my plugin. Thanks very much for the help.
>
> I do have another question, though. Are fully compiled builds from the
> source code on CVS available for download? If not, it may be difficult to
> use the features available through CVS, as I have not been able to compile
> VMD on my machine.
>
> Also, what format does the VolMap data take? It's not clear from the
> sources I've seen.
>
> Thanks,
> Karl
>
> On Tue, Feb 7, 2017 at 3:51 PM, Vermaas, Joshua <Joshua.Vermaas_at_nrel.gov<
> mailto:Joshua.Vermaas_at_nrel.gov>> wrote:
> Hi Karl,
>
> It sounds like you want to interact with volume maps already loaded into
> VMD. When I needed to do this for my own purposes, I dug into VMD internals
> and wrote something to access volumetric datasets and make it accessible to
> VMD's python interface (this is now in the VMD CVS as
> molecule.get_volumetric). From there, you can access the data itself in
> python and do whatever you want. This does not expose a pointer to VMD's
> internal data structure directly (which isn't even useful, since its stored
> out of order as far as numpy is concerned), however since the copy never
> went to disk, it was fast enough to be efficient.
>
> -Josh
>
> On 02/07/2017 02:15 PM, Karl Decker wrote:
> Is it possible to share memory between two processes, one of which is VMD?
> I'm aware this is generally messy and dangerous, but it's one way to avoid
> writing large files to disk and slowing down the execution of the plugin
> we're designing. It would obviously take some effort to write the code for
> sharing the memory between two processes, but first I want to know: can VMD
> even be made to share its memory with another process?
>
> Alternatively, we are considering implementing a python plugin to VMD. Can
> VMD be made to share memory with a plugin?
>
> The memory we want to share is from VolMap, specifically a distance map
> generated in VolMap. The idea is to sidestep writing the map to disk
> because it takes too long.
>
> Thanks,
> Karl
>
>
>
>
>