refactor generic hybrid

[lazarusA]

With this PR all the following will be removed and unified into only one HybridModel struct/function.

• SingleNNHybridModel [gone!]
• MultiNNHybridModel [gone!]
• constructHybridModel (is back!) for backwards compatibility.

and now only

HybridModel is needed.

@BernhardAhrens this will be highly breaking for the user.

Edit:
this works again constructHybridModel!

closes #191

[github-actions]

📚 Documentation preview 🚀

Preview URL: https://EarthyScience.github.io/EasyHybrid.jl/previews/PR274/

Note

The preview will be available once the documentation build completes successfully, and will reflect the last successful build for this PR.

[gemini-code-assist]

Code Review

This pull request consolidates SingleNNHybridModel and MultiNNHybridModel into a unified HybridModel struct, simplifying model construction, initialization, and forward pass logic across the codebase. The review feedback highlights several critical performance and correctness improvements: resolving a recursive configuration nesting issue in tune.jl by excluding the :config field before merging, avoiding inefficient vector comprehensions when constructing NamedTuples in prepare_data.jl, and replacing iterative merge loops with type-stable map operations in GenericHybridModel.jl to prevent excessive allocations and type instability during parameter initialization and the forward pass.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[BernhardAhrens]

Let's really stick with constructHybridModel - I think in the end that the rename is unnecessary and confusing. When I call a function named HybridModel I would expect that it runs the hybrid model but that's not what the function does. What it does is that it constructs a hybrid model that you have to run/train in the next step

[lazarusA]

I would expect that it runs the hybrid model

well, with the proposed changes, it actually does that when the arguments are the appropriate ones. This is handle in the forward run definition of HybridModel,

function (m::HybridModel)(ds_k::Tuple, ps, st) ... end

I will bring-back the interface constructHybridModel while we iron things out, and will not merge until things are totally clear.

The recipe is basically,

1. Define struct

struct test 
a
b
end

2. constructor

function test(args...)
  a, b = args
  return test(a,b)
end

3. forward run

function (m::test)(data, ps, st)
  # your logic using `m` and `data`
  return out, st_new
end

[BernhardAhrens]

But the users never does a forward run with this signature (?), it is under the hood:

function (m::test)(data, ps, st)
  # your logic using `m` and `data`
  return out, st_new
end

The constructor is clear but the user then runs a function with the name of his hybrid model? Or can you give any example for a forward run with HybridModel. I would say the constructHybridModel is meant to be similar to SciML's ODEProblem which is then called with a function solve

[lazarusA]

updated all function constructors to constructHybridModel. Things should be as before now.

@BernhardAhrens good to merge now?

[BernhardAhrens]

Nice! I like the new tutorial @lazarusA Ready to be merged

[BernhardAhrens]

Thanks :) Nice refactor - should make things easier down the road