Evaluate enthalpy in F case.

[jedwards4b]

Description of the run

We have extended the enthalpy calculation done in b.e23_alpha16b.BLT1850.ne30_t232.040
to include the F case. This is in cmeps fork https://github.com/jedwards4b/CMEPS.git branch: enthalpy_corrections
(ESCOMP/CMEPS#404)

We would like an ne30pg3_ne30pg3_mg17.FLTHIST_v0d run done
with this change to evaluate the impact on F cases. In order to activate the enthalpy correction for an F case you must add
compute_enthalpy = .true. to user_nl_cpl.

Suffix in the casename

Suffix

Namelist modifications

Namelist user_nl_cpl
compute_enthalpy = .true.

Source modifications

None

Sandbox

Requested sandbox or tag

Contact info

Contact information

Any other relevant information

Enter relevant info

[cecilehannay]

For that run, I will use the hash:
d6dc143

Update Externals.cfg to:

[cmeps]
hash=d6dc143
protocol = git
repo_url =  https://github.com/jedwards4b/CMEPS.git
local_path = components/cmeps
required = True

Also, all my F case have quite a bit of tuning. Should I include some tuning? (maybe the one from run "40" or any other?). If you need a baseline, I could use one the current F case. Or do a new one.

[jedwards4b]

The repo_url needs to be changed to https://github.com/jedwards4b/CMEPS.git

[cecilehannay]

Thanks. I changed the path.

[jedwards4b]

I'm not sure who will do the comparison - I don't feel qualified. But I think that you want to compare to the
F case you are used to looking at and so the tuning should be included.

[tto061]

Dear Jim 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 that you've written). So it loosk to me like there's been some poor communication, and ill timing, here. The code you are proposing here is scientifically incorrect, and causes other consistency problems (just as the old med_phases_prep_ocn did), as outlined above. I would suggest to try a merge with what I've written. I am entirely at your disposal for questions and to help out. Best regards Thomas Thomas Toniazzo MISU Stockholms university SE-106 91 Stockholm Sverige

…

On 2023-09-01 1:35 fm, Jim Edwards wrote: I'm not sure who will do the comparison - I don't feel qualified. But I think that you want to compare to the F case you are used to looking at and so the tuning should be included. — Reply to this email directly, view it on GitHub <#390 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZGLJAOCACSXDTGBEBZZ3LXYENUXANCNFSM6AAAAAA4GWKMUI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gustavo-marques]

Hi Thomas,
This PR is doing exactly what we have been talking about, which is 1) use the correct heat capacities, 2) use tbot instead to tocn for hrain and hsnow, and 3) use the same enthalpy formulation regardless of the compset (G, F, or B). As we have been discussing, the next step could be to add the option to receive some of these fluxes from ATM. However, we cannot do that until we have a consistent definition of the material enthalpy across components.

[tto061]

Hi Gustavo yes I see now that it's using the new cp's, thanks. However, I don't think you're right about the other points. First, hcorr is still passed as sensible heat flux to the atmosphere with the °0C zero enthalpy point (lines 247 in med_phases_prep_atm). This explicitly violates energy conservation. Second: the sum of all the Foxx_h's is used as a spurious "fixer" in the atmosphere. This is an unecessary change to the atmosphere state since either a) the h-fluxes over ocean are accounted for (which I and Peter have been working on doing), in which case it's double-counting, or b) in the current CAM defaults mass is removed from the atmosphere at exactly the local total specific enthalpy (since there is no associated update for T or KE), which does not nearly match htot. In both cases energy conservation is violated. It is better to do nothing (given how small rof is compared with the rest). Third, which I worry about most here: we DO have a consistent definition of the material enthalpy fluxes across components! It's a matter of applying it. Only THEN will we have conservation. The implementation in the land is much more complex that for the ocean, but we should make a start with the ocean. Finally, as you well know, I have made the correct code already available for you to use. As I said, I'm happy to work with you and Jim to bring them up to CESM code standards. But I also think this is really necessary. Best regards Thomas Thomas Toniazzo MISU Stockholms university SE-106 91 Stockholm Sverige

…

On 2023-09-01 3:21 em, Gustavo Marques wrote: Hi Thomas, This PR is doing exactly what we have been talking about, which is 1) use the correct heat capacities, 2) use |tbot| instead to |tocn| for |hrain| and |hsnow|, and 3) use the same enthalpy formulation regardless of the compset (G, F, or B). As we have been discussing, the next step could be to add the option to receive some of these fluxes from ATM. However, we cannot do that until we have a consistent definition of the material enthalpy across components. — Reply to this email directly, view it on GitHub <#390 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZGLJGPBVA4EVFBPOIE4EDXYHONPANCNFSM6AAAAAA4GWKMUI>. You are receiving this because you commented.Message ID: ***@***.***>

[PeterHjortLauritzen]

We would like extensive discussions not to take place in "run requestions". I'll work with Cecile on setting up a discussions section for enthalpy under discussions. Also no need to address science concerns to a software engineer. Thank you for respecting that in the future.

[tto061]

Hi Peter OK, but when the run request is the first response I get from you after my effort to improve your CESM code; that request is sidelining that effort, and not even ensuring the necessary level of scientific integrity: then I don't feel that you have given me any other choice than to post a comment on that run request. And just to be clear: I have not made and I'm not making Jim or anyone in particular responsible. I've just pointed out that this run request, as it stands, appears to lack merit. Finally: at the very minimum, for any code change effort where I am or have been significantly involved, as in this case, I expect continued involvement, e.g. with a request for review, as well as a public acknowledgement. I this case see your and Gustavo's names there, but not mine. Thanks for respecting this in the future! Best regards Thomas Thomas Toniazzo MISU Stockholms university SE-106 91 Stockholm Sverige

…

On 2023-09-01 3:59 em, Peter Hjort Lauritzen wrote: We would like extensive discussions not to take place in "run requestions". I'll work with Cecile on setting up a discussions section for enthalpy under "discussions". <https://github.com/NCAR/amwg_dev/discussions>. Also no need to address science concerns to a software engineer. Thank you for respecting that in the future. — Reply to this email directly, view it on GitHub <#390 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZGLJHPSUCPN2TPARG636DXYHS5HANCNFSM6AAAAAA4GWKMUI>. You are receiving this because you commented.Message ID: ***@***.***>