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 m1 analytic data & couple GreyM1 to fixed hydro #6453

Open
wants to merge 6 commits into
base: develop
Choose a base branch
from

Conversation

pajkosmi
Copy link
Contributor

Proposed changes

This PR adds the homogeneous sphere GreyM1 test problem, couples the fluid to a fixed hydro background, and allows the user to specify the M1Grey initial data in the yaml 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

@pajkosmi pajkosmi added the new feature Adds a new feature that's worth highlighting in release notes label Jan 24, 2025
@pajkosmi pajkosmi marked this pull request as ready for review January 24, 2025 17:59
@pajkosmi pajkosmi requested a review from wthrowe January 24, 2025 17:59
@pajkosmi pajkosmi changed the title Add m1 analytic data & couple hydro to fixed hydro Add m1 analytic data & couple GreyM1 to fixed hydro Jan 24, 2025
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.

Haven't looked through the entirety of the second commit yet, because it has 1600+ lines of changes. It looks like it's doing several things (updating the executable, reorganizing the boundary conditions, adding new analytic data). Are they separate enough that they could be split into separate commits, at least for review purposes?

@@ -11,6 +11,7 @@
#include "DataStructures/Tensor/EagerMath/RaiseOrLowerIndex.hpp"
#include "DataStructures/Tensor/Tensor.hpp"
#include "DataStructures/Variables.hpp"
#include "M1HydroCoupling.hpp"
Copy link
Member

Choose a reason for hiding this comment

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

Full path.

const Scalar<DataVector>& lorentz,
const Scalar<DataVector>& sqrt_det_spatial_metric

) {
Copy link
Member

Choose a reason for hiding this comment

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

Formatting.

const Scalar<DataVector>& lorentz,
const Scalar<DataVector>& sqrt_det_spatial_metric

) {
Copy link
Member

Choose a reason for hiding this comment

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

Formatting.

tmpl::pair<evolution::initial_data::InitialData, initial_data_list>,
tmpl::pair<ImexTimeStepper, TimeSteppers::imex_time_steppers>,

Copy link
Member

Choose a reason for hiding this comment

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

Fixing the alphabetization is good, but we generally use POSIX sorting where all lowercase letters are after all uppercase, so this should put evolution::initial_data::InitialData at the end.

@@ -108,6 +108,7 @@ struct TimeDerivativeTerms {
extrinsic_curvature, spatial_metric, emissivity, absorption_opacity,
scattering_opacity, tilde_j, tilde_h_normal, tilde_h_spatial,
spatial_velocity, lorentz, sqrt_det_spatial_metric));
return {true};
Copy link
Member

Choose a reason for hiding this comment

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

Squash into appropriate commit.

@pajkosmi
Copy link
Contributor Author

Haven't looked through the entirety of the second commit yet, because it has 1600+ lines of changes. It looks like it's doing several things (updating the executable, reorganizing the boundary conditions, adding new analytic data). Are they separate enough that they could be split into separate commits, at least for review purposes?

I'll do some more reorganizing later this week. Are you ok if I split into commits that don't independently compile, and then squash them together at the end of review?

@wthrowe
Copy link
Member

wthrowe commented Jan 28, 2025

Yes, if it's too interconnected the split can be just during the review.

@pajkosmi pajkosmi force-pushed the add_M1_analytic_data branch 2 times, most recently from 7c24d0a to 3ba9bdd Compare January 29, 2025 23:08
@pajkosmi pajkosmi force-pushed the add_M1_analytic_data branch from 3ba9bdd to 6cae38e Compare January 29, 2025 23:22
@pajkosmi
Copy link
Contributor Author

ping, I have reorganized the commits.

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.

Thank you, much less daunting split up like that.

const double sharpness = -0.03;
return Scalar<DataVector>{
(inner_value - outer_value) / M_PI *
atan((sqrt(square(x)) - sphere_radius) / sharpness) +
Copy link
Member

Choose a reason for hiding this comment

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

sqrt(square(x)) -> x (this is only called on non-negative values).

const double outer_value,
const double sphere_radius) {
// the closer to 0 this becomes, the sharper the discontinuity
const double sharpness = -0.03;
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 worth making this a parameter?

#undef EBIN
#undef GENERATE_LIST

// template class HomogeneousSphere;
Copy link
Member

Choose a reason for hiding this comment

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

Remove.

tmpl::list<TAG(data) < Frame::Inertial, NTYPE(data) < EBIN(data)> >> \
/*meta*/) const;

#define temp_list \
Copy link
Member

Choose a reason for hiding this comment

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

TEMP_LIST for macros (in a few places)

static constexpr Options::String help = {
"A homogeneous sphere emitting and absorbing neutrinos."};

// The sphere radius.
Copy link
Member

Choose a reason for hiding this comment

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

// -> ///


// All components of momentum density should be zero for this problem
CHECK(min(get<0>(tilde_s)) == 0.0);
CHECK(min(get<0>(tilde_s)) == max(get<0>(tilde_s)));
Copy link
Member

Choose a reason for hiding this comment

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

I believe get<0>(tilde_s) == 0.0 works. Similar in a few other places.

@@ -26,3 +26,31 @@ def constant_m1_tildeS(x, t, mean_velocity, comoving_energy_density):


# End Functions for testing ConstantM1.cpp


def homogen_sphere_m1_tildeE(
Copy link
Member

Choose a reason for hiding this comment

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

The C++ part of this comparison test is missing. These should also be moved from AnalyticSolutions to AnalyticData.

#include "Evolution/Systems/GrMhd/ValenciaDivClean/Tags.hpp"
#include "Evolution/TypeTraits.hpp"
#include "NumericalAlgorithms/Spectral/Mesh.hpp"
#include "Options/String.hpp"
Copy link
Member

Choose a reason for hiding this comment

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

Check the includes. Some (like this one) seem suspicious.

@@ -0,0 +1,242 @@
// Distributed under the MIT License.
Copy link
Member

Choose a reason for hiding this comment

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

This is just moving things into a cpp file without functionality changes, correct?

initial_data_evo_tags{});
});

const auto initial_data_hydro_vars = call_with_dynamic_type<
Copy link
Member

Choose a reason for hiding this comment

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

Combine the two calls to call_with_dynamic_type, just because I suspect it may be expensive to compile. You can return a pair and use structured bindings to keep the variables as they are now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature Adds a new feature that's worth highlighting in release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants