I'd like for us to begin using CI for PhysiCell. This is an important step in maintaining quality software. There are many CI services to choose from (that play well with github). I propose we just start with TravisCI.

1. an Admin (Paul) needs to sign up at TravisCI (using your github sign-in) then tell it to connect to this repo.
2. we need to add a .travis.yml file to our repo (root) that provides instructions on what we want done for CI.

I've made a google doc that will hopefully help walk through these initial steps. We'll iterate & improve as we go.

(reported by a user)
The total cells volume that is stored in the matlab files in Output00000000.xml is shown as 1. This appears to be correct for all subsequent steps.

e.g. when running the base 2D model (same is true in 3D)

MATLAB code
MCDS = read_MultiCellDS_xml( 'output00000000.xml');
MCDS.discrete_cells.phenotype.geometrical_properties.volumes
MCDS.discrete_cells.phenotype.geometrical_properties.volumes.total_volume

MCDS = read_MultiCellDS_xml( 'output00000001.xml');
MCDS.discrete_cells.phenotype.geometrical_properties.volumes
MCDS.discrete_cells.phenotype.geometrical_properties.volumes.total_volume

gives

output00000000_cells_physicell.mat
Elapsed time is 0.347925 seconds.

Summary for file ./output00000000.xml:
Voxels: 2500
Substrates: 1
oxygen (mmHg)
Cells: 4
ans = struct with fields:
total_volume: [4×1 double]
nuclear: [540 540 540 540]
cytoplasmic: [1954 1954 1954 1954]
fluid_fraction: [0.7500 0.7500 0.7500 0.7500]
calcified_fraction: [0 0 0 0]
ans = 4×1
1
1
1
1
output00000001_cells_physicell.mat
Elapsed time is 0.325475 seconds.

Summary for file ./output00000001.xml:
Voxels: 2500
Substrates: 1
oxygen (mmHg)
Cells: 4
ans = struct with fields:
total_volume: [4×1 double]
nuclear: [540 844.3312 791.9927 540]
cytoplasmic: [1954 2.9191e+03 2.7346e+03 1954]
fluid_fraction: [0.7500 0.7500 0.7500 0.7500]
calcified_fraction: [0 0 0 0]
ans = 4×1
103 ×
2.4940
3.7634
3.5266
2.4940

where ans=total volume

most of the Error write to std::cout only and give no error code back.
usually PhysiCell then just quits.

a Errors should be written to std::cerr and a proper Error should be raised (giving -1 back),
so that e.g. job scheduler like slurm can detect that there was an error and the code not successfully ended.

replacing:
std::cout << "Error: message goes here!" << std::endl;
with:
std::cerr << "Error : message goes here!" << std::endl; exit(-1);
should do the trick.

most easy way to find all error messages is: grep -r Error or grep -ir Error

happy to fix this and do a pull request.
please let me know. Elmar

I'm getting an error when running "make data-cleanup". It comes from the line
rm -f ./output/*
It has to do with there being too many objects for rm to remove. For instance, biorobots-sample produces ~7.2k files in the output directory. (https://support.qualityunit.com/257075-rm-and-the-Argument-list-too-long-error-message)

The error I get is:
/bin/sh: /bin/rm: Argument list too long
make: *** [data-cleanup] Error 126

My workaround was replacing the above makefile command with
rm -r ./output/
mkdir ./output/

I'm running bash on MacOS Catalina 10.15.2.

Could we possibly not have make reset do a rm *.cpp? Just wondering what the danger is in having them? I've been bitten by this on multiple occasions. I make my own personal backup copy of a main.cpp, due to testing edits I've made, then it's removed on a make reset.

The function void normalize (std::vector* v) on lines 206 - 217 of BioFVM_vector.cpp, does not catch when a very very small (a vector with components within a small epsilon of zero but magnitude greater than zero) vector is sent to the function. As discussed offline, we propose adding a tolerance to the normalization routine such that the normalize function returns the zero vector when the magnitude of vector v is less than some small epsilon.

Here is some propose example code to put around line 213:

if (norm < 1e-16)
{
for( unsigned int i=0; i < v->size(); i++ )
{ (*v)[i] = 0 ; }
}

There are many functions provided in BioFVM_microenvironment.cpp designed for implementing Dirichlet conditions (DCs). However, there is inconsistency across what they do and the naming conventions shed little light on what their under-the-hood differences are. Case in point (and maybe even the whole enchilada):

• add_dirichlet_node does not update dirichlet_activation_vectors and thus cannot be used to start applying a DC
• update_dirichlet_node( int voxel_index , int substrate_index , double new_value ) does do this but...
• update_dirichlet_node( int voxel_index , std::vector<double>& new_value ) does not

Just a short note that the graph filenames are messed up.
-rw-rw-r-- 1 abc def 121681 Feb 1 17:34 output00000000_attached_cells_graph.txt_cell_attached_graph.txt
-rw-rw-r-- 1 abc def 121681 Feb 1 17:34 output00000000_cell_neighbor_graph.txt_cell_neighbor_graph.txt

physicell will run into an error if there not already an output folder exist (with whatever the exact name specified under in the settings.xml).
it would be nice if the physicell in the beginning automatically checks if such a folder exists and, if not, generate it.

Since many of us work with C++ to writhe physicell models and use Python to analyze the output, I wonder if replacing all tabs with 4 spaces in the PhysiCell codebase (except Malkefiles) would make daily work for all of easier.

For me, it definitely would.
I happily make the changes if we can agree on that.

• sample_projects/Makefile-default
• sample_projects_intracellular/ode/test_sbml1/Makefile
• do a global search for others

this is minor, but please put this into .gitignore.

**/.DS_Store
**/._.DS_Store

and delete:

• documentation/.DS_Store
• unit_tests/.DS_Store

thank you, Elmar

There's a BioFVM_vector.o file included in the 1.10.4 release which apparently causes problems when compiling on Windows with MinGW g++ (HT to Michael Getz). We'll want to make sure there are no extraneous .o files in future releases.

I have set up physicell (by the way the installation manual is very well written and easy to follow) and trid to run the first sample project and got an error message:
BioFVM_vector.o: file not recognized: file format not recognized
collect2.exe: error: ld returned 1 exit status
make: *** [all] Error 1

In http://www.mathcancer.org/blog/saving-multicellds-data-from-biofvm/ I see

Future releases of BioFVM will support reading MultiCellDS snapshots (for model initialization).

I'd like to be able to restart a simulation from where it stopped. Is this now possible?

I found this: https://github.com/idontgetoutmuch/PhysiCell/blob/master/BioFVM/BioFVM_MultiCellDS.h#L191-L200

which suggests that I will have to implement read_BioFVM_to_MultiCellDS_xml_pugi myself?

Motivating question

If cd8 attacks tumor with attack_rate("tumor") = 1.0 and the damage_rate for cd8 is 1.0, how much damage do we expect a tumor agent to accumulate per minute as it continuously as a neighboring cd8 cell?

Expected answer

If the attack rate is in attack/minute (against a given neighbor) and the damage rate is in damage/attack, the answer is obvious: we expect 1.0 damage/minute. This answer is sensible, predictable, and knowable from only the two numbers above.

What actually happens

The cd8 attacks in a mechanics_dt (default = 0.1 min) with probability probability = attack_rate("tumor") * mechanics_dt = 1.0 * 0.1 = 0.1 ¹². This has the desirable effect of initiating an "attack" once per minute, exactly as the attack rate suggests.

Then the unexpected happens. Upon successful attack by the cd8, the tumor agent accumulates damage_rate * mechanics_dt = 1.0 * 0.1 = 0.1 damage³. The net effect is that the tumor agent is expected to accumulate 0.1 damage per minute from this interaction.

Analyzing this more closely, we see the expected damage accumulation in a minute for the tumor agent is

$$ \begin{align*} \Delta\text{damage} & = \mathbb{E}[\text{num attacks}] \times \text{damage}/\text{attack} \\ & = \text{attack probability per dt} * \text{num steps} \times (\text{damage rate} * dt) \\ & = (\text{attack rate} * dt) * (1.0 \text{ min} / dt) \times (\text{damage rate} * dt) \\ & = \text{attack rate} * \text{damage rate} * dt \end{align*} $$

Notice that $dt$, the mechanics_dt, factors in to how much damage is accumulated by the tumor agent. In other words, knowing only the attack rate and damage rate is insufficient to predict the damage accumulation rate.

Proposed change

Redefine the damage_rate to be damage/attack rather than damage/minute. That is, the attack_rate will be the rate at which the attacking cell type, cd8 above, attacks a given neighbor (possibly modulated by immunogenicity¹); and the damage_rate is the amount of damage dealt to the attacked cell type, tumor above, given that the attacker attacked.

To see this, make the template project and place the attached xml into the config folder. Run the simulation. Output should roughly match the attached video.

Expected behavior: All cells immediately begin apoptosis (apoptosis death rate is set to 100). random_duration cells have a variable time until they are removed. fixed_duration cells all disappear at 2 hours. Both cells have the phase duration set to 2 hours.

Observed behavior: All cells are removed at 2 hours, including the random_duration cells.

Possible cause: PhysiCell_cell.cpp reads in the cell definitions, overwriting the fixed duration field of the apoptosis CycleModel with each one. Unclear how only this field seems to be overwritten and not the apoptosis rates.

Archive.zip

A reminder that we still have some hierarchical config files, rather than the "flattened" syntax that the Studio requires. At least these, it seems:

~/dev/PhysiCell_v1.12.0/sample_projects$ grep parent */config/*.xml
cancer_immune/config/PhysiCell_settings.xml:		<cell_definition name="immune cell" ID="1" parent_type="cancer cell">
celltypes3/config/PhysiCell_settings.xml:		<cell_definition name="A" ID="1" parent_type="default">
celltypes3/config/PhysiCell_settings.xml:		<cell_definition name="B" ID="2" parent_type="default">
celltypes3/config/PhysiCell_settings.xml:		<cell_definition name="C" ID="3" parent_type="default">
pred_prey_farmer/config/PhysiCell_settings.xml:		<cell_definition name="prey" ID="1" parent_type="farmer">
pred_prey_farmer/config/PhysiCell_settings.xml:		<cell_definition name="predator" ID="2" parent_type="farmer">
virus_macrophage/config/PhysiCell_settings.xml:		<cell_definition name="macrophage" parent_type="epithelial cell" ID="1">

The Studio's /config dir has flattened versions, but we should verify they reproduce the same results.

In PhysiCell_standard_models.cpp's standard_volume_update_function I believe the calcified fraction update is not correct. All dynamic volumes except it are updated following a forward Euler method, e.g.

phenotype.volume.fluid += dt * phenotype.volume.fluid_change_rate * ( phenotype.volume.target_fluid_fraction * phenotype.volume.total - phenotype.volume.fluid );

The calcified fraction update does not have the + in the +=. It reads

phenotype.volume.calcified_fraction = dt * phenotype.volume.calcification_rate * (1- phenotype.volume.calcified_fraction);

This means the cell will never calcify completely, it's calcified fraction will fluctuate around dt * phenotype.volume.calcification_rate

Hi,

I am developing some simulations building upon PhysiCell.

I might be wrong with the import procedure of the sources, however, including PhysiCell header files forces me to include BioFVM namespace even when PhysiCell's is not included.
It is in fact the case from three .h files, e.g. PhysiCell_cell.h that is usually imported via `#include "./core/PhysiCell.h".

In my personal fork, I have solved this issue by moving such usings inside PhysiCell's namespace (actually two lines down in a bunch of files).

I think that could also be your initial idea since in the Documentation you suggest here to include PhysiCell's and BioFVM's namespaces.

Best,
Elia

In each Makefiel is the following command

PROJ := my_project

save: 
        echo "Saving project as $(PROJ) ... "
        mkdir -p ./user_projects
        mkdir -p ./user_projects/$(PROJ)
        mkdir -p ./user_projects/$(PROJ)/custom_modules
        mkdir -p ./user_projects/$(PROJ)/config 
        cp main.cpp ./user_projects/$(PROJ)
        cp Makefile ./user_projects/$(PROJ)
        cp VERSION.txt ./user_projects/$(PROJ)
        cp ./config/* ./user_projects/$(PROJ)/config
        cp ./custom_modules/* ./user_projects/$(PROJ)/custom_modules

if the following sed line would be added, then the PROJ := my_project would automatically be set to what ever name was choosen for saving.

e.g.:

make save PROJ

would not change the line at all.

e.g.:

make save PROJ=abc

would change the line to PROJ := abc

This is the sed line that would do the magic:

sed -i "0,/PROJ := /{s/PROJ := .*/PROJ := $(PROJ)/}" ./user_projects/$(PROJ)/Makefile

I added this line to the Makefiles of my PhysiCell user_projects, and it makes dealing with the projects much easier.

Bottom line

Has anyone thought about passing in other files/folders at the command line rather than in the config file? I think it's going to be useful enough for me that I'll implement it in my own project, but just wondering if there's any advice out there to make it more readily merge-able into main.

Background

I'm finding it would be helpful to be able to pass in paths to folders/files as command line arguments into a PhysiCell executable, similar to what's already done with the configuration file. Basically, I want to avoid changing the configuration file just to change the files/folders it encodes (output folder, initial conditions, rules). I can get it to work with minor edits to main.cpp for the output folder and configuration files, but it's a much bigger lift for the others requiring either

1. a rewrite of create_cell_types and setup_tissue which are essentially "core" code though live in custom_modules
2. a rewrite of setup_cell_rules and load_cells_from_pugixml which are core and modules, respectively

Proposed solution

./project -c $(path_to_config) -o $(path_to_output) -i $(path_to_ic) -r $(path_to_rules)

cell_type and substrate names are so far only kept in the settings.xml file.
if this names by the program could be passed down to the output.xml, then there would be no need for pcdl (physicell data loader) to read the settings.xml.

Sometimes, when two rules have the same target cell type and the same target behavior, a segmentation fault occurs when building the dictionary of rules for that cell type. This behavior has been observed for rules version 2, but may also occur when using other versions. These remain untested.

The error does not always occur when two such rules exist. In fact, in the two instances this error has manifested in the community, both were resolved with the same approach: move the offending rule up in the rules list. That is, when the segmentation fault occurs, it is immediately after the problematic rule is displayed in the console and so the user can identify which it is. Simply move this rule up the list (the top of the rules list will do) and the problem appears to go away.

Please post here if you have also ran into this issue. If the solution above does not work for you, please post here and reach out; we will look into it asap.

I was following along with the tutorial here: https://www.youtube.com/watch?v=hIP4JUrViRA&t=653s

And I followed all of the steps, but when I got to the point where you just run "make", right after running "make biorobots-sample", things error out. Here is a snippet of my output from the terminal

(base) D:\physicell_v2\PhysiCell>make
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./BioFVM/BioFVM_vector.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./BioFVM/BioFVM_mesh.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./BioFVM/BioFVM_microenvironment.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./BioFVM/BioFVM_solvers.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./BioFVM/BioFVM_matlab.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./BioFVM/BioFVM_utilities.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./BioFVM/BioFVM_basic_agent.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./BioFVM/BioFVM_MultiCellDS.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./BioFVM/BioFVM_agent_container.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./BioFVM/pugixml.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./core/PhysiCell_phenotype.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./core/PhysiCell_cell_container.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./core/PhysiCell_standard_models.cpp
g++ -march=native -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -c ./core/PhysiCell_cell.cpp
./core/PhysiCell_cell.cpp: In destructor 'virtual PhysiCell::Cell::~Cell()':
./core/PhysiCell_cell.cpp:441:56: error: no match for 'operator<<' (operand types are 'std::basic_ostream' and 'std::vector')
std::cout << "I am of type " << this->type << " at " << this->position << std::endl;
^
In file included from C:/ProgramData/Miniconda3/Library/mingw-w64/include/c++/5.3.0/iostream:39:0,
from ./core/./PhysiCell_custom.h:71,
from ./core/PhysiCell_cell.h:71,
from ./core/PhysiCell_cell.cpp:68:
C:/ProgramData/Miniconda3/Library/mingw-w64/include/c++/5.3.0/ostream:108:7: note: candidate: std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ostream_type& ()(std::basic_ostream<_CharT, _Traits>::__ostream_type&)) [with _CharT = char; _Traits = std::char_traits; std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream]
operator<<(__ostream_type& (__pf)(__ostream_type&))
^
C:/ProgramData/Miniconda3/Library/mingw-w64/include/c++/5.3.0/ostream:108:7: note: no known conversion for argument 1 from 'std::vector' to 'std::basic_ostream::__ostream_type& ()(std::basic_ostream::__ostream_type&) {aka std::basic_ostream& ()(std::basic_ostream&)}'
C:/ProgramData/Miniconda3/Library/mingw-w64/include/c++/5.3.0/ostream:117:7: note: candidate: std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ios_type& ()(std::basic_ostream<_CharT, _Traits>::__ios_type&)) [with _CharT = char; _Traits = std::char_traits; std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream; std::basic_ostream<_CharT, _Traits>::__ios_type = std::basic_ios]
operator<<(__ios_type& (__pf)(__ios_type&))
^

It repeats this over and over again, in many different places. It seems like their is a missing library or something? Please help if you have any ideas what is wrong.

Also, I am running this on windows 10, and I was using the Anaconda terminal as shown in the video.

https://github.com/MathCancer/PhysiCell/blob/master/sample_projects/cancer_biorobots/Makefile#L2

so far, in setting.xml only max_time can be specified to stop the series.
it would be nice to have additionally a max_cell setting to stop the series, and execution would be stopped when either max_time or max_cell is reached.

<overall>
    <max_time units="min">14400</max_time>
    <max_cell units="agent">9000</max_cell>
    ....
</overall>

https://github.com/MathCancer/PhysiCell/blob/master/core/PhysiCell_cell.cpp#L3039

I have a basic question of what is copied to the output folder.

1. the cell seeding file cells.csv or what ever it's name is, is so far not copied into the output folder.
   should we do that?
   might the cells.csv be needed for downstream analysis?

2. the cell_rules.csv file is actually not a copy of the cell_rules.csv file in the in the config folder (which is nowadays a version 2).
   it is generated, and it is a rules version 1 file.

The big question behind all of this is:

• What is the intent of the files that are copied into the output folder?
• Should there be only files that are of use for down stream data analysis (e.g. with physicell data loader)?
• Should there be all the files needed to be able to rerun?
• nothing of all above but something else?

PS: the calls to handle all of this are currently downstream of the custom.cpp / create_cell_types function, which is called from the main.cpp / main function.

I have not found the name of certain variables. To clarify why I need them, I will shortly describe my scenario.

This is a wound healing essay, where cells have two state: if a cell has 4 neighbors it will become quiescent, when it has less, it will transition back to proliferating cell. When 90% of cells have turned into quiescent cells, a scratch is introduced by deleting cells in the middle of the simulation area. After this, the simulation is continued for three more simulated days.

As I have read, the neighbor array is not used presently. I would need:

• the coordinates of a cell (I also need this to "inflict" the wound)
• and the variable, where the end of the simulation is stored.

Thank you.
Judit Sessler

I have been unable to compile PhysiCell on my MacBookPro
After make ANY-PROJECT > make, I obtain this error:

ld: symbol(s) not found for architecture arm64
clang-16: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [all] Error 1

I have installed all the required programs. I've tried with several flags, and PhysiCell can be compiled.:
clang-16 -march=native -O3 -fomit-frame-pointer -fopenmp -m64 -std=c++11 -v -o worm BioFVM_vector.o BioFVM_mesh.o BioFVM_microenvironment.o BioFVM_solvers.o BioFVM_matlab.o BioFVM_utilities.o BioFVM_basic_agent.o BioFVM_MultiCellDS.o BioFVM_agent_container.o pugixml.o PhysiCell_phenotype.o PhysiCell_cell_container.o PhysiCell_standard_models.o PhysiCell_cell.o PhysiCell_custom.o PhysiCell_utilities.o PhysiCell_constants.o PhysiCell_basic_signaling.o PhysiCell_signal_behavior.o PhysiCell_rules.o PhysiCell_SVG.o PhysiCell_pathology.o PhysiCell_MultiCellDS.o PhysiCell_various_outputs.o PhysiCell_pugixml.o PhysiCell_settings.o PhysiCell_geometry.o custom.o main.cpp

Do you know how I can fix this issue?

For better User experience:

• Move the About tab to the right if you are using the same layout as to bottom as in the pic below.
• Plotly module has a rich graphical representation than Matplotlib.

We want to have a community discussion about future extensions to PhysiCell. We begin by discussing the existing "addons" extension for intracellular models and then discuss a possible "plugins" extension.

As of PhysiCell 1.10.4, we have "officially" supported addons:

~/PhysiCell_v1.10.4/addons$ ls
PhysiBoSS/	dFBA/		libRoadrunner/

and it happens to be the case that these pertain to intracellular models. How? Well, each of the 3 types (boolean, FBA, and ODEs) provide concrete C++ classes which implement the same API to the abstract class Intrarcellular defined in core/PhysiCell_phenotype.h (as a reminder, an "abstract" class declares all its methods as virtual and those methods must be defined in any derived concrete class). For example, in/addons, we have these concrete classes:

~/PhysiCell_v1.10.4/addons$ grep -i intracellular */src/*.h|grep public

PhysiBoSS/src/maboss_intracellular.h:class MaBoSSIntracellular : public PhysiCell::Intracellular {

dFBA/src/dfba_intracellular.h:class dFBAIntracellular : public PhysiCell::Intracellular 

libRoadrunner/src/librr_intracellular.h:class RoadRunnerIntracellular : public PhysiCell::Intracellular

and then each of the three types of concrete intracellular interfaces provide a similar directory structure and files, e.g., for ODEs/libRoadrunner, we have:

~/dev/PhysiCell_v1.10.4/addons/libRoadrunner$ ls
empty.txt			roadrunner/			roadrunner_macos_arm64.tar.gz	src/

M1P~/dev/PhysiCell_v1.10.4/addons/libRoadrunner$ ls src/
librr_intracellular.cpp		librr_intracellular.h

M1P~/dev/PhysiCell_v1.10.4/addons/libRoadrunner$ ls roadrunner
include/	lib/

When a specific PhysiCell-intracellular model is compiled, it needs to provide information in its Makefile that will say what type of intracellular library will be used.

The PhysiCell distribution provides sample intracellular projects and each project provides a Makefile which uses a g++ compiler macro (-D ADDON_*) that defines which type of intracellular model is to be used:

~/PhysiCell_v1.10.4/sample_projects_intracellular$ 

ode/ode_energy/Makefile:#	CFLAGS := -march=$(ARCH) -fomit-frame-pointer -fopenmp -m64 -std=c++11 -D ADDON_ROADRUNNER 

boolean/physiboss_cell_lines/Makefile:INC := -DADDON_PHYSIBOSS -I$(CUR_DIR)/$(MABOSS_DIR)/include -DMAXNODES=$(MABOSS_MAX_NODES)

fba/cancer_metabolism/Makefile:CFLAGS := -march=$(ARCH) -O3 -fomit-frame-pointer -mfpmath=both -fopenmp -m64 -std=c++11 -pipe  -D ADDON_PHYSIDFBA

Should we distinguish "addons" from "plugins", by saying that addons are limited to officially supported, cross-platform, intracellular libs and “plugins” could be “community supported” code with, perhaps, a library which is not fully supported cross-platform? If so, we should define minimally required info for any plugin, e.g., a README.md and a sample project.

Could we agree on having both an /addons and a /plugins directory in the top level PhysiCell directory, with unique subdirectories for each plugin under /plugins (similar to what is done for intracellular)? And should we define a /sample_projects_plugins at the same directory level and following the template of /sample_projects_intracellular, or should sample projects be provided under each /plugins? Note that there shouldn't be a need for a compiler macro since there will won't be any abstract and concrete classes as with intracellular. Rather, a Makefile for a sample project using a plugin will simply provide the necessary paths and names of the new files and possible libraries.

To me, there appears to be an implied relationship between is_Dirichlet, dirichlet_activation_vector, and dirichlet_activation_vectors. It seems dirichlet_activation_vectors is an $n_\text{voxels}\times n_\text{substrates}$ array and the others are (supposed to be) the result of any along the two dimensions.

If this is correct, then current implementations in BioFVM_microenvironment.cpp do not maintain this consistency. It can lead to unexpected behaviors in which a command such as update_dirichlet_node targeting a single substrate actually affects other substrates as well.

i run

make reset
make temple

after that, in the granted PhysiCell_settings.xml is a standalone <molecular/> tag, line 315.
I am not a pro in xml, but this looks strange to me.

I don't think we want to do this (cell_definitions_by_index.push_back) in the assignment method, do we? Shouldn't it only be done in the two constructor methods? I added some unit tests in a recent PR, related to this.

Users have reported getting a strange compilation error after they updated their macOS to 12.6. Running make would end in:

ld: Assertion failed: (_file->_atomsArrayCount == computedAtomCount && "more atoms allocated than expected"), function parse, file macho_relocatable_file.cpp, line 2061.
collect2: error: ld returned 1 exit status

and this was using g++-12 from brew install gcc. The fix that seems to work is the following:

• download https://download.developer.apple.com/Developer_Tools/Command_Line_Tools_for_Xcode_13.4_Release_Candidate/Command_Line_Tools_for_Xcode_13.4_Release_Candidate.dmg (it should be about 689 MB). This may require that you create a (free) Apple developer's account if you don't already have one. If you create a developer's account (and are logged in to it) and are still unable to access the previous link, try going to this link https://developer.apple.com/download/all/?q=xcode and then scroll down to "Command Line Tools for Xcode 13.4 Release Candidate", then click the "View Details" and then click the exposed link to download the .dmg (ugh).
• open/install that .dmg (click through all the prompts)
• try to re-run your PhysiCell make from your shell terminal

If you still experience an error compiling, reply to this issue or report it on the PhysiCell community workspace #install-help slack channel.

for parameter scans, usually not all the output is needed.
to reduce the need of disk space it would be ideal if one could specify in the seetings.xml what output will be generated.

https://github.com/MathCancer/PhysiCell/blob/master/core/PhysiCell_rules.cpp#L2356

setup_cell_rules() is calling export_rules_csv_v1( rules_file );

As best I can tell, elapsed_time_in_phase is being saved twice:

1. PhysiCell/modules/PhysiCell_MultiCellDS.cpp

   Line 1769 in 3d7051f

   std::fwrite( &( pCell->phenotype.cycle.data.elapsed_time_in_phase ) , sizeof(double) , 1 , fp );

2. PhysiCell/modules/PhysiCell_MultiCellDS.cpp

   Line 1807 in 3d7051f

   std::fwrite( &( pCell->phenotype.cycle.data.elapsed_time_in_phase ) , sizeof(double) , 1 , fp );

Note: these two are appended to the list of labels in the output xml here:

1. PhysiCell/modules/PhysiCell_MultiCellDS.cpp

   Lines 942 to 950 in 3d7051f

   	name = "elapsed_time_in_phase";
   	units = "min";
   	size = 1;
   	data_names.push_back( name );
   	data_units.push_back(units);
   	data_sizes.push_back( size );
   	data_start_indices.push_back( index );
   	cell_data_size += size;
   	index += size;

2. PhysiCell/modules/PhysiCell_MultiCellDS.cpp

   Lines 1091 to 1099 in 3d7051f

   	name = "elapsed_time_in_phase";
   	units = "min";
   	size = 1;
   	data_names.push_back( name );
   	data_units.push_back(units);
   	data_sizes.push_back( size );
   	data_start_indices.push_back( index );
   	cell_data_size += size;
   	index += size;

There's currently a duplicate assignment for maximum_attachment_rate in the Mechanics constructor. Wondering if one should be for detachment_rate? Currently at this location in the dev branch:
https://github.com/MathCancer/PhysiCell/blob/development/core/PhysiCell_phenotype.cpp#L702

initialize_cell_definition_from_pugixml----------- substrate_name (for chemotaxis) =
initialize_cell_definition_from_pugixml----------- pMot->chemotaxis_index= -1

			std::string actual_name = microenvironment.density_names[ pMot->chemotaxis_index ]; 

the default PhysiCell output misses information to generate evolutionary lineage trees.
it would be good enough when each agent saves information about:

• parent agent_id
• simulation time of birth
• simulation time of death

with this information, things like generation number or generation time can be derived downstream (in Python, R, Julia or whatever your favorite data analysis language flavor).

I am planning to attend "Computational modelling to study cancer biology and treatments" and rather use the manual process to install PhysiCell on macos in advance, I created a nix derivation for it. NB you don't have to install openmp or set environment variables. It's all done for you and openmp and the C++ compiler are pinned to specific versions. I could probably make it so the script is parameterised but I've done enough for the workshop.

You can run it by downloading the matching settings file and then

nix-build release.nix
./result/bin/biorobots biorobots_PhysiCell_settings.xml

Of course you have to install nix first but that's just

curl https://nixos.org/nix/install | sh

Here are the files you will need

default.nix

{ stdenv
, fetchurl
, llvmPackages
, overrideCC
, gcc }:

let

openmp = llvmPackages.openmp;

in (overrideCC stdenv gcc).mkDerivation rec {
  pname = "PhysiCell";
  version = "1.7.1";

  buildInputs = [ openmp ];
  nativeBuildInputs = [ openmp ];

  src = fetchurl {
    url = "https://github.com/MathCancer/${pname}/archive/${version}.tar.gz";
    sha256 = "000pkw8maldb25b8g9cgr5qi4l905073pqrr3nfazc9n990260fi";
  };

  PHYSICELL_CPP="${gcc}/bin/g++";

  project = "biorobots";

  buildPhase = ''
    make $project-sample
    make
  '';

  installPhase = ''
    mkdir -p "$out"/bin
    cp $project $out/bin/$project
  '';

  meta = with stdenv.lib; {
    description = "PhysiCell: an Open Source Physics-Based Cell Simulator for 3-D Multicellular Systems.";
    homepage    = http://physicell.org;
    platforms   = platforms.all;
    maintainers = with maintainers; [ idontgetoutmuch ];
    license     = licenses.bsd3;
  };
}

release.nix

let

nixpkgs = builtins.fetchTarball {
    url = "https://github.com/NixOS/nixpkgs/archive/20.03.tar.gz";
    sha256 = "0182ys095dfx02vl2a20j1hz92dx3mfgz2a6fhn31bqlp1wa8hlq";
};

in

with import nixpkgs {};

callPackage ./default.nix {}

I've run a few simulations on my laptop and everything works fine. Now I am trying to use the HPCC at my university to test the simulation, but I encountered this error while viewing the output images.

I have no idea what this error means exactly. I also notice that for the first few minutes of the simulation, there is nothing wrong with the images, however, this error message comes up in the middle of the simulation after a while. In the meantime, this error doesn't stop my simulation, instead, it keeps running till the end but the rest of the images are all having the same issue.

A user shared his model with ~16Kx16K 2D domain and 10 substrates and ~40K cells. It crashed shortly after the simulation started. The reason was tracked down to this hard-code buffer size: https://github.com/MathCancer/PhysiCell/blob/master/BioFVM/BioFVM_MultiCellDS.cpp#L567

We might attempt doing a calculation to determine the size needed and also add a try-catch to exit more gracefully.

He's a grad student at Colorado State who posted on our slack general channel. He'd built his model using the Studio. I helped him fix his cells .csv syntax from histological data. @drbergman made him aware of the BIWT option in the Studio ICs tab.

https://github.com/MathCancer/PhysiCell/blob/master/sample_projects/rules_sample/config/cell_rules.csv#L27
and
https://github.com/MathCancer/PhysiCell/blob/master/sample_projects/rules_sample/config/cell_rules.csv#L32
need a comma after "decreases"

Hello,

I am trying to build using NVIDIA C++ Compiler nvc++ version 24.5

CC := nvc++
CFLAGS := -O3 -fomit-frame-pointer -mp -std=c++11

It complains with the following error(s):

nvc++ -O3 -fomit-frame-pointer -mp -std=c++11  -o heterogeneity BioFVM_vector.o BioFVM_mesh.o BioFVM_microenvironment.o BioFVM_solvers.o BioFVM_matlab.o BioFVM_utilities.o BioFVM_basic_agent.o BioFVM_MultiCellDS.o BioFVM_agent_container.o   pugixml.o PhysiCell_phenotype.o PhysiCell_cell_container.o PhysiCell_standard_models.o PhysiCell_cell.o PhysiCell_custom.o PhysiCell_utilities.o PhysiCell_constants.o PhysiCell_basic_signaling.o PhysiCell_signal_behavior.o PhysiCell_rules.o PhysiCell_SVG.o PhysiCell_pathology.o PhysiCell_MultiCellDS.o PhysiCell_various_outputs.o PhysiCell_pugixml.o PhysiCell_settings.o PhysiCell_geometry.o custom.o main.cpp
main.cpp:
/usr/bin/ld: PhysiCell_constants.o: in function `__sti___30___core_PhysiCell_constants_cpp_d2e95040':
nvc++Ormxb4w0R0PHy.ll:(.text+0xb4): undefined reference to `PhysiCell::PhysiCell_constants::advanced_Ki67_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0xc4): undefined reference to `PhysiCell::PhysiCell_constants::advanced_Ki67_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x118): undefined reference to `PhysiCell::PhysiCell_constants::basic_Ki67_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x120): undefined reference to `PhysiCell::PhysiCell_constants::basic_Ki67_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x158): undefined reference to `PhysiCell::PhysiCell_constants::flow_cytometry_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x164): undefined reference to `PhysiCell::PhysiCell_constants::live_cells_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x19c): undefined reference to `PhysiCell::PhysiCell_constants::flow_cytometry_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x1c8): undefined reference to `PhysiCell::PhysiCell_constants::live_cells_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x1f8): undefined reference to `PhysiCell::PhysiCell_constants::flow_cytometry_separated_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x234): undefined reference to `PhysiCell::PhysiCell_constants::flow_cytometry_separated_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x268): undefined reference to `PhysiCell::PhysiCell_constants::cycling_quiescent_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x274): undefined reference to `PhysiCell::PhysiCell_constants::apoptosis_death_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x278): undefined reference to `PhysiCell::PhysiCell_constants::necrosis_death_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x2b4): undefined reference to `PhysiCell::PhysiCell_constants::cycling_quiescent_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x2e0): undefined reference to `PhysiCell::PhysiCell_constants::apoptosis_death_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x30c): undefined reference to `PhysiCell::PhysiCell_constants::advanced_Ki67_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x310): undefined reference to `PhysiCell::PhysiCell_constants::necrosis_death_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x34c): undefined reference to `PhysiCell::PhysiCell_constants::advanced_Ki67_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x370): undefined reference to `PhysiCell::PhysiCell_constants::basic_Ki67_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x378): undefined reference to `PhysiCell::PhysiCell_constants::basic_Ki67_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x3f4): undefined reference to `PhysiCell::PhysiCell_constants::flow_cytometry_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x3f8): undefined reference to `PhysiCell::PhysiCell_constants::flow_cytometry_cycle_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x508): undefined reference to `PhysiCell::PhysiCell_constants::cycling_quiescent_model'
/usr/bin/ld: nvc++Ormxb4w0R0PHy.ll:(.text+0x514): undefined reference to `PhysiCell::PhysiCell_constants::cycling_quiescent_model'
pgacclnk: child process exit status 1: /usr/bin/ld
make: *** [Makefile:71: all] Error 2

I consulted NVIDIA compiler engineer. It looks like the code is not super portable. The file core/PhysiCell_constants.h contains many static data members of type const int, such as:

namespace PhysiCell
{
class PhysiCell_constants
{
 public:
        // ...
        static const int advanced_Ki67_cycle_model= 0;
        // ...
};
};

Each of those static data members must have an out-of-class definition in a .cpp file somewhere, so that storage for the static data member exists somewhere:

namespace PhysiCell {
const int PhysiCell_constants::advanced_Ki67_cycle_model;
}

In some cases the compiler can do constant folding and optimize away references to the static data member, in which case the code can get away without the definition. With -O3 GNU seems to work. With lower optimisation flags, it may complain too. nvc++ is unable to do the constant folding in this particular situation,

It would be best if the code becomes more robust, so that PhysiCell_constants.cpp contained definitions for all the static data members of class PhysiCell_constants. That will make the code able to build in more situations and with more compilers with different optimisation levels.

I have compiled and ran successfully PhysiCell.
From the output data, can anyone give me some directions to understand the data and make the 3D visualization using Unity Engine?
I have searched for more info on the meaning of output data but so far I've got no result. So if possible can you direct me to the resource?

I do appreciate for that. Thank you all so much!

Regards,
Anh

https://github.com/MathCancer/PhysiCell/blob/master/sample_projects/interactions/config/PhysiCell_settings.xml#L1525

https://github.com/MathCancer/PhysiCell/blob/master/sample_projects/interactions/custom_modules/custom.cpp#L219

-->
ERROR : Unknown parameter number_of_cells ! Quitting.

I can include a fix (add the param into the config file) in the dev-randy-DCs branch. Hmm, but not sure what the desired fix is though. Do we really want a number_of_cells user param, or should the custom.cpp be using one of the other number_of_* params for init?