fixes an issue in aux data streams

[jedwards4b]

Description of changes

The calculation of ddateLB seems to be different in different parts of the file, at line 965 we have
yy = yy + (mYear-dYear-nYears) while at line 1154 we had
yy = yy + (mYear-dYear) changing the line at 1154 to match that at 965 seems to have solved the issue.

Specific notes

Contributors other than yourself, if any:

CDEPS Issues Fixed (include github issue #):

Are there dependencies on other component PRs (if so list):

Are changes expected to change answers (bfb, different to roundoff, more substantial):

Any User Interface Changes (namelist or namelist defaults changes):

Testing performed (e.g. aux_cdeps, CESM prealpha, etc):

Hashes used for testing:

[jedwards4b]

@fischer-ncar could you please run prealpha tests with this branch.

[fischer-ncar]

Can do.

[jedwards4b]

I think that the issue here is that the cycle method in the model is only designed to cycle over full years of data and we are asking for a cycle over 2 days worth of data.

[mvertens]

Exactly

…

On Mon, Nov 7, 2022 at 7:05 AM Jim Edwards ***@***.***> wrote: I think that the issue here is that the cycle method in the model is only designed to cycle over full years of data and we are asking for a cycle over 2 days worth of data. — Reply to this email directly, view it on GitHub <#193 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4XCE5KJADBXA6C7GNQCETWHEEEHANCNFSM6AAAAAARVPD6IE> . You are receiving this because your review was requested.Message ID: ***@***.***>

[jedwards4b]

I guess I wasn't aware of that - I thought that we were trying to fix a bug in current functionality when in fact we want to add new functionality.

[mvertens]

Sorry i didn’t get a chance to help with this. Your bug fix is still needed?

…

On Mon, Nov 7, 2022 at 8:10 AM Jim Edwards ***@***.***> wrote: I guess I wasn't aware of that - I thought that we were trying to fix a bug in current functionality when in fact we want to add new functionality. — Reply to this email directly, view it on GitHub <#193 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4XCEYTDKTSXRFV7CFSFMLWHELXLANCNFSM6AAAAAARVPD6IE> . You are receiving this because your review was requested.Message ID: ***@***.***>

[jedwards4b]

That change broke all of our existing tests - I spent some time this weekend trying to better understand this code and rewriting a lot of the date and time variables as ESMF derived types. I think I have a better handle on the problem now and should have a solution soon. I do have questions about what new functionality should be allowed - for example if we provide several days input data we want to cycle over those full days - what if only 6 hours of inputdata is provided? I assume we do not want to cycle over that and should generate an error since it would not have a diurnal cycle.

[jedwards4b]

Now that I understand this to be new functionality and not a bug fix I have found a solution. For streams that do
not cycle over yearly boundaries the user may explicitly override the dt check by setting dtlimit=-1 for the stream.

I am not including this variable in the defaults, I think that in order to make sure that the user is aware that we are bypassing the limit they must set it explicitly for each stream file in user_nl_d*_streams

[jedwards4b]

@fischer-ncar Could you please run prealphas with this branch?

[fischer-ncar]

prealpha testing looks goog.

[uturuncoglu]

I also tested this under UFS by running couple of data atmosphere configurations and all worked fine.

[uturuncoglu]

Is this just required for data atmosphere? Do you need to same for other data components? Just curious.

[jedwards4b]

Thank you for asking. The other components either use the explicit fieldname in the call or already skip the cpl_scalar fields.