Build ODEInfo from InstanceModel

[bmaclach]

Currently, the InstanceModel type is not sophisticated enough to be able to detect when an instance model is an ODE and extract the required information from the instance model to solve the ODE. Thus, users must compile the ODEInfo object on their own, meaning the ODE-related information must be specified in two places (InstanceModel and ODEInfo).

We should instead build the ODEInfo automatically based on the InstanceModel. This requires changing the InstanceModel type such that the required information can be extracted. Some steps in this direction were taken in the QDef-In-InstMod branch.

It may make sense for the ODEOptions object, which is contained in ODEInfo, to still be defined by the user, instead of being automatically generated, because the information contained in ODEOptions may not end up being included in the InstanceModel representation for ODEs. The goal is just for the user to not have to specify the same information more than once.

[smiths]

Great issue @bmaclach. I agree that the user will still specify some information in ODEOptions. The Instance model captures the physics, but it should be written abstractly. How to satisfy the physics, in this case using an ODE solver, is a separate stage in problem solving. We will always have to add information as we go from abstract requirements to concrete implementations. As you have stated though, we don't want to have to repeat the same information in more than one place. We can add knowledge, but any transformation of knowledge should be automated.

[JacquesCarette]

There are a few issues related to this already - I think all of them are assigned to me. It is still on my list to try to recapture the ideas in the branch back into main. The basic idea is to have our 'models' have more static information in them. Right now, too much of the information is 'buried', or 'encoded'. This is sufficient for printing and some amounts of code generation, but not enough to do anything "smart" with the information. We need to teach Drasil that ODE Models are a thing.

[cd155]

To record meetings in #2943
With the work of splitting out the model kinds, we are one step further knowing when a model is an ODE.
Currently, we manually build ODEInfo and ODEOptions. Some information should available in Instance Model. Instead of building the ODE model manually, some information should retrieve from Instance Model.

[cd155]

Here are two ways to make ODEInfo automatically created from Instance Model. I think both of them seem fine, but any suggestion would be really appreciated. Here are potential changes. @JacquesCarette

1. Build the ODEInfo base on DifferentialModel,
   DifferentialModel is one kind of ModelKinds. We can extract DifferentialModel from InstanceModel. Then, having a smart constructor take DifferentialModel as a parameter and output an ODEInfo.

or

2. Integrate ODEInfo into ModelKinds
   We can map DifferentialModel to ODEInfo internally in the ModelKinds. In this case, we no longer create an ODEInfo manually, it automatically is created in the ModelKinds. (Discussed this method with @balacij)

I think both methods could automatically generate the ODEInfo.

• The first one has less automation than the second one, and the user has to call the smart constructor to get ODEInfo.
• The second one does not expose the ODEInfo to users anymore.

[JacquesCarette]

It depends. I forget exactly what information is in ODEInfo. I'm pretty sure we wouldn't want all of it into the DifferentialModel. So I don't think that either suggestion is possible in full, but it might be partially possible. The first step in either case starts with us analyzing what information is in ODEInfo and where that information belongs.

[cd155]

Here is a breakdown of ODEInfo and DifferentialModel.

ODEInfo has:

• independent variable
• dependent variable
• other variables (any variable besides independent and dependent)
• initial time
• final time
• initial value
• ode equation
• ode criteria (include tolerance, step size, which method to solve ODE eg. Runge-Kutta 4-5)

DifferentialModel has

• independent variable
• dependent variable
• ode equation
  • other variables can be extracted from ode equation

This is toward what @smiths said as a general solution in #473 (comment) . The next step can add an initial value problem(IVP) data type which contains initial time, final time, initial value. With the IVP data type, we can get a specific solution. This can leave the design space for the Boundary value problem if we want to add it later. Last, ode criteria will be excluded from DifferentialModel.

[smiths]

@cd155 do you mean that an IVP will have the information from a DifferentialModel, and add initial time, final time and initial value. This would make sense to me.

I like your point about being able to expand to BVPs in the future.

For ODEInfo, you mention "other variables". I think we should refer to these other variables as parameters.

[cd155]

Thanks for clarifying, I will change other variables to parameters

With regard to the information IVP, initially, I thought I can make the whole DifferentialModel be IVP since we only have IVP so far. All IVP-related information will cluster into one data type, so it can make future change easier. With the conversation developed, @smiths do you think I could treat the DifferentialModel as a gerenal solution. If we treat the DifferentialModel as a general solution, we can have an IVP have the information from a DifferentialModel, and add initial time, final time and initial value.

[smiths]

@cd155, we want the design to include the characterization of the general ode (without initial values or boundary conditions), the IVP and eventually the BVP. For higher order ODEs, there can also be a combination of initial values and boundary conditions. As long as your design doesn't preclude adding other combinations of initial and boundary values, that is fine with me. If you write out the skeleton code for your proposal, @JacquesCarette can review it to make sure that it is future proof.

[JacquesCarette]

Actually IVP shouldn't have final time as part of its data. We could have a "time-bounded" (or perhaps "region-bounded"?) version of IVP that also did that. Specifying an end-point is a frequent refinement, but shouldn't be required.

[cd155]

@JacquesCarette A quick question, what would the "time-bounded" look like in the IVP? The final time indicates when the specific solution will stop, how the "time-bounded" is different than the final time?

[JacquesCarette]

By "time bounded" I mean that one will only ever look at the solution inside that interval. The solution to an ODE is a function, valid at all intermediate times. "final time" makes it feel too much like we're only interested in the value at the end and nowhere else, which is often not the case.

[cd155]

This ticket is partially complete.

There are two ways to build the ODEInfo.

• set the ODEInfo explicitly. This is sometimes called writing equations manually. Basically, we rewrite the ODE based on the original ODE via its constructors.
• In the example of single higher-order ODEs, we complete building the ODEInfo from InstanceModel. In the InstanceModel, we use DifferentialModel as the model of the ODE. The automation is only working for a single ODE.

In the future, we would like it to be fully automated. In the Double Pendulum, we still write ODE manually because this example has a system of higher-order ODEs. In my final report, section 4.1 Higher Order to First Order, details how to transform a higher order ODE to a system of first-order ODEs. For the example of Double Pendulum, we have two second-order ODEs in the couple. We could transform the equation one by one; it will end up with two system of first-order ODEs. Later, we can combine these two system of ODEs into one system of first-order ODE. In theory, it is achievable.

[balacij]

What do you mean by 'fully automated' @cd155? Your work for the IVPs seems to make it quite smooth. There might be alternative ways, but I think that we wouldn't be able to go about those ways without reevaluating how we convert IMs to 'code fragments' entirely.

[cd155]

@balacij 'fully automated', I mean Drasil would automatically generate a system of ODE. Drasil can generate a single high-order ODE for the solver without explicitly writing it down, but it can't generate a system of ODEs.

[smiths]

I wonder if we should close this issue in favour of creating a new issue related to automatically handling systems of higher-order ODEs?

[cd155]

@smiths I can create a ticket if that is the preferable approach. Should we close this ticket and create a new one for automatically handling the system of higher-order ODE? @JacquesCarette

[JacquesCarette]

Yes, let's close this one as done and open a new one.

[cd155]

I created #3385 and closed this one.