[Users] Error to write PittNull during checkpointing

Bela Szilagyi bela at caltech.edu
Mon Jul 30 10:47:14 CDT 2012


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
>
> --
> Dr. Yosef Zlochower
> Center for Computational Relativity and Gravitation
> Assistant Professor
> School of Mathematical Sciences
> Rochester Institute of Technology
> 85 Lomb Memorial Drive
> Rochester, NY 14623
>
> Office:74-2067
> Phone: +1 585-475-6103
>
> yosef at astro.rit.edu
>
> CONFIDENTIALITY NOTE: The information transmitted, including
> attachments, is intended only for the person(s) or entity to which it
> is addressed and may contain confidential and/or privileged material.
> Any review, retransmission, dissemination or other use of, or taking
> of any action in reliance upon this information by persons or entities
> other than the intended recipient is prohibited. If you received this
> in error, please contact the sender and destroy any copies of this
> information.
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>


More information about the Users mailing list