Only saving cells data when there are cells

[vincent-noel]

Hi guys, I'm back and I found a bug !
When you try to run a simulation with 0 cells, we get a segmentation fault when writing the output files.
Here I'm just checking if there are cells before calling add_PhysiCell_cells_to_open_xml_pugi_v2. Maybe we should also print something ?

[heberlr]

Just a heads-up: this change will impact all applications that read PhysiCell cell simulation outputs. If all cells are eliminated, some applications—such as PhysiCell Studio, pcdataloader, and potentially others we may not be tracking—expect the following files to be present, even if they are empty:

• output*_cells.mat
• output*_attached_cells_graph.txt
• output*_attached_cell_neighbor_graph.txt
• output*_spring_cells_attached_cells_graph.txt

[MathCancer]

We probably ought ot write these to output empty files when there are no cells. And to do a check for cells / no cells when outputting. Probably stems from the way we traverse our list of all cells in these operations. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul Macklin, Ph.D. Associate Professor, Intelligent Systems Engineering Associate Dean for Undergraduate Education Luddy School of Informatics, Computing and Engineering Indiana University Founder and Lead of PhysiCell<http://physicell.mathcancer.org/> and MultiCellDS<http://multicellds.org/> email: ***@***.******@***.***> / ***@***.******@***.***> web: http://MathCancer.org<http://mathcancer.org/> Twitter: @MathCancer<http://www.twitter.com/MathCancer> From: Heber Lima da Rocha ***@***.***> Date: Wednesday, January 15, 2025 at 11:12 AM To: MathCancer/PhysiCell ***@***.***> Cc: paul.macklin mathcancer.org ***@***.***>, Review requested ***@***.***> Subject: Re: [MathCancer/PhysiCell] Only saving cells data when there are cells (PR #348) Just a heads-up: this change will impact all applications that read PhysiCell cell simulation outputs. If all cells are eliminated, some applications—such as PhysiCell Studio, pcdataloader, and potentially others we may not be tracking—expect the following files to be present, even if they are empty: · output*_cells.mat · output*_attached_cells_graph.txt · output*_attached_cell_neighbor_graph.txt · output*_spring_cells_attached_cells_graph.txt — Reply to this email directly, view it on GitHub<#348 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACVZW4DHM6L2HYGRTFE6CGL2K2CFHAVCNFSM6AAAAABU64GGEOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJTGM2DOMJXGI>. You are receiving this because your review was requested.Message ID: ***@***.***>

[vincent-noel]

I updated the PR, and now it is creating all the files, just empty.
The main problem was that (*all_cells)[0] was used to get the custom data of any cells. So I just added a check that there were cells every time this was used.

[drbergman]

Looks like a good solution to having no cells when writing output! Still produces all the files. I think I would prefer a solution that keeps the same label structure, but that seems like it would require storing the Death models and custom data structures outside of cell definitions. Ok, as I'm writing this I'm realizing that the Cell_Definition's still have phenotype and custom_data fields that should match with (*all_cells)[0]. Could we use those instead? Then we could avoid the structure of these files depending on the number of cells?

[drbergman]

Ok, as I'm writing this I'm realizing that the Cell_Definition's still have phenotype and custom_data fields that should match with (*all_cells)[0].

And match in terms of the number of/names/units/etc of the parameters being saved

[vincent-noel]

Hummm, you're right. We should use the cell definition there. I'll have a look...

[drbergman]

This looks good to me! cell_defaults is clearly the right struct for this.