Skip to content
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

Event trigger directionality #1715

Closed
paulflang opened this issue Aug 1, 2022 · 9 comments
Closed

Event trigger directionality #1715

paulflang opened this issue Aug 1, 2022 · 9 comments
Labels

Comments

@paulflang
Copy link
Member

I am trying to introduce directionality in an event trigger (i.e. only fire as either up or downpass). IIUC this correctly it should be possible in principle with affect_neg!=nothing in the ContinuousVectorCallback .
But in MTK, I am using a Pair{Vector{Equation}, Vector{Equation}}[] that is passed to continuous_events in the ODESystem constructor. Is there a good way to introduce directionality in a trigger using the ODESystem constructor/continuous_events keyword? My current code is here. Perhaps rather than using ~ in the trigger equation < or > could be used?

@isaacsas
Copy link
Member

isaacsas commented Aug 1, 2022

SymbolicContinuousCallbacks could be modified to accept an affect_neg! function too:

struct SymbolicContinuousCallback

@isaacsas
Copy link
Member

isaacsas commented Aug 1, 2022

@paulflang I can add that for you, but might not be till later in the week.

@paulflang
Copy link
Member Author

@isaacsas : that would be great. But not urgent rn.

@isaacsas
Copy link
Member

isaacsas commented Aug 1, 2022

I'm trying to finish off getting normal events into SDEs and jump processes first: #1714

@SLiemann
Copy link

SLiemann commented Oct 6, 2022

Hi, is there any progress or a workaround for this issue yet?

@cuihantao
Copy link

I have the same need for a directional callback. Currently using ifelse but thinking a directional callback can be more efficient.

@paulflang
Copy link
Member Author

We were discussing this more recently in SciML/SBMLToolkit.jl#101. I close it there, let's continue discussing here.

@isaacsas
Copy link
Member

isaacsas commented Aug 5, 2024

@BenChung this should now be handled by #2911 right?

@ChrisRackauckas
Copy link
Member

yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants