[ET Trac] [Einstein Toolkit] #1595: Is *) allowed as upper boundary for a parameter range?
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Thu May 28 02:33:48 CDT 2015
#1595: Is *) allowed as upper boundary for a parameter range?
-----------------------+----------------------------------------------------
Reporter: eschnett | Owner: sbrandt
Type: defect | Status: assigned
Priority: minor | Milestone: ET_2015_05
Component: Cactus | Version: development version
Resolution: | Keywords: postrelease
-----------------------+----------------------------------------------------
Comment (by rhaas):
> Quoted strings are widely used in the ET. Even making it a warning to
use them will generate a ton of > output.
I am not worried about quoted ''strings'' (in fact we advertise using
quotes for them) I am worried about surrounding the ranges (which are a
set of numbers) by quotes and we forbid surrounding numbers by quotes for
parameter values, ie:
{{{
Cactus::cctk_final_time = "10.0"
}}}
is invalid and produces
{{{
WARNING level 0 from host t1650-403463.aei.mpg.de process 0
while executing schedule bin (none), routine (no thorn)::(no routine)
in thorn Cactus, file tov.par:66:
-> Invalid assignment: Attempting to set a variable of type REAL with
(STRING)"10.0"
}}}
> I wasn't introducing ":", that was already supported and used. See, for
example, ADMMass, CartGrid3D, > etc.
Oh joy. Those entries are not my favorite parameter declarations :-). We
will have to continue to support it (and the usage is actually backed up
by the documentation it seems).
> Good point about the "::". That has to be avoided. However, it seems it
was caught earlier on. The
> match never sees it.
Well I would suspect that the range of type:
{{{
1::2 "blah"
}}}
gets split into a range of '1' and a description of '2 "blah"'. Eg setting
{{{
REAL xmin "Coordinate minimum in x-direction"
{
:: :: "Anything"
} -1.0
}}}
gives
{{{
CST error 1:
-> Description of range for parameter xmin has misplaced quotes ( ::
"Anything") in param.ccl for thorn CartGrid3D
}}}
> The regex doesn't need to handle a single star or number, because that's
also handled by code prior to > this line.
ok, just wanted to make sure.
> I think we can make this an error instead of a warning. The ET passes
with the above expression.
It always did (or at least has done so since we introduced the warning),
Ian's concern seems to be for third party thorns.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1595#comment:19>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list