-
-
Notifications
You must be signed in to change notification settings - Fork 553
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
Separate differential states that can be explicitly integrated #2240
Comments
@abillscmu |
This is a specific case of a more general feature, which would be to notice when blocks of the jacobian are independent of each other (e.g. the two particles in the SPM with constant current, the two particles and the electrolyte in the SPMe with constant current) and solve them separately in parallel. I don't know if any of the solvers are already doing this automatically |
Option 1 is better. More specifically the model should be solved in 3 steps:
model.rhs = {Q: 4}
model.initial_conditions = {Q: 1} gets replaced with A preliminary implementation could skip step 1 and just do steps 2 and 3 first. |
In all of the battery models, there is the state
Q=Variable("Discharge capacity [A.h]")
, which is just the integral of the current. This variable does not appear in any of the rhs or algebraic equations.This might be making the problem unnecessarily stiff. In particular, this is causing problems for the "Rest" steps, where dQ/dt = 0 which makes the first line of the Jacobian all zero and hence the Jacobian singular.
We should not be solving for Q at the same time as the rest of the model, since we can just do a post-processing step where we integrate the current. However, we still want to be able to access Q just like the other variables with
solution["Discharge capacity [A.h]"]
. I can think of two approaches:Q
does not appear anywhere in the rhs or algebraic equations and moving it to a different dictionaryrhs_explicit_integration
Q
in a different dictionaryrhs_explicit_integration
when creating the modelThen the
rhs_explicit_integration
dictionary can be handled by the solver after the other variables have been solved for, e.g. usingcumtrapz
. Ideally, this wouldn't even be done until the user callssolution["Discharge capacity [A.h]"]
(i.e. theSolution
object handles it, maybe by adding some functionality toProcessedVariable
)The text was updated successfully, but these errors were encountered: