Multi-model after time average about esmvalcore

[valeriupredoi]

@ledm _get_overlap() is your enemy here:

    all_times = []
    for cube in cubes:
        span = _datetime_to_int_days(cube)
        start, stop = span[0], span[-1]
        all_times.append([start, stop])
    bounds = [range(b[0], b[-1] + 1) for b in all_times]
    time_pts = reduce(np.intersect1d, bounds)
    if len(time_pts) > 1:

if the cube has a single time point then start = stop = single_cube_time_point and if single_cube_time_point is different from cube to cube by more than 1 then bounds will have no overlapping interval. You have two options: either make the cubes' single time points the same or introduce a condition in this function alike if start == stop: time_pts = range(start - 1, stop + 1), return time_pts - the second option will work fine but may introduce significant errors if the time points of the cubes are far apart in time eg you compute a multimodel between say, two models that one has its time point in 1971 and the second has its time point in 2019 which works functionally but has no statistical meaning

[valeriupredoi]

so a minimal temporal check has to be done, but that one is up to you ie how far part in time you can still compute the multimodel stats

[ledm]

I found a bug related to this today. The multi_model fails when the template_cube has no latitude or longitude component. The solution is to move the lines:

        lats = template_cube.coord('latitude')
        lons = template_cube.coord('longitude')

inside the shape statements:

    if len(template_cube.shape) == 3:
        lats = template_cube.coord('latitude')
        lons = template_cube.coord('longitude')
        ...

The problem with this whole part of multimodel is that it relies on an arbitrary set of coordinates - it should be generalised.

For instance, this line

ESMValCore/esmvalcore/preprocessor/_multimodel.py

Line 129 in 933403f

plev = template_cube.coord('depth')

)
has depth hardwired into it! Not useful for atmospheric people!.