VMD-L Mailing List

From: Stefan Boresch (stefan_at_mdy.univie.ac.at)
Date: Thu Dec 02 2021 - 13:05:28 CST

Hi John,

with your vmdinit.tcl (which I copied into the directory hierarchy of
my 1.9.4a53 installation) it's not necessary anymore to meddle with / set
TMPDIR.

vmd (and the multiseq/stamp plugin) now correctly recognize the default
windows TEMP directory, i.e.,

Info) Opened coordinate file C:\Users\<username>\AppData\Local\Temp/multiseq-4765841334483512.0.pdb for writing.
etc.

However, the stamp run still fail as reported this morning (see the
google drive link in my previous mail for the full log). Below find
the final lines from the vmd console window.

Best regards and many thanks,
Stefan

------------

Reading in matrix file multiseq-4765841334483512.mat...
Doing cluster analysis...
Read: 4 Entries
CPU time: 0.000000 seconds
Setting up unclust
Setting up notparent
Setting up clust
CPU time: 0.000000 seconds
Single linkage on similarity
Doing Cluster Analysis...
child killed: unknown signal
    while executing
"error $out"
    (procedure "run" line 41)
    invoked from within
"run "$tempDir" -f \"$filePrefix.scan\" -ATOMTYPE $atomTypeParam -prefix $filePrefix"
    (procedure "::STAMP::alignStructures" line 78)
    invoked from within
"::STAMP::alignStructures $regionSequenceIDs $scan $scanslide $scanscore $slowscan $npass"

-----------

On Thu, Dec 02, 2021 at 11:19:23AM -0600, John Stone wrote:
> Stefan,
> Try replacing the vmdinit.tcl in your Windows installation
> with the one I'm attaching to this email, and let me know if
> that cures your temporary file problems or not. This file
> would normally be installed in, e.g.:
> c:\Program files (x86)\University of Illinois\VMD\scripts\vmd\vmdinit.tcl"
>
> Try replacing the original with the new one, and then see if
> your problem goes away or not.
>
> Best,
> John
>
> On Thu, Dec 02, 2021 at 11:13:07AM -0600, John Stone wrote:
> > Stefan,
> > The difference in behavior w/ 32-bit and 64-bit builds and
> > the existence (or not) of various sytem environment variables
> > is almost certainly due to changes in Microsoft's approach in
> > the new ABI as well as the contents of the registry that exist
> > for the 64-bit apps. They've changed the location of user
> > temporary files at least 3 times, so this is not particularly
> > suprising.
> >
> > I've been digging and it seems that for recent Windows versions,
> > we should also be checking the contents of the system-provided
> > environment variable TEMP, which definitely exists on my machines,
> > and correctly points to "c:\users\<username>\AppData\Local\Temp".
> >
> > I'm going to go ahead and make that change in the VMD startup scripts
> > and we'll see what that buys us. It shouldn't interfere with any
> > of the situations where the existing code was working correctly,
> > this will only be invoked if TMPDIR is unset, and it has to be
> > a better situation than falling through to "c:"...
> >
> > I have similar issues with temporary directories on MacOS X now
> > because Apple has started to forbid interprocess communication via
> > temporary files in the standard temporary folders. There, I'm likely
> > to have to make a per-user VMD temporary files area within their
> > home directory. It's stupid that Apple's security is breaking
> > usability of temporary files there, but that's life, so we'll try
> > and code around it.
> >
> > Best,
> > John
> >
> > On Thu, Dec 02, 2021 at 10:49:17AM +0100, Stefan Boresch wrote:
> > > John,
> > >
> > > first: great to hear about 1.9.4beta approaching!! *and*
> > > congratulations to you and the whole team on the Covid work!! (anything
> > > we learn about this virus helps)
> > >
> > > Back to the issue at hand: one step forward, one sideways ..
> > >
> > > Setting TMPDIR to something meaningful (for users I would not
> > > recommend c:\temp!!, I have it set to c:\Users\<my_user_name>\tmp; the
> > > \ apparently cause no problem for tcl) makes the write failure go away
> > > (I had by accident set/named the environment variable TEMPDIR ..) and stap
> > > starts. However, it grinds away only to end with an error. I saved the
> > > log file, it's at
> > >
> > > https://urldefense.com/v3/__https://drive.google.com/file/d/1DREIGqc4r2wH1S9bFgZ6u8n1r_ielRMr/view?usp=sharing__;!!DZ3fjg!tkumkn--PenTqMpjbWC-1CJwLAaB6AMuOuur-x0TcNrRifnbAxVAt1q_A3dGbJAg$
> > >
> > > I notice that it doesn't find dssp, but to the best of my knowledge I have
> > > no dssp on this windows machine ..
> > >
> > > What I don't get is the following: I have installed on the very *same*
> > > (Windows) machine vmd 1.9.3 and vmd 1.9.4a53 -- they coexist
> > > peacefully as they install themselves in very different paths, and
> > > 1.9.3 is 32bit, 1.9.4 is 64 bit (as you obviously know!).
> > >
> > > * I compared the content of the ./plugin/WINxx/tcl/stamp1.2
> > > directories for the two installations, and the only file
> > > different is stamp.exe. E.g., stamp.tcl is identical in both
> > > cases.
> > >
> > > * Yet, having to set TMPDIR is (apparently) not needed for
> > > 1.9.3. Further, the stamp error/failure to align doesn't arise
> > > for 1.9.3 -- as I said earlier, the multiseq part of the tutorial
> > > works just fine with 1.9.3.
> > >
> > > Thanks again for your help, best regards,
> > >
> > > Stefan
> > >
> > > PS: One more aside: Is it just me, or are VMD / NAMD (Univ. Illinois)
> > > related pages extremely slow? Just now, trying to load the main
> > > tutorial
> > > (http://www.ks.uiuc.edu/Training/Tutorials/vmd/tutorial-html/index.html)
> > > and then go to the multiseq section took 2 minutes to load. There may
> > > be many things to complain about my university, but our internet
> > > connectivity really is extremely good and I checked a few pages
> > > originating in the US which loaded normally fast. I have noticed this
> > > sluggishness for quite a while, just thought I'd mention it.
> > >
> > > On Wed, Dec 01, 2021 at 11:35:30PM -0600, John Stone wrote:
> > > > Stefan,
> > > > 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:
> > > > plugins/WIN64/tcl/stamp1.2/stamp.tcl
> > > >
> > > > (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:
> > > > VMDNOOPTIX
> > > >
> > > > Best,
> > > > John
> > > >
> > > > 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
> > > > > > 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/
> > > >
> > > > --
> > > > 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/
> >
> > --
> > 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/
>
> --
> 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/