[ET Trac] [Einstein Toolkit] #1651: Problems with expansions in parameter files

[Einstein Toolkit]

#1651: Problems with expansions in parameter files
---------------------+------------------------------------------------------
  Reporter:  hinder  |       Owner:  sbrandt            
      Type:  defect  |      Status:  accepted           
  Priority:  major   |   Milestone:                     
 Component:  Cactus  |     Version:  development version
Resolution:          |    Keywords:                     
---------------------+------------------------------------------------------

Comment (by rhaas):

 I agree that complete order independence lets me use an editors 'find'
 function. My example was not a good one.

 I still don't like usage patterns like this though:
 {{{
 C = A
 ...lots of other stuff...
 A = B
 }}}
 Mostly for two reasons:
  1. Cactus parameters always have values, so C = A is valid even without A
 = B anywhere in the file. So, to me, having to read the whole file (rather
 than only the part above) to find out which of the two possible values of
 A is going to be used is unusual. Basically since all parameters in Cactus
 start out having values, parfiles always '''change''' parameters rather
 than '''set''' them. Order independence would seem to make more sense if
 all assignments are required.
  1. I am very commonly asked to review parameter files that are about to
 run (or to debug them). I start reading them from the bottom and continue
 to the end. If the order is completely free then for each assignment I
 have to search to the bottom of the file to find the possible value of the
 parameter. If parameters cannot be set after they have been read, I can
 rely on having seen any such change in the part of the file that I have
 just read.

 Ian's example also contains magic in the case of order independence. In
 that case both
 {{{
 C=A
 A=B
 }}}
 and
 {{{
 C=A
 }}}
 are valid and also C would change its value from 'B' in the first case to
 the default of 'A' in the second. It's possible to remove the magic by
 requiring and "read" variable to have been "set" before. On the technical
 side, this needs to be an option for the expression parser so that
 parameters can be used in expressions that are not in parfile line righ-
 hand-sides (eg for the Trigger thorn or in accumulators).

 However it seems to me that both Ian and I have stated out preferences,
 which differ and that it may be best to get some second opinion on the
 matter.

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