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

Exporter: allow extrapolation into excisions #6056

Merged
merged 2 commits into from
Jul 22, 2024

Conversation

nilsvu
Copy link
Member

@nilsvu nilsvu commented Jun 3, 2024

Proposed changes

This is needed to fill the excision region with (non-constraint-satisfying) data so it can be imported into moving puncture codes.

Upgrade instructions

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.

Further comments

@nilsvu nilsvu force-pushed the extrapolate_excisions branch 4 times, most recently from e8dd821 to 25febf1 Compare June 6, 2024 16:12
Copy link
Member

@wthrowe wthrowe left a comment

Choose a reason for hiding this comment

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

Exporter test failed on one of the CI jobs.

const double radial_distance_this_block =
x_logical->get(direction.dimension()) * direction.sign();
if (radial_distance_this_block < 1.) {
continue;
Copy link
Member

Choose a reason for hiding this comment

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

If I follow the logic correctly, if we hit this case the point is not inside the excision sphere. Should that be an error or an early return?

* The point will be reported to belong to one of the blocks that abut the
* excision sphere and will have a logical coordinate outside the range [-1, 1]
* in the radial direction. This is useful for extrapolating data into excision
* regions.
Copy link
Member

Choose a reason for hiding this comment

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

What happens if input_point is not inside excision_sphere? Either document the result or state it is considered invalid to call the function in that case.

continue;
}
// The checks above should leave only 1 valid block, so return that
return make_id_pair(domain::BlockId(block_id),
Copy link
Member

Choose a reason for hiding this comment

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

Could there be two valid blocks for points on the extrapolation of the boundary between two blocks into the sphere? The blocks are being pulled from an unordered container, so always choosing the first one isn't deterministic.

for (size_t s = 0; s < block_logical_coords->size(); ++s) {
auto& block_logical_coord = (*block_logical_coords)[s];
// Process only points inside the excision sphere. These points were found
// by `block_logical_coordinates` above, have a radial logical coordinate
Copy link
Member

Choose a reason for hiding this comment

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

block_logical_coordinates doesn't appear anywhere above.

* \cite Etienne2008re adjusted for distorted excisions: we choose uniformly
* spaced radial anchor points spaced as $\Delta r = 0.3 r_\mathrm{AH}$ in the
* grid frame (where the excision is spherical), then map the anchor points to
* the distorted frame (where we have the target point) and do a 7th order
Copy link
Member

Choose a reason for hiding this comment

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

The code has constexpr size_t extrapolation_order = 8;

@nilsvu
Copy link
Member Author

nilsvu commented Jun 18, 2024

Thanks for your review @wthrowe! I pushed a fixup.

@nilsvu nilsvu requested a review from wthrowe June 24, 2024 18:05
@nilsvu
Copy link
Member Author

nilsvu commented Jun 24, 2024

I'm investigating the NaNs in some of the unit tests, but the fixup is ready for your review @wthrowe

// range [-1, 1]
// range [-1, 1]. Also discard if the point is on the upper angular face of
// the block, to disambiguate which of the two blocks sharing the face the
// point is in.
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't work. The blocks don't have aligned frames, so some interfaces are two lower sides or two upper sides.

* the distorted frame (where we have the target point) and do a 7th order
* polynomial extrapolation into the excision region.
* the distorted frame (where we have the target point) and do a polynomial
* extrapolation into the excision region.
Copy link
Member

Choose a reason for hiding this comment

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

Is it 8th order or not?

Copy link
Member Author

@nilsvu nilsvu Jul 11, 2024

Choose a reason for hiding this comment

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

It's a 7th order polynomial with 8 collocation points. However in the polynomial_interpolation function the name order is degree + 1, so I used that naming here as well:


To avoid confusion I renamed to num_extrapolation_anchors.

@nilsvu
Copy link
Member Author

nilsvu commented Jul 19, 2024

@wthrowe I pushed a new fixup. I dropped the changes to BlockLogicalCoordinates.*pp and instead determine if the target point is inside an excision in the distorted frame. I think this is more robust and addresses your comments above.

@wthrowe
Copy link
Member

wthrowe commented Jul 19, 2024

OK, looks good. Squash and fix the clang-tidy complaint.

This can be useful to fill the excision region with
(non-constraint-satisfying) data so it can be imported into
moving puncture codes.
@wthrowe
Copy link
Member

wthrowe commented Jul 19, 2024

@nilsvu I filed a CI failure as #6168 and I'm rerunning it as I'm guessing it's unrelated to this change. Do you agree with that guess?

Edit: (The gcc-11 Release failure is obviously unrelated so I'm ignoring it.)

@nilsvu
Copy link
Member Author

nilsvu commented Jul 19, 2024

I don't see a connection 🤷‍♂️

Copy link
Member

@wthrowe wthrowe left a comment

Choose a reason for hiding this comment

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

Sounds good. Let's let the rerun finish, but feel free to merge once that's done (or I'll do it later, but I'm leaving for the day soon).

@nilsvu nilsvu merged commit 24ff7ea into sxs-collaboration:develop Jul 22, 2024
21 of 22 checks passed
@nilsvu nilsvu deleted the extrapolate_excisions branch July 22, 2024 07:43
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.

2 participants