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
Synchronization of ReactionRate
objects: Reaction
vs MultiRate
#1211
Comments
Out of curiosity, I just tested the option of sharing More broadly, I think there are actually two separate categories of information here where synchronization is a concern. The first is for parameters that define the reaction rate itself, where the question of synchronization is how to get the The other category is "properties" of the rate that are dependent on the state of the |
That's really welcome news! One other thing that's different here is that the blog deliberately randomized the memory structure, whereas for I overall agree with your assessment about the two separate categories, as well as the fact that the second one was just introduced by #1181. My own thinking was that if it were possible to use vectors of pointers, the original |
@speth ... are you planning on converting speth@b8f6132 to a PR? |
I'm not sure it makes sense right now. In light of #1217, it becomes a less-than-complete solution. I think something along the lines of #1051 will be required in any case to get consistent synchronization, and having "just modify |
I agree that things may be somewhat premature and don't think that there is a pressing need. I think it makes sense to defer until after 2.6. |
Problem description
Both 'legacy' and 'new' frameworks copy reaction rate objects into contiguous arrays of objects that are evaluated by
Kinetics
specializations (as all objects are in consecutive memory, access is efficient). As a result, it is necessary to use amodifyReaction
route to change parameters, etc.. In addition, it is also not possible to query internal states of the rate object from aReaction
that was used to originally create the rate.Behavior
The new framework being introduced in 2.6 allows for a more uniform access to
Reaction
andReactionRate
objects, but currently does not synchronize parameters and internal states once aReaction
is added to aKinetics
object. A user attempting to query any information will always access internal states of the original copy owned byReaction
, and is unable to access the copy used for evaluation (see, e.g. discussion in #1181).System information
Additional context
Potential solutions.
ReactionRate
objectAs long as performance is comparable, solution (1) is preferable. Notably, the Python API requires
shared_ptr
s for access, which may create additional overhead. Also see blog post, which indicates that (2) is likely to outperform (1).The text was updated successfully, but these errors were encountered: