duplication of complexes

[nilsbecker]

I am trying to implement a rule that duplicates a complex, including its internal state configuration.

Concretely, let's say a monomer has interface E(i1{a b c}, i2{d e}, x[y.E], y[x.E]). Each monomer thus has 6 internal states, and a trimer has already 6^3. It's infeasible to write exact duplication of trimers explicitly with definite values of the internal states. I have not found a way to describe this in Kappa. Is there one?

[glucksfall]

Hello,

Rules should be explicit. If you want to duplicate A you need to write something like A -> A + A. You could try using PySB, where you can define a python variable as the complex, and use that variable to write a simple rule. Then when exporting to kappa, PySB will translate the variable to the full agent definition. I used it before to duplicate a long chain of agents.

Another thing to keep in mind is that if you want to duplicate an agent, polymerize an agent or make a ring of agents. Those three reactions have associated three different rules.

Also, you could ask your doubts through the Gitter channel https://gitter.im/Kappa-Dev/KaSim

Best regards, PS1: I'm not a developer of KaSim... I don't know every trick the language allows to do. PS2: Neither a PySB developer... just using both tools (and dev my owns)

[nilsbecker]

@glucksfall thanks. i will investigate the PySB route. however, i am doubtful that it will work; in my actual use case, the complexes that need to be duplicated are 9-mers, which have around 1E6 internal states. even if generated programmatically, the rule set would become too big.

to me this seems a use case for which kappa is not flexible enough? or maybe there is another way to represent the internal states, e.g. fake additional agents that implement the internal states? but then i think i would still need a way to express something like E(arbitrary fake ligand bound (one of 6))-> 2 x E(the same ligand bound)

[nilsbecker]

one possible way to represent this situation would be to allow state-valued variables on the LHS and RHS of a rule , e.g. E(i1{_X})-> E(i1{X}), E(i1{X}) where _X is a variable that captures the state on the left and X is the same value on the right. obviously i have no clue if something like that is a simple extension of the simulation loop or if it is incompatible with the architecture of kappa.

[vd1]

Hello

You could try to do it the way nature does it.

• add a rep site to E
• make a new agent REP with a co-rep site and a train site
• add a rep/co-rep landing rule where by REP lands on the site rep of E provided its x is free - the x-most monomer
• add (rougly 6x2) sliding rules for REP to duplicate one E at a time attaching them to the growing train
• add a rule to terminate duplication by detaching REP and its trailing copy when REP reaches the y-most monomer

Cheers Vincent

[feret]

Very nice indeed!!!

Le 8 mai 2019 à 04:54, Vincent Danos notifications@github.com a écrit :

Hello

You could try to do it the way nature does it.

• add a rep site to E
• make a new agent REP with a co-rep site and a train site
• add a rep/co-rep landing rule where by REP lands on the site rep of E provided its x is free - the x-most monomer
• add (rougly 6x2) sliding rules for REP to duplicate one E at a time attaching them to the growing train
• add a rule to terminate duplication by detaching REP and its trailing copy when REP reaches the y-most monomer

Cheers Vincent — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[nilsbecker]

@vd1 thanks, that does sound like a possible answer!

i don't want or need the replication intermediates, but guess i could just not observe them. i'll give it a go i think.

one thing to beware of is that the availability of polymerases (REP) should not become limiting as the population grows. to avoid that, it might be possible to make the polymerase fully implicit, building the replication fork into E as another residue. to be seen.

as a more general comment, i think that supporting rules with variables would increase the expressiveness of kappa a lot, but may come at a price in terms of feasibility of static analysis and potentially, speed (although i don't see why it would make the core simulation loop slow necessarily)

[nilsbecker]

it's funny how one runs into questions about the mechanism of DNA replication when trying to set it up this way!

the rules for binding of the polymerase and advancement of the replication fork are local, which is why they may solve the combinatorial problem. however, then one also wants to prevent multiple replication forks progressing on the same complex at the same time, to keep things clean and easy to reason about. this is nonlocal, since it involves knowing if a fork exists somewhere down the polymer. testing all possible fork locations again makes the combinations blow up.

in the limit of fast fork progression and slow replication initiation it's perhaps ok. alternatively, one can introduce something like licensing for replication, where the origin of replication (the x-most site) is capped and inert unless it becomes licensed (bound by an activating agent); licensing would need to test for absence of a fork along the polymer; this corresponds to L rules, where L is the max. length of a polymer. this seems a bit cumbersome but feasible since it does not need to respect all the label configurations. huh.

[vd1]

indeed licensing for replication is also a trick that nature plays eg with polyadenylation and capping we played a lot of this polymerisation games when compiling synthetic circuits in kappa https://link.springer.com/protocol/10.1007/978-1-4939-1878-2_6

On Wed, 8 May 2019 at 14:11, nilsbecker notifications@github.com wrote:

it's funny how one runs into questions about the mechanism of DNA replication when trying to set it up this way!

the rules for binding of the polymerase and advancement of the replication fork are local, which is why they may solve the combinatorial problem. however, then one also wants to prevent multiple replication forks progressing on the same complex at the same time, to keep things clean and easy to reason about. this is nonlocal, since it involves knowing if a fork exists somewhere down the polymer. testing all possible fork locations again makes the combinations blow up.

in the limit of fast fork progression and slow replication initiation it's perhaps ok. alternatively, one can introduce something like licensing for replication, where the origin of replication (the x-most site) is capped and inert unless it becomes licensed (bound by an activating agent); licensing would need to test for absence of a fork along the polymer; this corresponds to L rules, where L is the max. length of a polymer. this seems a bit cumbersome but feasible since it does not need to respect all the label configurations. huh.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Kappa-Dev/KaSim/issues/577#issuecomment-490461258, or mute the thread https://github.com/notifications/unsubscribe-auth/AADQELWFS55OPABBVVM2N2LPUK7N5ANCNFSM4HLKHAUQ .

[hmedina]

You can also play around with the rates. Make the extension step have an infinite rate, and the ejection one too. Given a finite attachment rate, you'll always finish a replication process before attaching a new one.

I use a variant of this for degrading arbitrarily long polymers, using a PacMan agent :)

On Wed, May 8, 2019, 09:05 Vincent Danos notifications@github.com wrote:

indeed licensing for replication is also a trick that nature plays eg with polyadenylation and capping we played a lot of this polymerisation games when compiling synthetic circuits in kappa https://link.springer.com/protocol/10.1007/978-1-4939-1878-2_6

On Wed, 8 May 2019 at 14:11, nilsbecker notifications@github.com wrote:

it's funny how one runs into questions about the mechanism of DNA replication when trying to set it up this way!

the rules for binding of the polymerase and advancement of the replication fork are local, which is why they may solve the combinatorial problem. however, then one also wants to prevent multiple replication forks progressing on the same complex at the same time, to keep things clean and easy to reason about. this is nonlocal, since it involves knowing if a fork exists somewhere down the polymer. testing all possible fork locations again makes the combinations blow up.

in the limit of fast fork progression and slow replication initiation it's perhaps ok. alternatively, one can introduce something like licensing for replication, where the origin of replication (the x-most site) is capped and inert unless it becomes licensed (bound by an activating agent); licensing would need to test for absence of a fork along the polymer; this corresponds to L rules, where L is the max. length of a polymer. this seems a bit cumbersome but feasible since it does not need to respect all the label configurations. huh.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Kappa-Dev/KaSim/issues/577#issuecomment-490461258, or mute the thread < https://github.com/notifications/unsubscribe-auth/AADQELWFS55OPABBVVM2N2LPUK7N5ANCNFSM4HLKHAUQ

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Kappa-Dev/KaSim/issues/577#issuecomment-490477636, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMD2SLITL5A5QIKMSIO7ULPULFYTANCNFSM4HLKHAUQ .

[glucksfall]

One of my first models was to reproduce replication of a bacterial plasmid (https://www.sciencedirect.com/science/article/pii/S0006291X17323173). In the model (as well in nature), replication cannot restart at the origin until the deletion of the RNA primer. For simplicity, the rule that duplicates the plasmid also deletes the RNA at the origin.

What I didn't follow was "one also wants to prevent multiple replication forks progressing on the same complex at the same time". Do you mean prevent reinitiation at the origin of replication? Because there are multiple forks in eukaryotes (reply to " it involves knowing if a fork exists somewhere down the polymer").

[vd1]

I think he thought of another REP landing on the growing copy rather - which is not possible with existing template based polymerases. But maybe possible with synthetic ones.

On Wed 8 May 2019 at 17:46, Rodrigo Santibáñez notifications@github.com wrote:

One of my first models was to reproduce replication of a bacterial plasmid (https://www.sciencedirect.com/science/article/pii/S0006291X17323173). In the model (as well in nature), replication cannot restart at the origin until the deletion of the RNA primer. For simplicity, the rule that duplicates the plasmid also deletes the RNA at the origin.

What I didn't follow was "one also wants to prevent multiple replication forks progressing on the same complex at the same time". Do you mean prevent reinitiation at the origin of replication? Because there are multiple forks in eukaryotes (reply to " it involves knowing if a fork exists somewhere down the polymer").

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/Kappa-Dev/KaSim/issues/577#issuecomment-490540522, or mute the thread https://github.com/notifications/unsubscribe-auth/AADQELQFLFYPTTQU6R2BKR3PULYUZANCNFSM4HLKHAUQ .

[nilsbecker]

@hmedina ah good to know that infinite rates actually work and don't lead to overflow errors. @glucksfall @vd1 yes, i wanted to avoid re-initiation of replication at the start site while a previous round of replication is not finished. i know this exists in bacterial replication, but for my present use case i don't want it. it seems that infinite replication progress rates can solve that problem.

[vd1]

I think I misunderstood then - i thought you wanted to prevent the duplication of the nascent chain

On Thu, 9 May 2019 at 09:35, nilsbecker notifications@github.com wrote:

@hmedina https://github.com/hmedina ah good to know that infinite rates do actually work and don't lead to overflow errors. @glucksfall https://github.com/glucksfall @vd1 https://github.com/vd1 yes, i wanted to avoid re-initiation of replication at the start site while a previous round of replication is not finished. i know this does exist in bacterial replication, but for my present use case i don't want it. it seems that infinite replication progress rates can solve that problem.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Kappa-Dev/KaSim/issues/577#issuecomment-490787914, or mute the thread https://github.com/notifications/unsubscribe-auth/AADQELTJLMSNNJ6B5IEBPBDPUPH4VANCNFSM4HLKHAUQ .

[nilsbecker]

ah yes, i also don't want to allow duplication of the nascent chain. that seems to be a similar problem since the nascent end can in principle also accept a new REP. with infinite rates this should also disappear i think

[vd1]

incidentally, infinite rates are creating a special compartment of "infinite" events which are prioritised - there is no guarantee on the order in which the infinite events are selected by the simulator, so it can become difficult to understand the implications (if the infinite event structure ahead has conflicts).

On Thu, 9 May 2019 at 09:45, nilsbecker notifications@github.com wrote:

ah yes, i also don't want to allow duplication of the nascent chain. that seems to be a similar problem since the nascent end can in principle also accept a new REP. with infinite rates this should also disappear i think

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Kappa-Dev/KaSim/issues/577#issuecomment-490790788, or mute the thread https://github.com/notifications/unsubscribe-auth/AADQELVOHM2FFJE3MGHQMITPUPJCPANCNFSM4HLKHAUQ .