Sorting Example -- Q&A

[Simon Kahan]

Hi Kevin,

I am moving your questions below to this forum in case others have similar questions or other more experienced users have something to add.

Also, Ryan Tasseff has a tutorial draft posted that covers the sorting example and may be able to incorporate information as we hear about what aspects of the example need further explanation.

I have been modifying parameters within the files "model_define.h" and "sorting.xml" -- let me know if this isn't what I should be doing.

Those are the correct files to be modifying. 

In "model_define.h", here are some questions:

1. What's the difference between "domain x,y,z" and output parameter "size_x, size_y, size_z"? Does the latter just scale the simulation to fit the chosen value?

domain x,y,z are the dimensions of the entire simulation grid. You might not want to output data only for some particular rectilinear region, not the entire grid. The output region is defined by the rectilinear region having one corner at the point [start_x,start_y,start_z] and the other at [start_x+size_x,start_y+size_y,start_z+size_z]. In this example, the output is set to be the entire simulation domain: [0,0,0] to [64,64,64].

2. Do I need to worry about parallelism? (i.e. everything in the "optional" section including: system, super_partition, interval)

They are performance parameters. For now, you should be able to ignore them, though you'll get innocuous warning messages. When you're interested in running larger models, we can revisit this.

In "sorting.xml":

1. Is it possible to include more than 2 agents? I see parameters called "CELL_TYPE_A" and "CELL_TYPE_B". Can I introduce "CELL_TYPE_C" and add a third number to the parameters such as "A_CELL_RADIUS[NUM_CELL_TYPES] = {4.0, 4.0, 4.0}"?

Yes. You can look at the source code in model_routine_agent.cpp to see how these are used: there is a loop in ModelRoutine::addSpAgents that iterates i over NUM_CELL_TYPES creating a random number of cells of each type sticking each at a random location in the domain. It also sets for each cell i its type and radius via state.setType(i) and state.setRadius( A_CELL_RADIUS[i]).

Then, later on in ModelRoutine::adjustSpAgent it uses state.getType() to recover the type so that it can determine its radius as A_CELL_RADIUS[state.getType()].

You can mess around by setting the raidii of different cell types to different values in the sorting.xml file or even change the program so that the radius of a cell depends on its index i -- that would require modifications to multiple files, but it's a good way to get to learn how state is associated with each cell, which is something that will be needed to, for example, maintain a different state of contraction for each cell in the platelet model. Examples for maintaining state that is different depending on the type of the cell is illustrated in the yeast model.

2. What does IF_GRID_SPACING do?

Chapter 1 in the manual discusses grid spacing in more detail, but the short of it is that Biocellion imposes a cubic grid on the domain. Rather than having that grid define the units (ie, each cube is the unit cube), Biocellion offers the user the opportunity to define the length of the cube edge as IF_GRID_SPACING ("IF" is short for "interface"). Whatever it is, the cell centers can be anywhere -- they are not restricted to grid locations. Rather, the purpose of the gridding has to do with resolving cell-cell interactions. Biocellion's implicit assumption is that, whatever their shapes, two cells can be interacting physically only if their point locations are in the same or neighboring grid boxes. So, when cells are modeled as spheres (which so far has been true for all models), it's important that IF_GRID_SPACING be larger than the maximum cell diameter in the entire model to ensure no physical cell-cell interactions are missed. Making IF_GRID_SPACING much larger than the typical cell diameter could result in a lot of unnecessary computation: to see what cells a given cell might be touching, every cell whose center is in a box is compared to every other cell whose center is in that same box and in neighboring boxes; if the boxes are large, they may contain many cells, resulting in a lot of (quadratic in the number of cells in the box) comparisons.

3. What does ADHESION_S do?

See ModelRoutine::computeForceSpecialAgent in model_routine_mech_intrct.cpp. There ADHESION_S is used as the adhesive force constant in determining the (exponentially decaying with distance) force exerted on a cell drawing it towards a (non-touching) cell of the same type. Cells that are touching (or squished against each other) exert a repulsive spring force proportional to the deformation of their boundaries.

I understand that once you include this example in the documentation, it will be much more clear, but I hope this helps a little bit.

There is a tutorial page drafted by another user that describes the sorting example: biocellion.com/wiki_root/index.php/Tutorial

Thanks,

Sure!

[beu...@uw.edu]

Simon,

Thanks for uploading this to the support forum. I have another quick problem with the sorting example. In the output for this example, I get a radius (initially set to 4.0) and a color (defined by the cell type 0 or 1). I see that the color is output in "model_routine_output.cpp", but when is the radius sent to the output file? When I change the radius in "model_define.h" to 2.0 instead of 4.0, the output in Paraview still shows the radius as being 4.0. Additionally, giving each agent a different radius still yields the same radius 4.0 in Paraview,

Thanks for all the help,

Kevin

[Simon Kahan]

As the code is written, radius should be set to the values you've specified in model_define.h. I don't know why changing it in model_define.h isn't having an effect. I wonder if the executable is not being properly rebuilt? If you "make clean" & try again, does the 4.0 radius persist?

Both color and radius for each agent is printed to the paraview output file by routines internal to Biocellion.

The reason color is set in model_routine_output.cpp is that Biocellion doesn't know what colors you want to see.

ModelRoutine::updateSpAgentOutput is called for each agent every baseline timestep providing an opportunity to set the color based on the agent's state at that timestep.

Radius is initialized when the agent is created by ModelRoutine::addSpAgents. If you want to try changing the radius during simulation, you can do so in ModelRoutine::updateSpAgentState by for example:

if (state.getType() == 0) state.setRadius(2.0);

[Ryan Tasseff]

The compile issue that Simon mentions may be your problem.  Also note that you have to setup paraview to scale by the radius.  Here is a very old google doc, the section on view output should still be relevant:

https://docs.google.com/a/systemsbiology.org/document/d/1WU624YQaII7mKZ5f4nlIDRnonki2Vy0qoqWPa53DYXU/edit#heading=h.m7jqco7wkqlk

In paraview you can see that your output file has cell/point arrays, one of them is radius.  If you click on the ‘information’ tab you can see the values, at least the ranges.  This will tell you if its a settings issue in paraview visualization or if it’s an output file issue, i.e. radius is truly not changing.

Ryan Tasseff

Research Scientist

Institute for Systems Biology

--
You received this message because you are subscribed to the Google Groups "Biocellion Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to biocellion-supp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beu...@uw.edu]

Thanks Simon, your suggestions helped a lot. The problem was fixed when I ran "make clean" and "make" in the libmodel folder. This also worked when adding a third agent type.

Ryan, the document you sent was very helpful despite being "very old", I will keep it around as a guide when I am running biocellion/paraview!

Thanks again,

Kevin Beussman

To unsubscribe from this group and stop receiving emails from it, send an email to biocellion-support+unsub...@googlegroups.com.

[Shinwoo Chris Kang]

Hello, 

I'm having some difficulty understanding the addSpAgents function in "model_routine_agent.cpp"

In finding the number of agents to place in a Unit Box, the cell density "A_CELL_DENSITY_PER_UB" is set as .8 for both CELL_TYPE_A and CELL_TYPE_B. To find the number of cells, the following is used (where numUBs is the volume of the Unit Box):

S64 numCells = (S64)( (REAL)numUBs * A_CELL_DENSITY_PER_UB[i]);

1.) If we change the default cell density, wouldn't we get a non-integer value for numCells?

2.) Do all agents inside of a UnitBox have to be equal in dimension (size, radius, state)?

3.) When initially randomly placing two different types of cells in grid space, (for-looping through to find vIdx and vOffset), do we account for cells to not overlap?

Thank you.

[seunghwa.kang]

1.) If we change the default cell density, wouldn't we get a non-integer value for numCells?

=> Yes, we get a non-integer value, so the density value is an approximate value (it might be better if we use rounding than type conversion... but this is pretty minor if we are placing millions of cells).

2.) Do all agents inside of a UnitBox have to be equal in dimension (size, radius, state)?

=> No, it's just for simplicity, every agent can have different radius and state.

3.) When initially randomly placing two different types of cells in grid space, (for-looping through to find vIdx and vOffset), do we account for cells to not overlap?

=> There are overlaps, those overlaps are removed via shoving.

[seunghwa.kang]

Just want to add one more comment about overlap.

Cells often have sphere shape if they are in isolation, but when they are packed, they may look more rectangular.

We sometimes can better approximate packed cells using spheres by allowing some overlap, so here, spheres are not hard non-deformable objects (as they represent cells).

-seunghwa

[shin...@uw.edu]

Gotcha. Thank you!