[Users] simfactory (python): small requests

[Ian Hinder]

On 19 Sep 2011, at 02:59, Luca Baiotti wrote:

> Hello I have some other small questions and requests on simfactory.
> 
> 1) I would like the name of the simulation and the output directory to 
> be different. (The name of the simulation should be short in order to be 
> meaningful (visible in the queueing system) while the name of the output 
> directory can be long, in order to properly describe its content.)
> Is this possible?

The name of the simulation is the name of the simulation directory - this will not change.  The simulation makes use of jobs in the queing system - the names of these jobs doesn't matter to simfactory, so it would be possible to specify a job name to simfactory, but this is not implemented.  SimFactory creates output directories <simname>/output-NNNN in which the Cactus process is run.  Cactus is usually run such that it creates an output directory in the current directory named after the parameter file (e.g. by setting the parameter IO::out_dir = $parfile).  I that that what you want is for the job name to be shortened while leaving everything else the same.  Is that correct?

> 2) I would like to have a single file containing both sdtout and stderr 
> from the job. I tried to insert
> #$ -j y
> into simfactory/mdb/submitscripts/ranger-intel11.sub (which is what I am 
> using) and to remove the lines
> 
> #$ -o @RUNDIR@/@SIMULATION_NAME at .out
> #$ -e @RUNDIR@/@SIMULATION_NAME at .err
> 
> but this didn't sort the wanted effect (i.e. the stdout and stderr are 
> still in separate files). How can I achieve this?

From reading the qsub man page, you probably want to leave the -o setting so that it knows where to put the output file.  I haven't tried this, but it looks like if you do that it should work.  However, one problem with SimFactory is that it doesn't usually take any notice of modifications to configuration files until you tell it to.  After modifying the submission script, you need to run the build command, re-specifying the scriptfile:

	sim build.... --scriptfile ranger-intel11.sub

This is because simfactory considers the submission script to be a part of the configuration.  Did you do this?  If not, it was probably using the old script file.  You can find out what scriptfile was used by looking in the file <sim>/output-0000/SIMFACTORY/SubmitScript.

> 3) How can one change the default warning level in the cactus run (the 
> simfactory default is -L 3)?

There is a ticket about this:

	https://trac.einsteintoolkit.org/ticket/447

(It refers to simfactory 1 but applies also to simfactory 2).  The only way to change this is to modify the run script within simfactory.  One could think about adding an extra option to your defs.local.ini called cactus-options which was a set of extra options which were passed to the cactus executable.  Erik would say that the point of simfactory is not to provide the most flexibility, but to ensure ease-of-use, correctness, repeatability, and predictability.  When debugging problems, the fewer possible configuration options that have to be checked, the easier it is to debug.  Of course, if lots of people disagree, this feature could probably be implemented.  I also happen to think that -L 3 is a sensible setting to use for production runs, and that the source of the warnings should eventually be fixed.

> 4) For some reason (maximum core count exceeded), my job was rejected 
> from the queueing system, so it never started and I received no 
> notification email, and I was wondering what happened. Then I realised 
> that actually the line "Submit finished, job id is 212....." was not 
> printed by simfactory. Instead of simply not printing the final line, 
> could simfactory print an error message in this case?

It absolutely should.  Please could you open a ticket for this? 

	https://trac.einsteintoolkit.org/newticket

Thanks.

PS: cross-posted to simfactory mailing list https://mail.cct.lsu.edu/mailman/listinfo/simfactory.

-- 
Ian Hinder
ian.hinder at aei.mpg.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20110919/135ab281/attachment.html