SMC translocator: do we need a more general code?

[mimakaev]

Problem

After discussing with Hugo, we were thinking that current SMCTranslocator is outdated.

First, it is written in Cython, which is not necessary unless you want to create SMC-only contact maps. And nobody does that.

Second, it only accepts a limited set of rules, and modifying them is difficult

What do we do?

Perhaps, we need to think about / design a more generalized and flexible SMC translocator, written in pure python.

Ideally, it should have a set of features. From the top of my head: making lifetime dependent on what's going on (collision, pausing, status of two cohesins, etc.). It should support one-sided extrusion, as well as maybe diffusive extrusion (?).

[ebanigan]

There are basically 3 things a LEF can do (if we ignore exotic things like long-distance capture): LEFs can actively translocate, diffuse, or remain in place. I suggest assigning each subunit in a LEF to have one of these modes. This already permits, 1-sided, 2-sided, slip-link, and "semi-diffusive" extrusion. As suggested above, the rates of these steps could be controlled by context, e.g., diffusive step rates that depend on loop size, switching that exchanges active and stationary subunits, etc.

Additionally, it might be nice to facilitate use of multiple different kinds of LEFs together in one simulation (e.g., a mix of 1- and 2-sided, or using two different processivities, etc.).

[golobor]

One design feature that I'd strongly recommend is to separate the code that simulates 1D trajectories of SMCs from the OpenMM-related code. For example, the former could return a 2N x T array of N loop positions at T timepoints, which the latter would use to make an efficient polymer simulation. This way it'd be much easier to experiment with different codes for lattice simulations, e.g. step-wise Python/Cython or gillespie-type ones.

…

On Wed, Sep 4, 2019, 18:39 Maksim Imakaev ***@***.***> wrote: *Problem* After discussing with Hugo, we were thinking that current SMCTranslocator is outdated. First, it is written in Cython, which is not necessary unless you want to create SMC-only contact maps. And nobody does that. Second, it only accepts a limited set of rules, and modifying them is difficult *What do we do?* Perhaps, we need to think about / design a more generalized and flexible SMC translocator, written in pure python. Ideally, it should have a set of features. From the top of my head: making lifetime dependent on what's going on (collision, pausing, status of two cohesins, etc.). It should support one-sided extrusion, as well as maybe diffusive extrusion (?). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG64CVVQ34N5OROB4BUGPTQH7QCZANCNFSM4ITUDK6A> .

[mimakaev]

I fully agree with that: we need to separate SMCtranslocator and polymer simulations!

Irrespective of that, the question of which SMC translocator code to use remains open. Any comments on that?

[mimakaev]

Working draft of a proposal to make new loop extrusion code

Current implementation
https://gist.github.com/mimakaev/021cbc4cc58a603a13ea8e2e80a582ba

Suggested scenarios

• PolII simulations with pushing cohesins
• Lifetime/etc dependent on CTCF/etc
• CTCF capture/release
• Z-loops of certain types
• one-sided and two-sided extrusion

Ignored scenarios

• Cross-sister cohesin; loops connecting multiple chains
• merging of objects "on the go"
• replication forks and multi-strand extrusion

Do we need?

• A complicated pushing logic? (e.g. PolII cannot push CTCF cohesins)
• Complex z-loops

Requirements for the extrusion code

Movement

• Each object can have 1 or 2 (or more in principle) legs. Legs move independently.
• Each leg has drift speed and diffusion coefficient

• Diffusion and drift (have helper class)
• One-sided extrusion
• Walking though others Maybe
• Co-dependent extrusion of two legs???
• Walking like PolII
• Hooks to modify state of extruders at encounters

States

• States encoded by attributes
  • Functions to put/release from states are called at each step, they check conditions
  • Functions to provide lifetime based on states

Loading

• Loading probability for each type of cohesin
• Most likely: loading upon unloading
  • Add .reset() method that reverts an object to the ground state, but retains attributes such as speed?