Skip to content

Document (or close) five known validation gaps in DfsuBuilder and DfsuFile #50

Description

@ecomodeller

Five TODOs mark gaps that are already handled conservatively — they raise clearly or skip a check rather than producing wrong output. Collecting them so the limits are visible without reading the source; none is a silent bug.

DfsuBuilder.SetZUnit, mikecore/DfsuBuilder.py:201# TODO: Fix! above:

if (zUnit != eumUnit.eumUmeter
    and zUnit != eumUnit.eumUfeet
    and zUnit != eumUnit.eumUUnitUndefined):
  raise Exception("Currently only meter and feet unit is supported")

Any other Z unit is rejected outright. Whether more units should be accepted, and what "Fix!" meant, is unrecorded.

mikecore/DfsuFile.py:224# TODO Validate data. Data written to a dfsu is not checked for length or type against the item it belongs to; a mismatch surfaces further down rather than at the call.

mikecore/DfsuBuilder.py:310-311 — in the layered-file validation:

# TODO: Need to check that node coordinates are also on top of each other?
# TODO: Need to check that the 2D elements are defined counter-clockwise

Validate checks that layered elements sit on top of each other by connectivity and that layer counts match the sigma-layer count, but does not check coordinates or element orientation. A file violating either passes validation.

mikecore/DfsuBuilder.py:341# TODO do we need to check frequency or directions?; spectral file types get no validation beyond the type dispatch itself.

Each is one of: accept as designed and document it, or promote to its own issue with a case that goes wrong. The value here is that the answer is written down somewhere other than a code comment.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions