Now I finally got posting permission: How about we go with the names
Jy -> jacobian_ode_states
Jtheta -> jacobian_ode_params
I think that will make it even more clear what is meant.
I’d go with Jy and Jtheta in code—it follows
the standard convention of using J for Jacobians and our
convention of using y for states and theta for parameters.
But the longer form’s OK, too, if you find it clearer.
A further object I was thinking about to create was
This object would create all the needed derivatives of the sensitivity states using as input the sensitivity states and the jacobian_ode*. This object would also contain the decoupling operation. For the boost odeint integrator and the CVODES integrator we would then create very light wrappers around ode_rhs_sensitivity. The odeint adapter essentially glues together ode_rhs and ode_rhs_sensitivity while for CVODES ode_rhs output is feed to a different function than the ode_rhs_sensitivity.
I think it’ll be more efficient if you do this with templates
and concepts (in the C++ sense of “concept”). Look at it from
the perspective of which services the two (or more?) integrators
If the decoupling operations line up one-to-one with the Jacobian
operations, then you can put them together. But it’s often easier
to keep things minimal as it makes testing and composition into
bigger objects much easier.
What I want to avoid is having one big object that has functions
that may or may not work in various contexts (they’ll have to be
defined, but then set to throw exceptions or something when not
One question I still have is how to pass things around. That is, the greatest flexibility would be to use MatrixBase from Eigen as it allows to pass by reference views into sub-arrays form one to the next function. Are there other ways of achieving this, should something like this be avoided anyways or is there another way to do this?
If it’s matrices, that’ll be more efficient than forcing copies
by using Eigen::Matrix. It’s also harder to code and test because
of possible instantiations and the fact that Eigen isn’t perfect
at implmenting everything for every expression template.
To develop the concept further - is writing dummy code a good approach? By that I mean to write functions and objects without their bodies, but rather specifying their signatures.
Yes. Outline the classes and signatures and any
inheritance/extension relations. If you draw that
out graphically, you get UML diagrams. But I don’t find
UML diagrams any more enlightening than graphical diagrams
of graphical models.