[ET Trac] [Einstein Toolkit] #114: per-variable tolerances for Cactus testsuites

[Einstein Toolkit]

#114: per-variable tolerances for Cactus testsuites
--------------------------+-------------------------------------------------
  Reporter:  knarf        |       Owner:  tbode 
      Type:  enhancement  |      Status:  review
  Priority:  major        |   Milestone:        
 Component:  Cactus       |     Version:        
Resolution:               |    Keywords:        
--------------------------+-------------------------------------------------

Comment (by rhaas):

 I looked at the patches again. The very latest patch has an issue where it
 seems to pick the second matching (non-'.*') pattern instead of the first
 one. Another thing that I found confusing is that the order of the regex
 (ie. which is first, second etc) is determined by sorting the regular
 expressions alphabetically (not eg. the order in which the patterns appear
 in the file).

 Tanja promised an updated patch for the first issue. For the second: this
 seems to be completely avoidable if we only allow a single (non-'.*')
 match which should not be too hard to construct. If one really ever needs
 something like:
 {{{
 g[xyz][xyz]\..\.asc 1e-9
 g[xyz][xyz]\.d\.asc 1e-8
 }}}
 Then one can simply change the first pattern to
 {{{g[xyz][xyz]\.[xyz]\.asc}}}. This might yield a number of warnings if a
 new pattern is added that conflicts with existing ones but that seems
 preferable to having a new pattern silently overwriting existing ones. The
 uniqueness requirement means that it is sufficient to find the single
 matching pattern when creating new entries rather than having to
 understand all patterns to deduce their applicability. Implementing an
 order based on the order of which the patterns appear in test.ccl is
 annoyingly complicated (unless one uses a third party module Tie::IxHash
 which Tanja found) since hashes in Perl do not preserve the order in which
 entries were added. So for now I would suggest we go with Tanja's initial
 implementation that only allows a single match (beyond '.*') and then if
 and when we encounter a situation like then one Frank described in comment
 8 someone can go back and add this option without breaking backwards
 compatibility. It would seem good to me to have some implementation ready
 well before the next release so that we have time to test it.

 So: please apply (the patch looks good) with the second vs. first issue
 fixed and maybe even with the original uniqueness requirement.

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