[MITgcm-support] ptracer/DIC budget closure/calendar pkg

[Martin Losch]

Hi Hannah,

as far as I know, none of the output that is controlled by dumpFreq (or $PKG_dumpFreq) uses calendar dumps:

(base) bkli04m056::MITgcm (master)> grep CAL_TIME2DUMP pkg/*/*.F model/*/*.F
pkg/atm2d/atm2d_write_pickup.F:         CALL CAL_TIME2DUMP( zeroRL, pChkPtFreq, deltaTClock,
pkg/atm2d/atm2d_write_pickup.F:         CALL CAL_TIME2DUMP( zeroRL, chkPtFreq,  deltaTClock,
pkg/cal/cal_time2dump.F:      SUBROUTINE CAL_TIME2DUMP(
pkg/diagnostics/diagnostics_switch_onoff.F:          CALL CAL_TIME2DUMP( phiSec, freqSec, deltaTClock,
pkg/diagnostics/diagnostics_switch_onoff.F:          CALL CAL_TIME2DUMP( phiSec, freqSec, deltaTClock,
pkg/diagnostics/diagnostics_write_adj.F:            CALL CAL_TIME2DUMP( phiSec, freqSec, deltaTClock,
pkg/diagnostics/diagnostics_write.F:            CALL CAL_TIME2DUMP( phiSec, freqSec, deltaTClock,
pkg/diagnostics/diagnostics_write.F:            CALL CAL_TIME2DUMP( phiSec, freqSec, deltaTClock,
pkg/kpp/kpp_output.F:          CALL CAL_TIME2DUMP( zeroRL, KPP_taveFreq, deltaTClock,
pkg/seaice/seaice_jfnk.F:       CALL CAL_TIME2DUMP(
pkg/seaice/seaice_krylov.F:       CALL CAL_TIME2DUMP(
pkg/seaice/seaice_output.F:          CALL CAL_TIME2DUMP( ZERO, SEAICE_taveFreq, deltaTClock,
pkg/shelfice/shelfice_output.F:          CALL CAL_TIME2DUMP( zeroRL, SHELFICE_taveFreq, deltaTClock,
pkg/timeave/timeave_statv_write.F:         CALL CAL_TIME2DUMP( zeroRL, taveFreq, deltaTClock,
pkg/timeave/timeave_statvars.F:          CALL CAL_TIME2DUMP( zeroRL, taveFreq, deltaTClock,
model/src/do_write_pickup.F:         CALL CAL_TIME2DUMP( zeroRL, pChkPtFreq, deltaTClock,
model/src/do_write_pickup.F:         CALL CAL_TIME2DUMP( zeroRL, chkPtFreq,  deltaTClock,


This routine is only called for pickups and diagnostics (and some other routines, where the programmer, probably the same as the author of the email, was not aware of this convention). If you want to add it, I would start in model/src/do_the_model_io.F, which calls all of the “default” output such as write_state.F. 

Instead I recommend to use the diagnostics package for all output, especially when you want to close budgets. You can write avarages (with positive frequencies) and snapshots (with negative frequencies, for an daily snapshot of EtaN, including one at the beginning of the run you’d specify frequency = -86400., and timePhase = 0.), there are some examples in the verification experiments.
The main limitation of pkg/diagnostics is that is does only 3D and horizonal 2D fields and cannot handle vertical slices.

I try to answer some of your questions below and hope that other will also chip in.

Martin

> On 9. Jul 2025, at 10:30, Hannah Kleppin <hkleppin at marum.de> wrote:
> 
> Dear MITgcm-community,
> 
> I'm struggling closing an offline budget of some tracers (using package ptracer and a modified version of the DIC package). The residual between LHS (dTracer/dT, based on snapshots of Tracer) and the RHS (monthly averaged diffusive, advective and biological fluxes) is about an order of magnitude smaller than the actual tendency. I am using as well the package calendar to write output that corresponds to actual calendar month (calendarDumps = .TRUE. in data.cal). I realised now, that the calendar output is not implemented for ptracers and it seems also not to be effective for the snapshots of the state variables. This could possibly explain some offset in the budgets, since the advective, diffusive and biological flux output corresponds to the actual calendar month. For ptracer snapshot output I tried to implement the "Calndar dumps" in file ptracers_write_state.F by replacing lines 51-56 by
> 
> 
> #ifdef ALLOW_MNC
> dumpFiles=DIFFERENT_MULTIPLE(PTRACERS_dumpFreq,myTime,deltaTClock)
> 
> #ifdef ALLOW_CAL
>       IF ( useCAL ) THEN
>          CALL CAL_TIME2DUMP( zeroRL,PTRACERS_dumpFreq, deltaTClock,
>      U                       dumpFiles,
>      I                       myTime, myIter, myThid )
>       ENDIF
> #endif
> 
>       IF ((dumpFiles).OR.(dumpInitAndLast.AND.( myTime.EQ.endTime .OR.
>      &                             myTime.EQ.startTime ))) THEN
> 
> This works except that I don't have output on the first time step (the simulation is still running, so I don't know about the last time step yet).
> 
> Has anyone a suggestion why I don't get output at the first time step?
> 
> Could  someone point me to where this would need to be implemented in order to write calendar snapshots of eta?
> 
> Shouldn't there be a warning in the calendar package documentation that it is not implemented for all packages? (I know "Always look at your meta data, ...” )
I guess, adding a sentence on the scope would not be a bad idea, currently the documentation does not even describe the available runtime parameters, so feel free to submit a PR (o:
> 
> Other questions that are relevant for my budget calculations:
> 
> Is it true that there is no diagnostics available that contains the OBCS contribution to ptracers (RBCS contribution seems to be in the diagnostic ForcTr**)

The obcs-pkg does not compute tendencies, but just resets the tracer on the boundary.

> Is the resetting of negative tracer values in DIC and Bling somehow tracked?
Don’t know, probably not. In pkg/ggl90/ggl90_calc.F there’s an example how to track the implied tendency of resetting a value to a minimum value (diagnostic GGL90Emn).

> 
> Any suggestions are greatly appreciated.
> 
> Cheers,
> 
> Hannah
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20250709/d6de2b0b/attachment-0001.html>