Skip to content
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

Find apparent horizon in distorted frame #4720

Merged
merged 5 commits into from Feb 24, 2023

Conversation

markscheel
Copy link
Contributor

@markscheel markscheel commented Feb 10, 2023

Proposed changes

Two main changes:

  • compute_dest_vars_from_src_vars now recognizes distorted frame, so interpolation can be done in that frame.
  • Test_ApparentHorizonFinder now has a test where it finds the horizon in the distorted frame.

Other necessary changes are fixing a bug in UniformTranslation and adding instantiations of the distorted frame in many places.

Code review checklist

  • The code is documented and the documentation renders correctly. Run
    make doc to generate the documentation locally into BUILD_DIR/docs/html.
    Then open index.html.
  • The code follows the stylistic and code quality guidelines listed in the
    code review guide.
  • The PR lists upgrade instructions and is labeled bugfix or
    new feature if appropriate.

@markscheel markscheel marked this pull request as draft February 10, 2023 15:41
@markscheel markscheel force-pushed the AhFinderTest branch 2 times, most recently from 67d684f to be39103 Compare February 10, 2023 17:34
@markscheel markscheel changed the title AhFinder test: enable distorted frame but do not use it. Find apparent horizon in distorted frame Feb 10, 2023
@markscheel markscheel marked this pull request as ready for review February 10, 2023 17:38
@knelli2 knelli2 self-requested a review February 11, 2023 01:13
Copy link
Contributor

@knelli2 knelli2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can squash directly

Comment on lines 700 to 701
functions_of_time),
InterpolationTarget_detail::evaluate_temporal_id_for_expiration(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this not InterpolationTarget_detail::get_temporal_id_value? I know it's used above, but looking at the two functions, they are identical for all types except TimeStepId. The difference is that get_temporal_id does TimeStepId.substep_time().value() while evaluate_temporal_id_for_expiration does TimeStepId.step_time().value(). They are different, but does that matter here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good question. evaluate_temporal_id_for_expiration is used in the code for the other frames too, and I thought that was what @wthrowe wanted. @wthrowe should I be using get_temporal_id_value here (and for the other frames) instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably _value, but first, do you get any failures if you put ASSERT(time_id.substep() == 0, "Interpolating on substep " << time_id); in both get_temporal_id_* functions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wthrowe all the tests pass if I put those ASSERTs into both functions. Should evaluate_temporal_id_for_expiration be removed, and only get_temporal_id_value used everywhere? (and should I keep the ASSERT?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So at the moment, the functions always return the same value. I'm not sure I want to guarantee that that will always be true, though. If I remember right, this is only used during self start, which is only used for AdamsBashforth which doesn't have substeps. Predictor-corrector methods will presumably go through a similar infrastructure with substeps, though.

I don't really remember what's going on here. Why are there two of these? The _value function is presumably to represent the time (or iteration or whatever) to use in maps and such. What is the _expiration for? My first thought was we needed something monotonic, but it isn't monotonic. (Can these things get some documentation?)

Copy link
Contributor

@knelli2 knelli2 Feb 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both of these were added in #3421. It seems that evaluate_temporal_id_for_expiration was added because previously, VerifyTemporalIdsAndSendPoints.hpp used pending_id.step_time().value(). Whereas, get_temporal_id_value was added because ObserveTimeSeriesOnSurface.hpp used temporal_id.substep_time().value(). (take a look at the first commit of that PR)

So we needed one that got the step_time and the other that got the substep_time. However, I'm not sure if we need to use one or the other in each circumstance. I agree with @wthrowe that _value seems to just get the current time, but unclear what _expiration is actually needed for.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking more closely, I don't think any of the uses of step_time() here are correct. (Uses of step_time() outside time-related code are usually wrong.) So just get rid of that function and probably rename the other one to get rid of the now-unnecessary disambiguator.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I will keep the one using substep_time() and remove the other one. Should I leave the ASSERT in there?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I say yes. It's just an ASSERT so won't affect productions stuff

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. I intend to add valid cases where it will fail.

nilsvu
nilsvu previously approved these changes Feb 17, 2023
@markscheel
Copy link
Contributor Author

squashed.

knelli2
knelli2 previously approved these changes Feb 17, 2023
@nilsvu nilsvu requested a review from wthrowe February 18, 2023 19:04
nilsvu
nilsvu previously approved these changes Feb 18, 2023
@nilsdeppe
Copy link
Member

@wthrowe did you want to look at the part you were involved in discussing for this PR?

@@ -5,6 +5,7 @@

#include "DataStructures/LinkedMessageId.hpp"
#include "Time/TimeStepId.hpp"
#include "Utilities/ErrorHandling/Assert.hpp"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup still there

It did not include all the maps it needed to.
This is a bug fix that should have been done when
distorted frame was added to UniformTranslation.
Do this for many classes.
@markscheel
Copy link
Contributor Author

Removed include, rebased and fixed conflict.

@wthrowe
Copy link
Member

wthrowe commented Feb 22, 2023

Er, try again? It's still there.

@@ -5,6 +5,7 @@

#include "DataStructures/LinkedMessageId.hpp"
#include "Time/TimeStepId.hpp"
#include "Utilities/ErrorHandling/Assert.hpp"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup still there

Instead, use get_temporal_id_value.
@markscheel
Copy link
Contributor Author

Hopefully the include is gone now... sorry..

Copy link
Contributor

@knelli2 knelli2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup! Gone now!

@nilsdeppe nilsdeppe merged commit 37d7710 into sxs-collaboration:develop Feb 24, 2023
@markscheel markscheel deleted the AhFinderTest branch February 27, 2023 18:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants