[Users] using PBS -V on kraken

[Erik Schnetter]

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 at 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-----
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/