On 10 Oct 2011, at 18:54, Erik Schnetter wrote:

On Sun, Oct 9, 2011 at 7:39 PM, Luca Baiotti <baiotti@ile.osaka-u.ac.jp> wrote:
Hello,

I was looking into the param.ccl of CarpetIOASCII (hg version) and found
some deprecated parameters:

BOOLEAN out3D_ghosts "Output ghost zones (DEPRECATED)"
{
} "yes"


BOOLEAN out3D_outer_ghosts "Output outer boundary zones (assuming that
there are nghostzones boundary points (DEPRECATED)"
{
} "yes"

In what sense are they deprecated? I don't do 3D ASCII output, but I
think that setting the above parameters to "no" would be better (see
also below).

These are deprecated because they do not calculate the number of ghost
zones correctly; they make some assumptions that hold in many cases,
but may either output ghost zones or not output real grid points in
some cases.

Furthermore,

BOOLEAN out1D_d "Do output along the diagonal" STEERABLE = ALWAYS
{
} "yes"

should also default to no, I suggest.


Finally, I would also make the default of:

BOOLEAN output_ghost_points "Output ghost points"
{
} "yes"

to "no". This would also make the script
CarpetIOASCII/src/util/Carpet2ygraph.pl
work again (see other message about Carpet2ygraph.pl in this mailing list).
Except for debugging, is there any advantage in outputting ghost zones?

That is correct, one only wants to look at ghost zones for debugging.
Do you want to open a TRAC request, or suggest this again after the
release? Carpet is now certainly mature enough so that debugging
output does not need to be the default any more.

The relevant TRAC ticket is https://trac.einsteintoolkit.org/ticket/677.

Here are my 2 pence:

* Parameters which have been deprecated for a while should be removed now, and not changed, unless they are in fact routinely used, and the deprecation status should be changed;

* If we are going to change the default behaviour, we should also consider fixing the parameters to do a sensible thing;

* This output is useful not only for debugging Carpet, but also for debugging user thorns. 

* If possible, I would avoid a change which needed the test suites to be regenerated, unless someone is willing to commit time to doing this carefully.  This will likely affect the majority of tests in not only the ET but also in groups' private repositories.  I think that changing something as fundamental as this might be unreasonable.  The test suites should output these points anyway to catch regressions.  The test suite parameter files could be modified to handle the change of defaults, and this is much preferable to regenerating the data.