Open jedwards4b opened 1 year ago
Tested against b.e23_alpha16b.BLT1850.ne30_t232.040. results are bfb.
This is now functional for an f case. I added a print of the global enthalphy correction value to the mediator log file. Values over a 5 day run of ne30pg3_ne30pg3_mg17.FMTHIST_v0d are: 0.0 on the first step -0.66 on the second step then ranging between 0 and 1 over the rest of the run.
Values for the B case are very similar.
I think there are several problems with this code.
Gustavo and Peter and I have been discussing (a lot) on the scientifically correct and technically best way to implement the exchange material enthalpy fluxes. The main points we agreed on are:
hrain and hsnow depend on atmospheric processes and can only be computed correctly in the atmospheric model component; for consistency also hevap should be computed there
is it in fact not even possible to maintain energy consistency and (a fortiori) conservation in the atmosphere unless this is done
so the mediator is the wrong place for these calculations; in particular the current calculation breaks atmospheric energy conservation even at a basic level because it uses a zero meterial enthalpy point of 0°C: the fluxes passed to each component always need to be re-referenced to the zero enthalpy point of that component
even before all this, we had already decided to update the mediator to use the correct heat capacities for each water species
finally, with atmospheric energy consistency in place, we only need to use the mediator fixer (g.a. correction to the sensible heat flux) for the run-off components (hrofi/l)
I have already written code, tested it (both on betzy and on cheyenne) and shared it with Gustavo and Peter that does what we regard to be the correct calculation, computing the hfluxes in the atmosphere model (although not in the final way we eventually wish it to be done) and passing them to the ocean. My code works in all F, G, and coupled cases, (only for G cases the hfluxes are computed in the way you do).
As Gustavo and Peter already know, you can find this as SourceMods in my case directory /glade/work/toniazzo/4gustavo/cases/G/g.e23_b15.GJRAv4.TL319_t232_zstar_N65.toniazzo (for now it does still lack the namelist and diagnostic output parts). I invited G&P to check and run tests of their own (I don't know if they did).
So it loosk to me like there's been some poor communication, and ill timing, here. I think this pull request should be revised. I would suggest to try a merge with what I've written, and I am entirely at your disposal for questions and to help out.
@tto061 please review: https://github.com/jedwards4b/CMEPS/pull/2
I am trying to run a G compset and I am getting SIGSEGV(11). Here is the cesm.log file:
/glade/scratch/gmarques/g.e23_b16.GJRAv4.TL319_t232_zstar_N65.enthalpy_case5/run/cesm.log.3391111.chadmin1.ib0.cheyenne.ucar.edu.230919-142440
@gustavo-marques that issue should be fixed - update cmeps and try again.
Just confirming I was able to run a G compset
Description of changes
Update calculation of enthalpy and include for F cases.
Specific notes
Contributors other than yourself, if any: Mariana Vertenstein, Gustavo Marques, Peter Lauritzen
CMEPS Issues Fixed (include github issue #):
Are changes expected to change answers? yes
Any User Interface Changes (namelist or namelist defaults changes)? Added compute_enthalpy to driver namelist.
Testing performed
Please describe the tests along with the target model and machine(s) If possible, please also added hashes that were used in the testing