[Users] Error to write PittNull during checkpointing

[Yosef Zlochower]

Bela,

  Does this patch fix the O(h) error we saw in the CCE paper?
I think this patch was missing. Can you submit it?


On 07/30/2012 11:47 AM, Bela Szilagyi wrote:
> Yosef, and all
>
> 'start-up' here refers to the way the null parallelogram algorithm
> (marching out along a characteristic slice and starting from the inner
> boundary), gets its integration constants set by the boundary data.
> This is not a t=0 issue, but rather a \lambda=0 issue in CCE language.
>      I believe it is absolutely essential for the correctness of the
> code.
>
> As far as changing parameters from non-steerable to steerable goes, I
> also believe they are useful as one can legitimately want to start a
> new diagnostic for a run when restarted from a particular checkpoint.
> Or even from the middle of a run, checkpointed or not.  Those are,
> indeed, independent from the 'start-up' patch.
>
> I do understand that the Einstein Toolkit maintenance team may not be
> familiar with the Pitt code. Please regard the 'start-up' patch as an
> amendment to the 1st release of the code, by those same people who
> worked on it before releasing it.  If  you need any details of why
> have I changed things in the particular way I have, I will be glad to
> explain.
>
> Bela.
>
> On Mon, Jul 30, 2012 at 6:12 AM, Yosef Zlochower<yosef at astro.rit.edu>  wrote:
>> On 07/30/2012 02:22 AM, Christian Reisswig wrote:
>>>> Hello Yosef,
>>>>
>>>>>> Are all of them there? I didn't see a patch for the
>>>>>> SphericalHarmonicDecomp, Recomp
>>>>>> codes?
>>>>
>>>> They are all I have. There were patches to Christian Reisswig's
>>>> SphericalHarmonicReconASCII in incoming. Since then the thorn has
>>>> changed names to SphericalHarmonicReconGen. Unfortunately I don't think
>>>> any of these will help with a run that produces faulty output from
>>>> Cactus (since the input to CCE for Caltech came from SpEC).
>>>
>>> I believe the most important patch is the one that fixes a problem with the
>>> start-up algorithm at the worldtube.
>>> None of the patches affects the SphericalHarmonicRecon/Decomp thorns.
>>>
>>
>> I looked through the patches and I don't see where the start-up
>> algorithm is modified. Also there are these two changes that I am not
>> sure about. The first changes the algorithm in the middle of a run.
>> The second changes the meaning of the "time" in the output file.
>> My guess is that a typical user wouldn't want to do either of these.
>> Someone doing a test, could modify the param.ccl themselves.
>>
>>
>> -BOOLEAN first_order_scheme "should angular derviatives be reduced to
>> first order?"
>> +BOOLEAN first_order_scheme "should angular derviatives be reduced to
>> first order?" STEERABLE=ALWAYS
>>
>> -BOOLEAN interp_to_constant_uBondi "Interpolate quantities at Scri to
>> constant Bondi time"
>> +BOOLEAN interp_to_constant_uBondi "Interpolate quantities at Scri to
>> constant Bondi time" STEERABLE=ALWAYS
>>
>>> Indeed, at Caltech, we are using SphericalHarmonicReconGen (formerly
>>> SphericalHarmonicReconASCII) which can read the data from the SpEC code.
>>> This thorn should be located in the incoming directory and I hope it can make
>>> it to the next release.
>>>
>>> So I believe your problems will not be fixed by the changes listed in ticket
>>> 991.
>>>
>>> cheers,
>>> Christian
>>> _______________________________________________
>>> Users mailing list
>>> Users at einsteintoolkit.org
>>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>