SBML-spatial and Smoldyn

[Steven S Andrews]

Hi SBML crowd,

Lucian just suggested that I read through the latest SBML-spatial standard and make comments. I did so, from the lens of thinking about how it would apply to Smoldyn. Admittedly, I don't have plans for Smoldyn to support SBML-spatial at the moment, but I'm certainly in favor in principle. Someday, it would be great to have interoperability between the spatial packages. Anyhow, here is our conversation, with my questions in black and Lucian's answers in blue. Feel free to build on this as a discussion topic.

On Fri, May 13, 2022 at 2:04 PM Steve Andrews <steven.s...@gmail.com> wrote:

Hi Lucian (and Herbert),

I just read and skimmed the SBML-spatial specification, which is interesting. I'm not very familiar with UML or package specifications, so there were aspects that I didn't understand, but it made sense overall.

I hope it's not too self-centered, but my natural thought process was to wonder if it would work for Smoldyn or not. The answer is maybe, at least in part.

In the GeometryDefinitions section, I wasn't sure which, if any, of the definition approaches were compatible with Smoldyn. I would label Smoldyn's definition approach as constructive surface geometry, in which surfaces are constructed out of a set of primitives. These primitives are axis-aligned rectangles, triangles, spherical shells, hemispherical shells, cylindrical shells, and disks. Each of these constitutes a "panel" in Smoldyn terminology, and a collection of them create a "surface". A model may have many surfaces, each with different attributes.

The closest equivalent in Spatial would be the Constructed Solid Geometries.  The shapes you can use in Spatial are spheres, cubes, cylinders, cones, circles, and squares.  You can distort them to your heart's content, so you can get (say) a triangle or rectangle out of a square, and you can create intersections or unions, so you can get a hemisphere out of a sphere and a cube.  I guess importing a cone might be difficult, unless you can distort your own cylinders to have a circle of radius 0 at one side?  At any rate, it seems doable.

For the boundary conditions, I wasn't clear what the Robin boundary condition options represented. Presumably, they're for adsorption and desorption. Alternatively, they could represent partial transmission through the boundary. In any case, Smoldyn supports both options.

I'm not super sanguine about the different types of boundaries, but I think your analysis is correct.

 

Another important boundary condition that I didn't see was a transparent boundary, meaning that molecules just diffuse (or advect) right through it without any effect at all. 

I know this is possible, though I'm not certain how it works.  Perhaps if you set the diffusion to 100%?

 

Also, for the physical science community, periodic boundaries are extremely useful. Smoldyn supports these in a couple of ways, one of which is a "jumping surface", in which a molecule that bumps into a jumping surface gets instantly transported over to the far side of that surface's jumping partner. This is good for periodic boundaries, and also for creating holes in otherwise impermeable boundaries (e.g. if I want a cell with a hole in it, I create a sphere and then sandwich a pair of disk-shaped jumping boundaries onto the portion of the sphere where I want the hole).

This sounds like something Spatial doesn't have at this time.  If other groups do that sort of thing, though, I'm sure it could be added.

Something that I didn't see in the standard but is presumably supported is that the boundary conditions should vary depending on the molecular species. Thus, for example, one species reflects off of the boundary, whereas another is adsorbed onto it.

Yes, boundary conditions are species-specific.  You can either define a boundary condition for a species/boundary pair, or define an explicit reaction for the process.

 

I didn't understand the compartment concept, in terms of how they are used and how they occupy space. On the use aspect, Smoldyn allows users to create compartments, and to then use them to place molecules within the compartment, to have some reactions only occur within specific compartments, or to count molecules in certain compartments. Smoldyn does not allow diffusion coefficients to depend on what compartment a molecule is in, although many users have asked for this (doing so is a lot more complicated than they realize, because it also implies different reaction and surface parameters in each compartment). 

Diffusion coefficients can be defined for every species, axis, and compartment combination in the model.  So you might not be able to import all models, but you could definitely export what you need.

 

On how compartments occupy space, is every point in space within some compartment? And, can compartments overlap, so that some points in space are in multiple compartments at once? Also, do compartments include their bounding surfaces?

Compartments can be defined by overlapping shapes/geometries, but every point in space belongs to a single compartment.  I don't know what it means to 'include' a 2D thing in a 3D thing, but I think you can do what you like.  I know some models have both 3D and 2D compartments, modeling membranes as their own thing.

 

Smoldyn's approach for defining compartments is computationally efficient and convenient in practice, but seems a little odd at first glance. Users define compartments by defining one or more “interior-defining points” and then one or more bounding surfaces. A point in space is in the compartment if it’s possible to draw a line from it to any of the interior-defining points without crossing a boundary. This is probably not compatible with the VCell or other software compartment approaches.

There actually is a similar concept in Spatial where you can define one or more 'interior points' for a given geometry.  The compartment is defined by the boundaries, however, and not by ray-tracing.  You could probably reasonably switch between the two if need be?

 

I didn't understand how compartments differ from domains.

I remember eventually figuring out the difference, and then forgetting it again ;-)  My hazy recollection is that Compartments are more SBML-style 'things with species in them' and Domains are more 'geometrical areas'.  I don't know specifically why they're separate; maybe so you don't have to have a 1:1 mapping between the two?  This would be a good thing to ask sbml-discuss.

 

For advection, it seems that it would be easier to just define it as a single vector rather than a separate parameter for each axis, although those are obviously equivalent. Smoldyn supports this functionality, but it hasn't proven to be particularly useful. Instead, users generally want advection that depends on the local environment rather than the global coordinate system. For example, they want molecules to drift toward or away from membranes, or to drift toward ion channels, etc. I find that surface drift (e.g. surface-adsorbed molecules that drift toward one end of a cylinder) is actually much more useful than global advection in 3D space. One thing that might help is if advection depended on the compartment.

Where were you six years ago when this was being discussed? ;-)  But yes, since species are compartment-specific, the same would be true of its advection.

 

I didn't like the anisotropic diffusion definitions because they seemed overly complicated. Instead, a simple 3x3 matrix is fully sufficient for any anisotropic diffusion. Ideally, this would depend on the compartment. For example, suppose molecules diffuse rapidly along the long axis of a bacterium but slowly across it. Then, if the simulation has many bacteria with different orientations, the matrix could be rotated for each bacterium.

That also sounds like something that could be added (or something that could have been designed differently six years ago).  I at least vaguely recall the concept of local coordinate systems being bandied about.  

However, if you split up all your bacteria as having their own compartments, you could at least define this for each of those compartments' species.  I do think that people like to model 'the inside of any bacteria' as a single compartment, though.

 

I didn't see any support for surface-bound molecules. For example, membrane-bound receptors, which diffuse along the surface and have reactions with molecules on either side of the surface. These surface-bound molecules can also react with other surface-bound molecules, such as receptor dimerization. In addition, surface-bound molecules should also interact with other surfaces, such as a receptor that reaches the edge of a lipid raft, where perhaps it is excluded. (Smoldyn supports all of these.)

I think you would model these as species in a 2D compartment in 3D space.

 

I'm not sure if it's part of the SBML scope, but graphical rendering doesn't appear to be included here, such as the color and drawing method for each surface.

It is not!

 

Another thing that's probably beyond the SBML scope is to include molecule sizes and maybe shapes. For example, Smoldyn allows molecules to have sizes and hence to have excluded volume. ReaDDy and SpringSaLaD are other spatial simulators that support this functionality. I think MCell might, but I'm not sure. VCell does not (except with their embedded version of Smoldyn).

Correct; that is also outside of spatial's (current) scope.

 

Yet another thing that's probably beyond the scope is to consider dynamic surfaces. This includes surfaces that move in response to user instructions, that move in response to internal forces, and that change topology, such as a cell dividing. Smoldyn has some support for dynamics, but I'd like to add more.

Yes, that is indeed outside of spatial's current scope, and I also think it's an obvious target for future development.  If someone could manage to get a grant together to work on that, that'd be great.  I bet you'd have a bunch of labs that would be interested, assuming you could manage to point them all in the same direction...

Would you be willing to post all or some of these questions to sbml-discuss?  It'd be great to get a discussion going there, and the people that could answer your questions better than I would be able to chime in.  And we might also find bits of the spec that need better explanations as a result.