VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Thu May 09 2013 - 10:48:49 CDT

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/