Menu
▾
▴
sed-ml-discuss — Migrating to google groups: https://groups.google.com/d/forum/sed-ml-discuss
This list is closed, nobody may subscribe to it.
| 2008 |
Jan
(1) |
Feb
(35) |
Mar
(41) |
Apr
(4) |
May
(19) |
Jun
(26) |
Jul
(3) |
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(49) |
Feb
(15) |
Mar
(17) |
Apr
(7) |
May
(26) |
Jun
(1) |
Jul
(5) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(1) |
Mar
(29) |
Apr
(4) |
May
(31) |
Jun
(46) |
Jul
|
Aug
(5) |
Sep
(3) |
Oct
(2) |
Nov
(15) |
Dec
|
| 2011 |
Jan
(8) |
Feb
(1) |
Mar
(6) |
Apr
(10) |
May
(17) |
Jun
(23) |
Jul
(5) |
Aug
(3) |
Sep
(28) |
Oct
(41) |
Nov
(20) |
Dec
(1) |
| 2012 |
Jan
(20) |
Feb
(15) |
Mar
(1) |
Apr
(1) |
May
(8) |
Jun
(3) |
Jul
(9) |
Aug
(10) |
Sep
(1) |
Oct
(2) |
Nov
(5) |
Dec
(8) |
| 2013 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(16) |
May
(13) |
Jun
(6) |
Jul
(1) |
Aug
(2) |
Sep
(3) |
Oct
(2) |
Nov
(6) |
Dec
(2) |
| 2014 |
Jan
(4) |
Feb
(5) |
Mar
(15) |
Apr
(16) |
May
|
Jun
(6) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(13) |
Dec
(8) |
| 2015 |
Jan
(7) |
Feb
|
Mar
(3) |
Apr
|
May
(6) |
Jun
(24) |
Jul
(3) |
Aug
(10) |
Sep
(36) |
Oct
(3) |
Nov
|
Dec
(39) |
| 2016 |
Jan
(9) |
Feb
(38) |
Mar
(25) |
Apr
(3) |
May
(12) |
Jun
(5) |
Jul
(40) |
Aug
(13) |
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(29) |
Jun
(26) |
Jul
(12) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
|
From: David N. <dav...@gm...> - 2017-10-22 14:57:16
|
Hi all, Just a reminder that we will shut down this list soon. Please migrate over to the google group if you have not yet done so. Cheers, David. On 28 June 2017 at 19:49, David Nickerson <dav...@gm...> wrote: > Hi all, > > We are planning to migrate the SED-ML discussion list to google > groups: https://groups.google.com/d/forum/sed-ml-discuss > > Due to changes in sourceforge policy, we are no longer able to see who > is subscribed to this list and therefore unable to migrate people over > to the google group. So if you can please head over to the group and > sign up and then unsubscribe from this list. > > We will allow a couple of months for the transition during which time > the editors will endeavour to make sure messages are available via > both this sourceforge list and the new google group. The website will > be updated with the new details shortly. The current list archive will > remain on sourceforge. > > > Thanks, > David. -- David Nickerson about.me/david.nickerson |
|
From: Matthias K. <kon...@go...> - 2017-10-08 23:35:42
|
Dear SED-ML community, The SED-ML Editors are pleased to announce that a* release of the SED-ML Level 1 Version 3 (L1V3) *specification is now available. You can find the document attached and for download at https://sed-ml.github.io/specifications.html *Major changes are:* - support for Data in simulation experiments - updated and clarified UML diagrams - fixing all issues reported for the L1V2 spec In addition we now provide: - all specification examples as COMBINE archives with results available for download from https://sed-ml.github.io/examples.html - demonstrate execution of all specification examples with two implementations (SED-ML web tools & tellurium) In addition we already are planning and discussing SED-ML L1V4 features. The list of features which will be discussed during COMBINE https://github.com/sed-ml/sed-ml/issues?utf8=%E2%9C%93&q=is% 3Aissue%20is%3Aopen%20label%3Afeature%20label%3AL1V4 Please feel free to comment on the issues and give input. A first early draft of L1V4 is now also available. This includes the latest draft figures and changes discussed during HARMONY2017. The document can be found at https://github.com/SED-ML/sed-ml/raw/master/specification/level-1-version-4/sed-ml-L1V4.pdf Best regards, Matthias (on behalf of everyone) -- Dr. Matthias König Junior Group Leader LiSyM - Systems Medicine of the Liver Humboldt-University Berlin, Institute of Biology, Institute for Theoretical Biology https://www.livermetabolism.com kon...@go... Tel: +49 30 20938450 Tel: +49 176 81168480 |
|
From: Herbert S. <uw....@gm...> - 2017-10-03 14:35:38
|
Great news! Herbert On Tue, Oct 3, 2017 at 1:02 AM Matthias König via SED-ML-discuss < sed...@li...> wrote: > Dear SED-ML community, > > The SED-ML Editors are pleased to announce that a* release candidate of > the SED-ML Level 1 Version 3 (L1V3) *specification is now available. You > can find the document attached and for download at > https://sed-ml.github.io/specifications.html > > *Major changes are:* > - support for Data in simulation experiments > - updated and clarified UML diagrams > - fixing all issues reported for the L1V2 spec > In addition we now provide: > - all specification examples as COMBINE archives with results (which will > be released with the specification) > - demonstrate execution of all specification examples with two > implementations (SED-ML web tools & tellurium) > > We are planning on releasing SED-ML L1V3 before COMBINE, so we kindly ask > you for feedback until > *Friday 6th, October 24.00 MESZ* > Please report any typos, unclear formulations, incorrect formating, > incorrect examples, unclear UML diagrams, .... > This round of input from the community is for minor changes only. > > For larger issues not covered by the scope of L1V3 please open an issue on > https://github.com/sed-ml/sed-ml/issues > > In addition we already are planning and discussing SED-ML L1V4 features. > The list of features which will be discussed during COMBINE > > https://github.com/sed-ml/sed-ml/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Afeature%20label%3AL1V4 > > Please feel free to comment on the issues and give input. > > Best regards, > Matthias > (on behalf of everyone) > > > -- > Dr. Matthias König > Junior Group Leader LiSyM - Systems Medicine of the Liver > Humboldt-University Berlin, Institute of Biology, Institute for > Theoretical Biology > https://www.livermetabolism.com > kon...@go... > Tel: +49 30 20938450 > Tel: +49 176 81168480 > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > |
|
From: Matthias K. <kon...@go...> - 2017-10-02 23:07:37
|
Dear SED-ML community, The SED-ML Editors are pleased to announce that a* release candidate of the SED-ML Level 1 Version 3 (L1V3) *specification is now available. You can find the document attached and for download at https://sed-ml.github.io/specifications.html *Major changes are:* - support for Data in simulation experiments - updated and clarified UML diagrams - fixing all issues reported for the L1V2 spec In addition we now provide: - all specification examples as COMBINE archives with results (which will be released with the specification) - demonstrate execution of all specification examples with two implementations (SED-ML web tools & tellurium) We are planning on releasing SED-ML L1V3 before COMBINE, so we kindly ask you for feedback until *Friday 6th, October 24.00 MESZ* Please report any typos, unclear formulations, incorrect formating, incorrect examples, unclear UML diagrams, .... This round of input from the community is for minor changes only. For larger issues not covered by the scope of L1V3 please open an issue on https://github.com/sed-ml/sed-ml/issues In addition we already are planning and discussing SED-ML L1V4 features. The list of features which will be discussed during COMBINE https://github.com/sed-ml/sed-ml/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Afeature%20label%3AL1V4 Please feel free to comment on the issues and give input. Best regards, Matthias (on behalf of everyone) -- Dr. Matthias König Junior Group Leader LiSyM - Systems Medicine of the Liver Humboldt-University Berlin, Institute of Biology, Institute for Theoretical Biology https://www.livermetabolism.com kon...@go... Tel: +49 30 20938450 Tel: +49 176 81168480 |
|
From: David N. <dav...@gm...> - 2017-07-21 02:57:22
|
Hi all, Just a reminder that all SED-ML discussions should now be happening over at: https://groups.google.com/forum/#!forum/sed-ml-discuss. Please make sure you subscribe to that google group and then feel free to unsubscribed from this one. Cheers, David. |
|
From: Lucian S. <luc...@gm...> - 2017-07-18 18:05:14
|
Just to summarize the proposals I've seen so far, there are at least four possibilities on the table for repeating SED-ML runs: 1) Introduce a new KiSAO term, and use it like any other KiSAO parameter. 2) Introduce a new attribute to the SED-ML 'Task' class that would tell you how many times to repeat the Task. 3) Introduce a new attribute to the SED-ML 'RepeatedTask' class that would be a 'simpler' way of repeating tasks. 4) Just use the 'RepeatedTask' class as-is to repeat tasks. Chris is a staunch advocate of approach 1 and/or 2. I am not convinced we need anything other than option 4. Both of us agree that it would be best if there was exactly one way to encode this information: neither of us want one group of people using approach 1 while a different group of people use approach 4, for example. If KiSAO did indeed add the term, I would prefer SED-ML users use that and not option 2. The seed and the resetting thereof is a completely different issue, which needs to be addressed in SED-ML, but as noted, the term is indeed already in KiSAO; we just need to clarify its semantics when we use it: https://github.com/SED-ML/sed-ml/issues/30 (By the way--I've the new google groups list to this email's cc list, but did not remove the sourceforge list, in the vain hope that perhaps some day this discussion will be readable on one archive or the other.) -Lucian |
|
From: Herbert S. <uw....@gm...> - 2017-07-18 17:45:26
|
I did read through the conversation and it seemed that Lucian didn't seem convinced, that's why I said that consenus wasn't clear. How many implementations do we have of multiple stochastic runs? I don't think our sedml support handles multiple stochastic runs. Herbert On Tue, Jul 18, 2017 at 10:28 AM, Chris Myers <my...@ec...> wrote: > Herbert, Nicolas: please read the thread on github. I think that discussion clears things up in terms of my position. > > I do use the Kisao term for SEED. My point is that a stochastic simulation is semantically a Task NOT a RepeatedTask. This is because you need to think of a stochastic simulation as a single indivisible Task and not several Task in a loop. They are not semantically equivalent. > > Even if we tried to change RepeatedTask to match the semantics, which in my opinion I’m not sure it makes any sense, we are still left with the fact that you end up using a very complicated object to specify a very simple thing. > > Cheers, > > Chris > >> On Jul 18, 2017, at 11:12 AM, David Nickerson <dav...@gm...> wrote: >> >> Just to provide the link to the github issue where there has been some >> discussion relevant to this thread: >> https://github.com/SED-ML/sed-ml/issues/22. >> >> >> On 19 July 2017 at 05:08, Herbert Sauro <uw....@gm...> wrote: >>> Chris can you give your arguments for needing a kiaso term for the number of >>> runs? I can't decide whether the size of the ensemble is part of the >>> algorithm or not. Usually it's not. >>> >>> Unfortunately this wasn't discussed at harmony. There should be a wider >>> discussion on how to deal with ensemble runs for stochastic systems since >>> many of use will be affected. True, we already have repeated tasks but I >>> can't remember the arguments against using that for stochastic multiple >>> runs. >>> >>> Herbert >>> >>> On Tue, Jul 18, 2017 at 1:23 AM Nicolas Le Novere <n.l...@gm...> >>> wrote: >>>> >>>> Hi Chris, >>>> >>>> Last I heard, Anna was kind enough to update KiSAO when a new request >>>> came. >>>> >>>> What I am unclear about is where in KiSAO, would you like to put this? The >>>> number of run looks like a SED-ML attribute rather than a KiSAO term. >>>> Actually I thought that this was already covered by the current structures >>>> supporting repeated simulations. >>>> >>>> On 13/07/17 23:09, Chris Myers wrote: >>>>> Who maintains KISAO? I would like to get this added ASAP. It is >>>>> critical if we want SED-ML to support stochastic simulation properly. >>>>> >>>>> Chris >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> *From: *"Chris Myers" <cc...@us... >>>>>> <mailto:cc...@us...>> >>>>>> *Subject: **[kisao:feature-requests] #31 Number of Runs* >>>>>> *Date: *July 13, 2017 at 4:02:19 PM MDT >>>>>> *To: *"Ticket 31" <31...@fe... >>>>>> <mailto:31...@fe...>> >>>>>> *Reply-To: *"Ticket 31" <31...@fe... >>>>>> <mailto:31...@fe...>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >>>>>> >>>>>> *[feature-requests:#31] >>>>>> <https://sourceforge.net/p/kisao/feature-requests/31/> Number of Runs* >>>>>> >>>>>> *Status:* open >>>>>> *Created:* Thu Jul 13, 2017 10:02 PM UTC by Chris Myers >>>>>> *Last Updated:* Thu Jul 13, 2017 10:02 PM UTC >>>>>> *Owner:* nobody >>>>>> >>>>>> This should indicate the number of runs that a simulation should >>>>>> perform. It would typically be used to specify the number of runs for a >>>>>> stochastic simulation. >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >>>>>> >>>>>> Sent from sourceforge.net <http://sourceforge.net> because you >>>>>> indicated interest in https://sourceforge.net/p/kisao/feature-requests/31/ >>>>>> >>>>>> To unsubscribe from further messages, please visit >>>>>> https://sourceforge.net/auth/subscriptions/ >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Nicolas LE NOVERE, >>>> The Babraham Institute, Babraham Campus Cambridge, CB22 3AT >>>> Tel: +441223496433 Mob:+447833147074 http://lenoverelab.org >>>> orcid.org//0000-0002-6309-7327 Skype:n.lenovere twitter:@lenovere >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> SED-ML-discuss mailing list >>>> SED...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> SED-ML-discuss mailing list >>> SED...@li... >>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >>> >> >> >> >> -- >> >> >> David Nickerson >> about.me/david.nickerson > |
|
From: Herbert S. <uw....@gm...> - 2017-07-18 17:26:50
|
Thanks for that, very useful, seems there is no clear consensus at the moment. from my point of view I'd need to do some implementations to see how the different possibilities pan out. We could probably do some test in August. I assume there is sufficient post processing semantics to compute means and sds? Also I assume the kiaso terms are rich enough to specify the stochastic simulation alogorithm. As far as I am aware, to compute the mean and sd, the simulation points need to be on a grid. In sedml where does this happen, on the Kisao term? Herbert On Tue, Jul 18, 2017 at 10:13 AM David Nickerson <dav...@gm...> wrote: > Just to provide the link to the github issue where there has been some > discussion relevant to this thread: > https://github.com/SED-ML/sed-ml/issues/22. > > > On 19 July 2017 at 05:08, Herbert Sauro <uw....@gm...> wrote: > > Chris can you give your arguments for needing a kiaso term for the > number of > > runs? I can't decide whether the size of the ensemble is part of the > > algorithm or not. Usually it's not. > > > > Unfortunately this wasn't discussed at harmony. There should be a wider > > discussion on how to deal with ensemble runs for stochastic systems since > > many of use will be affected. True, we already have repeated tasks but I > > can't remember the arguments against using that for stochastic multiple > > runs. > > > > Herbert > > > > On Tue, Jul 18, 2017 at 1:23 AM Nicolas Le Novere <n.l...@gm...> > > wrote: > >> > >> Hi Chris, > >> > >> Last I heard, Anna was kind enough to update KiSAO when a new request > >> came. > >> > >> What I am unclear about is where in KiSAO, would you like to put this? > The > >> number of run looks like a SED-ML attribute rather than a KiSAO term. > >> Actually I thought that this was already covered by the current > structures > >> supporting repeated simulations. > >> > >> On 13/07/17 23:09, Chris Myers wrote: > >> > Who maintains KISAO? I would like to get this added ASAP. It is > >> > critical if we want SED-ML to support stochastic simulation properly. > >> > > >> > Chris > >> > > >> >> Begin forwarded message: > >> >> > >> >> *From: *"Chris Myers" <cc...@us... > >> >> <mailto:cc...@us...>> > >> >> *Subject: **[kisao:feature-requests] #31 Number of Runs* > >> >> *Date: *July 13, 2017 at 4:02:19 PM MDT > >> >> *To: *"Ticket 31" <31...@fe... > >> >> <mailto:31...@fe...>> > >> >> *Reply-To: *"Ticket 31" <31...@fe... > >> >> <mailto:31...@fe...>> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > >> >> > >> >> *[feature-requests:#31] > >> >> <https://sourceforge.net/p/kisao/feature-requests/31/> Number of > Runs* > >> >> > >> >> *Status:* open > >> >> *Created:* Thu Jul 13, 2017 10:02 PM UTC by Chris Myers > >> >> *Last Updated:* Thu Jul 13, 2017 10:02 PM UTC > >> >> *Owner:* nobody > >> >> > >> >> This should indicate the number of runs that a simulation should > >> >> perform. It would typically be used to specify the number of runs > for a > >> >> stochastic simulation. > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > >> >> > >> >> Sent from sourceforge.net <http://sourceforge.net> because you > >> >> indicated interest in > https://sourceforge.net/p/kisao/feature-requests/31/ > >> >> > >> >> To unsubscribe from further messages, please visit > >> >> https://sourceforge.net/auth/subscriptions/ > >> >> > >> > > >> > >> > >> -- > >> Nicolas LE NOVERE, > >> The Babraham Institute, Babraham Campus Cambridge, CB22 3AT > >> Tel: +441223496433 Mob:+447833147074 http://lenoverelab.org > >> orcid.org//0000-0002-6309-7327 Skype:n.lenovere twitter:@lenovere > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> _______________________________________________ > >> SED-ML-discuss mailing list > >> SED...@li... > >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > SED-ML-discuss mailing list > > SED...@li... > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > > -- > > > David Nickerson > about.me/david.nickerson > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > |
|
From: David N. <dav...@gm...> - 2017-07-18 17:13:20
|
Just to provide the link to the github issue where there has been some discussion relevant to this thread: https://github.com/SED-ML/sed-ml/issues/22. On 19 July 2017 at 05:08, Herbert Sauro <uw....@gm...> wrote: > Chris can you give your arguments for needing a kiaso term for the number of > runs? I can't decide whether the size of the ensemble is part of the > algorithm or not. Usually it's not. > > Unfortunately this wasn't discussed at harmony. There should be a wider > discussion on how to deal with ensemble runs for stochastic systems since > many of use will be affected. True, we already have repeated tasks but I > can't remember the arguments against using that for stochastic multiple > runs. > > Herbert > > On Tue, Jul 18, 2017 at 1:23 AM Nicolas Le Novere <n.l...@gm...> > wrote: >> >> Hi Chris, >> >> Last I heard, Anna was kind enough to update KiSAO when a new request >> came. >> >> What I am unclear about is where in KiSAO, would you like to put this? The >> number of run looks like a SED-ML attribute rather than a KiSAO term. >> Actually I thought that this was already covered by the current structures >> supporting repeated simulations. >> >> On 13/07/17 23:09, Chris Myers wrote: >> > Who maintains KISAO? I would like to get this added ASAP. It is >> > critical if we want SED-ML to support stochastic simulation properly. >> > >> > Chris >> > >> >> Begin forwarded message: >> >> >> >> *From: *"Chris Myers" <cc...@us... >> >> <mailto:cc...@us...>> >> >> *Subject: **[kisao:feature-requests] #31 Number of Runs* >> >> *Date: *July 13, 2017 at 4:02:19 PM MDT >> >> *To: *"Ticket 31" <31...@fe... >> >> <mailto:31...@fe...>> >> >> *Reply-To: *"Ticket 31" <31...@fe... >> >> <mailto:31...@fe...>> >> >> >> >> >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> >> >> >> *[feature-requests:#31] >> >> <https://sourceforge.net/p/kisao/feature-requests/31/> Number of Runs* >> >> >> >> *Status:* open >> >> *Created:* Thu Jul 13, 2017 10:02 PM UTC by Chris Myers >> >> *Last Updated:* Thu Jul 13, 2017 10:02 PM UTC >> >> *Owner:* nobody >> >> >> >> This should indicate the number of runs that a simulation should >> >> perform. It would typically be used to specify the number of runs for a >> >> stochastic simulation. >> >> >> >> >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> >> >> >> Sent from sourceforge.net <http://sourceforge.net> because you >> >> indicated interest in https://sourceforge.net/p/kisao/feature-requests/31/ >> >> >> >> To unsubscribe from further messages, please visit >> >> https://sourceforge.net/auth/subscriptions/ >> >> >> > >> >> >> -- >> Nicolas LE NOVERE, >> The Babraham Institute, Babraham Campus Cambridge, CB22 3AT >> Tel: +441223496433 Mob:+447833147074 http://lenoverelab.org >> orcid.org//0000-0002-6309-7327 Skype:n.lenovere twitter:@lenovere >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> SED-ML-discuss mailing list >> SED...@li... >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > -- David Nickerson about.me/david.nickerson |
|
From: Herbert S. <uw....@gm...> - 2017-07-18 17:08:53
|
Chris can you give your arguments for needing a kiaso term for the number of runs? I can't decide whether the size of the ensemble is part of the algorithm or not. Usually it's not. Unfortunately this wasn't discussed at harmony. There should be a wider discussion on how to deal with ensemble runs for stochastic systems since many of use will be affected. True, we already have repeated tasks but I can't remember the arguments against using that for stochastic multiple runs. Herbert On Tue, Jul 18, 2017 at 1:23 AM Nicolas Le Novere <n.l...@gm...> wrote: > Hi Chris, > > Last I heard, Anna was kind enough to update KiSAO when a new request came. > > What I am unclear about is where in KiSAO, would you like to put this? The > number of run looks like a SED-ML attribute rather than a KiSAO term. > Actually I thought that this was already covered by the current structures > supporting repeated simulations. > > On 13/07/17 23:09, Chris Myers wrote: > > Who maintains KISAO? I would like to get this added ASAP. It is > critical if we want SED-ML to support stochastic simulation properly. > > > > Chris > > > >> Begin forwarded message: > >> > >> *From: *"Chris Myers" <cc...@us... <mailto: > cc...@us...>> > >> *Subject: **[kisao:feature-requests] #31 Number of Runs* > >> *Date: *July 13, 2017 at 4:02:19 PM MDT > >> *To: *"Ticket 31" <31...@fe... <mailto: > 31...@fe...>> > >> *Reply-To: *"Ticket 31" <31...@fe... <mailto: > 31...@fe...>> > >> > >> > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > >> > >> *[feature-requests:#31] < > https://sourceforge.net/p/kisao/feature-requests/31/> Number of Runs* > >> > >> *Status:* open > >> *Created:* Thu Jul 13, 2017 10:02 PM UTC by Chris Myers > >> *Last Updated:* Thu Jul 13, 2017 10:02 PM UTC > >> *Owner:* nobody > >> > >> This should indicate the number of runs that a simulation should > perform. It would typically be used to specify the number of runs for a > stochastic simulation. > >> > >> > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > >> > >> Sent from sourceforge.net <http://sourceforge.net> because you > indicated interest in https://sourceforge.net/p/kisao/feature-requests/31/ > >> > >> To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/ > >> > > > > > -- > Nicolas LE NOVERE, > The Babraham Institute, Babraham Campus Cambridge, CB22 3AT > Tel: +441223496433 Mob:+447833147074 http://lenoverelab.org > orcid.org//0000-0002-6309-7327 Skype:n.lenovere twitter:@lenovere > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > |
|
From: Nicolas Le N. <n.l...@gm...> - 2017-07-18 08:23:28
|
Hi Chris, Last I heard, Anna was kind enough to update KiSAO when a new request came. What I am unclear about is where in KiSAO, would you like to put this? The number of run looks like a SED-ML attribute rather than a KiSAO term. Actually I thought that this was already covered by the current structures supporting repeated simulations. On 13/07/17 23:09, Chris Myers wrote: > Who maintains KISAO? I would like to get this added ASAP. It is critical if we want SED-ML to support stochastic simulation properly. > > Chris > >> Begin forwarded message: >> >> *From: *"Chris Myers" <cc...@us... <mailto:cc...@us...>> >> *Subject: **[kisao:feature-requests] #31 Number of Runs* >> *Date: *July 13, 2017 at 4:02:19 PM MDT >> *To: *"Ticket 31" <31...@fe... <mailto:31...@fe...>> >> *Reply-To: *"Ticket 31" <31...@fe... <mailto:31...@fe...>> >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> >> *[feature-requests:#31] <https://sourceforge.net/p/kisao/feature-requests/31/> Number of Runs* >> >> *Status:* open >> *Created:* Thu Jul 13, 2017 10:02 PM UTC by Chris Myers >> *Last Updated:* Thu Jul 13, 2017 10:02 PM UTC >> *Owner:* nobody >> >> This should indicate the number of runs that a simulation should perform. It would typically be used to specify the number of runs for a stochastic simulation. >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> >> Sent from sourceforge.net <http://sourceforge.net> because you indicated interest in https://sourceforge.net/p/kisao/feature-requests/31/ >> >> To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ >> > -- Nicolas LE NOVERE, The Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 http://lenoverelab.org orcid.org//0000-0002-6309-7327 Skype:n.lenovere twitter:@lenovere |
|
From: Matthias K. <kon...@go...> - 2017-07-05 07:33:55
|
Hi all, In my opinion the repeated task is already handling the multiple stochastic runs. The only issue is that we have to clearly define in the spec what is the expected output of repeated task and nested repeated task in form of data matrices which come out of them. How I understand the repeated tasks, and implemented them, is that with every nesting an additional matrix dimension is created. * Simple task of Time course simulation has result M(Nt, 1), i.e. matrix dimension of N time points times 1 * Simple task of One step and steady state has M(1,1) A repeated task r1 has * M(Nt, Nr1) for time course * M(1, Nr1) for steady state and one step A repeated task r2 of repeated task r1 (like scanning parameters over stochastic repeats, or parameters against parameters, i.e. scanning a parameter grid) results in * M(Nt, Nr1, Nr2) timecourse * M(1, Nr1, Nr2) one step and steady steady state and so on, i.e. with every nesting an additional dimension is added to the result matrix. What we need is mainly calculation of functions on dimensions of this matrix, i.e. mean(data, dimension) or std(data, dimension), i.e. the calculation on certain dimension of the resulting data matrices. In the following indexing starting from 0, i.e. functions on dimension 1 are integrating repeated task 1, functions on dimension 2 repeated task 2 and so on. The simple stochastic moments can than be calculated as mean(M(Nt, Nr1), 1) and std(M(Nt, Nr1), i.e. the functions are evaluated over the repeats If one wants a parameter scan over repeated tasks one would first scan the repeats for a given parameter (r1) and in the inner repeated task (r2) vary the parameters. Afterwards one calculates mean(M(Nt, Nr1, Nr2, 1) and std(M(Nt, Nr1, Nr2, 1) which brings down the dimension of the result matrix by one. That is why it is imporant to define what the result dimensions the different tasks can provide. For instance Jacobian tasks would produce M(Ns, Nv), with repeated jacobian adding more dimensions. In my opinion we have to write down once for every task what the result dimensions are, and how repeated tasks extend the dimensions. Than we have to allow function calculations on certain dimensions of the result Matrices. M On Wed, Jul 5, 2017 at 5:58 AM, David Nickerson <dav...@gm...> wrote: > Hi all, > > To keep up with this exciting discussion, don't forget to sign up to > the new google group over at > https://groups.google.com/d/forum/sed-ml-discuss. > > Cheers, > David. > > > > ---------- Forwarded message ---------- > From: Chris Myers <my...@ec...> > Date: 4 July 2017 at 09:17 > Subject: Re: [sed-ml-discuss] [SED-ML-discuss] Figures from HARMONY, plus > extras > To: Lucian Smith <luc...@gm...> > Cc: sed...@go... > > > No, slice will not work. This is not for reading a data file > externally, this is for specifying a data generator. Here is how I do > this now: > > <dataGenerator id="IPTG_Environment_mean_dg" name="IPTG"> > <annotation> > <dataSet xmlns="http://www.async.ece.utah.edu/iBioSim" > dataset="mean" /> > </annotation> > <listOfVariables> > <variable id="IPTG_Environment_mean_var" name="" > taskReference="Environment" > target="/sbml:sbml/sbml:model/sbml:listOfSpecies/sbml:species[@id='IPTG']" > /> > </listOfVariables> > <math:math> > <math:ci>IPTG_Environment_mean_var</math:ci> > </math:math> > </dataGenerator> > <dataGenerator id="IPTG_Environment_stddev_dg" name="IPTG"> > <annotation> > <dataSet xmlns="http://www.async.ece.utah.edu/iBioSim" > dataset="stddev" /> > </annotation> > <listOfVariables> > <variable id="IPTG_Environment_stddev_var" name="" > taskReference="Environment" > target="/sbml:sbml/sbml:model/sbml:listOfSpecies/sbml:species[@id='IPTG']" > /> > </listOfVariables> > <math:math> > <math:ci>IPTG_Environment_stddev_var</math:ci> > </math:math> > </dataGenerator> > <dataGenerator id="IPTG_Environment_1_dg" name="IPTG"> > <annotation> > <dataSet xmlns="http://www.async.ece.utah.edu/iBioSim" > dataset="1" /> > </annotation> > <listOfVariables> > <variable id="IPTG_Environment_1_var" name="" > taskReference="Environment" > target="/sbml:sbml/sbml:model/sbml:listOfSpecies/sbml:species[@id='IPTG']" > /> > </listOfVariables> > <math:math> > <math:ci>IPTG_Environment_1_var</math:ci> > </math:math> > </dataGenerator> > > What I would prefer to do instead is be allowed to treat the variable > id in a stochastic run as an array, and in the math be able to do > things like: > > mean(IPTG) > stddev(IPTG) > IPTG[1] > > This would be much cleaner. > > Chris > > On Jul 4, 2017, at 10:12 AM, Lucian Smith <luc...@gm...> > wrote: > > No, we didn't discuss either of those proposals explicitly. For the > second, I was under the impression that the 'Slice' construct could > get you what you want, but I don't know this for sure. Frank, would > that work? If not, I bet an update to 'slice' would make it work. > > -Lucian > > On Mon, Jul 3, 2017 at 9:31 PM, Chris Myers <my...@ec...> wrote: > > > > Hi Lucian, > > > > Thanks for creating these. I like the updates for plots and curves. > However, I do not see any updates for number of runs for a Task and a means > to access specific run data (or statistics) by a data generator. I was > pretty sure we agreed on that at COMBINE 2016. Did these get discussed at > Harmony? > > > > Chris > > > > > On Jul 3, 2017, at 9:05 PM, David Nickerson <dav...@gm...> > wrote: > > > > > > ---------- Forwarded message ---------- > > > From: Lucian Smith <luc...@gm...> > > > Date: 3 July 2017 at 13:53 > > > Subject: [SED-ML-discuss] Figures from HARMONY, plus extras > > > To: sed...@li... > > > > > > > > > As you may have heard by now, HARMONY 2017 was a very productive > > > conference for the SED-ML community. Many proposals that have been > > > considered and thought about for a long time were finally made into > > > concrete UML diagrams, and work has begun on writing up a proposed > > > specification describing those changes. > > > > > > I was in charge of creating the UML diagrams, and while I contributed > > > to their content, it was by no means a solo effort. Over the weekend, > > > I've worked on updating them a little more, and have thrown in a > > > couple other proposed changes while I was at it. Some of the proposed > > > changes would be fine in a new l1v4 document, while others might be > > > best suited to an l2v1; no decisions have been made about either > > > possibility. > > > > > > It will probably make the most sense to talk about each set of > > > proposed changes separately, to make sure everything is properly > > > discussed, but if you're interested in perusing them in the meantime, > > > the whole folder is at: > > > > > > https://drive.google.com/drive/folders/0B71r5kLs3FlibnZMUEpIU1RKR1k > > > > > > In particular, take a look at the legend, to make sure you know what > > > you're looking at: > > > > > > https://docs.google.com/drawings/d/1BEzZfK0MyA8qyplkrIvUkEpGeDr1c > 8Ji1LPx_6pz9eM/edit > > > > > > In general, a red color means it's a newly-proposed change from l1v2. > > > > > > Also note that 'id' and 'name' have been proposed to be moved to > > > SEDBase, which explains why they are missing from some other figures. > > > > > > If anything is incorrect or confusing, let me know, and I will make > > > updates! And thanks in particular to Frank, Herbert, Matthias, and > > > David for their work and contributions during the conference. > > > > > > -Lucian Smith > > > > > > ------------------------------------------------------------ > ------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > SED-ML-discuss mailing list > > > SED...@li... > > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "sed-ml-discuss" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an email to sed...@go.... > > > To post to this group, send an email to sed-ml-discuss@googlegroups. > com. > > > To view this discussion on the web, visit https://groups.google.com/d/ > msgid/sed-ml-discuss/CADizRjgi%2BbvOOQvxP7n%3DA0duBAOfLO2L4No7% > 2BGJbtAfaB3-JFQ%40mail.gmail.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > -- > You received this message because you are subscribed to the Google > Groups "sed-ml-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to sed...@go.... > To post to this group, send email to sed...@go.... > To view this discussion on the web, visit > https://groups.google.com/d/msgid/sed-ml-discuss/B65C820D- > 6BD0-429B-BE2A-FCCC844389B8%40ece.utah.edu. > > For more options, visit https://groups.google.com/d/optout. > > > -- > > > David Nickerson > about.me/david.nickerson > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > -- Dr. Matthias König Junior Group Leader LiSyM - Systems Medicine of the Liver Humboldt-University Berlin, Institute of Biology, Institute for Theoretical Biology https://www.livermetabolism.com kon...@go... Tel: +49 30 20938450 Tel: +49 176 81168480 |
|
From: David N. <dav...@gm...> - 2017-07-05 03:59:00
|
Hi all, To keep up with this exciting discussion, don't forget to sign up to the new google group over at https://groups.google.com/d/forum/sed-ml-discuss. Cheers, David. ---------- Forwarded message ---------- From: Chris Myers <my...@ec...> Date: 4 July 2017 at 09:17 Subject: Re: [sed-ml-discuss] [SED-ML-discuss] Figures from HARMONY, plus extras To: Lucian Smith <luc...@gm...> Cc: sed...@go... No, slice will not work. This is not for reading a data file externally, this is for specifying a data generator. Here is how I do this now: <dataGenerator id="IPTG_Environment_mean_dg" name="IPTG"> <annotation> <dataSet xmlns="http://www.async.ece.utah.edu/iBioSim" dataset="mean" /> </annotation> <listOfVariables> <variable id="IPTG_Environment_mean_var" name="" taskReference="Environment" target="/sbml:sbml/sbml:model/sbml:listOfSpecies/sbml:species[@id='IPTG']" /> </listOfVariables> <math:math> <math:ci>IPTG_Environment_mean_var</math:ci> </math:math> </dataGenerator> <dataGenerator id="IPTG_Environment_stddev_dg" name="IPTG"> <annotation> <dataSet xmlns="http://www.async.ece.utah.edu/iBioSim" dataset="stddev" /> </annotation> <listOfVariables> <variable id="IPTG_Environment_stddev_var" name="" taskReference="Environment" target="/sbml:sbml/sbml:model/sbml:listOfSpecies/sbml:species[@id='IPTG']" /> </listOfVariables> <math:math> <math:ci>IPTG_Environment_stddev_var</math:ci> </math:math> </dataGenerator> <dataGenerator id="IPTG_Environment_1_dg" name="IPTG"> <annotation> <dataSet xmlns="http://www.async.ece.utah.edu/iBioSim" dataset="1" /> </annotation> <listOfVariables> <variable id="IPTG_Environment_1_var" name="" taskReference="Environment" target="/sbml:sbml/sbml:model/sbml:listOfSpecies/sbml:species[@id='IPTG']" /> </listOfVariables> <math:math> <math:ci>IPTG_Environment_1_var</math:ci> </math:math> </dataGenerator> What I would prefer to do instead is be allowed to treat the variable id in a stochastic run as an array, and in the math be able to do things like: mean(IPTG) stddev(IPTG) IPTG[1] This would be much cleaner. Chris On Jul 4, 2017, at 10:12 AM, Lucian Smith <luc...@gm...> wrote: No, we didn't discuss either of those proposals explicitly. For the second, I was under the impression that the 'Slice' construct could get you what you want, but I don't know this for sure. Frank, would that work? If not, I bet an update to 'slice' would make it work. -Lucian On Mon, Jul 3, 2017 at 9:31 PM, Chris Myers <my...@ec...> wrote: > > Hi Lucian, > > Thanks for creating these. I like the updates for plots and curves. However, I do not see any updates for number of runs for a Task and a means to access specific run data (or statistics) by a data generator. I was pretty sure we agreed on that at COMBINE 2016. Did these get discussed at Harmony? > > Chris > > > On Jul 3, 2017, at 9:05 PM, David Nickerson <dav...@gm...> wrote: > > > > ---------- Forwarded message ---------- > > From: Lucian Smith <luc...@gm...> > > Date: 3 July 2017 at 13:53 > > Subject: [SED-ML-discuss] Figures from HARMONY, plus extras > > To: sed...@li... > > > > > > As you may have heard by now, HARMONY 2017 was a very productive > > conference for the SED-ML community. Many proposals that have been > > considered and thought about for a long time were finally made into > > concrete UML diagrams, and work has begun on writing up a proposed > > specification describing those changes. > > > > I was in charge of creating the UML diagrams, and while I contributed > > to their content, it was by no means a solo effort. Over the weekend, > > I've worked on updating them a little more, and have thrown in a > > couple other proposed changes while I was at it. Some of the proposed > > changes would be fine in a new l1v4 document, while others might be > > best suited to an l2v1; no decisions have been made about either > > possibility. > > > > It will probably make the most sense to talk about each set of > > proposed changes separately, to make sure everything is properly > > discussed, but if you're interested in perusing them in the meantime, > > the whole folder is at: > > > > https://drive.google.com/drive/folders/0B71r5kLs3FlibnZMUEpIU1RKR1k > > > > In particular, take a look at the legend, to make sure you know what > > you're looking at: > > > > https://docs.google.com/drawings/d/1BEzZfK0MyA8qyplkrIvUkEpGeDr1c8Ji1LPx_6pz9eM/edit > > > > In general, a red color means it's a newly-proposed change from l1v2. > > > > Also note that 'id' and 'name' have been proposed to be moved to > > SEDBase, which explains why they are missing from some other figures. > > > > If anything is incorrect or confusing, let me know, and I will make > > updates! And thanks in particular to Frank, Herbert, Matthias, and > > David for their work and contributions during the conference. > > > > -Lucian Smith > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > SED-ML-discuss mailing list > > SED...@li... > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > -- > > You received this message because you are subscribed to the Google Groups "sed-ml-discuss" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to sed...@go.... > > To post to this group, send an email to sed...@go.... > > To view this discussion on the web, visit https://groups.google.com/d/msgid/sed-ml-discuss/CADizRjgi%2BbvOOQvxP7n%3DA0duBAOfLO2L4No7%2BGJbtAfaB3-JFQ%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sed-ml-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to sed...@go.... To post to this group, send email to sed...@go.... To view this discussion on the web, visit https://groups.google.com/d/msgid/sed-ml-discuss/B65C820D-6BD0-429B-BE2A-FCCC844389B8%40ece.utah.edu. For more options, visit https://groups.google.com/d/optout. -- David Nickerson about.me/david.nickerson |
|
From: Herbert S. <uw....@gm...> - 2017-07-03 22:44:12
|
I'll do so e work on the text this week, probably Wednesday. Herbett On Mon, Jul 3, 2017 at 1:53 PM Lucian Smith <luc...@gm...> wrote: > As you may have heard by now, HARMONY 2017 was a very productive > conference for the SED-ML community. Many proposals that have been > considered and thought about for a long time were finally made into > concrete UML diagrams, and work has begun on writing up a proposed > specification describing those changes. > > I was in charge of creating the UML diagrams, and while I contributed to > their content, it was by no means a solo effort. Over the weekend, I've > worked on updating them a little more, and have thrown in a couple other > proposed changes while I was at it. Some of the proposed changes would be > fine in a new l1v4 document, while others might be best suited to an l2v1; > no decisions have been made about either possibility. > > It will probably make the most sense to talk about each set of proposed > changes separately, to make sure everything is properly discussed, but if > you're interested in perusing them in the meantime, the whole folder is at: > > https://drive.google.com/drive/folders/0B71r5kLs3FlibnZMUEpIU1RKR1k > > In particular, take a look at the legend, to make sure you know what > you're looking at: > > > https://docs.google.com/drawings/d/1BEzZfK0MyA8qyplkrIvUkEpGeDr1c8Ji1LPx_6pz9eM/edit > > In general, a red color means it's a newly-proposed change from l1v2. > > Also note that 'id' and 'name' have been proposed to be moved to SEDBase, > which explains why they are missing from some other figures. > > If anything is incorrect or confusing, let me know, and I will make > updates! And thanks in particular to Frank, Herbert, Matthias, and David > for their work and contributions during the conference. > > -Lucian Smith > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > |
|
From: Lucian S. <luc...@gm...> - 2017-07-03 20:53:44
|
As you may have heard by now, HARMONY 2017 was a very productive conference for the SED-ML community. Many proposals that have been considered and thought about for a long time were finally made into concrete UML diagrams, and work has begun on writing up a proposed specification describing those changes. I was in charge of creating the UML diagrams, and while I contributed to their content, it was by no means a solo effort. Over the weekend, I've worked on updating them a little more, and have thrown in a couple other proposed changes while I was at it. Some of the proposed changes would be fine in a new l1v4 document, while others might be best suited to an l2v1; no decisions have been made about either possibility. It will probably make the most sense to talk about each set of proposed changes separately, to make sure everything is properly discussed, but if you're interested in perusing them in the meantime, the whole folder is at: https://drive.google.com/drive/folders/0B71r5kLs3FlibnZMUEpIU1RKR1k In particular, take a look at the legend, to make sure you know what you're looking at: https://docs.google.com/drawings/d/1BEzZfK0MyA8qyplkrIvUkEpGeDr1c8Ji1LPx_6pz9eM/edit In general, a red color means it's a newly-proposed change from l1v2. Also note that 'id' and 'name' have been proposed to be moved to SEDBase, which explains why they are missing from some other figures. If anything is incorrect or confusing, let me know, and I will make updates! And thanks in particular to Frank, Herbert, Matthias, and David for their work and contributions during the conference. -Lucian Smith |
|
From: David N. <dav...@gm...> - 2017-06-28 23:49:43
|
Hi all, We are planning to migrate the SED-ML discussion list to google groups: https://groups.google.com/d/forum/sed-ml-discuss Due to changes in sourceforge policy, we are no longer able to see who is subscribed to this list and therefore unable to migrate people over to the google group. So if you can please head over to the group and sign up and then unsubscribe from this list. We will allow a couple of months for the transition during which time the editors will endeavour to make sure messages are available via both this sourceforge list and the new google group. The website will be updated with the new details shortly. The current list archive will remain on sourceforge. Thanks, David. |
|
From: David N. <dav...@gm...> - 2017-06-28 23:19:59
|
Hi all, The vote for two new SED-ML editors for 2017-2019 has closed and the confirmed results are now available. The new editors starting now are Dagmar Waltemath and Matthias König - congratulations! Dagmar and Matthias will replace outgoing editors Ion Moraru and Sven Sahle, whose terms have now ended. Many thanks to Ion and Sven for their valuable contributions to the editorial board! There were 25 unique votes cast in the election, with the results shown in the attached image. Cheers, David. |
|
From: Lucian S. <luc...@gm...> - 2017-06-28 21:51:40
|
On Wed, Jun 28, 2017 at 2:06 AM, Cooper, Jonathan <j.p...@uc...> wrote: > I don’t like the idea of removing an attribute in a version increment – I > think removing constructs should only happen when the level increases > really. So I’d like to keep the existing numberOfPoints with its existing > meaning (albeit perhaps clarified in the spec – but I think the spec was > already pretty clear on this). > > However, I agree that it’s a confusing attribute! So I think I would like > to see the addition of ‘numberOfSteps’ and users encouraged to use this > instead. > This sounds like my option 3--deprecate 'numberOfPoints' but keep it; add 'numberOfSteps' as a replacement (but disallow both at once). I do understand the distrust of removing attributes between versions, but this would still produce versions that were fully compatible with each other: all the information in the lower level/versions could be exactly replicated in the higher level/versions, so we're only adjusting, not removing any *semantic* information. The problem with the spec is that it's inconsistent: the examples and the text don't always match the description. It also doesn't help that the attribute name is a lie, which is the main point of contention. With regards to the outputTimeInterval, we could have that as well as an > option if we want. Am I correct in thinking that the current spec allows > points to be unevenly distributed, thus supporting adaptive integrators > without needing to interpolate? > The problem with adding outputTimeInterval is that it can be used to overspecify the output, which we presumably don't want. Any properly specified output can be translated to min/max/numberofSteps, so hopefully that could be handled in the user interface of a tool that wanted to use outputTimeInterval? -Lucian |
|
From: Herbert S. <uw....@gm...> - 2017-06-28 19:27:04
|
There is an opportunity here to correct something that is clearly wrong, better to get it right that leave as it is. Herbert On Wed, Jun 28, 2017 at 1:10 AM, Alan Garny <ala...@in...> wrote: > I am also in favour of option 1. Once agreed, the meaning of an attribute shouldn’t change. If anything, a new one should be created. > > While on the topic of ‘numberOfPoints’, I must confess that I don’t like having to specify a number of points. This ‘forces me’ to recompute that number whenever ‘outputStartTime’ and/or ‘outputEndTime’ change/s. > > I did ask about this before (on this mailing list), but what about something like ‘outputTimeInterval’? The idea is that if ‘outputStartTime’ is set to 0 and ‘outputEndTime’ to 1000, then I could specify an ‘outputTimeInterval’ of, say, 1.3, which would mean outputting at 0, 1.3, 2.6, …, 998.4, 999.7 and 1000 (yes, the last interval would be smaller, but that’s because I used a rather unusual value for ‘outputTimeInterval’). The rationale for this is that it matches what people do on the experimental side of things. > > In summary, I would personally go for option 1 and add a new attribute: ‘outputTimeInterval’. > > Alan > > On 28/06/2017, 06:15, "David Nickerson" <dav...@gm...> wrote: > > My preference is also option 1. > > Cheers, > David. > > On 27 June 2017 at 14:58, Bergmann, Frank T. <fbe...@ca...> wrote: > > I’d prefer option 1. > > > > Cheers > > Frank > > > > > > On Jun 27, 2017, at 2:03 PM, Kyle Medley <me...@co...> wrote: > > > > I was under the mistaken in impression that this change was going to impact > > SED-ML L1V2 retroactively, but it's actually slated for L1V3 and won't > > affect libsedml's ability to read older versions, so I also agree with > > Herbert (i.e. option 2). > > > > J Kyle Medley, PhD Candidate > > Bioengineering/BPSD, Sauro Lab > > University of Washington, Seattle > > skype: jkylemedley > > > > On 6/27/17 1:47 PM, Moraru,Ion wrote: > > > > I agree with Herbert. > > Ion > > > > From: Herbert Sauro [mailto:uw....@gm...] > > Sent: Tuesday, June 27, 2017 4:21 PM > > To: sed...@li... > > Subject: Re: [SED-ML-discuss] The 'numberOfPoints' attribute > > > > Given that the sedml community is still very small, it would be better to > > get it right at this early stage, hence I prefer option > > > > 2) change the name to set thing else, e.g. numberOfSteps > > > > For those clinging to earlier versions they can check the version of the > > sedml and interpret numberofpoints in the old way. In that sense I don't > > think it affects backward compatibility. > > > > Herbett > > > > > > On Tue, Jun 27, 2017 at 1:08 PM Kyle Medley <me...@co...> wrote: > > > > It seems to me that breaking backwards compatibility defeats one of the > > major advantages of having a standard encoding, so I would prefer option 1. > > If people are not happy with that, I have a different suggestion: > > > > 4) Allow 'numberOfPoints', and do not change its meaning, but also create a > > new attribute 'numberOfSteps' with the same semantics. 'numberOfPoints' > > would not be deprecated. > > > > Cheers, > > > > Kyle > > > > J Kyle Medley, PhD Candidate > > > > Bioengineering/BPSD, Sauro Lab > > > > University of Washington, Seattle > > > > skype: jkylemedley > > > > On 6/27/17 12:46 PM, Lucian Smith wrote: > > > > At HARMONY, the issue was brought up that the 'numberOfPoints' attribute is > > confusing, because the literal number of expected points in the output file > > is one more than that: the initial conditions, and the number of *computed* > > points. > > > > It was proposed that we fix this for SED-ML Level 1 Version 3. There are a > > few options: > > > > 1) No change: simply make it more clear in the spec that 'numberOfPoints' > > means 'number of computed points' aka 'number of steps'. > > > > 2) Change the name of the attribute to 'numberOfSteps' or possibly > > 'numberOfComputedPoints'. > > > > 3) Deprecate but allow 'numberOfPoints', and make a new 'numberOfSteps' > > attribute that people are encouraged to use instead. > > > > Any opinions? It seems like the advantage is preventing future confusion, > > and the cost is having a non-backwards-compatible spec, and the cost of > > implementation changes for the groups that currently support SED-ML. > > > > -Lucian > > > > > > > > ------------------------------------------------------------------------------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > > > SED-ML-discuss mailing list > > > > SED...@li... > > > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! > > http://sdm.link/slashdot_______________________________________________ > > SED-ML-discuss mailing list > > SED...@li... > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > SED-ML-discuss mailing list > > SED...@li... > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! > > http://sdm.link/slashdot_______________________________________________ > > SED-ML-discuss mailing list > > SED...@li... > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > SED-ML-discuss mailing list > > SED...@li... > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > > -- > > > David Nickerson > about.me/david.nickerson > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss |
|
From: Cooper, J. <j.p...@uc...> - 2017-06-28 09:40:11
|
I don’t like the idea of removing an attribute in a version increment – I think removing constructs should only happen when the level increases really. So I’d like to keep the existing numberOfPoints with its existing meaning (albeit perhaps clarified in the spec – but I think the spec was already pretty clear on this).
However, I agree that it’s a confusing attribute! So I think I would like to see the addition of ‘numberOfSteps’ and users encouraged to use this instead.
With regards to the outputTimeInterval, we could have that as well as an option if we want. Am I correct in thinking that the current spec allows points to be unevenly distributed, thus supporting adaptive integrators without needing to interpolate?
Best wishes,
Jonathan
On 28/06/2017, 09:10, "Alan Garny" <ala...@in...> wrote:
I am also in favour of option 1. Once agreed, the meaning of an attribute shouldn’t change. If anything, a new one should be created.
While on the topic of ‘numberOfPoints’, I must confess that I don’t like having to specify a number of points. This ‘forces me’ to recompute that number whenever ‘outputStartTime’ and/or ‘outputEndTime’ change/s.
I did ask about this before (on this mailing list), but what about something like ‘outputTimeInterval’? The idea is that if ‘outputStartTime’ is set to 0 and ‘outputEndTime’ to 1000, then I could specify an ‘outputTimeInterval’ of, say, 1.3, which would mean outputting at 0, 1.3, 2.6, …, 998.4, 999.7 and 1000 (yes, the last interval would be smaller, but that’s because I used a rather unusual value for ‘outputTimeInterval’). The rationale for this is that it matches what people do on the experimental side of things.
In summary, I would personally go for option 1 and add a new attribute: ‘outputTimeInterval’.
Alan
On 28/06/2017, 06:15, "David Nickerson" <dav...@gm...> wrote:
My preference is also option 1.
Cheers,
David.
On 27 June 2017 at 14:58, Bergmann, Frank T. <fbe...@ca...> wrote:
> I’d prefer option 1.
>
> Cheers
> Frank
>
>
> On Jun 27, 2017, at 2:03 PM, Kyle Medley <me...@co...> wrote:
>
> I was under the mistaken in impression that this change was going to impact
> SED-ML L1V2 retroactively, but it's actually slated for L1V3 and won't
> affect libsedml's ability to read older versions, so I also agree with
> Herbert (i.e. option 2).
>
> J Kyle Medley, PhD Candidate
> Bioengineering/BPSD, Sauro Lab
> University of Washington, Seattle
> skype: jkylemedley
>
> On 6/27/17 1:47 PM, Moraru,Ion wrote:
>
> I agree with Herbert.
> Ion
>
> From: Herbert Sauro [mailto:uw....@gm...]
> Sent: Tuesday, June 27, 2017 4:21 PM
> To: sed...@li...
> Subject: Re: [SED-ML-discuss] The 'numberOfPoints' attribute
>
> Given that the sedml community is still very small, it would be better to
> get it right at this early stage, hence I prefer option
>
> 2) change the name to set thing else, e.g. numberOfSteps
>
> For those clinging to earlier versions they can check the version of the
> sedml and interpret numberofpoints in the old way. In that sense I don't
> think it affects backward compatibility.
>
> Herbett
>
>
> On Tue, Jun 27, 2017 at 1:08 PM Kyle Medley <me...@co...> wrote:
>
> It seems to me that breaking backwards compatibility defeats one of the
> major advantages of having a standard encoding, so I would prefer option 1.
> If people are not happy with that, I have a different suggestion:
>
> 4) Allow 'numberOfPoints', and do not change its meaning, but also create a
> new attribute 'numberOfSteps' with the same semantics. 'numberOfPoints'
> would not be deprecated.
>
> Cheers,
>
> Kyle
>
> J Kyle Medley, PhD Candidate
>
> Bioengineering/BPSD, Sauro Lab
>
> University of Washington, Seattle
>
> skype: jkylemedley
>
> On 6/27/17 12:46 PM, Lucian Smith wrote:
>
> At HARMONY, the issue was brought up that the 'numberOfPoints' attribute is
> confusing, because the literal number of expected points in the output file
> is one more than that: the initial conditions, and the number of *computed*
> points.
>
> It was proposed that we fix this for SED-ML Level 1 Version 3. There are a
> few options:
>
> 1) No change: simply make it more clear in the spec that 'numberOfPoints'
> means 'number of computed points' aka 'number of steps'.
>
> 2) Change the name of the attribute to 'numberOfSteps' or possibly
> 'numberOfComputedPoints'.
>
> 3) Deprecate but allow 'numberOfPoints', and make a new 'numberOfSteps'
> attribute that people are encouraged to use instead.
>
> Any opinions? It seems like the advantage is preventing future confusion,
> and the cost is having a non-backwards-compatible spec, and the cost of
> implementation changes for the groups that currently support SED-ML.
>
> -Lucian
>
>
>
> ------------------------------------------------------------------------------
>
> Check out the vibrant tech community on one of the world's most
>
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
>
> SED-ML-discuss mailing list
>
> SED...@li...
>
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
--
David Nickerson
about.me/david.nickerson
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SED-ML-discuss mailing list
SED...@li...
https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SED-ML-discuss mailing list
SED...@li...
https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
|
|
From: Alan G. <ala...@in...> - 2017-06-28 08:10:49
|
I am also in favour of option 1. Once agreed, the meaning of an attribute shouldn’t change. If anything, a new one should be created.
While on the topic of ‘numberOfPoints’, I must confess that I don’t like having to specify a number of points. This ‘forces me’ to recompute that number whenever ‘outputStartTime’ and/or ‘outputEndTime’ change/s.
I did ask about this before (on this mailing list), but what about something like ‘outputTimeInterval’? The idea is that if ‘outputStartTime’ is set to 0 and ‘outputEndTime’ to 1000, then I could specify an ‘outputTimeInterval’ of, say, 1.3, which would mean outputting at 0, 1.3, 2.6, …, 998.4, 999.7 and 1000 (yes, the last interval would be smaller, but that’s because I used a rather unusual value for ‘outputTimeInterval’). The rationale for this is that it matches what people do on the experimental side of things.
In summary, I would personally go for option 1 and add a new attribute: ‘outputTimeInterval’.
Alan
On 28/06/2017, 06:15, "David Nickerson" <dav...@gm...> wrote:
My preference is also option 1.
Cheers,
David.
On 27 June 2017 at 14:58, Bergmann, Frank T. <fbe...@ca...> wrote:
> I’d prefer option 1.
>
> Cheers
> Frank
>
>
> On Jun 27, 2017, at 2:03 PM, Kyle Medley <me...@co...> wrote:
>
> I was under the mistaken in impression that this change was going to impact
> SED-ML L1V2 retroactively, but it's actually slated for L1V3 and won't
> affect libsedml's ability to read older versions, so I also agree with
> Herbert (i.e. option 2).
>
> J Kyle Medley, PhD Candidate
> Bioengineering/BPSD, Sauro Lab
> University of Washington, Seattle
> skype: jkylemedley
>
> On 6/27/17 1:47 PM, Moraru,Ion wrote:
>
> I agree with Herbert.
> Ion
>
> From: Herbert Sauro [mailto:uw....@gm...]
> Sent: Tuesday, June 27, 2017 4:21 PM
> To: sed...@li...
> Subject: Re: [SED-ML-discuss] The 'numberOfPoints' attribute
>
> Given that the sedml community is still very small, it would be better to
> get it right at this early stage, hence I prefer option
>
> 2) change the name to set thing else, e.g. numberOfSteps
>
> For those clinging to earlier versions they can check the version of the
> sedml and interpret numberofpoints in the old way. In that sense I don't
> think it affects backward compatibility.
>
> Herbett
>
>
> On Tue, Jun 27, 2017 at 1:08 PM Kyle Medley <me...@co...> wrote:
>
> It seems to me that breaking backwards compatibility defeats one of the
> major advantages of having a standard encoding, so I would prefer option 1.
> If people are not happy with that, I have a different suggestion:
>
> 4) Allow 'numberOfPoints', and do not change its meaning, but also create a
> new attribute 'numberOfSteps' with the same semantics. 'numberOfPoints'
> would not be deprecated.
>
> Cheers,
>
> Kyle
>
> J Kyle Medley, PhD Candidate
>
> Bioengineering/BPSD, Sauro Lab
>
> University of Washington, Seattle
>
> skype: jkylemedley
>
> On 6/27/17 12:46 PM, Lucian Smith wrote:
>
> At HARMONY, the issue was brought up that the 'numberOfPoints' attribute is
> confusing, because the literal number of expected points in the output file
> is one more than that: the initial conditions, and the number of *computed*
> points.
>
> It was proposed that we fix this for SED-ML Level 1 Version 3. There are a
> few options:
>
> 1) No change: simply make it more clear in the spec that 'numberOfPoints'
> means 'number of computed points' aka 'number of steps'.
>
> 2) Change the name of the attribute to 'numberOfSteps' or possibly
> 'numberOfComputedPoints'.
>
> 3) Deprecate but allow 'numberOfPoints', and make a new 'numberOfSteps'
> attribute that people are encouraged to use instead.
>
> Any opinions? It seems like the advantage is preventing future confusion,
> and the cost is having a non-backwards-compatible spec, and the cost of
> implementation changes for the groups that currently support SED-ML.
>
> -Lucian
>
>
>
> ------------------------------------------------------------------------------
>
> Check out the vibrant tech community on one of the world's most
>
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
>
> SED-ML-discuss mailing list
>
> SED...@li...
>
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
--
David Nickerson
about.me/david.nickerson
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
SED-ML-discuss mailing list
SED...@li...
https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
|
|
From: David N. <dav...@gm...> - 2017-06-28 04:15:52
|
My preference is also option 1. Cheers, David. On 27 June 2017 at 14:58, Bergmann, Frank T. <fbe...@ca...> wrote: > I’d prefer option 1. > > Cheers > Frank > > > On Jun 27, 2017, at 2:03 PM, Kyle Medley <me...@co...> wrote: > > I was under the mistaken in impression that this change was going to impact > SED-ML L1V2 retroactively, but it's actually slated for L1V3 and won't > affect libsedml's ability to read older versions, so I also agree with > Herbert (i.e. option 2). > > J Kyle Medley, PhD Candidate > Bioengineering/BPSD, Sauro Lab > University of Washington, Seattle > skype: jkylemedley > > On 6/27/17 1:47 PM, Moraru,Ion wrote: > > I agree with Herbert. > Ion > > From: Herbert Sauro [mailto:uw....@gm...] > Sent: Tuesday, June 27, 2017 4:21 PM > To: sed...@li... > Subject: Re: [SED-ML-discuss] The 'numberOfPoints' attribute > > Given that the sedml community is still very small, it would be better to > get it right at this early stage, hence I prefer option > > 2) change the name to set thing else, e.g. numberOfSteps > > For those clinging to earlier versions they can check the version of the > sedml and interpret numberofpoints in the old way. In that sense I don't > think it affects backward compatibility. > > Herbett > > > On Tue, Jun 27, 2017 at 1:08 PM Kyle Medley <me...@co...> wrote: > > It seems to me that breaking backwards compatibility defeats one of the > major advantages of having a standard encoding, so I would prefer option 1. > If people are not happy with that, I have a different suggestion: > > 4) Allow 'numberOfPoints', and do not change its meaning, but also create a > new attribute 'numberOfSteps' with the same semantics. 'numberOfPoints' > would not be deprecated. > > Cheers, > > Kyle > > J Kyle Medley, PhD Candidate > > Bioengineering/BPSD, Sauro Lab > > University of Washington, Seattle > > skype: jkylemedley > > On 6/27/17 12:46 PM, Lucian Smith wrote: > > At HARMONY, the issue was brought up that the 'numberOfPoints' attribute is > confusing, because the literal number of expected points in the output file > is one more than that: the initial conditions, and the number of *computed* > points. > > It was proposed that we fix this for SED-ML Level 1 Version 3. There are a > few options: > > 1) No change: simply make it more clear in the spec that 'numberOfPoints' > means 'number of computed points' aka 'number of steps'. > > 2) Change the name of the attribute to 'numberOfSteps' or possibly > 'numberOfComputedPoints'. > > 3) Deprecate but allow 'numberOfPoints', and make a new 'numberOfSteps' > attribute that people are encouraged to use instead. > > Any opinions? It seems like the advantage is preventing future confusion, > and the cost is having a non-backwards-compatible spec, and the cost of > implementation changes for the groups that currently support SED-ML. > > -Lucian > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > > SED-ML-discuss mailing list > > SED...@li... > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! > http://sdm.link/slashdot_______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! > http://sdm.link/slashdot_______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > -- David Nickerson about.me/david.nickerson |
|
From: Bergmann, F. T. <fbe...@ca...> - 2017-06-27 23:31:50
|
I’d prefer option 1. Cheers Frank On Jun 27, 2017, at 2:03 PM, Kyle Medley <me...@co...<mailto:me...@co...>> wrote: I was under the mistaken in impression that this change was going to impact SED-ML L1V2 retroactively, but it's actually slated for L1V3 and won't affect libsedml's ability to read older versions, so I also agree with Herbert (i.e. option 2). J Kyle Medley, PhD Candidate Bioengineering/BPSD, Sauro Lab University of Washington, Seattle skype: jkylemedley On 6/27/17 1:47 PM, Moraru,Ion wrote: I agree with Herbert. Ion From: Herbert Sauro [mailto:uw....@gm...] Sent: Tuesday, June 27, 2017 4:21 PM To: sed...@li...<mailto:sed...@li...> Subject: Re: [SED-ML-discuss] The 'numberOfPoints' attribute Given that the sedml community is still very small, it would be better to get it right at this early stage, hence I prefer option 2) change the name to set thing else, e.g. numberOfSteps For those clinging to earlier versions they can check the version of the sedml and interpret numberofpoints in the old way. In that sense I don't think it affects backward compatibility. Herbett On Tue, Jun 27, 2017 at 1:08 PM Kyle Medley <me...@co...<mailto:me...@co...>> wrote: It seems to me that breaking backwards compatibility defeats one of the major advantages of having a standard encoding, so I would prefer option 1. If people are not happy with that, I have a different suggestion: 4) Allow 'numberOfPoints', and do not change its meaning, but also create a new attribute 'numberOfSteps' with the same semantics. 'numberOfPoints' would not be deprecated. Cheers, Kyle J Kyle Medley, PhD Candidate Bioengineering/BPSD, Sauro Lab University of Washington, Seattle skype: jkylemedley On 6/27/17 12:46 PM, Lucian Smith wrote: At HARMONY, the issue was brought up that the 'numberOfPoints' attribute is confusing, because the literal number of expected points in the output file is one more than that: the initial conditions, and the number of *computed* points. It was proposed that we fix this for SED-ML Level 1 Version 3. There are a few options: 1) No change: simply make it more clear in the spec that 'numberOfPoints' means 'number of computed points' aka 'number of steps'. 2) Change the name of the attribute to 'numberOfSteps' or possibly 'numberOfComputedPoints'. 3) Deprecate but allow 'numberOfPoints', and make a new 'numberOfSteps' attribute that people are encouraged to use instead. Any opinions? It seems like the advantage is preventing future confusion, and the cost is having a non-backwards-compatible spec, and the cost of implementation changes for the groups that currently support SED-ML. -Lucian ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot<https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=9F_v0bUXB6j5kn7Vv_3WfktqtVDUS0b6558jV6juN6A&e=> _______________________________________________ SED-ML-discuss mailing list SED...@li...<mailto:SED...@li...> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_sed-2Dml-2Ddiscuss&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=CJx4rItQ2ECm949FtSEOLLKAjDzxvCHyxfloP89GGCM&e=> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot<https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=9F_v0bUXB6j5kn7Vv_3WfktqtVDUS0b6558jV6juN6A&e=>_______________________________________________ SED-ML-discuss mailing list SED...@li...<mailto:SED...@li...> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_sed-2Dml-2Ddiscuss&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=CJx4rItQ2ECm949FtSEOLLKAjDzxvCHyxfloP89GGCM&e=> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot _______________________________________________ SED-ML-discuss mailing list SED...@li...<mailto:SED...@li...> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://slashdot.org/>! http://sdm.link/slashdot_______________________________________________ SED-ML-discuss mailing list SED...@li...<mailto:SED...@li...> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss |
|
From: Kyle M. <me...@co...> - 2017-06-27 21:05:47
|
I was under the mistaken in impression that this change was going to impact SED-ML L1V2 retroactively, but it's actually slated for L1V3 and won't affect libsedml's ability to read older versions, so I also agree with Herbert (i.e. option 2). J Kyle Medley, PhD Candidate Bioengineering/BPSD, Sauro Lab University of Washington, Seattle skype: jkylemedley On 6/27/17 1:47 PM, Moraru,Ion wrote: > > I agree with Herbert. > > Ion > > *From:*Herbert Sauro [mailto:uw....@gm...] > *Sent:* Tuesday, June 27, 2017 4:21 PM > *To:* sed...@li... > *Subject:* Re: [SED-ML-discuss] The 'numberOfPoints' attribute > > Given that the sedml community is still very small, it would be better > to get it right at this early stage, hence I prefer option > > 2) change the name to set thing else, e.g. numberOfSteps > > For those clinging to earlier versions they can check the version of > the sedml and interpret numberofpoints in the old way. In that sense I > don't think it affects backward compatibility. > > Herbett > > On Tue, Jun 27, 2017 at 1:08 PM Kyle Medley <me...@co... > <mailto:me...@co...>> wrote: > > It seems to me that breaking backwards compatibility defeats one > of the major advantages of having a standard encoding, so I would > prefer option 1. If people are not happy with that, I have a > different suggestion: > > 4) Allow 'numberOfPoints', and do not change its meaning, but also > create a new attribute 'numberOfSteps' with the same semantics. > 'numberOfPoints' would not be deprecated. > > Cheers, > > Kyle > > J Kyle Medley, PhD Candidate > > Bioengineering/BPSD, Sauro Lab > > University of Washington, Seattle > > skype: jkylemedley > > On 6/27/17 12:46 PM, Lucian Smith wrote: > > At HARMONY, the issue was brought up that the 'numberOfPoints' > attribute is confusing, because the literal number of expected > points in the output file is one more than that: the initial > conditions, and the number of *computed* points. > > It was proposed that we fix this for SED-ML Level 1 Version > 3. There are a few options: > > 1) No change: simply make it more clear in the spec that > 'numberOfPoints' means 'number of computed points' aka 'number > of steps'. > > 2) Change the name of the attribute to 'numberOfSteps' or > possibly 'numberOfComputedPoints'. > > 3) Deprecate but allow 'numberOfPoints', and make a new > 'numberOfSteps' attribute that people are encouraged to use > instead. > > Any opinions? It seems like the advantage is preventing > future confusion, and the cost is having a > non-backwards-compatible spec, and the cost of implementation > changes for the groups that currently support SED-ML. > > -Lucian > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org!http://sdm.link/slashdot > <https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=9F_v0bUXB6j5kn7Vv_3WfktqtVDUS0b6558jV6juN6A&e=> > > _______________________________________________ > > SED-ML-discuss mailing list > > SED...@li... > <mailto:SED...@li...> > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_sed-2Dml-2Ddiscuss&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=CJx4rItQ2ECm949FtSEOLLKAjDzxvCHyxfloP89GGCM&e=> > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > <https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=9F_v0bUXB6j5kn7Vv_3WfktqtVDUS0b6558jV6juN6A&e=>_______________________________________________ > SED-ML-discuss mailing list > SED...@li... > <mailto:SED...@li...> > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_sed-2Dml-2Ddiscuss&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=CJx4rItQ2ECm949FtSEOLLKAjDzxvCHyxfloP89GGCM&e=> > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss |
|
From: Moraru,Ion <mo...@uc...> - 2017-06-27 20:48:06
|
I agree with Herbert. Ion From: Herbert Sauro [mailto:uw....@gm...] Sent: Tuesday, June 27, 2017 4:21 PM To: sed...@li... Subject: Re: [SED-ML-discuss] The 'numberOfPoints' attribute Given that the sedml community is still very small, it would be better to get it right at this early stage, hence I prefer option 2) change the name to set thing else, e.g. numberOfSteps For those clinging to earlier versions they can check the version of the sedml and interpret numberofpoints in the old way. In that sense I don't think it affects backward compatibility. Herbett On Tue, Jun 27, 2017 at 1:08 PM Kyle Medley <me...@co...<mailto:me...@co...>> wrote: It seems to me that breaking backwards compatibility defeats one of the major advantages of having a standard encoding, so I would prefer option 1. If people are not happy with that, I have a different suggestion: 4) Allow 'numberOfPoints', and do not change its meaning, but also create a new attribute 'numberOfSteps' with the same semantics. 'numberOfPoints' would not be deprecated. Cheers, Kyle J Kyle Medley, PhD Candidate Bioengineering/BPSD, Sauro Lab University of Washington, Seattle skype: jkylemedley On 6/27/17 12:46 PM, Lucian Smith wrote: At HARMONY, the issue was brought up that the 'numberOfPoints' attribute is confusing, because the literal number of expected points in the output file is one more than that: the initial conditions, and the number of *computed* points. It was proposed that we fix this for SED-ML Level 1 Version 3. There are a few options: 1) No change: simply make it more clear in the spec that 'numberOfPoints' means 'number of computed points' aka 'number of steps'. 2) Change the name of the attribute to 'numberOfSteps' or possibly 'numberOfComputedPoints'. 3) Deprecate but allow 'numberOfPoints', and make a new 'numberOfSteps' attribute that people are encouraged to use instead. Any opinions? It seems like the advantage is preventing future confusion, and the cost is having a non-backwards-compatible spec, and the cost of implementation changes for the groups that currently support SED-ML. -Lucian ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot<https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=9F_v0bUXB6j5kn7Vv_3WfktqtVDUS0b6558jV6juN6A&e=> _______________________________________________ SED-ML-discuss mailing list SED...@li...<mailto:SED...@li...> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_sed-2Dml-2Ddiscuss&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=CJx4rItQ2ECm949FtSEOLLKAjDzxvCHyxfloP89GGCM&e=> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot<https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=9F_v0bUXB6j5kn7Vv_3WfktqtVDUS0b6558jV6juN6A&e=>_______________________________________________ SED-ML-discuss mailing list SED...@li...<mailto:SED...@li...> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_sed-2Dml-2Ddiscuss&d=DwMFaQ&c=EZxp_D7cDnouwj5YEFHgXuSKoUq2zVQZ_7Fw9yfotck&r=Uahi_Qsm5BuafcKS0wC-iw&m=wKDsf_F966wgDSfa6n7E0NHaXou1yRkMgwEQBGu_w8M&s=CJx4rItQ2ECm949FtSEOLLKAjDzxvCHyxfloP89GGCM&e=> |
14 messages has been excluded from this view by a project administrator.
