#473: Add support for parameter file scripts --------------------------+------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by hinder):
The parameter script is first run, and SimFactory's @...@ variables are expanded in the resulting file. It would be slightly cleaner for this to happen in the opposite order, but it would break compatibility with a huge number of parameter file scripts at the AEI which have to escape the @s in @WALLTIME_HOURS@ with a backslash. We could add a temporary workaround which dealt with this if we decided that expanding in the script was better.
At the moment, I only support the case where a script generates a single parameter file. This has the advantage of having a 1-1 mapping between scripts and simulations. This is good because the simulation name is conveniently derived from the script name. It is also a disadvantage, as it means that I need N scripts when I do N resolutions in a convergence test, which currently leads to a lot of copy commands and manual editing.
One method which would work with the current patch is to create a symbolic link to the script for each resolution that you want to run. The script could determine which resolution to run from the name it is invoked with. e.g. you could have bbh_24.rpar, bbh_28.rpar, bbh_32.rpar as your symbolic links to bbh.rpar, and bbh.rpar looks at $0 to determine "n", which it uses to set the required number of grid points.
Another method would be to have a "variant" option to simfactory. This would be a string passed on the "sim create" command line which would be expanded using @VARIANT@ in the parameter file. This would need the expansion to happen in the script rather than in the generated file though. The script could then look at the value of @VARIANT@ and decide how to interpret it. The simulation name could have @VARIANT@ appended by default, when it is derived from the parameter file. For example,
sim create-submit --variant 24 par/bbh.rpar 256 24:00:00
would give a simulation called "bbh_24" and @VARIANT@ would be expanded as "24" in the script. Alternatively, the variant string could be passed as an argument to the script, rather than using the substitution method.