Constant influx of immune cells into the computational domain.

[Эрвин Визард]

Dear Colleagues,

I'm looking for a way to construct the time uniform influx of immune cells in computational domain. The new cells should appear in random place of 2D area. But I've met some difficulties using default Morpheus functions.

1) AddCell - is it possible to use this functions several times during calculations? I mean adding new cells with some fixed probability.

2) ChangeCellType - it works well, but I can't understand: do cells that have changed type receive new characteristics other than the type?

Or should we specify all the required characteristics and parameters manually in ChangeCellType environment?

Thank you for the answer!

[Lutz Brusch]

Hi Эрвин,

what you describe should be doable with AddCell and please see the in-app docu on AddCell with some examples of spatially patterned cell placement. For instance (you may simply click this in the GUI and set the attributes, here just copy-pasted the corresponding lines from the resulting model.xml), influx [unit is mean number of added cells per 1 MCS] in the following can be 0.01 to add one cell every 100 MCS on average, or can be 100 to add 100 cells every 1 MCS. Added cells are initialized with the given values of their Properties and these may immediately be updated by the Trigger Rules.

<AddCell>

<Count> influx </Count>

<Distribution> 1 </Distribution>

<Triggers> <Rule symbol-ref="birth_time"> time </Rule> </Triggers>

</AddCell>

1) Yes, AddCell can be used several times. Your probability will determine the attribute Count, possibly factoring in the lattice size: <Count> p_per_area * size.x * size.y </Count>

2) No, those cell Properties that exist in both (old and new) CellTypes, will carry the current value from the old CellType over to the new CellType. Only Properties that are first used in the new CellType and didn't exist in the old CellType will be initialized by the user-given value. Moreover, optional Triggers (also see above) allow to update Properties at the moment when ChangeCellType is executed (e.g. in case you do not want the current value from the old CellType to be carried over to the new CellType).

Best,

Jörn and Lutz

[Эрвин Визард]

Dear Lutz,

Thank you very much for the clarification, I will test your recommendations today.

You are definitely the best multicellular modeling tool!

понедельник, 1 ноября 2021 г. в 15:59:29 UTC+3, Lutz Brusch:

[Эрвин Визард]

Dear Lutz,

I suppose I revealed source of AddCell incorrect work.

In the current model I try to add new cells in the already occupied computational domain (by other cells). In such case users should apply following settings: «overwrite = TRUE» allow new cells to be placed on top of existing ones.

But there is small problem: sometimes new immune cells can be placed upon other immune cells. In such situation they become like frozen and stop any movement.

понедельник, 1 ноября 2021 г. в 15:59:29 UTC+3, Lutz Brusch:

Hi Эрвин,

[Lutz Brusch]

Hi Эрвин,

thank you for your careful analysis. However, I did not see the freeze effect when I've played around with AddCell on top of other cells. The old cells were happily sharing the available space with the newly spawned and growing cells inside the old cells. This shape dynamics and motility of cause depend on the CPM parameters. Please check which contact energies are set in CPM > Interaction and which settings your VolumeConstraint and SurfaceConstraint have and if a higher temperature value works.

You may also attach a minimal model with the freeze effect here and we'll try to get the added cells moving.

Best,

Lutz

[Эрвин Визард]

Dear Lutz,
Thank you for your reply!

Please look at the attached simple program file and the recorded screenshot with the "frozen" cell on top of the computational area.
It looks like one red cell on top of another.

среда, 10 ноября 2021 г. в 20:37:17 UTC+3, Lutz Brusch:

[Lutz Brusch]

Hi Эрвин,

thank you for sharing your demo model.

You are right, adding one cell inside another cell generates a topological ring (for the older cell) that would need to break open at some place to let the newly added cell interact with the rest of the system. Since your cells have the ConnectivityConstraint switched on, the ring cell will stay a ring. The newly added cell meanwhile tends to satisfy its VolumeConstraint and thereby stretches the ring cell into a 1-node thin ring. This ring cell is everywhere forced to stay connected and hence cannot retract any voxel anywhere. But it also has a (twice as) large surface and the SurfaceConstraint straightens its boundaries and makes adding any new voxel (giving two further excess edges) unlikely. Hence the ring cell freezes and with it the added cell gets frozen.

The easy fix would be to delete the ConnectivityConstraint - that works. The SurfaceConstraint also controls a bit how many isolated voxels form.

A nicer fix would be to detect that a newly added cell is completely surrounded by another (ring) cell and then to delete the newly added cell again. Two NeighborhoodReporters can measure min and max cell.id of all neighbors. If these are equal, then the cell knows that it is trapped inside a single other cell. However, the neighborhood width of >1 (which is good for CPM dynamics) lets an interior cell that was added one voxel inside another cell still sense the other outer neighbor's cell.id "through" the one voxel of the ring cell and thereby survive. So, that fix works for many interiorly added cells but not for all (not nice). The latter can be fixed by neighborhood = 1 but that shows lattice artifacts in the CPM dynamics (not nice). But maybe this principle of detecting the ring neighbor can be exploited in other ways?

Best,

Lutz

[Эрвин Визард]

Hi, Lutz!
Thank you for your detailed answer! 

Now I can see the problem more clear than earlier. Very interesting numerical artefact :) 

Maybe I can cancel using ConnectivityConstraints. I decided that this is obligarory thing when we use ActModel Protrusions hamiltonian term. If not -- modeling will be easier.

--

Kind regards,

Ivan Azarov.

вторник, 23 ноября 2021 г. в 02:45:56 UTC+3, Lutz Brusch: