Is this valid usage of Modelica's 3.6 "break" feature?

[mestinso]

One apparent potential usage of the break feature is to roughly emulate replaceable behavior but without having the upstream component actually be marked replaceable and also without having to rely on common base classes for the component that is being replaced. Let me give an example where I give an input parameter and apply two operations in series:

model ExampleOperations
  Modelica.Blocks.Sources.Constant const(k=7);
  Modelica.Blocks.Math.Gain operation1(k=2);
  Modelica.Blocks.Math.Gain operation2(k=5);
equation 
  connect(const.y, operation1.u);
  connect(operation1.y, operation2.u);
end ExampleOperations;

Now let's say I want to replace that operation1 with a log operation instead of a gain, but instead of starting a new model I can extend from the above one.

I can do this in the code the following way via code:

model BreakExample
  extends ExampleOperations(break operation1);
  Modelica.Blocks.Math.Log operation1(base=3);
equation 
  connect(operation1.y, operation2.u);
  connect(operation1.u, const.y);
end BreakExample;

Now, I will note that I tested this, and it worked fine in Dymola 2024x (but there are some setup quirks....which can explain if helpful), but my question is whether this is considered safe/valid usage of the new break feature?

[christoff-buerger]

but my question is whether this is considered safe/valid usage of the new break feature?

Yes. This is an absolutely valid application.
The example is a bit artitificial -- just good for demonstration -- but nevertheless all semantic restrictions are satisfied (a more pratical use-case would be fault injection/modeling for example).

[christoff-buerger]

One apparent potential usage of the break feature is to roughly emulate replaceable behavior but without having the upstream component actually be marked replaceable and also without having to rely on common base classes for the component that is being replaced.

or in other words -- more general -- as stated in the Modelica specification:

The goal of selective model extension is to enable unforeseen structural variability without requiring deliberately prepared base-models

[christoff-buerger]

If you like to get an idea for the motivation and more elaborated application examples of selective model extension, you can also have a look in its original motivation paper "Modelica language extensions for practical non-monotonic modelling: on the need for selective model extension": https://2019.international.conference.modelica.org/proceedings/html/papers/Modelica2019paper3B1.pdf

Just ignore the minor differences in syntax, which we improved since then for the final adoption in the Modelica Specification (as it is right now).

[christoff-buerger]

but there are some setup quirks....which can explain if helpful

@mestinso: That would be interesting; which issues did you have?

[mestinso]

but there are some setup quirks....which can explain if helpful

@mestinso: That would be interesting; which issues did you have?

First, assuming everything I presented is OK, then the issues I'm referring to probably just fall under the "tool issue" category. As mentioned, I am testing this in Dymola 2024x. With that said, the issue I'm seeing specifically happens when 1) a model is removed with the break/selective model extension feature, and then 2) a new component is declared, and that component's name is set to the same name as the component that was removed. In fact, given the issues that showed up, this is specifically what made me question whether this was a safe/allowable thing to do.

Now, to explain these issues in Dymola (@HansOlsson FYI):

1. Once the name is set to the name of the component that was removed, the component cannot be renamed via the GUI again. Dymola seems to be confusing the new component with the old one. While the old one should not be re-nameable, the new one should be.
2. Similar to the previous issue, once the name of the new component is set to the name of the component that was removed, the "change class" operation on right-click is now greyed out. Again, Dymola seems to be confusing the new component (which should allow a "change class" operation) with the old component (which shouldn't allow a "change class" operation).
3. Again, once the name of the new component is set to the name of the component that was removed, if the user modifies any of the parameters etc for the the new component, they are also attempted to be modified in the old component. Again, Dymola is confusing the old and new components. To explain this one further with the code, you can see the modification base=3 happens in two spots when performed via the GUI:

model BreakExample
  extends ExampleOperations(break operation1, operation1(base=3));
  Modelica.Blocks.Math.Log operation1(base=3);
equation 
  connect(operation1.y, operation2.u);
  connect(operation1.u, const.y);
end BreakExample;

...this causes issues on check and translation until I manually clear the base=3 in the extends statement.

[HansOlsson]

Yes, those are tool issues - it will be handled internally.

[HansOlsson]

Answered and seems the issues are tool issues.