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

Release v0.14.0 #278

Merged
merged 4 commits into from
Nov 6, 2024
Merged

Release v0.14.0 #278

merged 4 commits into from
Nov 6, 2024

Conversation

k-arakane
Copy link
Contributor

Hello @himoto!
Sorry I haven't been able to actively work on this project lately. Although the feature discussed in #274 is still under development, I though we should make the other updated features available by releasing a new version.
I hope you can take your time to review the changes and let me know if we need any further discussions, thank you!

k-arakane and others added 3 commits June 13, 2024 13:49
…273)

It should be acceptable to have experimental data with different time
points between conditions for the same observable (as in [Raia *et al.*,
2011](https://doi.org/10.1158/0008-5472.CAN-10-2987)), but currently it
is only possible to vary the time points between the observables.

Here, I modified the `get_timepoint()` function to return a dictionary
(`{ "condition": list(tpoints) }`) to offer more flexibility while
trying not to complicate the code too much.

Due to this change, I needed to alter several parts of the code
including `get_timepoint()` of the example model files. I also added a
replication of Raia *et al.*'s JAK-STAT model to showcase an actual use
case of this feature.

I would like to know what you think about changing the return type of
`get_timepoint()`, because alternatively I think we can pass the
condition name as one of the inputs to achieve the same effect.

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Hiroaki Imoto <hiroaki.imoto@ucd.ie>
This PR makes the following two changes to how the user-defined `@rxn`
reactions are handled within the code:

- fixes wrong variable in `user_defined()`

There was a line that incorrectly refers to `product` instead of
`reactant` when handling user-defined degradation reactions (e.g., `@rxn
A -> 0:...`), which led to the placeholder variable (`"0"`) being
included as one of the species in the resulting model.

- Adds feature to allow multiple reactants and/or products in
user-defined reactions

Currently, the `@rxn` reaction type only accepts single reactant and
product reactions. Changes were made to allow users to describe custom
reactions with multiple reactants/products by concatenating them with a
`+` symbol within the Text2Model file.

The implementation of this feature mimics that of the
`state_transition()` function.

I will attach a toy Text2Model file that I used for testing below.

I would appreciate any type of comments/suggestions. Thanks in advance!

```
@rxn 0 -> A: p[kf_a] | kf_a=0.1
@rxn A -> 0: p[deg_a] * u[A] | deg_a=0.05
@rxn A + B -> AB + B: p[kf_ab] * u[A] * u[B] | kf_ab=0.1
@rxn AB + B -> 0: p[deg_ab] * u[AB] | deg_ab=0.05

@obs A: u[A]
@obs B: u[B]
@obs AB: u[AB]

@SiM tspan:[0, 100]
@SiM condition control: init[A]=1; init[B]=1
```
@k-arakane k-arakane requested a review from himoto November 5, 2024 23:40
@himoto himoto merged commit 11a0ba0 into master Nov 6, 2024
7 checks passed
@himoto himoto deleted the dev branch November 6, 2024 11:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants