adjoint_options files

[mjlosch]

Currently we have 4 slightly different files with AD options for TAF/TAMC and one for TAMC only (adjoint_tamc_compatibility) in tools/adjoint_options and two more local copies in local code_ad directories:

• "adjoint_default" and adjoint_f95 differ only in the flag "-f95" instead of "-f77" or "-f90"
• "adjoint_state_file" is not tested (used for "SVD"), but is contains only two relevant differences to the default file..
• "adjoint_diva" sets an extra flag (DIVA='true', not sure where that is used), an extra "-pure" option and includes mpi-header files in the list of files shown to TAF (something that TAF has difficulties with since version 4.9.10)
• I have no idea, when "adjoint_tamc_compatibility" was used the last time, and if it will ever be used again, but the main difference I see there is are "-v1 -nonew_arg" flags.

I found 4 "genmake_local" files that contain flags relevant for the AD, pointing to two local ad_optfile.local (in bottom_ctrl_5x5, tutorial_dic_adjoffline); the genmake_local files in verification_other have no relevance for AD:

• bottom_ctrl_5x5/build/genmake_local (points to ../code_ad/ad_optfile.local mainly for the taf option "-e", and USE_EXTENDED_SRC='t')
• halfpipe_streamice/build/genmake_local (ALWAYS_USE_F90=1, and AD_OPTFILE='../../../tools/adjoint_options/adjoint_f95', which is a contradiction)
• lab_sea/build/genmake_local (points to ../../../tools/adjoint_options/adjoint_diva and commented #TAF_EXTRA='-version 2.9.3')
• tutorial_dic_adjoffline/build/genmake_local (points to ../code_ad/ad_optfile.local, because of a xx_dic ctrl variable that no longer is used and will be removed together with ECCO_CTRL_DEPRECTATED)

All six different build options files can be easily combined into one, and the different options can be controlled via flags in genmake_local, e.g. TAF_EXTRA or new flags like ALWAYS_USE_F90, USE_DIVA (I tried this successfully here: https://github.com/mjlosch/MITgcm/tree/preproc_adjoint). This would be much simpler to maintain, especially in the light of the ECCO_CTRL_DEPRECTATED flag, the removal of which will make the list of control variables considerably shorter. I assume that we want to have an example of specifying a specific AD_OPTFILE, but that could still be done, by having one experiment point at the default explicitly.

I suggest two options and would be happy for your opinion:

1. do nothing, never change a running system
2. merge options files into one and adjust genmake_local files (this would be done after getting rid of ECCO_CTRL_DEPRECTATED code), with details to be discussed.

[timothyas]

I think it makes sense to merge the files and just adjust the genmake_local files. I remember being confused early on about why there are all those different adjoint option files. Merging means less to maintain, and less for other people to get confused about

[jm-c]

I agree that it would be good to have fewer AD optfiles (not sure about removing the SVD one). But in term of timing, I think it would be better to merge this future PR after we do the last checkpoint that support the ECCO_CTRL_DEPRECTATED. But it does not prevent us to make these changes sooner, in a new PR (just that it will not be merged right away).

[mjlosch]

Since the SVD file is never tested, it's hard to know if my attempt (with a "USE_SVD") would work, but the differences to the default file are minimal (see https://github.com/mjlosch/MITgcm/blob/preproc_adjoint/tools/adjoint_options/adjoint_default, l67-l72)

Clearly, merging the files does not make any sense before the ECCO_CTRL_DEPRECTATED is removed.

[jm-c]

An other thing we could remove (or better: comment out) from the ad-optfile is the "-server" setting:

1. it's better and cleaner to rely on what "staf" does.
2. if someone want to use "fastopt.net" as a default, it just involves changing 1 line in "staf" script (i.e., the default server).
3. It's confusing when trying to use some ot "staf" options to set the server while it's also set in the ad-optfile, because it's not obvious which setting will be used at the end (+ some info reported to screen/log-file might be misleading).

[mjlosch]

merged PR #649 addresses this issue, so we can close it.