VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue May 19 2020 - 21:50:14 CDT

Dallas,

On Wed, May 20, 2020 at 09:30:17AM +1000, Dallas Warren wrote:
> John,
> Thank you for the suggestion. I am aware of ways that can tweak
> representations to alter the number of faces, resolution etc. And that
> definitely works for a given system.
> However, that isn't going to help us here because we are looking for a
> more generalised solution. You may recall we have VMD wrapped inside
> other software (in-house) and the number of particles and representation
> for things displayed within the VMD window will be highly variable.

Just because it is wrapped doesn't mean that you can make better choices
in the representations that you generate!

I have seen many people choose unwise graphical representation parameters
when they generate them via their own code.

As I warn, some of the reps have quadratic or cubic behavior in terms of
generated geometry wrt/ resolution or grid spacing parameters.
Whoever is developing the code to emit the graphical representation commands
needs to be wary of going too far with these parameters.

Also, VMD enforces some sanity checks when you create graphical
representations in the VMD GUI, but if you do it via Tcl, VMD assumes you
know what you're doing and it does not enforce the same limits.
This freedom can allow an expert VMD user to go beyond what the
GUI would normally allow, but it will also allow you to hang yourself. :-)

> This
> error has been freezing the software and we're looking for a way to handle
> that. First option was to see if we can resolve the issue.

As I said, the first question is to find out what you're doing with the
graphical rep parameters, as that is likely the genesis of the problem.

> I take it
> this is a hard ceiling on the memory usage with 32 bit Windows?

32-bit Windows apps can typically use up to 2GB of memory unless
specially compiled, which creates other incompatibilities usually.

> If that
> is the case, then we will move to the second option, which is an error
> capture so that when this is thrown up it doesn't freeze things (because
> it constantly outputs the error, over and over and over, rather than just
> a single write). And we will couple that with optimising representations
> so that it is harder to reach the limit as well.
> Can you also tell us what compiler you use with the Windows versions?

It depends on which version you're running (CUDA vs. non-CUDA),
but it's not relevant to anything going forward.
I have to setup a totally new Windows x64 build machine now due to the
coronavirus lockdown and a combination of the inaccessibility
of the old build machines and network security issues with
Windows revs prior to Windows 10 as of earlier this spring.

At present, we've likely just got a couple weeks or so until the
final CUDA 11.0 is released, and when CUDA 11 comes out, I will
setup the new build machine's compiler stack, and being compiling
the library dependencies that work with that. We need CUDA 11 to be
able to support the upcoming NVIDIA Ampere GPUs. I'm setting up the
Windows build system for x64 compilations of VMD 1.9.4, but I
need to test compatibility between CUDA 11 and the various MS compilers,
FLTK, Tcl/Tk, and a bunch of other VMD library dependencies, almost
exactly the same thing I've just had to do to get VMD compiling on
MacOS X Catalina.

Stay tuned a bit longer here and I hope to have news about x64
compilations of VMD on Windows...

Best,
  John

> Catch ya,
>
> Dr. Dallas Warren
> Drug Delivery, Disposition and Dynamics
> Monash Institute of Pharmaceutical Sciences, Monash University
> 381 Royal Parade, Parkville VIC 3052
> [1]dallas.warren_at_monash.edu
> ---------------------------------
> When the only tool you own is a hammer, every problem begins to resemble a
> nail.
> On Wed, 20 May 2020 at 06:18, John Stone <[2]johns_at_ks.uiuc.edu> wrote:
>
> Dallas,
> Â Can you be more specific about what graphical representations
> you're using that are causing the memory exhaustion problem? There
> may be a simple adjustment to your display parameters that can
> dramatically reduce memory usage. This is particularly true for
> the surface representations, isosurface, and the various ribbon/cartoon
> representations which have either quadratic or cubic memory consumption
> vs. their respective "resolution" parameters of various kinds.
>
> If you share more about what representations and parameters you're
> using,
> I may be able to give you advice to overcome the issue.
>
> Going forward I'm working on a 64-bit Windows build of VMD, but
> this has been complicated by the fact that I don't have effective remote
> access to my normal Windows VMD build systems, and I'm having to setup
> a new one that I can use here at home. That would ultimately increase
> the amount of memory available to VMD, at least on modern machines
> with say 8GB or more of memory, but I've got probably a week or two
> of work to do there and I'm waiting on the next rev of the Windows
> CUDA tools to be released (a matter of days now) so that I can ensure
> compiler version compatiblity etc.
>
> Best,
> Â John Stone
>
> On Mon, May 18, 2020 at 05:39:32PM +1000, Dallas Warren wrote:
> >Â Â Works fine with Linux installation.
> >Â Â Works fine for Windows installation (WIN32 1.9.3 Nov 30 2016)
> with less
> >Â Â graphically intensive molecule representations.
> >Â Â Fails for Windows installation for more graphically intensive
> molecule
> >Â Â representations with the following error message:
> >Â Â ################
> >Â Â Failed to increase display list memory pool size, system out of
> memory
> >Â Â Ã*Â Ã* Previous pool size: 200MB
> >Â Â Ã*Â Ã* Requested pool size: 240MB
> >Â Â ################
> >Â Â How do I resolve thisÃ* issue?
> >Â Â Start up message:
> >Â Â
> [1][3]https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> >Â Â Error message:
> >Â Â
> [2][4]https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> >Â Â And another question, exactly which MS compilers are being used
> to build
> >Â Â the Windows version of VMD?
> >Â Â Thank you for any assistance.
> >Â Â Catch ya,
> >
> >Â Â Dr. Dallas Warren
> >Â Â Drug Delivery, Disposition and Dynamics
> >Â Â Monash Institute of Pharmaceutical Sciences, Monash University
> >Â Â 381 Royal Parade, Parkville VIC 3052
> >Â Â [3][5]dallas.warren_at_monash.edu
> >Â Â ---------------------------------
> >Â Â When the only tool you own is a hammer, every problem begins to
> resemble a
> >Â Â nail.
> >
> > References
> >
> >Â Â Visible links
> >Â Â 1.
> [6]https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> >Â Â 2.
> [7]https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> >Â Â 3. mailto:[8]dallas.warren_at_monash.edu
>
> --
> NIH Center for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> [9]http://www.ks.uiuc.edu/~johns/Â Â Â Â Â Â Phone: 217-244-3349
> [10]http://www.ks.uiuc.edu/Research/vmd/Â Â Â
>
> References
>
> Visible links
> 1. mailto:dallas.warren_at_monash.edu
> 2. mailto:johns_at_ks.uiuc.edu
> 3. https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> 4. https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> 5. mailto:dallas.warren_at_monash.edu
> 6. https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> 7. https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> 8. mailto:dallas.warren_at_monash.edu
> 9. http://www.ks.uiuc.edu/~johns/
> 10. http://www.ks.uiuc.edu/Research/vmd/ 

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/