[cmdupuis3]

Closes #1753

Overview

_encode_exodus finds the end of each face with np.where(row == -1), but connectivity padding is stored as INT_FILL_VALUE. The comparison never matches, so every face is counted at the maximum width. Two things follow: a mixed mesh collapses into a single element block carrying the wrong element type (triangles and quads all written as SHELL4), and the padding itself is written out as INT_FILL_VALUE + 1 in a slot where a node index belongs.

The fix matches INT_FILL_VALUE. Element blocks then split by face size, which is what Exodus requires — blocks are homogeneous.

One note for reviewers: because blocks now genuinely split, a mixed mesh is regrouped by face size on write, and nothing yet records that permutation, so the mesh reloads reordered. Two existing round-trip tests therefore compare the Exodus faces as a set in this PR instead of element-wise — test_mixed_exodus (on the mixed.exo fixture) and test_grid_ugrid_exodus_roundtrip (on outRLL1deg, which has polar triangles among its quads). The follow-up (cmd/exodus_block_reorder) records the ordering and restores both strict comparisons. This PR is green on its own, but it does temporarily loosen those two assertions.

PR Checklist

General

• An issue is created and linked
• Added appropriate labels (if your uxarray repo permissions allow it)
• Filled out Overview and Expected Usage (if applicable) sections

Testing & Benchmarking

• There is adequate test coverage of changes from this PR (add new tests if needed)

Documentation and Examples

• Docstrings updated with any function changes, and included in all new functions
• User (public) functions added to docs/api.rst; internal (private) function names start with an underscore (_)

AI Disclosure

AI Usage: Claude Opus 5

• I have tested and take responsibility for all AI-generated content in my PR.

[jayeshkrishna]

The change looks good. There are some suggestions on more test cases and modifying the comments/PR commit message,

The PR commit message could be changed to something like,

Exodus element blocks are homogeneous, so a mixed mesh has to be split by
face size (e.g. Mixed mesh containing TRI and SHELL elements are split
into two homogeneous blocks, the first block containing TRI elements and
the second block containing SHELL elements). In the face node connectivity
array the user specifies padding for shorter elements using a fillvalue.
This fillvalue is frequently specified by users as -1. However note that
this fillvalue/padding is internally stored as INT_FILL_VALUE in uxarray.
See PR #241 for details.

The _encode_exodus function was incorrectly finding the end of each face with
np.where(row == -1). The comparison never matches if the fillvalue is different
(or not specified by the user), so every face (including faces with padding) is counted at the maximum width of the connectivity array. Two things follow:
(1) a mixed mesh collapses into a single element block carrying the wrong
element type (e.g. triangles and quads all written as SHELL4)
(2) the padding itself is written out as INT_FILL_VALUE + 1 in a slot where
a node index belongs.

The fix matches node values to INT_FILL_VALUE to detect each face. Element
blocks are then split by face size, which is what Exodus requires (blocks are
homogeneous).

[cmdupuis3]

@jayeshkrishna I'll use your commit message when I squash-merge it; otherwise it should be ready for another look.

[dylannelson]

Confirmed the fix works as intended and that the followup work of reordering will be needed but since it's expected after this, we can proceed.
Was interesting seeing a node index return "-9223372036854775807", which is now fixed.