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@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@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@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users