一般来说，这个问题是因为when子句中的方程影响触发它们的条件语句。
对于 Modelica，您需要了解的是，求解器将使用“候选解”作为模拟过程的一部分来评估方程。这些不一定是它最终选择的解决方案，但它仍然需要在接近最终解决方案时对其进行评估。
这有什么关系？在你的例子中，我看到你正在改变“融化”变量的值。但如果该值随后影响介质温度（从而引发“熔化”值的变化），则该工具将检测到方程系统中的不一致。一个工具也许能够迭代找到一致的候选解决方案，但 Dymola 只是“下注”并表示它不支持这种情况。
现在，这里要理解的重要一点是，基本上这通常是全部不相关的。为什么？因为在大多数情况下，用户确实不希望在这种情况下使用 when 子句的默认语义。大多数用户想要的是将when 子句中的条件视为“原因”，并将when 子句中的方程视为“结果”。从这个意义上说，它们是连续的，结果不应该逆转并影响原因（尽管白条纹写了一首关于这种情况的伟大歌曲;-)）。
这里的一般模式是隔离条件，然后在 when 子句中在其周围添加一个“pre”运算符。如果原始模型如下所示：
model Test
...
equation
when x>12.5 then
// equations involving y
end when;
// equations coupling x to y
end Test;
您只需将模型重构为如下所示：
model Test2
...
Boolean cond;
equation
cond = x>12.5;
when pre(cond) then
// equations involving y
end when;
// equations coupling x to y
end Test;
这里最重要的是涉及 y 的方程只出现after条件为真。在这种情况下，“pre”基本上表示，如果当前时间减去一些 epsilon，则条件值wastrue 那么（作为响应）when 子句中的方程开始起作用。
这种情况可能会导致一种称为“chattering”的情况，其中条件值会随着时间流逝的每个“epsilon”而翻转，但这意味着问题没有很好地提出。
我希望这有一定道理。我承认，在复杂的情况下，很难准确检测代数环存在的位置（尽管 Dymola 试图为您提供一些诊断）。另外，在某些情况下，您确实需要 Modelica 的默认行为，因此您并不总是想添加无偿的“pre”限定符。
如果您对此解释有任何疑问，请告诉我。
