This page reports the downstream check of the net-hydrodynamics plan (WP-D3, § "Downstream check"): fhsim_fishery runs data/trawl/movies/trawl/morenot520/Trawl.xml against fhsim_marine_elements 3.2.1 and 4.0.0, and the change in trawl loads is recorded as information, not as a pass/fail test. Run on 2026-09-27.

1. Result

‍**Superseded by the steady tow of WP-I1 (2026-09-27, § 4.3 Steady tow (WP-I1, 2026-09-27)).** The 1.0–1.9 MN figures below were an artefact. The net file set MaxAcceleration = "10", and the limit made the net drive itself into the warp clamp (MARE-0133). They were not net drag and not an effect of the 4.0 load laws. Settled, with only the limit switched off, the net drag is 90 kN under the default law, 114 kN under TwineCrossFlow and 131 kN under 3.2.1. The limit has since been removed from the library (MARE-0133, owner ruling R40), and the attribute from the fishery net files (FISH-0080).

fhsim_fishery builds against fhsim_marine_elements 4.0.0 without a source change and without a compiler warning, once its version ranges admit 4.x and the fhsim_base conflict (§ 2.1 What a downstream build needs) is resolved. The input runs to its end time (300 s) under 4.0.0 with both laws tried.
The input as committed does not load headless in either version: it uses the 2.x Environment/Basic object, which no 3.x library registers (fishery FISH-0078, on fishery branch wp/D3-downstream; FISH-0019 fixed examples/input/ only). All numbers below come from a scratch copy with the fhsim_environment Environment block (§ 3. Input).
The scenario does not reach a steady tow in either version, so no single drag change can be given. It is a cold start (vessel at x = 535 m, gear at rest near the origin, no initial-state file; the committed workflow movie.cmd used TrawlPrepare.xml with a states file that is not in the repository). Under 3.2.1 the warp tensions reach the cable's MaxTension of 1 MN (Warp.xml, Bridle.xml) from 65 s to 208 s and keep swinging between 1 and 1000 kN until 900 s; door spread stays between 1 and 44 m and the headline changes sign against the fishline. At MaxTension the cable element stops resisting further stretch: CableElBasics.cpp:406-407 bounds the spring-plus-damping force to m_maxTension (same code in 3.2.1).
With the default HydroModel (LocalThroughFlow), the 4.0.0 run reaches MaxTension at 48 s and stays there to the end (100 % of the samples from 100 s to 900 s). The gear lengthens (vessel to codend 710 m against 658 m, 100–300 s mean) as the clamped warps stretch.
With HydroModel="TwineCrossFlow" (a scratch-only change), the 4.0.0 run behaves like the 3.2.1 run over the first 300 s (sum of warp tensions +5 % on the 100–300 s mean, same clamp episode 66–210 s). Continued to 900 s, it diverged after about 500 s (door spread up to 414 m, codend above the sea surface) and the integrator stalled at t = 769 s; the run was stopped after 50 min without progress.

Headline numbers, mean over 100–300 s (all runs cross MaxTension; see the caveats above):

Quantity	3.2.1	4.0.0 LocalThroughFlow	4.0.0 TwineCrossFlow
Sum of warp tensions at the vessel	1112 kN	2000 kN (+80 %)	1170 kN (+5 %)
Towing force, x, sum of both warps at the vessel	1100 kN	1960 kN (+78 %)	1163 kN (+6 %)
Net drag, x, sum of the six bridle forces at the wings	1020 kN	1863 kN (+83 %)	1068 kN (+5 %)
Door spread (warp attachment points, horizontal)	17.4 m	12.8 m (−27 %)	19.2 m (+10 %)
Share of samples with a warp at `MaxTension`	37 %	100 %	55 %

2. Builds

Run	fishery source	fhsim_marine_elements	fhsim_environment / marenv	fhsim_base
before	`main` `ff17183`, exported with `git archive` to a scratch folder and built there	3.2.1 from the Conan cache	3.2.1 / 1.0.32 from the cache	4.0.1 from the cache
after	`wp/D3-downstream` `772310e` (ranges only) in `/home/karlr/_work/_DEV/worktrees/nethydro-wp/D3-fhsim_fishery`	4.0.0 editable, integration branch at `9f64581`	4.0.0 / 2.0.0 editables	4.0.1 built from source against fhsim_environment 4.0.0

Both are no-visualization Release builds with -c tools.build:skip_test=True; FhSim v3.3.0-41a573bf. The editable registration, the profile and the playpen links are in the programme's BUILD.md ("Building fhsim_fishery against the editables (D3)"). The integration branch's own ctest passed 3/3 before the runs (main entry 94 s, TrawlCable_NoClumpWeight, VALIDATION 292 s).

2.1 What a downstream build needs

Version ranges. fishery requires fhsim_marine_elements/[^3.2.0] and fhsim_environment/[^3.2.0]; both become [>=4.0.0 <5] (772310e). fishery does not require marenv.
fhsim_base 4.0.1 requires fhsim_environment/[^3.2.0], and the graph conflicts. For D3 a profile [replace_requires] maps every fhsim_environment/*@sintef/stable to 4.0.0, and fhsim_base is built from source. Neither fhsim_base nor fishery uses the renamed or removed wake API (GetWakeRatio, GetCurrentVelocityFactor, WakeField: no match in either src/). A fishery release on fhsim_marine_elements 4 needs an fhsim_base release that admits fhsim_environment 4.
No source change in fishery: it includes net/NetStructure.h, cable/CableBranched.h and cable/subroutines/InternalCableWithBottomContact.h, none of which lost a symbol it uses.

3. Input

Each run used a scratch copy of the morenot520 folder with these changes to Trawl.xml, none committed:

Environment/Basic (LibName="base") replaced by the block fishery FISH-0019 chose for the examples: LibName="environment" SimObject="Environment", Waves.NumWaves="0", Bathymetry.Depth="190" (the old MeanDepth), Current.Model="Constant", Current.Vector="0, 0, 0" (the file's Environment.CurrentVel), and RandomSeed="1" so that the seabed is the same in both versions.
The Environment.CurrentVel connection deleted (the object has no inports).
PHeadlineC, PFishlineC, PCodend appended to the net's NodesOutputPosAndVel. This adds output ports only (state slices, NetStructure.cpp:765-770).
An <OBSERVERS><FileOutput TOutput="0:1:300" .../> block for the ports in § 3.1 Quantities.
For the TwineCrossFlow run only: HydroModel="TwineCrossFlow" on Net/NetStructure. The log confirms it was read; the default run logs "Parameter HydroModel requested but not found".

The before and default-law inputs are byte-identical. The camera objects were kept (they load headless). The 900 s runs change TEnd and TOutput only. A run is started from its folder with a SimObjectLibraries symlink to the playpen's (FhSim looks for the libraries relative to the working directory). Wall time: 7–8.5 min per 300 s run, one core.

3.1 Quantities

Warp tension: |PWarp.Force1|, |SWarp.Force1| at the vessel, |Force2| at the door. "Towing force" is −x of PWarp.Force1 + SWarp.Force1.
Door loads: |PBridle.Force1|, |SBridle.Force1| (the bridle's force on the door). The door's own position is a state, not an outport, so door spread uses the warp attachment points PDoor.Pos1, SDoor.Pos1.
Net drag: −x of the sum of the six bridle forces at the wing nodes (Force2–Force4 of each bridle).
Headline height: PFishlineC.z − PHeadlineC.z (z down). Not meaningful here: it swings between about −20 m and +20 m in every run, i.e. the net does not hold its shape.

4. Results

4.1 300 s, the input's end time

Mean over 100–300 s (min … max in brackets):

Quantity	3.2.1	4.0.0 LocalThroughFlow	4.0.0 TwineCrossFlow
PWarp tension at the vessel	569 kN (1 … 1000)	1000 kN (1000 … 1000)	584 kN (1 … 1000)
SWarp tension at the vessel	543 kN (1 … 1000)	1000 kN (998 … 1000)	586 kN (12 … 1000)
PWarp tension at the door	557 kN	981 kN	570 kN
SWarp tension at the door	528 kN	980 kN	570 kN
PBridle load on the door	538 kN	950 kN	554 kN
SBridle load on the door	506 kN	954 kN	553 kN
Net drag, x	1020 kN	1863 kN	1068 kN
Door spread	17.4 m (1.0 … 44.4)	12.8 m (1.4 … 22.8)	19.2 m (3.8 … 47.6)
Wing-end spread, PWing1–SWing1	15.6 m	12.4 m	24.8 m
Door depth, mean of both	62 m	90 m	45 m
Vessel to codend, x	658 m	710 m	653 m
Samples with a warp at `MaxTension`	108 of 301 (65–208 s)	253 of 301 (48–300 s)	144 of 301 (66–210 s)

Mean over 250–300 s, to show how much a window changes the answer: sum of warp tensions at the vessel 396 kN (3.2.1), 2000 kN (LocalThroughFlow), 173 kN (TwineCrossFlow); door spread 26.6 m, 9.8 m, 30.1 m.

4.1a Rerun after the phase G load-law changes (2026-09-27)

Rerun by WP-G1 with the same scratch input (§ 3. Input), 300 s, means over 100–300 s, against the ME integration branch with the r ≤ 1 clamp (MARE-0109) and the screen laws' in-plane twine friction (MARE-0111). The TwineCrossFlow run reproduced the table above exactly (1170 kN, 19.2 m, 55 %), which checks the setup.

Run	Sum of warp tensions	Net drag, x	Door spread	Samples at `MaxTension`
3.2.1	1112 kN	1020 kN	17.4 m	37 %
4.0.0 LocalThroughFlow, above	2000 kN	1863 kN	12.8 m	100 %
LocalThroughFlow, integration before G1 (`5d291f0`)	2000 kN	1909 kN	11.3 m	100 %
LocalThroughFlow with the in-plane friction	2000 kN	1900 kN	10.6 m	100 %

The friction changes this cold start by less than its run-to-run sensitivity; the warps stay at the 1 MN clamp. The picture of § 1. Result is unchanged, and it is still no drag estimate (no steady tow). Measurements to compare with: none in the workspace (owner follow-up to Q17; survey in the programme's TRAWL_MEASUREMENTS.md).

4.2 900 s, to see whether the tow settles

Run	End	Samples at `MaxTension`	300 s–end: sum of warp tensions, door spread
3.2.1	900 s, exit 0 (25.9 min)	381 of 901; the last at 887 s	1124 kN, 18.2 m (max 43.8)
4.0.0 LocalThroughFlow	900 s, exit 0 (23.4 min)	853 of 901; 48–900 s	2000 kN, 11.4 m (max 26.1)
4.0.0 TwineCrossFlow	stalled at t = 769 s, stopped	211 of 768	344 kN, 87 m (max 414); diverged after about 500 s

The first 300 s of each 900 s run reproduce the 300 s run.

4.3 Steady tow (WP-I1, 2026-09-27)

fhsim_fishery now has a steady-tow scenario of the same trawl: tests/in/SteadyTow/, the tests SteadyTow_VALIDATION.* (FISH-0079) and the page doc/user/steady_tow.md (fhsim_fishery_steady_tow), on fishery branch wp/I1-steady-tow. It is the rig of Trawl.xml with the environment block of § 3. Input and three changes: MaxAcceleration = "0" in a copy of the net file, a laid-out start and a 120 s speed ramp. (Since MARE-0133 removed the limit, and FISH-0080 the attribute from the net file, the copy is a byte copy of the net file; the two remaining changes are the start and the ramp. The table below was run with the net's limit switched off; rerun after the removal, which also removed the warps' and bridles' 1000 m/s² per-component limit, every figure is within 0.1 %: net drag 90.25 kN and 114.05 kN, fishery doc/user/steady_tow.md.) No load-law, mass, stiffness or damping input was changed. Mean over 350–450 s, settled from about 250 s (each mean changes by less than 0.3 % between 250–350 s and 350–450 s):

Quantity	4.0 LocalThroughFlow	4.0 TwineCrossFlow	3.2.1
Net drag, x, sum of the six bridle forces at the wings	90.3 kN	114.0 kN	130.8 kN
Sum of warp tensions at the vessel	184.0 kN	203.2 kN	216.7 kN
Largest warp end tension over the run (`MaxTension` 1000 kN)	110 kN	122 kN	121 kN
Door spread	104.4 m	83.2 m	74.3 m
Wing-end spread, PWing1–SWing1	32.8 m	26.4 m	23.2 m
Headline height	6.79 m	8.79 m	9.48 m

Against 3.2.1 the default law gives 31 % less net drag and TwineCrossFlow 13 % less. The doors and the groundgear lie on the 190 m seabed, so the net drag includes seabed contact.

What went wrong in D3. The net file's acceleration limit (MARE-0133, since removed) is enough to explain it. The unchanged D3 cold start with only MaxAcceleration = "0" settles at the same plateau (90.3 kN, 105.2 m door spread). With the limit on, every start and ramp tried reached the clamp: a 300 s ramp, a laid-out start with a 60 s or 120 s ramp, and ME 3.2.0, 3.2.1 and 4.0 with either law. The net alone in still water, with the limit on, drives itself to node speeds of 3–8 m/s, also with tight integrator tolerances. With 60–100 m² of twine, no drag law could give more than about 150–260 kN at 2.058 m/s. The published bottom-trawl net drags (10–20 kN, Fiorentini et al. 2004, smaller Italian trawls at 3.5 kn) are 5–10 times smaller than the settled figures. The morenot520 is a large trawl (155 mm meshes, about 49 m of headline, 8 m² doors, 499 m warps, 4 kn), so the settled figures are the order of a large trawl.

5. Diagnosis

(Written for the D3 runs. The cause found later is the net's acceleration limit, § 4.3 Steady tow (WP-I1, 2026-09-27).)

The committed input does not run on 3.x or 4.0. "The simulation object of class "Environment/Basic" was not found", exit 1, in both builds. FISH-0019 replaced the block in the five examples/input/ files only; the data/trawl/movies/ inputs still carry it (open item FISH-0078, on fishery branch wp/D3-downstream).
The scenario is a violent cold start in every version. At t = 0 the warps already carry 100 kN. From about 60 s the load reaches the 1 MN MaxTension of the warps and bridles, and above it the element force is clamped, so the warp stretches freely until the load drops. The 3.2.1 run leaves the clamp and re-enters it for the whole 900 s. Door spread (at most 44 m) and a sign-changing headline height show that the gear never takes a towed shape. This behaviour does not come from the net-hydrodynamics changes.
Under LocalThroughFlow (the 4.0 default) the loads stay above the clamp. The run never leaves MaxTension after 48 s. The migration note then advised HydroModel="TwineCrossFlow" for trawl models (MARE-0111, then open: no in-plane load in the screen laws; since resolved with twine friction only, § 4.1a Rerun after the phase G load-law changes (2026-09-27)). That advice is withdrawn: the default law applies to trawls too (owner answer to Q17, 2026-09-27), and the D3 figures were the acceleration limit's artefact, not a load-law effect (§ 4.3 Steady tow (WP-I1, 2026-09-27)). Why the screen law raises the load in this input was not investigated. The per-panel changes in the migration note are all below +10 % at 0° and large decreases at 80°, so this is a system effect (net shape, clamp, cold start) and not a direct panel-force increase. MeshOpening solidity for this net (t = 3–8 mm, L₀ = 77.5 mm) exceeds the laws' 0.5 clamp once the meshes close below φ ≈ 12° for the 8 mm twine; 3.x clamped at the same 0.5.
Under TwineCrossFlow the first 300 s match 3.2.1 within the scatter, as the migration note says for this law (K = 1 here; K = 1.1 would reproduce the 3.x panel force). The divergence after 500 s, with the integrator stalling at 769 s, is a single observation of a model that is already unsteady in 3.2.1. It was not investigated and is not taken as a 4.0 defect.

6. What would make this a usable comparison

Done in WP-I1 (§ 4.3 Steady tow (WP-I1, 2026-09-27)): the limit off, a laid-out start and a ramp; the test asserts that no warp reaches its MaxTension. Kept for the record:

A settled start: a prepare run that writes an initial-state file, as TrawlPrepare.xml did, or a speed ramp. The first is a fishery-side decision (open item FISH-0078, on fishery branch wp/D3-downstream, covers the environment block of the data/ inputs).
A warp and bridle MaxTension that the steady tow does not reach, or an output of the clamp state, so that a clamped run is recognised.
Then compare towing force, door spread and headline height at the steady tow for 3.2.1, 4.0.0 LocalThroughFlow and 4.0.0 TwineCrossFlow with KnotFactor 1 and 1.1.

Table of Contents