For NorESM2.3+ - should DMS fluxes be computed in the mediator or docn?

[mvertens]

@tjiputra @MicSchu-Nesodden @gold2718 @matsbn @DirkOlivie - I am proposing that we think about computing DMS atm/ocean fluxes in the mediator or in the CDEPS data ocn (DOCN)

Below is the current scenario.

• If a compset is run with CAM/BLOM, then BLOM will send DMS fluxes to CAM.
• If a compset is run with CAM/DOCN then CAM reads in DMS concentrations and compute the DMS fluxes at the surface using the time interpolated concentration as well as the bottom level wind speed and ocean surface temperatures. In fact the following code is being used inside CAM in this case.

       !start with midpoint wind speed
       u10m(:ncol)=sqrt(state%u(:ncol,pver)**2+state%v(:ncol,pver)**2)

       if (method_oslo) then

          ! move the winds to 10m high from the midpoint of the gridbox:
          u10m (:ncol) = u10m(:ncol)*log(10._r8/z0)/log(state%zm(:ncol,pver)/z0)
          rk600(:ncol) = (0.222_r8*(u10m(:ncol)*u10m(:ncol))) + (0.333_r8*u10m(:ncol))        ! [cm/hr]
          flux (:ncol) = 2.778e-15*cnst_mw(pndx_fdms)*rk600(:ncol)*open_ocn(:ncol)*odms(:ncol) ! [kg m-2 s-1]

       else if (method_hamocc) then

          t(:ncol)=cam_in%sst(:ncol)-273.15_r8
          u10m (:ncol) = u10m(:ncol)*log(10._r8/z0)/log(state%zm(:ncol,pver)/z0)
          scdms(:ncol) = 2855.7+  (-177.63 + (6.0438 + (-0.11645 + 0.00094743*t(:ncol))*t(:ncol))*t(:ncol))*t(:ncol)
          kwdms(:ncol) = open_ocn(:ncol) * Xconvxa *u10m(:ncol)**2*(660./scdms(:ncol))**0.5
          flux (:ncol) = 62.13*kwdms(:ncol)*1e-9*odms(:ncol)

       endif

Its not clear if the above method_hamocc is the same computation as is done inside BLOM.

It would be good to have these fluxes computed in one place regardless of the type of ocean being used.
There are two possible options that we could consider:

1. Mediator computes DMS atm/ocn fluxes
   Currently for NorESM and CESM, atm/ocn fluxes are computed in the mediator at the atm coupling frequency. There are several reasons for this - which I am happy to go into if its necessary. It would be straightforward to have the mediator (CMEPS) read in DMS concentrations and compute the fluxes to the atm. This could be an optional part of the atm/ocn flux computation. This approach could be extended to fluxes of other species as well.
   The key point here is that in this case BLOM or DOCN would send DMS concentrations and SST to the mediator and then the mediator would compute the atm/ocn DMS fluxes.
2. DOCN computes DMS atm/ocn fluxes
   In this case, BLOM would continue to send DMS fluxes to CAM, but DOCN would have as input the atm bottom level winds and atm zm and from there would use those to compute that DMS atm/ocn fluxes.

In either 1. or 2. above there would only be one place for DMS fluxes to be computed.
Thoughts?

[tto061]

Hi again Mariana, the 'hamocc' method was introduced to harmonise the formulae in CAM with those in HAMOCC. I'm not sure the actual results would be identical (given the different grids etc). My opinion is that option 1. would be preferable, with model component passing states (e,g, surface concentrations) and the mediator computing fluxes. The computation of ustar/u10m could/should be obtained with the appropriate stability-dependent self-similarity functions. Thomas Toniazzo MISU Stockholms university SE-106 91 Stockholm Sverige

…

On 2023-05-26 14:49, mvertens wrote: @tjiputra <https://github.com/tjiputra> @MicSchu-Nesodden <https://github.com/MicSchu-Nesodden> @gold2718 <https://github.com/gold2718> @matsbn <https://github.com/matsbn> @DirkOlivie <https://github.com/DirkOlivie> - I am proposing that we think about computing DMS atm/ocean fluxes in the mediator or in the CDEPS data ocn (DOCN) Below is the current scenario. * If a compset is run with CAM/BLOM, then BLOM will send DMS fluxes to CAM. * If a compset is run with CAM/DOCN then CAM reads in DMS concentrations and compute the DMS fluxes at the surface using the time interpolated concentration as well as the bottom level wind speed and ocean surface temperatures. In fact the following code is being used inside CAM in this case. !start with midpoint wind speed u10m(:ncol)=sqrt(state%u(:ncol,pver)**2+state%v(:ncol,pver)**2) if (method_oslo)then ! move the winds to 10m high from the midpoint of the gridbox: u10m (:ncol)= u10m(:ncol)*log(10._r8/z0)/log(state%zm(:ncol,pver)/z0) rk600(:ncol)= (0.222_r8*(u10m(:ncol)*u10m(:ncol)))+ (0.333_r8*u10m(:ncol))! [cm/hr] flux (:ncol)= 2.778e-15*cnst_mw(pndx_fdms)*rk600(:ncol)*open_ocn(:ncol)*odms(:ncol)! [kg m-2 s-1] else if (method_hamocc)then t(:ncol)=cam_in%sst(:ncol)-273.15_r8 u10m (:ncol)= u10m(:ncol)*log(10._r8/z0)/log(state%zm(:ncol,pver)/z0) scdms(:ncol)= 2855.7+ (-177.63 + (6.0438 + (-0.11645 + 0.00094743*t(:ncol))*t(:ncol))*t(:ncol))*t(:ncol) kwdms(:ncol)= open_ocn(:ncol)* Xconvxa*u10m(:ncol)**2*(660./scdms(:ncol))**0.5 flux (:ncol)= 62.13*kwdms(:ncol)*1e-9*odms(:ncol) endif Its not clear if the above method_hamocc is the same computation as is done inside BLOM. It would be good to have these fluxes computed in one place regardless of the type of ocean being used. There are two possible options that we could consider: 1. *Mediator computes DMS atm/ocn fluxes* Currently for NorESM and CESM, atm/ocn fluxes are computed in the mediator at the atm coupling frequency. There are several reasons for this - which I am happy to go into if its necessary. It would be straightforward to have the mediator (CMEPS) read in DMS concentrations and compute the fluxes to the atm. This could be an optional part of the atm/ocn flux computation. This approach could be extended to fluxes of other species as well. The key point here is that in this case BLOM or DOCN would send DMS concentrations and SST to the mediator and then the mediator would compute the atm/ocn DMS fluxes. 2. *DOCN computes DMS atm/ocn fluxes* In this case, BLOM would continue to send DMS fluxes to CAM, but DOCN would have as input the atm bottom level winds and atm zm and from there would use those to compute that DMS atm/ocn fluxes. In either 1. or 2. above there would only be one place for DMS fluxes to be computed. Thoughts? — Reply to this email directly, view it on GitHub <#455>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZGLJHCA64VRFRSKXCKSLTXICRGPANCNFSM6AAAAAAYQGB7QE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mvertens]

@tto061 - Sorry for not including you in the original discussion and thanks so much for your quick response. That's very helpful and what you are suggesting makes sense to me as well. The good thing about putting this in the mediator is that it would be done in only one place. Would it be a problem to remove this from the HAMMOCC code in BLOM - or could it just be ignored. And also - how does BLOM obtain the surface concentrations of DMS. Does it read those in from a file and then interpolate them?

[oyvindseland]

BLOM or more precisely the ocean biogeochemistry package (iHAMOCC) embedded in BLOM has a prognostic equation for DMS concentration in the ocean (3D)

[mvertens]

Thanks. That clarifies things. In this case if both DOCN and BLOM send the DMS concentration to the mediator everything can then be done consistently. So the point is that DOCN reads in DMS concentration from file(s) where as BLOM does a prognostic computation for this quantity. Both BLOM and DOCN also send SST to the mediator. The mediator will have obtained u10m from the output of the atm/ocn flux calculation and can use that in conjunction with the SST from the ocean to compute the DMS flux. So this is a very consistent picture of how this could be done.

[oyvindseland]

Method_hamocc is supposed to be the same calculation as within BLOM in order to reproduce the flux also when using DOCN. The method_oslo is the parameterisation that was used before the coupling with hamocc/blom.

It is nice if the fluxcalculations can be found the same point in the code so I guess that is an argument for 1, but there are some caveats.
It is possible that the ocean-atmosphere flux is included in the DMS equation in the ocean. This should be checked. If so the (negative) flux must also be communicated to the ocean. It follows that also DATM then need to send the relevant fields to the mediator. I guess the same problem may hold true also for water isotopes, or can you assume that you have a unlimited ocean source?

[matsbn]

I also think option 1 would be the most consistent. I believe @JorgSchwinger has been involved in the DMS flux computation in HAMOCC so it would be good to get his opinion also.

[tto061]

No worries :) Jörg, Jerry, and Dirk are the best people to answer these last two questions. I think there will be more tracers (VOCs s.a. Bromoform etc) flixes that would need "relocating" and I do not know all implications. To Øyvind's points: I think DATM already does that, and any (unchanging) tracer concentrations can in principle be prescribed in a DOCN. Thomas Toniazzo MISU Stockholms university SE-106 91 Stockholm Sverige

…

On 2023-05-26 15:30, mvertens wrote: @tto061 <https://github.com/tto061> - Sorry for not including you in the original discussion and thanks so much for your quick response. That's very helpful and what you are suggesting makes sense to me as well. The good thing about putting this in the mediator is that it would be done in only one place. Would it be a problem to remove this from the HAMMOCC code in BLOM - or could it just be ignored. And also - how does BLOM obtain the surface concentrations of DMS. Does it read those in from a file and then interpolate them? — Reply to this email directly, view it on GitHub <#455 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZGLJDSMI4YOVG5K2ZCMETXICWADANCNFSM6AAAAAAYQGB7QE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[oyvindseland]

With unchanging I presume you mean as read from file.
The ocean concentrations have a strong annual cycle.
In principle it should also take into account year to year variation but then one should probably run a coupled model anyway.

[MichaelSchulzMETNO]

Option 1 seems to me more versatile and clear wrt to finding the place where fluxes are calculated. I think it would be nice to think alos of other biogeochemical fluxes, eg Bromoform and CO2. For the latter also the atmospheric concentrations are needed in the mediator, since the partial pressure difference between ocean and atmosphere is determing the flux.

It would be also nice to prepare for multiple options on how the flux is computed and which concentrations are used.

[tto061]

Perhaps the best way to accommodate all specific tracer calculation, including required additional inputs, would be to use the optionsl output duu10m already available from flux_atmocn, plus ls M-O length L as a new optional output, and then separate out the calculation of tracer fluxes to dedicated subroutines called from med_phases_aofluxes. These subroutine can then use sqrt(duu10m), L, the respective "measurement heights" ztr of the different tracers (e.g. ztr=10m) as given by their respective parametrisation, and the stability functions psiuo and psit_30 defined in shr_flux_mod, to compute the tracers fluxes accurately. Thomas Toniazzo MISU Stockholms university SE-106 91 Stockholm Sverige

…

On 2023-05-26 17:00, Michael Schulz wrote: Option 1 seems to me more versatile and clear wrt to finding the place where fluxes are calculated. I think it would be nice to think alos of other biogeochemical fluxes, eg Bromoform and CO2. For the latter also the atmospheric concentrations are needed in the mediator, since the partial pressure difference between ocean and atmosphere is determing the flux. It would be also nice to prepare for multiple options on how the flux is computed and which concentrations are used. — Reply to this email directly, view it on GitHub <#455 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZGLJC47O7OL7JDXE24XNDXIDASTANCNFSM6AAAAAAYQGB7QE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[JorgSchwinger]

Hi everyone

I generally see the advantages and beauty of option 1. Some thoughts/questions/additions from the HAMMOC side:

1. it is correct that for DMS fluxes iHAMOCC assumes an atmospheric concentration of 0 (because DMS is short lived), but it wouldn't hurt to change this.

2. Since iHAMOCC needs to update the prognostic ocean tracers, all fluxes need to be passed back from the mediator. Would this mean that the updates of prognostic tracers would occur at a delay of one (coupling) time-step? If so, how would this work for restarts/branching/hybrid restarts?

3. Would everything work in the same way when we use DATM compsets (this would be important for us)?

4. iHAMMOC also calculates fluxes for O2, N2, and CFCs that are not passed anywhere. It's a bit the question what to do with these calculations then. There are methods where anthropogenic carbon is estimated with help of O2 fluxes, and for such applications it would be important to have consistent flux calculation between O2/CO2

[mvertens]

@JorgSchwinger - these are really great questions/points.

1. I'm not sure what you mean by an atmospheric concentration of 0 and changing this? From the equation in method_hamocc - odms is the ocean dms concentration read in from a file (/cluster/shared/noresm/inputdata/noresm-only/atm/cam/camoslo/dms-hamocc-dow-taylor_chlor_a-lanaclim_N1850_f19_tn14_20190621_1751-1780_cycle_version20190726.nc) which just has the ocean dms concentration.
2. You are right - there would be a coupling lag of one or more timesteps (depending on the frequency of coupling from the ocean). In runs with all prognostic components, the ocean normally couples at a slower frequency than the atm (e.g. 1 hour for the ocean and 1/2 hour for the atm/ice/land). What the mediator does is do a time average of the compute fluxes (e.g. atm/ocn stresses, latent and sensible heat fluxes) over the ocean coupling interval. These are then sent to the atm at the atm coupling frequenc and to the ocean at the ocean coupling frequency. In terms of restarts - this is already handled for atm/ocn fluxes computed in the mediator and the addition of other fluxes such as dms would easily be handled as an extension to the current set of variables on the mediator restarts.
3. Yes - this would work the same way when you use datm. The simplification is that no fluxes are sent back to datm and normally the datm/ocn coupling frequency is the same.
4. I think your question here clearly needs a lot more discussion. It would be no problem to keep these in the ocean for now.

[jmaerz]

Dear @mvertens , I am not sure, if it is the right place to mention, but in addition to the fluxes mentioned by @JorgSchwinger , there is currently development done for NH3 (a new air-sea flux) and N2O (previously not passed anywhere) air-sea fluxes + the deposition of NHx and NOy in the course of the new implementation of the extended nitrogen cycle NorESMhub/BLOM#147 in iHAMOCC. The development and coupling thus far only lives in separate branches and was carried out through the old coupler. Generally, for any air-sea fluxes, it would be nice to have the ability to switch on and off the online coupling to enable investigation of the coupling effects.

[mvertens]

@jmaerz -thanks so much for your input. This is totally the right place.In the PR I am working on (NorESMhub/BLOM#259) the goal is to optionally send BROMO and DMS concentrations to the mediator and have the mediator compute the ocn/atm fluxes for those species and send them back to BLOM.
After talking to @JorgSchwinger @matsbn and @TomasTorsvik last week at the KeyClim meeting we concluded that having a consistent calculation in the new CMEPS mediator for DMS and BROMO fluxes would make sense. Are you envisioning the same type of mechanism for NH3 and N2O?
I am happy to help implement a flexible scheme where as you suggest where both the flux computation and transfer could be optionally turned off and on. It would be good to set up a meeting to discuss this further.

[jmaerz]

@mvertens , many thanks. Yes, during the coupling in the branches, we (me and @DirkOlivie) followed the BROMO implementation for the exchange of fluxes in the old coupler. So yes, it would be the same mechanisms to be implemented in the CMEPS mediator. I noted though, that in NorESMhub/BLOM#259 BROMO now becomes a standard tracer in iHAMOCC and after briefly speaking with @TomasTorsvik , he mentioned that there were some technical issues with using the pre-processor flag further in the new system. Currently, the extended nitrogen cycle is also handled via a pre-processor flag and whether it will become the new default nitrogen cycle implementation is yet an open question (which suggests handling it further via a pre-processor flag, since iHAMOCC is not yet ready to handle the number of tracers at run-time). Sorry for being a bit late with these comments, but I was on holidays the last weeks.

[JorgSchwinger]

I think the first things we need to decide are i) is the extended nitrogen cycle becoming standard in iHAMOCC (I would tend to think yes) and ii) whether coupling of NH3 and N2O to the atmosphere become standard in NorESM (I would tend to think no, but I'm not sure). Anyway, once this is clear we can discuss further. The code implemented by @mvertens is easy to extend to other trace gas fluxes.

[jmaerz]

Hi @JorgSchwinger , thanks for the input. I just wanted to raise awareness that there will be (potentially, as to be discussed) coming up further fluxes in addition to DMS and bromoform (which should be similarly easy to implement, I agree). Plus, that it would be good to think about the option to not always fully couple the air-sea fluxes.
The consequences of pre-processor flags being a potential obstacle for the new coupler system and hence for the timeline of bringing in the extended nitrogen cycle wrt to phasing out the old coupler can be discussed elsewhere.