`TypingError` when running `eddy_identification` about py-eddy-tracker

[ctroupin]

Yes, v3.3.0. I think I can almost isolate the error with numba. I'm preparing a MWE.

[AntSimi]

I thought a little bit about that, but i haven't quick/clean answer. I thought at this point the quickest solution is to load a regular grid(py-eddy-tracker meanings).
Another hack could be after loading grid

# When handler is create, no grid variable is loaded, you needs first to use 'grid' method to populate 'vars'
h.grid('XE')
# Manual transpose
h.vars['XE'] = h.vars['XE'].T

[ctroupin]

Hi Antoine, I though I had replied,
so thanks for the last bit of code, I'm trying to finish it now,
(had to stop working on this for the last two weeks).

[AntSimi]

Could you specify numba version?

[ctroupin]

Name: numba
Version: 0.51.1
Summary: compiling Python code using LLVM
Home-page: https://numba.github.com
Author: Anaconda, Inc.
Author-email: [email protected]
License: BSD
Location: /home/ctroupin/Software/PythonEnvs/EddyMitchell/lib/python3.8/site-packages/numba-0.51.1-py3.8-linux-x86_64.egg
Requires: llvmlite, numpy, setuptools
Required-by: pyEddyTracker

Edit: I've upgraded to 0.52, same result.

[AntSimi]

ok,
Did you use a py-eddy-tracker up to date ?

[ctroupin]

OK all fixed, I don't know exactly what failed by probably not numba.

Now I just need to understand why the coordinates are mixed up, but it's cool to get results at the end.

[AntSimi]

I think several issues come from hack of RegularGridDataset.
In this specific case, i think i know reasons.
To know if software need to transpose grid in case of RegularGridDataset, we look at dimensions order of grid. That's good when you have a grid which are function of 1D array coordinates, but in your case i think this analyse fail due to coordinates are function of 2 dimensions.

[ctroupin]

Yes, that totally makes sense.
Is there any property of the grid class that I could use to ensure the transpose if enabled or disabled?