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 ADM Mass / Spin and Extrapolation to Infinity #121

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

TaigoFr
Copy link
Member

@TaigoFr TaigoFr commented May 6, 2020

Addition of a class ADMMass that calculates the ADM mass and spin of a spacetime, together with a class ADMMassExtraction that extracts the corresponding variables.

This partially solves #90 , and will have to be changed once diagnostics are added. #90 also includes the Kretschmann scalar and such variables, but that's in my opinion a feature to be added separately.

This PR also includes Extrapolation to infinity of first and second order. First order is in Alcubierre. Second order I wrote some notes about it, as I didn't find it elsewhere and made the computation myself. Second order (requires 3 radii to cancel leading terms of order 1/r AND 1/r^2) greatly improves the result, so it must be correct.

I added this extraction to the Kerr example, as it's a neat place for it to be. For a Kerr BH with Mass=1.0 and Spin=0.3 I managed to get in my laptop a quick extraction that with 2nd order extraction to infinity results in M=1.0000609955 and a=0.29994697676, which looks pretty good to me. I used N=64, L=128, extraction radii at r = (30. 40. 50.) at levels (1 1 0). The simpson method of @mirenradia's SurfaceExtraction also greatly helps this. Other methods (except for boole rule) or first order extraction get slightly worse results, but still converge.

ADM extraction has some ambiguity in terms of what factors of chi should be added. In principle it doesn't matter. I tested that indeed it doesn't matter much, once extrapolation is done. So I added them trying to follow standard calculations, but it is open for review.

@TaigoFr TaigoFr requested review from KAClough and mirenradia May 6, 2020 19:24
@mirenradia mirenradia added the feature New feature label May 7, 2020
@KAClough
Copy link
Member

This is also very nice! Especially nice to have the extrapolation of the quantities to infinity output automatically.

A few minor comments which I will put in the code.

if (m_p.activate_extraction == 1)
{
// Populate the Weyl Scalar values on the grid
fillAllGhosts();
Copy link
Member

Choose a reason for hiding this comment

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

Comment should say Madm not Weyl.

I have always thought that filling the Weyl/Madm data on every level post timestep is quite inefficient. This is especially true here when we only actually use it every coarse or second to coarse timestep.

Perhaps we could do something like
if(m_time % extraction_dt == 0) {calculate diagnostics}
I think the modulo thing is usually non trivial as you have to check to numerical precision. Having a small function in GRAMRLevel that returns true if m_time is a multiple of dt for a given level would be quite useful generally, and could then be used here.

This can be filed as an issue if you don't want to do it now :-)

Copy link
Member Author

@TaigoFr TaigoFr May 13, 2020

Choose a reason for hiding this comment

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

A quick alternative is to just move it to inside the following if(m_level == m_p.extraction_params.min_extraction_level()) no? Like that it is only calculated on the moments we want output. I'm not sure this is the same as what you wanted, let me know.
EDIT: ignore this silly comment. This does not work.

Copy link
Member

Choose a reason for hiding this comment

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

Careful @TaigoFr, you want the BoxLoops::loop called on all levels, not just the extraction level.

Copy link
Member Author

Choose a reason for hiding this comment

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

I realized that and edited my comment. I solved it in the last commit. It's a solution that is stable under numerical perturbations.

Copy link
Member

Choose a reason for hiding this comment

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

Nice fix :-)
Can we also add it to BinaryBHLevel::specificPostTimeStep()? It probably doesn't save us much, but it annoys me that we calculate Weyl on every level timestep.

@KAClough
Copy link
Member

Subject to the small change I suggested for amending the BBH example I'm happy with this, @mirenradia are you?

@mirenradia
Copy link
Member

I will make a full review at some point but my main comment at the moment is that I think the code for ADM angular momentum should be separated out from the code for the ADM mass (and their respective extraction classes) and ChomboParameters::variable_names_to_enum shouldn't be used to check for this (especially in a compute class where performance is important).

@mirenradia
Copy link
Member

Now that #119 is merged, we should make these diagnostic variables.

@KAClough
Copy link
Member

KAClough commented Aug 4, 2020

I am wondering pedantically about the "ADMMass" name. It also includes the angular momentum, so I think that as Miren suggests this could be separated out, or it could become ADMQuantities or ADMMetrics or some other name which makes it sound more general. I would also like to add the ADM Momentum in some specified direction (doesn't have to be now, but maybe this influences how we solve this issue).

Apart from this (and potential merge conflicts with the other PRs) I think it looks great.

@KAClough KAClough marked this pull request as draft October 23, 2020 13:27
@TaigoFr
Copy link
Member Author

TaigoFr commented Jan 12, 2021

I changed the name from ADMMass to ADMQuantities. I think it's best to not separate the mass and momentum calculations, as they involve the common calculation of the normal dS. Since now the mass and momentum diagnostic components are specified in the constructor and defaulted to "don't calculate" (a_c_Madm = -1, int a_c_Jadm = -1), it's hopefully good enough.
Updated to the most recent code as well.

@mirenradia
Copy link
Member

Can it be made possible for the user to select (via a parameter) which radii to use for the extrapolation?

@TaigoFr TaigoFr force-pushed the feature/adm_mass branch 3 times, most recently from f468bfa to 4a60c40 Compare January 19, 2021 17:27
Base automatically changed from master to main January 21, 2021 16:42
TaigoFr added 7 commits March 17, 2021 17:42
Add Richardson Extrapolation to Infinity
In BinaryBH Example, calculate Weyl only on the minimum extraction level full cycles
Allow the user to extract only the ADM mass without adding the spin as a variable
…r storage

(more like the style of Miren's NewConstraints class)
@TaigoFr TaigoFr marked this pull request as ready for review March 17, 2021 18:21
TaigoFr added 4 commits March 26, 2021 18:33
# Conflicts:
#	Examples/KerrBH/params.txt
#	Examples/KerrBH/params_cheap.txt
#	Source/AMRInterpolator/SurfaceExtraction.hpp
#	Source/GRChomboCore/SimulationParametersBase.hpp
Copy link
Member

@mirenradia mirenradia left a comment

Choose a reason for hiding this comment

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

Thanks for adding this code and sorry for the long delay in reviewing.

Would it be possible to add the Richardson extrapolation in a new write_xxx function e.g. SurfaceExtraction::write_integrals_and_extrapolate rather than hacking it into the existing function?

{
CH_TIME("KerrBHLevel::specificPostTimeStep");
// Do the extraction on the min extraction level
if (m_p.activate_extraction == 1)
Copy link
Member

Choose a reason for hiding this comment

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

Pretty sure you corrected this elsewhere.

Suggested change
if (m_p.activate_extraction == 1)
if (m_p.activate_extraction)

@@ -29,6 +29,8 @@ class SimulationParameters : public SimulationParametersBase
pp.load("kerr_mass", kerr_params.mass);
pp.load("kerr_spin", kerr_params.spin);
pp.load("kerr_center", kerr_params.center, center);

pp.load("activate_extraction", activate_extraction, false);
Copy link
Member

Choose a reason for hiding this comment

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

Might as well use the one in SimulationParametersBase

@@ -51,6 +53,7 @@ class SimulationParameters : public SimulationParametersBase
}

KerrBH::params_t kerr_params;
bool activate_extraction;
Copy link
Member

Choose a reason for hiding this comment

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

(as above)

@@ -118,7 +119,7 @@ max_steps = 4
# Spatial derivative order (only affects CCZ4 RHS)
max_spatial_derivative_order = 4 # can be 4 or 6

nan_check = 1
# nan_check = 1
Copy link
Member

Choose a reason for hiding this comment

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

Why?

int min_extraction_level()
{
return *(std::min_element(extraction_levels.begin(),
extraction_levels.end()));
}

//! deletes invalid or repeated
void validate_extrapolation_radii();
Copy link
Member

Choose a reason for hiding this comment

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

Can we do this via parameter checking instead? This will make it more transparent to the user.

Comment on lines +183 to +184
extraction_extrapolation_order = 3
extraction_extrapolation_radii = 0 1 2
Copy link
Member

Choose a reason for hiding this comment

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

Can't extrapolate Weyl4 as time is not retarded.

# 2 2

# integral_file_prefix = "Weyl4_mode_"

Copy link
Member

Choose a reason for hiding this comment

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

Can you add the extrapolation parameters here (even if just commented out)?

Comment on lines +165 to +167
pp.load("extraction_extrapolation_radii",
extraction_params.radii_idxs_for_extrapolation,
extrapolation_order);
Copy link
Member

Choose a reason for hiding this comment

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

Can we provide the actual radii rather than the radii indices? This can then be checked with parameter checking so that you're not requesting extrapolation from a radii you're not actually extracting on.

Comment on lines +83 to +86
Madm += dS_L[i] / (16. * M_PI * m_G_Newton) /
(vars.chi * sqrt(vars.chi)) * h_UU[j][k] * h_UU[i][l] *
(vars.chi * (d1.h[l][k][j] - d1.h[j][k][l]) -
(vars.h[l][k] * d1.chi[j] - vars.h[j][k] * d1.chi[l]));
Copy link
Member

Choose a reason for hiding this comment

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

Maybe add a reference for these formulae as a comment e.g. Baumgarte and Shapiro p85 Eq. (3.128)?

Comment on lines +104 to +113
Jadm += -dS_L[i] / (8. * M_PI * m_G_Newton) *
epsilon[m_dir][j][k] * x[j] * vars.K *
TensorAlgebra::delta(i, k);

FOR(l, m)
{
Jadm += dS_L[i] / (8. * M_PI * m_G_Newton) *
epsilon[m_dir][j][k] * x[j] * h_UU[i][l] *
h_UU[k][m] * vars.chi *
(vars.A[l][m] + vars.K * vars.h[l][m] / 3.);
Copy link
Member

Choose a reason for hiding this comment

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

Add a reference e.g. Baumgarte and Shapiro p95 Eq. (3.191).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants