Benoît Pasquier

Another thing that is sometimes a pain with the current `struct` implementation is its rigidity. You can't change the parameters' `struct` on the fly. Maybe a simpler wrapped array type...

Additional note: an important feature would be the ability to read and write csv files.

I think [this MWE](https://gist.github.com/briochemc/96df33ccaa34195689f1b1365b899dda) of using a large sparse matrix with [ModelingToolkit.jl](https://github.com/JuliaDiffEq/ModelingToolkit.jl) is a good place to start this!

discourse post for reference: https://discourse.julialang.org/t/solving-for-the-steady-state-of-a-large-nonlinear-ode-in-sciml/50613/16

Some more thoughts and notes on a hard-to-solve mode I stumbled upon. It took 75 iterations of the CTKAlg, with about 50 of them going through a two-step Armijo line...

Maybe classify diagnostics in different groups (passages, age, and so on) and lay down a plan to implenent them. E.g., automate the extraction of the equivalent linear models and use...

Somehow it might be nice to have a struct detailing the model generated as well, i.e., containing metadata about the model. See DSL branch for trials.

Also might be good to replace the current parameter API into something like ```julia @parameters "MyParams" begin a | 1.0u"m/s" b | 2.0u"m^2" end ``` Hopefully [this issue in FieldMetadata.jl](https://github.com/rafaqz/FieldMetadata.jl/issues/7)...


Agreed. If I find the time, I will try and revamp the API to focus on `observations` only when GEOTRACES IDP21 comes out (in less than 10 days). The idea...