cleaning tamc.h : collect previous comments

[jm-c]

In PR #579 discussion, removing some un-used parameters within "tamc.h" was mentionned but postponed until "nthreads_chkpt" could also be removed (after removing it from tape initialisations).
Raise this issue here to give this task more visibility (+ also as a reminder).

The relevant part in the discussion were:
#579 (comment)
and
#579 (comment)

[mjlosch]

@jm-c could you please explain, for reference, why nthreads_chkpt should never be different from 1? Is It because the number of threads (i.e. nTx*nTy) always needs to be < nSx*nSy, and since nSx and nSy are already considered in the size of the tapes?

[mjlosch]

I suggest a (draft) PR where we remove nthreads_chkpt from the_main_loop.F (the only place where it is used) and agree on the form of the reference tamc.h and then adjust all 19 verification-tamc.h (and the verification_other ones). I can start this PR if desired.

[jm-c]

Regarding nthreads_chkpt , you are right: each time it appears in the code (in: the_main_loop.F and in pkg/smooth/smooth_diff2/3d.F) it's multiplied by nSx*nSy. But whether we run single thread or mutlple threads, the size of multi-tile arrays don't change, always nSx*nSy tiles per proc. So there is no need to reserve more space than the array size.
And in the case where we would need to store a common block array such as the ones in pkg/aim_v23/ (e.g., in AIM_GRID.h, com_forcing.h or com_physvar.h) with the last dimension function of the maximum number of threads "MAX_NO_THREADS" instead of the number of tiles "nSx*nSy", we would not use the product of both but instead either one or the other (MAX_NO_THREADS or nSx*nSy).

[jm-c]

@mjlosch I agree with your plan for a draft PR.

[jm-c]

An other simplification we could do when computing "key" to store a single tile array:
The key setting involves the tile indices bi,bj (as it should), but in a complicated way, for instance, see

MITgcm/model/src/convective_adjustment.F

Line 104 in 1575dc0

ikey = (act1 + 1) + act2*max1

grouping the tiles by thread.
This ordering is not necessary (if we were running multi-threads, they would not run sequentially anyway) and we could just use simply the tile indices bi,bj:
ikey = bi + (bj - 1)*nSx + (ikey_dynamics - 1)*nSx*nSy

[mjlosch]

Thanks for this suggestion! The key computation was always hard for my to understand, but I never dared to touch this in fear of breaking something that was well tested.
There are a few places where I introduced new key computations, and I already did them in the way similar to your suggestions, e.g. here:

MITgcm/pkg/thsice/thsice_advection.F

Line 276 in 1575dc0

ipasskey = ipass + (ticekey-1) * maxcube

So I am all for it!