VMD-L Mailing List

From: Stefan Boresch (stefan_at_mdy.univie.ac.at)
Date: Wed Dec 01 2021 - 03:23:47 CST

Hi John,

as usual, thank you for your detailed and thoughtful reply. It starts to
look as if this is mostly out of your control. Remaining answers inline:

On Wed, Dec 01, 2021 at 12:49:28AM -0600, John Stone wrote:
> Hi,
>
> On Tue, Nov 30, 2021 at 02:45:40PM +0100, Stefan Boresch wrote:
> > Hi,
> >
> > there was a mail to the list a few days ago, to which I can't answer
> > anymore since I too quickly deleted it, but I just want to confirm the
> > issue (and it's also biting me in a course I am teaching ;-)
>
> The other note described hanging behavior, so that's a little different from
> what you're describing below.
>
> > On Windows 1.9.4a53 the multiseq tool does not really work; even for the
> > very simple example from the tutorial. (The tutorial example works fine
> > with 1.9.3).
>
> Do your windows systems have the TEMPDIR environment variable set?
> If so, what is it set to?
>
> This can impact the behavior of VMD's use of temporary files generally,
> and that may also affect multiseq's use of STAMP, although since we didn't
> develop multiseq I would need to look at the code to determine what exactly
> it is trying to do there..

It certainly looks as something goes wrong here. So, the Windows provided
environments TEMP and TMP seem to be set up correctly, pointing to

C:\Users\<my_user_name>\AppData\Local\Temp

In addition, I just retried my test with vmd 1.9.4a53 (Windows) and since
I have to set NOOSPRAY=1 anyways, I also set

$env:TEMPDIR="C:\Users\<my_user_name>\tmp"

before starting vmd in this powershell window.

Looking at the output of 'env', these environment variables are definitely
set in this powershell instance.

However, same problems as before, the
STAMP alignment part fails with (from my console/powershell window):

ERROR) Unable to open file c:/multiseq-6760554558951666.0.pdb of type pdb for writing frames.
Unable to open file c:/multiseq-6760554558951666.1.pdb for writing
ERROR) Unable to open file c:/multiseq-6760554558951666.1.pdb of type pdb for writing frames.
Unable to open file c:/multiseq-6760554558951666.2.pdb for writing
ERROR) Unable to open file c:/multiseq-6760554558951666.2.pdb of type pdb for writing frames.
Unable to open file c:/multiseq-6760554558951666.3.pdb for writing
ERROR) Unable to open file c:/multiseq-6760554558951666.3.pdb of type pdb for writing frames.
MultiSeq Error)
couldn't open "c:/multiseq-6760554558951666.start.domain": permission denied
    while executing
"open "$tempDir/$filePrefix.start.domain" w"
    (procedure "::STAMP::alignStructures" line 58)
    invoked from within
"::STAMP::alignStructures $regionSequenceIDs $scan $scanslide $scanscore $slowscan $npass"

If this were the path it tried, it obviously can't work, but see below:

> > The STAMP alignment exercise with 1.9.4a53 (Windows) fails, because
> > temporary files want apparently be written to C:\ which obviously
> > doesn't work. The console output on 1.9.3 shows the same location, but
> > there things work, so I assume it's writing these files to some
> > legitimate location. (I failed to locate them ..).

Let me stress again that the same exercise with 1.9.3 (Windows)
works. According to the console/powershell output, the intermediate
files are apparently also written directly to "C:/.." -- which should
NOT work, but quite evidently does. Let me rephrase this: I assume the console
message is wrong, and the intermediate files are written somewhere "legitimate".
As I said before, I fail to locate these files, but on Windows I am a complete
beginner.

> > Additional observations:
> >
> > 1) On all platforms, the multiseq tool tries to download two files (or
> > the same file from two locations) which are/is not available anymore
> > (but at least for the tutorial example this seems irrelevant).
>
> I'm aware of the download problems, we had reported this to the team
> that has developed multiseq, but they haven't managed to resolve the
> problem with their web server. I will send them a note reminding them
> to dig into this again.

In fact, I think this error has been around for quite some time -- for the
tutorial exercise(s) it seems to have no effect.

> > 2) Running Linux 1.9.4a55 under WSL/Windows 11 (with WSLg) mostly
> > works (fonts too small, but that's a generic WSLg issue). The
> > multiseq exercise, however, also fails because the menus of the
> > multiseq tool become unresponsive. All primary menus (molecule,
> > graphics, display ..) work just fine.
>
> That's an interesting issue. I assume that if you run natively
> on Linux this hanging behavior for multiseq doesn't occur?

OK, just tried with 1.9.4a55 (the OptiX RTRT enabled build) natively on
Linux, and the whole multiseq exercise runs through without a hitch.

BTW: here the path reported by STAMP is /tmp/... , which makes sense ;-)

And I just retried under Windows/WSLg; the multiseq menus are unusable; no
error in the console itself.

> > Just thought I'd confirm the earlier post -- any insights / hints would
> > be appreciated.
>
> The linux version uses a different version of Tcl/Tk than the
> Windows/Mac versions, which hasn't previously shown any hanging
> behavior w/ Multiseq, but it's possible that WSLg triggers some
> different behavior with Tk GUI processing that leads to a hang
> for a different reason than the Windows/Mac-native builds.
> As with the other email, a big question is whether or not you
> see any error messages logged in the main VMD text console or not.

But WSLg in general is a bit strange. I have a lot of fun (no success)
getting any CUDA stuff (CHARMM, OpenMM, some other MD related stuff)
to run (error is always along the lines 'inconsitent toolchain'),
though the CUDA toolkit testcases themselves compile and run. This
most likely explains, btw, the failure of the RTRT context to work

OpenGLDisplayDevice) Creating OptiX RTRT context...
OptiXRenderer) Error setting RT_GLOBAL_ATTRIBUTE_ENABLE_RTX!!!
ERROR) OptiXRenderer) ERROR: Failed to load OptiX library (OptiXRenderer.C:1045
ERROR) OptiXRenderer) Failed to create OptiX rendering context
OpenGLDisplayDevice) OptiX RTRT context created.
OptiXRenderer) ERROR: Failed to load OptiX shared library.
OptiXRenderer) NVIDIA driver may be too old.
OptiXRenderer) Check/update NVIDIA driver

If anything, the nvidia driver is too new ;-) [510.06]

But since Microsoft considers this 'beta', I think they'll need time to
sort this out. Certainly getting the basic functionality
of VMD to run out of a WSL window without fiddling with an X Server etc *is*
impressive in itself ..

Again, thanks for your help -- if you or someone on the list who is more
Windows savvy has ideas, I am happy to try them.

Best,

Stefan Boresch

> Best,
> John Stone
> vmd_at_ks.uiuc.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
> http://www.ks.uiuc.edu/~johns/ Phone: 217-244-3349
> http://www.ks.uiuc.edu/Research/vmd/