mikecore/MeshFile.py (around line 281, in ReadMesh) contains:
# Element code must be 21 or 25 (21 for triangular meshes, 25 for mixed meshes)
if (elmtCode != 21) or (elmtCode != 25):
pass # TODO?? Do we care?The condition is a tautology: no integer can be equal to both 21 and 25, so != 21 or != 25 is true for every possible value — including the two the comment says are valid. It needs and.
Today this is harmless, because the body is pass. The problem is the invitation: the TODO asks someone to decide what to do with an unexpected code, and anyone who fills the body in — with a raise, a warning, anything — makes it fire on every mesh, valid ones included.
The check is also redundant as written. A few lines further down, ElementType is derived per element from the number of corners actually parsed, so the header code is not what the reader relies on.
Two things to settle:
- Remove the dead block so the trap is gone. (Doing this in a PR alongside this issue.)
- Decide the policy: should an element code other than 21 or 25 raise, warn, or continue to be ignored? Right now
elmtCode is read from the header and never used for anything.
mikecore/MeshFile.py(around line 281, inReadMesh) contains:The condition is a tautology: no integer can be equal to both 21 and 25, so
!= 21 or != 25is true for every possible value — including the two the comment says are valid. It needsand.Today this is harmless, because the body is
pass. The problem is the invitation: theTODOasks someone to decide what to do with an unexpected code, and anyone who fills the body in — with araise, a warning, anything — makes it fire on every mesh, valid ones included.The check is also redundant as written. A few lines further down,
ElementTypeis derived per element from the number of corners actually parsed, so the header code is not what the reader relies on.Two things to settle:
elmtCodeis read from the header and never used for anything.