Welcome to learning how to build models using Summit! The good news is, if you know how to write formulas in a spreadsheet, you already know a lot. These guides will quickly cover the basics (familiar territory for any that has used a spreadsheet), and then move on to what's new and what makes the language inside Summit (Summit Event Language, or "SEL" for short) so tidy and powerful.
An Event is a building block of a model in Summit. Since models are functional, you can also think of an Event as a function. Unlike most languages, Summit processes these functions based on an internal representation of time that is independent of clock time. In other words, events are interpreted by simulation.
When you define an event, you are defining a function that will run at a certain time, for a certain time (duration), and at a certain interval (once or recurring). This makes events excellent encapsulations of business activities that happen on a schedule.
Just like a function can be empty, all fields and attributes of an event are optional. For an event to be executed, however, it must have either a start date or be linked downstream of another event that has a start date, i.e. it must be triggered.
Lastly, and most important, events may also contain a series of instructions written in Summit Event Language, or SEL (rhymes with "cell"). Since events are essentially functions, SEL expressions are primarily responsible for declaring the behavior of the event when it's triggered.
Events are Types?
When you're first learning a language, it's common to study its types. For a lot of languages, these are things like strings (words), numbers, arrays (lists), etc.
For Summit Event Language, the most useful types to learn are the different types of events available to you as a modeler. Each event has a special behavior. Learning how to chain these behaviors together is how you'll become proficient at SEL.
Events may return one and only one value, the same way a spreadsheet cell always evaluates to a single value. In Summit, these return values are always numeric.
This numeric value can be sent (passed) to another event using a route -- the lines and arrows on the canvas.
Routes have a single attribute: a percentage. This is set to 100% by default, and it specifies the percentage of the return value that should be sent to the next event. So for example, an event with an expression of
=500may have 4 routes to 4 downstream events, each labeled with a 25%. If so, the interpreter will send the number 125 to each event. If the routes are labeled with 100%, it will send the full 500 to each.
When a set of events (a model) is interpreted, you get model output. This output is a record of the internal state of each event immediately after it finishes executing. These measurements can be grouped by some time interval (most commonly a month) to see totals, averages, etc. over that period.
Updated over 1 year ago
Now that you've got an overview of events, let's dive into some examples!