|
FhSim
3.1.0
Marine systems simulation
|
|
|
FhSim
3.1.0
Marine systems simulation
|
| ID | 0028 |
| Class | ARCHITECTURE |
| Severity | 2 |
| Status | blocked |
| Models | — |
| Found | 2026-09-17 test pass (new finding) |
| Decision needed | Should fhsim_fishery declare fhsim_base as a dependency so that the shipped inputs and the test cases may use the standard Src/*, Sink/* and Camera/* building blocks, or is base deliberately out of this package's closure, in which case every input and test scenario must be written from fishery, marine_elements and environment objects only and the limitation documented? |
examples/input/Example.xml:16-26 instantiates
<Lib LibName = "base" SimObject = "Src/SmoothTrajectory" Name = "RollTrajectory" ... />
Src/SmoothTrajectory is registered only by fhsim_base (ADD_SIMOBJECT_REF(CSmoothTrajectory, Src/SmoothTrajectory), fhsim_base/src/fhsim_base.cpp:31), and fhsim_base is not in this package's dependency closure: conanfile.py:38-44 requires fhsim, fhsim_marine_elements, fhsim_environment and fmt only, and nothing pulls base transitively (fhsim_environment, fhsim_marine_elements and fhsim_coribo each require fhsim and eigen, never fhsim_base). The playpen therefore carries four SimObject libraries, build/Release/playpen/bin/SimObjectLibraries/{libfhsim_coriboVis.so, libfhsim_environmentVis.so, libfhsim_fisheryVis.so, libfhsim_marine_elementsVis.so}, and running the playpen FhSim on the committed examples/input/Example.xml aborts at setup, after the Environment object is created:
[ERROR] Simobject library file not found in one of: "SimObjectLibraries/libbaseVis.so"
or "SimObjectLibraries/libfhsim_baseVis.so".
FhSim caught an exception: Simobject library file not found in one of: ...
No source file in src/ or include/ includes a fhsim_base header and CMakeLists.txt:25-28 does not find_package it, so this is purely a runtime/input-file dependency.
Four separate consequences, each verified:
examples/input/Example.xml does not load at all.** FISH-0019 migrated its environment block, and the log now shows --- Created simObject Environment --- before the abort above, so the environment migration is complete and base is the only remaining obstacle. The rest of the file is sound: on a scratch copy with the Src/SmoothTrajectory object removed and CLControl.Reference set to a literal, the full 51-state roll-control model (Warp, Bridle, Crowfoot, Actuator, PID, Door) builds and runs to completion. Unlike the other six inputs, Example.xml is not @included by any header — src/trawl/Actuator.h:73 only asks @todo add example input (why not Example.xml?) — so no model documentation page currently shows a dead example because of this.Example.xml with -o CSV output, and its Owner question still says the scenario "needs the
`Environment/Basic` replacement from 0019 to run at all". FISH-0019 is now resolved, so the standing blocker is this item, not FISH-0019. FISH-0018 is nevertheless marked ready, which is correct — the fix shape is known — but the sanitizer run it asks for cannot be set up on the committed input until base is available or the trajectory source is replaced.data/ inputs cannot be migrated without deciding this. Counted at HEAD by extracting every <Lib .../> block with LibName = "base"; FISH-0019 deliberately scoped only the five examples/input/ files.| File | base objects used (line) |
|---|---|
data/trawl/demos/trawldoorcontrol/FoilControl.xml | Environment/Basic (:7), Src/SmoothTrajectory (:20) |
data/trawl/demos/trawldoorcontrol/TrawlDoorControl.xml | Camera/Controller (:3), Environment/Basic (:13) |
data/trawl/demos/trawldoorcontrol/TrawlDoorControl2.xml | Environment/Basic (:3), Src/Sine (:16, :28) |
data/trawl/demos/trawldoorcontrol/TrawlDoorControlMovie.xml | Camera/Shot (:5), Camera/Controller (:17), Environment/Basic (:27) |
data/trawl/demos/trawldoorcontrol/flume.xml | Environment/Basic (:7), Src/SmoothTrajectory (:20) |
data/trawl/demos/trawldoorcontrol/flume2.xml | Environment/Basic (:7), Camera/Controller (:19), Camera/Shot (:28), Src/Sine (:40) |
data/trawl/demos/trawldoorcontrol/flume3.xml | Environment/Basic (:7), Src/Sine (:20), Src/SmoothTrajectory (:30) |
data/trawl/movies/trawl/morenot520/Trawl.xml | Camera/Shot (:5), Camera/Controller (:17), Environment/Basic (:27) |
data/trawl/movies/trawl/morenot520/TrawlMovie.xml | Camera/Shot (:5), Camera/Controller (:17), Environment/Basic (:28) |
data/trawl/movies/trawl/morenot520/TrawlPrepare.xml | Environment/Basic (:4) only |
data/trawl/movies/trawl/morenot520/TrawlSimple.xml | Camera/Controller (:15), Environment/Basic (:25) |
Ten of the eleven need base for a Camera/* or Src/* object and so are blocked by this item as well as by the Environment/Basic migration of FISH-0019. TrawlPrepare.xml is the exception: its only base object is Environment/Basic, so it needs the FISH-0019 treatment alone. Note that Environment/Basic itself is not supplied by fhsim_base 3.1.0 — grep -n Environment fhsim_base/src/fhsim_base.cpp matches nothing — so adding the dependency does not fix these files by itself; only the Camera/* and Src/* half.
Src/Step or Src/Constant and drives its square wave from Seine/Operation's own Op.WarpConnectedVessel output instead (issues/resolved/FISH-0011-seineoperation-minwarplength-overwritten.md:119-122), and the Crowfoot case could not use Src/SmoothTrajectory as FISH-0003 itself proposed and uses Trawl/Actuator paying out LineLength1 instead (issues/resolved/FISH-0003-crowfoot-externalvel-always-zero.md:116-118). Both note the cause in the same words: the object "is in the `base` library, which the test
playpen does not carry". Every further test scenario, including the seine example that FISH-0017 asks for, inherits the same restriction.Three options; only the first two are wholly in this repository's gift, and the third is a documentation change here plus an acceptance of the limitation.
1. Add fhsim_base to conanfile.py's requirements(). Investigated, and it is a plain addition as far as this repository is concerned:
fhsim_base/3.1.0@sintef/stable is present in the local Conan cache, at exactly the version and user/channel the existing requires use (fhsim/[^3.1.0]@sintef/stable, etc.), so self.requires("fhsim_base/[^3.1.0]@sintef/stable") resolves today.conan.lock anywhere in the checkout, so nothing has to be relocked. fhsim_base's own closure is fhsim/[^3.1.0]@sintef/stable, fhsim_environment/[^3.1.0]@sintef/stable and eigen/[~5.0.0] — a subset of what this package already resolves, at the same ranges, so no new transitive package and no version conflict is introduced.conancenter and sintef-public; sintef-private is disabled. sintef-public carries fhsim_base only up to 3.0.0@sintef/{stable,testing}, i.e. the whole 3.1.0 line is unpublished there — but that is equally true of fhsim (public up to 3.0.0@sintef/testing) and fhsim_environment (public up to 2.2.0@sintef/testing), which this package already requires at [^3.1.0]. So adding fhsim_base is symmetric with the existing dependencies: it works wherever the current build works, and it does not introduce a new class of resolution problem. Publishing fhsim_base/3.1.0 is the same release chore as for the packages already required, and it is not in this repository's gift.src/ or include/ file includes a fhsim_base header and CMakeLists.txt does not find_package(fhsim_base), so nothing is needed at compile or link time. A plain self.requires(...) on a package_type = "shared-library" recipe would nonetheless become a declared dependency of the shipped package and propagate to consumers of fhsim_fishery. If the intent is only "our own playpen and test runs carry `base`", the owner may prefer to scope it — visible = False, or a build_requires/test-only scope — but note that the playpen the examples run in is built by generate()'s import_playpen_files, so the scope chosen must still place libfhsim_baseVis.so in SimObjectLibraries/. That choice is the packaging question below.2. Replace the base objects in the affected inputs with fishery, marine_elements or environment equivalents, as the FISH-0011 and FISH-0003 test cases already did ad hoc. Cheap per file and entirely in this repository's gift, but it means the shipped examples cannot use the standard source, sink and camera building blocks that every other FhSim package's examples use, and each substitution changes the scenario (the FISH-0003 case had to accept an Trawl/Actuator line pay-out in place of a prescribed trajectory). It also does not help the ten data/ files whose base use is Camera/*: there is no fishery equivalent, so those objects would simply have to be deleted and the movie/demo inputs lose their camera work.
3. Leave it and document it. Record on the library page and in DEVELOPING.md that the shipped examples/input/ and data/ inputs require a wider SimObject set than the package declares, that they must be run against a playpen that also carries fhsim_base, and that test scenarios in this repository may not use base objects. Costs nothing and is in this repository's gift, but leaves Example.xml permanently unrunnable as shipped and FISH-0018 permanently unreproducible from the committed file.
The Examples-Load_Test proposed under FISH-0019 (every file in examples/input/ must set up without error) fails on Example.xml today and passes under option 1 or option 2. For the data/ files the equivalent check is a load-only pass over data/trawl/demos/ and data/trawl/movies/, which additionally needs the FISH-0019 migration of Environment/Basic.
Option 1 widens the declared dependency closure of a shipped library for the benefit of input files only; if it is declared visibly, every consumer of fhsim_fishery inherits fhsim_base. Option 2 changes the shipped scenarios and silently drops camera setup from the demo and movie inputs. Option 3 has no code risk. No model code is touched by any of them.
1.9.8