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