Allow regridding for very large grids

[davidhassell]

Fixes #878

[sadielbartholomew]

Very nice! And very well tested. I have only minor feedback, as raised in-line plus the below. (We can ignore the CI failures which is on packaging issues with Python 3.8 which we've removed support for in separate PRs.)

One general comment is that, ideally, we can clarify the maximum cap that gets applied - for example, a user might set dst_grid_partitions=7 and it be capped to 5, say, then they could either be confused as to why 5 was used (if they happened to view with high verbosity i.e. debug mode), or (perhaps worse), be blissfully unaware the value applied was not that which they set. A particularly bad case would be when the maximum allowed is 1, such that setting any value including "maximum" would result still in 1 - which looks like something isn't working in the logic but really it is due to the cap. This isn't just a theoretical case, since I saw it when playing around interactively to explore the debug outputs, e.g:

>>> src, dst = cf.example_fields(1, 0)
>>> z = src.regridc(dst, method='conservative', axes=['Y'], dst_grid_partitions=3, verbose=-1)
Source Grid:
Grid(name='source', coord_sys='Cartesian', type='structured grid', axis_keys=['domainaxis1'], axis_indices=[1], axes=['domainaxis1'], n_regrid_axes=1, dimensionality=1, shape=(10,), esmpy_shape=(10,), coords=[<CF DimensionCoordinate: grid_latitude(10) degrees>, array([0.])], bounds=[<CF Bounds: grid_latitude(10, 2) degrees>, array([[-1.,  1.]])], cyclic=False, method='conservative', dummy_size_2_dimension=False, is_grid=True, is_mesh=False, is_locstream=False, mesh_location=None, domain_topology=None, featureType=None, new_axis_keys=[], z=None, ln_z=False, z_index=None)

Destination Grid:
Grid(name='destination', coord_sys='Cartesian', type='structured grid', axis_keys=['domainaxis0'], axis_indices=[0], axes=['domainaxis0'], n_regrid_axes=1, dimensionality=1, shape=(5,), esmpy_shape=(5,), coords=[<CF DimensionCoordinate: latitude(5) degrees_north>, array([0.])], bounds=[<CF Bounds: latitude(5, 2) degrees_north>, array([[-1.,  1.]])], cyclic=False, method='conservative', dummy_size_2_dimension=False, is_grid=True, is_mesh=False, is_locstream=False, mesh_location=None, domain_topology=None, featureType=None, new_axis_keys=[], z=None, ln_z=False, z_index=None)

Calculating weights ...

Number of destination grid partitions: 1
Free memory before weights creation: 8.845745086669922 GiB
Maximum RSS before weights creation: 0.2023167908191681 GiB

where the Number of destination grid partitions: 1 had me confused until I clocked why.

Does that make sense?

My preference in this regard would be to note the cap in the debug log (something like a line Maximum cap on destination grid partitions: N above the Number of destination grid partitions: M line) but more importantly raise a log 'warning' when the user sets a value which exceeds the cap, to inform them that it wasn't possible given the cap to use that value.

(Also you can set the dst_grid_partitions keyword to 0 or negative integers and they will be silently ignored such that the default value 1 is applied - hopefully users will realise not to do that but might be good to raise a ValueError on nonsensical values.)

[davidhassell]

One general comment is that, ideally, we can clarify the maximum cap that gets applied - for example, a user might set dst_grid_partitions=7 and it be capped to 5, say,

The requested number of partitions is now reported: 5decf3f

Number of destination grid partitions: 5 ('maximum' requested)

Number of destination grid partitions: 5 (7 requested)

[davidhassell]

There is a possible (probable!) issue with conservative 1-d Cartesian regridding - for this, a dummy size 1 2nd dimension is introduced, because ESMF likes that. However, that dummy dimension is the trailing poisition, so gets the partitioning treatment ... but it's size 1!

(Note to self: for linear 1-d Cartesian regridding this already is handled correctly, because grid.dummy_size_2_dimension=True)

There is an easy fix for this, but not on the timescales of this release, so I'll open a new issue for it.

[davidhassell]

OK - hopefully no need for a new issue: 3acbdf0

[sadielbartholomew]

Thanks for addressing the minor feedback. All good after reviewing the new commits and a final sanity check.

As agreed in person, I will merge so I can get on with the new release with this included.