Repository navigation
Initialisation Limitations and outlook
The initialisation module implemented in OSMOSE 4.4 is functional and flexible, but it also reflects the historical evolution of the model. The different methods documented in the preceding sections were not all designed at the same time or for the same modelling context. As a result, the current implementation combines conceptually distinct workflows, legacy mechanisms retained for practical reasons, and later extensions introduced to increase applicability. This section summarises the main limitations of the present implementation and explains why a broader recoding is planned for a future release.
One of the main limitations of the current initialisation module is that it is the product of successive additions rather than a single unified design. Egg seeding initialisation belongs to an older stage in the development of OSMOSE, when explicit alternatives for describing the initial state were more limited. Direct school-level initialisation arose naturally from restart and coupling needs. Reconstructed population-level initialisation was later developed to provide a more practical route for ordinary applications. On top of that, additional branches were progressively introduced to support more data-poor contexts.
This history is understandable and, in many ways, scientifically productive. However, it also means that the current module includes several overlapping concepts and several configuration layers that are not always immediately transparent to users. Some parameter names reflect earlier terminology rather than the most descriptive current terminology, and some procedures are best understood as utilities or bridges between workflows rather than as cleanly separated methods.
Reconstructed population-level initialisation was originally developed in a data-rich context, where biomass, yield, and catch-at-length information were normally available for focal species. This remains the context in which the method is most coherent and most strongly constrained.
When the method is used outside that original setting, it can still be practically useful, but some of its assumptions become more exposed. For example, when biomass is replaced by a biomass guess, or when catch-at-length is absent and selectivity must be assumed rather than inferred, the reconstruction becomes less empirically anchored. The method still produces a workable initial state, but it does so by relying more strongly on the rest of the species parameterisation and on the user’s assumptions.
This is not a defect in itself, but it does mean that the same method can behave rather differently depending on the amount and type of information supplied. A module originally designed for one data context has therefore become a more general tool through successive extensions, and this broader flexibility comes at the cost of conceptual simplicity.
A further limitation concerns the structure of reconstructed population-level initialisation itself. The reconstruction procedure operates species by species, using a single-species approximation to infer a plausible initial demographic structure from biomass, yield, and related life-history information.
This is a reasonable and practical choice, but it is still an approximation. It does not explicitly solve the full multispecies interactions that will govern the simulation once the OSMOSE core simulator starts. Predation interactions, competition effects, and full ecosystem feedbacks are therefore not part of the estimation stage. Instead, they begin only after the reconstructed initial state has been converted into schools and the full simulation is launched.
In practice, this means that the reconstructed state should be understood as a coherent starting approximation rather than as a fully equilibrated ecosystem state. For many applications this is entirely sufficient, especially when followed by an appropriate spin-up. However, it remains a structural limitation of the current method.
Another source of difficulty in the current implementation is the coexistence of multiple representation levels for the initial state. Depending on the workflow, a user may interact with:
- observational and biological inputs used in the reconstruction;
- a generated population-level parameter block;
- or a direct school-level file.
These are not equivalent representations, and moving between them is not entirely lossless. A school-level state can be aggregated into a population-level block, but that aggregation loses detailed school identity and explicit spatial information. Conversely, a population-level block can be expanded into schools, but the realised school structure includes random within-class allocation and is not identical to an explicitly provided school file.
This multiplicity of representations is scientifically legitimate, but it complicates both documentation and usage. Users may think they are modifying the initial state directly when they are actually modifying only the inputs used to reconstruct it, or they may assume that a generated population-level block is identical to a school-level initial condition when it is only an aggregate representation of one.
The current configuration also suffers from a degree of terminological inertia. Some parameter names are tied to older terminology and do not necessarily reflect the clearest conceptual names for the methods as described in this document. A good example is the activation flag for reconstructed population-level initialisation, whose name still refers to “relative biomass” initialisation, the original name of the implementation even though the method reconstructs much more than biomass alone.
Similarly, some auxiliary outputs or method-specific parameters reflect implementation history rather than a fully harmonised design. This does not prevent the module from being used correctly, but it increases the burden on documentation and user interpretation. In practice, it means that a technically valid configuration can still be conceptually confusing if the user does not know which parameters belong to which stage of the workflow. Parameter naming is something that will be improved in the future.
The current module also places strong demands on reproducibility practice. In reconstructed population-level initialisation, the actual initial state used by the OSMOSE core simulator is the generated population.initialization.* block, not merely the observational and biological inputs that were used to reconstruct it. If users archive only the input data but not the resulting generated block, then the exact initial state used in a given simulation may be harder to recover later, especially if code or parameter settings evolve.
Likewise, if users rely on direct school-level initialisation, the school-level file itself becomes a key part of the experimental design and must be archived as such. These requirements are manageable, but they make it especially important to distinguish between input data, generated representations, and final runtime state.
Taken together, these limitations explain why a broader recoding of the initialisation module is planned for a future release of OSMOSE. The goal of such a recoding is not to change the scientific motivation of initialisation, but to make the implementation more coherent, more transparent, and easier to use.
A future redesign could, for example, clarify the separation between conceptual methods and utility conversions, harmonise terminology, reduce ambiguity between data-layer and initialisation-layer parameters, and make the expected representations of the initial state more explicit. It could also improve support for data-poor workflows by incorporating them as first-class design cases rather than as later extensions to a method originally conceived for data-rich applications.
With the planned transition of the OSMOSE core simulator to a C++ implementation in version 5, this is also an appropriate moment to revisit the architecture of initialisation more generally. A clearer separation between preprocessing, generated initial-state descriptors, and runtime instantiation would make the module easier both to document and to maintain.
These limitations should not be interpreted as a reason to avoid the initialisation methods documented here. OSMOSE 4.4 provides workable and scientifically useful routes for constructing initial conditions, and in many applications the current workflows are entirely adequate.
The practical implication is instead that users should approach initialisation with care, especially when working outside the original data-rich design of reconstructed population-level initialisation or when moving between school-level and population-level representations. Clear documentation, explicit archiving of the actual initial-state representation used in a run, and routine inspection of generated initialisation outputs are therefore not optional extras. They are part of good modelling practice under the current implementation.
In that sense, the present document has a dual role. It documents the methods as they exist in OSMOSE 4.4, and it also provides the conceptual clarity needed to use them safely until a more unified module is introduced in a later release.