Opened 8 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 Martin Sjölund, 7 years ago

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:

The cardinality operator should only be used in the condition of assert and if-statements that do not contain connect

comment:2 by Martin Sjölund, 7 years ago

Component: FrontendBackend

comment:3 by Martin Sjölund, 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):

  1. 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)
  2. Adding Evaluate=true or ContainedCardinality=true to the parameter equation to make it easier for the backend to identify the equation
Note: See TracTickets for help on using tickets.