search

E3SM-Project / E3SM

Energy Exascale Earth System Model source code. NOTE: use "maint" branches for your work. Head of master is not validated.
https://docs.e3sm.org/E3SM
Other
343 stars 352 forks source link

Compute KPP input fields #6507

Closed qingli411 closed 1 week ago

qingli411 commented 1 month ago

@vanroekel, I think the call below to compute necessary input fields for CVMix should be placed outside the if statement checking config_cvmix_kpp_nonlocal_with_implicit_mix, or somewhere else? This seems to be the only place where this subroutine is called and the computed fields surfaceBuoyancyForcing and surfaceFrictionVelocity are required by other CVMix subroutines. What do you think?

https://github.com/E3SM-Project/E3SM/blob/c7d7998ab483f09bd17b8c399345df8fd247c6f4/components/mpas-ocean/src/shared/mpas_ocn_tendency.F#L1249-L1250

vanroekel commented 1 month ago

@qingli411 great catch, yes you are right on. If we set config_cvmix_kpp_nonloacl_with_implicit_mix those critical quantities would not be computed. Fortunately that is not the default value, but we need to fix this. I'll assign this to myself.

qingli411 commented 1 month ago

I guess we could probably put it in ocn_diagnostic_solve()? I realized it that I was using surfaceFrictionVelocity in GOTM as well... So maybe do the computation when either CVMix or GOTM is on?

vanroekel commented 1 month ago

Oh, GOTM uses this as well? That's more problematic.

I think we should do a two step process.

  1. for now - move the KPP_input_fields above that if statement and change the if on L1248 to if(config_cvmix .or. config_gotm)
  2. move the calculation to diagnostic solve or vmix.F - since diagnostic_solve is called multiple times perhaps making this call in vmix.F is more effective

I suggest this way as we can keep our current v3 simulations BFB

What do you think?

qingli411 commented 1 month ago

Yes, doing it in two steps sounds good.

I'm a bit concerned about making this call in vmix.F - vmix is after tend_tracer in time_integration? Maybe only move the computation of surfaceFrictionVelocity to ocn_diagnostic_solve? The computation of buoyancy flux and non-local surface fluxes can stay here in tend_tracer?

vanroekel commented 1 month ago

So here is my thinking. In the operator splitting we do here, vmix should be fully contained at the end and in the way we compute things everything going into KPP/GOTM (including u* and b_sfc) should be updated values at the end of the timestep. Right now we compute the nonlocal part of KPP based on partially updated buoyancy fluxes and the non local shape from the previous timestep. If we move this call to vmix we won't have this time offset anymore. So the move to later feels more consistent to me. What are your concerns in making the call after the main time step?

But it also occurs to me that calling this in vmix and diagnostic_solve is functionally equivalent. Diagnostic_solve is called right before vmix_implicit

qingli411 commented 1 month ago

OK. That makes sense now - I didn't realize there is a time offset between the shape function and surface buoyancy flux and was thinking that the non-local fluxes are needed by tend_tracer...

I was also a bit confused to see the computation of friction velocity in a subroutine called by tend_tracer. But moving that call to vmix_implicit will address that.