[MITgcm-devel] SFLUX

Mon Nov 13 22:09:48 EST 2006

Hi there,

I agree that we should first sort out diagnostics for
model core, and deal with packages later.
Since we even have a bulk formula/seaice setup 
(without underlying ocean, just prescribed SST),
some redundancy in diagnostics is not necessarily bad.

Re. names, all 1st choices sound good to me.

Re. EXFtaux, EXFtauy,
a bit unfortunate that they are on center cells
for ALLOW_BULKFORMULAE since they're later
properly interpolated onto W/S faces.
Maybe we should do consistent interpolation
for diagnostic as well?

-p.

On Mon, 2006-11-13 at 15:06, Jean-Michel Campin wrote:
> 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
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
-- 
Dr Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS, 54-1518 | 77 Massachusetts Ave | Cambridge, MA 02139, USA
FON: +1-617-253-5259 | FAX: +1-617-253-4464 | SKYPE: patrick.heimbach