MITgcm / MITgcm

M.I.T General Circulation Model master code and documentation repository
http://mitgcm.org/
MIT License
326 stars 240 forks source link

sFld argument in FIND_RHO_2D #241

Open menemenlis opened 5 years ago

menemenlis commented 5 years ago

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, ...

edoddridge commented 4 years ago

This makes sense to me.

mjlosch commented 4 years ago

@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

jm-c commented 4 years ago

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

ifdef CHECK_SALINITY_FOR_NEGATIVE_VALUES, like this:

  SUBROUTINE FIND_RHO_2D(
 I                iMin, iMax, jMin, jMax, kRef,

ifdef CHECK_SALINITY_FOR_NEGATIVE_VALUES

 I                tFld, 
 U                sFld,

else

 I                tFld, sFld,

endif

 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 of S/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