Repository navigation
Wps ml nan - #4261
Merged
Merged
Wps ml nan#4261
Conversation
…llocated
init_base_state_from_wrfinput evaluates the analytic p(z) inversion over the
base state's grown box and clamps the height lookup into
grow(mfi.validbox(), z_phys_cc->nGrowVect())
which is the region where z_phys_cc is allocated. That is not the region where
it holds anything. On the branch that reads a wrfinput file, init_only runs
before init_zphys, so make_terrain_fitted_coords has not touched z_phys_nd yet
and its halo outside the domain is still the poison it was allocated with;
make_zcc then averages eight of those nodes into each z_phys_cc halo cell, and
FillBoundary cannot replace them across a non-periodic face. The halo came back
as z = 5e149 -- one eighth of four times bogus_large_value, exactly as that
average predicts.
The isothermal branch then evaluates exp(-g(z - z_iso)/(R_d TISO)) at that
height, which underflows Pd to exactly zero, and getThgivenTandP divides p_0 by
it. th_hse comes out inf and r_hse NaN in precisely the ghost cells the comment
at the top of the loop says must be valid, because read_and_convert_from_wrfbdy
-> scale_bdy_normal_by_rho0 reads rho0 one cell outside the domain.
Intersect the clamp box with the domain instead. Ghost cells inside the domain
are kept and still come from a neighbouring box through FillBoundary; only the
ones outside it are clamped onto the nearest real column, which is the
zeroth-order extrapolation of the profile the comment already promised.
Found by running inputs_wps_ml under amrex.fpe_trap_zero=1, which dies in
getThgivenTandP during initialization. After this, that deck and
inputs_wps_ml_interp both initialize without a divide-by-zero under the same
flag.
Behaviour: the base state's ghost cells OUTSIDE the domain change, at every
level built from a wrfinput file on a terrain-fitted mesh, from inf/NaN to a
finite extrapolation. Ghost cells inside the domain and all valid cells are
untouched. Whether that reaches the solution depends on whether a consumer
reads the base state outside the domain: on inputs_wps_ml_interp it does not --
plt00010 and plt00020 are bit-for-bit unchanged on both levels over the 20-step
deck, and the restart-parity residue against the straight run is unchanged digit
for digit -- so no tracked deck's answer moves here, but anything that does read
out there now reads a number rather than a NaN.
This does NOT fix the NaN that inputs_wps_ml hits on its second step; that is a
separate terrain-coordinate problem (the STF layer thickness falls to 0.21 of
nominal over steep terrain, against the gamma_m = 0.5 floor the method is
supposed to hold).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ess floor
The smoothed terrain-following grid places nodes at z = z_lev[k] + A(k) h_s(k),
so a layer is
dz = dz_nominal + [ A_k h_s(k) - A_k-1 h_s(k-1) ]
Each smoothing pass flattens h_s at level k while level k-1 is already frozen, so
over a peak every pass thins that layer. Klemp2011 bounds how far this may go
with Eqn. 7 -- the fraction of the nominal thickness must stay at or above
gamma_m -- and the M_k iteration exists to stop before that is violated.
The loop measured the fraction only after committing a pass, and nothing then
stopped the pass that broke the criterion from being the one kept. There was no
earlier state to go back to, so the violating grid was the output. Measured on
inputs_wps_ml, whose wrfinput has a 3620 m massif: the thinnest layer came out at
0.213 of nominal against a gamma_m of 0.5, 1484 cells were under the floor, and
one column had a 3.53 m layer at k = 26 -- mid-column, where nominal is ~17 m.
That column then carried a 2-delta sawtooth in w, drove the density negative at
(60,148,35) on the second step, and getExnergivenRTh turned the negative rho
theta into the NaN the deck aborts on.
Reject that pass and restore what preceded it. At iter 0 there is no earlier
pass at this level, so carry the level below up unsmoothed; that leaves only the
A-decay term, which is exactly what z_H = 2.44 h_m/(1-gamma_m) was chosen to
bound. For A = cos^6(pi z / 2 z_H), max|dA/dz| = 2.439/z_H, so h_m max|dA/dz| dz
is (1-gamma_m) dz and the fraction lands on gamma_m -- the 2.44 already in the
code is that constant.
Also report, once per level, how many k the floor had to cap. A terrain needing
it at most levels is at the edge of what STF can represent on that vertical grid,
and that is worth saying rather than leaving in the grid.
Measured, three decks, before -> after:
deck min thickness fraction cells under 0.5 k capped
inputs_wps_ml 0.213 -> 0.516 1484 -> 0 142/176
inputs_wps_ml_interp 0.312 -> 0.524 70 -> 0 59/79
Terrain2Lev_STF_* (not measured) 3/32
inputs_wps_ml now runs 10 steps with its own erf.fixed_dt = 0.5 and its own
erf.terrain_smoothing = 1, where it used to abort on the second; the refinement
indicator fires and level 1 is built, so the deck reaches what it was written to
exercise. It is still configured max_step = 1, so this was never seen in CI.
Behaviour: the grid moves for a deck with erf.terrain_smoothing = 1 whose
columns were violating the floor, and only for those -- a pass that satisfies
Eqn. 7 is accepted exactly as before, so a deck that never caps is bit-for-bit
unchanged. Of the four tracked STF decks, two cap and two do not:
Terrain2Lev_STF_interp caps 3/32 -> gold regenerated (2 ranks)
Terrain2Lev_STF_transform caps 3/32 -> gold regenerated (2 ranks)
DensityCurrent_detJ2 caps 0 -> gold verified unchanged (2 ranks)
DensityCurrent_detJ2_nosub caps 0 -> gold verified unchanged (4 ranks)
The two regenerated golds move by 0.50 m in z_phys (1.6e-4 relative) and 4.6e-5
in density (3.9e-5 relative) at plt00010; both agree with the new gold at the
suite's 2e-10 tolerance. erf.terrain_smoothing = 0 and = 2 are different
branches and are untouched.
inputs_wps_ml_interp caps at 59 of its 79 levels, so its answers move too; its
restart parity is unchanged in character, still only the coarse/fine density
halo residue of issue 4224 (KE 5.5e-7 at plt00010, against 5.7e-7 before).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.