Hello Christoph,
Actually, the "mpiexec" command can be parametrized in the code_saturne post-installation step, by editing <install_prefix>/etc/code_saturne.cfg, so adaptation to SLURM is not an issue.
Other than that, most of the optional command-line arguments to cs_solver are probably not useful in an "ensemble" run such as when using Melissa..
These options include "--proprocess" and "--quality" for a mesh check mode only, but these are used to check mesh quality beforehand, so may be useful before running with Melissa, but probably not with Melissa.
The only options which might be useful is " --sig-defaults" if you need to replace the code_saturne signal handler with the default ones (for example to generate a core file instead of a backtrace), and "--wdir <path>" to force the working directory (in case the mpiexec/srun/ or equivalent command does not handle it). "The "--mpi" option can also be used to force MPI initialization if no known MPI environment variable indicating that we are undeer MPI is detected by code_saturne.
All information relative to the user physical and numerical setup is passed throuhg setup.xml, which has a fixed nam so does not need to be specified (at least not since code_saturne 6.0), or through user-defined functions.
In all cases, these are related more to the run environment than to the case setup, so for an "external" launch, it is probably simpler not to bother with Python at all, even at a high level, and just build your "mpiexec" or equivalent command around the "./cs_solver" executable.
If "cs_solver" is not present in the working directory, it means there are no user-defined sources at all and the default executable (<install_prefix>/libexec/code_saturne/cs_solver on mist systems, with libexec replaced by "bin" or "lib" on some systems such as OpenSUSE).
So since this is basically the only precaution needed, I can add a high-level python wrapper to check that, but simply testing the presence of cs_solver in the working directory is sufficient (and if you do not want to bother, if there is no file in a case's SRC, you may still have generated code, and you can even force things by adding an empty or default (reference) cs_user_parameters.c file in SRC.
For the working directory, you have two possibilities:
- You did not specify an directory when running "code_saturne run --initialize".
in that case, you are stuck, as you have no idea od the directory used (actuallly, the default is YYYY-MM-DD, but if you launch several cases in quick succession, _1, _2, ... etc is added to avoid reusing an existing directory).
- You specified a run id using "code_saturne run --initialize --id <run_id>".
In this case, the execution directory is under CASE/RESU/<run_id>, or when running coupled cases, under RESU_COUPLING/<run_id>/CASE.
You can use a high level "code_saturne run --sugest-id" to obtain a run id suggestion (based on YYYY-MM-DD) before running the case if you have no idea of which run id to provide, but in parametric cases, generating a run id based on the parameters combination seems like a cleaner option.
If some parts of this are not clear, do not hesitate to ask me to clarify.
Thanks also for the remark on the unused "app_id". I'll clean that up soon.
Best regards,
Yvan