From: John Stone (
Date: Wed Dec 01 2021 - 23:35:30 CST

  I just read the code -- the very top of the STAMP plugin queries
TMPDIR at runtime and assigns the temp directory to whatever it contains.
Here I will note that Tcl can Unix path separators "/" even on Windows,
so I would try making a c:\temp directory on your box, and then set
TMPDIR to "c:/temp" (note the forward slash for Tcl's benefit), and see
if you get differing behavior or not.

I would also advocate perhaps just directly hacking the STAMP plugin src if
necessary to try various workarounds. The actual code is in your VMD
installation directory, e.g., in this relative path:

(you can also just find it on your system with "dir /s stamp.tcl" or similar)

Interesting issues with WSLg.
In general, a "newer" driver version should not cause trouble for
VMD (unless we're talking many years newer), so that's likely something else.
My intuition here is that the WSL CUDA driver package is missing the
OptiX 7.x RTX entry points at present. Even though CUDA is there,
OptiX needs more. You can prevent those errors by disabling OptiX
on WSL for the time being, by setting the environment variable:


On Wed, Dec 01, 2021 at 10:23:47AM +0100, Stefan Boresch wrote:
> 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
> >
> >
> > --
> > NIH Center for Macromolecular Modeling and Bioinformatics
> > Beckman Institute for Advanced Science and Technology
> > University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> > Phone: 217-244-3349
> >

NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801           Phone: 217-244-3349