If you consider the location to be machine dependent, then it should be part of Simfactory. Simfactory should set this environment variable as specified in its mdb. This will allow your collaborators/students to use the same setup as you, without you having to explain them how to set up their accounts on the various machines you are using.
If you don't think that modifying .bashrc is a problem, then modifying kraken.sub shouldn't be much of a problem either. (Version control systems are good at managing small local changes.)
Alternatively, if you think that Simfactory should help, then you could e.g. source ~/.bashrc in kraken.run -- this would solve similar problems as well. Or you can introduce a file ~/.environment that is sourced by both ~/.bashrc and by kraken.run.
You could also augment Simfactory's MDB to have a notion of a "read-only input data directory" for each machine. Lorene data would go there, and other input data as well. (One could argue that $sourcebasedir is a good location for this, but I believe there are systems where $sourcebasedir is not accessible from compute nodes.) Lorene's input data would be located in $inputdir/$name, where $name is specified in the parameter file (e.g. "Lorene/BNS-08-15").
If you do the latter, then extending the "sync" command to sync the input data directory (or a portion thereof) would also make sense.
-erik
2012/2/22 Frank Loeffler knarf@cct.lsu.edu:
Hi,
On Wed, Feb 22, 2012 at 01:35:42PM -0500, Erik Schnetter wrote:
Shouldn't the location of the initial data be in the parameter file?
The location of the initial data is system-dependent, while the parameter file should not.
Either this, or it should be compiled into the executable (similar to the location of a shared library).
It should be possible to set that location at start time. The current mechanism does that: it instructs Cactus to look at an environment variable. For most cases it would work to compile this in, but that would mean to recompile to change just this, where a recompilation isn't strictly necessary and could be avoided.
Frank
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJPRTcGAAoJEOkzpip+I59kQmwP/iYBaZm/5Wq8yIrTY8ouG3uQ SD9gZAkx3c5CqFCJPJIKFmS0QQYj0MLEWJxl7B7+/cCBYA5aZts0hSq9uAmn/ToB AIqZ1goKvdEE61/36FDGYR9MFEIM77+Pyk0djxksmMCE7CwieGJSB7TIPwDU3O+C QNX6trxKD46wswU+cGNKsfpc3STWuVnAlEzbEgrImBdQOo54SrFi2hP0U70v72Xc 0QlT6t9qxoBg7myKGJBDnqOMWjdPqhTgj9jhoMYpt3+bywl/rQY1Nzzug7Z6Be2I pPRHaXAY6t5ZFZiGM6u/CEKCFG/Aj5/rwRv2/u+KTIHbICgcOfUTwbmHSWbdxV5I y9QffiIsL9JrfJfh/sJia7NEiQn9uLvjd7JFFd+eTh81dyJRp9X/WfMtfMBbVG2o OiTlc9oyTI0SBwSKQxBomLl6lIZqy+jxxYikZufGEItztUKqOxLqnG0xX8NjzfWf Sqp8ESqopsHC9BZs4l2ZlQVGZwG6pBpl4xttd1UoDlPzfMztTCzjo4pKdWI6Cjlr +gjdX5KsQLLtiezzDcw/eZmlK36Doyy2sr83NOFzb6qLhBPxZsNOkYZqwcEq/rPn dJCv0muiXdIaxLfPQCc+dY5MuajywWiDEijIorfiKl4HQOQDGU9yrIsO/8VziFdT CUpNczGpuTN2PGASj3QA =XfGh -----END PGP SIGNATURE-----