VMD-L Mailing List

From: Dallas Warren (dallas.warren_at_monash.edu)
Date: Wed May 20 2020 - 00:29:08 CDT

Thank you for the response John.

We are after the MSVC version so that we can compile from source for Win32,
nothing specifically to do with this issue. Have tried quite a few
different compilers and each compiler has been failing at linking.

I'll be adjusting the representations of all molecules to minimise the
chance that a user will encounter this error, on the list of things to get
to already ( I'd hate to see your todo list ;) ). Plus will be adding an
error catch for it if it does happen. So that will sort things out as best
we can currently and shouldn't encounter it again.

To start with we have been using defaults for each of the representations.
This error has been arising with systems with DynamicBonds, resolution 12,
for a large number (100,000) of water molecules. Yes, well aware not a
reasonable representation for water, it was something simply added randomly
to get things going. Thing that threw us some was the fact that this error
doesn't occur with Linux installs, including with significantly larger
numbers of waters. Plus the fact that it was failing and only asking for
hundreds of MB of memory.

Anyway, have a way forward now. Thanks for your assistance John

Catch ya,

Dr. Dallas Warren
Drug Delivery, Disposition and Dynamics
Monash Institute of Pharmaceutical Sciences, Monash University
381 Royal Parade, Parkville VIC 3052
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 12:50, John Stone <johns_at_ks.uiuc.edu> wrote:

> 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/
>