VMD-L Mailing List

From: Christopher MacDermaid (chris.macdermaid_at_gmail.com)
Date: Thu May 09 2013 - 10:59:03 CDT

Hi John,

Yeah, the multi-platform business I hadn't considered. I do like your
suggestion, though. For now, the other solutions are fine, I was just
curious as to the design decision. Thanks for clearing that up. Appreciate
it.

C

On Thu, May 9, 2013 at 11:48 AM, John Stone <johns_at_ks.uiuc.edu> wrote:

> Hi,
> The molinfo command simply returns the path that was originally recorded
> upon loading. The issues with normalizing the path automatically are
> complicated by the fact that there are several different mechanisms for
> loading files, and different operating systems have different rules that
> govern what is considered to be a legal path name, which can in some cases
> violate what Tcl or other tools are expecting.
>
> The only "advantage" of the current approach is that in cases when
> the user prefers relative path names for convenience when
> migrating VMD saved states between a laptop and a desktop machine,
> the current mechanism preserves these. If we were to force all paths
> to be stored in absolute form, any inconsistencies in filesystem
> mount points would break these saved states, including in large labs
> where the same filesystem may be mounted at a different NFS or Samba mount
> point depending on what client machine the user is logged into.
> Another example occurs when one uses 'rsync' to copy work back and
> forth between a laptop and a desktop. In that case, one would have
> to hand-edit the saved state files to fix them for the other machine if
> absolute paths are forced in all cases.
>
> Clearly, it is less than ideal that some file browsers return absolute
> paths and other store relative paths and there is therefore variation
> in the behavior of VMD depending on what platform you're running it on,
> and what preference you've set for using either the Tk-provided file
> selector or the FLTK-provided file selector window (of which Tk
> sometimes uses the native OS-provided file selector), which have
> differing behavior.
>
> The best solution would be for VMD to store both the absolute path and
> the relative path, and allow the user code calling 'molinfo' commands
> to determine which path they want/need to use. In the case of VMD saved
> state files, the ideal situation would be for VMD to try and load the
> file using the absolute path first, and try the relative path second if
> the first fails.
>
> All of this discussion is deceivingly simple sounding. When you start
> dealing with the differences in behavior on Mac/Unix/Windows it can be
> quite tricky to get anything that works across all three. The current
> code,
> despite its detractions, does work on all three. I had tried various
> things with normalizing paths years ago and after encountering various
> bugs, I left it the way it is. It may be time to revisit these issues,
> but the current code is the way it is for good (albeit in some respects
> historical) reasons.
>
> Cheers,
> John
>
> On Thu, May 09, 2013 at 11:32:35AM -0400, Christopher MacDermaid wrote:
> > Hi Axel,
> > On Thu, May 9, 2013 at 10:21 AM, Axel Kohlmeyer <akohlmey_at_gmail.com>
> > wrote:
> >
> > Why not simply canonicalize the file name yourself before calling
> mol
> > new?
> >
> > Of course, which is the workaround. However, this doesn't change that
> fact
> > that molinfo returns different things depending on how the mol was
> loaded.
> > I think it's pretty clear that the expectation should be that the
> absolute
> > path is always returned. What's the advantage the way it currently is?
> >
> > Axel
> > --
> > Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0
> > International Centre for Theoretical Physics, Trieste. Italy.
> >
> >
> ----------------------------------------------------------------------
> >
> > From: Christopher MacDermaid <chris.macdermaid_at_gmail.com>
> > Sender: owner-vmd-l_at_ks.uiuc.edu
> > Date: Thu, 9 May 2013 09:30:13 -0400
> > To: <vmd-l_at_ks.uiuc.edu>
> > Subject: vmd-l: molinfo top get filename, dialogue vs. "mol new"
> > Hello,
> > When calling "molinfo top get filename", the filename returned is
> > different depending on the method in which I choose to load the
> > molecule.
> > If I use the file browser dialogue, molinfo returns the absolute
> path,
> > however if I use the console with "mol new" it returns the relative
> > path:
> > vmd> mol new ../../../../test/test.pdb
> > vmd > molinfo top get filename
> > ../../../../test/test.pdb
> > detrimental in the event that I want to reload the molecule like so
> and
> > if I've changed working directories...
> > proc reload { mol } {
> > lassign {*}[molinfo $mol get filename] psf dcd
> > mol delete $mol
> > mol new $psf type psf waitfor all
> > mol addfile $dcd waitfor all
> > }
> > Can this be fixed such that "mol new" will set the correct file
> name to
> > one that is the absolute path of the loaded files. I realize this
> may
> > present complications since mol new can be used to create an empty
> > molecule, but the behavior regarding the file names is rather
> > unexpected.
> > Thanks!
> > Dr. Chris MacDermaid, Postdoctoral Fellow
> > Institute for Computational Molecular Science
> > Temple University, Philadelphia, PA
> >
> > --
> > --
> > C
> >
> > Dr. Chris MacDermaid, Postdoctoral Fellow
> > Institute for Computational Molecular Science
> > Temple University, Philadelphia, PA
>
> --
> 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/
> 

-- 
--
C
Dr. Chris MacDermaid, Postdoctoral Fellow
Institute for Computational Molecular Science
Temple University, Philadelphia, PA