ref & hist times in bias adjustment methods must match

[coxipi]

Pull Request Checklist:

• This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes #xyz
• Tests for the changes have been added (for bug fixes / features)
  • (If applicable) Documentation has been added / updated (for bug fixes / features)
• CHANGELOG.rst has been updated (with summary of main changes)
  • Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?

• Add a method to bias adjustment classes to raise an error if ref and hist times do not match

Does this PR introduce a breaking change?

Other information:

[coxipi]

it keeps saying that some checks were not successful, but I don't see any red x, showing the failures.

[aulemahal]

Weird, the previous CI shows some runs "cancelled". I don't see why they were cancelled...

[Zeitsperre]

It's a configuration issue. I'll see what I can do.

[coxipi]

So all this discussion about conflict values of time with map_blocks if times are not maching:

I guess that's why NpdfTransform had:

                "ref": ref.rename(time="time_hist"),
                "hist": hist.rename(time="time_hist"),
                "sim": sim,

I'll try and see if the class Adjust could handle this on its own to also avoid the problem in other classes. I recently had this problem when trying to use dOTC.

For MBCn, I didn't see this with the groupies-like implementation since it doesn't use map_groups. I'm not sure how it worked for my map_groups implementation though , I feel it should have failed for this specific reason above.

[coxipi]

Ready for xclim next version

[aulemahal]

Looks good to me. I think the replace_sim logic needs a bit more doc, the current docstring does not list "same size same calendar" as a requirement for sim.

[aulemahal]

This would only work with a uniform calendar, no ? Should we raise a meaningful error if the sizes and/or calendars are different ?

[coxipi]

Looks good to me. I think the replace_sim logic needs a bit more doc, the current docstring does not list "same size same calendar" as a requirement for sim.

Hmm, should I just leave this a case-by-case for each specific method? I don't think there is much documentation on _allow_diff_calendars either? Maybe this should be improved too

I guess _allow_diff_calendars and _allow_diff_training_times are explained a little bit more than _replace_sim_time since there is a check in TrainAdjust. But it's just in-line documentation inside the function, so I don't think it's documented a lot more? Maybe I'm missing something

e.g.

        if not cls._allow_diff_calendars and len(calendars) > 1:
            raise ValueError(
                "Inputs are defined on different calendars,"
                f" this is not supported for {cls.__name__} adjustment."
            )

vs.

        # This below implies that ref.time and sim.time have the same size
        # Since `ref,hist, sim` are in the same `map_groups` call, they must have
        # the same time
        if cls._replace_sim_time:
            sim_time = sim.time
            sim["time"] = ref["time"]

maybe I should simply have : _allow_ref_and_sim_time_different_size, and if it's False, there is the check, documented in the same way, and the conversion. This would be clearer?

EDIT: This would already be better, we can anticipate a wrong input, and raise an error if need-be

[aulemahal]

Héhé I guess you're right about the other having almost no doc. The difference though is that _allow_diff_calendars doesn't actually do something, but the error it raises tells what's wrong. In Adjust, if sim.time is different than ref.time, the error will come from xarray and it might not make sense for the user ?

[coxipi]

Héhé I guess you're right about the other having almost no doc. The difference though is that _allow_diff_calendars doesn't actually do something, but the error it raises tells what's wrong. In Adjust, if sim.time is different than ref.time, the error will come from xarray and it might not make sense for the user ?

Yes good point, that's what I was slowly converging to when thinking about your comment.

Is _allow_ref_and_sim_time_different_size too long? I think it's the way to go, and replacing the times can be done too without any specific attribute

[Zeitsperre]

FYI, the issues with conda are fixed here: 9aa4e4a

[coxipi]

I can just add _allow_diff_times_size, and for adjust, the check will be for ref,hist,sim which, in any case, this is what we want.

You know, there is an implicit assumption in other function that ref and hist will have the same calendar AND the same time, right? I can add this check in other TrainAdjust class for the train part. But this would be more strict, something like:

_allow_diff_times, i.e. times must be the exact same

[coxipi]

_allow_diff_calendars is a less strict condition than _allow_diff_training_times, and likewise it also applies only on ref and hist currently ... except for Adjust class where it is applied on ref,hist,sim.

Just to say: _allow_diff_calendars = False is mostly useless in TrainAdjust classes if we also check training times, _allow_diff_training_times = False

[coxipi]

FYI, the issues with conda are fixed here: 9aa4e4a

I'll wait for it to be merged in main, if you'd like another course of action tell me

[Zeitsperre]

@coxipi Feel free to cherry-pick that commit. There's also the issue of the xarray/flox bug that still needs addressing. I think neither this PR nor mine can be merged until that's addressed at the very least.

[coxipi]

@coxipi Feel free to cherry-pick that commit. There's also the issue of the xarray/flox bug that still needs addressing. I think neither this PR nor mine can be merged until that's addressed at the very least.

I've added the change from the commit you linked, we'll see

[github-actions]

Note

It appears that this Pull Request modifies the main.yml workflow.

On inspection, the XCLIM_TESTDATA_BRANCH environment variable is set to the most recent tag (v2024.8.23).

No further action is required.

[Zeitsperre]

Woops, there's one more thing: You need to remove "defaults" from the environment.yml. The default libraries of conda are now under a weird commercial license. conda-forge remains fully open.

Nope, that's not it. It looks like they've changed their download URL from conda.anaconda.com to repo.anaconda.com as of today. Modifying that should fix the connection issue.