我们已经介绍了时间事件和状态事件，现在我们来探讨一些与状态事件相关的重要的复杂情况。令人惊讶的是，即使是很简单的模型也可能引入这些复杂情况。

基本衰变模型

考虑以下近乎简单的模型：

model Decay1
  Real x;
initial equation
  x = 1;
equation
  der(x) = -sqrt(x);
end Decay1;

如果我们尝试对该模型进行 5 秒钟的模拟，结果发现模拟大约在 2 秒后结束，其轨迹如下：

再次，数值方面的问题出现了。尽管从数学角度来看，x 的值不应低于零，但使用数值积分技术，可能会出现微小的误差累积，从而使 x 降为零以下。一旦发生这种情况，sqrt(x) 表达式就会引发浮点异常，模拟程序也将终止。

守卫表达式

为避免这种情况，我们或许可以引入一个 if 表达式来防止计算负数的平方根，例如这样：

model Decay2
  Real x;
initial equation
  x = 1;
equation
  der(x) = if x>=0 then -sqrt(x) else 0;
end Decay2;

通过模拟这个模型，我们得到了以下轨迹[1]：

再次，模拟失败了。但这是为什么呢？它之所以失败，也是出于同样的原因，即由于对负数求平方根而产生的数值异常。

当人们在引入保护表达式之后（正如我们所做的那样）看到类似这样的浮点运算异常的错误信息（比如除以零的情况）时，往往会感到十分困惑。他们自然而然地认为，如果 x 小于零，那么 sqrt(x) 就无法进行计算。但这种假设是错误的。

事件与条件表达式

事件在行为中的作用

假设有如下的 if 表达式：

der(x) = if x>=0 then sqrt(x) else 0;

完全有可能在调用 sqrt 函数时会使用负数作为参数。其原因与这是一个状态事件这一事实有关。请记住，时间事件的发生时间是事先已知的。但对于状态事件来说，情况并非如此。为了确定事件何时发生，我们必须搜索解决方案轨迹，以查看当条件（例如 x >= 0 变为假时）何时会变为不成立的状态。

需要明白的重要一点是，在事件发生之前，行为并不会改变。换句话说，这个 if 表达式的两个部分分别代表了两种不同的行为，即 der(x)=sqrt(x) 和 der(x)=0。由于 x 初始时大于零，所以初始的行为是 der(x)=sqrt(x)。求解器会一直使用这个方程，直到确定由 x>=0 所表示的事件发生的时间。为了确定那个事件的时间，它必须越过条件表达式值发生变化的那个点。这意味着，在试图精确确定条件 x>=0 从真变为假的时间时，它会继续使用方程 der(x)=sqrt(x)，尽管 x 是负数。

大多数用户最初都认为，每次对 der(x) 进行计算时，都会同时计算 if 表达式（确切地说，就是 if 表达式中的条件表达式）。希望前一段内容已经清楚地说明了并非如此。

由于 Modelica 能够从 if 表达式中提取出一种被称为“零交叉”函数的元素，所以以往为完成集成步骤而反复尝试和重试的过程现在可以省去了。这个函数之所以被称为“零交叉函数”，是因为通常它的构造会使得在事件发生点处有一个根。例如，如果我们有以下的 if 表达式：

y = if a>b then 1 else 0;

零交叉函数为 a - b 。选择此函数是因为它恰好在 a > b 的位置从正转负。

回想一下我们之前的方程式：

der(x) = if x>=0 then sqrt(x) else 0;

在这种情况下，零交叉函数就是 x ，因为该事件正是在 x 自身从正变负时发生的。

Modelica 编译器会将模型中的所有零交叉函数收集起来，供积分器使用。在积分过程中，积分器会检查是否有任何零交叉函数的符号发生了变化。如果有变化，它就会使用该步骤中计算出的解来插值零交叉函数，从而确定零交叉函数的根在时间上的位置，这就是事件发生的时刻。这个过程效率更高，因为根查找算法有更多的信息来帮助它们确定根的位置（例如零交叉函数的导数等信息），而且评估过程非常简单，因为它不需要进行额外的积分步骤，只是评估触发积分步骤中的插值函数即可。

事件抑制

但经过这一切之后，我们仍不清楚如何避免我们在“ Decay1”和“Decay2”模型中所遇到的问题。答案是一个名为“noEvent”的特殊操作符。这个“noEvent”操作符会抑制这种特殊的事件处理。相反，它会按照大多数用户原本预期的方式进行操作，即对 x 的每个值都评估条件表达式。在以下模型中，我们可以看到“noEvent”操作符的实际应用：

model Decay3
  Real x;
initial equation
  x = 1;
equation
  der(x) = if noEvent(x>=0) then -sqrt(x) else 0;
end Decay3;

而结果可以在这里查看：

现在模拟过程顺利完成，没有任何问题。这是因为没有使用“noEvent”这一参数，从而确保了在调用“sqrt(x)”函数时，其输入的 x 值永远不会为负数。

这似乎有些奇怪，我们竟然需要明确地使用“noEvent”操作符才能获得我们认为最直观的行为表现。为何不将默认行为设定为最直观的那种呢？答案在于性能。通过使用条件表达式来生成事件，可以提高模拟的性能，因为它能为求解器提供关于何时会出现行为突然变化的线索。大多数时候，这种方法不会造成任何问题。我们在本章中所给出的示例旨在突出这个问题，但它们并不能代表大多数情况。因此，noEvent 不是默认值，而是必须明确使用。需要指出的是，noEvent 操作符仅应在行为有平滑过渡的情况下使用，否则可能会导致性能问题。

抖动

在使用 Modelica 时，您迟早会遇到一种被称为“抖动”的常见现象。请看下面的模型：

model WithChatter
  Real x;
initial equation
  x = 2;
equation
  der(x) = if x>=1 then -1 else 1;
end WithChatter;

实际上，这个模型的行为是：对于任何初始值 x，它都会沿着直线向 1 运动。从数学角度来讲，一旦 x 的值达到 1，它就应该保持在这个值上。这是因为任何偏离 1 的情况，无论是大于还是小于 1，都会立即导致它回到 1。

但我们不会以纯粹的数学方式来求解这些方程。我们将采用浮点数表示法，并使用数值积分器。因此，我们会有精度限制和积分误差需要考虑。最终结果是，x 的轨迹不会精确地保持在 1 上，而是会略微高于和低于这个值。每次出现这种情况时，都会产生一个事件。

模拟这个模型后，我们得到了以下结果：

这种模型会产生一种被称为“抖动”的效应。抖动指的是由于大量事件的发生导致模拟性能下降的现象，这些事件人为地缩短了解算器所采用的时间步长。如果我们查看模拟过程中的 CPU 使用时间，就会清楚地看到其影响。一旦 x 接近 1，CPU 使用时间就会急剧上升。这是因为幕后发生的事件会引发大量极短的时间步长，从而极大地增加了所进行的计算量。关于“WithChatter”示例的重要之处在于，它似乎有明显的数学解决方案，但由于事件的高频率，仍然会受到模拟性能下降的影响。

这是另一个可以借助“noEvent”操作符来解决问题的例子。我们可以通过使用“noEvent”操作符来抑制由条件表达式所产生的事件，具体做法如下：

model WithoutChatter
  Real x;
initial equation
  x = 2;
equation
  der(x) = if noEvent(x>=1) then -1 else 1;
end WithoutChatter;

通过这样做，我们将会得到大致相同的解决方案，但同时模拟性能也会更佳：

请注意，在 x 为 1 之前和之后，CPU 使用率的斜率并无明显变化。将此与 WithChatter 案例中所呈现的显著差异进行对比。

实际上，像这样的方程式并不常见。在这种情况下，我们采用了极端案例以清晰地展示抖动的影响。这里所描述的行为并非特别符合实际情况或物理规律。在这种情形下，我们夸大了这种效应，以便清晰地展示其对模拟性能的影响。

在现实世界中，更常见的抖动现象通常会包含一个处于稳定状态的条件表达式（例如“Decay2”就是一个很好的例子）。在这种情况下，抖动的发生是因为系统往往会自然地稳定在或接近条件表达式所在的位置。但由于精度和数值方面的考虑，与该条件表达式相关的事件常常会被触发。在系统中存在许多组件且都处于或接近此类平衡点的情况下，这种影响会更加严重。

速度与准确性

想必到目前为止的讨论已经清楚地说明了在某些情况下为何需要抑制事件。但有人可能会合理地提出这样的疑问：为什么不直接跳过事件，而总是去评估条件表达式呢？那么让我们花些时间来探讨这个问题，并解释一下为什么总体而言，将事件与条件表达式关联起来是一个非常好的想法[2]。

如果没有事件检测功能，积分器就会直接忽略这些事件。一旦出现这种情况，积分器就会遗漏行为上的重要变化，这将对模拟的准确性产生重大影响。这是因为大多数积分算法的准确性是基于对基础函数及其导数的连续性的假设。如果这些假设被违反，我们就需要让积分算法知晓，以便它们能够考虑到这些行为上的变化。

这就是事件发挥作用的地方。它们会促使整合过程在行为发生改变的那一刻停止，然后在行为改变完成后再次重新开始。其结果是提高了准确性，但代价是模拟速度变慢。让我们来看一个具体的例子。考虑以下一个简单的 Modelica 模型：

model WithEvents "Integrate with events"
  parameter Real freq = 1.0;
  Real x(start=0);
  Real y = time;
equation
  der(x) = if sin(2*Modelica.Constants.pi*freq*time)>0 then 2.0 else 0.0;
end WithEvents;

观察这个系统，我们可以发现，x 的导数一半时间是 2，另一半时间则是 0。因此，在每个这样的周期内，x 的平均导数应该是 1。这意味着在每个周期结束时，x 和 y 应该相等。

如果我们对“具有事件处理功能的控件”模型进行模拟，将会得到以下结果：

请注意，在每个周期结束时，x 和 y 的轨迹会交汇在一起。这直观地表明了底层积分的准确性。即使我们增加底层周期的频率，我们也会发现这一特性依然成立：

然而，现在让我们来考虑这样一种情况：我们使用完全相同的积分参数，但通过使用“noEvents”操作符来抑制事件，具体操作方式如下：

model WithNoEvents "Integrate without events"
  parameter Real freq = 1.0;
  Real x(start=0);
  Real y = time;
equation
  der(x) = noEvent(if sin(2*Modelica.Constants.pi*freq*time)>0 then 2.0 else 0.0);
end WithNoEvents;

在这种情况下，集成器无法察觉行为的变化。它会尽力进行准确的集成，但由于没有明确了解行为变化发生的具体位置，它会盲目地继续使用错误的导数值，并将结果过度延伸至行为变化之外的范围。如果我们使用相同的集成器设置来模拟“无事件”模型，就可以看到我们的结果会有多么大的差异：

请注意，这个积分器很快就出现了相当严重的误差。

在这些示例中所采用的集成设置旨在展示“noEvent”操作符对准确性可能产生的影响。然而，这些设置的确是为了突出这些差异而选择的。如果使用更常见的设置，结果的差异可能不会如此显著。此外，由于使用“noEvent”操作的影响会因不同的求解器而有很大差异，所以无法对其进行预测或量化。但核心观点是明确的：使用“noEvent”操作符会对准确性模拟结果产生重大影响。

[1] 该模型并非总是会失效。其失效情况取决于引入的集成误差大小，而这一点又取决于所使用的数值精度。

[2] 特别感谢莱昂内尔·贝尔蒙对我的初始论述提出质疑，并指出了我自身的一些未经证实的假设。因此，这次的解释有了很大改进，并且包含了支持得出的结论的实证结果。