The behavior of a CPN often depends on the values of several parameters in the model. Changing the values of the parameters will usually change the behavior of the model.
Parameters can be used to define many kinds of values, such as: the number of resources in a model, time delays, intervals of time between certain events, the probability of certain events happening, and the distribution of numerical values (e.g., exponential or normally distributed processing times).
Parameters can be defined in several different ways.
A parameter can be defined as a constant in a
val declaration. For example, the parameter
n in the dining philosophers net, determines how many philosophers (and chopsticks) are to be represented in the model:
A parameter can also be defined as part of another declaration. For example, in the Timed Protocol net, the minimum and maximum amount of time required to transmit a packet are defined the color set
NetDelay by the constants
Parameters can also be hard-coded intoinscriptions in the net. For example, in the example net for the Timed Protocol, the time required to send a packet is determined by the constant
9 in the time delay inscription for the
Send Packet transition:
Similarly, in the Resource Allocation net, the numbers of
p processes that are represented in the model, are determined by the coefficients in the initial marking inscriptions for places
A parameter can also be defined in a token color. For example, in the Timed Protocol net, the color of the token on place
SP determines the probability that a packet will be transmitted successfully:
The color of this token is determined by the initial marking inscription of the place, and the color of the token is never changed by the occurrence of the
Transmit Packet transition.
Parameters can also be defined as reference variables (in
globref declarations). The following example shows how the
OK function from the Timed Protocol can be rewritten to use a reference variable (rather than the value of a token on a place) to determine the probability for successful transmission. The declarations for variable
s and function
OK must be changed to:
globref s = (8: Ten0);
fun OK(r:Ten1) = (r<=(!s));
s has been changed to a reference variable. Its initial contents is the value
8 from the color set
OK function has been changed to take one argument instead of two. In the body of the function, the argument
r is compared to the contents of
s which is obtained using the operator
!. Given these declarations, the inscription on the output arc from the
Transmit Packet transition must be changed, and place
SP can be removed:
Changing parameter values
All parameter values can, of course, be changed.
If a parameter is defined as a constant in a net inscription, as a constant token color, or in a declaration of a constant (a
val declaration), a color set, or a function, then the only way to change the value of the parameter is to manually edit the appropriate declaration or net inscription. When such a change is made, CPN Tools will automatically recheck the syntax for the parts of the model that are dependent on the declaration or inscription.
If a parameter is defined as a reference variable, then the value of the parameter can be changed without having to manually edit the declaration, and it is not necessary to recheck the syntax of any parts of the model. One way to change the contents of a reference variable is to apply the Evaluate ML tool to an auxiliary text containing an appropriate CPN ML expression. Here, for example, is a CPN ML expression that will change the contents of reference variable
s to the value
Reference variables in initial marking inscriptions
Note that initial marking inscriptions should not depend on reference variables. This is due to the fact that the initial marking of a place is calculated once immediately after a syntax check of the place.
Suppose that an initial marking inscription did depend on a reference variable. Suppose also that the contents of the reference variable is changed after the syntax of the place has been checked. If model is returned to the initial marking, e.g. if the Rewind tool is applied, then the initial marking of the place will not be recalculated, and the initial marking of the place will not depend on the new value of the reference variable.
If you want to have an initial marking that is dependent on a reference variable, then it is necessary to add an initialization transition that is used to create a pseudo-initial marking for the place.
Consider, for example, the Queue System net. The number of server resources in the model is determined by the initial marking inscription of the place Idle. Each token on the place in the initial marking represents one server. Here the initial marking inscription determines that there should be one server represented in the model:
The number of servers represented in the model can be changed by manually changing the initial marking inscription. Here there are four servers represented in the model:
This change can be made only by manually editing the initial marking inscription, which will force the syntax of the place to be checked again.
Suppose that we would like to define a reference variable that determines the number of server resources in the model. The following declarations define such a reference variable, and a function that can be used to generate the tokens representing the servers in the initial marking:
globref num_of_servers = 4;
fun initServers() = (!num_of_servers)`server;
If we want to use the
initServers function to determine the (pseudo-) initial marking of place
Idle, then it is necessary to add a transition that will properly initialize the number of tokens on the place.
The example net for Queue System Configurations shows an example of how parameters can be defined with reference variables. The example also contains a function that is used to define several different model configurations by assigning different values to the reference variables. When the function is called a number of simulation replications will be automatically run for each of the specified model configurations.