[Users] simfactory run sub-options

Roland Haas roland.haas at physics.gatech.edu
Tue May 1 10:57:52 CDT 2012

Hello Erik,

> No, the --recover option should not be necessary unless you want to
> recover from a particular restart.
Thank you. That is good to know.

> The "sim run" command is supposed to look at what actions "sim submit"
> did, and perform those that are missing. This includes creating the
> directory structure. I don't expect this to be well tested. Linking to
> checkpoint files cannot be done by "sim submit", so it is always "sim
> run" that does this.

> You seem to be intending to chain jobs together. I assume you are
> aware that Simfactory already offers a facility for this? This would
> submit several the jobs simultaneously with respective dependencies.
> You can also pre-submit more jobs to extend this chain. Thus "sim
> submit" instead of "qsub" should do the same thing, and/or you can
> also run the "sim submit" from the command line (adding, say, ten more
> restarts) if needed.
I am using presubmission for other jobs (though it has been fragile
occasionally in not finding checkpoints and not warning about it, but I
am not quite sure how I triggered it. It's one of those "magic" things
that almost always work it seems unless one does something unexpected.).

I cannot use the presubmission facility straightforwardly (I believe)
since I currently lump a number of independent simulations into a single
queue item (to get a bit of higher run priority on kraken due to the
higher core count).

The simplest way right now seems to use "sim submit ... --mdbkey=submit
'/bin/bash @SCRIPTFILE@ &'" in my qsub script to start all
sub-simulations which means I can simply re-use the very same qsub
script again at the end after waiting for all simulations to finish.

> The logic that triggers pre-submission is that you require more wall
> time than the queue limit. In this case, the job is broken into
> several restarts.
It also happens if I submit a job to to a simulation that is already in
queue or running, does it not? Or would I explicitly have to add a
--presubmit (or similar) flag to the submit sub-command?


> PS: I hope that my description above does not deviate too much from reality.
Well I can always try and see how reality compares to the design
specifications. Any difference is a bug in the specifications...

-------------- 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/20120501/0a525d5a/attachment.bin 

More information about the Users mailing list