VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Wed May 20 2020 - 02:36:33 CDT

Dallas,

On Wed, May 20, 2020 at 03:29:08PM +1000, Dallas Warren wrote:
> 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.

The precise compiler version typically isn't important at all (I've even linked
VMD Windows binaries built using a mix of two different C++ compiler
versions, though I wouldn't normally recommend it). What is absolutely
critical however is that VMD and all of the libraries it links with are
compiled using the same linkage model. Microsoft's compilers have
always offered 4 or more linkage modes, and with more modern toolchains,
there are even more. If even one .obj file is compiled with a mismatched
linkage model, it's game over. In the Microsoft build options, these
flags are associated with both the linkage mode and C/C++ runtime linkage
mode (static vs. dynamic, optimized vs. debug, and in newer compilers
there are other flags for CPU arch types, etc, all of which must be
matched for all .obj, .lib, and .dll files you're working with!!

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

DynamicBonds uses geometry / display command memory linearly proporotional
to the resolution parameter. There's also a bunch of memory used for a
grid search for connected atoms. If I were to guess, it's the grid search
data structure that's killing you in this particular case.
You can test my theory here by changing your code to use the "Bonds" rep
instead of "DynamicBonds", and see if your memory issue is resolved or not.
If the memory problem is either gone, or reduced, then it's probably the
grid search data structure presenting the big challenge here.

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

The error messages are only telling you about the final allocation that's
failing, they aren't telling you about all of the other ones that
succeeded.

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

Sure, try that simple rep experiment and see if it makes a difference or not.

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 12:50, John Stone <[2]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][3]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][4]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][5]https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> >Â Â Â >Ä*Â Ä*Â Error message:
> >Â Â Â >Ä*Â Ä*
> >Â Â Â
> [2][4][6]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][7]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][8]https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> >Â Â Â >Ä*Â Ä*Â 2.
> >Â Â Â
> [7][9]https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> >Â Â Â >Ä*Â Ä*Â 3. mailto:[8][10]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][11]http://www.ks.uiuc.edu/~johns/Ä*Â Ä*Â Ä*Â Ä*Â Ä*Â
> Ä* Phone: 217-244-3349
> >Â Â Â [10][12]http://www.ks.uiuc.edu/Research/vmd/Ä*Â Ä*Â Ä*
> >
> > References
> >
> >Â Â Visible links
> >Â Â 1. mailto:[13]dallas.warren_at_monash.edu
> >Â Â 2. mailto:[14]johns_at_ks.uiuc.edu
> >Â Â 3.
> [15]https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> >Â Â 4.
> [16]https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> >Â Â 5. mailto:[17]dallas.warren_at_monash.edu
> >Â Â 6.
> [18]https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> >Â Â 7.
> [19]https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> >Â Â 8. mailto:[20]dallas.warren_at_monash.edu
> >Â Â 9. [21]http://www.ks.uiuc.edu/~johns/
> >Â Â 10. [22]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
> [23]http://www.ks.uiuc.edu/~johns/Â Â Â Â Â Â Phone: 217-244-3349
> [24]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. mailto:dallas.warren_at_monash.edu
> 4. mailto:johns_at_ks.uiuc.edu
> 5. https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> 6. https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> 7. mailto:dallas.warren_at_monash.edu
> 8. https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> 9. https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> 10. mailto:dallas.warren_at_monash.edu
> 11. http://www.ks.uiuc.edu/~johns/%C4%80
> 12. http://www.ks.uiuc.edu/Research/vmd/%C4%80
> 13. mailto:dallas.warren_at_monash.edu
> 14. mailto:johns_at_ks.uiuc.edu
> 15. https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> 16. https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> 17. mailto:dallas.warren_at_monash.edu
> 18. https://pbs.twimg.com/media/EYSJJIbVAAEp7gz?format=png&name=900x900
> 19. https://pbs.twimg.com/media/EYSJK97U4AEACm5?format=png&name=900x900
> 20. mailto:dallas.warren_at_monash.edu
> 21. http://www.ks.uiuc.edu/~johns/
> 22. http://www.ks.uiuc.edu/Research/vmd/
> 23. http://www.ks.uiuc.edu/~johns/
> 24. 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/