[Users] using PBS -V on kraken

Roland Haas roland.haas at physics.gatech.edu
Wed Feb 22 15:58:38 CST 2012


Hello all,

> 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.
Having a @DATADIR@ (or similar) directive does seem to make sense. It
could point to either a project directory or $WORK or if nothing else is
available $SCRATCH.

> 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.)
Well yes. Part of the question was whether to propagate my (local)
change to kraken.sub to trunk. It seems as if this is not favoured solution.

> 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.
Doable I think (and what SpEC does). It would have the definite
advantage of working for any use of $ENV{'...'} rather than just
$INITIAL_DATA. The disadvantage is that -- unless I make a copy of the
environment file at submimsion time -- a simulation directory is no
longer self contained (using -V it is, since it makes copy of the
current env settings).

> 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.)
Yes. Kraken is one those I think ($HOME is not visible, not sure about
the projects directories).

> If you do the latter, then extending the "sync" command to sync the
> input data directory (or a portion thereof) would also make sense.
Thank you all for your suggestions.

So consensus seems to "be nice" and not do what NICS says not to do.
I'll play around with the solutions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20120222/9a1af5a2/attachment.bin 


More information about the Users mailing list