Closed qingli411 closed 1 week 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.
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?
Oh, GOTM uses this as well? That's more problematic.
I think we should do a two step process.
KPP_input_fields
above that if statement and change the if on L1248 to if(config_cvmix .or. config_gotm)
I suggest this way as we can keep our current v3 simulations BFB
What do you think?
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
?
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
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.
@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 fieldssurfaceBuoyancyForcing
andsurfaceFrictionVelocity
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