ESCOMP / CMEPS

NUOPC Community Mediator for Earth Prediction Systems
https://escomp.github.io/CMEPS/
24 stars 79 forks source link

add med_enthaply_mod #404

Open jedwards4b opened 1 year ago

jedwards4b commented 1 year ago

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

jedwards4b commented 1 year ago

Tested against b.e23_alpha16b.BLT1850.ne30_t232.040. results are bfb.

jedwards4b commented 1 year ago

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.

jedwards4b commented 1 year ago

Values for the B case are very similar.

tto061 commented 1 year ago

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:

  1. 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

  2. is it in fact not even possible to maintain energy consistency and (a fortiori) conservation in the atmosphere unless this is done

  3. 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

  4. even before all this, we had already decided to update the mediator to use the correct heat capacities for each water species

  5. 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.

jedwards4b commented 1 year ago

@tto061 please review: https://github.com/jedwards4b/CMEPS/pull/2

gustavo-marques commented 1 year ago

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

jedwards4b commented 1 year ago

@gustavo-marques that issue should be fixed - update cmeps and try again.

gustavo-marques commented 1 year ago

Just confirming I was able to run a G compset