-
Notifications
You must be signed in to change notification settings - Fork 189
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
FindHorizon.py: also compute horizon quantities #6024
Conversation
dd08192
to
2e4234f
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.
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
src/PointwiseFunctions/GeneralRelativity/Surfaces/Python/Bindings.cpp
Outdated
Show resolved
Hide resolved
tnsr::ii<DataVector, Dim, Frame> spatial_metric, | ||
tnsr::II<DataVector, Dim, Frame> inv_spatial_metric, |
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.
What about only requiring the inv_spatial_metric
and just compute the determinant_and_inverse
here? That way less data needs to be output
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.
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?
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.
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)
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.
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.
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.
Yeah we can worry about them later. I do think people will want to have the option though.
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.
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).
requested_quantity + | ||
"' is not available."); |
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.
Print the available quantities.
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.
Ping on this.
3ccc9a1
to
41913a7
Compare
tnsr::ii<DataVector, Dim, Frame> spatial_metric, | ||
tnsr::II<DataVector, Dim, Frame> inv_spatial_metric, |
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.
Yeah we can worry about them later. I do think people will want to have the option though.
requested_quantity + | ||
"' is not available."); |
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.
Ping on this.
if output: | ||
assert output_coeffs_subfile or output_coords_subfile, ( |
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.
Can you add an .h5
extension to the output if there isn't one already? Ran into this today.
gr::surfaces::Tags::DimensionlessSpinMagnitudeCompute<Frame>, | ||
gr::surfaces::Tags::DimensionlessSpinVectorCompute<Frame, Frame>>; |
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.
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 double
s. 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.
7e51107
to
9978ee4
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.
Fixups look good. Squash
9978ee4
to
698b16a
Compare
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:Code review checklist
make doc
to generate the documentation locally intoBUILD_DIR/docs/html
.Then open
index.html
.code review guide.
bugfix
ornew feature
if appropriate.Further comments