bug in store directives in pkg/bling

[mjlosch]

It is very likely that the TAF store directives in pkg/bling/blink_light.F are wrong:

1. 3D fields are saved within i,j,k loops, where it would only make sense to save individual values
2. only a tile dependent key tkey is used for this instead of on that depends on all 3 loop indices
3. store directives are incomplete if the nonlinear free surface is turned on (irr_inst causes recomputations)

Further, the k-loop is the innermost loop which makes this routine more difficult to handle w.r.t. TAF store directives. Most of the code seems to be prepared to push the k-loop to the outside, but not everything (e.g. ML_MEAN_LIGHT code).

Maybe @mmazloff wants to have a look at this?

[averdy]

Thanks, I'm looking into this. Looks like we should either save the 3D fields outside of the loops, or use a different key. Any thoughts on which is best?

[mjlosch]

@averdy, I didn't know if you still used this code for AD-simulations, that's why I didn't just go ahead and suggest something. In our verification experiments, pkg/bling is only used in global_oce_biogeo_latlon, and in this experiments the cpp-flags are set in a way that no storing is necessary (in particular #undef PHYTO_SELF_SHADING). When I use global_oce_biogeo_latlon and define PHYTO_SELF_SHADING, then I get about 18 recomputation warnings (which is very easy to fix with a few store directives). Do you have a configuration, where you actually use this part of the code? Otherwise it makes little sense to invest time here. If you do need this code, I would do this (but it's not my code, so it's up to you):

1. rewrite the code so that the k-loop is outside for better vectorisation (and in-line with most of the other code in the MITgcm), this may already make it unnecessary to use STORE directives in some instances. I am not even sure, if you need 3D fields irr_bg.
2. There may be some interaction with my PR penetrating shortwave fraction as a 3D-field #750 where I define a global swfrac field (that could be set here in bling_light.F), maybe you want to review that PR, please?
3. after rewriting, it would be easy to store 2D fields (or maybe even 3D-fields)
4. If you don't want to do this, it should be possible keep the current code unchanged and to use "ijk-keys" and store in each loop iteration, see e.g. tape comlev1_mom_ijk_loop in mom_calc_visc.F. What important is that you make sure that the gradients are the same without storing and with storing these variables (one can mess up the gradients with specifying the wrong keys, and the reference is almost always the solution with recomputations).