[Carpet] expensive logging of CarpetRegrid[2] parameter changes

[Ian Hinder]

Bela Szilagyi wrote:
> Erik,
> 
> On Wednesday 07 November 2007 17:43:27 Erik Schnetter wrote:
>>> instead of steerable parameters ?
>> I found in the past that using parameter steering during simulations  
>> does not work.  There are two main problems.  The first is that there  
>> is no machine-readable output about parameter values, and the other  
>> is that parameter settings are often overwritten during recovery.  I  
>> have therefore already implemented such grid scalars, and these grid  
>> scalars are used by other thorns, e.g. CarpetTracker.  The parameters  
>> are only used during initialisation.
> 
> The steerable parameter interface for CarpetRegrid DOES work for me.  Why do 
> you want to disable it?  I often hit various problems with CarpetTracker / 
> CarpetRegrid2 and just find it easier to use the interface I built to 
> CarpetRegrid.  You can argue that should I find a problem with CarpetRegrid2 
> I should either fix it or complain about it.  But that is much more 
> time-expensive than to use existing software that works with my thorns.
> 
> 
>> I will remove the STEERABLE tags, since they are now outdated.
> 
> Then I'll have to remember not to update Carpet.

I agree with Bela - we use the CarpetRegrid::coordinates parameter to
determine the grid structure throughout the run.  I believe Uli also
uses this.  This works fine for us - please don't remove the
functionality!

I don't understand the comment about the parameter values being
overwritten during recovery.  If a parameter is steerable, it should be
checkpointed and recovered just like a grid scalar.  What is the problem
here?

-- 
Ian Hinder
hinder at gravity.psu.edu
http://www.gravity.psu.edu/~hinder