SIMION 8.0 Issues/Bugs/Enhancements

Filter issues by query:

IssueI220 [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)