Conditions

A "condition" in SAInt is composed of a "Boolean logic conditional expression" returning a true or false value, and an "evaluation rule", testing the application of the specified event. The table of the scenario events and the Property Editor, once an event is selected, show the field Condition and Evaluation where the user needs to specify the expression and the rule for the evaluation.

Conditions are used in dynamic simulations to direct a possible solution for the system at time step t_N+1, starting from time step t_N.

The use of conditions is discouraged and not possible for steady state problems or optimization problems. In a steady state gas simulation, adding conditions to a scenario may frequently enforce a set of infeasible constraints. It also requires the use of multiple instances of the same type of event for an object (e.g., given a supply point we would define a PSET if condition A is true and another PSET if condition B is true). This option is not allowed in SAInt.

In optimization problems like DCUCOPF, it is typically not possible to have a meaningful evaluation of expressions because the values of variables are not known until the optimization is complete unless the terms of expressions refer to known properties. Additionally, DCUCOPF has several constraints linked over multiple time steps (for example, uptime and downtime), making it difficult to control the individual time steps independently using values from previous time steps. Trying to influence the solution process with ill-defined conditions can cause wrong results or infinite loops. Furthermore, if the user applies conditions using unknowns, the problem will become non-linear, which cannot be handled in a DCUCOPF scenario. Electric constraints ENET are advised in optimization models to relate one object’s unknown parameter with another object’s unknown parameters.

The user is free to build any type of Boolean logic conditional expression. SAInt has a built-in Script Editor for writing statements and checking for any syntax errors. As in the command line, the Script Editor can autocomplete names and properties of objects. The statement is checked for proper formatting, and its results are returned after evaluation for the current time step.

The statement of the expression could be as simple as a comparison between a property of an object and a reference value (e.g., ObjectType.ObjectName.Property > 25) or as complex as multiple comparisons linked by Boolean operators (e.g., ObjectType1.ObjectName1.Property1 > 25 and ObjectType2.ObjectName2.Property2 <= 15 or ObjectType3.ObjectName3.Property3 <> 'OFF').

Table 1 shows an example where the value of a QSET event for a gas demand object is chosen based on the control mode of a control valve. If GCV.CV_1.CTRL=='OFF' returns True at time step t_N, the demand of the gas offtake CGS_02 for time step t_N+1 is set to 10 ksm³/h. If GCV.CV_1.CTRL<>'OFF' returns True, the demand of the gas offtake CGS_02 is set to 150 ksm³/h and a profile. Both conditional events start at the same time. The rule for evaluating the condition is the same, and it is set to DoIFTRUE. The two events are mutually exclusive (i.e., the control valve can be on or off, but not both at any time step) because only one can be logically true for each time step. Figure 1 shows the flow rate at the offtake point and the control mode of the control valve. Note how the last event of the example is overwriting the conditional events from 06:00 a.m. of day 6.

Table 2 shows an example where the value of a QSET event for a gas demand object is chosen based on the value of the outlet pressure of a control valve. If GCV.CV_1.PO<29 returns True at time step t_N, the demand of the gas offtake CGS_02 for time step t_N+1 is set to 10 ksm³/h. If GCV.CV_1.PO>=29 returns True, the demand of the gas offtake CGS_02 is set to 150 ksm³/h and a profile. Both conditional events start at the same time. The rule for evaluating the condition is the same, and it is set to DoIFTRUE. The two events are mutually exclusive (i.e., the outlet pressure can be either lower or higher and equal to the threshold of 29 bar-g, but not both at any time step). Figure 2 shows the flow rate at the offtake point and the control mode of the control valve. Compared to the previous example, two spikes are indicating how during the period the control valve is off, the outlet pressure goes above the threshold, but only for one time step for each spike. As before, the last event of the example is overwriting the conditional events from 06:00 a.m. of day 6.

Table 3 shows an example where the value of a QSET event for a gas demand object is set based on the pressure at the same object and three different operational regions. The regions define a partition of the admissible values for the pressure of the offtake point. They are all mutually exclusive binary events and are evaluated with the same DoIFTRUE rule. Figure 3 shows the flow rate at the offtake point and, for comparison with the previous figures, the control mode of the control valve CV_1. Multiple spikes down to 10 ksm³/h occur during the simulation indicating the crossing between the first and second region for the calculated pressure. As before, the last event of the example is overwriting the conditional events from 06:00 a.m. of day 6.

This last example shows how to define a condition on an object, starting a feedback loop and ending on the same object. The other two examples demonstrate creating a feedback loop starting on a different object from the one impacted.

SAInt applies conditions only when an "evaluation rule" is specified. The evaluation rule answers the question: "For how long do I need to apply the event based on the outcome of the condition?". By default, SAInt uses the evaluation rule NONE, implying that the expression will not be considered. Possible valid rules are:

The use of DoIFTRUE and DoIFFALSE is equivalent if the condition is logically inverted. A DoIFTRUE for a statement like ObjectType.ObjectName.Property > 25 is equivalent to DoIFFALSE with ObjectType.ObjectName.Property <= 25. The same holds for DoUntilTRUE and DoUntilFALSE.

In a simulation, the period during which a condition is evaluated is generally defined by the starting time of the event and the starting time of another event for the same object. It is possible to change this behavior by adding a "time-dependent expression" in the condition statement. The SAInt built-in function gtime allows retrieving the time (in hours) of the current time step and making comparisons with user-defined values.

Let’s change the last event of example 1 (Table 1) in the following way:

Figure 4 shows the effect of the new conditions on the flow rate at the offtake point CGS_02. The two new mutually exclusive conditions are evaluated using the rule IfTRUE and a time-dependent expression where the current time step is compared to a threshold value of hour 18:00 (06:00 p.m.) of February 6. The numeric value 132 indicates 5 days and 12 after the beginning of the simulation. For the time interval from 06/02/2022 06:00 to 06/02/2022 18:00 the first condition is true. And from 06/02/2022 18:00 onward, only the second condition is true.

This example is equivalent to the case of having two simple events starting 06/02/2022 at 06:00 and 06/02/2022 at 18:00, respectively, with no conditions.