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

Add functionality to Ylm IO #5921

Merged
merged 3 commits into from
Apr 19, 2024

Conversation

knelli2
Copy link
Contributor

@knelli2 knelli2 commented Apr 18, 2024

Proposed changes

This is the first of 3 PRs to allow reading horizon coefficients from a file into the shape map coefficients in a domain creator. This PR just factors out a function into a more accessible part of the code and adds the ability to read Ylm coefs at a specific time from a file.

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

iter.reset();

// Where max_l is larger than strahlkorper.l_max()
{
Copy link
Member

Choose a reason for hiding this comment

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

[optional] My understanding is that the goal of this function is that the output is effectively a prolonged version of the input strahlkorper to the requested l_max. If so, a simpler test for this part would be to check that fill_ylm_legend_and_data(strahkorper, larger_l_max) and fill_ylm_legend_and_data(Strahlkorper(larger_l_max, larger_l_max, strahkorper), larger_l_max) give the same result.

* \param time Time to read the coefficients at.
* \param epsilon How much error is allowed when looking for a specific time.
* This is useful so users don't have to know the specific time to machine
* precision.
Copy link
Member

Choose a reason for hiding this comment

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

What is the expected use case where the caller doesn't know the exact time?

Mention that epsilon is a relative error, possibly by renaming it to indicate that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Say I've been dumping data every 0.5M and I want to read it it at time 123.5M. However, the actual time of the output is something like 123.499999999999748. The epsilon accounts for this. The rename sounds like a good idea though

nilsvu
nilsvu previously approved these changes Apr 18, 2024
@knelli2
Copy link
Contributor Author

knelli2 commented Apr 19, 2024

@wthrowe pushed fixups

@wthrowe
Copy link
Member

wthrowe commented Apr 19, 2024

OK. Squash and rebase.

@wthrowe wthrowe merged commit 5b6dac1 into sxs-collaboration:develop Apr 19, 2024
22 checks passed
@knelli2 knelli2 added this to the BBH evolve through ringdown milestone Apr 22, 2024
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.

3 participants