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

[Erik Schnetter]

On Nov 7, 2007, at 11:23:28, Ian Hinder wrote:

> 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?

The problem appears if you set these parameters explicitly in the  
parameter file which you use for recovering.  Many people use the  
same parameter file for the initial submission and for recovering,  
and in this case, you overwrite the stored parameters and change the  
grid structure.

Things work somewhat if you ensure that you don't regrid right after  
recovery, but instead you only re-run the routine which determines  
the grid structure, overwriting all pertinent parameters.  In this  
way, you end up with a self-consistent grid structure, but the grid  
structure after recovering can be slightly different than before, and  
this can be inconvenient.

I am speaking of CarpetRegrid2 here.  I am not suggesting to change  
CarpetRegrid.  CarpetRegrid2 does not even check the parameters  
during evolution, which is what I meant with "outdated": you can  
steer CarpetRegrid2's parameters, but this won't have any effect.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/developers/attachments/20071107/0ab32841/attachment.pgp