Open menemenlis opened 5 years ago
This makes sense to me.
@menemenlis As far as I remember, this flag was introduced as a hack to make sure that we never have negative salinities that would bomb sqrt(sFld)
. Maybe it would make more sense to remove this call here and add once in beginning the timestep, before find_rho is called for the first time, e.g. at the beginning of S/R do_oceanic_physics
The location of this call to LOOK_FOR_NEG_SALINITY is not ideal: a) if we really want to reset negative salinity to zero, I agree with Martin (@mjlosch) it would be better outside FIND_RHO_2D (like FREEZE_SURFACE, which, BTW, is not a great name). b) if the only reason of this CHECK_SALINITY_FOR_NEGATIVE_VALUES is to prevent problems in density computation, then we could change the behavior to just compute density from MAX(0, sFld) (when CHECK_SALINITY_FOR_NEGATIVE_VALUES is defined). Would not be difficult to change since it's a CPP option. Otherwise, if we just follow Dimitris' (@menemenlis) recommendation with no other code change than continuation line switch from "I" to "U", I would suggest to put it within
SUBROUTINE FIND_RHO_2D(
I iMin, iMax, jMin, jMax, kRef,
I tFld,
U sFld,
I tFld, sFld,
O rhoLoc,
I k, bi, bj, myThid )
On Sun, Nov 10, 2019 at 10:25:18PM -0800, Martin Losch wrote:
@menemenlis As far as I remember, this flag was introduced as a hack to make sure that we never have negative salinities that would bomb
sqrt(sFld)
. Maybe it would make more sense to remove this call here and add once in beginning the timestep, before find_rho is called for the first time, e.g. at the beginning ofS/R do_oceanic_physics
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/MITgcm/MITgcm/issues/241#issuecomment-552310563
The CHECK_SALINITY_FOR_NEGATIVE_VALUES flag can modify sFld Shall we switch the description of argument from "I" to "U", i.e., SUBROUTINE FIND_RHO_2D( I iMin, iMax, jMin, jMax, kRef, I tFld, U sFld, ...