-
Notifications
You must be signed in to change notification settings - Fork 25
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
SSA performance bug regarding order of reactions #265
Comments
I notice that S0->S1 is defined twice in your example. Does the last instance simply replace the first instance? I don’t know the answer - check the NET file to see if the reaction is there only once or twice. I’m assuming a NET file can be generated. If only the last instance of S0->S1 is kept, that would explain why simulation is slower when the fast rule appears last. Try this instead of two rules: S0->S1 kfast+kslow Sent from my iPhoneOn Jun 28, 2023, at 12:59 AM, Leon Herrmann ***@***.***> wrote:
If the last reaction defined in a model file is comparatively fast, then the simulation is significantly slower compared to when a slower reaction is last.
Example: consider a circular model with all equal initial populations and rate constants, but with two additional reactions with higher rate constants
S0 -> S1 (slow)
S1 -> S2 (slow)
...
Sn -> S0 (slow)
S0 -> S1 (fast)
S1 -> S0 (fast)
For such a model with 500 species and the fast reactions being defined last (last.bngl), I get the following results:
TOTAL STEPS: 2525732
CPU TIME: simulate 11.76 s.
If one slow reaction is defined after both fast reactions at the end of the file (second_to_last.bngl), then these are my results:
TOTAL STEPS: 2491560
CPU TIME: simulate 3.15 s.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
I notice that S0->S1 is defined twice in your example. Does the last instance simply replace the first instance? I don’t know the answer - check the NET file to see if the reaction is there only once or twice. I’m assuming a NET file can be generated. If only the last instance of S0->S1 is kept, that would explain why simulation is slower when the fast rule appears last. Try this instead of two rules: S0->S1 kfast+kslow Sent from my iPhoneOn Jun 28, 2023, at 12:59 AM, Leon Herrmann ***@***.***> wrote:
If the last reaction defined in a model file is comparatively fast, then the simulation is significantly slower compared to when a slower reaction is last.
Example: consider a circular model with all equal initial populations and rate constants, but with two additional reactions with higher rate constants
S0 -> S1 (slow)
S1 -> S2 (slow)
...
Sn -> S0 (slow)
S0 -> S1 (fast)
S1 -> S0 (fast)
For such a model with 500 species and the fast reactions being defined last (last.bngl), I get the following results:
TOTAL STEPS: 2525732
CPU TIME: simulate 11.76 s.
If one slow reaction is defined after both fast reactions at the end of the file (second_to_last.bngl), then these are my results:
TOTAL STEPS: 2491560
CPU TIME: simulate 3.15 s.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Both generated NET files contain all 502 reactions. The example also works if I remove the slow "S0 -> S1" reaction. |
Sorry for the delay in getting to this. We will have a look and get back to you next week. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If the last reaction defined in a model file is comparatively fast, then the simulation is significantly slower compared to when a slower reaction is last.
Example: consider a circular model with all equal initial populations and rate constants, but with two additional reactions with higher rate constants
For such a model with 500 species and the fast reactions being defined last (last.bngl), I get the following results:
If one slow reaction is defined after both fast reactions at the end of the file (second_to_last.bngl), then these are my results:
The text was updated successfully, but these errors were encountered: