Menu
▾
▴
sbml-spatial — The SBML L3 Spatial Processes package discussion list
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(11) |
Jul
(32) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(23) |
| 2014 |
Jan
(12) |
Feb
|
Mar
(1) |
Apr
(4) |
May
(17) |
Jun
(14) |
Jul
(3) |
Aug
(26) |
Sep
(100) |
Oct
(42) |
Nov
(15) |
Dec
(6) |
| 2015 |
Jan
(3) |
Feb
|
Mar
(19) |
Apr
(4) |
May
(9) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(22) |
Dec
(22) |
| 2017 |
Jan
(5) |
Feb
(4) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(1) |
Feb
(4) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(12) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(6) |
Dec
(1) |
| 2020 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
(6) |
Jun
(4) |
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(1) |
Jun
|
Jul
(8) |
Aug
(3) |
Sep
|
Oct
(7) |
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
|
2
(3) |
3
(13) |
4
(12) |
5
(14) |
6
(5) |
|
7
|
8
(2) |
9
(1) |
10
|
11
(6) |
12
|
13
|
|
14
|
15
|
16
(1) |
17
(1) |
18
|
19
|
20
|
|
21
|
22
(1) |
23
|
24
(1) |
25
|
26
|
27
|
|
28
|
29
(16) |
30
(24) |
|
|
|
|
|
From: Weatherby,Gerard <gwe...@uc...> - 2014-09-30 20:12:19
|
I don’t expect a human to ever have write this, but sooner or later someone is likely to have to debug it when it doesn’t work perfectly. It’s one of the reasons for using XML (http://www.w3.org/TR/2008/REC-xml-20081126/#sec-origin-goals ), especially #6, XML documents should be human-legible and reasonably clear ). For that reason, if we’re going to put delimiters in the spec they should be required. On unixy system at least, large text documents are fairly manageable (less, grep, vi, sed ,et. al) -Gerard From: Lucian Smith [mailto:luc...@gm...] Sent: Tuesday, September 30, 2014 3:29 PM To: The SBML L3 Spatial Processes and Geometries package discussion list Subject: Re: [sbml-spatial] Examples? (array data) On Tue, Sep 30, 2014 at 11:45 AM, Frank T. Bergmann <fbe...@ca...<mailto:fbe...@ca...>> wrote: Sorry for coming late to the party, there are too many emails to reply, so I’m choosing just a couple of them. Here Lucian asks about my opinion, so this seemed as good as any to reply: - I prefer not to use delimiters (other than whitespace) at all, the white space is what we use to separate one number from another, and that is all that is needed. Would you object to a semicolon as an optional delimiter, treating it as the equivalent of whitespace, for smaller example models that *could* be read by humans? I think people are interested in using it in the ParametricData lists, not so much the SampledField class. As you say, that data is just linearized 2D or 3D data, with each dimension being probably very long; in contrast, the SpatialPoints and ParametricData classes are grouped lists of 3 or 4 data points, where it makes more visual sense to distinguish them from each other. -Lucian - This data is not data a human will ever write. And most often it will be there in compressed form, so there it won’t mean anything if you have three consecutive numbers (talking about the sampleddata here) they don’t represent points as such, they just represent three bytes of compressed data. - Even if the data is not compressed, it is going to be a linearized two or three dimensional array. The dimensionality comes out of the numSamples attributes later on. Cheers Frank From: Lucian Smith [mailto:luc...@gm...<mailto:luc...@gm...>] Sent: Tuesday, September 30, 2014 7:33 PM To: The SBML L3 Spatial Processes and Geometries package discussion list Subject: Re: [sbml-spatial] Examples? (array data) I would be fine with delimiters; if we went with the attribute-defined delimiter route ('delimiter=";"'), would we be OK with blank delimiters? (delimiter="" or delimiter=" " ?) Or other whitespace delimiters? Also, Frank, since you're on the implementation side of things here, would adding delimiters be straightforward to implement? Do you have an opinion about using them here? -Lucian On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...<mailto:gwe...@uc...>> wrote: If the general SBML standard is only say things once (normalized data), then I’m for sticking with that rather than doing things differently in different places. But I’m definitely for delimiters, either standardized or specified by attribute as suggested in another reply. -Gerard From: Lucian Smith [mailto:luc...@gm...<mailto:luc...@gm...>] Sent: Monday, September 29, 2014 9:13 PM To: The SBML L3 Spatial Processes and Geometries package discussion list Subject: Re: [sbml-spatial] Examples? Trying to not miss the other topics in this discussion... On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...<mailto:de...@cm...>> wrote: Hi all, Sorry for the delay in response. Thanks a lot to Lucian for his work looking over those examples. I am remaking my scripts for the models at the moment. Although slightly annoying, I think it's ok to have to look up the dimensionality elsewhere in the document. I'm in favor of not adding a separate redundant field to the geometry object, unless it's not redundant. Do we expect to have instances where there are 2 and 3D structures? In that case I guess having a dimensionality would be good for each object. Thoughts? Is there any reason we can't just keep the semicolons? That option might work too. Gerard's comments on this were: > I’d advocate for, a minimum, semi-colon separators, and I’d be in favor a redundant dimensions attribute (2,3, et. al.) so the human reader, who can only view a portion of SBML document, knows what they are looking at. So, that's two votes for semicolons, and one vote for a redundant dimensions attribute and one vote against a redundant dimensions attribute. Anyone else want to weigh in? The trade-off on the dimensions attribute is that if you don't include it, you have to look up the information elsewhere, which might be inconvenient, but that information is only defined once. If you do include it, you then have the information locally, but add another possibility of creating an invalid/inconsistent model. SBML core has gone different ways on this for different situations, but tends towards trying to only define things once. But I'm happy to go either way on this. As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because that's what I last had VCell using. If this is still true, I suggest we all change over to what is in the spec and my new files will reflect that. Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) another option in your program, and do you find it useful if so? On the rotation issue, one thing I noticed is that I'm using "rotationAxisX" rather than "rotateX" for the naming convention. Both are in the spec with the prior being in the UML and the latter being in the text. Which are we going with? Thanks for noticing this! I'm personally inclined to go with the the longer name, though actually, I like 'rotationAxisX' better than 'rotateAxisX', which is what the UML actually has. Anyone else have an opinion? -Lucian ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ sbml-spatial mailing list sbm...@li...<mailto:sbm...@li...> https://lists.sourceforge.net/lists/listinfo/sbml-spatial ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ sbml-spatial mailing list sbm...@li...<mailto:sbm...@li...> https://lists.sourceforge.net/lists/listinfo/sbml-spatial |
|
From: Lucian S. <luc...@gm...> - 2014-09-30 19:29:17
|
On Tue, Sep 30, 2014 at 11:45 AM, Frank T. Bergmann <fbe...@ca...>
wrote:
> Sorry for coming late to the party, there are too many emails to reply, so
> I’m choosing just a couple of them. Here Lucian asks about my opinion, so
> this seemed as good as any to reply:
>
>
>
> - I prefer not to use delimiters (other than whitespace) at all,
> the white space is what we use to separate one number from another, and
> that is all that is needed.
>
Would you object to a semicolon as an optional delimiter, treating it as
the equivalent of whitespace, for smaller example models that *could* be
read by humans? I think people are interested in using it in the
ParametricData lists, not so much the SampledField class. As you say, that
data is just linearized 2D or 3D data, with each dimension being probably
very long; in contrast, the SpatialPoints and ParametricData classes are
grouped lists of 3 or 4 data points, where it makes more visual sense to
distinguish them from each other.
-Lucian
- This data is not data a human will ever write. And most often it
> will be there in compressed form, so there it won’t mean anything if you
> have three consecutive numbers (talking about the sampleddata here) they
> don’t represent points as such, they just represent three bytes of
> compressed data.
>
> - Even if the data is not compressed, it is going to be a
> linearized two or three dimensional array. The dimensionality comes out of
> the numSamples attributes later on.
>
>
>
> Cheers
>
> Frank
>
>
>
> *From:* Lucian Smith [mailto:luc...@gm...]
> *Sent:* Tuesday, September 30, 2014 7:33 PM
> *To:* The SBML L3 Spatial Processes and Geometries package discussion list
> *Subject:* Re: [sbml-spatial] Examples? (array data)
>
>
>
> I would be fine with delimiters; if we went with the attribute-defined
> delimiter route ('delimiter=";"'), would we be OK with blank delimiters?
> (delimiter="" or delimiter=" " ?) Or other whitespace delimiters?
>
>
>
> Also, Frank, since you're on the implementation side of things here, would
> adding delimiters be straightforward to implement? Do you have an opinion
> about using them here?
>
>
>
> -Lucian
>
>
>
> On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...>
> wrote:
>
> If the general SBML standard is only say things once (normalized data),
> then I’m for sticking with that rather than doing things differently in
> different places. But I’m definitely for delimiters, either standardized or
> specified by attribute as suggested in another reply.
>
> -Gerard
>
>
>
> *From:* Lucian Smith [mailto:luc...@gm...]
> *Sent:* Monday, September 29, 2014 9:13 PM
> *To:* The SBML L3 Spatial Processes and Geometries package discussion list
> *Subject:* Re: [sbml-spatial] Examples?
>
>
>
> Trying to not miss the other topics in this discussion...
>
>
>
> On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote:
>
> Hi all,
>
>
>
> Sorry for the delay in response. Thanks a lot to Lucian for his work
> looking over those examples. I am remaking my scripts for the models at the
> moment. Although slightly annoying, I think it's ok to have to look up the
> dimensionality elsewhere in the document. I'm in favor of not adding a
> separate redundant field to the geometry object, unless it's not redundant.
> Do we expect to have instances where there are 2 and 3D structures? In that
> case I guess having a dimensionality would be good for each object.
> Thoughts? Is there any reason we can't just keep the semicolons? That
> option might work too.
>
>
>
> Gerard's comments on this were:
>
>
>
> > I’d advocate for, a minimum, semi-colon separators, and I’d be in
> favor a redundant dimensions attribute (2,3, et. al.) so the human reader,
> who can only view a portion of SBML document, knows what they are looking
> at.
>
>
>
> So, that's two votes for semicolons, and one vote for a redundant
> dimensions attribute and one vote against a redundant dimensions
> attribute. Anyone else want to weigh in?
>
>
>
> The trade-off on the dimensions attribute is that if you don't include it,
> you have to look up the information elsewhere, which might be inconvenient,
> but that information is only defined once. If you do include it, you then
> have the information locally, but add another possibility of creating an
> invalid/inconsistent model. SBML core has gone different ways on this for
> different situations, but tends towards trying to only define things once.
> But I'm happy to go either way on this.
>
>
>
> As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because
> that's what I last had VCell using. If this is still true, I suggest we all
> change over to what is in the spec and my new files will reflect that.
>
>
>
> Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent)
> another option in your program, and do you find it useful if so?
>
>
>
> On the rotation issue, one thing I noticed is that I'm using
> "rotationAxisX" rather than "rotateX" for the naming convention. Both are
> in the spec with the prior being in the UML and the latter being in the
> text. Which are we going with?
>
>
>
> Thanks for noticing this! I'm personally inclined to go with the the
> longer name, though actually, I like 'rotationAxisX' better than
> 'rotateAxisX', which is what the UML actually has. Anyone else have an
> opinion?
>
>
>
> -Lucian
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
>
>
|
|
From: Lucian S. <luc...@gm...> - 2014-09-30 19:02:08
|
That's one of the proposed changes, actually: instead of https://docs.google.com/drawings/d/1GT1cjJ64N9X3CISGoFWoXLK1NObzBFwZ-7uEXLvujCg/edit to go to https://docs.google.com/drawings/d/1Qn_A-uGqjN9zVyd56EWfdGBt_yp_zwIjxh-9KCIHB78/edit and have the points encoded simply as a list: <spatialPoints>0 0 0; 0 1 0; 0 1 1; 1 2 2; 1 2 1</spatialPoints> (including the semicolons just for readability right now; not making an argument for or against them.) In this case, they'd be referenced by index by ParametricObject. -Lucian On Tue, Sep 30, 2014 at 11:50 AM, Frank T. Bergmann <fbe...@ca...> wrote: > For the parametric geometry we really have a list of Spatial points > > > > <spatialPoint id=”foo” coord1=”1.0” coord2=”2.0” coord3=”1.0”/>… > > > > Later on the PolygonObject chooses to take indices out of this list. Why > we would choose indices when we were already forced to give each point a > unique id is beyond me. It might just as well be a list of ids on the > polygonObject. But it does not matter. In any case here each index stands > for a separate (possibly three dimensional point), so I don’t see > delimiters (apart from the space that we use) necessary or useful. > > > > Frank > > > > *From:* Lucian Smith [mailto:luc...@gm...] > *Sent:* Tuesday, September 30, 2014 7:53 PM > > *To:* The SBML L3 Spatial Processes and Geometries package discussion list > *Subject:* Re: [sbml-spatial] Examples? (array data) > > > > Well, you don't *have* to have any delimiters at all if you know the > dimensionality of the data; it would be a cross-check for validity and to > make it more easily viewable. I guess the field data does have 3D data in > it that could have different delimiters, but that data might be inherently > less viewable to begin with, and delimiters wouldn't help? As someone > mentioned here recently, that format has not actually been well defined yet > anyway; still need to hear back from Frank or Jim or someone who knows > what's going on there. > > > > The data in the elements we've been discussing so far in the > ParametricGeometry class are all lists of points in space, and lists of > vertexes of triangles or quadrilaterals, and would therefore both only need > a single delimiter. > > > > -Lucian > > > > On Tue, Sep 30, 2014 at 10:37 AM, Weatherby,Gerard <gwe...@uc...> > wrote: > > A blank would be okay – presumably each level of delimiter would have to > be different? > > > > -Gerard > > *From:* Lucian Smith [mailto:luc...@gm...] > *Sent:* Tuesday, September 30, 2014 1:33 PM > *To:* The SBML L3 Spatial Processes and Geometries package discussion list > *Subject:* Re: [sbml-spatial] Examples? (array data) > > > > I would be fine with delimiters; if we went with the attribute-defined > delimiter route ('delimiter=";"'), would we be OK with blank delimiters? > (delimiter="" or delimiter=" " ?) Or other whitespace delimiters? > > > > Also, Frank, since you're on the implementation side of things here, would > adding delimiters be straightforward to implement? Do you have an opinion > about using them here? > > > > -Lucian > > > > On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...> > wrote: > > If the general SBML standard is only say things once (normalized data), > then I’m for sticking with that rather than doing things differently in > different places. But I’m definitely for delimiters, either standardized or > specified by attribute as suggested in another reply. > > -Gerard > > > > *From:* Lucian Smith [mailto:luc...@gm...] > *Sent:* Monday, September 29, 2014 9:13 PM > *To:* The SBML L3 Spatial Processes and Geometries package discussion list > *Subject:* Re: [sbml-spatial] Examples? > > > > Trying to not miss the other topics in this discussion... > > > > On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote: > > Hi all, > > > > Sorry for the delay in response. Thanks a lot to Lucian for his work > looking over those examples. I am remaking my scripts for the models at the > moment. Although slightly annoying, I think it's ok to have to look up the > dimensionality elsewhere in the document. I'm in favor of not adding a > separate redundant field to the geometry object, unless it's not redundant. > Do we expect to have instances where there are 2 and 3D structures? In that > case I guess having a dimensionality would be good for each object. > Thoughts? Is there any reason we can't just keep the semicolons? That > option might work too. > > > > Gerard's comments on this were: > > > > > I’d advocate for, a minimum, semi-colon separators, and I’d be in > favor a redundant dimensions attribute (2,3, et. al.) so the human reader, > who can only view a portion of SBML document, knows what they are looking > at. > > > > So, that's two votes for semicolons, and one vote for a redundant > dimensions attribute and one vote against a redundant dimensions > attribute. Anyone else want to weigh in? > > > > The trade-off on the dimensions attribute is that if you don't include it, > you have to look up the information elsewhere, which might be inconvenient, > but that information is only defined once. If you do include it, you then > have the information locally, but add another possibility of creating an > invalid/inconsistent model. SBML core has gone different ways on this for > different situations, but tends towards trying to only define things once. > But I'm happy to go either way on this. > > > > As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because > that's what I last had VCell using. If this is still true, I suggest we all > change over to what is in the spec and my new files will reflect that. > > > > Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) > another option in your program, and do you find it useful if so? > > > > On the rotation issue, one thing I noticed is that I'm using > "rotationAxisX" rather than "rotateX" for the naming convention. Both are > in the spec with the prior being in the UML and the latter being in the > text. Which are we going with? > > > > Thanks for noticing this! I'm personally inclined to go with the the > longer name, though actually, I like 'rotationAxisX' better than > 'rotateAxisX', which is what the UML actually has. Anyone else have an > opinion? > > > > -Lucian > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-spatial mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-spatial > > > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-spatial mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-spatial > > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-spatial mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-spatial > > |
|
From: Paul M. <pau...@us...> - 2014-09-30 18:50:43
|
Thanks! The human-reading point is good: just opening an XML file in a text editor with a few fields recorded on a few million voxels is ... challenging. :-) Best -- Paul -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul Macklin, Ph.D. Assistant Professor of Research Medicine Center for Applied Molecular Medicine Keck School of Medicine University of Southern California Los Angeles, CA Founder and Co-Lead of the MultiCellDS Project *MultiCellDS*: http://MultiCellDS.org <http://multicellds.org/> / @MultiCellDS <http://www.twitter.com/MultiCellDS> *email*: Pau...@us... / Pau...@Ma... *web*: http://MathCancer.org <http://mathcancer.org/> *Twitter*: @MathCancer <http://www.twitter.com/MathCancer> *mobile*: +1 310-701-5785 *FAX*: +1 323-442-2764 On Tue, Sep 30, 2014 at 11:45 AM, Frank T. Bergmann <fbe...@ca...> wrote: > Sorry for coming late to the party, there are too many emails to reply, so > I’m choosing just a couple of them. Here Lucian asks about my opinion, so > this seemed as good as any to reply: > > > > - I prefer not to use delimiters (other than whitespace) at all, > the white space is what we use to separate one number from another, and > that is all that is needed. > > - This data is not data a human will ever write. And most often > it will be there in compressed form, so there it won’t mean anything if you > have three consecutive numbers (talking about the sampleddata here) they > don’t represent points as such, they just represent three bytes of > compressed data. > > - Even if the data is not compressed, it is going to be a > linearized two or three dimensional array. The dimensionality comes out of > the numSamples attributes later on. > > > > Cheers > > Frank > > > > *From:* Lucian Smith [mailto:luc...@gm...] > *Sent:* Tuesday, September 30, 2014 7:33 PM > *To:* The SBML L3 Spatial Processes and Geometries package discussion list > *Subject:* Re: [sbml-spatial] Examples? (array data) > > > > I would be fine with delimiters; if we went with the attribute-defined > delimiter route ('delimiter=";"'), would we be OK with blank delimiters? > (delimiter="" or delimiter=" " ?) Or other whitespace delimiters? > > > > Also, Frank, since you're on the implementation side of things here, would > adding delimiters be straightforward to implement? Do you have an opinion > about using them here? > > > > -Lucian > > > > On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...> > wrote: > > If the general SBML standard is only say things once (normalized data), > then I’m for sticking with that rather than doing things differently in > different places. But I’m definitely for delimiters, either standardized or > specified by attribute as suggested in another reply. > > -Gerard > > > > *From:* Lucian Smith [mailto:luc...@gm...] > *Sent:* Monday, September 29, 2014 9:13 PM > *To:* The SBML L3 Spatial Processes and Geometries package discussion list > *Subject:* Re: [sbml-spatial] Examples? > > > > Trying to not miss the other topics in this discussion... > > > > On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote: > > Hi all, > > > > Sorry for the delay in response. Thanks a lot to Lucian for his work > looking over those examples. I am remaking my scripts for the models at the > moment. Although slightly annoying, I think it's ok to have to look up the > dimensionality elsewhere in the document. I'm in favor of not adding a > separate redundant field to the geometry object, unless it's not redundant. > Do we expect to have instances where there are 2 and 3D structures? In that > case I guess having a dimensionality would be good for each object. > Thoughts? Is there any reason we can't just keep the semicolons? That > option might work too. > > > > Gerard's comments on this were: > > > > > I’d advocate for, a minimum, semi-colon separators, and I’d be in > favor a redundant dimensions attribute (2,3, et. al.) so the human reader, > who can only view a portion of SBML document, knows what they are looking > at. > > > > So, that's two votes for semicolons, and one vote for a redundant > dimensions attribute and one vote against a redundant dimensions > attribute. Anyone else want to weigh in? > > > > The trade-off on the dimensions attribute is that if you don't include it, > you have to look up the information elsewhere, which might be inconvenient, > but that information is only defined once. If you do include it, you then > have the information locally, but add another possibility of creating an > invalid/inconsistent model. SBML core has gone different ways on this for > different situations, but tends towards trying to only define things once. > But I'm happy to go either way on this. > > > > As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because > that's what I last had VCell using. If this is still true, I suggest we all > change over to what is in the spec and my new files will reflect that. > > > > Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) > another option in your program, and do you find it useful if so? > > > > On the rotation issue, one thing I noticed is that I'm using > "rotationAxisX" rather than "rotateX" for the naming convention. Both are > in the spec with the prior being in the UML and the latter being in the > text. Which are we going with? > > > > Thanks for noticing this! I'm personally inclined to go with the the > longer name, though actually, I like 'rotationAxisX' better than > 'rotateAxisX', which is what the UML actually has. Anyone else have an > opinion? > > > > -Lucian > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-spatial mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-spatial > > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-spatial mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-spatial > > |
|
From: Frank T. B. <fbe...@ca...> - 2014-09-30 18:50:34
|
For the parametric geometry we really have a list of Spatial points
<spatialPoint id=”foo” coord1=”1.0” coord2=”2.0” coord3=”1.0”/>…
Later on the PolygonObject chooses to take indices out of this list. Why we would choose indices when we were already forced to give each point a unique id is beyond me. It might just as well be a list of ids on the polygonObject. But it does not matter. In any case here each index stands for a separate (possibly three dimensional point), so I don’t see delimiters (apart from the space that we use) necessary or useful.
Frank
From: Lucian Smith [mailto:luc...@gm...]
Sent: Tuesday, September 30, 2014 7:53 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples? (array data)
Well, you don't *have* to have any delimiters at all if you know the dimensionality of the data; it would be a cross-check for validity and to make it more easily viewable. I guess the field data does have 3D data in it that could have different delimiters, but that data might be inherently less viewable to begin with, and delimiters wouldn't help? As someone mentioned here recently, that format has not actually been well defined yet anyway; still need to hear back from Frank or Jim or someone who knows what's going on there.
The data in the elements we've been discussing so far in the ParametricGeometry class are all lists of points in space, and lists of vertexes of triangles or quadrilaterals, and would therefore both only need a single delimiter.
-Lucian
On Tue, Sep 30, 2014 at 10:37 AM, Weatherby,Gerard <gwe...@uc... <mailto:gwe...@uc...> > wrote:
A blank would be okay – presumably each level of delimiter would have to be different?
-Gerard
From: Lucian Smith [mailto:luc...@gm... <mailto:luc...@gm...> ]
Sent: Tuesday, September 30, 2014 1:33 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples? (array data)
I would be fine with delimiters; if we went with the attribute-defined delimiter route ('delimiter=";"'), would we be OK with blank delimiters? (delimiter="" or delimiter=" " ?) Or other whitespace delimiters?
Also, Frank, since you're on the implementation side of things here, would adding delimiters be straightforward to implement? Do you have an opinion about using them here?
-Lucian
On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc... <mailto:gwe...@uc...> > wrote:
If the general SBML standard is only say things once (normalized data), then I’m for sticking with that rather than doing things differently in different places. But I’m definitely for delimiters, either standardized or specified by attribute as suggested in another reply.
-Gerard
From: Lucian Smith [mailto:luc...@gm... <mailto:luc...@gm...> ]
Sent: Monday, September 29, 2014 9:13 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples?
Trying to not miss the other topics in this discussion...
On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm... <mailto:de...@cm...> > wrote:
Hi all,
Sorry for the delay in response. Thanks a lot to Lucian for his work looking over those examples. I am remaking my scripts for the models at the moment. Although slightly annoying, I think it's ok to have to look up the dimensionality elsewhere in the document. I'm in favor of not adding a separate redundant field to the geometry object, unless it's not redundant. Do we expect to have instances where there are 2 and 3D structures? In that case I guess having a dimensionality would be good for each object. Thoughts? Is there any reason we can't just keep the semicolons? That option might work too.
Gerard's comments on this were:
> I’d advocate for, a minimum, semi-colon separators, and I’d be in favor a redundant dimensions attribute (2,3, et. al.) so the human reader, who can only view a portion of SBML document, knows what they are looking at.
So, that's two votes for semicolons, and one vote for a redundant dimensions attribute and one vote against a redundant dimensions attribute. Anyone else want to weigh in?
The trade-off on the dimensions attribute is that if you don't include it, you have to look up the information elsewhere, which might be inconvenient, but that information is only defined once. If you do include it, you then have the information locally, but add another possibility of creating an invalid/inconsistent model. SBML core has gone different ways on this for different situations, but tends towards trying to only define things once. But I'm happy to go either way on this.
As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because that's what I last had VCell using. If this is still true, I suggest we all change over to what is in the spec and my new files will reflect that.
Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) another option in your program, and do you find it useful if so?
On the rotation issue, one thing I noticed is that I'm using "rotationAxisX" rather than "rotateX" for the naming convention. Both are in the spec with the prior being in the UML and the latter being in the text. Which are we going with?
Thanks for noticing this! I'm personally inclined to go with the the longer name, though actually, I like 'rotationAxisX' better than 'rotateAxisX', which is what the UML actually has. Anyone else have an opinion?
-Lucian
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311 <http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk> &iu=/4140/ostg.clktrk
_______________________________________________
sbml-spatial mailing list
sbm...@li... <mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-spatial
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311 <http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk> &iu=/4140/ostg.clktrk
_______________________________________________
sbml-spatial mailing list
sbm...@li... <mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-spatial
|
|
From: Paul M. <pau...@us...> - 2014-09-30 18:45:34
|
Yes, no matter what, you'll have to specify how your data are ordered. This is why I'd personally suggest a separate indexing of the spatial locations, then linear arrays: to circumvent such ambiguity, while also simplifying storage, while allowing any ordering that the generating code found most appropriate. Best -- Paul -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul Macklin, Ph.D. Assistant Professor of Research Medicine Center for Applied Molecular Medicine Keck School of Medicine University of Southern California Los Angeles, CA Founder and Co-Lead of the MultiCellDS Project *MultiCellDS*: http://MultiCellDS.org <http://multicellds.org/> / @MultiCellDS <http://www.twitter.com/MultiCellDS> *email*: Pau...@us... / Pau...@Ma... *web*: http://MathCancer.org <http://mathcancer.org/> *Twitter*: @MathCancer <http://www.twitter.com/MathCancer> *mobile*: +1 310-701-5785 *FAX*: +1 323-442-2764 On Tue, Sep 30, 2014 at 11:42 AM, Samuel Friedman < sam...@ca...> wrote: > One thing that you need to address is whether you're working with > row-major or column-major data, which are the default ordering for C and > Fortran respectively. This is why I'm in favor of different delimiters for > different dimensions. Again, you could eliminate them if you specified the > layout of the dimensions of the data. > > Also, XML has some standards about storing 1D arrays. What have other > groups done before with multidimensional arrays of data in XML? > > Sam > > > On Tuesday, September 30, 2014, Lucian Smith <luc...@gm...> > wrote: > > Sorry, I didn't mean that you didn't need spaces; I was assuming the > spaces were a given. What I meant to say was that if you knew the > dimensionality of the data, then "1 2 3; 4 5 6" could be reduced to "1 2 3 > 4 5 6" without loss of information (as is in the current spec). > > I guess my question at this point is: do we want to *require* a > semicolon or semicolon-equivalent in that list, or do we want to make it > optional? > > Here are the options as I see them now: > > > > 1) The current spec: spaces only. > > <spatialPoints compression="none" samplesLength="2">1 2 3 4 5 > 6</spatialPoints> > > 2) Allow semicolons to be used as a delimiter in the spec, but don't > require it > > <spatialPoints compression="none" samplesLength="2">1 2 3 4 5 > 6</spatialPoints> > > or > > <spatialPoints compression="none" samplesLength="2">1 2 3; 4 5 > 6</spatialPoints> > > 3) Allow any delimiter to be used; add a required attribute to say what > it is: > > <spatialPoints compression="none" samplesLength="2" > pointDelimiter=" ">1 2 3 4 5 6</spatialPoints> > > or > > <spatialPoints compression="none" samplesLength="2" > pointDelimiter="">1 2 3 4 5 6</spatialPoints> > > or > > <spatialPoints compression="none" > samplesLength="2" pointDelimiter=";">1 2 3; 4 5 6</spatialPoints> > > > > 4) Require that a semicolon be used > > <spatialPoints compression="none" samplesLength="2">1 2 3; 4 5 > 6</spatialPoints> > > I think my current preference would be #2--programmatically treat > semicolons as spaces, letting people use them for clarity if they want them. > > > > The other issue is that for the 3D field data, you'd need yet another > level of delimiter: "1 2; 3 4 ;; 5 6; 7 8". But I think this data might > be something completely different, and/or have different precedents. Frank > will have to chime in here about the possibilities. > > -Lucian > > On Tue, Sep 30, 2014 at 11:04 AM, Paul Macklin <pau...@us...> > wrote: > >> > >> Thanks, Lucian. > >> Sure, if you know the dimensionality of the data (number of points) and > each element has same size. But then you won't be able to do this without > delimiters > >> 1 3.21834 4 -3.1 5.034 0 > >> unless you pad to equal length: > >> 01.00000000 03.21834000 -3.10000000 05.03400000 00.00000000 > >> which has all data elements of equal length, so now you can smash them > together: > >> 01.0000000003.21834000-3.1000000005.0340000000.00000000 > >> > >> Point is moot for binary formats where you know the bit length of each > element. But in human-readable text, I don't know how you get around > delimiters without a lot of extra padding to ensure equal length of each > recorded datum. > >> Agreed with Gerard that lists of points like that are a lot easier to > read as he recorded them, although it looks to me like the delimiters there > are " " (space) and "; " (semicolon space). > >> Thanks -- Paul > >> > >> > >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >> Paul Macklin, Ph.D. > >> Assistant Professor of Research Medicine > >> Center for Applied Molecular Medicine > >> Keck School of Medicine > >> University of Southern California > >> Los Angeles, CA > >> Founder and Co-Lead of the MultiCellDS Project > >> MultiCellDS: http://MultiCellDS.org / @MultiCellDS > >> > >> email: Pau...@us... / Pau...@Ma... > >> web: http://MathCancer.org > >> Twitter: @MathCancer > >> mobile: +1 310-701-5785 > >> FAX: +1 323-442-2764 > >> > >> On Tue, Sep 30, 2014 at 10:53 AM, Lucian Smith < > luc...@gm...> wrote: > >>> > >>> Well, you don't *have* to have any delimiters at all if you know the > dimensionality of the data; it would be a cross-check for validity and to > make it more easily viewable. I guess the field data does have 3D data in > it that could have different delimiters, but that data might be inherently > less viewable to begin with, and delimiters wouldn't help? As someone > mentioned here recently, that format has not actually been well defined yet > anyway; still need to hear back from Frank or Jim or someone who knows > what's going on there. > >>> The data in the elements we've been discussing so far in the > ParametricGeometry class are all lists of points in space, and lists of > vertexes of triangles or quadrilaterals, and would therefore both only need > a single delimiter. > >>> -Lucian > >>> On Tue, Sep 30, 2014 at 10:37 AM, Weatherby,Gerard < > gwe...@uc...> wrote: > >>>> > >>>> A blank would be okay – presumably each level of delimiter would have > to be different? > >>>> > >>>> > >>>> > >>>> -Gerard > >>>> > >>>> From: Lucian Smith [mailto:luc...@gm...] > >>>> Sent: Tuesday, September 30, 2014 1:33 PM > >>>> To: The SBML L3 Spatial Processes and Geometries package discussion > list > >>>> Subject: Re: [sbml-spatial] Examples? (array data) > >>>> > >>>> > >>>> > >>>> I would be fine with delimiters; if we went with the > attribute-defined delimiter route ('delimiter=";"'), would we be OK with > blank delimiters? (delimiter="" or delimiter=" " ?) Or other whitespace > delimiters? > >>>> > >>>> > >>>> > >>>> Also, Frank, since you're on the implementation side of things here, > would adding delimiters be straightforward to implement? Do you have an > opinion about using them here? > >>>> > >>>> > >>>> > >>>> -Lucian > >>>> > >>>> > >>>> > >>>> On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard < > gwe...@uc...> wrote: > >>>> > >>>> If the general SBML standard is only say things once (normalized > data), then I’m for sticking with that rather than doing things differently > in different places. But I’m definitely for delimiters, either standardized > or specified by attribute as suggested in another reply. > >>>> > >>>> -Gerard > >>>> > >>>> > >>>> > >>>> From: Lucian Smith [mailto:luc...@gm...] > >>>> Sent: Monday, September 29, 2014 9:13 PM > >>>> To: The SBML L3 Spatial Processes and Geometries package discussion > list > >>>> Subject: Re: [sbml-spatial] Examples? > >>>> > >>>> > >>>> > >>>> Trying to not miss the other topics in this discussion... > >>>> > >>>> > >>>> > >>>> On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> > wrote: > >>>> > >>>> Hi all, > >>>> > >>>> > >>>> > >>>> Sorry for the delay in response. Thanks a lot to Lucian for his work > looking over those examples. I am remaking my scripts for the models at the > moment. Although slightly annoying, I think it's ok to have to look up the > dimensionality elsewhere in the document. I'm in favor of not adding a > separate redundant field to the geometry object, unless it's not redundant. > Do we expect to have instances where there are 2 and 3D structures? In that > case I guess having a dimensionality would be good for each object. > Thoughts? Is there any reason we can't just keep the semicolons? That > option might work too. > >>>> > >>>> > >>>> > >>>> Gerard's comments on this were: > >>>> > >>>> > >>>> > >>>> > I’d advocate for, a minimum, semi-colon separators, and I’d be in > favor a redundant dimensions attribute (2,3, et. al.) so the human reader, > who can only view a portion of SBML document, knows what they are looking > at. > >>>> > >>>> > >>>> > >>>> So, that's two votes for semicolons, and one vote for a redundant > dimensions attribute and one vote against a redundant dimensions > attribute. Anyone else want to weigh in? > >>>> > >>>> > >>>> > >>>> The trade-off on the dimensions attribute is that if you don't > include it, you have to look up the information elsewhere, which might be > inconvenient, but that information is only defined once. If you do include > it, you then have the information locally, but add another possibility of > creating an invalid/inconsistent model. SBML core has gone different ways > on this for different situations, but tends towards trying to only define > things once. But I'm happy to go either way on this. > >>>> > >>>> > >>>> > >>>> As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those > because that's what I last had VCell using. If this is still true, I > suggest we all change over to what is in the spec and my new files will > reflect that. > >>>> > >>>> > >>>> > >>>> Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) > another option in your program, and do you find it useful if so? > >>>> > >>>> > >>>> > >>>> On the rotation issue, one thing I noticed is that I'm using > "rotationAxisX" rather than "rotateX" for the naming convention. Both are > in the spec with the prior being in the UML and the latter being in the > text. Which are we going with? > >>>> > >>>> > >>>> > >>>> Thanks for noticing this! I'm personally inclined to go with the the > longer name, though actually, I like 'rotationAxisX' better than > 'rotateAxisX', which is what the UML actually has. Anyone else have an > opinion? > >>>> > >>>> > >>>> > >>>> -Lucian > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > >>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS > Reports > >>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > >>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > >>>> > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > >>>> _______________________________________________ > >>>> sbml-spatial mailing list > >>>> sbm...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > >>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS > Reports > >>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > >>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > >>>> > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > >>>> _______________________________________________ > >>>> sbml-spatial mailing list > >>>> sbm...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial > >>>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > >>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS > Reports > >>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > >>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > >>> > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > >>> _______________________________________________ > >>> sbml-spatial mailing list > >>> sbm...@li... > >>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial > >>> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > >> > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> sbml-spatial mailing list > >> sbm...@li... > >> https://lists.sourceforge.net/lists/listinfo/sbml-spatial > >> > > > > > > -- > Dr. Samuel H. Friedman > University of Southern California Postdoctoral Scholar - Research > Associate > Center for Applied Molecular Medicine Keck School of Medicine > Email: sam...@ca... Phone: 323-442-2531 > 2250 Alcazar St Rm 259 Los Angeles, CA 90033 > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-spatial mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-spatial > > |
|
From: Frank T. B. <fbe...@ca...> - 2014-09-30 18:45:18
|
Sorry for coming late to the party, there are too many emails to reply, so I’m choosing just a couple of them. Here Lucian asks about my opinion, so this seemed as good as any to reply:
- I prefer not to use delimiters (other than whitespace) at all, the white space is what we use to separate one number from another, and that is all that is needed.
- This data is not data a human will ever write. And most often it will be there in compressed form, so there it won’t mean anything if you have three consecutive numbers (talking about the sampleddata here) they don’t represent points as such, they just represent three bytes of compressed data.
- Even if the data is not compressed, it is going to be a linearized two or three dimensional array. The dimensionality comes out of the numSamples attributes later on.
Cheers
Frank
From: Lucian Smith [mailto:luc...@gm...]
Sent: Tuesday, September 30, 2014 7:33 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples? (array data)
I would be fine with delimiters; if we went with the attribute-defined delimiter route ('delimiter=";"'), would we be OK with blank delimiters? (delimiter="" or delimiter=" " ?) Or other whitespace delimiters?
Also, Frank, since you're on the implementation side of things here, would adding delimiters be straightforward to implement? Do you have an opinion about using them here?
-Lucian
On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc... <mailto:gwe...@uc...> > wrote:
If the general SBML standard is only say things once (normalized data), then I’m for sticking with that rather than doing things differently in different places. But I’m definitely for delimiters, either standardized or specified by attribute as suggested in another reply.
-Gerard
From: Lucian Smith [mailto:luc...@gm... <mailto:luc...@gm...> ]
Sent: Monday, September 29, 2014 9:13 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples?
Trying to not miss the other topics in this discussion...
On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm... <mailto:de...@cm...> > wrote:
Hi all,
Sorry for the delay in response. Thanks a lot to Lucian for his work looking over those examples. I am remaking my scripts for the models at the moment. Although slightly annoying, I think it's ok to have to look up the dimensionality elsewhere in the document. I'm in favor of not adding a separate redundant field to the geometry object, unless it's not redundant. Do we expect to have instances where there are 2 and 3D structures? In that case I guess having a dimensionality would be good for each object. Thoughts? Is there any reason we can't just keep the semicolons? That option might work too.
Gerard's comments on this were:
> I’d advocate for, a minimum, semi-colon separators, and I’d be in favor a redundant dimensions attribute (2,3, et. al.) so the human reader, who can only view a portion of SBML document, knows what they are looking at.
So, that's two votes for semicolons, and one vote for a redundant dimensions attribute and one vote against a redundant dimensions attribute. Anyone else want to weigh in?
The trade-off on the dimensions attribute is that if you don't include it, you have to look up the information elsewhere, which might be inconvenient, but that information is only defined once. If you do include it, you then have the information locally, but add another possibility of creating an invalid/inconsistent model. SBML core has gone different ways on this for different situations, but tends towards trying to only define things once. But I'm happy to go either way on this.
As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because that's what I last had VCell using. If this is still true, I suggest we all change over to what is in the spec and my new files will reflect that.
Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) another option in your program, and do you find it useful if so?
On the rotation issue, one thing I noticed is that I'm using "rotationAxisX" rather than "rotateX" for the naming convention. Both are in the spec with the prior being in the UML and the latter being in the text. Which are we going with?
Thanks for noticing this! I'm personally inclined to go with the the longer name, though actually, I like 'rotationAxisX' better than 'rotateAxisX', which is what the UML actually has. Anyone else have an opinion?
-Lucian
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311 <http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk> &iu=/4140/ostg.clktrk
_______________________________________________
sbml-spatial mailing list
sbm...@li... <mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-spatial
|
|
From: Paul M. <pau...@us...> - 2014-09-30 18:43:58
|
Thanks, Lucian! Regarding 3-D data fields, if you have a separate indexing of the sample locations, then you can record the data field as a one-dimensional array (listed in the same order as your sample locations). I.e., designate the mesh / sampling, and then record the fields that are saved on that set of points. Sort of like this (in pseudo-XML) <sample_points number_of_samples="42" dimension="3" ID=0> x0 y0 z0; x1 y1 z1; .... ; x41 y41 z42 </sample_points> <sampled_field mesh_index="0" name="oxygen"> f(x0,y0,z0) f(x1,y1,z1) .... f(x41,y41,z41) </sampled_field> <sampled_field mesh_index="0" name="glucose"> g(x0,y0,z0) g(x1,y1,z1) .... g(x41,y41,z41) </sampled_field> <sampled_field mesh_index="0" name="ECM" encoding="base64"> 2348anmdfjq2348adEJDF0f9anjuu... </sampled_field> Then, you don't have to worry about all these multiple types of delimiters, which starts to get very complicated in 3D I don't know particular of the specs well enough, alas, but I'm guessing here the sample_points would map onto the spatialPoints ... Thanks -- Paul -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul Macklin, Ph.D. Assistant Professor of Research Medicine Center for Applied Molecular Medicine Keck School of Medicine University of Southern California Los Angeles, CA Founder and Co-Lead of the MultiCellDS Project *MultiCellDS*: http://MultiCellDS.org <http://multicellds.org/> / @MultiCellDS <http://www.twitter.com/MultiCellDS> *email*: Pau...@us... / Pau...@Ma... *web*: http://MathCancer.org <http://mathcancer.org/> *Twitter*: @MathCancer <http://www.twitter.com/MathCancer> *mobile*: +1 310-701-5785 *FAX*: +1 323-442-2764 On Tue, Sep 30, 2014 at 11:29 AM, Lucian Smith <luc...@gm...> wrote: > Sorry, I didn't mean that you didn't need spaces; I was assuming the > spaces were a given. What I meant to say was that if you knew the > dimensionality of the data, then "1 2 3; 4 5 6" could be reduced to "1 2 3 > 4 5 6" without loss of information (as is in the current spec). > > I guess my question at this point is: do we want to *require* a semicolon > or semicolon-equivalent in that list, or do we want to make it optional? > > Here are the options as I see them now: > > 1) The current spec: spaces only. > <spatialPoints compression="none" samplesLength="2">1 2 3 4 5 > 6</spatialPoints> > > 2) Allow semicolons to be used as a delimiter in the spec, but don't > require it > <spatialPoints compression="none" samplesLength="2">1 2 3 4 5 > 6</spatialPoints> > or > <spatialPoints compression="none" samplesLength="2">1 2 3; 4 5 > 6</spatialPoints> > > 3) Allow any delimiter to be used; add a required attribute to say what it > is: > <spatialPoints compression="none" samplesLength="2" pointDelimiter=" > ">1 2 3 4 5 6</spatialPoints> > or > <spatialPoints compression="none" samplesLength="2" > pointDelimiter="">1 2 3 4 5 6</spatialPoints> > or > <spatialPoints compression="none" > samplesLength="2" pointDelimiter=";">1 2 3; 4 5 6</spatialPoints> > > 4) Require that a semicolon be used > <spatialPoints compression="none" samplesLength="2">1 2 3; 4 5 > 6</spatialPoints> > > I think my current preference would be #2--programmatically treat > semicolons as spaces, letting people use them for clarity if they want them. > > The other issue is that for the 3D field data, you'd need yet another > level of delimiter: "1 2; 3 4 ;; 5 6; 7 8". But I think this data might > be something completely different, and/or have different precedents. Frank > will have to chime in here about the possibilities. > > -Lucian > > On Tue, Sep 30, 2014 at 11:04 AM, Paul Macklin <pau...@us...> > wrote: > >> Thanks, Lucian. >> >> Sure, if you know the dimensionality of the data (number of points) and >> each element has same size. But then you won't be able to do this without >> delimiters >> >> 1 3.21834 4 -3.1 5.034 0 >> >> unless you pad to equal length: >> >> 01.00000000 03.21834000 -3.10000000 05.03400000 00.00000000 >> >> which has all data elements of equal length, so now you can smash them >> together: >> >> 01.0000000003.21834000-3.1000000005.0340000000.00000000 >> >> Point is moot for binary formats where you know the bit length of each >> element. But in human-readable text, I don't know how you get around >> delimiters without a lot of extra padding to ensure equal length of each >> recorded datum. >> >> Agreed with Gerard that lists of points like that are a lot easier to >> read as he recorded them, although it looks to me like the delimiters there >> are " " (space) and "; " (semicolon space). >> >> Thanks -- Paul >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Paul Macklin, Ph.D. >> >> Assistant Professor of Research Medicine >> Center for Applied Molecular Medicine >> Keck School of Medicine >> University of Southern California >> Los Angeles, CA >> >> Founder and Co-Lead of the MultiCellDS Project >> *MultiCellDS*: http://MultiCellDS.org <http://multicellds.org/> / >> @MultiCellDS <http://www.twitter.com/MultiCellDS> >> >> *email*: Pau...@us... / Pau...@Ma... >> *web*: http://MathCancer.org <http://mathcancer.org/> >> *Twitter*: @MathCancer <http://www.twitter.com/MathCancer> >> >> *mobile*: +1 310-701-5785 >> *FAX*: +1 323-442-2764 >> >> >> On Tue, Sep 30, 2014 at 10:53 AM, Lucian Smith <luc...@gm... >> > wrote: >> >>> Well, you don't *have* to have any delimiters at all if you know the >>> dimensionality of the data; it would be a cross-check for validity and to >>> make it more easily viewable. I guess the field data does have 3D data in >>> it that could have different delimiters, but that data might be inherently >>> less viewable to begin with, and delimiters wouldn't help? As someone >>> mentioned here recently, that format has not actually been well defined yet >>> anyway; still need to hear back from Frank or Jim or someone who knows >>> what's going on there. >>> >>> The data in the elements we've been discussing so far in the >>> ParametricGeometry class are all lists of points in space, and lists of >>> vertexes of triangles or quadrilaterals, and would therefore both only need >>> a single delimiter. >>> >>> -Lucian >>> >>> On Tue, Sep 30, 2014 at 10:37 AM, Weatherby,Gerard <gwe...@uc...> >>> wrote: >>> >>>> A blank would be okay – presumably each level of delimiter would have >>>> to be different? >>>> >>>> >>>> >>>> -Gerard >>>> >>>> *From:* Lucian Smith [mailto:luc...@gm...] >>>> *Sent:* Tuesday, September 30, 2014 1:33 PM >>>> *To:* The SBML L3 Spatial Processes and Geometries package discussion >>>> list >>>> *Subject:* Re: [sbml-spatial] Examples? (array data) >>>> >>>> >>>> >>>> I would be fine with delimiters; if we went with the attribute-defined >>>> delimiter route ('delimiter=";"'), would we be OK with blank delimiters? >>>> (delimiter="" or delimiter=" " ?) Or other whitespace delimiters? >>>> >>>> >>>> >>>> Also, Frank, since you're on the implementation side of things here, >>>> would adding delimiters be straightforward to implement? Do you have an >>>> opinion about using them here? >>>> >>>> >>>> >>>> -Lucian >>>> >>>> >>>> >>>> On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...> >>>> wrote: >>>> >>>> If the general SBML standard is only say things once (normalized data), >>>> then I’m for sticking with that rather than doing things differently in >>>> different places. But I’m definitely for delimiters, either standardized or >>>> specified by attribute as suggested in another reply. >>>> >>>> -Gerard >>>> >>>> >>>> >>>> *From:* Lucian Smith [mailto:luc...@gm...] >>>> *Sent:* Monday, September 29, 2014 9:13 PM >>>> *To:* The SBML L3 Spatial Processes and Geometries package discussion >>>> list >>>> *Subject:* Re: [sbml-spatial] Examples? >>>> >>>> >>>> >>>> Trying to not miss the other topics in this discussion... >>>> >>>> >>>> >>>> On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> Sorry for the delay in response. Thanks a lot to Lucian for his work >>>> looking over those examples. I am remaking my scripts for the models at the >>>> moment. Although slightly annoying, I think it's ok to have to look up the >>>> dimensionality elsewhere in the document. I'm in favor of not adding a >>>> separate redundant field to the geometry object, unless it's not redundant. >>>> Do we expect to have instances where there are 2 and 3D structures? In that >>>> case I guess having a dimensionality would be good for each object. >>>> Thoughts? Is there any reason we can't just keep the semicolons? That >>>> option might work too. >>>> >>>> >>>> >>>> Gerard's comments on this were: >>>> >>>> >>>> >>>> > I’d advocate for, a minimum, semi-colon separators, and I’d be in >>>> favor a redundant dimensions attribute (2,3, et. al.) so the human reader, >>>> who can only view a portion of SBML document, knows what they are looking >>>> at. >>>> >>>> >>>> >>>> So, that's two votes for semicolons, and one vote for a redundant >>>> dimensions attribute and one vote against a redundant dimensions >>>> attribute. Anyone else want to weigh in? >>>> >>>> >>>> >>>> The trade-off on the dimensions attribute is that if you don't include >>>> it, you have to look up the information elsewhere, which might be >>>> inconvenient, but that information is only defined once. If you do include >>>> it, you then have the information locally, but add another possibility of >>>> creating an invalid/inconsistent model. SBML core has gone different ways >>>> on this for different situations, but tends towards trying to only define >>>> things once. But I'm happy to go either way on this. >>>> >>>> >>>> >>>> As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those >>>> because that's what I last had VCell using. If this is still true, I >>>> suggest we all change over to what is in the spec and my new files will >>>> reflect that. >>>> >>>> >>>> >>>> Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) >>>> another option in your program, and do you find it useful if so? >>>> >>>> >>>> >>>> On the rotation issue, one thing I noticed is that I'm using >>>> "rotationAxisX" rather than "rotateX" for the naming convention. Both are >>>> in the spec with the prior being in the UML and the latter being in the >>>> text. Which are we going with? >>>> >>>> >>>> >>>> Thanks for noticing this! I'm personally inclined to go with the the >>>> longer name, though actually, I like 'rotationAxisX' better than >>>> 'rotateAxisX', which is what the UML actually has. Anyone else have an >>>> opinion? >>>> >>>> >>>> >>>> -Lucian >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> sbml-spatial mailing list >>>> sbm...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> sbml-spatial mailing list >>>> sbm...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> sbml-spatial mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> _______________________________________________ >> sbml-spatial mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >> >> > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-spatial mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-spatial > > |
|
From: Samuel F. <sam...@ca...> - 2014-09-30 18:42:32
|
One thing that you need to address is whether you're working with row-major or column-major data, which are the default ordering for C and Fortran respectively. This is why I'm in favor of different delimiters for different dimensions. Again, you could eliminate them if you specified the layout of the dimensions of the data. Also, XML has some standards about storing 1D arrays. What have other groups done before with multidimensional arrays of data in XML? Sam On Tuesday, September 30, 2014, Lucian Smith <luc...@gm...> wrote: > Sorry, I didn't mean that you didn't need spaces; I was assuming the spaces were a given. What I meant to say was that if you knew the dimensionality of the data, then "1 2 3; 4 5 6" could be reduced to "1 2 3 4 5 6" without loss of information (as is in the current spec). > I guess my question at this point is: do we want to *require* a semicolon or semicolon-equivalent in that list, or do we want to make it optional? > Here are the options as I see them now: > > 1) The current spec: spaces only. > <spatialPoints compression="none" samplesLength="2">1 2 3 4 5 6</spatialPoints> > 2) Allow semicolons to be used as a delimiter in the spec, but don't require it > <spatialPoints compression="none" samplesLength="2">1 2 3 4 5 6</spatialPoints> > or > <spatialPoints compression="none" samplesLength="2">1 2 3; 4 5 6</spatialPoints> > 3) Allow any delimiter to be used; add a required attribute to say what it is: > <spatialPoints compression="none" samplesLength="2" pointDelimiter=" ">1 2 3 4 5 6</spatialPoints> > or > <spatialPoints compression="none" samplesLength="2" pointDelimiter="">1 2 3 4 5 6</spatialPoints> > or > <spatialPoints compression="none" samplesLength="2" pointDelimiter=";">1 2 3; 4 5 6</spatialPoints> > > 4) Require that a semicolon be used > <spatialPoints compression="none" samplesLength="2">1 2 3; 4 5 6</spatialPoints> > I think my current preference would be #2--programmatically treat semicolons as spaces, letting people use them for clarity if they want them. > > The other issue is that for the 3D field data, you'd need yet another level of delimiter: "1 2; 3 4 ;; 5 6; 7 8". But I think this data might be something completely different, and/or have different precedents. Frank will have to chime in here about the possibilities. > -Lucian > On Tue, Sep 30, 2014 at 11:04 AM, Paul Macklin <pau...@us...> wrote: >> >> Thanks, Lucian. >> Sure, if you know the dimensionality of the data (number of points) and each element has same size. But then you won't be able to do this without delimiters >> 1 3.21834 4 -3.1 5.034 0 >> unless you pad to equal length: >> 01.00000000 03.21834000 -3.10000000 05.03400000 00.00000000 >> which has all data elements of equal length, so now you can smash them together: >> 01.0000000003.21834000-3.1000000005.0340000000.00000000 >> >> Point is moot for binary formats where you know the bit length of each element. But in human-readable text, I don't know how you get around delimiters without a lot of extra padding to ensure equal length of each recorded datum. >> Agreed with Gerard that lists of points like that are a lot easier to read as he recorded them, although it looks to me like the delimiters there are " " (space) and "; " (semicolon space). >> Thanks -- Paul >> >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Paul Macklin, Ph.D. >> Assistant Professor of Research Medicine >> Center for Applied Molecular Medicine >> Keck School of Medicine >> University of Southern California >> Los Angeles, CA >> Founder and Co-Lead of the MultiCellDS Project >> MultiCellDS: http://MultiCellDS.org / @MultiCellDS >> >> email: Pau...@us... / Pau...@Ma... >> web: http://MathCancer.org >> Twitter: @MathCancer >> mobile: +1 310-701-5785 >> FAX: +1 323-442-2764 >> >> On Tue, Sep 30, 2014 at 10:53 AM, Lucian Smith <luc...@gm...> wrote: >>> >>> Well, you don't *have* to have any delimiters at all if you know the dimensionality of the data; it would be a cross-check for validity and to make it more easily viewable. I guess the field data does have 3D data in it that could have different delimiters, but that data might be inherently less viewable to begin with, and delimiters wouldn't help? As someone mentioned here recently, that format has not actually been well defined yet anyway; still need to hear back from Frank or Jim or someone who knows what's going on there. >>> The data in the elements we've been discussing so far in the ParametricGeometry class are all lists of points in space, and lists of vertexes of triangles or quadrilaterals, and would therefore both only need a single delimiter. >>> -Lucian >>> On Tue, Sep 30, 2014 at 10:37 AM, Weatherby,Gerard <gwe...@uc...> wrote: >>>> >>>> A blank would be okay – presumably each level of delimiter would have to be different? >>>> >>>> >>>> >>>> -Gerard >>>> >>>> From: Lucian Smith [mailto:luc...@gm...] >>>> Sent: Tuesday, September 30, 2014 1:33 PM >>>> To: The SBML L3 Spatial Processes and Geometries package discussion list >>>> Subject: Re: [sbml-spatial] Examples? (array data) >>>> >>>> >>>> >>>> I would be fine with delimiters; if we went with the attribute-defined delimiter route ('delimiter=";"'), would we be OK with blank delimiters? (delimiter="" or delimiter=" " ?) Or other whitespace delimiters? >>>> >>>> >>>> >>>> Also, Frank, since you're on the implementation side of things here, would adding delimiters be straightforward to implement? Do you have an opinion about using them here? >>>> >>>> >>>> >>>> -Lucian >>>> >>>> >>>> >>>> On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...> wrote: >>>> >>>> If the general SBML standard is only say things once (normalized data), then I’m for sticking with that rather than doing things differently in different places. But I’m definitely for delimiters, either standardized or specified by attribute as suggested in another reply. >>>> >>>> -Gerard >>>> >>>> >>>> >>>> From: Lucian Smith [mailto:luc...@gm...] >>>> Sent: Monday, September 29, 2014 9:13 PM >>>> To: The SBML L3 Spatial Processes and Geometries package discussion list >>>> Subject: Re: [sbml-spatial] Examples? >>>> >>>> >>>> >>>> Trying to not miss the other topics in this discussion... >>>> >>>> >>>> >>>> On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> Sorry for the delay in response. Thanks a lot to Lucian for his work looking over those examples. I am remaking my scripts for the models at the moment. Although slightly annoying, I think it's ok to have to look up the dimensionality elsewhere in the document. I'm in favor of not adding a separate redundant field to the geometry object, unless it's not redundant. Do we expect to have instances where there are 2 and 3D structures? In that case I guess having a dimensionality would be good for each object. Thoughts? Is there any reason we can't just keep the semicolons? That option might work too. >>>> >>>> >>>> >>>> Gerard's comments on this were: >>>> >>>> >>>> >>>> > I’d advocate for, a minimum, semi-colon separators, and I’d be in favor a redundant dimensions attribute (2,3, et. al.) so the human reader, who can only view a portion of SBML document, knows what they are looking at. >>>> >>>> >>>> >>>> So, that's two votes for semicolons, and one vote for a redundant dimensions attribute and one vote against a redundant dimensions attribute. Anyone else want to weigh in? >>>> >>>> >>>> >>>> The trade-off on the dimensions attribute is that if you don't include it, you have to look up the information elsewhere, which might be inconvenient, but that information is only defined once. If you do include it, you then have the information locally, but add another possibility of creating an invalid/inconsistent model. SBML core has gone different ways on this for different situations, but tends towards trying to only define things once. But I'm happy to go either way on this. >>>> >>>> >>>> >>>> As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because that's what I last had VCell using. If this is still true, I suggest we all change over to what is in the spec and my new files will reflect that. >>>> >>>> >>>> >>>> Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) another option in your program, and do you find it useful if so? >>>> >>>> >>>> >>>> On the rotation issue, one thing I noticed is that I'm using "rotationAxisX" rather than "rotateX" for the naming convention. Both are in the spec with the prior being in the UML and the latter being in the text. Which are we going with? >>>> >>>> >>>> >>>> Thanks for noticing this! I'm personally inclined to go with the the longer name, though actually, I like 'rotationAxisX' better than 'rotateAxisX', which is what the UML actually has. Anyone else have an opinion? >>>> >>>> >>>> >>>> -Lucian >>>> >>>> ------------------------------------------------------------------------------ >>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> sbml-spatial mailing list >>>> sbm...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> sbml-spatial mailing list >>>> sbm...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> sbml-spatial mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >>> >> >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> _______________________________________________ >> sbml-spatial mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >> > > -- Dr. Samuel H. Friedman University of Southern California Postdoctoral Scholar - Research Associate Center for Applied Molecular Medicine Keck School of Medicine Email: sam...@ca... Phone: 323-442-2531 2250 Alcazar St Rm 259 Los Angeles, CA 90033 |
|
From: Lucian S. <luc...@gm...> - 2014-09-30 18:29:55
|
Sorry, I didn't mean that you didn't need spaces; I was assuming the spaces
were a given. What I meant to say was that if you knew the dimensionality
of the data, then "1 2 3; 4 5 6" could be reduced to "1 2 3 4 5 6" without
loss of information (as is in the current spec).
I guess my question at this point is: do we want to *require* a semicolon
or semicolon-equivalent in that list, or do we want to make it optional?
Here are the options as I see them now:
1) The current spec: spaces only.
<spatialPoints compression="none" samplesLength="2">1 2 3 4 5
6</spatialPoints>
2) Allow semicolons to be used as a delimiter in the spec, but don't
require it
<spatialPoints compression="none" samplesLength="2">1 2 3 4 5
6</spatialPoints>
or
<spatialPoints compression="none" samplesLength="2">1 2 3; 4 5
6</spatialPoints>
3) Allow any delimiter to be used; add a required attribute to say what it
is:
<spatialPoints compression="none" samplesLength="2" pointDelimiter="
">1 2 3 4 5 6</spatialPoints>
or
<spatialPoints compression="none" samplesLength="2"
pointDelimiter="">1 2 3 4 5 6</spatialPoints>
or
<spatialPoints compression="none"
samplesLength="2" pointDelimiter=";">1 2 3; 4 5 6</spatialPoints>
4) Require that a semicolon be used
<spatialPoints compression="none" samplesLength="2">1 2 3; 4 5
6</spatialPoints>
I think my current preference would be #2--programmatically treat
semicolons as spaces, letting people use them for clarity if they want them.
The other issue is that for the 3D field data, you'd need yet another level
of delimiter: "1 2; 3 4 ;; 5 6; 7 8". But I think this data might be
something completely different, and/or have different precedents. Frank
will have to chime in here about the possibilities.
-Lucian
On Tue, Sep 30, 2014 at 11:04 AM, Paul Macklin <pau...@us...> wrote:
> Thanks, Lucian.
>
> Sure, if you know the dimensionality of the data (number of points) and
> each element has same size. But then you won't be able to do this without
> delimiters
>
> 1 3.21834 4 -3.1 5.034 0
>
> unless you pad to equal length:
>
> 01.00000000 03.21834000 -3.10000000 05.03400000 00.00000000
>
> which has all data elements of equal length, so now you can smash them
> together:
>
> 01.0000000003.21834000-3.1000000005.0340000000.00000000
>
> Point is moot for binary formats where you know the bit length of each
> element. But in human-readable text, I don't know how you get around
> delimiters without a lot of extra padding to ensure equal length of each
> recorded datum.
>
> Agreed with Gerard that lists of points like that are a lot easier to read
> as he recorded them, although it looks to me like the delimiters there are
> " " (space) and "; " (semicolon space).
>
> Thanks -- Paul
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Paul Macklin, Ph.D.
>
> Assistant Professor of Research Medicine
> Center for Applied Molecular Medicine
> Keck School of Medicine
> University of Southern California
> Los Angeles, CA
>
> Founder and Co-Lead of the MultiCellDS Project
> *MultiCellDS*: http://MultiCellDS.org <http://multicellds.org/> /
> @MultiCellDS <http://www.twitter.com/MultiCellDS>
>
> *email*: Pau...@us... / Pau...@Ma...
> *web*: http://MathCancer.org <http://mathcancer.org/>
> *Twitter*: @MathCancer <http://www.twitter.com/MathCancer>
>
> *mobile*: +1 310-701-5785
> *FAX*: +1 323-442-2764
>
>
> On Tue, Sep 30, 2014 at 10:53 AM, Lucian Smith <luc...@gm...>
> wrote:
>
>> Well, you don't *have* to have any delimiters at all if you know the
>> dimensionality of the data; it would be a cross-check for validity and to
>> make it more easily viewable. I guess the field data does have 3D data in
>> it that could have different delimiters, but that data might be inherently
>> less viewable to begin with, and delimiters wouldn't help? As someone
>> mentioned here recently, that format has not actually been well defined yet
>> anyway; still need to hear back from Frank or Jim or someone who knows
>> what's going on there.
>>
>> The data in the elements we've been discussing so far in the
>> ParametricGeometry class are all lists of points in space, and lists of
>> vertexes of triangles or quadrilaterals, and would therefore both only need
>> a single delimiter.
>>
>> -Lucian
>>
>> On Tue, Sep 30, 2014 at 10:37 AM, Weatherby,Gerard <gwe...@uc...>
>> wrote:
>>
>>> A blank would be okay – presumably each level of delimiter would have
>>> to be different?
>>>
>>>
>>>
>>> -Gerard
>>>
>>> *From:* Lucian Smith [mailto:luc...@gm...]
>>> *Sent:* Tuesday, September 30, 2014 1:33 PM
>>> *To:* The SBML L3 Spatial Processes and Geometries package discussion
>>> list
>>> *Subject:* Re: [sbml-spatial] Examples? (array data)
>>>
>>>
>>>
>>> I would be fine with delimiters; if we went with the attribute-defined
>>> delimiter route ('delimiter=";"'), would we be OK with blank delimiters?
>>> (delimiter="" or delimiter=" " ?) Or other whitespace delimiters?
>>>
>>>
>>>
>>> Also, Frank, since you're on the implementation side of things here,
>>> would adding delimiters be straightforward to implement? Do you have an
>>> opinion about using them here?
>>>
>>>
>>>
>>> -Lucian
>>>
>>>
>>>
>>> On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...>
>>> wrote:
>>>
>>> If the general SBML standard is only say things once (normalized data),
>>> then I’m for sticking with that rather than doing things differently in
>>> different places. But I’m definitely for delimiters, either standardized or
>>> specified by attribute as suggested in another reply.
>>>
>>> -Gerard
>>>
>>>
>>>
>>> *From:* Lucian Smith [mailto:luc...@gm...]
>>> *Sent:* Monday, September 29, 2014 9:13 PM
>>> *To:* The SBML L3 Spatial Processes and Geometries package discussion
>>> list
>>> *Subject:* Re: [sbml-spatial] Examples?
>>>
>>>
>>>
>>> Trying to not miss the other topics in this discussion...
>>>
>>>
>>>
>>> On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> Sorry for the delay in response. Thanks a lot to Lucian for his work
>>> looking over those examples. I am remaking my scripts for the models at the
>>> moment. Although slightly annoying, I think it's ok to have to look up the
>>> dimensionality elsewhere in the document. I'm in favor of not adding a
>>> separate redundant field to the geometry object, unless it's not redundant.
>>> Do we expect to have instances where there are 2 and 3D structures? In that
>>> case I guess having a dimensionality would be good for each object.
>>> Thoughts? Is there any reason we can't just keep the semicolons? That
>>> option might work too.
>>>
>>>
>>>
>>> Gerard's comments on this were:
>>>
>>>
>>>
>>> > I’d advocate for, a minimum, semi-colon separators, and I’d be in
>>> favor a redundant dimensions attribute (2,3, et. al.) so the human reader,
>>> who can only view a portion of SBML document, knows what they are looking
>>> at.
>>>
>>>
>>>
>>> So, that's two votes for semicolons, and one vote for a redundant
>>> dimensions attribute and one vote against a redundant dimensions
>>> attribute. Anyone else want to weigh in?
>>>
>>>
>>>
>>> The trade-off on the dimensions attribute is that if you don't include
>>> it, you have to look up the information elsewhere, which might be
>>> inconvenient, but that information is only defined once. If you do include
>>> it, you then have the information locally, but add another possibility of
>>> creating an invalid/inconsistent model. SBML core has gone different ways
>>> on this for different situations, but tends towards trying to only define
>>> things once. But I'm happy to go either way on this.
>>>
>>>
>>>
>>> As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those
>>> because that's what I last had VCell using. If this is still true, I
>>> suggest we all change over to what is in the spec and my new files will
>>> reflect that.
>>>
>>>
>>>
>>> Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent)
>>> another option in your program, and do you find it useful if so?
>>>
>>>
>>>
>>> On the rotation issue, one thing I noticed is that I'm using
>>> "rotationAxisX" rather than "rotateX" for the naming convention. Both are
>>> in the spec with the prior being in the UML and the latter being in the
>>> text. Which are we going with?
>>>
>>>
>>>
>>> Thanks for noticing this! I'm personally inclined to go with the the
>>> longer name, though actually, I like 'rotationAxisX' better than
>>> 'rotateAxisX', which is what the UML actually has. Anyone else have an
>>> opinion?
>>>
>>>
>>>
>>> -Lucian
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> sbml-spatial mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> sbml-spatial mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sbml-spatial mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
>>
>>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
>
>
|
|
From: Paul M. <pau...@us...> - 2014-09-30 18:05:07
|
Thanks, Lucian. Sure, if you know the dimensionality of the data (number of points) and each element has same size. But then you won't be able to do this without delimiters 1 3.21834 4 -3.1 5.034 0 unless you pad to equal length: 01.00000000 03.21834000 -3.10000000 05.03400000 00.00000000 which has all data elements of equal length, so now you can smash them together: 01.0000000003.21834000-3.1000000005.0340000000.00000000 Point is moot for binary formats where you know the bit length of each element. But in human-readable text, I don't know how you get around delimiters without a lot of extra padding to ensure equal length of each recorded datum. Agreed with Gerard that lists of points like that are a lot easier to read as he recorded them, although it looks to me like the delimiters there are " " (space) and "; " (semicolon space). Thanks -- Paul -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul Macklin, Ph.D. Assistant Professor of Research Medicine Center for Applied Molecular Medicine Keck School of Medicine University of Southern California Los Angeles, CA Founder and Co-Lead of the MultiCellDS Project *MultiCellDS*: http://MultiCellDS.org <http://multicellds.org/> / @MultiCellDS <http://www.twitter.com/MultiCellDS> *email*: Pau...@us... / Pau...@Ma... *web*: http://MathCancer.org <http://mathcancer.org/> *Twitter*: @MathCancer <http://www.twitter.com/MathCancer> *mobile*: +1 310-701-5785 *FAX*: +1 323-442-2764 On Tue, Sep 30, 2014 at 10:53 AM, Lucian Smith <luc...@gm...> wrote: > Well, you don't *have* to have any delimiters at all if you know the > dimensionality of the data; it would be a cross-check for validity and to > make it more easily viewable. I guess the field data does have 3D data in > it that could have different delimiters, but that data might be inherently > less viewable to begin with, and delimiters wouldn't help? As someone > mentioned here recently, that format has not actually been well defined yet > anyway; still need to hear back from Frank or Jim or someone who knows > what's going on there. > > The data in the elements we've been discussing so far in the > ParametricGeometry class are all lists of points in space, and lists of > vertexes of triangles or quadrilaterals, and would therefore both only need > a single delimiter. > > -Lucian > > On Tue, Sep 30, 2014 at 10:37 AM, Weatherby,Gerard <gwe...@uc...> > wrote: > >> A blank would be okay – presumably each level of delimiter would have >> to be different? >> >> >> >> -Gerard >> >> *From:* Lucian Smith [mailto:luc...@gm...] >> *Sent:* Tuesday, September 30, 2014 1:33 PM >> *To:* The SBML L3 Spatial Processes and Geometries package discussion >> list >> *Subject:* Re: [sbml-spatial] Examples? (array data) >> >> >> >> I would be fine with delimiters; if we went with the attribute-defined >> delimiter route ('delimiter=";"'), would we be OK with blank delimiters? >> (delimiter="" or delimiter=" " ?) Or other whitespace delimiters? >> >> >> >> Also, Frank, since you're on the implementation side of things here, >> would adding delimiters be straightforward to implement? Do you have an >> opinion about using them here? >> >> >> >> -Lucian >> >> >> >> On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...> >> wrote: >> >> If the general SBML standard is only say things once (normalized data), >> then I’m for sticking with that rather than doing things differently in >> different places. But I’m definitely for delimiters, either standardized or >> specified by attribute as suggested in another reply. >> >> -Gerard >> >> >> >> *From:* Lucian Smith [mailto:luc...@gm...] >> *Sent:* Monday, September 29, 2014 9:13 PM >> *To:* The SBML L3 Spatial Processes and Geometries package discussion >> list >> *Subject:* Re: [sbml-spatial] Examples? >> >> >> >> Trying to not miss the other topics in this discussion... >> >> >> >> On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote: >> >> Hi all, >> >> >> >> Sorry for the delay in response. Thanks a lot to Lucian for his work >> looking over those examples. I am remaking my scripts for the models at the >> moment. Although slightly annoying, I think it's ok to have to look up the >> dimensionality elsewhere in the document. I'm in favor of not adding a >> separate redundant field to the geometry object, unless it's not redundant. >> Do we expect to have instances where there are 2 and 3D structures? In that >> case I guess having a dimensionality would be good for each object. >> Thoughts? Is there any reason we can't just keep the semicolons? That >> option might work too. >> >> >> >> Gerard's comments on this were: >> >> >> >> > I’d advocate for, a minimum, semi-colon separators, and I’d be in >> favor a redundant dimensions attribute (2,3, et. al.) so the human reader, >> who can only view a portion of SBML document, knows what they are looking >> at. >> >> >> >> So, that's two votes for semicolons, and one vote for a redundant >> dimensions attribute and one vote against a redundant dimensions >> attribute. Anyone else want to weigh in? >> >> >> >> The trade-off on the dimensions attribute is that if you don't include >> it, you have to look up the information elsewhere, which might be >> inconvenient, but that information is only defined once. If you do include >> it, you then have the information locally, but add another possibility of >> creating an invalid/inconsistent model. SBML core has gone different ways >> on this for different situations, but tends towards trying to only define >> things once. But I'm happy to go either way on this. >> >> >> >> As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those >> because that's what I last had VCell using. If this is still true, I >> suggest we all change over to what is in the spec and my new files will >> reflect that. >> >> >> >> Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) >> another option in your program, and do you find it useful if so? >> >> >> >> On the rotation issue, one thing I noticed is that I'm using >> "rotationAxisX" rather than "rotateX" for the naming convention. Both are >> in the spec with the prior being in the UML and the latter being in the >> text. Which are we going with? >> >> >> >> Thanks for noticing this! I'm personally inclined to go with the the >> longer name, though actually, I like 'rotationAxisX' better than >> 'rotateAxisX', which is what the UML actually has. Anyone else have an >> opinion? >> >> >> >> -Lucian >> >> >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> _______________________________________________ >> sbml-spatial mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >> >> >> >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> _______________________________________________ >> sbml-spatial mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >> >> > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-spatial mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-spatial > > |
|
From: Weatherby,Gerard <gwe...@uc...> - 2014-09-30 17:58:07
|
A list of points is much easier to read (for the human) with two delimiters
1 1 1; 1 1 2 ; 1 2 2;
(with spaces between values and semi-colons between sets of values)
-Gerard
From: Lucian Smith [mailto:luc...@gm...]
Sent: Tuesday, September 30, 2014 1:53 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples? (array data)
Well, you don't *have* to have any delimiters at all if you know the dimensionality of the data; it would be a cross-check for validity and to make it more easily viewable. I guess the field data does have 3D data in it that could have different delimiters, but that data might be inherently less viewable to begin with, and delimiters wouldn't help? As someone mentioned here recently, that format has not actually been well defined yet anyway; still need to hear back from Frank or Jim or someone who knows what's going on there.
The data in the elements we've been discussing so far in the ParametricGeometry class are all lists of points in space, and lists of vertexes of triangles or quadrilaterals, and would therefore both only need a single delimiter.
-Lucian
On Tue, Sep 30, 2014 at 10:37 AM, Weatherby,Gerard <gwe...@uc...<mailto:gwe...@uc...>> wrote:
A blank would be okay – presumably each level of delimiter would have to be different?
-Gerard
From: Lucian Smith [mailto:luc...@gm...<mailto:luc...@gm...>]
Sent: Tuesday, September 30, 2014 1:33 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples? (array data)
I would be fine with delimiters; if we went with the attribute-defined delimiter route ('delimiter=";"'), would we be OK with blank delimiters? (delimiter="" or delimiter=" " ?) Or other whitespace delimiters?
Also, Frank, since you're on the implementation side of things here, would adding delimiters be straightforward to implement? Do you have an opinion about using them here?
-Lucian
On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...<mailto:gwe...@uc...>> wrote:
If the general SBML standard is only say things once (normalized data), then I’m for sticking with that rather than doing things differently in different places. But I’m definitely for delimiters, either standardized or specified by attribute as suggested in another reply.
-Gerard
From: Lucian Smith [mailto:luc...@gm...<mailto:luc...@gm...>]
Sent: Monday, September 29, 2014 9:13 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples?
Trying to not miss the other topics in this discussion...
On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...<mailto:de...@cm...>> wrote:
Hi all,
Sorry for the delay in response. Thanks a lot to Lucian for his work looking over those examples. I am remaking my scripts for the models at the moment. Although slightly annoying, I think it's ok to have to look up the dimensionality elsewhere in the document. I'm in favor of not adding a separate redundant field to the geometry object, unless it's not redundant. Do we expect to have instances where there are 2 and 3D structures? In that case I guess having a dimensionality would be good for each object. Thoughts? Is there any reason we can't just keep the semicolons? That option might work too.
Gerard's comments on this were:
> I’d advocate for, a minimum, semi-colon separators, and I’d be in favor a redundant dimensions attribute (2,3, et. al.) so the human reader, who can only view a portion of SBML document, knows what they are looking at.
So, that's two votes for semicolons, and one vote for a redundant dimensions attribute and one vote against a redundant dimensions attribute. Anyone else want to weigh in?
The trade-off on the dimensions attribute is that if you don't include it, you have to look up the information elsewhere, which might be inconvenient, but that information is only defined once. If you do include it, you then have the information locally, but add another possibility of creating an invalid/inconsistent model. SBML core has gone different ways on this for different situations, but tends towards trying to only define things once. But I'm happy to go either way on this.
As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because that's what I last had VCell using. If this is still true, I suggest we all change over to what is in the spec and my new files will reflect that.
Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) another option in your program, and do you find it useful if so?
On the rotation issue, one thing I noticed is that I'm using "rotationAxisX" rather than "rotateX" for the naming convention. Both are in the spec with the prior being in the UML and the latter being in the text. Which are we going with?
Thanks for noticing this! I'm personally inclined to go with the the longer name, though actually, I like 'rotationAxisX' better than 'rotateAxisX', which is what the UML actually has. Anyone else have an opinion?
-Lucian
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
sbml-spatial mailing list
sbm...@li...<mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-spatial
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
sbml-spatial mailing list
sbm...@li...<mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-spatial
|
|
From: Paul M. <pau...@us...> - 2014-09-30 17:55:25
|
Also very interested in Frank's perspective on it. You could make it an optional attribute, with default to delimiter=" " when not specified .... I'm not sure how you'd use a blank delimiter (no delimiter) without ensuring that all data elements in the array are of equal bit / character length. I'm guessing that I'm missing something there ... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul Macklin, Ph.D. Assistant Professor of Research Medicine Center for Applied Molecular Medicine Keck School of Medicine University of Southern California Los Angeles, CA Founder and Co-Lead of the MultiCellDS Project *MultiCellDS*: http://MultiCellDS.org <http://multicellds.org/> / @MultiCellDS <http://www.twitter.com/MultiCellDS> *email*: Pau...@us... / Pau...@Ma... *web*: http://MathCancer.org <http://mathcancer.org/> *Twitter*: @MathCancer <http://www.twitter.com/MathCancer> *mobile*: +1 310-701-5785 *FAX*: +1 323-442-2764 On Tue, Sep 30, 2014 at 10:33 AM, Lucian Smith <luc...@gm...> wrote: > I would be fine with delimiters; if we went with the attribute-defined > delimiter route ('delimiter=";"'), would we be OK with blank delimiters? > (delimiter="" or delimiter=" " ?) Or other whitespace delimiters? > > Also, Frank, since you're on the implementation side of things here, would > adding delimiters be straightforward to implement? Do you have an opinion > about using them here? > > -Lucian > > On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...> > wrote: > >> If the general SBML standard is only say things once (normalized data), >> then I’m for sticking with that rather than doing things differently in >> different places. But I’m definitely for delimiters, either standardized or >> specified by attribute as suggested in another reply. >> >> -Gerard >> >> >> >> *From:* Lucian Smith [mailto:luc...@gm...] >> *Sent:* Monday, September 29, 2014 9:13 PM >> *To:* The SBML L3 Spatial Processes and Geometries package discussion >> list >> *Subject:* Re: [sbml-spatial] Examples? >> >> >> >> Trying to not miss the other topics in this discussion... >> >> >> >> On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote: >> >> Hi all, >> >> >> >> Sorry for the delay in response. Thanks a lot to Lucian for his work >> looking over those examples. I am remaking my scripts for the models at the >> moment. Although slightly annoying, I think it's ok to have to look up the >> dimensionality elsewhere in the document. I'm in favor of not adding a >> separate redundant field to the geometry object, unless it's not redundant. >> Do we expect to have instances where there are 2 and 3D structures? In that >> case I guess having a dimensionality would be good for each object. >> Thoughts? Is there any reason we can't just keep the semicolons? That >> option might work too. >> >> >> >> Gerard's comments on this were: >> >> >> >> > I’d advocate for, a minimum, semi-colon separators, and I’d be in >> favor a redundant dimensions attribute (2,3, et. al.) so the human reader, >> who can only view a portion of SBML document, knows what they are looking >> at. >> >> >> >> So, that's two votes for semicolons, and one vote for a redundant >> dimensions attribute and one vote against a redundant dimensions >> attribute. Anyone else want to weigh in? >> >> >> >> The trade-off on the dimensions attribute is that if you don't include >> it, you have to look up the information elsewhere, which might be >> inconvenient, but that information is only defined once. If you do include >> it, you then have the information locally, but add another possibility of >> creating an invalid/inconsistent model. SBML core has gone different ways >> on this for different situations, but tends towards trying to only define >> things once. But I'm happy to go either way on this. >> >> >> >> As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those >> because that's what I last had VCell using. If this is still true, I >> suggest we all change over to what is in the spec and my new files will >> reflect that. >> >> >> >> Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) >> another option in your program, and do you find it useful if so? >> >> >> >> On the rotation issue, one thing I noticed is that I'm using >> "rotationAxisX" rather than "rotateX" for the naming convention. Both are >> in the spec with the prior being in the UML and the latter being in the >> text. Which are we going with? >> >> >> >> Thanks for noticing this! I'm personally inclined to go with the the >> longer name, though actually, I like 'rotationAxisX' better than >> 'rotateAxisX', which is what the UML actually has. Anyone else have an >> opinion? >> >> >> >> -Lucian >> >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> _______________________________________________ >> sbml-spatial mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-spatial >> >> > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-spatial mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-spatial > > |
|
From: Lucian S. <luc...@gm...> - 2014-09-30 17:53:28
|
Well, you don't *have* to have any delimiters at all if you know the
dimensionality of the data; it would be a cross-check for validity and to
make it more easily viewable. I guess the field data does have 3D data in
it that could have different delimiters, but that data might be inherently
less viewable to begin with, and delimiters wouldn't help? As someone
mentioned here recently, that format has not actually been well defined yet
anyway; still need to hear back from Frank or Jim or someone who knows
what's going on there.
The data in the elements we've been discussing so far in the
ParametricGeometry class are all lists of points in space, and lists of
vertexes of triangles or quadrilaterals, and would therefore both only need
a single delimiter.
-Lucian
On Tue, Sep 30, 2014 at 10:37 AM, Weatherby,Gerard <gwe...@uc...>
wrote:
> A blank would be okay – presumably each level of delimiter would have to
> be different?
>
>
>
> -Gerard
>
> *From:* Lucian Smith [mailto:luc...@gm...]
> *Sent:* Tuesday, September 30, 2014 1:33 PM
> *To:* The SBML L3 Spatial Processes and Geometries package discussion list
> *Subject:* Re: [sbml-spatial] Examples? (array data)
>
>
>
> I would be fine with delimiters; if we went with the attribute-defined
> delimiter route ('delimiter=";"'), would we be OK with blank delimiters?
> (delimiter="" or delimiter=" " ?) Or other whitespace delimiters?
>
>
>
> Also, Frank, since you're on the implementation side of things here, would
> adding delimiters be straightforward to implement? Do you have an opinion
> about using them here?
>
>
>
> -Lucian
>
>
>
> On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...>
> wrote:
>
> If the general SBML standard is only say things once (normalized data),
> then I’m for sticking with that rather than doing things differently in
> different places. But I’m definitely for delimiters, either standardized or
> specified by attribute as suggested in another reply.
>
> -Gerard
>
>
>
> *From:* Lucian Smith [mailto:luc...@gm...]
> *Sent:* Monday, September 29, 2014 9:13 PM
> *To:* The SBML L3 Spatial Processes and Geometries package discussion list
> *Subject:* Re: [sbml-spatial] Examples?
>
>
>
> Trying to not miss the other topics in this discussion...
>
>
>
> On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote:
>
> Hi all,
>
>
>
> Sorry for the delay in response. Thanks a lot to Lucian for his work
> looking over those examples. I am remaking my scripts for the models at the
> moment. Although slightly annoying, I think it's ok to have to look up the
> dimensionality elsewhere in the document. I'm in favor of not adding a
> separate redundant field to the geometry object, unless it's not redundant.
> Do we expect to have instances where there are 2 and 3D structures? In that
> case I guess having a dimensionality would be good for each object.
> Thoughts? Is there any reason we can't just keep the semicolons? That
> option might work too.
>
>
>
> Gerard's comments on this were:
>
>
>
> > I’d advocate for, a minimum, semi-colon separators, and I’d be in
> favor a redundant dimensions attribute (2,3, et. al.) so the human reader,
> who can only view a portion of SBML document, knows what they are looking
> at.
>
>
>
> So, that's two votes for semicolons, and one vote for a redundant
> dimensions attribute and one vote against a redundant dimensions
> attribute. Anyone else want to weigh in?
>
>
>
> The trade-off on the dimensions attribute is that if you don't include it,
> you have to look up the information elsewhere, which might be inconvenient,
> but that information is only defined once. If you do include it, you then
> have the information locally, but add another possibility of creating an
> invalid/inconsistent model. SBML core has gone different ways on this for
> different situations, but tends towards trying to only define things once.
> But I'm happy to go either way on this.
>
>
>
> As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those
> because that's what I last had VCell using. If this is still true, I
> suggest we all change over to what is in the spec and my new files will
> reflect that.
>
>
>
> Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent)
> another option in your program, and do you find it useful if so?
>
>
>
> On the rotation issue, one thing I noticed is that I'm using
> "rotationAxisX" rather than "rotateX" for the naming convention. Both are
> in the spec with the prior being in the UML and the latter being in the
> text. Which are we going with?
>
>
>
> Thanks for noticing this! I'm personally inclined to go with the the
> longer name, though actually, I like 'rotationAxisX' better than
> 'rotateAxisX', which is what the UML actually has. Anyone else have an
> opinion?
>
>
>
> -Lucian
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
>
>
|
|
From: Weatherby,Gerard <gwe...@uc...> - 2014-09-30 17:37:35
|
A blank would be okay – presumably each level of delimiter would have to be different?
-Gerard
From: Lucian Smith [mailto:luc...@gm...]
Sent: Tuesday, September 30, 2014 1:33 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples? (array data)
I would be fine with delimiters; if we went with the attribute-defined delimiter route ('delimiter=";"'), would we be OK with blank delimiters? (delimiter="" or delimiter=" " ?) Or other whitespace delimiters?
Also, Frank, since you're on the implementation side of things here, would adding delimiters be straightforward to implement? Do you have an opinion about using them here?
-Lucian
On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...<mailto:gwe...@uc...>> wrote:
If the general SBML standard is only say things once (normalized data), then I’m for sticking with that rather than doing things differently in different places. But I’m definitely for delimiters, either standardized or specified by attribute as suggested in another reply.
-Gerard
From: Lucian Smith [mailto:luc...@gm...<mailto:luc...@gm...>]
Sent: Monday, September 29, 2014 9:13 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples?
Trying to not miss the other topics in this discussion...
On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...<mailto:de...@cm...>> wrote:
Hi all,
Sorry for the delay in response. Thanks a lot to Lucian for his work looking over those examples. I am remaking my scripts for the models at the moment. Although slightly annoying, I think it's ok to have to look up the dimensionality elsewhere in the document. I'm in favor of not adding a separate redundant field to the geometry object, unless it's not redundant. Do we expect to have instances where there are 2 and 3D structures? In that case I guess having a dimensionality would be good for each object. Thoughts? Is there any reason we can't just keep the semicolons? That option might work too.
Gerard's comments on this were:
> I’d advocate for, a minimum, semi-colon separators, and I’d be in favor a redundant dimensions attribute (2,3, et. al.) so the human reader, who can only view a portion of SBML document, knows what they are looking at.
So, that's two votes for semicolons, and one vote for a redundant dimensions attribute and one vote against a redundant dimensions attribute. Anyone else want to weigh in?
The trade-off on the dimensions attribute is that if you don't include it, you have to look up the information elsewhere, which might be inconvenient, but that information is only defined once. If you do include it, you then have the information locally, but add another possibility of creating an invalid/inconsistent model. SBML core has gone different ways on this for different situations, but tends towards trying to only define things once. But I'm happy to go either way on this.
As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because that's what I last had VCell using. If this is still true, I suggest we all change over to what is in the spec and my new files will reflect that.
Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) another option in your program, and do you find it useful if so?
On the rotation issue, one thing I noticed is that I'm using "rotationAxisX" rather than "rotateX" for the naming convention. Both are in the spec with the prior being in the UML and the latter being in the text. Which are we going with?
Thanks for noticing this! I'm personally inclined to go with the the longer name, though actually, I like 'rotationAxisX' better than 'rotateAxisX', which is what the UML actually has. Anyone else have an opinion?
-Lucian
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
sbml-spatial mailing list
sbm...@li...<mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-spatial
|
|
From: Lucian S. <luc...@gm...> - 2014-09-30 17:33:30
|
I would be fine with delimiters; if we went with the attribute-defined
delimiter route ('delimiter=";"'), would we be OK with blank delimiters?
(delimiter="" or delimiter=" " ?) Or other whitespace delimiters?
Also, Frank, since you're on the implementation side of things here, would
adding delimiters be straightforward to implement? Do you have an opinion
about using them here?
-Lucian
On Tue, Sep 30, 2014 at 10:17 AM, Weatherby,Gerard <gwe...@uc...>
wrote:
> If the general SBML standard is only say things once (normalized data),
> then I’m for sticking with that rather than doing things differently in
> different places. But I’m definitely for delimiters, either standardized or
> specified by attribute as suggested in another reply.
>
> -Gerard
>
>
>
> *From:* Lucian Smith [mailto:luc...@gm...]
> *Sent:* Monday, September 29, 2014 9:13 PM
> *To:* The SBML L3 Spatial Processes and Geometries package discussion list
> *Subject:* Re: [sbml-spatial] Examples?
>
>
>
> Trying to not miss the other topics in this discussion...
>
>
>
> On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote:
>
> Hi all,
>
>
>
> Sorry for the delay in response. Thanks a lot to Lucian for his work
> looking over those examples. I am remaking my scripts for the models at the
> moment. Although slightly annoying, I think it's ok to have to look up the
> dimensionality elsewhere in the document. I'm in favor of not adding a
> separate redundant field to the geometry object, unless it's not redundant.
> Do we expect to have instances where there are 2 and 3D structures? In that
> case I guess having a dimensionality would be good for each object.
> Thoughts? Is there any reason we can't just keep the semicolons? That
> option might work too.
>
>
>
> Gerard's comments on this were:
>
>
>
> > I’d advocate for, a minimum, semi-colon separators, and I’d be in
> favor a redundant dimensions attribute (2,3, et. al.) so the human reader,
> who can only view a portion of SBML document, knows what they are looking
> at.
>
>
>
> So, that's two votes for semicolons, and one vote for a redundant
> dimensions attribute and one vote against a redundant dimensions
> attribute. Anyone else want to weigh in?
>
>
>
> The trade-off on the dimensions attribute is that if you don't include it,
> you have to look up the information elsewhere, which might be inconvenient,
> but that information is only defined once. If you do include it, you then
> have the information locally, but add another possibility of creating an
> invalid/inconsistent model. SBML core has gone different ways on this for
> different situations, but tends towards trying to only define things once.
> But I'm happy to go either way on this.
>
>
>
> As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those
> because that's what I last had VCell using. If this is still true, I
> suggest we all change over to what is in the spec and my new files will
> reflect that.
>
>
>
> Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent)
> another option in your program, and do you find it useful if so?
>
>
>
> On the rotation issue, one thing I noticed is that I'm using
> "rotationAxisX" rather than "rotateX" for the naming convention. Both are
> in the spec with the prior being in the UML and the latter being in the
> text. Which are we going with?
>
>
>
> Thanks for noticing this! I'm personally inclined to go with the the
> longer name, though actually, I like 'rotationAxisX' better than
> 'rotateAxisX', which is what the UML actually has. Anyone else have an
> opinion?
>
>
>
> -Lucian
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-spatial mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-spatial
>
>
|
|
From: Weatherby,Gerard <gwe...@uc...> - 2014-09-30 17:17:53
|
If the general SBML standard is only say things once (normalized data), then I’m for sticking with that rather than doing things differently in different places. But I’m definitely for delimiters, either standardized or specified by attribute as suggested in another reply. -Gerard From: Lucian Smith [mailto:luc...@gm...] Sent: Monday, September 29, 2014 9:13 PM To: The SBML L3 Spatial Processes and Geometries package discussion list Subject: Re: [sbml-spatial] Examples? Trying to not miss the other topics in this discussion... On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...<mailto:de...@cm...>> wrote: Hi all, Sorry for the delay in response. Thanks a lot to Lucian for his work looking over those examples. I am remaking my scripts for the models at the moment. Although slightly annoying, I think it's ok to have to look up the dimensionality elsewhere in the document. I'm in favor of not adding a separate redundant field to the geometry object, unless it's not redundant. Do we expect to have instances where there are 2 and 3D structures? In that case I guess having a dimensionality would be good for each object. Thoughts? Is there any reason we can't just keep the semicolons? That option might work too. Gerard's comments on this were: > I’d advocate for, a minimum, semi-colon separators, and I’d be in favor a redundant dimensions attribute (2,3, et. al.) so the human reader, who can only view a portion of SBML document, knows what they are looking at. So, that's two votes for semicolons, and one vote for a redundant dimensions attribute and one vote against a redundant dimensions attribute. Anyone else want to weigh in? The trade-off on the dimensions attribute is that if you don't include it, you have to look up the information elsewhere, which might be inconvenient, but that information is only defined once. If you do include it, you then have the information locally, but add another possibility of creating an invalid/inconsistent model. SBML core has gone different ways on this for different situations, but tends towards trying to only define things once. But I'm happy to go either way on this. As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because that's what I last had VCell using. If this is still true, I suggest we all change over to what is in the spec and my new files will reflect that. Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) another option in your program, and do you find it useful if so? On the rotation issue, one thing I noticed is that I'm using "rotationAxisX" rather than "rotateX" for the naming convention. Both are in the spec with the prior being in the UML and the latter being in the text. Which are we going with? Thanks for noticing this! I'm personally inclined to go with the the longer name, though actually, I like 'rotationAxisX' better than 'rotateAxisX', which is what the UML actually has. Anyone else have an opinion? -Lucian |
|
From: Paul M. <pau...@us...> - 2014-09-30 13:27:16
|
Regarding 4x4 affine: I'd suggest that it should be regarded as a numerical implementation detail and not a model or geometry specification detail. Yes a 4x4 matrix is necessary if you want to implement translation as a matrix multiply. But you could just as well implement translation as an overloaded operator+= on vector<double>. That should be up to the implementer and not hard cooked into the geometry description. As such I'd suggest only specifying the direction and distance (vector) of translation and leave implementation details up to the implementer. Likewise is suggest rotations should not necessarily be stated as all 16 elements of the affine transformation matrix but rather as the angle axis and origin. Etc. I definitely agree however that things sound be kept minimal / least complex as possible. Good luck on your release Jim! Best -- Paul On Sep 30, 2014 3:00 AM, "Samuel Friedman" <sam...@ca...> wrote: > Responses are in line: > > I'm picking this up mid-stream, out of context, and such, but are you sure >> you want to mix operations with rotate origin and rotate axis? this is >> pretty nonstandard. The rotation about a direction is using Euler angles, >> just another way of specifying a rotation about the origin. >> > > I'm aware we're looking into very non-standard rotations. I'm very > familiar with the standard z-x'-z' angles associated with Euler Angles. I > agree that this should be in a "best practices" part of the specification. > The question isn't, "What should people do?" but rather, "What can people > do?" What if I want to rotate something (e.g. a cell) around the vector > defined by a chemical gradient? What if I want to use a non-standard > ordering of rotation axes because I work in a field that uses non-standard > notation? > > We're also looking into rotation using the center of an object as the > origin for the rotation, not the coordinate system's origin. > > Typically, to perform this compound operation, you would translate >> (0,-1,-1), then rotate PI radians about the (1,1,1) vector using right hand >> rule, and then translate (0,1,1). > > > I also don't understand your example of translating an object, rotating > it, and the retranslating the object. As I understand it, I would move the > object, rotate it along some axis that is NOT the X-axis, and then move the > object back. I interpret your rotation about the (1,1,1) vector as being > centered either at the origin or at the center of my object. In either > case, I have a vector of (1,1,1) or (1,2,2), neither of which has the form > (X,0,0), which is what I would expect for an X-axis rotation. Even if I > wanted to transform along the (1,1,1) vector, why the extra movement? > > The axis/angle notation is the Euler angle notation, which avoids the >> complication of mis-ordering separate rotations about the x, y, and z axis >> (which don't commute). > > > The axis-angle representation is related to Euler Angles but does allow > for arbitrary axes centered at the origin. Check out: > http://en.wikipedia.org/wiki/Axis%E2%80%93angle_representation > > As for dealing with order dependence, that's the norm when dealing with > rotations. I think you might be able to get away with two rotations around > arbitrary axes centered at the origin instead of three rotations around > fixed axes. Looking at some math, there is no way you can do this with just > one rotation: > > Look at the matrix R here: > > http://en.wikipedia.org/wiki/Rotation_matrix#Rotation_matrix_from_axis_and_angle > > Look at the matrix Z_1 X_2 Z_3 in the table here: > http://en.wikipedia.org/wiki/Euler_angles#Rotation_matrix > > I don't see any easy way to put this together. I suspect we need three > angles and the ordering of the angles does matter IMO. > > >> If you want to combine operations of rotations and scaling, this can be >> accommodated using 3x3 cosine matrices and 3x3 diagonal scaling matrices >> (the result of a series of such operations can be computed as the product >> of the individual 3x3 matrices). >> > > Next question: How do you construct your 3x3 matrices? Do you want to > specify all 9 elements? Or do you want to specify the relevant component > parts? > > >> If you want to include translations, rotations and scaling, you need >> Affine transformations, represented as 4x4 matrices . These matrices are >> capable of uniformly representing rotations, translations, and scaling as >> 4x4 matrices ... and can be applied by matrix multiplications to get a >> resulting 4x4 matrix encoding all operations. These matrices are common in >> computer graphics (see OpenGL Programming Guide for a nice description). >> > > Thanks for the info about affine transformations. I haven't really seen > them before. They look quite nifty. Again, how should this be represented? > All 16 elements of a 4x4 matrix or the constituent parts? > > I would encourage everyone to stick to basic operations. Maybe scalex, >> scaley, scalez attributes can be given to the geometric primitives ... but >> I don't know if we need any other "conveniences" (redundancies). Right now >> I'm knee deep in sign conventions while generalizing VCell's >> electrophysiology. >> > > Rotations seem pretty basic to me. If I want to place an object with a > given orientation in a given location, then I need to deal with rotations > to get the orientation. > > Sam > > > -- > Dr. Samuel H. Friedman > University of Southern California Postdoctoral Scholar - Research > Associate > Center for Applied Molecular Medicine Keck School of Medicine > Email: sam...@ca... Phone: 323-442-2531 > 2250 Alcazar St Rm 259 Los Angeles, CA 90033 > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-spatial mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-spatial > > |
|
From: Samuel F. <sam...@ca...> - 2014-09-30 09:59:45
|
Responses are in line: I'm picking this up mid-stream, out of context, and such, but are you sure > you want to mix operations with rotate origin and rotate axis? this is > pretty nonstandard. The rotation about a direction is using Euler angles, > just another way of specifying a rotation about the origin. > I'm aware we're looking into very non-standard rotations. I'm very familiar with the standard z-x'-z' angles associated with Euler Angles. I agree that this should be in a "best practices" part of the specification. The question isn't, "What should people do?" but rather, "What can people do?" What if I want to rotate something (e.g. a cell) around the vector defined by a chemical gradient? What if I want to use a non-standard ordering of rotation axes because I work in a field that uses non-standard notation? We're also looking into rotation using the center of an object as the origin for the rotation, not the coordinate system's origin. Typically, to perform this compound operation, you would translate > (0,-1,-1), then rotate PI radians about the (1,1,1) vector using right hand > rule, and then translate (0,1,1). I also don't understand your example of translating an object, rotating it, and the retranslating the object. As I understand it, I would move the object, rotate it along some axis that is NOT the X-axis, and then move the object back. I interpret your rotation about the (1,1,1) vector as being centered either at the origin or at the center of my object. In either case, I have a vector of (1,1,1) or (1,2,2), neither of which has the form (X,0,0), which is what I would expect for an X-axis rotation. Even if I wanted to transform along the (1,1,1) vector, why the extra movement? The axis/angle notation is the Euler angle notation, which avoids the > complication of mis-ordering separate rotations about the x, y, and z axis > (which don't commute). The axis-angle representation is related to Euler Angles but does allow for arbitrary axes centered at the origin. Check out: http://en.wikipedia.org/wiki/Axis%E2%80%93angle_representation As for dealing with order dependence, that's the norm when dealing with rotations. I think you might be able to get away with two rotations around arbitrary axes centered at the origin instead of three rotations around fixed axes. Looking at some math, there is no way you can do this with just one rotation: Look at the matrix R here: http://en.wikipedia.org/wiki/Rotation_matrix#Rotation_matrix_from_axis_and_angle Look at the matrix Z_1 X_2 Z_3 in the table here: http://en.wikipedia.org/wiki/Euler_angles#Rotation_matrix I don't see any easy way to put this together. I suspect we need three angles and the ordering of the angles does matter IMO. > If you want to combine operations of rotations and scaling, this can be > accommodated using 3x3 cosine matrices and 3x3 diagonal scaling matrices > (the result of a series of such operations can be computed as the product > of the individual 3x3 matrices). > Next question: How do you construct your 3x3 matrices? Do you want to specify all 9 elements? Or do you want to specify the relevant component parts? > If you want to include translations, rotations and scaling, you need > Affine transformations, represented as 4x4 matrices . These matrices are > capable of uniformly representing rotations, translations, and scaling as > 4x4 matrices ... and can be applied by matrix multiplications to get a > resulting 4x4 matrix encoding all operations. These matrices are common in > computer graphics (see OpenGL Programming Guide for a nice description). > Thanks for the info about affine transformations. I haven't really seen them before. They look quite nifty. Again, how should this be represented? All 16 elements of a 4x4 matrix or the constituent parts? I would encourage everyone to stick to basic operations. Maybe scalex, > scaley, scalez attributes can be given to the geometric primitives ... but > I don't know if we need any other "conveniences" (redundancies). Right now > I'm knee deep in sign conventions while generalizing VCell's > electrophysiology. > Rotations seem pretty basic to me. If I want to place an object with a given orientation in a given location, then I need to deal with rotations to get the orientation. Sam -- Dr. Samuel H. Friedman University of Southern California Postdoctoral Scholar - Research Associate Center for Applied Molecular Medicine Keck School of Medicine Email: sam...@ca... Phone: 323-442-2531 2250 Alcazar St Rm 259 Los Angeles, CA 90033 |
|
From: Schaff,Jim <sc...@uc...> - 2014-09-30 02:31:41
|
Sorry for only reading this one so far .. in the middle of a release cycle.
I'm picking this up mid-stream, out of context, and such, but are you sure you want to mix operations with rotate origin and rotate axis? this is pretty nonstandard. The rotation about a direction is using Euler angles, just another way of specifying a rotation about the origin.
Typically, to perform this compound operation, you would translate (0,-1,-1), then rotate PI radians about the (1,1,1) vector using right hand rule, and then translate (0,1,1).
The axis/angle notation is the Euler angle notation, which avoids the complication of mis-ordering separate rotations about the x, y, and z axis (which don't commute).
If you want to combine operations of rotations and scaling, this can be accommodated using 3x3 cosine matrices and 3x3 diagonal scaling matrices (the result of a series of such operations can be computed as the product of the individual 3x3 matrices).
If you want to include translations, rotations and scaling, you need Affine transformations, represented as 4x4 matrices . These matrices are capable of uniformly representing rotations, translations, and scaling as 4x4 matrices ... and can be applied by matrix multiplications to get a resulting 4x4 matrix encoding all operations. These matrices are common in computer graphics (see OpenGL Programming Guide for a nice description).
I would encourage everyone to stick to basic operations. Maybe scalex, scaley, scalez attributes can be given to the geometric primitives ... but I don't know if we need any other "conveniences" (redundancies). Right now I'm knee deep in sign conventions while generalizing VCell's electrophysiology.
I'll be back to the discussion by Friday (after VCell's release).
Thanks,
Jim.
________________________________
From: Lucian Smith <luc...@gm...>
Sent: Monday, September 29, 2014 8:50 PM
To: The SBML L3 Spatial Processes and Geometries package discussion list
Subject: Re: [sbml-spatial] Examples?
Cool, sounds like we're converging.
On Mon, Sep 29, 2014 at 4:36 PM, Samuel Friedman <sam...@ca...<mailto:sam...@ca...>> wrote:
If you wanted a single rotation around a line parallel to the X axis and intersecting (1,1,1), (and wanted to avoid the need for a translation), you'd need something like the following:
<spatial:csgRotation rotateAxisOriginX="0" rotateAxisOriginY="1" rotateAxisOriginZ="1"
rotateAxisX ="1" rotateAxisY ="1" rotateAxisZ ="1"
rotateAngleInRadians="3.14159">
I think you mean:
<spatial:csgRotation rotateAxisOriginX="1" rotateAxisOriginY="1" rotateAxisOriginZ="1" rotateAxisX="1" rotateAxisY="0" rotateAxisZ="0" rotateAngleinRadians="3.14159">
Otherwise, you would have a vector that starts at (0,1,1) pointing towards (1,2,2). Vector addition is how I perceive this. What I wrote would have a vector that starts at (1,1,1) pointing towards (2,1,1).
I was imagining defining two points that make the base and direction of the vector (i.e. (0,1,1) towards (1,1,1)), but your way would obviously work, too. But it sounds like it might be best to just leave it off and let people use Translations instead.
You know the object's location because the CSGPrimitive class defines both a shape and a location for the object. In this case, the cube is defined (in Table 2 on page 29) as being a cube with sides of length 2, centered at the origin. It would exactly enclose the CSGPrimitive 'sphere', which has radius 1 and is also centered at the origin.
The CSGPrimitive class defines a default location for the object, the origin. It is sufficient to specify three rotations and one three dimensional translation. To be honest, I would use the translation separate from the rotateAxisOrigin. The reason being is that I think it is clearer to create an object at the origin, rotate it, and then move it over instead of rotating it around some non-origin centered axis (which will cause a translation) and then perform an additional translation. What needs to be clear is that this object must always have been created at the origin.
Hopefully, that is indeed clear in the spec (in the definition of CSGPrimitive); if not, let me know what bit is potentially confusing and I'll try to re-word it.
The question is: What happens when you get to dynamic spatial processes? If you need to move your cube and rotate your cube, do you still have the position information from the CSGPrimitive? It's not entirely obvious to me from the spec that CSGPrimitive has location information that could change over time.
Since that was outside the scope of the specification, I'm very sure that nobody has yet thought about this sort of thing. However, final shapes might not just be single primitives; they might be the intersection and/or union of various primitives, meaning that the original 'origin' of any given shape may well not make any sense any more. I would imagine that in any future dynamic/spatial package, one would need to define a new 'relative origin' for any given shape explicitly.
If I'm doing the spatial contortions in my head correctly, this means that the rotation around the Z axis 'looking up' out of the surface would be counterclockwise (as normal), making the rotation 'looking down' on the 2D surface as being clockwise.
Rotation looking down at the surface going counterclockwise is the convention for the right hand rule. Think about the unit circle. If you are looking up, everything is reversed, but then you'd be on the other side of the surface. These contortions are tricky.
Counterclockwise for 2D objects it is!
-Lucian
|
|
From: Lucian S. <luc...@gm...> - 2014-09-30 01:51:08
|
On Mon, Sep 29, 2014 at 6:41 PM, Samuel Friedman < sam...@ca...> wrote: > Agreed, we are converging. > > You know the object's location because the CSGPrimitive class defines both >>>> a shape and a location for the object. In this case, the cube is defined >>>> (in Table 2 on page 29) as being a cube with sides of length 2, centered at >>>> the origin. It would exactly enclose the CSGPrimitive 'sphere', which has >>>> radius 1 and is also centered at the origin. >>>> >>> >>> The CSGPrimitive class defines a default location for the object, the >>> origin. It is sufficient to specify three rotations and one three >>> dimensional translation. To be honest, I would use the translation separate >>> from the rotateAxisOrigin. The reason being is that I think it is clearer >>> to create an object at the origin, rotate it, and then move it over instead >>> of rotating it around some non-origin centered axis (which will cause a >>> translation) and then perform an additional translation. What needs to be >>> clear is that this object must always have been created at the origin. >>> >> >> Hopefully, that is indeed clear in the spec (in the definition of >> CSGPrimitive); if not, let me know what bit is potentially confusing and >> I'll try to re-word it. >> > > Not clear at all in the spec. As far as I can tell, CSGPrimitive only has > one member: PrimitiveKind. I'm looking at Release 0.88 for September 2014. > It does indeed only have one attribute. Here's what section 3.30 says now: 3.30 The CSGPrimitive class CSGPrimitive element represents the primitive geometric shapes that can be represented by the CSGeometry. These shapes are defined in Table 2 on the preceding page with a predefined orientation and fitting within the unit cube (+/- 1 in x, y, and z) or unit square (+/- 1 in x and y). This element has one required attribute : primitiveType of type PrimitiveKind. 3.30.1 The primitiveType attribute The primitiveType attribute is a required attribute that is of type PrimitiveKind. It represents one of the predefined primitive shapes. The meaning and definition of those types is listed in Table 2 on the previous page Then, if you look at Table 2, it defines each possible value: PrimitiveKind Dimensions Definition sphere 3 A sphere with radius 1, centered at the origin. cube 3 A cube with sides of length 2, centered at the origin. cylinder 3 A cylinder with a base circle of radius 1, centered at (0,0,-1), and top circle of radius 1, centered at (0,0,1). The height is 2. cone 3 A cone with a base circle of radius 1, centered at (0,0,-1), and top vertex at (0,0,1). circle 2 A circle with radius 1, centered at the origin. square 2 A square with sides of length 2, centered at the origin rightTriangle 2 A triangle with vertexes at (-1,-1), (-1,1), and (1,-1). Do you want more explanation somewhere? Let me think about this some more. I keep coming up with that the three > rotations and one translation are sufficient. They might be the most ideal > way of describing what is going on, but I think it is sufficient. > Sounds like a plan; obviously we'll need to finalize spatial itself before we can worry too much about adding dynamic to it. -Lucian |
|
From: Samuel F. <sam...@ca...> - 2014-09-30 01:41:33
|
Agreed, we are converging. You know the object's location because the CSGPrimitive class defines both >>> a shape and a location for the object. In this case, the cube is defined >>> (in Table 2 on page 29) as being a cube with sides of length 2, centered at >>> the origin. It would exactly enclose the CSGPrimitive 'sphere', which has >>> radius 1 and is also centered at the origin. >>> >> >> The CSGPrimitive class defines a default location for the object, the >> origin. It is sufficient to specify three rotations and one three >> dimensional translation. To be honest, I would use the translation separate >> from the rotateAxisOrigin. The reason being is that I think it is clearer >> to create an object at the origin, rotate it, and then move it over instead >> of rotating it around some non-origin centered axis (which will cause a >> translation) and then perform an additional translation. What needs to be >> clear is that this object must always have been created at the origin. >> > > Hopefully, that is indeed clear in the spec (in the definition of > CSGPrimitive); if not, let me know what bit is potentially confusing and > I'll try to re-word it. > Not clear at all in the spec. As far as I can tell, CSGPrimitive only has one member: PrimitiveKind. I'm looking at Release 0.88 for September 2014. > > >> The question is: What happens when you get to dynamic spatial processes? >> If you need to move your cube and rotate your cube, do you still have the >> position information from the CSGPrimitive? It's not entirely obvious to me >> from the spec that CSGPrimitive has location information that could change >> over time. >> > > Since that was outside the scope of the specification, I'm very sure that > nobody has yet thought about this sort of thing. However, final shapes > might not just be single primitives; they might be the intersection and/or > union of various primitives, meaning that the original 'origin' of any > given shape may well not make any sense any more. I would imagine that in > any future dynamic/spatial package, one would need to define a new > 'relative origin' for any given shape explicitly. > Let me think about this some more. I keep coming up with that the three rotations and one translation are sufficient. They might be the most ideal way of describing what is going on, but I think it is sufficient. Sam -- Dr. Samuel H. Friedman University of Southern California Postdoctoral Scholar - Research Associate Center for Applied Molecular Medicine Keck School of Medicine Email: sam...@ca... Phone: 323-442-2531 2250 Alcazar St Rm 259 Los Angeles, CA 90033 |
|
From: Lucian S. <luc...@gm...> - 2014-09-30 01:13:30
|
Trying to not miss the other topics in this discussion... On Mon, Sep 29, 2014 at 8:07 AM, Devin Sullivan <de...@cm...> wrote: > Hi all, > > Sorry for the delay in response. Thanks a lot to Lucian for his work > looking over those examples. I am remaking my scripts for the models at the > moment. Although slightly annoying, I think it's ok to have to look up the > dimensionality elsewhere in the document. I'm in favor of not adding a > separate redundant field to the geometry object, unless it's not redundant. > Do we expect to have instances where there are 2 and 3D structures? In that > case I guess having a dimensionality would be good for each object. > Thoughts? Is there any reason we can't just keep the semicolons? That > option might work too. > Gerard's comments on this were: > I’d advocate for, a minimum, semi-colon separators, and I’d be in favor a redundant dimensions attribute (2,3, et. al.) so the human reader, who can only view a portion of SBML document, knows what they are looking at. So, that's two votes for semicolons, and one vote for a redundant dimensions attribute and one vote against a redundant dimensions attribute. Anyone else want to weigh in? The trade-off on the dimensions attribute is that if you don't include it, you have to look up the information elsewhere, which might be inconvenient, but that information is only defined once. If you do include it, you then have the information locally, but add another possibility of creating an invalid/inconsistent model. SBML core has gone different ways on this for different situations, but tends towards trying to only define things once. But I'm happy to go either way on this. As for the SOLID_CUBE/SOLID_SPHERE CSG objects, I was using those because > that's what I last had VCell using. If this is still true, I suggest we all > change over to what is in the spec and my new files will reflect that. > Jim or Ion, any insight here? Is 'CUBE_SURFACE' (or the equivalent) another option in your program, and do you find it useful if so? > On the rotation issue, one thing I noticed is that I'm using > "rotationAxisX" rather than "rotateX" for the naming convention. Both are > in the spec with the prior being in the UML and the latter being in the > text. Which are we going with? > Thanks for noticing this! I'm personally inclined to go with the the longer name, though actually, I like 'rotationAxisX' better than 'rotateAxisX', which is what the UML actually has. Anyone else have an opinion? -Lucian |
|
From: Lucian S. <luc...@gm...> - 2014-09-30 00:50:56
|
Cool, sounds like we're converging. On Mon, Sep 29, 2014 at 4:36 PM, Samuel Friedman < sam...@ca...> wrote: > If you wanted a single rotation around a line parallel to the X axis and >> intersecting (1,1,1), (and wanted to avoid the need for a translation), >> you'd need something like the following: >> > >> <spatial:csgRotation rotateAxisOriginX="0" rotateAxisOriginY="1" >> rotateAxisOriginZ="1" >> rotateAxisX ="1" rotateAxisY >> ="1" rotateAxisZ ="1" >> rotateAngleInRadians="3.14159"> >> >> I think you mean: > > <spatial:csgRotation rotateAxisOriginX="1" rotateAxisOriginY="1" > rotateAxisOriginZ="1" rotateAxisX="1" rotateAxisY="0" rotateAxisZ="0" > rotateAngleinRadians="3.14159"> > > Otherwise, you would have a vector that starts at (0,1,1) pointing towards > (1,2,2). Vector addition is how I perceive this. What I wrote would have a > vector that starts at (1,1,1) pointing towards (2,1,1). > I was imagining defining two points that make the base and direction of the vector (i.e. (0,1,1) towards (1,1,1)), but your way would obviously work, too. But it sounds like it might be best to just leave it off and let people use Translations instead. > You know the object's location because the CSGPrimitive class defines both >> a shape and a location for the object. In this case, the cube is defined >> (in Table 2 on page 29) as being a cube with sides of length 2, centered at >> the origin. It would exactly enclose the CSGPrimitive 'sphere', which has >> radius 1 and is also centered at the origin. >> > > The CSGPrimitive class defines a default location for the object, the > origin. It is sufficient to specify three rotations and one three > dimensional translation. To be honest, I would use the translation separate > from the rotateAxisOrigin. The reason being is that I think it is clearer > to create an object at the origin, rotate it, and then move it over instead > of rotating it around some non-origin centered axis (which will cause a > translation) and then perform an additional translation. What needs to be > clear is that this object must always have been created at the origin. > Hopefully, that is indeed clear in the spec (in the definition of CSGPrimitive); if not, let me know what bit is potentially confusing and I'll try to re-word it. > The question is: What happens when you get to dynamic spatial processes? > If you need to move your cube and rotate your cube, do you still have the > position information from the CSGPrimitive? It's not entirely obvious to me > from the spec that CSGPrimitive has location information that could change > over time. > Since that was outside the scope of the specification, I'm very sure that nobody has yet thought about this sort of thing. However, final shapes might not just be single primitives; they might be the intersection and/or union of various primitives, meaning that the original 'origin' of any given shape may well not make any sense any more. I would imagine that in any future dynamic/spatial package, one would need to define a new 'relative origin' for any given shape explicitly. > If I'm doing the spatial contortions in my head correctly, this means that >> the rotation around the Z axis 'looking up' out of the surface would be >> counterclockwise (as normal), making the rotation 'looking down' on the 2D >> surface as being clockwise. >> >> > Rotation looking down at the surface going counterclockwise is the > convention for the right hand rule. Think about the unit circle. If you are > looking up, everything is reversed, but then you'd be on the other side of > the surface. These contortions are tricky. > Counterclockwise for 2D objects it is! -Lucian |
|
From: Samuel F. <sam...@ca...> - 2014-09-29 23:37:21
|
>
> OK, I think I now understand. However, I don't think the spec currently
> allows rotation around *any* arbitrary axis, merely any axis that goes
> through the origin, making other rotations require an additional
> translation. To use your example, the spec allows you to define rotation
> around the actual X axis ('rotating at (0,0,0)' in your terminology), but
> does *not* allow rotating along an axis parallel to the X axis that
> intersects point (1,1,1). If you define your csgRotation object as:
>
>
I understand and accept what you mean now. I indeed meant arbitrary axis as
long as that axis is centered at the origin.
> <spatial:csgRotation rotateAxisX="1" rotateAxisY="1" rotateAxisZ="1"
> rotateAngleInRadians="3.14159">
>
> This would actually define rotation around the diagonal line coming out
> from the origin and intersecting point (1,1,1), which is not (I believe)
> what you intended.
>
>
We agree. I thought I had written
<spatial:csgRotation rotateAxisX="1" rotateAxisY="0" rotateAxisZ="0"
rotateAngleInRadians="3.14159">
> If you wanted a single rotation around a line parallel to the X axis and
> intersecting (1,1,1), (and wanted to avoid the need for a translation),
> you'd need something like the following:
>
> <spatial:csgRotation rotateAxisOriginX="0" rotateAxisOriginY="1"
> rotateAxisOriginZ="1"
> rotateAxisX ="1" rotateAxisY
> ="1" rotateAxisZ ="1"
> rotateAngleInRadians="3.14159">
>
> Do we want that? Or should we just tell people to use a translation?
>
I think you mean:
<spatial:csgRotation rotateAxisOriginX="1" rotateAxisOriginY="1"
rotateAxisOriginZ="1" rotateAxisX="1" rotateAxisY="0" rotateAxisZ="0"
rotateAngleinRadians="3.14159">
Otherwise, you would have a vector that starts at (0,1,1) pointing towards
(1,2,2). Vector addition is how I perceive this. What I wrote would have a
vector that starts at (1,1,1) pointing towards (2,1,1).
> You know the object's location because the CSGPrimitive class defines both
> a shape and a location for the object. In this case, the cube is defined
> (in Table 2 on page 29) as being a cube with sides of length 2, centered at
> the origin. It would exactly enclose the CSGPrimitive 'sphere', which has
> radius 1 and is also centered at the origin.
>
The CSGPrimitive class defines a default location for the object, the
origin. It is sufficient to specify three rotations and one three
dimensional translation. To be honest, I would use the translation separate
from the rotateAxisOrigin. The reason being is that I think it is clearer
to create an object at the origin, rotate it, and then move it over instead
of rotating it around some non-origin centered axis (which will cause a
translation) and then perform an additional translation. What needs to be
clear is that this object must always have been created at the origin.
The question is: What happens when you get to dynamic spatial processes? If
you need to move your cube and rotate your cube, do you still have the
position information from the CSGPrimitive? It's not entirely obvious to me
from the spec that CSGPrimitive has location information that could change
over time.
If I'm doing the spatial contortions in my head correctly, this means that
> the rotation around the Z axis 'looking up' out of the surface would be
> counterclockwise (as normal), making the rotation 'looking down' on the 2D
> surface as being clockwise.
>
>
Rotation looking down at the surface going counterclockwise is the
convention for the right hand rule. Think about the unit circle. If you are
looking up, everything is reversed, but then you'd be on the other side of
the surface. These contortions are tricky.
--
Dr. Samuel H. Friedman
University of Southern California Postdoctoral Scholar - Research
Associate
Center for Applied Molecular Medicine Keck School of Medicine
Email: sam...@ca... Phone: 323-442-2531
2250 Alcazar St Rm 259 Los Angeles, CA 90033
|
5 messages has been excluded from this view by a project administrator.