[ET Trac] [Einstein Toolkit] #473: Add support for parameter file scripts

[Einstein Toolkit]

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

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/473#comment:3>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit