OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xmile message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xmile] model url / event poster


I'm a little confused now.  They're in the spec as a child element of the <model>, but STELLA version 10.0.4 saves them as a child of the variable:

    <model>
        <aux name="Converter_1">
            <event_poster min="0" max="1">
                <threshold value="0.7005" interval="4">
                    <event sim_action="stop">
                        <text />
                    </event>
                </threshold>
            </event_poster>
            <display x="124" y="173" color="blue" />
        </aux>
    </model>

SO - that is better, but the spec needs to be updated then (or clarified).

Karim - it would be great if you could either have the more detailed conversation about events on the mailing list - or at least report back to the rest of the TC after the meeting so everyone is kept in the loop.  Thanks!

yours,
Bobby


On Mon, Jun 2, 2014 at 10:47 AM, Karim Chichakly <kchichakly@iseesystems.com> wrote:
Hi Will,

With regards to that, I was hoping you and I could have a more detailed conversation about events in general when you and I have a chance (I won't have a chance till after Wednesday, so if I don't continue to answer these e-mails, you'll know why).

I'm not 100% sure about include.  I need some time to think about it.  The purpose of URL was to specify a submodel in another file.  Does <include> completely cover that?  On the surface, I think so, but I really want to think about it a little more and work through some cases to make sure.  I have no issue with removing it if it's completely redundant.

I like that you are coming up with a lot of good questions as you work through the XSD, but am also concerned that we change a lot of stuff this late and without a meeting between now and our next meeting when we hope to vote.  If we change too much, that vote probably won't be able to happen.

Thanks,

Karim



On Mon, Jun 2, 2014 at 10:37 AM, Will Glass-Husain <wglass@forio.com> wrote:
I'm on the fence about event posters.

But I do see use cases outside of iThink.

For example, Vensim allows models to stop at arbitrary points by changing the stop time.

And we've built Forio game like simulations in which the game ends early, say if the player is fired for poor performance.   

In both cases, the event poster feature can be used to implement this.

WILL


On Mon, Jun 2, 2014 at 7:31 AM, Bobby Powers <bobbypowers@gmail.com> wrote:
Hi Billy,

Thats good feedback.  Specifically I feel like event posters are inverted in their specification.  If the goal is runtime errors/warnings for variable values, that should be specified on the variable itself.  In fact - it already partially is with <non_negative>.  I don't like having to write code to look in multiple locations for this sort of stuff.  I would suggest that if we want to allow for user errors saying "calculation error, prices can never be negative" that it should live with the variable prices, not separately somewhere else in the file.

I agree that warnings like that are good for the user, but I think we need to firmly limit the scope of the spec if we want it to be in a publishable state sometime soon, and that since there is (in my mind at least) a lot of questions as to how and where runtime warning & errors should be specified, it should be left out of version 1 of the spec.  There would be no impact to isee that I can see, and it would allow us to better discuss it and come to a consensus for version 1.1 or 2 of the spec.

yours,
Bobby


On Mon, Jun 2, 2014 at 10:17 AM, Billy Schoenberg <bschoenberg@iseesystems.com> wrote:
Hi,

I agree on with the use of the <include> tag.

As for posters I think there is some value in including a small subset of the feature.  In particular I think the subset that is worth making core to XMILE the ability for a threshold to be passed (or met) and for the simulation to be stopped (in the case of an error) or paused (in the case of a warning) for a text message to be displayed.

In english, lets imagine a pricing model.  The modeler would specify.  "If price is less then 0, stop the simulation, display message to user saying 'calculation error, prices can never be negative'".  I see it as a way of allowing modeler generated runtime errors/warnings.

I think this is important because it lets the modeler warn users of the simulation when the simulation has exited reasonable bounds of results or may be operating incorrectly.  I think this will help to de-complicate the feature for v1 of the spec (removing the image, videos aspects), while providing useful functionality, while also giving us a base to suggest additions in future versions of the spec.  I still think even this core subset of functionality is an optional feature <uses_events/> in the options tag.

Billy


On Sun, Jun 1, 2014 at 9:14 PM, Will Glass-Husain <wglass@forio.com> wrote:
I agree with you, Bobby for the reasons you listed.

Look forward to any thoughts on this from Karim, Bob, etc.

WILL


On Sun, Jun 1, 2014 at 5:58 PM, Bobby Powers <bobbypowers@gmail.com> wrote:
Hello Will,

I think <include> instead of <model url> is a very nice simplification.

I have said before I that I think event posters should be removed from the spec - they are not a core feature of system dynamics, can be implemented as an isee vendor extension, and then added in a future expanded version of the spec if they're adopted by other vendors.

yours,
Bobby


On Sat, May 31, 2014 at 2:50 PM, Will Glass-Husain <wglass@forio.com> wrote:
Hi,

I'm working through some more details this weekend on the model schema.  More questions.

(1) <model url="">

In <model> I see you can use a URL for model contents.  

I note that the include tag provides the same capability (ability to include models from an external model) and it's more specific (includes the ability to version, etc)..     I propose we drop the "url" attribute from model and instead encourage use of <include>.

The spec reads:

Optional reference to a separate model file for the model contents:  url="" with a URL path. Since the <module> tag can also specify the model file URL, this is only needed for models that do not use modules. However, when the same module is shared in multiple parts of the file, it is better to create one URL reference in a model block, rather than specifying it in the module block.

Comments?

(2) <event_poster>

There is not a complete example for event_poster in the spec.  Is this how it works?  

<event_poster min="0" max="1000000">
  <threshold value="1000" direction="decreasing" repeat="each">
    <event sim_action="message">Your profit is dropping</event>
  </threshold>
  <threshold value="100" direction="decreasing" repeat="once">
    <event sim_action="stop">You are fired!</event>
  </threshold>
</event_poster>


Cheers, WILL
--
William Glass-Husain   /forio  |  +1 (415) 440 7500 x89  |  forio.com





--
William Glass-Husain   /forio  |  +1 (415) 440 7500 x89  |  forio.com






--
William Glass-Husain   /forio  |  +1 (415) 440 7500 x89  |  forio.com





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]