Add a timescale to DGLC ice discharge

[Katetc]

Based on thoughts from this new paper, the land ice team wants to try adding a 10-year (or otherwise adjustable) time lag to ice fluxes from DGLC to the runoff model. The thought is that this could reduce some of the immediate cold water fluxes into the lab sea area and reduce freezing.

The sea ice team has also suggested improved seasonality of freshwater fluxes from DGLC. In other words, instead of releasing ice fluxes equally each month, release most of the water in the summer. Part of this project will be an analysis of the feasibility of that request.

[Katetc]

Note, because DGLC only couples once a year, it is really not possible for this code to affect seasonality. I think the "break up the flux into 12 equal parts" code is in the coupler, so that is where we would need to add seasonality.

[mvertens]

@Katetc - I believe that DGLC couples daily not once a year. Out of the box (at least for NorESM) I am getting the following for a fully active configuration with DGLC%NOEVOLVE.

	ATM_NCPL: 48
	GLC_NCPL: 1
	ICE_NCPL: 48
	LND_NCPL: 48
	NCPL_BASE_PERIOD: day
	OCN_NCPL: 24
	ROF_NCPL: 8
	WAV_NCPL: 48

[Katetc]

@Katetc - I believe that DGLC couples daily not once a year. Out of the box (at least for NorESM) I am getting the following for a fully active configuration with DGLC%NOEVOLVE.

	ATM_NCPL: 48
	GLC_NCPL: 1
	ICE_NCPL: 48
	LND_NCPL: 48
	NCPL_BASE_PERIOD: day
	OCN_NCPL: 24
	ROF_NCPL: 8
	WAV_NCPL: 48

Hmm, interesting. This would also explain why I don't see anything about breaking up the fluxes over time in DGLC. I need to do more diagnostics.

[Katetc]

Current status is that I have added a circular buffer and (what I thought was a) 10 year exact lag. It worked in a 15 year run after a cursory examination. The code is here: https://github.com/Katetc/CDEPS/tree/katetc_dglc_timelag

This code is based on the thought that dglc_datamode_store_advance gets called once per year. If it got called once per day, then we would have just a 10 day lag. However, the ROF history fields showed 10 years with zero Ice flux in GRIS and then normal looking ice flux for the final 5 years of the 15 year run (I-compset for testing). So, that suggests that DGLC is coupled once per year. But I see the same coupling XML variables as Mariana above. This is confusing.

[Katetc]

Current status is that I have added a circular buffer and (what I thought was a) 10 year exact lag. It worked in a 15 year run after a cursory examination. The code is here: https://github.com/Katetc/CDEPS/tree/katetc_dglc_timelag

This code is based on the thought that dglc_datamode_store_advance gets called once per year. If it got called once per day, then we would have just a 10 day lag. However, the ROF history fields showed 10 years with zero Ice flux in GRIS and then normal looking ice flux for the final 5 years of the 15 year run (I-compset for testing). So, that suggests that DGLC is coupled once per year. But I see the same coupling XML variables as Mariana above. This is confusing.

Looking at the logs, I think the answer is in this valid_inputs check which looks for input from the coupler for dglc_comp_run. While DGLC is "coupled" daily, there is only once per year when there is information from the coupler (valid_inputs). This is due to the xml variable GLC_AVG_PERIOD that tells the coupler to accumulate smb for the glaciers over the year. Even thought DGLC is "coupled" daily, it is only once per year that it gets info from the coupler, and that is when the "advance" code is called. Maybe we should discuss if this is what we want. It is very confusing.

[mvertens]

@KateC - just a few more clarifications to what you have above.
In nuopc.runconfig we have as
glc_avg_period = yearly
as you point out - this is obtained from the xml variable GLC_AVG_PERIOD.

And then in the dglc glc_comp_nuopc.F90

       call NUOPC_CompAttributeGet(gcomp, name="glc_avg_period", value=glc_avg_period, rc=rc)
       if (ChkErr(rc,__LINE__,u_FILE_u)) return
        ....
       else if (trim(glc_avg_period) == 'yearly') then
          call alarmInit(mclock, valid_alarm, 'yearly', alarmname='alarm_valid_inputs', rc=rc)
          if (ChkErr(rc,__LINE__,u_FILE_u)) return
       ..... 

So in this case alarm_valid_inputs is yearly. This means that dglc will only get valid inputs from the mediator on a yearly basis and CMEPS will average the inputs from CLM to DGLC over a year.
So although dglc is called on a daily basis it only updates what it only advances it's internal state yearly. Furthermore,
dglc will not update it's export state daily from the input stream data since there is no input data stream.

[billsacks]

To keep @Katetc in the loop: @mvertens and I just talked. It sounds like she might update this issue with some updated thoughts. But I wanted to address this general point:

Looking at the logs, I think the answer is in this valid_inputs check which looks for input from the coupler for dglc_comp_run. While DGLC is "coupled" daily, there is only once per year when there is information from the coupler (valid_inputs). This is due to the xml variable GLC_AVG_PERIOD that tells the coupler to accumulate smb for the glaciers over the year. Even thought DGLC is "coupled" daily, it is only once per year that it gets info from the coupler, and that is when the "advance" code is called. Maybe we should discuss if this is what we want. It is very confusing.

This valid_inputs thing is an unfortunate complexity that arose out of a need to accommodate two somewhat-conflicting requirements:

1. We wanted SMB forcings to be averaged over a year before being downscaled to the glc grid, because this was found to be better scientifically (relying less on the post-bilinear-remap conservation correction)
2. We wanted the ability to stop / restart the model in the middle of a year

Point (2) required this valid_inputs logic in cpl7. And I think at least some of these issues carried over - and there were possibly new ones as well - when we moved to cmeps. It's possible that some of these issues are cism-specific and wouldn't exist with dglc... I would need to dig a bit to remember the details, but I don't think it will be trivial to remove this logic.

[billsacks]

2. We wanted the ability to stop / restart the model in the middle of a year

I was looking into something else and stumbled across this:

https://github.com/ESMCI/cime/blob/f0b9d218e97eb92ea84decaf6ae1bfc263b8ddc9/CIME/case/case_submit.py#L317-L370

This confirms that yes, it's a requirement with nuopc/cmeps that we can only stop the model at a multiple of the longest coupling interval. So I believe that the conditions that led us to the somewhat messy pattern of glc coupling still apply, unfortunately.