[MITgcm-devel] SFLUX

[Dimitris Menemenlis]

Jean-Michel, thank you for taking a look.

> I looked to the history of this SFLUX diagnostics:
> It seems to me that you coded the first version:
> MITgcm/pkg/diagnostics/Attic/diagnostics_fill_surf_flux.F
> And later on, I moved this file to model/src/diags_oceanic_surf_flux.F
> but did not change this "SFLUX" diagnostics.
> Do you remember why you defined SFLUX this way ?

Yes.  pkg/diagnostics/diagnostics_fill_surf_flux.F was mostly a carbon copy of 
pkg/timeave/timeave_surf_flux.F, which already included all the "#ifdef 
NONLIN_FRSURF" stuff.

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

> 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 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 ?

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.

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