Unhandled numba exception

[RomillyClose]

I'm working on XDEM version 0.0.14. I received the following error when trying to get the terrain attributes for a 2m resolution REMA strip:

Traceback (most recent call last):
  File "<<path>>/lib/python3.10/site-packages/xdem/terrain.py", line 329, in get_quadric_coefficients
    coeffs = _get_quadric_coefficients(
MemoryError: Allocation failed (probably too large).

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<<script path>>", line 218, in <module>
    slope = xdem.terrain.slope(dem)
  File "<<path>>/lib/python3.10/site-packages/xdem/terrain.py", line 1153, in slope
    return get_terrain_attribute(
  File "<<path>>/lib/python3.10/site-packages/xdem/terrain.py", line 887, in get_terrain_attribute
    terrain_attributes["surface_fit"] = get_quadric_coefficients(
  File "<<path>>/lib/python3.10/site-packages/xdem/terrain.py", line 337, in get_quadric_coefficients
    raise RuntimeError("Unhandled numba exception. Please raise an issue of what happened.") from exception
RuntimeError: Unhandled numba exception. Please raise an issue of what happened.

The code takes a long time to generate the attribute, and then fails. The error is consistent with aspect/slope/etc, so it seems to be universal to all terrain attributes.

I've tested on 30m ASTER strip and a heavily cropped version of the REMA strip, and it works without issue, although it is a little slower. Before the latest update, I've previously generated terrain attributes on REMA strips of this size without issue, so this error is a surprise.

If you need any more information from me to help with this, please let me know. Do you know if there is a simple fix I'm missing?

[adehecq]

Hi @RomillyClose,

Thanks for reporting the issue. I'm not familiar with such error, but maybe @rhugonnet will be. A few questions/suggestions to move forward:

• what is the size of the DEM that you are processing? Can you maybe send us the metadata information for this file, obtained e.g. from gdalinfo or directly in xdem with the attribute self.info().
• can you please share the exact command and the data that fail (privately is fine). If you can't share the data, can you reproduce the error with a synthetic case, i.e. a DEM filled with 0 of same shape and transform as the one you're using?
• if you think the issue is due to an update in xdem, would you be able to run the same command with a previous version of xdem so that we can track what triggered this issue?

In the meantime, an easy fix is to use the richdem implementation, with the argument use_richdem=True (you need to install richdem with conda-forge).

[rhugonnet]

Not familiar with it unfortunately. For a 2 m DEM, I'd say it is simply too big. @RomillyClose Maybe your current REMA strip is the same size on-disk as the other one you mention, but larger in-memory due to more NaNs? (nodata are compressed on disk but loaded as float in memory).

Probably of interest to you: After a lot of discussions this summer with other Python packages, we intend to implement out-of-memory operations through an Xarray accessor in xDEM during the next year. It'll take a little while to get there, but that will solve your scaling problems for sure 😉

[rhugonnet]

This should get easier when adding Xarray accessor, see #392, by doing out-of-memory operations.
In the meantime, the solution to this issue is simply to use either more RAM on the computer or to split the DEM in subsets!