getter functions for lists of dying and dividing cells

[josephabrams]

I realize there are other ways to figure this out, but it might be very convenient to access the list of cells that are going to divide or die in C++ code. These are (I think) relatively safe getters that pass back a reference to the cell_containers private members: cells_ready_to_divide and cells_ready_to_die, I realize these getters have some redundancy, but I wasn't sure which version would be the preferred. My main motivation is that these functions allow me to easily check the safety of cell addons that aren't inheriting the Cell class. It also makes it easier to code custom functions that track generations or customize post-death cell actions outside of using a "phenotype" approach.

[MathCancer]

Hi, this is really cool!

Could you provide some brief documentation on when it's best (and safe) to use this function, and the use cases?

[josephabrams]

Both versions of the function, read what cells have been flagged for division (or death) in a cell container. These variables are private, but they can be used to trigger/track division or death-based events. They can also be used for lineage tracking. To safely trigger such an event you would want to be sure that you store the vector of cells that are flagged for death or flagged for division after all flags have been updated. Then after division or death occurs, you have a list of what cells have died or been newly created on this time step. My use case is: when I have custom code that will break if divisions or death occurs, I can check for these flags as a safety feature, or more easily change the custom code to adapt to changes in the number of active/valid cells.

[drbergman]

Is your custom code in custom_modules? Or is it custom additions to update_all_cells? The main concern about adding these functions in to core PhysiCell is where in the code others would make use of them. These lists quickly become stale/cleared:

1. advance_bundled_phenotype_functions parallel iterates over all cells ... a. Some are flagged for death b. all cells advance cycle (and thus some are flagged for division)
2. the division list is processed serially
3. the death list is processed serially
4. the lists are cleared

You would (likely) have to make use of these lists after 1 (since that's done in parallel) and then before 4. I believe the only functions that we expect a user to be changing in that window would be cycle entry and exit functions. If you could provide some insight on where in this flow your functions are used, that would help in assessing if they make sense to include in core PhysiCell.

[josephabrams]

I thought I would be able to put it into a custom_phenotype function, but it seems I made a mistake in the order.

[drbergman]

Ah I see. Yeah, the phenotype functions are run in parallel and prior to what I labeled above as 'a' within advance_bundled_phenotype_functions. If I'm reading this correctly, you have not yet tested this in your own custom phenotype functions/in your own project? If not, it is encouraged to experiment in your own project by editing the core features of PhysiCell. It might be difficult to do it right, but you can definitely make changes to your own stuff. If after running it with your own work for a bit, you think others could benefit, that would be the time to open a PR. If you can't figure out how to get some feature working in the core code, that would be a time to open an Issue or bring it up in Slack. Slack is probably better for that.

[drbergman]

Hi @josephabrams, just wanted to follow up and see what your thoughts are about this PR. Do you want to leave it open and have it merged (perhaps after new commits)? Or should we go ahead and close it?

[josephabrams]

oh! yes, go ahead, I appologize for not responding sooner, I thought it was already closed.

[drbergman]

@MathCancer this can be closed

[MathCancer]

closed by agreement, but thank you!