Open cecilehannay opened 1 year ago
@islasimpson is suggesting to add Uzm, Wzm, Vzm, THzm to the TEM diagnostics. I am modifying the namelist to do that.
@fvitt and @islasimpson: I tried to output the TEM diags, but it seems that the variables don't exist.
FLDLST: VTHzaphys in fincl(1, 5) not found
FLDLST: WTHzaphys in fincl(2, 5) not found
FLDLST: UVzaphys in fincl(3, 5) not found
FLDLST: UWzaphys in fincl(4, 5) not found
FLDLST: Uzm in fincl(5, 5) only available with FV dycore
FLDLST: Wzm in fincl(6, 5) only available with FV dycore
FLDLST: Vzm in fincl(7, 5) only available with FV dycore
FLDLST: THzm in fincl(8, 5) only available with FV dycore
I think you need "do_tem_diag=True" for the first four. It looks like not all of these are currently included in the TEM diagnostics code. It seems like it would be a lot easier if they were though. Should they be added?
@cecilehannay The zm history fiields are available only when the FV dycore is used. You are using the SE dycore.
The calls to phys_grid_ctem
are not in 'src/physics/cam_dev/physpkg.F90', only in src/physics/cam/physpkg.F90
. This is a bug. Because you are using cam_dev physics the zaphys history fields were not found.
uh oh! @fvitt can you open a git issue please?
I am skipping the tem_diag for now.
This run is crashing for the error:
2107: ERROR: In UpdateState_TopLayerFluxes, h2osoi_ice has gone significantly negativ
2107: e
2107: Bulk/tracer name = bulk
2107: c, lev_top(c) = 61 0
2107: h2osoi_ice_top_orig = 1.990291810086836E-006
2107: h2osoi_ice = -3.550762114890027E-018
2107: frac_sno_eff = 1.00000000000000
2107: qflx_soliddew_to_top_layer*dtime = 0.000000000000000E+000
2107: qflx_solidevap_from_top_layer*dtime = 1.990291810090387E-006
2107:iam = 2107: local column index = 61
2107:iam = 2107: global column index = 97626
2107:iam = 2107: global landunit index = 44433
2107:iam = 2107: global gridcell index = 15068
2107:iam = 2107: gridcell longitude = 239.8560077
2107:iam = 2107: gridcell latitude = 50.4828476
2107:iam = 2107: column type = 75
2107:iam = 2107: landunit type = 9
2107: ENDRUN:
2107: ERROR:
2107: In UpdateState_TopLayerFluxes, h2osoi_ice has gone significantly negative
Hmm ... this run got 4 years in before dumping out. @wwieder @olyson is there any way we can determine whether we need to adjust the h2osoi_ice threshold for negative values, or whether the state really is becoming increasingly unrealistic (and therefore an actual blow-up)?
I don't know how one would generate negative soil ice, I may defer to @olyson on this one.
Based on previous conversations about this error that crops up very occasionally and the size of the error (e-18) I doubt the state is becoming unrealistic, e.g.,
I'll discuss this with @billsacks later to see if we can do something more robust (I think he is out on PTO), but in the meantime try changing custom_rel_epsilon to 1.e-11_r8 in this block of code in /components/clm/src/biogeophys/SnowHydrologyMod.F90 (make sure it's the h2osoi_ice block):
call truncate_small_values_one_lev( &
num_f = num_snowc, &
filter_f = filter_snowc, &
lb = bounds%begc, &
ub = bounds%endc, &
lev_lb = -nlevsno+1, &
lev = lev_top(bounds%begc:bounds%endc), &
data_baseline = h2osoi_ice_top_orig(bounds%begc:bounds%endc), &
data = h2osoi_ice(bounds%begc:bounds%endc, :), &
custom_rel_epsilon = 1.e-12_r8)
@olyson: Thanks for your fast reply. I changed the custom_rel_epsilon to 1.e-11_r8 in the h2osoi_ice block. Hopefully, this will allow us to keep going until we have a more robust solution.
uh oh! @fvitt can you open a git issue please?
@fvitt I am not understanding this issue - you had previously provided output from and SE run that I was able to calculate TEM diags from. I thought the code mods were merged into the version Cecile is running so we can do a similar TEM analysis on all runs going forward. As mentioned elsewhere, all we need to begin with is TEM terms to be calculated every 6 hours and averaged over a month - I'll likely be trying to get seasonal TEM diags as a standard part of the new climate diagnostics package.
uh oh! @fvitt can you open a git issue please?
@fvitt I am not understanding this issue - you had previously provided output from and SE run that I was able to calculate TEM diags from. I thought the code mods were merged into the version Cecile is running so we can do a similar TEM analysis on all runs going forward. As mentioned elsewhere, all we need to begin with is TEM terms to be calculated every 6 hours and averaged over a month - I'll likely be trying to get seasonal TEM diags as a standard part of the new climate diagnostics package.
The tests I did for you were using cam6 physics. Cecile is using cam_dev physics which is not calling the phys_grid_ctem routines. As stated in another thread, the fix for this here https://github.com/ESCOMP/CAM/pull/770
@fvitt just to clarify, I think the other pieces that are needed are Uzm, Vzm, THzm and Wzm (or whatever we want to call them now). I see they are there in the code as the part that is subtracted to calculate the zonal deviations, before the fluxes are calculated (uzm, vzm, wzm, thzm). Thanks.
Description: @adamrher , @JulioTBacmeister and @PeterHjortLauritzen would like a new baseline created with cam6_3_100 (FWscHIST, L58) in preparation for evaluating new science code (incl. condensates in pressure and having energy fixer use an energy consistent with the dynamical core).
This baseline will also include the bug fix from @tto061 and @bstephens82's latest clubb tuning as described in #223.
It also includes the TEM diags as requested by @dan800
user_nl_cam
SourceMods Thomas's bug fix
Case directory: Locally (if still available):
On github: https://github.com/NCAR/amwg_dev/tree/f.cam6_3_100.FWscHIST.ne30_L58.001
Sandbox: Locally (if still available):
On github: https://github.com/ESCOMP/CAM/tree/cam6_3_100
hash: 82baf1a
Diagnostics: AMWG diags (if available) https://webext.cgd.ucar.edu/FWscHIST/f.cam6_3_100.FWscHIST.ne30_L58.001/atm/
Contacts: @adamrher , @JulioTBacmeister, @PeterHjortLauritzen, @tto061, @bstephens82, @cecilehannay, @cacraigucar, @jtruesdal