[MITgcm-devel] SFLUX

[Jean-Michel Campin]

Hi Dimitris,

On Sun, Nov 12, 2006 at 10:35:07PM -0800, Dimitris Menemenlis wrote:
> 
> >I am not 100% sure, but this older version (before your latest
> >change) should match the evolution of the salt content
> >(and we can agree that it should be like this, in the same way
> >as TFLUX should match the evolution of the heat content).
> 
> I agree.  I think it was a mistake on my part to comment out the "#ifdef 
> NONLIN_FRSURF" section for SFLUX and that code should remain as it was 
> before latest change.
> 

> >Now, it would be better (and also easier to understand)
> >to make the distinction
> >IF (temp_EvPrRn.EQ.UNSET_RL) THEN / ELSE / ENDIF
> >and
> >IF (salt_EvPrRn.EQ.UNSET_RL) THEN / ELSE / ENDIF
> 
> I don't understand above.
> 
OK, this later comment is wrong, so just forget it.

> >Not directly related to SFLUX:
> >The diagnostics that I would like to add (with filling calls in
> >diags_oceanic_surf_flux.F) are for Qnet, EmPmR, saltFlux
> 
I think we need "direct" diagnostics of oceanic forcing, 
after sea-ice modification, and neither exf or bulkf diagnostics
provide this information.
I recognize that it is usefull to have other (not direct) diagnostics
like SFLUX, TFLUX, but we just need to decide what they actually are.

> I agree but
> 
> 1) isn't SFLUX above, prior to latest change, exactly equal to saltFlux, 
> virtual or real depending on the runtime options?  Should we rename 
> pkg/diagnostics "SFLUX" and call it "saltFlux" to clarify its meaning and 
> to differentiate it from variable SFLUX in pkg/exf ?
> 
right now, saltFlux is the salt flux (comming from melting/freezing of
sea-ice), does not include restoring neither EmPmR virtual salt flux.
If we add this new diagnostics, it should not be called "saltFlux",
since it's different from the model varable.

> 2) Instead of EmPmR, should we instead output a variable called 
> "freshWaterFlux"?  So over open water, and assuming that rain, evaporation, 
> and runoff have zero salt content, EmPmR would be included in saltFlux for 
> virtual salt flux and in freshWaterFlux for real freshwater flux, but never 
> in both.
> 

I am not really in favor of this solution:
a) instead of 1 diagnostic (SFLUX) that change according to
what option we use, we would have 2. 
b) freshWaterFlux would be either zero, or equal to EmPmR.
is it really necessary to add this one ?

An other possibility would be to diagnose directly 
surfaceForcingT & surfaceForcingS, with, for convenience, some 
conversion factor (in fact, exactly what SFLUX is now, with those
lines commented out). Those 2 diags would be usefull, and convenient 
(related to surface temperature/salinity effect). The problem
is that they don't match the temperature/salt budget evolution
(as oppose to TFLUX & SFLUX) which cannot be computed from the
other diagnostics (at least for temperature, since the heat flux 
associated with P-E would be missing).

> >(in addition to Qsw, tRelax & sRelax, taux & tauy) to have
> >the complete set of oceanic forcing diagnostics
> >(and after I could remove the pkg/thsice diagnostics:
> >SIflx2oc, SIfrw2oc, SIsaltFx).
> 
> OK, and there are a bunch of pkg/seaice and pkg/exf diagnostics that are 
> also somewhat redundant.  Here is a pkg/seaice-centric summary of situation 
> since latest (7 nov 2006) change:
> 
> C     pkg/diagnostics SIfu and TAUX, dumpfreq FU, and tavefreq FUtave
> C     are identical but they differ from pkg/diagnostics EXFtaux, which
> C     is stress before impact of ice.  Also when using exf bulk
> C     formulae, EXFtaux is defined on tracer rather than uvel points.
> 
> C     pkg/diagnostics SIfv and TAUY, dumpfreq FV, and tavefreq FVtave
> C     are identical but they differ from pkg/diagnostics EXFtauy, which
> C     is stress before impact of ice.  Also when using exf bulk
> C     formulae, EXFtauy is defined on tracer rather than vvel points.
> 
> C     pkg/diagnostics SIempmr, dumpfreq EmPmR, and tavefreq EmPmRtave
> C     are identical but they differ from pkg/diagnostics EXFempmr, which
> C     is EmPmR before impact of ice.
> C     pkg/diagnostics SIempmr is also, depending on various options,
> C     approximately equal to (SFLUX-SRELAX)/rhoConstFresh/salt(k=1),
> C     but note that prior to latest (7 nov 2006) change SFLUX was
> C     identical to SRELAX for
> C        (nonlinFreeSurf.GT.0 .OR. usingPCoords)
> C        .AND. useRealFreshWaterFlux .AND. salt_EvPrRn.EQ.0
> 
> C     SIqnet, Qnet, and QNETtave are identical.
> C     With #undef NONLIN_FRSURF SIqnet is identical to -(TFLUX-TRELAX).
> C     Except over land and under sea ice, SIqnet is also identical to
> C     EXFlwnet+EXFswnet-EXFhl-EXFhs.
> 
> C     SIqsw, Qsw, and QSWtave are identical.
> C     Except under sea ice, SIqsw is also identical to EXFswnet.
> 

May be we can sort out the "main" oceanic diagnostics first and later
on, remove the multiple copy (if identical) in pkgs sea-ice & thsice.
But regarding exf & bulkf diag., since they are always different from 
the main diag. over sea-ice, we propably need to keep them.

Jean-Michel