Skip to content

Conversation

@nilsdeppe
Copy link
Member

Proposed changes

Add mutator used to resize and compute the prims on the DG grid when switching from DG back to FD

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
    major new feature if appropriate.

Further comments

@nilsdeppe nilsdeppe requested review from fmahebert and kidder June 16, 2021 15:55
#include "Evolution/DgSubcell/Tags/Mesh.hpp"
#include "Evolution/Systems/GrMhd/ValenciaDivClean/Tags.hpp"
#include "PointwiseFunctions/GeneralRelativity/TagsDeclarations.hpp"
#include "PointwiseFunctions/Hydro/EquationsOfState/EquationOfState.hpp"
Copy link
Member

Choose a reason for hiding this comment

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

forward declare


template <size_t ThermodynamicDim>
static void apply(
gsl::not_null<Variables<hydro::grmhd_tags<DataVector>>*> prim_vars,
Copy link
Member

Choose a reason for hiding this comment

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

forward declare Variables

// Use a small range of random values since we need recovery to succeed and we
// also reconstruct to the DG grid from the FD grid and need to maintain a
// somewhat reasonable state on both grids.
std::uniform_real_distribution<> dist(0.01, 0.010005);
Copy link
Member

Choose a reason for hiding this comment

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

is this limit because you messed up the Lorentz factor?

Copy link
Member Author

Choose a reason for hiding this comment

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

no, it's because reconstructing random numbers leads to wild oscillations

Copy link
Member

Choose a reason for hiding this comment

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

how about a narrow range around 0.5? that at least would have caught your incorrect lorentz factor

Copy link
Member Author

Choose a reason for hiding this comment

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

seems to work so far. I'll squash it in once @fmahebert has looked at the fixups

namespace grmhd::ValenciaDivClean::subcell {
/*!
* \brief Mutator that resizes the primitive variables to have the size of the
* active mesh and then computes the primitive variables on the active mesh.
Copy link
Contributor

Choose a reason for hiding this comment

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

the implementation only does these things if active_grid == Subcell

const size_t num_grid_points =
(active_grid == evolution::dg::subcell::ActiveGrid::Dg ? dg_mesh
: subcell_mesh)
.number_of_grid_points();
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 compute this inside the if statement?

* If the active grid is DG (we are switching from subcell back to DG) then this
* mutator computes the primitive variables on the active grid. We reconstruct
* the pressure to the DG grid to give a high-order initial guess for the
* primitive recovery. It would be nice if we can avoid this reconstruction when
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it'd help to describe this clearly as a possible optimization? E.g., "A possible future optimization would be to avoid this reconstruction when...".

subcell_spatial_metric.get(i, i) = 1.0 + 0.01 * i;
}
get(get<hydro::Tags::LorentzFactor<DataVector>>(prim_vars)) =
sqrt(1.0 + get(dot_product(spatial_velocity, spatial_velocity,
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this compute 1 / sqrt(1 - v2) ?

@nilsdeppe
Copy link
Member Author

I've pushed a fixup. Thanks for the reviews :)

Copy link
Member

@kidder kidder left a comment

Choose a reason for hiding this comment

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

you have my permission to squash

Copy link
Contributor

@fmahebert fmahebert left a comment

Choose a reason for hiding this comment

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

Fixup LGTM

@nilsdeppe nilsdeppe force-pushed the grmhd_resize_and_compute_prims branch from 9f74ea0 to 55c42bd Compare June 21, 2021 18:02
@nilsdeppe
Copy link
Member Author

I've rebased and squashed. Thanks for the reviews :)

@kidder kidder merged commit 0b0fd1c into sxs-collaboration:develop Jun 23, 2021
@nilsdeppe nilsdeppe deleted the grmhd_resize_and_compute_prims branch June 25, 2021 23:00
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