Yosef,
I have made several attempts to commit the changes, over the course of the past couple of months. Somehow every time I figure out how to re-download the code from the latest incarnation of the repository, I figure I no longer have write access or no longer know my password or some combination of the above. This simply because I am not an active Cactus user.
I had asked Roland to just push these changes as they are essential for the correctness of the code. If you rely on me finding the time to figure out how to (re-)gain checking access to these thorns, this will delay the application of the patches by further months.
The start-up related change could be logged as
Improve the start-up algorithm of the characteristic marching scheme from the inner boundary towards scri+.
All other changes are related to either improving IO (will correctly truncate/create diagnostic files) or allowing for flexible tuning of IO between checkpoints/restarts (by changing the parameters into steerable ones).
I'd like to ask that someone with working write access to the arrangement apply the patches.
Bela.
On Mon, Jul 30, 2012 at 12:05 PM, Yosef Zlochower yosef@astro.rit.edu wrote:
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 et al, It would probably be a good idea to have some kind of informative commit message. Since you checked that these changes are correct and necessary, can you commit them? I'll then update the testsuite, if needed.
Bela.