Update UxGrid search API to match BaseGrid

[VeckoTheGecko]

Continuing the work in #2037 to fix #2048, this PR defines the axes for UxGrid as ["Z", "FACE"]. See #2048 for the full context

Changes:

• Remove search2D from UxGrid.search
• Update UxGrid ravelling to match BaseGrid API
• Update Field.eval and VectorField eval to match new grid search API (also update interpolation template to remove ei, bcoords and replace witth position)

Open questions:

• In terms of naming, should we go with "FACE" or "CELL"? Is there convention here?

  • decided on FACE to match the uxarray vocab

• Do you feel that there should be more test cases for ravelling/unravelling on an unstructured grid @fluidnumerics-joe ? (kinda what is done for structured grids at the moment?). If yes, I don't think its a high priority - though stubs would be helpful so we don't forget

• Chose the correct base branch (v4-dev for v4 changes)

• Fixes A clear API for handling grid axes, barycentric coordinates, index searching, and ravelling. #2048

• Added tests - None (yet)

[fluidnumerics-joe]

In terms of naming, should we go with "FACE" or "CELL"? Is there convention here?
For lateral indexing we should use "FACE" for face indices and "NODE" for node/vertex indices . A cell or element refers to the full 3-d object that you get when a face is extruded vertically between two vertical layers.

WRT testing ravel/unravel, we have a few tests that check evaluation of a field from our generic data sets; under the hood, this exercises both raveling and unraveling. Are you thinking of tests that just exercise ravel/unravel ?

[VeckoTheGecko]

Are you thinking of tests that just exercise ravel/unravel ?

Yes. In the xgrid case I have a test that checks that roundtrips ravel and unravel and checks that it generates unique ei's . Maybe that's overkill, I can also see that POV

[fluidnumerics-joe]

That makes sense though. The eval call stack involves a lot of other things and having these kinds of highly directed tests can help us further characterize what could be going wrong in eval (for example).

[VeckoTheGecko]

That makes sense though. The eval call stack involves a lot of other things and having these kinds of highly directed tests can help us further characterize what could be going wrong in eval (for example).

Considering now I don't think round tripping ravelling is actually needed right now for uxgrid - with #2056 ravel and unravel could then be tested on the BaseGrid level (and also make testing easier for xgrid and uxgrid).

Any other review comments/thoughts for this PR?

[fluidnumerics-joe]

Quite a tidy change. All good on my end