-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add iterative scheme to worldtube #5855
Conversation
b265111
to
b669469
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also please fix the clang-tidy errors
if (db::get<Tags::CurrentIteration>(box) < | ||
db::get<Tags::MaxIterations>(box) - 1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this logic just go in IteratePunctureField
instead? I think it makes more sense for IteratePunctureField
to be the one to increase the current_iteration
and determine if it actually needs to compute another iteration of the puncture field or go to BCs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I had originally but I think this way is better because it automatically handles the cases where MaxIterations
is equal to 0 (geodesic) or 1 and the IteratePunctureField
and IterateAccelerationTerms
actions are skipped entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh I see. I guess I was a bit confused because checking the iterations didn't seem related to sending data to the worldtube. But the beginning of the iterate actions can determine if an iteration needs to happen or not. I don't have a strong opinion on this so I'll defer to you.
src/Evolution/Systems/CurvedScalarWave/Worldtube/SingletonActions/ReceiveElementData.hpp
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Squash
if (db::get<Tags::CurrentIteration>(box) < | ||
db::get<Tags::MaxIterations>(box) - 1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh I see. I guess I was a bit confused because checking the iterations didn't seem related to sending data to the worldtube. But the beginning of the iterate actions can determine if an iteration needs to happen or not. I don't have a strong opinion on this so I'll defer to you.
@knelli2 thanks, I decided to leave the iteration decision as is. I noticed that I forgot to actually use the iterated puncture field which I addressed in another fixup commit if you would like to take a look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. There are a couple more clang-tidy errors, so you can squash those in as well.
Ignoring unrelated test failure |
Adds the iterative scheme to the worldtube, as described in section V A of https://arxiv.org/abs/2403.08864.
The worldtube sends the updated acceleration to the adjacent elements which use it to compute the updated puncture field and then the updated regular field. This is send back to the worldtube and used to update the acceleration which can be repeated an arbitrary number of times. An action test of this iterative scheme is included.
depends on #5847