[Users] Error to write PittNull during checkpointing

Yosef Zlochower yosef at astro.rit.edu
Mon Jul 30 10:58:15 CDT 2012


On 07/30/2012 11:54 AM, Roland Haas wrote:
> Hello Yosef,
>
>> 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.
> It seems as if the patches were mixed up somehow (though just how that
> happened is a mystery to me, given that it is just a svn diff inside of
> a bash for loop). Anyhow. I have updated the patches on the trac ticket
> and now one (NullEvolve) actually has non-trivial code changes. There
> are now to 1 and 2 byte patch files since I cannot seem to remove
> attachments, only replace them.
>
>> 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.
> Can you point out which change this is, please?
>

This would happen if you steer the parameter "interp_to_constant_uBond"
during a run. If this is set to no, the output files contain
spherical harmonics of the News (etc) at fixed code time (and the label
may be off by 1/2 dt). If it's switched to yes, then the same files
would contain the harmonics calculated on a fixed bondi time.



>> -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
> These are the ones that allow changing the algorithm in the middle of
> arun? Or is the first_order_scheme the one that changes algorithm and
> the Bondi time one the one that changes output time?
>
> I usually promote the viewpoint that parameters should be as steerable
> as possible without breaking the code, even if a means that a user can
> ruin their data by unwise parameter changes (rather than just unwise
> parameter settings). maybe being able to steer this parameter at least
> during recovery is useful for some debugging runs?
>
> Yours,
> Roland
>
>
>
>
> _______________________________________________
> 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.


More information about the Users mailing list