Refactoring improve4ogurses calendar

[patrickscholz]

Solve special problem here: Ozgurs wants to repeat only a part of the JRA55 forcing periodically (e.g repeat the period 1958-1967) through re-linking of the original forcing files.

• 1st problem: This will mess up the leap year cycle of the entire forcing, so the model has to run best without leapyear although the calendar system of the forcing remains gregorian (so with leapyear) This can be solved by makeing the treatment of the time-axes depending on the calendar of the forcing files, not alone from the include_fleapyear flag

• 2nd problem: In the case of a periodically repeated forcing period through re-linking of the original files it happens that e.g. the year 1968 is linked to the file 1958. In that case the time axis of the 1968 forcing file remains that of the original 1958 file. So the time axis needs to be resetted properly to the right year they are supposed to represent

[JanStreffing]

I'm not sure the visual inspection is enough for this. Would it be possible to run a 65 year cycle with this turned on and off? If results are bit-identical, I think it's good to go.

Or does the Draft status mean more work needs to be done?

[patrickscholz]

@JanStreffing Im still running some tests to check if everything fits together!

[ogurses]

I see that we turn leapyear off in FESOM config. Does this code patch consider the exclusion of 29th Feb. from the forcing data if the forcing file is on leapyear but FESOM clock not. In other words, do I have to drop 29th Feb. from the forcing files of leap year before I make any linking operation?

[patrickscholz]

@ogurses you were right in the previous solution the 29 Feb. was not fully skipped in the cache of the temporal interpolation. I changed that now! So when include_fleapyear=.false., the model checks if it finds a forcing file whos original time-axes represent a leapyear and than jumps over the 29. Feb when selecting the indices for the time interpolation cache. So now you should be able to truly only relink the original JRA55 forcing files to create your periodically repeating forcing. So no need to fully dublicate the forcing and delete leapyear 29. Feb from hand.

[patrickscholz]

There still seems to be some bias between this and the original refactoring branch, that do not seem to happen in the test case. Since the testcase seems to work with CORE2 data which do not have leap years.