-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build ODEInfo from InstanceModel #2194
Comments
Great issue @bmaclach. I agree that the user will still specify some information in |
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. |
To record meetings in #2943 |
Here are two ways to make
or
I think both methods could automatically generate the
|
It depends. I forget exactly what information is in |
Here is a breakdown of ODEInfo and DifferentialModel. ODEInfo has:
DifferentialModel has
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. |
@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. |
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. |
@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. |
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. |
@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? |
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. |
This ticket is partially complete. There are two ways to build the
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. |
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. |
@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. |
I wonder if we should close this issue in favour of creating a new issue related to automatically handling systems of higher-order ODEs? |
@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 |
Yes, let's close this one as done and open a new one. |
I created #3385 and closed this one. |
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 theODEInfo
object on their own, meaning the ODE-related information must be specified in two places (InstanceModel
andODEInfo
).We should instead build the
ODEInfo
automatically based on theInstanceModel
. This requires changing theInstanceModel
type such that the required information can be extracted. Some steps in this direction were taken in theQDef-In-InstMod
branch.It may make sense for the
ODEOptions
object, which is contained inODEInfo
, to still be defined by the user, instead of being automatically generated, because the information contained inODEOptions
may not end up being included in theInstanceModel
representation for ODEs. The goal is just for the user to not have to specify the same information more than once.The text was updated successfully, but these errors were encountered: