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

John,

thanks a lot for trying to look into this -- it's quite clear that you have
to fix other people's code. While it won't help you much, let me just
repeat that the same sequence (so I guess identical invocation of STAMP
itself) runs fine on the same computer using 1.9.3 (32bit).

I wish I'd know anything about programming on Windows, then I could at
least try getting a stacktrace or something.

Best regards,

Stefan

On Thu, Dec 02, 2021 at 01:50:06PM -0600, John Stone wrote:
> Stefan,
> I read your STAMP output log and compared it with a couple of other
> bug reports I've heard there, and it seems that STAMP itself is crashing
> when it gets to the clustering step. I suspect there's a bug in STAMP here
> that's doing something that Windows isn't allowing, that Linux and MacOS
> are ignoring. A classic example would be something that's system-dependent
> like a malloc() of zero, or the like. Both your log and that of the other
> user end with the crash in STAMP's clustering step.
> I'll see if I can determine whether there's an easy fix to STAMP or not.
> Since we didn't write it, it'll be an adventure I'm sure...
>
> Best,
> John
>
> On Thu, Dec 02, 2021 at 08:05:28PM +0100, Stefan Boresch wrote:
> >
> > 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/
> >
>
> --
> 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/