Bug in shortwave forcing

[anton-seaice]

The global sum of the incoming shortwave field into the mediator shows strange sawtoothing:

The same error exists in the components of swdn (i.e. visible/infraraed etc)

This is possibly due to a misconfiguration of the timeinterpolation ? (which uses the coszen interpolation)

Found in config in #1236

[aekiss]

Eww - well spotted!

[anton-seaice]

<offset>0</offset>
<tintalgo>coszen</tintalgo>

is worse:

<offset>0</offset>
<tintalgo>linear</tintalgo>

seems plausible:

[aekiss]

I guess the globally integrated incoming insolation is varying due to the patchiness of cloud cover as Earth rotates through a day? If so, linear definitely looks better than the other two.

Odd that the 2nd coszen example varies over a much wider range. Does this differ from the first example only in the offset?

Looks like there's a problem with how coszen is calculated - maybe the time units are wrong for the zenith angle? eg if it varies much faster than it should, the samples could be picking it up at incorrect phases? A mixup of hours/degrees/radians perhaps?

[anton-seaice]

I guess the globally integrated incoming insolation is varying due to the patchiness of cloud cover as Earth rotates through a day? If so, linear definitely looks better than the other two.

Yes probably - but also this is the sum of swdn onto ocean (& sea ice), so i don't know if that also contributes to a not-smooth result. I don't know if linear interpolation would be meaningfully worse than smoothing between points following the curve of a sine wave?

Odd that the 2nd coszen example varies over a much wider range. Does this differ from the first example only in the offset?

Yeah that's right

Looks like there's a problem with how coszen is calculated - maybe the time units are wrong for the zenith angle? eg if it varies much faster than it should, the samples could be picking it up at incorrect phases? A mixup of hours/degrees/radians perhaps?

Yeah, ill look into this. We've inherited this interpolation method from CESM, I wonder if it works correctly in their case and if so how the forcing is different (e.g. I believe all forcing are pre-processed for CESM).

[anton-seaice]

The coszen time interpolation calculations are only based on the lower value in the interval

https://github.com/ACCESS-NRI/CDEPS/blob/7c266f28a6bda640bf35850fd66011925cabeb73/streams/dshr_strdata_mod.F90#L1291

dataptr1d(i) = dataptr1d_lb(i)*coszen(i)/sdat%tavCoszen(i)

i.e. the resulting dataptr1d for the Faxa_swdn field is dataptr1d_lb (the stream data) multiplied by the current coszen and divided by the average coszen for that stream time interval. coszen and tavCoszen look consistent with each other.

[anton-seaice]

There is one strange aspect about tavCoszen - it's calculated as follows

!---------------------------------------------------------------
! Returns a time-average of cos(z) over the time interval [LB,UB].
! The time-avg is calculated via a right-sum Riemann sum where the partitian
! width is the model dt, and the left-most partitian starts at the LB.
! NOTE: For cosine of solar zenith angle forcing the time-stamps MUST be for
! the beginning of the interval.
!---------------------------------------------------------------

This is counter-intuintive, I would have expected the average over a time interval to be the mean of lower bound and upper bound

[anton-seaice]

Looks like we end up with less incoming radiaton than prescribed:

The intent of the coszen is clear by looking at some points:

although possibly not conserving:

Other points (cloud affected?) look worse:

Notebook:

anton-seaice/sandbox@0b778d8

[anton-seaice]

To summarise:

There's no clear option to get a smooth result following a physically realistic curve.

The existing coszen interpolation only uses one data point (every three hours) when interpolating to the model timesteps (1 hour or less). To get a smooth result would require interpolating across two data points. Maybe some code changes to calculate a combine coszen from 2 data points, and then linear interpolate between the two intermediate "coszen" weighted data points is an option