Initialisation Summary

Initialisation is a fundamental part of any OSMOSE simulation. Because OSMOSE is a stochastic, school-based, multispecies model, the initial condition is not just a total biomass by species. It must define, directly or indirectly, the demographic and ecological structure from which the simulation begins. In practice, this means specifying or reconstructing enough information to determine total biomass, age or size structure, the number of schools used to represent the population, trophic level, and, depending on the method, spatial distribution. Initialisation therefore conditions the early demographic and trophic dynamics of the model and can influence not only the length of the transient adjustment, but also the long-term regime eventually reached by the simulation.

This point is closely related to, but distinct from, spin-up. Initialisation is the construction of the starting state at simulation time zero. Spin-up is the subsequent adjustment phase during which the model evolves from that imposed state towards a regime more consistent with its equations, parameterisation, and forcing. In some applications, especially steady-state ones, spin-up is a central part of the workflow. In interannual simulations, however, the early transient dynamics are often part of the target of the analysis, so a satisfactory initial condition is one that already captures the relevant demographic and ecological structure at the beginning of the run.

OSMOSE 4.4 currently supports three main conceptual routes for initialisation. The preferred default for most applications is reconstructed population-level initialisation. In this workflow, the user provides a data layer, typically biomass, yield, catch-at-length, and a small number of additional inputs, together with the regular species parameterisation already required by OSMOSE. These inputs are used to reconstruct a plausible class-based initial population structure for each focal species. The result is written as a population.initialization.* block describing total biomass, biomass allocation among classes, size boundaries, ages, trophic levels, and the number of schools per class. The OSMOSE core simulator then expands this population-level description into the school-based runtime state used at the beginning of the simulation.

The second route is direct school-based initialisation. Here, the initial condition is provided explicitly as a restart-like netCDF file referenced through population.initialization.file. This file contains one record per school, including species identity, position, abundance, age, length, weight, and trophic level. This is the most explicit and direct representation of the initial state, and it is particularly suitable for restart workflows, coupling applications, or cases where a school-based state already exists. Its main limitation is practical: preparing a valid school-level initial-condition file can be demanding when such a file is not already available.

The third route is egg seeding initialisation. This is a legacy, reproduction-based mechanism implemented within the reproduction process of the OSMOSE core simulator. It does not provide a complete initial state directly. Instead, it can generate eggs artificially from a user-defined seeding biomass or abundance when no eggs are produced by mature schools and the simulation is still within the configured seeding period. In practice, this route can serve two related purposes: it can help establish the first reproducing population when mature individuals are initially absent, and it can also act as a safeguard against irreversible collapse by maintaining a minimal reproductive source. It is therefore useful in some situations, but it offers much less direct control over the resulting initial state than the two explicit representations above.

A key practical distinction in OSMOSE 4.4 is the difference between three representations that may appear in the same workflow. First, there is the data layer, that is, the observational and biological information used to reconstruct an initial state. Second, there is the generated population-level initialisation block, namely the population.initialization.* parameters. Third, there is the final school-based runtime state created by the OSMOSE core simulator. These are not interchangeable objects, and much of the practical confusion around initialisation comes from moving between them without keeping their roles distinct.

For most applications in OSMOSE 4.4, the recommended workflow is therefore clear: use reconstructed population-level initialisation, inspect the generated population.initialization.* block explicitly, and archive both the upstream data-layer inputs and the generated initialisation block. Direct school-based initialisation should be used when an explicit school-level state is already available or required, and egg seeding should be regarded as a complementary route for specialised cases where parameter-free or anti-collapse behaviour is needed. In all cases, the central principle is the same: the initial condition is part of the model definition, and its adequacy should be assessed in relation to the purpose of the simulation, not treated as a purely technical detail.