-
Notifications
You must be signed in to change notification settings - Fork 375
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
Homme(xx)/pgN: Add pgN feature to doubly periodic planar mode. #6057
Conversation
Testing:
|
@@ -514,6 +514,7 @@ ::run_dyn_to_fv_phys (const int timeidx, const Phys1T& ps, const Phys1T& phis, c | |||
kv.team_barrier(); // w2, w3, w4 in use | |||
// T_f | |||
loop_ik(ttrf, tvr, [&] (int i, int k) { T(ie,i,k) = th_f(i,k)*exner_f(i,k); }); | |||
kv.team_barrier(); // w2, w3 in use |
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 understand why we need this barrier (and the one below)
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.
Neither is clearly needed. However, because there is still a potential source of very rare nondeterminism lurking in our code, I've been inspecting old code as I work on new related code. All the data I've collected about this rare nondeterminism can't rule out its occurring in physics-dynamics grid remap, so I read through this file again while working on the planar physgrid case. I decided to put these two barriers in based on this fresh read-through.
The one below, in my analysis, is needed if uv_dim != 3, but I decided to put it in w/o a check on that condition for the reason I'll state in a minute. (In practice, uv_dim == 3.)
I put this one in the for the same reason, although here again the loop patterns in the two adjacent loops arguably don't require it, though in a much subtler way than the usual case of identical loop patterns.
The principle I decided to follow here was strict adherence to protecting work arrays, disregarding implicit protection from loop patterns, just to make reasoning about determinism here simpler. I believe with these two additional team_barriers, that principle is then followed throughout the whole file.
@@ -536,6 +591,8 @@ function gfr_check_api(hybrid, nets, nete, hvcoord, elem) result(nerr) | |||
integer :: nphys, ftype_in, ftype_idx, boost_idx, nerr | |||
logical :: boost_pg1 | |||
|
|||
is_sphere = trim(geometry) /= 'plane' |
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.
unrelated to this code, but why do we have both geometry and topology in control_mod?
if (topology == "cube") then
write(iulog,*)"readnl: ne,np = ",ne,np
else if (topology == "plane") then
write(iulog,*)"readnl: ne_x,ne_y,np = ",ne_x,ne_y,np
end if
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.
Topology is for the grid, geometry for the metric terms. Chris did that.
@@ -347,3 +347,4 @@ ELSE() | |||
ENDIF() | |||
cxx_unit_test (gllfvremap_ut "${GLLFVREMAP_UT_F90_SRCS}" "${GLLFVREMAP_UT_CXX_SRCS}" "${GLLFVREMAP_UT_INCLUDE_DIRS}" "${CONFIG_DEFINES}" ${NUM_CPUS}) | |||
TARGET_LINK_LIBRARIES(gllfvremap_ut thetal_kokkos_ut_lib) | |||
cxx_unit_test_add_test(gllfvremap_planar_ut gllfvremap_ut ${NUM_CPUS} "hommexx -planar") |
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 thought `cxx_unit_test_add_test' macro is just to go around mpiexec in cxx_unit_test, but here it is called standalone. why?
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.
This is to call the same unit test exe twice with different inputs. Before, you could only call it once or else have to create a new exe, meaning another build.
@@ -2175,6 +2208,29 @@ subroutine limiter_clip_and_sum(spheremp, qmin, qmax, dp, q) | |||
call limiter1_clip_and_sum(np*np, spheremp, qmin, qmax, dp, q) | |||
end subroutine limiter_clip_and_sum | |||
|
|||
subroutine ref2plane(corners, a, b, plane) |
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 assume this is needed for SL?
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.
This is for the metric terms in dynamics-physics grid remap. This PR is to support pg2 in planar mode.
@@ -168,14 +208,29 @@ subroutine set_gll_state(hvcoord, elem, nt1, nt2) | |||
end do | |||
end subroutine set_gll_state | |||
|
|||
function make_tendency(p) result(t) |
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.
Is this a forcing function tied to the special Cinf IC? If not, what is this for?
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.
This is for gllfvremap internal functional property unit tests. I suggest ignoring this.
thetanh-moist-bubble-sl-kokkos.cmake) | ||
thetanh-moist-bubble-sl-kokkos.cmake | ||
thetanh-moist-bubble-sl-pg2.cmake | ||
thetanh-moist-bubble-sl-pg2-kokkos.cmake) |
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.
it seems pg2 tests in this list are planar, can we use planar in their names?
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 can, but please note I'm following the naming scheme that I believe you established.
regarding "Add some standalone-hommexx infrastructure to support using the same uni-test exe in multiple tests." -- can you elaborate? "Add a unit test: gllfvremap_planar_ut." -- which part does it test? "Add a BFB test for F90/C++ dycore consistency." -- i assume this is for a planar pg2 test, can i modify the PR description? thanks! |
This is to make it possible to call a unit test exe multiple times with different inputs, permitting e.g. cube-sphere and then planar runs without building another exe.
It's the long-standing gllfvremap_ut test extended to planar geometry and doubly periodic topology.
Done. |
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.
thanks
regarding renaming tests -- it is a minor thing, up to you (i am sure i will forget which ones are planar next time, but i will read nl files).
This is an old bug in the original forcing function. The physgrid variant, dcmip2016_test1_forcing, is fine.
8792299
to
50d641d
Compare
Homme(xx)/pgN: Add pgN feature to doubly periodic planar mode. * Add pgN feature to planar doubly periodic mode. * Add some standalone-hommexx infrastructure to support using the same unit-test exe in multiple tests. * Add an init-planar capability to Hommexx unit tests. * Add a unit test: gllfvremap_planar_ut, planar version of old gllfvremap_ut unit test. * Add a BFB test for F90/C++ dycore consistency in planar mode with pg2 physics grid. e3sm_developer passes on Chrysalis. Additional tests for GPU/EAMxx pass on various machines. [BFB] except for new tests in homme_integration
[BFB] except for new tests in homme_integration