[Carpet] CCTK_TraverseString: invalid group/variable name
Luca Baiotti
baiotti at ea.c.u-tokyo.ac.jp
Fri Feb 29 07:36:53 CET 2008
Erik,
I am aware of the problem of different users having different wishes and
I don't think that the default solution can be good for everyone.
Indeed, I would suggest to add parameters for CarpetIO* to specify the
warning level. There are other level 1 warnings which I don't care
about, like
WARNING level 1 in thorn IOUtil processor 28 host node0017.admin
(line 599 of
/data1/baiotti/Cactus/configs/belladonna_NoDebug/build/IOUtil/CheckpointRecovery.c):
-> Recovery directory
'/data20/baiotti/Meudon-45km-5lev-dx.25_noRefBoundInStar_IF/checkpoint'
doesn't exist
(because I was setting recovery to autoprobe).
Did I convince you?
Luca
Erik Schnetter wrote:
> Luca,
>
> people's opinions on whether a simulation should output a warning or
> should abort when a problem is detected differs greatly. Personally, I
> prefer simulations to abort as early as possible if there is an error,
> but it would not be appropriate to impose this opinion onto others.
>
> Cactus has the notion of an "error level", which is the severest warning
> level which is accepted before the simulation aborts. It defaults to
> zero. If you set it to one, the simulation would abort on this error.
>
> Alternatively, you can write stdout and stderr to different files. If
> you check stderr of your simulations regularly, then you will detect
> these problems. If you find that the stderr file is too large, then we
> need to change this, because only severe problems should be reported
> there. Sometimes Cactus repeats the same error message multiple times
> in there, which is not useful and buries the real errors.
>
> I would prefer to have these generic mechanisms work. If they don't
> work, then we could introduce parameters into every thorn letting people
> choose the warning level of its messages. However, that wouldn't solve
> the problem that Cactus should do something sensible by default.
>
> -erik
More information about the developers
mailing list