Opened 11 years ago

Closed 11 years ago

#2280 closed defect (fixed)

Possibly bad number of equations and variables computation

Reported by: massimo ceraolo Owned by: probably noone
Priority: high Milestone: 1.9.0
Component: Backend Version: trunk
Keywords: Cc:

Description

When OM R16555 checks the enclosed model it reports 33 equations and 34 variables.
Instead, the model should be balanced (Dymola reports 33 equations and variables).

Attachments (5)

getUPeak.mo (3.1 KB ) - added by massimo ceraolo 11 years ago.
BugPeak.mo (6.4 KB ) - added by massimo ceraolo 11 years ago.
ConnectionGraph_woInductor.graphml (24.1 KB ) - added by Christian Schubert 11 years ago.
yEd ConnectionGraph (without the inductor)
meshOnly.mo (2.6 KB ) - added by massimo ceraolo 11 years ago.
tiny.mo (7.4 KB ) - added by massimo ceraolo 11 years ago.
A model containing the issue (model tiny in package tiny)

Download all attachments as: .zip

Change History (10)

by massimo ceraolo, 11 years ago

Attachment: getUPeak.mo added

comment:1 by Per Östlund, 11 years ago

It seems like there might be some issues with this model. Dymola does say it's balanced when you check it, but the model does not simulate. Dymola gives an error about overconstrained connectors which are connected but that does not have any root defined when you try to simulate it.

by massimo ceraolo, 11 years ago

Attachment: BugPeak.mo added

comment:2 by massimo ceraolo, 11 years ago

The model does not simulate because it is a sensor and as such it needs to be connected to a circuit to operate.
I've added a tiny package named "BugPeak", that contains the model "simpleMesh".
This model uses "getUPeak" and checks and runs well under Dymola.
OM complains about equation balance and does not run it.

comment:3 by Christian Schubert, 11 years ago

As far as I can tell, it has got to do with the connection graph. There are two VoltageSources within the system. Each having the root:

Connections.root(pin_p.reference);

And therefore each source provides an equation for reference.gamma:

omega = 2*Modelica.Constants.pi*f;
omega = der(pin_p.reference.gamma);

Problem is that in the OpenModelica Connection Graph both roots are connected to each other and therefore (indirectly)

U.pin_p.reference.gamma = U1.pin_p.reference.gamma;
der(U.pin_p.reference.gamma) = U.omega; 
der(U1.pin_p.reference.gamma) = U1.omega;

holds, with known U.omega and U1.omega.

The question that springs to mind is if the sources are modelled correctly?

A possible solution could be not to connect two roots with each other, i.e. also break the connection between getUPeak1.negativePin and U.pin_n for example.
Although, in this case, this seems physically dodgy to me as this would allow the user to connect two sources with different frequency. But then there is the assert statement

 assert(abs(reference1.gamma - reference2.gamma) < 1E-6*2*Modelica.Constants.pi, "Reference angles should be equal!");

Which would at least throw an error at runtime.

by Christian Schubert, 11 years ago

yEd ConnectionGraph (without the inductor)

comment:4 by massimo ceraolo, 11 years ago

I've created a very small model containing the issue.
It contains just one source.
It is in "tiny.mo" that I will upload in a minute.

Last edited 11 years ago by massimo ceraolo (previous) (diff)

by massimo ceraolo, 11 years ago

Attachment: meshOnly.mo added

by massimo ceraolo, 11 years ago

Attachment: tiny.mo added

A model containing the issue (model tiny in package tiny)

comment:5 by massimo ceraolo, 11 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.