[MITgcm-support] Mass balance... again...
Stefano Querin
squerin at ogs.trieste.it
Mon Jun 28 11:27:39 EDT 2010
Dear MITgcmers, dear Martin,
we figured out which were the problems we were encountering a few days
ago when checking the mass balance in our simulations.
- the discrepancy in the salt budget of the first 5-8 subsurface cells
is due to the fact that we are using checkpoint61t, that comes without
the new diagnostic for KPP flux (KPPg_SLT). In fact, we calculate off-
line the KPP flux as the product of the three (time-averaged) saved
terms: KPPdiffKzS, KPPghat and surfaceForcingS. That is obviously an
approximation of the real df term in KPP_TRANSPORT_S.F
- the discrepancy in the salt budget of the first cell (surface layer)
is due to the fact that using:
1. nonHydrostatic=.TRUE. (=> linear free surface)
2. useRealFreshwaterFlux=.TRUE.
3. selectAddFluid =1
4. exactConserv=.TRUE.
the following run-time option should be set TRUE:
5. linFSConserveTr=.TRUE. (FALSE by default)
Otherwise the salinity of the surface layer will not be conserved in
case of changes of Eta (w(k=1) not equal to zero).
We are wondering if a warning should be added in CONFIG_CHECK.F when
imposing mass conservation (as specified above: options 1., 2., 3. and
4.) without using nonlinearfreesurface and keeping
linFSConservaTS=.FALSE.
However, we note that linFSConserveTr affects only the suface cell
tendency of T and S. It doesn't have any affect on passive tracers.
We think that, in order to conserve the mass balance for ptracers as
well, the code related to the linFSConserveTr term should be added to
the ptracer-related routines.
We are modifying our version of the model (starting from
checkpoint61t) coding this part.
Please tell us if you think there is another (better) way to impose
the mass conservation for tracers in the surface layer.
Thank you!
Cheers,
GP and S
On 17 Jun 2010, at 10:59:21, Martin Losch wrote:
> Dear Gianpiero and Stefano,
>
> I have no idea what going wrong, but maybe you can narrow down your
> problem by switching off parts of the code (e.g. KPP, implicit
> diffusion, surface forcing, in that order).
>
> These are also candidates
>> selectAddFluid =1 (=0 off)
>
>> kpp_freq = 300.
>
> Martin
>
> On Jun 16, 2010, at 5:25 PM, Stefano Querin wrote:
>
>> Dear MITgcmers,
>>
>> we are still working to compute the exact mass balance of a passive
>> tracer for a single cell due to advection-diffusion (no source, no
>> sink).
>>
>> We use salinity as a generic passive tracer.
>> We consider the following terms for a given cell (i,j,k), for a
>> given time period:
>>
>> - the values of ADVx and DFxE at i and i+1 as zonal fluxes at the 2
>> cell boundaries;
>> - the values of ADVy and DFyE at j and j+1 as meridional fluxes at
>> the 2 cell boundaries;
>> - the values of ADVr and DFyI at k and k+1 as vertical fluxes at
>> the upper and lower cell boundary;
>> - the KPP non local transport terms at k and k+1 as additional
>> vertical fluxes at the upper and lower cell boundary;
>> - the surfaceForcing term.
>>
>> All these fluxes are time averages (diagnostic dump frequency > 0).
>>
>> We compute the sum of these terms (changing the sign for i+1, j+1
>> and k fluxes). The resulting value, multiplied by the time
>> interval, should give the net variation of the tracer mass
>> (salinity) in the cell.
>> However, this result is not equal to the difference of the salinity
>> values at the two consecutive snapshot outputs (diagnostic dump
>> frequency for salinity field < 0), multiplied by the cell volume.
>> In other words, the mass difference between two dump times
>> (snapshots) is not equal to the sum of the average fluxes between
>> the two snapshots.
>> We observed that:
>>
>> - the balance is heavily not conserved for the surface cell;
>> - the balance is not conserved for a number of subsurface cells
>> (5-8 over 51 layers) but with much smaller error than that of the
>> surface layer;
>> - the balance shows negligible differences for the remaining cells
>> of the water column.
>>
>> Is anybody able to find out if and what we are missing in our
>> computations?
>>
>> We report below the most relevant parameters we changed in the
>> namelists and we attach the full namelist files for sake of clarity.
>> Then, we shortly summarize what we think the model is doing for
>> computing the transport terms and for saving them.
>>
>> Thanks for your help (and sorry for the long email...)!
>>
>> Cheers!
>>
>> Gianpiero and Stefano
>>
>>
>> ------------------------------------------------------------------------
>>
>> Run configuration:
>>
>> MITgcmUV version: checkpoint61t
>>
>> Parameters:
>>
>> deltaT=300.,
>> implicitDiffusion=.TRUE.,
>> implicitViscosity=.TRUE.,
>> nonHydrostatic=.TRUE.,
>> useNHMTerms=.TRUE.,
>> useRealFreshwaterFlux=.TRUE.,
>> selectAddFluid=1,
>> saltAdvScheme=33,
>> saltVertAdvScheme =33
>> exactConserv=T
>> selectAddFluid =1 (=0 off)
>> useRealFreshWaterFlux =T
>> staggerTimeStep =T
>>
>> Packages used:
>>
>> useOBCS=.TRUE.,
>> useKPP=.TRUE.,
>> useMNC=.FALSE.,
>> useGMRedi=.FALSE.
>>
>> KPP parameters
>>
>> kpp_freq = 300.,
>>
>>
>> With this configuration the transport terms are computed and saved
>> in THERMODYNAMICS as follows (as far as we understand…):
>>
>> 1. advection terms are computed in GAD_ADVECTION for x, y and r
>> directions. A temporary term (TlocalTij) is computed after each of
>> the 3 advection terms. Then a tendency (gS) is calculated as the
>> difference between the former value and the last temporary term
>> (divided by deltaTlev).
>> Advection terms are temporary stored in afx, afy and fVerT which
>> are then passed to the diagnostic ADVx, ADVy and ADVr.
>> However, extra terms (Tracer*u,v,rTrans) are computed in the
>> equations for TlocalTij. Which is the meaning of these extra terms?
>> And are they passed to the diagnostic tool somehow?
>>
>> A do loop in the vertical direction starts here.
>>
>> 2. Horizontal explicit diffusion is computed in GAD_CALC_RHS and
>> the terms fZon and fMer are passed to the diagnostics variables
>> DFxE ad DFyE.
>>
>> 3. The KPP mixing term is computed in GAD_CALC_RHS using KPPdifKzS,
>> KPPghat and surfaceForcingS and temporary stored in fVert. The
>> terms KPPdifKzS and KPPghat are passed to the diagnostic tool,
>> while surfaceForcingsS is passed to the diagnostic tool in
>> DIAG_OCEANIC_SURF_FLUX which in turn is called by DO_OCEANIC_PHYS.
>>
>> 4. The tendency gS is augmented by the terms fZon, fMer and fVert.
>>
>> 5. In EXTERNAL_FORCING_S the tendency gS for k=1 is increased by
>> the surfaceForcingS term.
>>
>> 6. TIMESTEP_TRACERS computes gS as the new term of salinity using
>> the previous term and the tendency.
>>
>> End of the do loop.
>>
>> 7. The vertical implicit diffusion is computed in IMPLDIFF, the new
>> term of gS is updated and diagnostic term DFrI is computed.
>>
>> ------------------------------------------------------------------------
>>
>> <
>> data
>> .diagnostics_slt
>> >
>> <
>> data
>> >
>> <
>> data
>> .exf
>> >
>> <
>> data
>> .obcs
>> >
>> <
>> data
>> .cal
>> ><data.pkg><data.kpp>_______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
More information about the MITgcm-support
mailing list