mastrof / microbeagents.jl Goto Github PK

It's probably better to move the analysis routines into a MicrobeAgents.Analysis submodule to keep the core cleaner.

Some classical turn angle distributions should be made available, e.g.:

• E. coli as measured by Berg & Brown, PNAS 1972 (Fig. 3)

A convenient implementation could be obtained by finding an appropriate analytical distribution in Distributions.jl, eventually also using a MixtureModel if the distribution has to be extended from [0,pi] to [-pi,pi]

AbstractGridSpace can be supported by extending the way rotations are evaluated.
Any continuous turn angle distribution can be approximated by weighted reorientations on a grid; will also differ depending on space metric.

Motion of microbes along spherical surfaces should be implemented along the lines of what I previously had in Bactos.jl (see mastrof/Bactos.jl#11 to implement the interactions and mastrof/Bactos.jl#50 for the neighborlist via CellListMap.jl).

This allows for different types of behavior along spherical walls, which is better to have than only the pathfinder approach. With this implementation, out-of-the-box microbes can:

• move smoothly along the surface until a tumble occurs (slide!)
• stick to the surface until a tumble occurs (stick!)

I will probably not implement the method to reorient as soon as they hit the surface (bounce!).
The interface to celllistmap will be provided to allow for easy addition of any custom methods by the user.

https://www.pnas.org/doi/full/10.1073/pnas.0807569105

Add examples for evaluation of drift velocity in a linear gradient, e.g. a comparison between the drift of chemotactic vs non-chemotactic strains.

The docstring does not explain if the vector is calculated from a to b or viceversa.
The new docstring should read

Evaluate the distance vector from a to b respecting the spatial properties of model.

Tumbles should be considered as a different step from runs.
This would allow the user to define e.g. a run_time and a tumble_time, and the microbe would be switching between the running state and the tumbling state with transition rates defined by these timescales.

More generally, this could go hand in hand with a full rewrite of the Motility implementation (#78).

The advantage is that setting a tumble_time=0 (or anything below the model.timestep) would reduce to the current implementation of instantaneous tumbles, but the new approach would allow the implementation of more refined models of chemotaxis and the reformulation of the run-tumble switching in terms of CCW bias, which is a more modern approach than just considering the tumbling rate.

A tumble detection algorithm could be included in the analysis toolkit (which then could also be used for #10 ).
The algorithm can simply evaluate the angle between the velocity vector at successive steps.
It would also require an optarg for a "threshold angle" which should be non-zero when rotational diffusion is present.

This function would simply move the agent randomly, with diffusivity defined by the Stokes-Einstein relationship
$$D = \dfrac{kT}{6\pi\eta r}$$
Properties of the medium (temperature and viscosity) can be added to the DEFAULT_ABM_PROPERTIES, defaulting to the values for water. Then brownian_motion!(microbe, model) would just use model.viscosity, model.temperature and microbe.radius to generate a random step.

To be done after JuliaDynamics/Agents.jl#843 is merged and released.

Whenever initialized in an environment with non-zero concentration, Celani shows an immediate response. This is because the steady state of the internal Markovian variables state[1], state[2] and state[3] depends on the absolute concentration.

I have to extend the add_agent! method to initialize the internal variables to their steady state as defined by the concentration_field of the model.

Add example where it is shown that the run lengths sampled during a random walk simulation match the expected exponential distribution. That is, for a walker with average turn rate $\omega$ the PDF to observe a run of duration $\Delta t$ is
$$P(\Delta t) = \omega \exp(-\omega\Delta t)$$

This should also go in the "validation" section of the docs

The following validation checks should be included under the "Validation" section in the docs:

• MSD for different angular distributions (Lovely & Dahlquist, J Theor Biol 1975; Taktikos et al, PLoS ONE 2013) (#48)
• Velocity autocorrelation functions for different motile patterns (Taktikos et al, PLoS ONE 2013) (#48)
• Drift velocity vs memory for BrownBerg model (Brown & Berg, PNAS 1974)
• Impulse and step response for Celani model (Segall et al, PNAS 1986)
• Step response for Xie model (Xie et al, Biophys J 2015)

Makes no sense to hide the space interface behind the ABM constructor.

Required for #30

run!, add_agent!, UnremovableABM, StandardABM

Just learned that StatsBase has a family of functions autocor, autocov, crosscov, crosscor, pacf.
I have to check that they do exactly what I think they do, but with high probability these will be more complete and most likely more performant than my version of acf.

Fieldnames of distinct microbe types should be standardized as much as possible, despite them having possibly slightly different physical meanings, e.g.:

• BrownBerg and Brumley have a motor_gain field, while in Celani the equivalent field is just called gain
• BrownBerg and Brumley have an adaptation_time field, while the Celani equivalent is called memory
• the state field in Celani is a vector, whereas it is a scalar in BrownBerg, Brumley and Xie; it's maybe more convenient to keep it a scalar and rename the internal markovian variables to something different

By default MicrobeAgents now works with UnremovableABM; there should also be:

• a constructor for StandardABM
• an overload of run! for StandardABM

@JuliaRegistrator register()

This would be an advanced example that showcases integration with DifferentialEquations

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Should be relatively easy to implement a steep soft-core repulsion (e.g. $r^{-12}$) using the CellListMap.PeriodicSystem interface which is already implemented. At least as long as the microbes can be considered spherical.

I will have to think, however, how to combine the current "kinetic" approach with this dynamic component.
Also in view of further extensions, I should probably consider whether it's wiser to translate everything into dynamic terms.

Will then need to look into how this can be extended to other shapes but it's something for the future.

The arrow operator is very confusing. Better to just use ChainedFunction

Since the velocity of microbes is split into a velocity versor microbe.vel and a magnitude microbe.speed it might be good to introduce a convenience function velocity(microbe::AbstractMicrobe) = microbe.vel .* microbe.speed. Will make code clearer.

• single-step run for each microbe type
• large-scale run for each microbe type

https://github.com/mastrof/MicrobeAgents.jl/blob/e6da8495bab2978468bb7bf3a485a98e833581fa/src/chemotaxis/brumley.jl#LL71C5-L71C5

The conversion factor for the molecular counting noise should be defined as a global constant accessible to all the chemotaxis models (Brumley, Celani, Xie), not hard-coded into them.

The current implementation of motility types is cumbersome, not easily extendable and even incomplete.

Ideally, it would be nice to implement a single Motility{N} type with N being the number of motile states, with the switches between such states defined by a transition matrix.

The states would need to contain all the information required for the microbe stepping and the transition to other states (e.g. speed of motion, reorientation distributions, average lifetime of the state...).

Ideally, this could be something as simple as

mutable struct Motility{N}
    current_state::Int
    motile_states::SVector{N,MotileState}
    transition_matrix::SMatrix{N,N,Float64}
end

but I'm not yet sure if having a unique MotileState type to represent all sorts of behaviors (runs, tumbles, stops....) makes sense

Instead of defining a different AbstractMicrobe type for each model of chemotaxis, there could be a single Microbe type with a parameter C<:Chemotaxis and a field chemotaxis::C field which would wrap the entire chemotactic system of the microbe.

Rather than enforcing a structure to follow for new microbe types, it would then only be required for the Chemotaxis struct to follow some prescribed rules.

Such a refactoring might also make it easier to implement further behavioral traits down the road (e.g. chemokinesis, interactions...) and separate the integration of "internal states" from the motion itself.

Types, however, are an issue.
Fast execution requires the struct types to be concretely typed (which is also a problem for AbstractMotility right now), which means that each behavioral trait would need its own parameter if a generic interface is to be provided.
This will eventually lead to breaking changes whenever new traits with their own type have to be added, and will require Microbe to store a load of type parameters most of which are not going to be used simultaneously in typical scenarios.

AbstractMicrobe types should be given a type parameter to represent motility, in order to avoid the inefficient motility::AbstractMotility in the struct definition.