[Users] PARAMCHECK and non fatal but inefficient parameter choices

Erik Schnetter schnetter at cct.lsu.edu
Wed May 7 17:18:56 CDT 2014


People often ignore warnings.

Since there is no point in using "higher order restriction" with vertex centring, one can assume this is an oversight. I would abort the simulation to keep things simple.

Alternatively, one could ignore this parameter for vertex centring.

-erik

On May 7, 2014, at 18:08 , Roland Haas <rhaas at tapir.caltech.edu> wrote:

> Signed PGP part
> Hello all,
> 
> the PARAMCHECK routines normally abort if inconsistent parameters are
> given. I have a situation where the parameter choice is valid and the
> result of the simulation should be identical with or without the
> parameter set (assuming not bugs...), however setting the parameter is
> likely going to make the simulation slower.
> 
> Im this particular case the parameter is
> CarpetLib::use_higher_order_restriction when used for a run with
> Carpet::refinement_centering = "vertex". In that case restriction is
> just a copy operation and independent of use_higher_order_restriction,
> for cell-centered runs this is not true anymore and this is the
> situation that use_higher_order_restriction was implemented for.
> 
> However there is code in Carpet/Evolve.cc that calls POSTREGRID
> multiple times if use_higher_order_restriction is set (it has to in
> order to get symmetry, outer boundaries and also ghost zones right).
> 
> For vertex centering nothing should happen (since there is a second
> call to POSTRESTRICT after all restriction is done).
> 
> Options are:
> 
> * do nothing since these parameters are perfectly valid if slow
> * warn with level CCTK_WARN_COMPLAIN ("the user should know about this
> but the problem is not terribly surprising")
> * warn with level CCTK_WARN_ALERT ("the results of this run will be
> wrong, and this will surprise the user, but we can still continue the
> run")
> * abort since the user most likely did not want to set the parameter
> 
> Note that current practise in most code seems to be to use
> CCTK_WARN_COMPLAIN (Level 1) for warnings about situations that do not
> invalidate the result and CCTK_WARN_ABORT (Level 0) for anything that
> invalidates results, ie. we do not adhere to the meaning of the levels
> documented in src/include/cctk_WarnLevel.h .
> 
> Yours,
> Roland
> 
> --
> My email is as private as my paper mail. I therefore support encrypting
> and signing email messages. Get my PGP key from http://keys.gnupg.net.
> 
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users

-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu/.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20140507/2dd8d229/attachment.bin 


More information about the Users mailing list