What is an Event?

In GoldSim, a discrete event is something that occurs instantaneously (as opposed to continuously or gradually) in time. It represents a “spike”, a discontinuity, a command, or a discrete change of state for the system.

For example, through continuous compounding of interest, the money in a bank account continuously increases, but the account can also increase and decrease instantaneously due to discrete events (i.e., deposits and withdrawals).

Such events are particularly important for the Financial Module because the systems being modeling are controlled primarily by discrete occurrences (such as deposits, withdrawals, purchase, expenses, and the exercising of options).

Of course, “instantaneous” and “gradual” are relative terms. That is, whether something is treated as instantaneous or gradual is a function of the time scale of interest, and hence you must differentiate between the two based on the context of your model. Typically, the distinction will be obvious. For example, if the time scale of interest is 10 years, something happening over the span of a day can be considered to be “instantaneous”. If the time scale of interest is several days, however, something happening over the span of a day would in most cases need to be treated in a continuous manner.

GoldSim handles “instantaneous” changes to a model by providing a mechanism for a model to generate and respond to discrete events. This is accomplished by providing the ability to instantaneously trigger an element to take a particular action (e.g., instantaneously change its value) in response to an event. Hence, in GoldSim, an event is specifically defined as an instantaneous occurrence that subsequently triggers a particular action.

• The event occurs when a specified condition (e.g., X > Y) becomes true or false;

• The event occurs based on a specified rate of occurrence, which can be treated as regular or random ("occur exactly once a week" or "occur, on average, once a week").

In addition, some elements can respond to an event generated via one of the mechanisms above, and generate a new event.

In some cases, an event will occur (e.g., X becoming greater than Y) which triggers a particular action in a single element (exercise an option). In such a case, the event is internal to that element, and it does not directly impact other elements. In other cases, however, an event may impact multiple elements, or one element may respond to an event by triggering other elements to take a particular action. In these cases, it is necessary for discrete signals to propagate between elements.

In order to propagate events (and their consequences) between elements in a model, it is necessary to send information between elements intermittently as a "spike" or discrete "packet" of information. To facilitate this, GoldSim allows certain elements to emit and receive (i.e., produce as outputs and/or accept as inputs) a discrete signal. Discrete signals are a special category of outputs that emit information discretely, rather than continuously.

Within GoldSim, there are actually two types of discrete signals that can be passed from one element to another: discrete event signals and discrete change signals.

A discrete event signal is a discrete signal indicating that something (e.g., a purchase or a sale) has occurred. It does not describe the consequence of that occurrence; it simply emits a signal between elements indicating that an event has occurred.

A discrete change signal, on the other hand, emits information regarding the response to an event. In particular, a discrete change signal contains two pieces of information: a value (e.g., 10 dollars) and an instruction (e.g., Add). A discrete change signal can only be generated in response to an event. It can only be received by a few select elements (e.g., a Reservoir, some Financial Module elements) which understand how to process it.

Within the Financial Module, discrete event modeling is a fundamental feature of the elements used to model financial components, and is utilized in the following ways:

• Several elements (which are used to model system components such as funds, accounts, investments, and cash flows) accept as inputs discrete change signals in the form of discrete additions and withdrawals (e.g., deposits, withdrawals, purchases, expenses, revenues).

• Two elements require triggers (by an event) in order to carry out a particular action (i.e., acquire or exercise an option, process an insurance claim).

• Several elements output discrete change signals in response to events (e.g., a discrete output representing the return when an option is exercised). These outputs can then be subsequently used by other elements.

Note: Depending on how the event was generated, it may not fall exactly on a “scheduled update” (i.e., a timestep that was defined in the Time tab of the Simulation Settings dialog). That is, an event could actually occur between scheduled updates of the model. Such events can trigger an “unscheduled update” of the model.