[Users] simfactory (python): small requests

[Luca Baiotti]

On 19/9/11 3:31 PM, Ian Hinder wrote:
>
> 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?

Yes, that is correct, Ian.

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

It should be --submitscript, but otherwise it worked. Thanks.

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

Without any -o option, the stdout should be placed in the directory 
where the executable is run. Or at least this happens when submitting 
jobs without simfactory.

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

OK

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

Done.

Best,
Luca