- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 212
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
WIP: refactor: use ImplicitDiscreteSystem
to implement affects in callback systems
#3452
base: master
Are you sure you want to change the base?
Conversation
|
||
dbs | ||
sys isa JumpSystem && reset_aggregated_jumps!(integrator) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vyudu is this now being called on all affects coming from a JumpSystem? i.e. not just affects in callbacks but affects in jumps themselves? Because reset_aggregated_jumps!
has very significant performance implications, and should not be needed for affects coming from within jumps. i.e. it currently isn't used when compiling affects within jumps here,
ModelingToolkit.jl/src/systems/jumps/jumpsystem.jl
Lines 291 to 300 in 1c00326
function generate_affect_function(js::JumpSystem, affect, outputidxs) | |
consts = collect_constants(affect) | |
if !isempty(consts) # The SymbolicUtils._build_function method of this case doesn't support postprocess_fbody | |
csubs = Dict(c => getdefault(c) for c in consts) | |
affect = substitute(affect, csubs) | |
end | |
compile_affect( | |
affect, nothing, js, unknowns(js), parameters(js); outputidxs = outputidxs, | |
expression = Val{true}, checkvars = false) | |
end |
it is only used for affects within callbacks:
ModelingToolkit.jl/src/systems/jumps/jumpsystem.jl
Lines 582 to 583 in 1c00326
cbs = process_events(js; callback, eval_expression, eval_module, | |
postprocess_affect_expr! = _reset_aggregator!) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This is a big PR, so I haven't read enough to understand where this is being used -- I just wanted to double check because of the potential performance implications of calling reset_aggregated_jumps!
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I wasn't aware of this distinction, I'll make sure it only gets called inside the callback affects. The JumpSystem stuff is very WIP still since I want to add an optimization that generates the original explicit updates for systems without algebraic equations. My goal is for the codegen for those cases to be the same as it was before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do JumpSystems support functional affects in callbacks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they should for callbacks, but the user would need to manually add reset_aggregated_jumps!
into their affect function then. I'm not sure if they would be work for affects within jumps though (where there is no need for reset_aggregated_jumps!
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are assemble_vrj_expr
and assemble_crj_expr
for? In general how important is it to keep the ability to generate expressions for the affect functions?
Close #2639 #2612