[ET Trac] [Einstein Toolkit] #114: per-variable tolerances for Cactus testsuites
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Sun Sep 25 16:04:03 CDT 2011
#114: per-variable tolerances for Cactus testsuites
--------------------------+-------------------------------------------------
Reporter: knarf | Owner: tbode
Type: enhancement | Status: review
Priority: major | Milestone: ET_2011_11
Component: Cactus | Version:
Resolution: | Keywords:
--------------------------+-------------------------------------------------
Comment (by tbode):
Thanks for looking at the patch.
* Concerning debugging code, the only debugging left uncommented is in
PrintDataBase, which is in there specifically ''for'' debugging and only
for debugging. This should be left in there so that the database printing
routine descends one step lower in the hierarchy, giving useful
information instead of just the reference to the hash. There is a
PrintDataBase call in RunTest.pl that is commented out. If we don't want
any commented debugging, this should also be deleted. If we want no
debugging at all committed, that entire function should be removed.
* I fully expected a complaint concerning the keywords. Easily changed.
Long all-caps really annoy me so I prefer not to use it while coding.
Search and replace are sufficient. I apologize for having left the case is
is. Figured there would be enough discussion concerning functionality that
there would be changes anyway. I didn't think of a better choice for the
keyword, though, that wasn't absurdly long or misleading.
* I implemented it as an extra keyword as it was easier to parse the lines
this way, and specifying the expression first and tolerance second makes
more sense to me as a user. Changing how ABSTOL and RELTOL are specified
would outdate all current test.ccl files and would be a much more invasive
change. I could put in extra loops of logic to treat both old and new
cases. I should think on this some more, whether there is a good way to
handle this, but I prefer a second keyword.
The interface in the patch ''does'' allow any number of expressions to be
specified at either level. Where it falls short is in logic when a file
matches more than one expression. Currently any test tolerances override
thorn-wide tolerances, and expression-specific tolerances blindly override
all other tolerances. If it matches more than one expression, though,
it's only the last match's tolerance that is used. How should we treat
cases where a filename matches more than one expression? I'm inclining
towards throwing an error if this happens indicating that test.ccl should
be modified.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/114#comment:5>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list