distinguishing extensions: addons vs. plugins

[rheiland]

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.

[drbergman]

I agree on having both /addons and /plugins in the top level directory.

On where to house sample projects for the plugin, I think it makes more sense for those to be in /plugins/[plugin-name]/sample_projects or some such directory to minimize setup for users downloading the plugin. I.e., they just unzip the plugin folder and move it inside /plugins.

[drbergman]

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.

I don't understand this part. Can you confirm PhysiPKPD matches this description?