Replies: 1 comment 1 reply
-
|
I agree that this might be helpful as long as we clearly state that all conditions are collated together and applied as "single event". |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all,
TL;DR: #616
I know we had this discussion just recently, but nonetheless, I think it would be great to allow applying multiple simulation conditions with disjoint targets simultaneously.
We often have some factorial experiment design where different subjects / cell lines / ... are exposed to different drugs / environments / .... Depending on how many model entities are required to represent each factor, this can lead to pretty long and repetitive conditions tables.
I'll take the Froehlich_CellSystems2018 benchmark collection problem as a maybe not representative, but illustrative example:
There, the conditions table has roughly 6 million entries (some of which could be optimized out, and some will drop out due to the new sparse format, but let's ignore that for the sake of this example). This is because we have 9570 conditions describing different cell line × (drug × concentration) combinations (145 cell lines, 66 drug concentrations), each characterized by 638 changes to the model. I didn't count but it's something like the concentrations of 10 drugs and the rest, 628 are transcript levels.
So those 628 changes need to be repeated for each drug concentration applied to the same cell line. If we could factorize these changes and have reusable conditions for the cell lines, this would save a lot of space and make the whole thing much more editable. Specifying 145 (cell lines) * 628 (changes) + 10 (drugs) * 66 (drug concentrations) = 91,720 changes is still a lot, but it's <2% of what is currently done (145 (cell lines) * 66 (drug concentrations) * 638 (changes) = 6,105,660 changes).
Admittedly, for most applications, this won't be as drastic. Yet, I think it would make things more understandable, maintainable, and in line with the DRY principle; whereas the added PEtab complexity is negligible (#616).
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions