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

FindHorizon.py: also compute horizon quantities #6024

Merged
merged 7 commits into from
Jun 7, 2024

Conversation

nilsvu
Copy link
Member

@nilsvu nilsvu commented May 24, 2024

Proposed changes

This allows to get the horizon area, mass, spin, etc from BBH initial data just by calling a Python function.

Upgrade instructions

The FindHorizons3D executable was removed. You can find horizons in 3D volume data in Python like this:

from spectre.Pipelines.Bbh.FindHorizon import find_horizon
from spectre.SphericalHarmonics import Strahlkorper

horizon, quantities = find_horizon(
    h5_files, subfile_name, obs_id, obs_time,
    initial_guess=Strahlkorper(l_max, m_max, radius, center)
)

mass = quantities["ChristodoulouMass"]
spin = quantities["DimensionlessSpinMagnitude"]

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 added the cli/pybindings Command line interface & Python bindings label May 24, 2024
@nilsvu nilsvu added this to the BBH Pipeline Automation milestone May 24, 2024
@nilsvu nilsvu force-pushed the id_horizon_quantities branch 2 times, most recently from dd08192 to 2e4234f Compare May 24, 2024 19:03
@nilsvu nilsvu changed the title FindHorizons.py: also compute horizon quantities FindHorizon.py: also compute horizon quantities May 24, 2024
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.

Add in the upgrade instructions that the FindHorizon exec was removed and that the preferred method for finding horizons in data on disk is the CLI now

Comment on lines +26 to +28
tnsr::ii<DataVector, Dim, Frame> spatial_metric,
tnsr::II<DataVector, Dim, Frame> inv_spatial_metric,
Copy link
Contributor

Choose a reason for hiding this comment

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

What about only requiring the inv_spatial_metric and just compute the determinant_and_inverse here? That way less data needs to be output

Copy link
Member Author

@nilsvu nilsvu May 29, 2024

Choose a reason for hiding this comment

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

The spatial metric is in the output anyway because we load it as initial data. I could drop the inv_spatial_metric from the volume data and compute it here. But the horizon finder needs the inv_spatial_metric, so it would have to compute the inverse in every iteration of the horizon finder. Not sure what's best, so I think just keep as is for now?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm just worried we are making assumptions about what will be available when we don't necessarily know. Yes for the ID solve we'll have the spatial metric, but what about for a BNS run where somebody wants to see if a horizon formed? Or a supernova bounce? What about taking both as optionals? Then if both are available, you can just use both, but if one or the other are specified then you'll have to compute the inverse (you'd be doing it in volume data anyways)

Copy link
Member Author

Choose a reason for hiding this comment

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

Can we worry about these applications later? You can always use spectre transform-vol to compute the inverse and other quantities. I could do the optionals but that adds quite a lot of logic that I'm not sure is needed and I think is premature optimization.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah we can worry about them later. I do think people will want to have the option though.

Copy link
Member Author

@nilsvu nilsvu May 30, 2024

Choose a reason for hiding this comment

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

Yes, we want to find horizons in evolution output data. Note that we also have to output ExtrinsicCurvature, spatial Christoffels, and the spatial Ricci tensor, which we probably don't do atm. So we either have to output those (lots of data), or postprocess with transform-vol (possible, maybe best solution and works already, see #6071), or build the postprocessing into the horizon finder routines (possible, except for numerical derivatives), or have more flexible horizon finder triggers in the evolution (hopefully enabled by interpolation framework changes, but doesn't help if you already have the simulation output).

Comment on lines 64 to 65
requested_quantity +
"' is not available.");
Copy link
Contributor

Choose a reason for hiding this comment

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

Print the available quantities.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ping on this.

@nilsvu nilsvu force-pushed the id_horizon_quantities branch 2 times, most recently from 3ccc9a1 to 41913a7 Compare May 29, 2024 02:03
Comment on lines +26 to +28
tnsr::ii<DataVector, Dim, Frame> spatial_metric,
tnsr::II<DataVector, Dim, Frame> inv_spatial_metric,
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah we can worry about them later. I do think people will want to have the option though.

Comment on lines 64 to 65
requested_quantity +
"' is not available.");
Copy link
Contributor

Choose a reason for hiding this comment

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

Ping on this.

Comment on lines 198 to 199
if output:
assert output_coeffs_subfile or output_coords_subfile, (
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add an .h5 extension to the output if there isn't one already? Ran into this today.

Comment on lines 44 to 45
gr::surfaces::Tags::DimensionlessSpinMagnitudeCompute<Frame>,
gr::surfaces::Tags::DimensionlessSpinVectorCompute<Frame, Frame>>;
Copy link
Contributor

Choose a reason for hiding this comment

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

Damn. This was my bad. I forgot that this tag list is used in the ObserveTimeSeriesOnSurface callback, and that requires the types of all tags it observes to be doubles. I roughly know how to generalize this, but haven't had a chance to implement it. So you can't add the compute tag here, but you can just append it to the list in the pybinding cpp.

@nilsvu nilsvu force-pushed the id_horizon_quantities branch 2 times, most recently from 7e51107 to 9978ee4 Compare June 3, 2024 19:41
@nilsvu nilsvu requested a review from knelli2 June 5, 2024 21:41
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.

Fixups look good. Squash

@nilsvu nilsvu merged commit 68c226b into sxs-collaboration:develop Jun 7, 2024
22 checks passed
@nilsvu nilsvu deleted the id_horizon_quantities branch June 18, 2024 23:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli/pybindings Command line interface & Python bindings
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants