[Users] Error to write PittNull during checkpointing

[Bela Szilagyi]

The 1st order accuracy is yet another story.  Part of it may be induced by the news code itself but understanding and fixing this will need more effort. 

Sent from my iPhone

On Jul 30, 2012, at 8:51 AM, Yosef Zlochower <yosef at astro.rit.edu> wrote:

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