[MITgcm-support] Objective Function for Ptracers

[Yohei Takano - BAS]

Hi Martin,

Thank you for following up, and yes, I see many different flags to consider...

Good to confirm that the flags will NOT impact the forward part of the simulations, and I understand the assumptions behind
by turning the flags to FALSE.  As you suggested I think I should try  useGGL90inAdMode = .TRUE., (for now this is false for my
adjoint sensitivity runs) but need to check the GMRedi options used in ECCOv4. Thank you also for the information on pkg/seaice.

Currently I am testing the adjoint with short simulations so will try running with flags and compare the gradients.

Regards,

Yohei


________________________________
From: MITgcm-support <mitgcm-support-bounces at mitgcm.org> on behalf of Martin Losch <Martin.Losch at awi.de>
Sent: 12 November 2024 12:42
To: MITgcm Support <mitgcm-support at mitgcm.org>
Subject: Re: [MITgcm-support] Objective Function for Ptracers

Hi Yohei,

I am glad that you could solve your problem. Often there are too many different flags to consider and even as an experienced user I stumble over this type of stuff …

The “use***inAdMode” flags were put in place to circumvent unstable AD-code. When these flags are set to FALSE, the corresponding code is only run in the forward part of the model (ie. when computing the cost function and the tapes etc.), but they area not used to compute the gradients. That is with useKPPinADMode=F, the KPP code will have no explicit contribution to the gradient (sensitivities), but will only determined the forward trajectory around which the model is linearized. This means that the gradients are not correct, but most of the time the small errors incrurred are the smaller evil (as opposed to a crashing run).

The AD code of KPP is relatively unstable (I was able to use it in short integrations), but you could use GGL90 instead, which should have a working (stable) adjoint. For GMredi there are also stable versions (there are many different options, again). The pkg/seaice has a stable AD thermodynamics, but the dynamics really don’t work in my experience.

I would just try if the code runs without these flags, maybe for a shorter integration, and compare the gradients to get a feeling for size of differences.

Martin

On 12. Nov 2024, at 13:09, Yohei Takano - BAS <yokano at bas.ac.uk> wrote:

Hi all,

   I think I found a solution (moreover a mistake), some how my  AUTODIFF option
was turned off but after I turned this on,

useAUTODIFF  =  .TRUE.,

   the model starts to generate the objective function file (although beside this file generation
everything seems to be proceeding (i.e. the model did not crash) so it took me some time to figure out.

   Actually this is a good timing to also follow up and ask about AUTODIFF, so in data.autodiff,
I usually turn KPP/Redi off in adjoint mode (according to my colleague, for a numerical stability reason)

 “useKPPinAdMode =  .FALSE.,”
 “useGMRediInAdMode  =  .FALSE.,”

   ... but is this the general approach for adjoint simulations (like in ECCOv4 or other setups)?
I am wondering whether this has an impact on the results etc. Hope I can understand more on what is behind.

Sincerely,

Yohei












________________________________
From: Yohei Takano - BAS
Sent: 12 November 2024 10:21
To: mitgcm-support at mitgcm.org <mitgcm-support at mitgcm.org>
Subject: Objective Function for Ptracers

Dear all,

   I am trying to run adjoint simulations using  Ptracers as an objective function in ECCOv4 framework.
Pkg/ecco has capability using Ptracers as an objective function (setting data.ecco) and
I set gencost_barfile(1) = 'm_boxmean_ptracer', and gencost_itracer(1) = 1 to define
box mean ptracer (tracer #1) as an objective function.

   However, unlike temperature and salinity, the model does not generate adm_ file for Ptracers.
(Here is an error I obtained).

(PID.TID 0000.0001) *** ERROR ***  MDS_READ_FIELD: filename: adm_boxmean_ptracer.0000000012.data
(PID.TID 0000.0001) *** ERROR ***  MDS_READ_FIELD: File does not exist

   I thought "adm_boxmean_ptracer.0000000012.data" should be automatically generated so I was wondering
I forgot to turn some settings on (or off) (and I looked at the codes and 'm_boxmean_ptracer' option exists).
The setup is based on ECCOv4r2 + Ptracers and pkg/dic turned on. The MITgcm checkpoint is 67z.

   Does anyone know a reason why adm_ file is not generate for Ptracers (again it works for "m_boxmean_theta"
and ? (and costfunction0012 contains value for Ptracers). I will also attach the data.ecco below.
Thank you in advance.

Regards,

Yohei

----- data.ecco -----

# *******************
# ECCO Cost Functions
# *******************
 &ECCO_COST_NML
 &
# ***************************
# ECCO Generic Cost Functions
# ***************************
 &ECCO_GENCOST_NML
 gencost_name(1) = 'ptracer_ad',
 gencost_barfile(1) = 'm_boxmean_ptracer',
 gencost_avgperiod(1) = 'month',
 gencost_itracer(1) = 1,
 gencost_msk_is3d(1)=.TRUE.,
 gencost_outputlevel(1) = 1,
 gencost_mask(1) = 'mask',
 mult_gencost(1) = 1.0D9,
 &
#




This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.

_______________________________________________
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/20241112/c930eab0/attachment-0001.html>