sbml-spatial Mailing List for Systems Biology Markup Language (SBML)

> 
> OK, I've checked into SVN a new version of the spec that has the
> changes:
> 
> * 'spatialId' -> 'id'
> * 'componentType' -> 'type'
> * No R-function
> * 'inwardNormalFlux' -> 'Neumann'
> * 'value' -> 'Dirichlet'
> * 'ComponentKind' -> 'CoordinateKind'
> * 'CoordinateIndex' -> 'CoordinateReference'
> * 'coordinateIndex' of type 'int' -> 'coordinate' of type 'CoordinateKind'
> * DiffusionCoefficient's can have 1 child CoordinateReference.
> * New 'anisotropic' DiffusionKind, to go with 'tensor' and 'isotropic'.
> 
> If people like these changes, I'll release that spec as release 0.87.
> 

That looks good to me.  I would still prefer DiffusionCoefficient to have
optional attributes: 

coordinateReference1 : CoordinateKind (optional)
coordinateReference2: CoordinateKind (optional)
coordinateReference3 : CoordinateKind (optional)

rather than the sub elements. It would safe another class to be added, would
provide people less hassle in interrogating the model later on, or producing
the elements. (And would make the whole thing less verbose). If however you
insist on the sub-elements, we will need to additionally wrap them in a
'listOf' to be consistent with the rest of the object model. 

Cheers
Frank

OK, I've checked into SVN a new version of the spec that has the 
changes:

* 'spatialId' -> 'id'
* 'componentType' -> 'type'
* No R-function
* 'inwardNormalFlux' -> 'Neumann'
* 'value' -> 'Dirichlet'
* 'ComponentKind' -> 'CoordinateKind'
* 'CoordinateIndex' -> 'CoordinateReference'
* 'coordinateIndex' of type 'int' -> 'coordinate' of type 'CoordinateKind'
* DiffusionCoefficient's can have 1 child CoordinateReference.
* New 'anisotropic' DiffusionKind, to go with 'tensor' and 'isotropic'.

If people like these changes, I'll release that spec as release 0.87.

-Lucian

On Tue, Jun 24, 2014 at 10:09:48PM +0200, Frank T. Bergmann wrote:
> > 
> > So, are you saying that we still need a DiffusionCoefficient that
> references a
> > single axis?  In that case, what if, instead of allowing it to have either
> zero or
> > two children, we also allowed it to have one?
> > 
> 
> Indeed, and that is what we have in the current implementation in libSBML.
> (and what we had in the spec that was the word document back in the day).
> And what is required for a species to have different diffusion coefficients
> for the different components. 
> 
> > (The reason I made them children instead of attributes is because with
> > children, if something is missing, it's more clear tht it means, "it
> doesn't have
> > one" instead of "it might have one, but it's not defined".
> > This goes with the whole 'no defaults' policty of SBML L3.)
> > 
> 
> I don't think that is enough of a reason. Look at the point definition for
> example, you have one required coordinate, and two optional ones. The same
> would have worked here, except of course that it would seem all three are
> optional, and the key to validating them is the new type attribute. 
> 
> That can work for me, 
> Frank
> 
> > -Lucian
> > 
> > On Tue, Jun 24, 2014 at 08:28:38PM +0200, Frank T. Bergmann wrote:
> > > We still need to be able to define a different diffusion coefficients
> though.
> > As it is it is not possible to descript anisotropic diffusion in 2D
> anymore (that
> > are frequently used for example like in the attached form).
> > >
> > >
> > >
> > > Maybe you would need to add another type ???anisotropic??? that defines
> > one coordinateIndex (or rather the ComponentKind/ SpidRef) for a species.
> > Of those there then can be one diffusion coefficient per species and
> > ComponentKind.
> > >
> > >
> > >
> > > Thank you
> > >
> > > Frank
> > >
> > >
> > >
> > > From: Lucian Smith [mailto:luc...@gm...]
> > > Sent: Tuesday, June 24, 2014 7:49 PM
> > > To: The SBML L3 Spatial Processes and Geometries package discussion
> > > list
> > > Subject: [sbml-spatial] Fwd: Edits to the SBML spatial specification -
> > > DIFFUSION ONLY
> > >
> > >
> > >
> > > Here's the email from Jim I got a while back that describes what the
> > thinking was behind the changes to diffusion.  Comments welcome!
> > >
> > >
> > >
> > > -Lucian
> > >
> > > ---------- Forwarded message ----------
> > > From: Schaff,Jim <sc...@ne...
> > > <mailto:sc...@ne...> >
> > > Date: Mon, Oct 7, 2013 at 10:59 AM
> > > Subject: RE: Edits to the SBML spatial specification - DIFFUSION ONLY
> > > To: Michael Hucka <mh...@ca... <mailto:mh...@ca...> >
> > > Cc: "lpsmith@u.washington.edu <mailto:lpsmith@u.washington.edu> "
> > > <lpsmith@u.washington.edu <mailto:lpsmith@u.washington.edu> >
> > >
> > >
> > > Hi Mike and Lucian,
> > >
> > > The response for Diffusion is complicated all by itself ... so I'm going
> to
> > include it here separately.
> > >
> > >
> > > Section 3.10 The DiffusionCoefficient class
> > >
> > > 1) DiffusionCoefficient <CAN> change in time.
> > >
> > > 2) DiffusionCoefficient needs a type attribute "isotropic" or "tensor".
> > ("isotropic" doesn't need any coordinate index, and tensor needs two
> > coordinate indices coordinateIndex1 and coordinateIndex2 with a constraint
> > that Diffusion(i,j) = Diffusion(j,i).
> > >       Or make a DiffusionCoefficient class and a DiffusionTensor class.
> > >
> > > 3) The diffusion coefficient is a physical constant that is independent
> of the
> > dimension and should always be expressed as length^2/time (L2/T) with the
> > default length units and the default time units.
> > >
> > > NOW ... DISCUSSION OF DIFFUSION, and SPATIAL MAPPING in general:
> > > ======================================================
> > >
> > > Let's use a function notation for units;  define unit(C) as the "unit of
> C".
> > >
> > > The appropriate equation to consider for continuous diffusion (works
> > > for stochastic as well) is the Flux Density due to diffusion (J = D *
> > gradient(C)) Always the flux density is equal to the diffusion coefficient
> times
> > the gradient of the concentration.
> > > Note that gradient is the first derivative in space ... and so
> unit(gradient(C))
> > = 1/L*unit(C).
> > >
> > > 3D domain case:      J [molecules.um-2.s-1] = D [um2.s-1] * grad(C)
> [um-1 *
> > molecules.um-3]
> > > 2D domain case:      J [molecules.um-1.s-1] = D [um2.s-1] * grad(C)
> [um-1 *
> > molecules.um-2]
> > > 1D domain case:      J [molecules.s-1] = D [um2.s-1] * grad(C) [um-1 *
> > molecules.um-1]
> > > 0D domain case: (undefined)
> > >
> > > MORE ABOUT SPATIAL UNITS:
> > > =======================
> > >
> > > Now, the unit of the mapped species variable (concentration or surface
> > density or linear density) comes from the unit of the SBML Core species in
> its
> > Compartment multiplied by the unit of the CompartmentMapping.
> > >
> > > Example: suppose you map a membrane (2D Compartment) to a 3D
> > DomainType (like the plasma membrane mapped to a 3D continuum of tissue
> > in a 3D geometry ... slab of cells which are not spatially resolved).
> > > 1) The membrane species "receptor" has units of
> > > SBML_substance/SBML_area
> > > 2) The compartmentMapping for "plasmaMembrane" has units of
> > > SBML_area/SBML_volume
> > > 3) The product of (1) and (2), the "mapped" species variable (to coin a
> > phrase) has units of SBML_substance/SBML_volume.
> > >
> > > In general, each "mapped species variable" always has dimensions of the
> > mathematical framework 1D, 2D, 3D (maybe different from the physical
> > dimension). ... it is really a frame of reference ...when seen from the
> Slab of
> > Cells, the membrane receptor has a volumetric concentration ... but also
> has
> > a local surface density within the distributed membrane compartment.
> > >
> > > Maybe we need some text that generally explains this.
> > >
> > > Jim.
> > >
> > 
> > 
> > > ----------------------------------------------------------------------
> > > -------- Open source business process management suite built on Java
> > > and Eclipse Turn processes into business applications with Bonita BPM
> > > Community Edition Quickly connect people, data, and systems into
> > > organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > > http://p.sf.net/sfu/Bonitasoft
> > > _______________________________________________
> > > sbml-spatial mailing list
> > > sbm...@li...
> > > https://lists.sourceforge.net/lists/listinfo/sbml-spatial
> > 
> > 
> >
> ----------------------------------------------------------------------------
> --
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community
> > Edition Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > sbml-spatial mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbml-spatial
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial

> 
> So, are you saying that we still need a DiffusionCoefficient that
references a
> single axis?  In that case, what if, instead of allowing it to have either
zero or
> two children, we also allowed it to have one?
> 

Indeed, and that is what we have in the current implementation in libSBML.
(and what we had in the spec that was the word document back in the day).
And what is required for a species to have different diffusion coefficients
for the different components. 

> (The reason I made them children instead of attributes is because with
> children, if something is missing, it's more clear tht it means, "it
doesn't have
> one" instead of "it might have one, but it's not defined".
> This goes with the whole 'no defaults' policty of SBML L3.)
> 

I don't think that is enough of a reason. Look at the point definition for
example, you have one required coordinate, and two optional ones. The same
would have worked here, except of course that it would seem all three are
optional, and the key to validating them is the new type attribute. 

That can work for me, 
Frank

> -Lucian
> 
> On Tue, Jun 24, 2014 at 08:28:38PM +0200, Frank T. Bergmann wrote:
> > We still need to be able to define a different diffusion coefficients
though.
> As it is it is not possible to descript anisotropic diffusion in 2D
anymore (that
> are frequently used for example like in the attached form).
> >
> >
> >
> > Maybe you would need to add another type ???anisotropic??? that defines
> one coordinateIndex (or rather the ComponentKind/ SpidRef) for a species.
> Of those there then can be one diffusion coefficient per species and
> ComponentKind.
> >
> >
> >
> > Thank you
> >
> > Frank
> >
> >
> >
> > From: Lucian Smith [mailto:luc...@gm...]
> > Sent: Tuesday, June 24, 2014 7:49 PM
> > To: The SBML L3 Spatial Processes and Geometries package discussion
> > list
> > Subject: [sbml-spatial] Fwd: Edits to the SBML spatial specification -
> > DIFFUSION ONLY
> >
> >
> >
> > Here's the email from Jim I got a while back that describes what the
> thinking was behind the changes to diffusion.  Comments welcome!
> >
> >
> >
> > -Lucian
> >
> > ---------- Forwarded message ----------
> > From: Schaff,Jim <sc...@ne...
> > <mailto:sc...@ne...> >
> > Date: Mon, Oct 7, 2013 at 10:59 AM
> > Subject: RE: Edits to the SBML spatial specification - DIFFUSION ONLY
> > To: Michael Hucka <mh...@ca... <mailto:mh...@ca...> >
> > Cc: "lpsmith@u.washington.edu <mailto:lpsmith@u.washington.edu> "
> > <lpsmith@u.washington.edu <mailto:lpsmith@u.washington.edu> >
> >
> >
> > Hi Mike and Lucian,
> >
> > The response for Diffusion is complicated all by itself ... so I'm going
to
> include it here separately.
> >
> >
> > Section 3.10 The DiffusionCoefficient class
> >
> > 1) DiffusionCoefficient <CAN> change in time.
> >
> > 2) DiffusionCoefficient needs a type attribute "isotropic" or "tensor".
> ("isotropic" doesn't need any coordinate index, and tensor needs two
> coordinate indices coordinateIndex1 and coordinateIndex2 with a constraint
> that Diffusion(i,j) = Diffusion(j,i).
> >       Or make a DiffusionCoefficient class and a DiffusionTensor class.
> >
> > 3) The diffusion coefficient is a physical constant that is independent
of the
> dimension and should always be expressed as length^2/time (L2/T) with the
> default length units and the default time units.
> >
> > NOW ... DISCUSSION OF DIFFUSION, and SPATIAL MAPPING in general:
> > ======================================================
> >
> > Let's use a function notation for units;  define unit(C) as the "unit of
C".
> >
> > The appropriate equation to consider for continuous diffusion (works
> > for stochastic as well) is the Flux Density due to diffusion (J = D *
> gradient(C)) Always the flux density is equal to the diffusion coefficient
times
> the gradient of the concentration.
> > Note that gradient is the first derivative in space ... and so
unit(gradient(C))
> = 1/L*unit(C).
> >
> > 3D domain case:      J [molecules.um-2.s-1] = D [um2.s-1] * grad(C)
[um-1 *
> molecules.um-3]
> > 2D domain case:      J [molecules.um-1.s-1] = D [um2.s-1] * grad(C)
[um-1 *
> molecules.um-2]
> > 1D domain case:      J [molecules.s-1] = D [um2.s-1] * grad(C) [um-1 *
> molecules.um-1]
> > 0D domain case: (undefined)
> >
> > MORE ABOUT SPATIAL UNITS:
> > =======================
> >
> > Now, the unit of the mapped species variable (concentration or surface
> density or linear density) comes from the unit of the SBML Core species in
its
> Compartment multiplied by the unit of the CompartmentMapping.
> >
> > Example: suppose you map a membrane (2D Compartment) to a 3D
> DomainType (like the plasma membrane mapped to a 3D continuum of tissue
> in a 3D geometry ... slab of cells which are not spatially resolved).
> > 1) The membrane species "receptor" has units of
> > SBML_substance/SBML_area
> > 2) The compartmentMapping for "plasmaMembrane" has units of
> > SBML_area/SBML_volume
> > 3) The product of (1) and (2), the "mapped" species variable (to coin a
> phrase) has units of SBML_substance/SBML_volume.
> >
> > In general, each "mapped species variable" always has dimensions of the
> mathematical framework 1D, 2D, 3D (maybe different from the physical
> dimension). ... it is really a frame of reference ...when seen from the
Slab of
> Cells, the membrane receptor has a volumetric concentration ... but also
has
> a local surface density within the distributed membrane compartment.
> >
> > Maybe we need some text that generally explains this.
> >
> > Jim.
> >
> 
> 
> > ----------------------------------------------------------------------
> > -------- Open source business process management suite built on Java
> > and Eclipse Turn processes into business applications with Bonita BPM
> > Community Edition Quickly connect people, data, and systems into
> > organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > sbml-spatial mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbml-spatial
> 
> 
>
----------------------------------------------------------------------------
--
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community
> Edition Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial

  I like Jim schaff's description. The clarity it brings is important, e.g. 
where a receptor or transmembrane transporter with surface density in 
moles/cm^2  combines with a molecule in the adjacent 3-d solution.
   jim b
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
James B. Bassingthwaighte, MD, PhD    email:jbb2@u.washington.edu
Prof. Bioengineering, Radiology       ph: 206-685-2012 (direct)
N210G Foege Bldg. 3720 15th Ave NE    FAX  206-685-3300
University of Washington, Box 35-5061 http://nsr.bioeng.washington.edu
Seattle, WA 98195-5061		      http://www.physiome.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Tue, 24 Jun 2014, Lucian Smith wrote:

> Date: Tue, 24 Jun 2014 10:49:25 -0700
> From: Lucian Smith <luc...@gm...>
> Reply-To: The SBML L3 Spatial Processes and Geometries package discussion list
>      <sbm...@li...>
> To: The SBML L3 Spatial Processes and Geometries package discussion list
>     <sbm...@li...>
> Subject: [sbml-spatial] Fwd: Edits to the SBML spatial specification -
>     DIFFUSION ONLY
> 
> Here's the email from Jim I got a while back that describes what the
> thinking was behind the changes to diffusion.  Comments welcome!
>
> -Lucian
>
> ---------- Forwarded message ----------
> From: Schaff,Jim <sc...@ne...>
> Date: Mon, Oct 7, 2013 at 10:59 AM
> Subject: RE: Edits to the SBML spatial specification - DIFFUSION ONLY
> To: Michael Hucka <mh...@ca...>
> Cc: "lpsmith@u.washington.edu" <lpsmith@u.washington.edu>
>
>
> Hi Mike and Lucian,
>
> The response for Diffusion is complicated all by itself ... so I'm going to
> include it here separately.
>
>
> Section 3.10 The DiffusionCoefficient class
>
> 1) DiffusionCoefficient <CAN> change in time.
>
> 2) DiffusionCoefficient needs a type attribute "isotropic" or "tensor".
> ("isotropic" doesn't need any coordinate index, and tensor needs two
> coordinate indices coordinateIndex1 and coordinateIndex2 with a constraint
> that Diffusion(i,j) = Diffusion(j,i).
>      Or make a DiffusionCoefficient class and a DiffusionTensor class.
>
> 3) The diffusion coefficient is a physical constant that is independent of
> the dimension and should always be expressed as length^2/time (L2/T) with
> the default length units and the default time units.
>
> NOW ... DISCUSSION OF DIFFUSION, and SPATIAL MAPPING in general:
> ======================================================
>
> Let's use a function notation for units;  define unit(C) as the "unit of C".
>
> The appropriate equation to consider for continuous diffusion (works for
> stochastic as well) is the Flux Density due to diffusion (J = D *
> gradient(C))
> Always the flux density is equal to the diffusion coefficient times the
> gradient of the concentration.
> Note that gradient is the first derivative in space ... and so
> unit(gradient(C)) = 1/L*unit(C).
>
> 3D domain case:      J [molecules.um-2.s-1] = D [um2.s-1] * grad(C) [um-1 *
> molecules.um-3]
> 2D domain case:      J [molecules.um-1.s-1] = D [um2.s-1] * grad(C) [um-1 *
> molecules.um-2]
> 1D domain case:      J [molecules.s-1] = D [um2.s-1] * grad(C) [um-1 *
> molecules.um-1]
> 0D domain case: (undefined)
>
> MORE ABOUT SPATIAL UNITS:
> =======================
>
> Now, the unit of the mapped species variable (concentration or surface
> density or linear density) comes from the unit of the SBML Core species in
> its Compartment multiplied by the unit of the CompartmentMapping.
>
> Example: suppose you map a membrane (2D Compartment) to a 3D DomainType
> (like the plasma membrane mapped to a 3D continuum of tissue in a 3D
> geometry ... slab of cells which are not spatially resolved).
> 1) The membrane species "receptor" has units of SBML_substance/SBML_area
> 2) The compartmentMapping for "plasmaMembrane" has units of
> SBML_area/SBML_volume
> 3) The product of (1) and (2), the "mapped" species variable (to coin a
> phrase) has units of SBML_substance/SBML_volume.
>
> In general, each "mapped species variable" always has dimensions of the
> mathematical framework 1D, 2D, 3D (maybe different from the physical
> dimension). ... it is really a frame of reference ...when seen from the
> Slab of Cells, the membrane receptor has a volumetric concentration ... but
> also has a local surface density within the distributed membrane
> compartment.
>
> Maybe we need some text that generally explains this.
>
> Jim.
>

To describe anisotropic diffusion, don't you need a diffusion matrix? 3x3 for 3D and 2x2 for 2D. 


On Jun 24, 2014, at 3:13 PM, Lucian Smith wrote:

> So, are you saying that we still need a DiffusionCoefficient that 
> references a single axis?  In that case, what if, instead of allowing it 
> to have either zero or two children, we also allowed it to have one?
> 
> (The reason I made them children instead of attributes is because with 
> children, if something is missing, it's more clear tht it means, "it 
> doesn't have one" instead of "it might have one, but it's not defined".  
> This goes with the whole 'no defaults' policty of SBML L3.)
> 
> -Lucian
> 
> On Tue, Jun 24, 2014 at 08:28:38PM +0200, Frank T. Bergmann wrote:
>> We still need to be able to define a different diffusion coefficients though. As it is it is not possible to descript anisotropic diffusion in 2D anymore (that are frequently used for example like in the attached form). 
>> 
>> 
>> 
>> Maybe you would need to add another type ???anisotropic??? that defines one coordinateIndex (or rather the ComponentKind/ SpidRef) for a species. Of those there then can be one diffusion coefficient per species and ComponentKind. 
>> 
>> 
>> 
>> Thank you
>> 
>> Frank
>> 
>> 
>> 
>> From: Lucian Smith [mailto:luc...@gm...] 
>> Sent: Tuesday, June 24, 2014 7:49 PM
>> To: The SBML L3 Spatial Processes and Geometries package discussion list
>> Subject: [sbml-spatial] Fwd: Edits to the SBML spatial specification - DIFFUSION ONLY
>> 
>> 
>> 
>> Here's the email from Jim I got a while back that describes what the thinking was behind the changes to diffusion.  Comments welcome!
>> 
>> 
>> 
>> -Lucian
>> 
>> ---------- Forwarded message ----------
>> From: Schaff,Jim <sc...@ne... <mailto:sc...@ne...> >
>> Date: Mon, Oct 7, 2013 at 10:59 AM
>> Subject: RE: Edits to the SBML spatial specification - DIFFUSION ONLY
>> To: Michael Hucka <mh...@ca... <mailto:mh...@ca...> >
>> Cc: "lpsmith@u.washington.edu <mailto:lpsmith@u.washington.edu> " <lpsmith@u.washington.edu <mailto:lpsmith@u.washington.edu> >
>> 
>> 
>> Hi Mike and Lucian,
>> 
>> The response for Diffusion is complicated all by itself ... so I'm going to include it here separately.
>> 
>> 
>> Section 3.10 The DiffusionCoefficient class
>> 
>> 1) DiffusionCoefficient <CAN> change in time.
>> 
>> 2) DiffusionCoefficient needs a type attribute "isotropic" or "tensor".  ("isotropic" doesn't need any coordinate index, and tensor needs two coordinate indices coordinateIndex1 and coordinateIndex2 with a constraint that Diffusion(i,j) = Diffusion(j,i).
>>      Or make a DiffusionCoefficient class and a DiffusionTensor class.
>> 
>> 3) The diffusion coefficient is a physical constant that is independent of the dimension and should always be expressed as length^2/time (L2/T) with the default length units and the default time units.
>> 
>> NOW ... DISCUSSION OF DIFFUSION, and SPATIAL MAPPING in general:
>> ======================================================
>> 
>> Let's use a function notation for units;  define unit(C) as the "unit of C".
>> 
>> The appropriate equation to consider for continuous diffusion (works for stochastic as well) is the Flux Density due to diffusion (J = D * gradient(C))
>> Always the flux density is equal to the diffusion coefficient times the gradient of the concentration.
>> Note that gradient is the first derivative in space ... and so unit(gradient(C)) = 1/L*unit(C).
>> 
>> 3D domain case:      J [molecules.um-2.s-1] = D [um2.s-1] * grad(C) [um-1 * molecules.um-3]
>> 2D domain case:      J [molecules.um-1.s-1] = D [um2.s-1] * grad(C) [um-1 * molecules.um-2]
>> 1D domain case:      J [molecules.s-1] = D [um2.s-1] * grad(C) [um-1 * molecules.um-1]
>> 0D domain case: (undefined)
>> 
>> MORE ABOUT SPATIAL UNITS:
>> =======================
>> 
>> Now, the unit of the mapped species variable (concentration or surface density or linear density) comes from the unit of the SBML Core species in its Compartment multiplied by the unit of the CompartmentMapping.
>> 
>> Example: suppose you map a membrane (2D Compartment) to a 3D DomainType (like the plasma membrane mapped to a 3D continuum of tissue in a 3D geometry ... slab of cells which are not spatially resolved).
>> 1) The membrane species "receptor" has units of SBML_substance/SBML_area
>> 2) The compartmentMapping for "plasmaMembrane" has units of SBML_area/SBML_volume
>> 3) The product of (1) and (2), the "mapped" species variable (to coin a phrase) has units of SBML_substance/SBML_volume.
>> 
>> In general, each "mapped species variable" always has dimensions of the mathematical framework 1D, 2D, 3D (maybe different from the physical dimension). ... it is really a frame of reference ...when seen from the Slab of Cells, the membrane receptor has a volumetric concentration ... but also has a local surface density within the distributed membrane compartment.
>> 
>> Maybe we need some text that generally explains this.
>> 
>> Jim.
>> 
> 
> 
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> sbml-spatial mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial

So, are you saying that we still need a DiffusionCoefficient that 
references a single axis?  In that case, what if, instead of allowing it 
to have either zero or two children, we also allowed it to have one?

(The reason I made them children instead of attributes is because with 
children, if something is missing, it's more clear tht it means, "it 
doesn't have one" instead of "it might have one, but it's not defined".  
This goes with the whole 'no defaults' policty of SBML L3.)

-Lucian

On Tue, Jun 24, 2014 at 08:28:38PM +0200, Frank T. Bergmann wrote:
> We still need to be able to define a different diffusion coefficients though. As it is it is not possible to descript anisotropic diffusion in 2D anymore (that are frequently used for example like in the attached form). 
> 
>  
> 
> Maybe you would need to add another type ???anisotropic??? that defines one coordinateIndex (or rather the ComponentKind/ SpidRef) for a species. Of those there then can be one diffusion coefficient per species and ComponentKind. 
> 
>  
> 
> Thank you
> 
> Frank
> 
>  
> 
> From: Lucian Smith [mailto:luc...@gm...] 
> Sent: Tuesday, June 24, 2014 7:49 PM
> To: The SBML L3 Spatial Processes and Geometries package discussion list
> Subject: [sbml-spatial] Fwd: Edits to the SBML spatial specification - DIFFUSION ONLY
> 
>  
> 
> Here's the email from Jim I got a while back that describes what the thinking was behind the changes to diffusion.  Comments welcome!
> 
>  
> 
> -Lucian
> 
> ---------- Forwarded message ----------
> From: Schaff,Jim <sc...@ne... <mailto:sc...@ne...> >
> Date: Mon, Oct 7, 2013 at 10:59 AM
> Subject: RE: Edits to the SBML spatial specification - DIFFUSION ONLY
> To: Michael Hucka <mh...@ca... <mailto:mh...@ca...> >
> Cc: "lpsmith@u.washington.edu <mailto:lpsmith@u.washington.edu> " <lpsmith@u.washington.edu <mailto:lpsmith@u.washington.edu> >
> 
> 
> Hi Mike and Lucian,
> 
> The response for Diffusion is complicated all by itself ... so I'm going to include it here separately.
> 
> 
> Section 3.10 The DiffusionCoefficient class
> 
> 1) DiffusionCoefficient <CAN> change in time.
> 
> 2) DiffusionCoefficient needs a type attribute "isotropic" or "tensor".  ("isotropic" doesn't need any coordinate index, and tensor needs two coordinate indices coordinateIndex1 and coordinateIndex2 with a constraint that Diffusion(i,j) = Diffusion(j,i).
>       Or make a DiffusionCoefficient class and a DiffusionTensor class.
> 
> 3) The diffusion coefficient is a physical constant that is independent of the dimension and should always be expressed as length^2/time (L2/T) with the default length units and the default time units.
> 
> NOW ... DISCUSSION OF DIFFUSION, and SPATIAL MAPPING in general:
> ======================================================
> 
> Let's use a function notation for units;  define unit(C) as the "unit of C".
> 
> The appropriate equation to consider for continuous diffusion (works for stochastic as well) is the Flux Density due to diffusion (J = D * gradient(C))
> Always the flux density is equal to the diffusion coefficient times the gradient of the concentration.
> Note that gradient is the first derivative in space ... and so unit(gradient(C)) = 1/L*unit(C).
> 
> 3D domain case:      J [molecules.um-2.s-1] = D [um2.s-1] * grad(C) [um-1 * molecules.um-3]
> 2D domain case:      J [molecules.um-1.s-1] = D [um2.s-1] * grad(C) [um-1 * molecules.um-2]
> 1D domain case:      J [molecules.s-1] = D [um2.s-1] * grad(C) [um-1 * molecules.um-1]
> 0D domain case: (undefined)
> 
> MORE ABOUT SPATIAL UNITS:
> =======================
> 
> Now, the unit of the mapped species variable (concentration or surface density or linear density) comes from the unit of the SBML Core species in its Compartment multiplied by the unit of the CompartmentMapping.
> 
> Example: suppose you map a membrane (2D Compartment) to a 3D DomainType (like the plasma membrane mapped to a 3D continuum of tissue in a 3D geometry ... slab of cells which are not spatially resolved).
> 1) The membrane species "receptor" has units of SBML_substance/SBML_area
> 2) The compartmentMapping for "plasmaMembrane" has units of SBML_area/SBML_volume
> 3) The product of (1) and (2), the "mapped" species variable (to coin a phrase) has units of SBML_substance/SBML_volume.
> 
> In general, each "mapped species variable" always has dimensions of the mathematical framework 1D, 2D, 3D (maybe different from the physical dimension). ... it is really a frame of reference ...when seen from the Slab of Cells, the membrane receptor has a volumetric concentration ... but also has a local surface density within the distributed membrane compartment.
> 
> Maybe we need some text that generally explains this.
> 
> Jim.
> 


> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial

One thing that I see is missing from the specification is a way to specify a stiffness tensor for each element. 

In general, the stiffness tensor may be time dependent, so ideally, there should be a way to specify an expression for each element which calculates the stiffness tensor. 

I'm sure there are other ways to specify it, but each expression could return an array, specified by the arrays package. 

Here's the email from Jim I got a while back that describes what the
thinking was behind the changes to diffusion.  Comments welcome!

-Lucian

---------- Forwarded message ----------
From: Schaff,Jim <sc...@ne...>
Date: Mon, Oct 7, 2013 at 10:59 AM
Subject: RE: Edits to the SBML spatial specification - DIFFUSION ONLY
To: Michael Hucka <mh...@ca...>
Cc: "lpsmith@u.washington.edu" <lpsmith@u.washington.edu>


Hi Mike and Lucian,

The response for Diffusion is complicated all by itself ... so I'm going to
include it here separately.


Section 3.10 The DiffusionCoefficient class

1) DiffusionCoefficient <CAN> change in time.

2) DiffusionCoefficient needs a type attribute "isotropic" or "tensor".
 ("isotropic" doesn't need any coordinate index, and tensor needs two
coordinate indices coordinateIndex1 and coordinateIndex2 with a constraint
that Diffusion(i,j) = Diffusion(j,i).
      Or make a DiffusionCoefficient class and a DiffusionTensor class.

3) The diffusion coefficient is a physical constant that is independent of
the dimension and should always be expressed as length^2/time (L2/T) with
the default length units and the default time units.

NOW ... DISCUSSION OF DIFFUSION, and SPATIAL MAPPING in general:
======================================================

Let's use a function notation for units;  define unit(C) as the "unit of C".

The appropriate equation to consider for continuous diffusion (works for
stochastic as well) is the Flux Density due to diffusion (J = D *
gradient(C))
Always the flux density is equal to the diffusion coefficient times the
gradient of the concentration.
Note that gradient is the first derivative in space ... and so
unit(gradient(C)) = 1/L*unit(C).

3D domain case:      J [molecules.um-2.s-1] = D [um2.s-1] * grad(C) [um-1 *
molecules.um-3]
2D domain case:      J [molecules.um-1.s-1] = D [um2.s-1] * grad(C) [um-1 *
molecules.um-2]
1D domain case:      J [molecules.s-1] = D [um2.s-1] * grad(C) [um-1 *
molecules.um-1]
0D domain case: (undefined)

MORE ABOUT SPATIAL UNITS:
=======================

Now, the unit of the mapped species variable (concentration or surface
density or linear density) comes from the unit of the SBML Core species in
its Compartment multiplied by the unit of the CompartmentMapping.

Example: suppose you map a membrane (2D Compartment) to a 3D DomainType
(like the plasma membrane mapped to a 3D continuum of tissue in a 3D
geometry ... slab of cells which are not spatially resolved).
1) The membrane species "receptor" has units of SBML_substance/SBML_area
2) The compartmentMapping for "plasmaMembrane" has units of
SBML_area/SBML_volume
3) The product of (1) and (2), the "mapped" species variable (to coin a
phrase) has units of SBML_substance/SBML_volume.

In general, each "mapped species variable" always has dimensions of the
mathematical framework 1D, 2D, 3D (maybe different from the physical
dimension). ... it is really a frame of reference ...when seen from the
Slab of Cells, the membrane receptor has a volumetric concentration ... but
also has a local surface density within the distributed membrane
compartment.

Maybe we need some text that generally explains this.

Jim.

> 
> Let me see if I understand this in general:  is the idea that we are setting a boundary condition either for where the Domain intersects the actual boundary of the simulation (i.e. the edge of an axis), in which case we use the 'coordinateBoundary' attribute, or for the edges of the Domain that do *not* hit the edge of the simulation, in which case we use 'boundaryDomainType'?
> 
> If so, might this not depend not on the domain of the species in question, but on the type of domain that *borders* the species' domain?  That might account for the use of 'boundaryDomainType' as an attribute, and would indicate that its explanation would need to be updated.
> 
> However, this is all speculation; I don't personally know why the attribute is there.  It may be that for v1, we actually only want to define boundaries for the edges of the coordinate system.
> 

Ok … this needs to be sorted in the specification. Suppose we have a coordinate system from (0,0) to (50,50) and i have a analytic geometry defined from (10,10) to (30,30). Then for me the only thing that makes sense when having a boundaryCondition defined for Xmin on a species, in that domain, would be to have it apply for (x=10), certainly not for (x=0) which would be outside of the domain. The same would hold for Xmax,Ymin and Ymax, they can only apply at the borders of the species domain. 

The only advantage that I saw would be a convenience, of not having to add 4 (for 2D) boundary condition parameters separately. 

> CoordinateIndex:
> - in the advectionCoefficient, there is only an 'int' value defined for the
> index
> - whereas in the diffusionCoefficient, there are 0 or 2 elements of type
> CoordinateIndex used
> 
> In each case it would be consistent to use the enum ComponentKind (possibly
> enhanced by the value 'unset')
> 
> I agree that an int is almost certainly the least helpful option, and argue in my comments in the spec that it should be a SpIdRef to the coordinate in question instead.  Using the ComponentKind enum would also be fine with me, though I don't think 'unset' would be a helpful addition in this case.
> 

well as far as SBML is concerned the ‘unset’ case would be implied by the attribute not being set. As far as an enum in a parsing library is concerned, it might be convenient to have a value returned indicating that. If you really prefer I could live with a SpIdRef, but don’t see an advantage. But it should be consistent among the different elements.
> 
> DiffusionCoefficients:
> - in the current implementation it is possible to define diffusion
> coefficients for each coordinate separately:
> - however in the current spec, it is only possible to have 'isotropic' (same
> along all axis) or 'tensor' (same along precisely two axis)
> 
> This seems to imply that we can no longer describe what we could before.
> (Except of course
> for the case of a 2D simulation, where we could misuse the (non simulated) z
> component, for this. But that seems awkward). For me the old way seemed
> almost easier.
> 
> If I understand correctly from conversations with Jim that led to this change, the old way of defining diffusion was not actually how diffusion works, or is modeled.  However, I could be wrong about this, and would welcome more input from people who do this sort of modeling.
> 

Consider the 2D case of anisotropic diffusion. How would you define it using the ‘tensor’ construct? I don’t see it possible. If we have an example to the contrary I would be satisfied as well. 

> InteriorPoint / SpatialPoint:
> - it seems strange to have two different (entirely unrelated point classes
> in the package)
> 
> It would make sense to have only one being used in both places. My
> preference would be to use the spatialPoint (with optional SpId)
> 
> That would be fine with me.  Do we want to try to make this change right now?
> 
> Another option would be to make SpatialPoint a child class of InteriorPoint, that would add the 'id' and 'domain'.  Except I'm not actually sure we need the 'domain' attribute, anyway.  Is it there for some purpose?
>  

In both cases (InteriorPoint and SpatialPoint) the domain is also specified through the parent element. So no matter whether you leave it in or take it out, the domain will always be available. 

As for when a change like this should happen, it does not have to be now, but should happen sometime. 

> order attribute:
> - in the analyticvolume this attribute is optional,
> - in the CSGObject it is not, this seems inconsistent
> 
> as you correctly spell out in your comment in the spec this needs to be
> sorted.
> 
> My vote is to have them both optional.
>  

that works for me

> ImageData / SampleField:
> - dataType ought to be enum (and preferably be only either on the
> samplefield class or the imagedata class (where it currently seems to
> confuse datatype and compression))
> - interpolationType should be enum
> - encoding should be enum
> 
> Yup!  If you propose a list of options, I'll put them in, and that can be our starting point for further discussion.
>  

Well … we could go with the fixed strings in the spec for now, adding to it later when it becomes necessary

dataType: int32
interpolationType: constant, linear
encoding: compressed, uncompressed

with the spec stating that when the encoding is compressed the standard ‘deflate’ algorithm is to be used. 

> 
> - PolygonObject: should probably have a length attribute as well
> 
> Why does this need a length attribute?  Isn't it basically completely defined by the list of points?
> 

currently you have only an ‘pointIndex’ integer array as element. Everywhere else in the spec, when the array was given as element, there was an accompanying attribute storing the length of the elements in that array as well. This will facilitate checking for validity and so made sense to me. It also helps people to pre-allocate arrays and such. So it seemed best to be consistent. 

> Also, I just noticed that the 'pointIndex' attribute assumes a fixed order for the elements in the ListOfSpatialPoints, which we're supposed to be avoiding.  I guess we could reference them by ID instead, since the 'id' attribute of SpatialPoint is required?
> 

well, indeed referencing them via spidRefs would be possible. 

> Also, from your email the previous week:
> 
> > - currently boundary conditions in the implementation are ‘flux’ and ‘value’ … instead of changing that to ‘invwardNormalFlux’ I will go for ‘Dirichlet’ and ‘Neumann’
> >
> > @Lucian: you never send the final list of names to be used for the Robin conditions, if you could do so that would be great. 
> 
> I'm not sure what other list of names you want--are the current ones insufficient, somehow?
> 

personally, i thought ‘Robin_inwardNormalGradientCoefficient' would be a bit of a mouthful, but if you think the names of them are fine then that is OK with me. 

> > - AnalyticVolume::functionType: I thought at harmony we discussed restricting Spatial V1 to just have ‘layered’ as allowable value. (What with there being no implementation of R-function, and from the description it seems that only the sign of the R-function would be important, and so it could easily be transformed into the layered kind, so there is no loss of generality). 
> 
> I am fine with this, too, and can make the change.
> 

Thanks
Cheers
Frank

Thanks for doing this, Frank--here's my thoughts and plans:

On Mon, Jun 23, 2014 at 2:13 AM, Frank T. Bergmann <fbe...@ca...>
wrote:

> Hello all,
>
> as mentioned last week, I am in the process of updating the libSBML
> implementation of the spatial package. However, in addition to the issues
> raised last week, it would be nice to get clarification on the following
> issues:
>
> BoundaryCondition / boundaryDomainType:
> - this (newly introduced) attribute seems strange. A spatial species will
> only belong to one specific domainType,
>   so it is odd that we are here allowed to specify an arbitrary DomainType.
> It ought to be
>   the domainType for the compartment the species is in and no other.
>
> --> we could get rid of this attribute, and apply it to the domainType
> whenever no coordinateBoundary is set
>

Let me see if I understand this in general:  is the idea that we are
setting a boundary condition either for where the Domain intersects the
actual boundary of the simulation (i.e. the edge of an axis), in which case
we use the 'coordinateBoundary' attribute, or for the edges of the Domain
that do *not* hit the edge of the simulation, in which case we use
'boundaryDomainType'?

If so, might this not depend not on the domain of the species in question,
but on the type of domain that *borders* the species' domain?  That might
account for the use of 'boundaryDomainType' as an attribute, and would
indicate that its explanation would need to be updated.

However, this is all speculation; I don't personally know why the attribute
is there.  It may be that for v1, we actually only want to define
boundaries for the edges of the coordinate system.

CoordinateIndex:
> - in the advectionCoefficient, there is only an 'int' value defined for the
> index
> - whereas in the diffusionCoefficient, there are 0 or 2 elements of type
> CoordinateIndex used
>
> In each case it would be consistent to use the enum ComponentKind (possibly
> enhanced by the value 'unset')
>

I agree that an int is almost certainly the least helpful option, and argue
in my comments in the spec that it should be a SpIdRef to the coordinate in
question instead.  Using the ComponentKind enum would also be fine with me,
though I don't think 'unset' would be a helpful addition in this case.

AdjacentDomain / AdjacentDomains:
> - both spellings are used in the spec, and this ought to be sorted.
>

Looks like I just made a mistake when creating the figures--let's go with
'AdjacentDomains'.

DiffusionCoefficients:
> - in the current implementation it is possible to define diffusion
> coefficients for each coordinate separately:
> - however in the current spec, it is only possible to have 'isotropic'
> (same
> along all axis) or 'tensor' (same along precisely two axis)
>
> This seems to imply that we can no longer describe what we could before.
> (Except of course
> for the case of a 2D simulation, where we could misuse the (non simulated)
> z
> component, for this. But that seems awkward). For me the old way seemed
> almost easier.
>

If I understand correctly from conversations with Jim that led to this
change, the old way of defining diffusion was not actually how diffusion
works, or is modeled.  However, I could be wrong about this, and would
welcome more input from people who do this sort of modeling.

InteriorPoint / SpatialPoint:
> - it seems strange to have two different (entirely unrelated point classes
> in the package)
>
> It would make sense to have only one being used in both places. My
> preference would be to use the spatialPoint (with optional SpId)
>

That would be fine with me.  Do we want to try to make this change right
now?

Another option would be to make SpatialPoint a child class of
InteriorPoint, that would add the 'id' and 'domain'.  Except I'm not
actually sure we need the 'domain' attribute, anyway.  Is it there for some
purpose?


> order attribute:
> - in the analyticvolume this attribute is optional,
> - in the CSGObject it is not, this seems inconsistent
>
> as you correctly spell out in your comment in the spec this needs to be
> sorted.
>

My vote is to have them both optional.


> ImageData / SampleField:
> - dataType ought to be enum (and preferably be only either on the
> samplefield class or the imagedata class (where it currently seems to
> confuse datatype and compression))
> - interpolationType should be enum
> - encoding should be enum
>

Yup!  If you propose a list of options, I'll put them in, and that can be
our starting point for further discussion.


> Figure 17:
> - ListOfParametrcObjects: does it really need an id, polygonType and
> domain?
>   or is that a copy/paste error from ParametricObject
>

Whoops, good catch.  Yes, that's my mistake creating the figure.


> - PolygonObject: should probably have a length attribute as well
>

Why does this need a length attribute?  Isn't it basically completely
defined by the list of points?

Also, I just noticed that the 'pointIndex' attribute assumes a fixed order
for the elements in the ListOfSpatialPoints, which we're supposed to be
avoiding.  I guess we could reference them by ID instead, since the 'id'
attribute of SpatialPoint is required?

Also, from your email the previous week:

> - currently boundary conditions in the implementation are ‘flux’ and
‘value’ … instead of changing that to ‘invwardNormalFlux’ I will go for
‘Dirichlet’ and ‘Neumann’
>
> @Lucian: you never send the final list of names to be used for the Robin
conditions, if you could do so that would be great.

I'm not sure what other list of names you want--are the current ones
insufficient, somehow?

> - AnalyticVolume::functionType: I thought at harmony we discussed
restricting Spatial V1 to just have ‘layered’ as allowable value. (What
with there being no implementation of R-function, and from the description
it seems that only the sign of the R-function would be important, and so it
could easily be transformed into the layered kind, so there is no loss of
generality).

I am fine with this, too, and can make the change.

-Lucian

Hello all, 

as mentioned last week, I am in the process of updating the libSBML
implementation of the spatial package. However, in addition to the issues
raised last week, it would be nice to get clarification on the following
issues: 

BoundaryCondition / boundaryDomainType: 
- this (newly introduced) attribute seems strange. A spatial species will
only belong to one specific domainType, 
  so it is odd that we are here allowed to specify an arbitrary DomainType.
It ought to be 
  the domainType for the compartment the species is in and no other. 
  
--> we could get rid of this attribute, and apply it to the domainType
whenever no coordinateBoundary is set

CoordinateIndex: 
- in the advectionCoefficient, there is only an 'int' value defined for the
index
- whereas in the diffusionCoefficient, there are 0 or 2 elements of type
CoordinateIndex used

In each case it would be consistent to use the enum ComponentKind (possibly
enhanced by the value 'unset')

AdjacentDomain / AdjacentDomains: 
- both spellings are used in the spec, and this ought to be sorted. 

DiffusionCoefficients: 
- in the current implementation it is possible to define diffusion
coefficients for each coordinate separately:
- however in the current spec, it is only possible to have 'isotropic' (same
along all axis) or 'tensor' (same along precisely two axis)

This seems to imply that we can no longer describe what we could before.
(Except of course
for the case of a 2D simulation, where we could misuse the (non simulated) z
component, for this. But that seems awkward). For me the old way seemed
almost easier. 

InteriorPoint / SpatialPoint:
- it seems strange to have two different (entirely unrelated point classes
in the package)

It would make sense to have only one being used in both places. My
preference would be to use the spatialPoint (with optional SpId)

order attribute: 
- in the analyticvolume this attribute is optional, 
- in the CSGObject it is not, this seems inconsistent

as you correctly spell out in your comment in the spec this needs to be
sorted. 

ImageData / SampleField: 
- dataType ought to be enum (and preferably be only either on the
samplefield class or the imagedata class (where it currently seems to
confuse datatype and compression))
- interpolationType should be enum
- encoding should be enum

Figure 17: 
- ListOfParametrcObjects: does it really need an id, polygonType and domain?
  or is that a copy/paste error from ParametricObject
- PolygonObject: should probably have a length attribute as well

Thanks, 
Frank

Hi People who might be using the requiredElements package

As you will be aware the specification for this package has changed 
dramatically since it's first inception. Up until now libSBML has 
implemented support for the old specification but the next release of 
libSBML will update to support the new version.

** This will break people's code **

Whilst looking at the libsbml code I noticed that there were some file 
name inconsistencies; this presents me with a dilemma. I have two options.

Option 1: I change the filenames to be consistent. This will be a very 
obvious break in existing code; and so easy for developers to notice !

Option 2: I leave the names as-is. It would then be seamless for a 
developer to extract the req code archive for either the old 
specification (libsbml-5.10.0) or that latest specification (will be 
libsbml-5.10.2) and create a libsbml build with whichever specification 
they are currently working with. With Option 1 this would involve 
possibly needing to remove some files.

Whilst it is best that developers update to the latest versions of 
specifications, we acknowledge that this can take time. So there are 
advantages/disadvantages to either option.

I'd be grateful for any opinions.

Thanks

Sarah

Hello all, 

I just wanted to let you know that about next week I will finally get to update the implementation of the Spatial Package in libSBML. This will be based on the 0.86 version of the spec together with the changes we agreed on here in the list: 

- the ‘spatialId’ attribute will be called ‘id’ (the new version will still have the setSpatialId/getSpatialId calls, but refer them to the set/getId ones for now, so nothing breaks badly)
- currently boundary conditions in the implementation are ‘flux’ and ‘value’ … instead of changing that to ‘invwardNormalFlux’ I will go for ‘Dirichlet’ and ‘Neumann’

@Lucian: you never send the final list of names to be used for the Robin conditions, if you could do so that would be great. 

There are a couple of things that have not been resolved yet: 

- AdvectionCoefficient::coordinateIndex and DiffusionCoefficient::coordinateIndex. Since we dropped the index from the CoordinateComponent, making it a componentType there, i think we ought to also make it a ComponentKind on Advection/DiffusionCoefficient. I know that Lucian argues for a SpidRef to the CoordinateComponent, and we need to come to a conclusion on that. 

- AnalyticVolume::functionType: I thought at harmony we discussed restricting Spatial V1 to just have ‘layered’ as allowable value. (What with there being no implementation of R-function, and from the description it seems that only the sign of the R-function would be important, and so it could easily be transformed into the layered kind, so there is no loss of generality). 

It would be perfect if we could get some more feedback on that. Otherwise it will go in with a need to change it again later :)

Cheers and all the best
Frank