[MITgcm-devel] Re: saltFlux in FFIELDS.h

[Dimitris Menemenlis]

Jean Michel,

> I'am trying to use z* and realFresWaterFlux with sea-ice.
> And for this reason, it seems to me better to separe
> the salt flux that is associated with sea-ice formation/melting
> (because sea-ice contains salt) from the fresf water flux.

> My plan was not to make "big changes" (right now, saltFlux is just
> set to zero and that's all) until you give your opinion 
> about the saltFlux and see how things can be implemented 
> to work with both seaice and therm_seaice.

I agree that this a good idea.  It will be no problem modifying
pkg/seaice to work with this new input field.  I already have this on my
to-do list.

> I am just starting the modifications and will not check-in things
> soon. But I also wants to use EXTERNAL_FORCING_SURF 
> with therm_seaice and the fact it moves to forward_step was
> a litle anoying for the moment.

> And sorry not answering your e-mail (posted on 25 Sept)
> but the point is that Alistair always wanted to get rid of
> EXTERNAL_FORCING_SURF, so I don't known where we are going.

I agree that EXTERNAL_FORCING_SURF is annoying.  But it's much better
than how it used to be, i.e., recomputation of net surface fluxes from
scratch every time you needed them.

EXTERNAL_FORCING_SURF was originally included inside what was then known
as DYNAMICS (before the split between DYNAMICS and THERMODYNAMICS)
because it needed to happen after the correction step.  Now that the
correction step has been moved to the end of FORWARD_STEP, there is no
reason for EXTERNAL_FORCING_SURF to remain there.  It's very confusing
for new users and even for old timers (for example, Steph's and Martin's
recent problems in setting up ptracers_forcing).

The logical place for EXTERNAL_FORCING_SURF is to group it with all the
other routines that read-in and/or compute oceanic surface fluxes:
BULKF_FORCING, EXF_GETFORCING, EXTERNAL_FIELDS_LOAD, SEAICE_MODEL,
FREEZE, GCHEM_FIELDS_LOAD, etc.  Also ICE_FORCING and ICE_FREEZE
logically belong in that cluster, not inside THERMODYNAMICS.

> Regarding the sign convention, I feel a litle bit confused
> when the wind stress has the opposite sign of the wind.
> (O.K., might be easy to see on a Lat-Long grid, but on the 
> cube, it's not obvious to detect immediately on a 6 faces
> plot). I think that we can discuss also this point next week,
> if its o.k. for you.

For existing users changing the sign yet one more time will be a pain. 
But for new users and for release 2, a consistent convention might be
nice.  My preference (as seems to be yours from above) is to have all
the fluxes ocean-centric, i.e., positive flux means increase in the
corresponding ocean variable.  That convention would mean reversing sign
convention for variables saltFlux, Qnet, and Qsw.

Dimitris

-- 
Dimitris Menemenlis <menemenlis at jpl.nasa.gov>
Jet Propulsion Lab, California Insitute of Technology
MS 300-323, 4800 Oak Grove Dr, Pasadena CA 91109-8099
tel: 818-354-1656;  fax: 818-393-6720