MeshFile element-code check is a tautology and does nothing
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start in mikecore/MeshFile.py at ReadMesh around line 281, then follow how elmtCode and the later ElementType derivation are used. Confirm whether the header code has any required role, decide the behavior for codes other than 21 and 25, and ensure the dead tautological block is removed without changing valid mesh parsing.
Written by the indexing model from the issue text.
Description
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
elmtCodeis read from the header and never used for anything.
- Dominant language
- Python
- Stars
- 5
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from DHI/mikecore-python
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
DHI/mikecore-python#49 ·
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
DHI/mikecore-python#52 ·
-
Remaining TODOs in production code: platform notes, licensing questions, and one likely-stale marker Open
Difficulty 5/5 Over a week Newbie friendliness 30/100
DHI/mikecore-python#51 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
DHI/mikecore-python#50 ·
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
DHI/mikecore-python#48 ·
All issues in DHI/mikecore-python
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100