Species on membranes

[lkeegan]

As suggested by @shoops It would be nice to be able to have species (e.g. transmitters) that live on the membranes.

Some open questions:

• how would this be defined in SBML
• would they be spatial & diffuse, or fixed spatial distribution/location but no diffusion?
• implementation in dune-copasi
• implementation in pixel

[lkeegan]

one solution (for transmitters with a fixed location) which would require minimal changes to either simulator would be:

• add a transmitter species to one (or better both) of the compartments
• set it to have a zero diffusion constant
• set the initial concentration zero everywhere, except adjacent to the membrane where desired
  • for pixel simulations this could be as small as a single pixel
  • for dune would have to ensure it is not lost in the interpolation
  • however, assuming the species only affects membrane reactions, no harm in it extending away from the membrane as it doesn't affect anything else by doing so
• then add a membrane reaction that involves it

This could be presented to the user in the GUI as the species being located only on the membrane, (and the GUI could by default omit this species from the simulation results) but the above is what the simulators would see.

This approach would mean we wouldn't need the finite volume rectangles approach at all on the dune side (which would be good since it significantly reduces both the speed and accuracy of the solution), nor would we need to alter the pixel simulator to have species explicitly living on the membrane.

Note: if the species should also diffuse in the membrane, then this obviously doesn't work. However, in this case the membrane can simply be an explicit compartment in the model. This would mean reactions on the membrane now have to be duplicated for both sides of the membrane compartment, which is not very user friendly, but if there is demand for this the GUI interface could hide / take care of this duplication. Otherwise I don't see any fundamental problems.

[SoilRos]

If I understand well, this is what Prof. Bastian proposed in one of the meetings, right?

I would not -yet- disregard the finite volume membrane. Yes, it is way slower and reduces accuracy on the boundaries of the FEM problem, but it does not add a bunch of degrees of freedom that scale inversely with respect to the mesh size in the domain. My guess is that it would not scale well (I think this was the main reason we went for FV in the first place). But, if you manage to implement that, it would be really good to compare results with the different approaches for the same problem.

[SoilRos]

I will try to do measurements on that, though :wink:

[lkeegan]

If I understand well, this is what Prof. Bastian proposed in one of the meetings, right?

I don't remember this, but if so then great!

I would not -yet- disregard the finite volume membrane. Yes, it is way slower and reduces accuracy on the boundaries of the FEM problem, but it does not add a bunch of degrees of freedom that scale inversely with respect to the mesh size in the domain.

The additional degrees of freedom would be one additional variable which scales in the same way as the other variables, right? so the cost would not be so large - the same as adding another (normal) species to the model (maybe less since I guess it's mostly adding zeros to the jacobians if they are implemented as sparse matrices).

My guess is that it would not scale well (I think this was the main reason we went for FV in the first place). But, if you manage to implement that, it would be really good to compare results with the different approaches for the same problem.

Given that FV is more complicated to implement (both on the GUI side constructing the mesh & reactions, and on the dune side) and gives less accurate results, I would be in favour of first implementing the simpler & more accurate method.

[SoilRos]

The additional degrees of freedom would be one additional variable which scales in the same way as the other variables, right? so the cost would not be so large - the same as adding another (normal) species to the model (maybe less since I guess it's mostly adding zeros to the jacobians if they are implemented as sparse matrices).

If you think about refinement that doesn't look so good. In dune, doing per-entity-dof selection in the jacobian is not so easy so the memory-access burden will still be there. But you are right that it might be compensated with respect to the approximation error. Hard to say without trying. So this is definitely worth to check it out.

Given that FV is more complicated to implement (both on the GUI side constructing the mesh & reactions, and on the dune side) and gives less accurate results, I would be in favour of first implementing the simpler & more accurate method.

Right, but is already implemented. I don't want to say, "don't do it, we have a super good solution", I instead want to say: "don't just throw away something is complicated to do and is already working to find out later that you need to re-implement it because X or Y", or at least don't until we can prove that the new alternative outperforms the current one.

In dune, the burden implementing it is already done and supporting it now on is not so much of a problem. What do you think about the GUI? If that's so bad, then getting only one to work is more maintainable and then I understand your position :)

[lkeegan]

Right, but is already implemented. I don't want to say, "don't do it, we have a super good solution", I instead want to say: "don't just throw away something is complicated to do and is already working to find out later that you need to re-implement it because X or Y", or at least don't until we can prove that the new alternative outperforms the current one.

Yes, I agree

In dune, the burden implementing it is already done and supporting it now on is not so much of a problem. What do you think about the GUI? If that's so bad, then getting only one to work is more maintainable and then I understand your position :)

Maintaining both options simultaneously in the GUI makes both the code (in particular the meshing) and the UI more complicated & harder to maintain & test, so what I would propose is to make a branch of the GUI that uses the current rectangles method, and implement the new method on master.

This way both methods remain available for testing & comparing them.

[SoilRos]

I discussed this approach a bit, and we are not sure that this would give the wanted results. True, the spatial integrals can be deceived to only perform local computations with this approach, but what happens to the runge-kutta stage evaluations? As I understand it, they would contribute to the mass matrix even on the interior of the cell, affecting thus the total mass per cell of the species. This would make the interface species dependent on the mesh!

[lkeegan]

With zero diffusion constant and no reaction terms for this species, I would have expected the runge-kutta stage not to do anything to this species in the interior of the cell.

Is it because of a possible flux of the species at the membrane?

If so, would it be ok if there was no flux of the membrane species across the boundary? (i.e. it could still affect the flux interface condition for other species but would itself have zero flux interface conditions).

[SoilRos]

The time integral still has a volume measure and would contribute to the mass matrix as if the concentration was in the whole cell. So no, this happens regardless of the diffusion coefficient or whether you have intersection fluxes.

[SoilRos]

Next release of dune-copasi will natively support membrane species. I am still working on some details but the feature is for the most part implemented. Some questions remain.

• How to exchange in and out values? (grid functions do not work particularly well here)
• The feature will not work in 3D due to a problem of the grid.
• Membrane species on the boundary are also possible if needed. So far not implemented.

[SoilRos]

Next release of dune-copasi will natively support membrane species.

Unfortunately, I over-promised here. I had to exclude this from v2.0.