Opened 7 years ago
Last modified 7 years ago
#4429 new defect
Builtin function cardinality is not implemented in Ceval.cevalBuiltinHandler
Reported by: | Patrick Täuber | Owned by: | Adrian Pop |
---|---|---|---|
Priority: | high | Milestone: | Future |
Component: | Backend | Version: | |
Keywords: | cardinality. ThermoSysPro | Cc: |
Description
This leads to problems, e.g. if the binding of a structural parameter contains cardinality.
To reproduce such a case please use the ThermoSysPro model ThermoSysPro.Examples.SimpleExamples.TestCentrifugalPump5.mo
.
In the current version of the library there is a workaround, so please remove annotation(Evaluate=true)
for
parameter Boolean dyn_mech_equation=((cardinality(M) <> 0) and dynamic_mech_equation);
in ThermoSysPro.WaterSteam.Machines.CentrifugalPump.mo
.
Since the structural parameter centrifugalPump.dyn_mech_equation
cannot be evaluated in the frontend due to cardinality function, no branch for the conditional initial equation can be chosen:
Initial Equations (4, 3) ======================================== 1/1 (0): if centrifugalPump.dyn_mech_equation then der(centrifugalPump.w) = 0.0 end if [unknown] ...
Thus, during initialization this equation is not considered and removed in "Simple Equations". In consequence $DER.centrifugalPump.w
is solved in another equation which inevitably leads to a division by zero and the model fails.
Change History (3)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Component: | Frontend → Backend |
---|
comment:3 by , 7 years ago
As far as I can see, the cardinality call is removed at the expected position, but it's of course done between the frontend and backend where cardinality can be resolved.
I see a few proposals for resolving the issue (in order of preference):
- Making the backend see the unbalanced if-equation (must have the same number of variables solved in each branch unless compilation can select a single branch and use this information to force evaluation of the condition)
- Adding Evaluate=true or ContainedCardinality=true to the parameter equation to make it easier for the backend to identify the equation
Yes, bindings of structural parameters should not contain calls to cardinality: in order to know the cardinality, you need to flatten the model to get all connections. But in order to flatten the model, you need to know all structural parameters.
The cardinality operator is deprecated and restricted: