From: Raman Preet Singh (ramanpreetsingh_at_hotmail.com)
Date: Thu Dec 02 2021 - 07:27:27 CST

Stamp issues apart, the website is indeed slow at my end too. Not only plugins pages but other NAMD/VMD pages too take quite a while. I am located in India.

Regards,
Raman

________________________________
From: owner-vmd-l_at_ks.uiuc.edu <owner-vmd-l_at_ks.uiuc.edu> on behalf of Stefan Boresch <stefan_at_mdy.univie.ac.at>
Sent: Thursday, December 2, 2021 3:19:17 PM
To: John Stone <johns_at_ks.uiuc.edu>; vmd-l_at_ks.uiuc.edu <vmd-l_at_ks.uiuc.edu>
Subject: Re: vmd-l: Multiseq / stamp alignment on Windows 1.9.4alpha

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!tauNuHYyJhZJkTDnBB7Thuz_LLUVCQ9Y2t-ztEyqaHeAQeiHK3vQw4nWGNGQhwlLlA$

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/