SIMION 8.0 Issues/Bugs/Enhancements

Issue I220 [med,80,HIGH]
  Requirement that all files in the same workbench (.iob) be in the
  same directory.

  SIMION 7.0 and 8.0 require all files (.pa, .fly, .rec, etc.) 
  associated with a workbench (.iob file) to be in the same directory
  as that .iob file.  This is specified in the manual.  Partly the
  reason for this that the association between these files and the
  .iob is defined implicitly: on loading an .iob file, SIMION looks to
  see if any other files in the same directory exist with the same
  base filename as the .iob and automatically loads those files
  (e.g. hello.iob will search for and load hello.fly, hello.rec,
  etc.).  An exception is potential array files, whose names are
  listed explicitly in the .iob file (since a workbench can contain
  multiple different potential arrays).  However, even then, only
  the file names are stored (there is no directory information), so
  these potential arrays are assumed to be in the same directory
  as the .iob file.

  Loading an .iob file and then attempting to use files not in the
  same directory is not recommended (the behavior on doing this is
  undefined) and may cause odd problems, particularly in less recent
  versions of SIMION (e.g. prior to 8.0.5).  These problems are being
  eliminated in more recent versions of SIMION to allow this more.
  For example...

  Sub-issues:

    As of 8.0.2, relative paths in the "fly" command are
    accepted: simion --nogui fly ../examples/tof/tof.iob

    Issue I220.2 - "Prevent current directory changing when loading
      .con/.rec/.fly/.fly2/.ion/.pa files outside the current directory"

    Issue I220.3 - Allow workbench IOB to contain PAs in a different directory.

  There are reasons one might want to have files in a project be in
  different directories.  You might have files that are shared by
  multiple workbenches.  These may be large potential array files
  that you don't want to have multiple copies of.

  There are some workarounds you can use:

  Method #1: Multiple .iob files in the same directory.

    Multiple .iob files may be placed in the same directory
    and share potential array files.  For example, if one.iob and
    two.iob both need to use alpha.pa, you can can place all these
    files in a single directory:

      myexample\one.iob
      myexample\two.iob
      myexample\alpha.pa

    A number of SIMION examples use this approach (e.g. "hda").

  Method #2: import statements.

    Some files types allow "simion.import" statements (e.g. .lua and
    .fly2) similar "include" statements (e.g. .gem) that load the
    contents of another file.  For example, consider that one.iob and
    two.iob both need to share a common FLY2 file named one.fly2.  You
     could of course make a copy of one.fly2 and save it as two.fly2 like
    this:

      example1\one.iob
      example1\one.fly2
      example2\two.iob
      example2\two.fly2

    An alternative is to edit two.fly2 in a text editor so that
    it contains only this:

      simion.import '../example1/one.fly2'

    Now, any changes to one.fly2 are automatically reflected in
    two.fly2 (upon reloading two.fly2).

    A number of SIMION example use this type of approach
    (e.g. "ionfunnel"), usually for sharing workbench programs code or
    entire programs.

  Method #3: Hard links in the NTFS file system.

    A number of operating systems allow a file system to contain links
    (either "hard links" -- http://en.wikipedia.org/wiki/Hard_link -- or
    "symbolic (soft) links" --
    http://en.wikipedia.org/wiki/Symbolic_link ) so that a single file
    on disk can be referenced from multiple locations.  For example,
    consider the case of

      example1\one.iob
      example1\one.pa
      example2\two.iob
      example2\two.pa

    Normally, one.pa and two.pa are different files (maybe even copies
    of each other).  However, if two.pa is a link to one.pa, then both
    are actually the same file--only one copy is stored on disk and
    changes made two one of these are immediately seen in the other.
    The file just has two identities.

    Now, there are two commonly supported types of links: hard and soft
    (a.k.a symbolic).  Refer to the Wikipedia pages above for the
    difference.

    On *nix-like operating systems (e.g. Linux and Mac OS X), both
    hard and soft links are available.  Hard links are also supported
    on more recent versions of Windows (e.g. 2000, XP, and Vista),
    assuming the file system is NTFS (the default).  Windows also has
    some support for soft links but it is not useful to us here since
    its soft links are only supported on directories (not individual
    files).

    On Windows, hardlinks can be created via the "fsutil" command-line
    command:

      Usage : fsutil hardlink create <new filename> <existing filename>
         Eg : fsutil hardlink create c:\foo.txt c:\bar.txt

    On *nix-like operating systems (even Cygwin shells under Windows for
    hard links), the "ln" command can be used:

      ln foo.txt bar.txt      # make hard link
      ln -s foo.txt bar.txt   # make soft link

    A convenient way to run these commands is with the .iob file open
    in SIMION run this command in the bottom Lua command bar to open
    a Windows console window:

      os.execute 'start cmd'

    Then type the required fsutil command in the console window and
    finally close the console window.

    One disadvantage of these links is that it is not always easy to see
    (or at least notice) that a link exists between two files.
    modifying a file from one location would (possibly inadvertantly)
    modify the file seen from the other location.  Futhermore, these
    links could get lost if the directories are copied or moved to
    some other location.

  These are some possible ways SIMION may be extended in the future to
  better support files in different directories:

  Suggestion #1: Windows shortcuts or similar mechanism.

    Windows shortcuts are files that link to another file.  A shortcut
    is a real file that contains the path of another file.  Is
    (probably to our advantage) not some low level transparent
    reference maintained in the filesystem (like hard/symbolic links).
    However, shortcuts don't support relative paths, and an ASCII
    format for shortcuts would be preferrable.
    
  Suggestion #2: Handle relative paths in the IOB files.

    This is probably the optimal solution.  Howeverm this might
    slightly break some compatiblity with 7.0, though there are
    ways to deal with that. This should be investigated more.

  Suggestion #3: Allow a list of search paths to be specified with the IOB.

  Comments (paraphrased):

    > When a FLY is taken from a different directory than an IOB, and
    > the Retain button is unchecked, the .trj file is NOT
    > deleted....(theo)

      This is resolved by Issue I220.2 - "Prevent current directory
      changing when loading .con/.rec/.fly/.fly2/.ion/.pa files
      outside the current directory."

    > Usually I have different projects that use the same
    > PAs. To keep things nicely organized I have all stuff for
    > each project within the same directory. Since the PAs loaded
    > with the IOB have to be in the same directory this means I have
    > many identical duplicate PAs. I would propose that either you
    > allow longer paths that or you could just use virtual PAs
    > (i.e. linked to the real PA which however could be in a
    > different directory).  With large PAs this would save space.
    > (theo-20051115)

      Noted (see above).

    > A similar thing holds for the PRG names that have to be identical
    > to the PA names. Many times I want to use different PRGs with
    > the same PAs. Same problem and for the time same space
    > squandering solution as above.  (theo-20051115)

      Note: Lua files attached to the IOB avoid this problem, and
      Lua files can use simion.import to load code from other files.

    > I have not been able to execute the 'fly' command successfully
    > unless the .iob and all of the .pa's, .fly, etc. are all in the
    > same directory as the simion executable.  If I have the project in
    > a directory different than the simion executable, and I execute
    > simion from the SIMION 8.0 directory, I can get the .iob to load
    > if I specify its full path on the command line, but then that path
    > doesn't seem to be used to load the .pa's, etc., so it fails.
    > If I execute simion from the project directory (by including the
    > SIMION 8.0 executable directory in the PATH system variable), I
    > don't need to specify the path for the .iob, but the .pa's still
    > don't load.  It is as if simion is looking for the .pa's in the
    > simion executable directory. (danr-20051213)

      This is fixed as of 8.0.2, in which case relative paths in the
      "fly" command are accepted: simion --nogui fly
      ../examples/tof/tof.iob

    > Recommending support windows-like links (*.lnk shortcut files),
    > not the soft/hard-links as in *nix, to allow PAs and IOBs to be
    > in different directories.  We have some big models on our
    > network share and currently have to copy them for every new
    > project we make.  This should also work across drives.
    > --thomasb -- http://www.simion.com/discuss/viewtopic?p=2144

      .

  Reported by jasons - 20060918, theo - 20060922 / 20061016, danr - 20061213.

  Affects: 7.0 and 8.0.
  To resolve in 8.0.x.
  Partly resolved in 8.0.5-TEST17 (Issue I220.3)
  To fully resolve by 8.1 if not earlier (review before 8.0.5 final release)