Data base class

[djmallum]

New data base class

New base class for the per-module data class: data_base. Useful for writing modules making use of submodules. Example here using data_base and base_step: https://github.com/djmallum/CHM/blob/develop/src/modules/surface_temperature.hpp.

More details in commit messages.

New submodule base class

base_step name comes from the idea that submodules are steps in a module.

Uses CRTP to avoid v-table overhead. Derived classes are defined as follows:

template<typename data>
class step : public base_step<step,data>
{
public:
    void execute_impl(data& d) const
    {
        // Implementation here
    }
}

data is intended to be the module specific data class derived from face_info.

Derived classses should make use of concepts to enforce getters and setters on data. Example

#include <concepts>
template<typename T>
concept StepConcept = requires(const T& t)
{
    { t.input1() } -> std::floating_point;
    { t.input2() } -> std::integral;

    { t.output1(std::declval<double>()) } -> std::same_as<void>
}

template<StepConcept data>
class step : public base_step<step,data>
{
public:
    void execute_impl(data& d) const
    {
        // Implementation here
    }
}

At the moment, it is recommended to supply everything via functions, even parameters that are set at run time but never changed.

For parameters that are domain wide one could write a function:

const double module::data::foo()
{
    static const double result = cfg.get("result");
    return result;
}

Static ensures that the instance is (a) uniform per instance of data, and (b) set once (thread safe).

It does involve a hidden bool and if check that is evaluated at runtime on every call.

Parameters that are per-face must have a private variable. Designing submodules derived from base_step with getters and setters provides flexibility for the writer.

Future work

Following this, can merge:

1. Submodules derived from base_step
2. Modules using these submodules as well as data_base to couple the calculations.

[Copilot]

Pull request overview

This PR introduces two new base classes for modular code organization in CHM: data_base for per-module data management with caching capabilities, and base_step for implementing submodule execution steps using the CRTP pattern. The data_base class provides lazy evaluation, automatic cache invalidation based on timesteps, and type-safe output handling.

Key changes:

• New data_base<CacheType> template class with cache management, lazy evaluation via update_value(), and output accumulation via set_output()
• New base_step<Derived, Data> CRTP base class enforcing execute_impl() implementation in derived classes
• Comprehensive test suite for data_base functionality including cache initialization, timestep-based invalidation, and default value handling

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 9 comments.

File	Description
src/modules/submodules/data_base.hpp	Implements the core data_base template class with caching, concepts for type safety, and cache lifecycle management
src/modules/submodules/base_step.hpp	Implements CRTP-based base_step class for enforcing submodule execution interface at compile-time
src/tests/submoduletests/test_data_base.cpp	Provides comprehensive unit tests for data_base including cache behavior, value updates, and default value verification
src/CMakeLists.txt	Adds submodules directory to includes and integrates new test file (though most existing tests are commented out)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[djmallum]

Can you comment on the directory structure? Currently the submodule directory is a subdirectory of modules. But it could instead just be in the src directory. As in:

src/modules/submodules

vs

src/modules and src/submodules

[djmallum]

Done + above comment

[djmallum]

I thought about converting this to a draft because I think what is here could be better. In particular, functions required by submodules will look like this:

    double my_module::data::air_temperature() {
        update_value(
            [this]() -> auto& { return cache_->air_temperature; },
            [this]() { return (*face)["air_temperature"_s]; }
        );
        return cache_->air_temperature;
    }

which means constructing the lambda on every single call. And it just has bad boiler plate.

One idea I have is to find a way to create these lambdas in the data constructor.

something like

private:
    // Store bound functions as members
    std::function<double&()> air_temp_cache_getter_;
    std::function<double()> air_temp_face_getter_;
    
    std::function<double&()> water_vapour_cache_getter_;
    std::function<double()> water_vapour_face_getter_;
    
public:
    data() {
        // Initialize getters once in constructor
        air_temp_cache_getter_ = [cache_]() -> double& {
            return cache->air_temperature;
        };
        air_temp_face_getter_ = [face]() {
            return (*face)["air_temperature"_s];
        };

so that

double my_module::data::air_temperature()
{
return update_value(air_temp_cache_getter_,air_temp_face_getter_);
}

where now update_value returns whatever is stored in air_temp_cache_getter_ at the end of the update_value function.

This the same amount of boilerplate really, but certainly eliminates the repeated creation of lambdas.

For now, I think this version is OK and if we notice performance problems then it can be improved.

Also worth noting that macros might be useful here since all the functions that use the cache system look the same.