iHAMOCC structure for reading climatology input data from files

[TomasTorsvik]

In iHAMOCC there is not a clear convention for reading climatology input data from files. For n-deposition this is done in three stages:

1. read input data in hamocc_init : call ini_ndep
2. get data for current month in hamocc_step : call get_ndep
3. compute the N-deposition in hamocc4bcm : call n-deposition

For swa_clim short-wave climatology, it is assumed that there is no temporal variation, only grid dependence.

For surface PI pH field used to compute pH dependent DMS, the input file is specified as MONTHLY_PI_PH.nc, which is read in hamocc_init and used in ocprod. This input data is assumed to be monthly climatology.

River input does not include temporal variation, only grid dependence.

Some questions / considerations / suggestions:

1. Should all temporal dependencies be handled within hamocc_step? The temporal information flows from BLOM to iHAMOCC. Could we separate all processes that depends on specific year-month-day in a separate routine in hamocc_step, before calling hamocc4bcm? Would this be a useful structure to aim for?
2. Should we create a structure that will allow all input climatology fields to have a monthly variability? Should we accommodate a more generalized input data structure (yearly or yearly-monthly climatology)?
3. Should we make a generalized structure for all climatology input files, or create solutions on a case-by-case basis? Different input data may have different structure (e.g. 2D, 3D), but all input data should already be interpolated on the model grid.
4. Should we support / enforce a specific input data naming convention or directory structure to inform about the spatial (grid) and temporal specifications?

[JorgSchwinger]

I think this makes it unnecessarily complicated. There are only two instances of climatoliogical fields (dms ph and swa), and I can't see that there will be many more in the future. Regarding the general structure I think we should stick to how it is done in n-dep and riverinput (and fe-dep, except that this field is currently constant and there is no need to have a get_fedep function called in hamocc_step).

[TomasTorsvik]

Regarding pt. 1 above, at the moment get_cfc is the only subroutine in hamoc4bcm that has a temporal dependency (yearly data). If pi_ph is implemented as n-dep we can remove the monthly dependency for get_dmsph.

I think get_cfc can be moved to hamocc_step and that will remove the need to pass the date information through hamocc4bcm. Would this be useful?

[jmaerz]

Outdated with the move to NUOPC and CDEPS usage.