0043 — No test or build step ever parses examples/input/FMU/AuvSurvey.xml

ID	0043
Class	TEST
Severity	2
Status	ready
Models	— (the FMU scenario in examples/input/FMU/)
Found	2026-09-23
Decision needed

Evidence

examples/input/FMU/AuvSurvey.xml shipped in a state where no XML parser could read it at all. Its header comment contained a literal double hyphen,

to nothing. That is what the --autocopy in AuvSurvey.fmu.yaml is for. The exporter

and XML forbids -- inside a comment, so tinyxml2 refused the document outright:

$ cd build/Release/playpen/bin
$ ./FhSim ../examples/input/fishery/FMU/AuvSurvey.xml
[ERROR] SimulationManagerFactory: failed to load '.../FMU/AuvSurvey.xml':
        Double hyphen within comment: <!--
          The AUV survey scenario, exposed for co-simula

The comment has been corrected, because the failure and the correction are both certain: the XML specification forbids the sequence, and rewording prose cannot change a model. The defect recorded here is not the hyphen. It is that the hyphen survived at all.

Nothing in the repository parses this file:

• tests/CMakeLists.txt registers regression cases from tests/in/<Case>/<Case>_in.xml. There is no tests/in/ case for any file under examples/input/FMU/.
• tests/AuvSurvey_Test.cpp:471, AuvSurvey_TheExampleAndTheRegressionInputAreTheSameFile, compares examples/input/AuvSurvey.xml with tests/in/AuvSurvey/AuvSurvey_in.xml. The FMU variant is not mentioned in any test.
• The FMU catalogue build pairs each .xml with a .fmu.yaml and stops there; AuvSurvey.fmu.yaml sets visibility: private, and the export pipeline (export_fmus.py) skips a private model outright, so even a full FMU export run never opens the XML.

So the one file in this library that is only ever read by a tool nobody runs is also the one file with no syntax check of any kind.

Effect

A co-simulation host, or a developer flipping visibility to public at release time, is the first thing to discover that the model does not load. The failure is at parse time, so it is not subtle when it happens — it is only invisible until then. The same hole would hide a misspelled port name, a missing Size_ attribute or a dangling connection just as well.

The scenario XML under examples/input/ has the same exposure in principle, but in practice AuvSurvey.xml is byte-identical to a registered regression input and the other examples are run by hand, so the FMU directory is the only unguarded one.

Possible fix

1. A load-only smoke test: one gtest case, or one ctest entry, that runs the model loader over every examples/input/**/*.xml with TEnd overridden to a single step and asserts that construction succeeds. This catches parse errors, unknown SimObject names, bad port names and missing connections for every example at once, and is what would have caught this. It needs fhsim_base on the playpen, which this library does not currently have — see FISH-0028 — because the FMU variant names System/ExternalLinkStandard and two Signal/Switch objects from that library.
2. Cheaper and narrower: an XML well-formedness check over examples/input/**/*.xml in the build, with no SimObject loading at all. It would have caught this exact defect and has no dependency problem, but it proves nothing about the model.
3. Register examples/input/FMU/AuvSurvey.xml as its own regression case. This gives the strongest guarantee for this one file and none for any other, and it inherits the same fhsim_base dependency as option 1.

Test that would prove it

Reintroduce a -- into any comment of examples/input/FMU/AuvSurvey.xml and run the full suite: everything passes today. Under option 1 or 2 the new case fails.

Risk

Option 2 is risk free. Option 1 and option 3 both require fhsim_base as a test dependency of this library, which is FISH-0028 and is a packaging change rather than a test change; both would also start failing the build for any example whose SimObject libraries are not on the playpen, which is a behaviour change worth choosing on purpose.