tra_qsr_mean: restartability issue and some questions

[greffray]

PISCES can not works correctly with a diurnal cycle. In others words, PISCES always needs sun light. By consequence, in the case where high frequency atmospheric forcing or daily frequency with the analytical diurnal cycle are considered, PISCES can not use the same forcing than those used by the physical model.

To overcome this issue, a daily mean solar fluxes are now computed online in the routine trcstp.F90 by this call:

IF( l_trcdm2dc ) CALL trc_mean_qsr( kt )

This procedure deals with a computation of the daily mean solar fluxes using a moving average. The tab qsr_arr contains 24 dumps (or less if the time-step of the model is greater than 1 hour).
The first problem is the initialisation of this tab. At the first time-step, all the dumps are assigned by the solar flux at the first time step then 0 in the Atlantic ocean for a global configuration. I am not sure it is a good choice confronted to the assumption of PISCES introduced at the beginning of this ticket.

Next, at the first reading of the routine trc_mean_qsr, it is obvious that the restartability is not respected as qsr_arr is never saved !
This doubt has been confirmed by SETTE tests done by Clement Bricaud.

The last point concerns the scope of this method. By the actual implementation, l_trcdm2dc is true when the analytic diurnal cycle is true too.

What is the interest to compute again the daily mean whereas they are already read ? The simplest method is to store daily mean solar fluxes in qsr_mean just after reading and to apply the analytical diurnal cycle for qsr used for physics. This was already implemented by Clement Bricaud in the version r5974.

In the case of high frequency solar fluxes, I see 2 solutions :

• compute offline daily mean solar fluxes and read them for PISCES
• compute online the daily means but i am not sure it is obvious to do that with fld_read

[timgraham]

I've modified the milestone on this to remind us to look at it at the merge party next week.

[cetlod]

1°) I agree for the initialisation/restartability issue. We must store the daily mean qsr in the passive tracer restart file.  A bugfix will follow

2°) Regarding the scope of the method as you said :

• when coupling with the atmosphere, the solar radiation is not read in files, but given at each coupling frequency. So we need to compute online the daily mean solar radiation

• even if we are in forced mode, Clement Bricaud has implemented it in a very particular case : the coupling with LIM2 using the core bulk formulae. Since the solar fluxes is modified by the sea-ice model, the changes should also been applied in LIM3, CICE, GELATO. Not very optimal...

The proposed solution is not perfect, but it seems to us to be the most comfortable on a global point of view