# v2.0.0 This release adds many features meant to improve either the runtime or the user experience in MoCSI. The main feature of the release is the addition of CPU-based parallelization using the MPI library and framework. ## Additions - MPI support for all currently supported operating systems through their respective MPI libraries (Windows - Microsoft MPI; Linux - Open MPI; MacOS - Open MPI). This includes multi-process support for calculations as well as binary I/O-operations. ```SolarFluxVariablePotter2023Radiosity.h``` is only partially parallelizable due to the mathematical equations having cross-facet dependencies, so speed-ups are reduced when using this module - the rest of the code is fully parallelized. Snapshot functionality is also present when using MPI. All generated output with MPI is in binary format. - A new python file ```mocsi_binary_to_csv_converter.py``` has been added to allow conversion from the binary output files of MPI to the usual MoCSI output csv files. - A ```Dockerfile``` for the full MPI+VTK+CSPICE build, producing a container image with all optional features enabled. This gives a reproducible build/run environment without installing the libraries on the host. See [Installation → Docker](installation/docker.md). - Support for Compressed Sparse Row (CSR) format matrices in all areas of MoCSI, where matrix operations are used - mainly the finite elements and their managers and solvers and within the radiosity module. This change also results in measurable speed-up. - Module/Submodule creation is now fully dynamic - only managing modules which are present in the managing_modules field in the run ini are created and only submodules present in the ini files of either loaded managing modules or submodules are created. This enables running MoCSI without the need for *every* ini file being present, but only the ones for the actually requested modules/submodules. - Reworked module creation to allow access to public module fields and functions from within other modules through static access pointers. This allows limited module-to-module communication in cases where using a separate field in the field map is either not feasible or would lead to significant extra development workload. - Improved and expanded error handling where errors now tag the name of their origin script onto the message to allow for easier traceability. - Removed warnings thrown during compilation to allow for a clean compilation where the user can more easily spot errors within the compiler messages. - Two new save modes for ```OutputCsvTool.h```: ```time_interval``` and ```time_interval_surface```, which restrict data recording to user-defined UTC time intervals (set via ```interval_start_times_utc``` and ```interval_end_times_utc```). This is useful for recording only a specific phase of a simulation, e.g. the period after an equilibration run. - A relative convergence criterion for the inner iteration loop, configurable through the new ```relative_epsilon_inner_iterations``` parameter. The inner iterations now also stop once the change between iterations relative to the field maximum drops below this value, complementing the existing absolute ```epsilon_inner_iterations``` criterion. - Usability improvements to the interactive configuration generator ```mocsi_config_generator.py```: tab characters are now allowed inside quoted string values, `````` filesystem path completion is available at the prompts (with a graceful fallback when ```readline```/```pyreadline3``` is not installed), commonly used directories now have sensible defaults, and all generated input/output paths are normalised to forward slashes so the generated configs work out of the box on Windows. ### New modules/submodules - Added ```HeatCapacityVariableCustomPolynomial.h``` module, which allows the use of a heat capacity description through a 4th order polynomial with user supplied coefficients. - Added ```HeatConductivityVariableKiradjiev2019PorousRockSolidRadiation.h``` module, which allows the use of a thermal conductivity description for porous rocks with radiative energy transport within the pores established by Kiradjiev et al. (2019) and based on the Maxwell model. ## Behavior changes - Optional build features are now explicitly **opt-in and OFF by default**. VTK (previously auto-detected), CSPICE and MPI must each be enabled at configure time via ```-DINCLUDE_VTK=ON```, ```-DINCLUDE_CSPICE=ON -DCSPICE_DIR=...``` and ```-DINCLUDE_MPI=ON``` respectively. When MPI is enabled a separate ```mocsi_mpi``` executable is built alongside the serial ```mocsi```. See the installation instructions for the full flag table. - ```HeliocentricDistanceVariableSpice.h``` now requires the parameter ```abcorr``` which allows for aberration and light time corrections to be applied to the spkpos calls to the SPICE library. - ```SolarVectorVariableSpice.h``` now requires the parameter ```abcorr``` which allows for aberration and light time corrections to be applied to the spkpos calls to the SPICE library. - When using MPI, the snapshot files created by ```SnapshotCreator.h``` will be 2 files instead of 1. They can, however, still be used in the same way, as when not using MPI. - When using MPI, output generated by ```OutputCsvTool.h``` will be in binary instead of ASCII. ## Deprecations - None. ## Bug fixes - Requesting a submodule that is not present in the registry now raises a clear error naming the missing submodule and the module that requested it, instead of crashing silently. - Fixed a bug where the ```mocsi_config_generator.py``` file was missing functions. - Fixed a bug where the ```m_save_steps``` parameter within ```OutputCsvTool.h``` would not be filled when selecting the saving option ```specific_time_steps_surface``` and would result in no data being saved. --- # v1.0.0 First public release of MoCSI (2025-09-09). These notes are added retroactively — v1.0.0 predates this changelog. v1.0.0 provides the serial MoCSI thermophysical model (TPM) for dry, airless bodies — no ice/water and no atmosphere — distributed as pre-compiled executables for Linux x64, macOS arm64 and Windows x64, plus source archives. > **Runtime note for the pre-compiled v1.0.0 binaries:** they were built with shape-model support enabled and are **dynamically linked against VTK**, so they require a matching VTK installation on the target machine to run. The required VTK version is **not the same on every platform** — each asset was built against the VTK that was current on its build machine, and the binaries resolve their VTK libraries by version-tagged name, so an installation with a different version will not satisfy them: > > | Asset | Required VTK | Recorded as | > |-------|--------------|-------------| > | Linux x64 | **9.1.x** | sonames ```libvtk*-9.1.so.1``` | > | Windows x64 | **9.4.x** | DLLs ```vtk*-9.4.dll``` | > | macOS arm64 | **9.4.1** | dylibs ```libvtk*-9.4.1.dylib``` | > > Linux and Windows tag their libraries with major.minor only, so any patch release of that minor line works (9.1.x and 9.4.x respectively); the macOS dylib names carry the full version, so that asset needs 9.4.1 specifically. This requirement was not stated at release time and is documented here after the fact. From v2.0.0 onward, the exact build flags and library versions of every released asset are documented explicitly (see the release notes).