The Computational Domain
Following definition of all bulk compartments, the computationDomain is defined.
The computationDomain may be either 2D or 3D, as desired. (Note though that 3D simulations are more computationally intensive and will require more time to run.) The spatial domain is broken into rectilinear regions that each occupy a small space, and definition of the computationDomain* requires defining how these regions are set up.
The parameter nDim controls the number of simulation dimensions: 2 or 3. The parameters nI, nJ, and nK set the number of grid elements in each of the x, y, and z directions, respectively. Note that in iDynoMiCS the y and z directions represent the two horizontal directions and x is always the vertical direction – whether 2D or 3D – in order to preserve the substratum location in 2D simulations (when the z direction is ignored). The algorithm used to solve for the solute concentration fields requires that the number of gridpoints be a power of two plus 1, i.e. 33, 65, etc. In the biofilm scenario the resolution parameter (units of micrometers) defines the width of each side of each grid element, so that in the first dimension the spatial extent of the computational domain will be nI*resolution, and will be nJ*resolution and nK*resolution in the second and third dimensions, respectively.
In the chemostat scenario there is only one cubic grid element, and the resolution parameter will determine the volume of the reactor and hence the size of the system being simulated - the higher the volume, the more agents can exist for a given set of growth and substrate conditions.
When defining a 2D simulation, merely set nDim to 2 and set nK=1; the third dimension will be assumed to have the length of the resolution.
In a chemostat run there is only one grid element and the resolution is used to calculate the volume of a cube with that length. This is the real volume being simulated, and the number of agents being simulated is determined by the size of the chemostat. Nevertheless, substrate and biomass concentrations in steady state given a set of growth conditions remain unchanged despite the volume being simulated. Bear in mind that big volumes will simulate thousands of agents, which in turn renders the simulations much slower. The volume of the chemostat is noted in the first few lines of the log file.
The next few parameters refer to more physical aspects of the domain. The boundaryLayer parameter gives the thickness of the boundary layer between the biofilm and the bulk. This boundary layer forms part of the pure liquid region within the domain, and in this region only diffusion governs the local concentration. Beyond the boundary layer region the liquid is assumed to be well-mixed, and so the solute concentrations are kept equal to their concentration in an attached bulk compartment.
The biofilmDiffusivity parameter is a factor used to decrease solute diffusivity inside the biofilm. It is a multiplicative factor applied to the diffusivity in water. Values around 0.8 are common; values lower than 0.5 are rare.
The specificArea parameter is used to describe the ratio between the carrier surface (substratum on which the biofilm grows) and the bulk compartment volume; this is where the physical volume of the system appears in the simulation definition. This parameter is expressed in units of m²/m3.
It is also necessary to define the behaviour at the boundaries of the computationDomain. A 2D simulation requires 4 boundary conditions and a 3D system requires 6. iDynoMiCS at this point includes only planar boundaries, but the extensible nature of the code means different shapes may be introduced (see the source code package simulator.geometry.shape for details). The planar shape of a particular boundary is defined by the following mark-up:
Because a plane is fully defined by a point and a normal vector, these two properties must be specified for each boundary; the normal vector by convention points outside the domain. For a particular boundary plane, the parameter pointIn defines a gridpoint which exists on that domain boundary (just outside the domain itself), and the parameter vectorOut specifies the direction of the planar normal vector. Note that each of these two parameters are described in the XML file using discrete coordinates, and so the pointIn parameter should be given in terms of gridpoint index. Because the gridpoint indices run from 0 to N-1, the pointIn parameter will take value -1 or N in the relevant direction. For reference, consider the following image of a cyan computationDomain with indexed gridpoints and dashed boundaries:
In this image, the green elements represent the points belonging to the boundary plane and the two arrows are the planar normal vectors. The left green element will have the plane description given above, while the green element on the right will be described by the following:
In addition to the boundary shape, one must also specify the behaviour of the boundary when defining a boundary condition. The class used to create a boundary condition is defined by the attribute class of the mark-up boundaryCondition. iDynoMiCS has several possible boundaries already defined, but once again more may be defined by adding source code for different behaviours (see the package simulator.geometry.boundaryConditions). In addition to the class attribute of each boundaryCondition mark-up, one must specify via the name attribute which face of the cubic computationDomain is being described. For example, the y-z plane for x = 0 will be called ‘y0z’ while the opposing side will be called yNz; these two faces describe the bottom and top of the domain, respectively. The remaining four faces are called ‘x0y’, ‘xNy’, ‘x0z’, and ‘xNz’. We now show an example of each currently usable boundary condition type.
The zero-flux boundary condition defines a boundary that is impermeable to both agents and solutes (the substratum is usually of this type):
The bulk boundary condition connects the domain to a previously-defined bulk compartment:
The solute concentrations at this boundary are set equal to the concentrations in the connected bulk compartment. This boundary condition is generally used for the top of the domain.
A constant boundary condition is similar to the BoundaryBulk type, but in this case the bulk concentration is not updated dynamically:
The BoundaryBulk type is more generally applicable than BoundaryConstant because it may too handle constant bulks, but this condition is here if needed.
Cyclic boundaries are useful in that they allow simulation of larger domains by assuming that the computationDomain region is replicated indefinitely; in this treatment it is assumed that variations in the laterally-repeated direction are less important than vertical variations within the domain. The two connected boundaries are specified together when creating cyclic boundary conditions, and so one must define two planes within the boundaryCondition mark-up:
Solute concentrations are kept constant across cyclic boundaries, and any agent crossing one of the cyclic boundaries will be instantly moved to the connected boundary. These boundaries are generally used for the sides of the domain.
Finally, a BoundaryGasMembrane boundary condition is provided in order to simulate systems where one or more boundaries exhibit selective permeability (e.g. growth on an oxygen-permeable membrane):
This boundary condition acts like a zero-flux boundary for the agents and all solutes, except for any solutes for which the isPermeableTo parameter is given; in that case, the solute permeability governs the behaviour of that solute at the boundary. This boundary condition will generally be used for the domain bottom (substratum).