-
Notifications
You must be signed in to change notification settings - Fork 15
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 initial pertubation for cluster pgen #67
Conversation
src/pgen/cluster.cpp
Outdated
a_jb.e += 1; | ||
IndexRange a_kb = kb; | ||
a_kb.s -= 1; | ||
a_kb.e += 1; | ||
|
||
/************************************************************ | ||
* Initialize an initial magnetic tower | ||
************************************************************/ | ||
const auto &magnetic_tower = hydro_pkg->Param<MagneticTower>("magnetic_tower"); | ||
|
||
magnetic_tower.AddInitialFieldToPotential(pmb.get(), a_kb, a_jb, a_ib, A); | ||
|
||
/************************************************************ | ||
* Add dipole magnetic field to the magnetic potential | ||
************************************************************/ | ||
const auto &init_dipole_b_field = hydro_pkg->Param<bool>("init_dipole_b_field"); | ||
if (init_dipole_b_field) { | ||
const Real mx = hydro_pkg->Param<Real>("dipole_b_field_mx"); | ||
const Real my = hydro_pkg->Param<Real>("dipole_b_field_my"); | ||
const Real mz = hydro_pkg->Param<Real>("dipole_b_field_mz"); | ||
parthenon::par_for( | ||
DEFAULT_LOOP_PATTERN, "MagneticTower::AddInitialFieldToPotential", | ||
parthenon::DevExecSpace(), a_kb.s, a_kb.e, a_jb.s, a_jb.e, a_ib.s, a_ib.e, | ||
KOKKOS_LAMBDA(const int &k, const int &j, const int &i) { | ||
// Compute and apply potential | ||
const Real x = coords.Xc<1>(i); | ||
const Real y = coords.Xc<2>(j); | ||
const Real z = coords.Xc<3>(k); | ||
|
||
const Real r3 = pow(SQR(x) + SQR(y) + SQR(z), 3. / 2); | ||
|
||
const Real m_cross_r_x = my * z - mz * y; | ||
const Real m_cross_r_y = mz * x - mx * z; | ||
const Real m_cross_r_z = mx * y - mx * y; | ||
|
||
A(0, k, j, i) += m_cross_r_x / (4 * M_PI * r3); | ||
A(1, k, j, i) += m_cross_r_y / (4 * M_PI * r3); | ||
A(2, k, j, i) += m_cross_r_z / (4 * M_PI * r3); | ||
}); | ||
} | ||
|
||
/************************************************************ | ||
* Apply the potential to the conserved variables | ||
************************************************************/ | ||
parthenon::par_for( | ||
DEFAULT_LOOP_PATTERN, "MagneticTower::AddInitialFieldToPotential", | ||
parthenon::DevExecSpace(), a_kb.s, a_kb.e, a_jb.s, a_jb.e, a_ib.s, a_ib.e, | ||
DEFAULT_LOOP_PATTERN, "cluster::ProblemGenerator::ApplyMagneticPotential", | ||
parthenon::DevExecSpace(), kb.s, kb.e, jb.s, jb.e, ib.s, ib.e, | ||
KOKKOS_LAMBDA(const int &k, const int &j, const int &i) { | ||
// Compute and apply potential | ||
const Real x = coords.Xc<1>(i); | ||
const Real y = coords.Xc<2>(j); | ||
const Real z = coords.Xc<3>(k); | ||
u(IB1, k, j, i) = | ||
(A(2, k, j + 1, i) - A(2, k, j - 1, i)) / coords.Dxc<2>(j) / 2.0 - | ||
(A(1, k + 1, j, i) - A(1, k - 1, j, i)) / coords.Dxc<3>(k) / 2.0; | ||
u(IB2, k, j, i) = | ||
(A(0, k + 1, j, i) - A(0, k - 1, j, i)) / coords.Dxc<3>(k) / 2.0 - | ||
(A(2, k, j, i + 1) - A(2, k, j, i - 1)) / coords.Dxc<1>(i) / 2.0; | ||
u(IB3, k, j, i) = | ||
(A(1, k, j, i + 1) - A(1, k, j, i - 1)) / coords.Dxc<1>(i) / 2.0 - | ||
(A(0, k, j + 1, i) - A(0, k, j - 1, i)) / coords.Dxc<2>(j) / 2.0; | ||
|
||
u(IEN, k, j, i) += 0.5 * (SQR(u(IB1, k, j, i)) + SQR(u(IB2, k, j, i)) + | ||
SQR(u(IB3, k, j, i))); | ||
}); | ||
|
||
const Real r3 = pow(SQR(x) + SQR(y) + SQR(z), 3. / 2); | ||
/************************************************************ | ||
* Add uniform magnetic field to the conserved variables | ||
************************************************************/ | ||
const auto &init_uniform_b_field = hydro_pkg->Param<bool>("init_uniform_b_field"); | ||
if (init_uniform_b_field) { | ||
const Real bx = hydro_pkg->Param<Real>("uniform_b_field_bx"); | ||
const Real by = hydro_pkg->Param<Real>("uniform_b_field_by"); | ||
const Real bz = hydro_pkg->Param<Real>("uniform_b_field_bz"); | ||
parthenon::par_for( | ||
DEFAULT_LOOP_PATTERN, "cluster::ProblemGenerator::ApplyUniformBField", | ||
parthenon::DevExecSpace(), kb.s, kb.e, jb.s, jb.e, ib.s, ib.e, | ||
KOKKOS_LAMBDA(const int &k, const int &j, const int &i) { | ||
const Real bx_i = u(IB1, k, j, i); | ||
const Real by_i = u(IB2, k, j, i); | ||
const Real bz_i = u(IB3, k, j, i); | ||
|
||
u(IB1, k, j, i) += bx; | ||
u(IB2, k, j, i) += by; | ||
u(IB3, k, j, i) += bz; | ||
|
||
// Old magnetic energy is b_i^2, new Magnetic energy should be 0.5*(b_i + | ||
// b)^2, add b_i*b + 0.5b^2 to old energy to accomplish that | ||
u(IEN, k, j, i) += | ||
bx_i * bx + by_i * by + bz_i * bz + 0.5 * (SQR(bx) + SQR(by) + SQR(bz)); | ||
}); | ||
// end if(init_uniform_b_field) | ||
} | ||
|
||
} // END if(hydro_pkg->Param<Fluid>("fluid") == Fluid::glmmhd) | ||
} | ||
|
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.
Note that I didn't touch any of this. It's just marked because it was intended due to the explicit loop over blocks (at the ProblemGenerator is not the Mesh one and not the MeshBlock one)
prim[:, prim_col_dict["density"]], "code_mass*code_length**-3" | ||
prim[prim_col_dict["density"], :], "code_mass*code_length**-3" | ||
) | ||
pres = unyt.unyt_array( | ||
prim[:, prim_col_dict["pressure"]], | ||
prim[prim_col_dict["pressure"], :], |
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.
bugfix from when we updated the output format in Parthenon
@pgrete Just wanted to check on this. I want to run some driving runs with the precipitator next week if possible. |
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.
Been a while since I reviewed most of this PR, I think it looks good. Good idea to test the perturbations on top of the HSE since the two don't interact at initialization.
<problem/cluster/init_perturb> | ||
# for the velocity field | ||
sigma_v = 0.0 # in code velocity; default: 0.0 (disabled) | ||
k_peak_v = ??? # wavenumber in normalized units where the velocity spectrum peaks. No default value. |
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 change to peak wavelength for these parameters? Or provide that as an alternative option?
It's awkward for a problem parameter to have a different action depending on the box size, especially when we'll be testing a number of box sizes.
Could also normalize k
by code length instead of box length but l
seems more intuitive.
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 don't have a strong preference here. I guess I'm just used to normalized units.
I agree that l
(in code_length
) would be the most intuitive parameter given that all other params of this pgen are also in code units.
I'll add it.
// This could be more optimized, but require a refactor of init routines being called. | ||
// However, given that it's just called during initial setup, this should not be a | ||
// performance concern. | ||
for (int b = 0; b < md->NumBlocks(); b++) { |
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 think this actually might be a performance concern. Start up is painfully slow but that might also be writing ASCENT slices and particularly profiles at the same time.
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'd be surprised if this is a big performance concern, but I'll double check.
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 suspect it's Ascent or I/O. Did we ever get Darshan to work with cce/15.0.1?
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 did not experience any slow startups over the past weeks when running without Ascent. So I don't think this is a concern at the moment.
Just want to check- what is remaining to do on this PR? |
) * Velocity and temperature ceilings * Added ceilings to velocity and temperature within AGN region * Fixed to apply only to kinetic jet injection zone * Fixed missing magnetic energy from temperature ceil * Fixed typos in ceilings * Fixed arguments for EOS constructor * cpp-py-formatter * Added V, V_a, T, D clipping within defined radius * Check kinetic feedback in release builds * Fixed Va ceiling typo * Fixed cluster/clips -> problem/cluster/clips * Update src/pgen/cluster.cpp Co-authored-by: Philipp Grete <[email protected]> * Fix comments * Fix formattin --------- Co-authored-by: Forrest Glines <[email protected]> Co-authored-by: Forrest Glines <[email protected]> Co-authored-by: par-hermes <[email protected]> Co-authored-by: Philipp Grete <[email protected]>
The contents of this PR have been tested over the past weeks for cluster and turbulence runs and nothing surprising came up. |
From the docs:
In addition, this PR also