<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 19 Sep 2011, at 02:59, Luca Baiotti wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hello I have some other small questions and requests on simfactory.<br><br>1) I would like the name of the simulation and the output directory to <br>be different. (The name of the simulation should be short in order to be <br>meaningful (visible in the queueing system) while the name of the output <br>directory can be long, in order to properly describe its content.)<br>Is this possible?<br></div></blockquote><div><br></div><div>The name of the simulation is the name of the simulation directory - this will not change. &nbsp;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. &nbsp;SimFactory creates output directories &lt;simname&gt;/output-NNNN in which the Cactus process is run. &nbsp;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). &nbsp;I that that what you want is for the job name to be shortened while leaving everything else the same. &nbsp;Is that correct?</div><div><br></div><blockquote type="cite"><div>2) I would like to have a single file containing both sdtout and stderr <br>from the job. I tried to insert<br>#$ -j y<br>into simfactory/mdb/submitscripts/ranger-intel11.sub (which is what I am <br>using) and to remove the lines<br><br>#$ -o @RUNDIR@/@SIMULATION_NAME@.out<br>#$ -e @RUNDIR@/@SIMULATION_NAME@.err<br><br>but this didn't sort the wanted effect (i.e. the stdout and stderr are <br>still in separate files). How can I achieve this?<br></div></blockquote><div><br></div><div>From reading the qsub man page, you probably want to leave the -o setting so that it knows where to put the output file. &nbsp;I haven't tried this, but it looks like if you do that it should work. &nbsp;However, one problem with SimFactory is that it doesn't usually take any notice of modifications to configuration files until you tell it to. &nbsp;After modifying the submission script, you need to run the build command, re-specifying the scriptfile:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>sim build.... --scriptfile ranger-intel11.sub</div><div><br></div><div>This is because simfactory considers the submission script to be a part of the configuration. &nbsp;Did you do this? &nbsp;If not, it was probably using the old script file. &nbsp;You can find out what scriptfile was used by looking in the file &lt;sim&gt;/output-0000/SIMFACTORY/SubmitScript.</div><div><br></div><blockquote type="cite"><div>3) How can one change the default warning level in the cactus run (the <br>simfactory default is -L 3)?<br></div></blockquote><div><br></div><div>There is a ticket about this:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span><a href="https://trac.einsteintoolkit.org/ticket/447">https://trac.einsteintoolkit.org/ticket/447</a></div><div><br></div><div>(It refers to simfactory 1 but applies also to simfactory 2). &nbsp;The only way to change this is to modify the run script within simfactory. &nbsp;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. &nbsp;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. &nbsp;When debugging problems, the fewer possible configuration options that have to be checked, the easier it is to debug. &nbsp;Of course, if lots of people disagree, this feature could probably be implemented. &nbsp;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.</div><br><blockquote type="cite"><div>4) For some reason (maximum core count exceeded), my job was rejected <br>from the queueing system, so it never started and I received no <br>notification email, and I was wondering what happened. Then I realised <br>that actually the line "Submit finished, job id is 212....." was not <br>printed by simfactory. Instead of simply not printing the final line, <br>could simfactory print an error message in this case?<br></div></blockquote><div><br></div><div>It absolutely should. &nbsp;Please could you open a ticket for this?&nbsp;</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span><a href="https://trac.einsteintoolkit.org/newticket">https://trac.einsteintoolkit.org/newticket</a></div><div><br></div><div>Thanks.</div><div><br></div><div>PS: cross-posted to simfactory mailing list&nbsp;<a href="https://mail.cct.lsu.edu/mailman/listinfo/simfactory">https://mail.cct.lsu.edu/mailman/listinfo/simfactory</a>.</div><div><br></div></div><div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 12px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--&nbsp;</div><div>Ian Hinder</div><div><a href="mailto:ian.hinder@aei.mpg.de">ian.hinder@aei.mpg.de</a></div></div></div>
</div>
<br></body></html>