Opened 7 years ago

Closed 5 years ago

Last modified 5 years ago

#4157 closed defect (fixed)

Problems with complex numbers

Reported by: belen.goncer-maraver@… Owned by: AnHeuermann
Priority: blocker Milestone: 1.14.0
Component: Backend Version:
Keywords: Complex numbers Cc: Karim.Abdelhak, AnHeuermann

Description

Two problems which concern operations with complex numbers have been encountered with OpenModelica.

You will find attached two models which enables to reproduce the errors encountered.

1- The model called "when_init_complex": The somme of complex numbers doesn't work correctly in this case.

2- The model called "if_complex_if_expression": A problem is encountered while using the "if expression". However, if we use the "if clause", the model works correctly.

I Thank you in advance for the information you can provide us concerning these problems and for the updates of Open Modelica.

The version of OpenModelica that I use is : OMEdit V1.9.5 connected to OpenModelica v1.9.6.

Attachments (1)

Tests_OM_pour_OM.mo (588 bytes) - added by belen.goncer-maraver@… 7 years ago.
Models to reproduce errors with complex numbers

Download all attachments as: .zip

Change History (17)

Changed 7 years ago by belen.goncer-maraver@…

Models to reproduce errors with complex numbers

comment:1 Changed 7 years ago by anonymous

see also #4055

comment:2 Changed 7 years ago by ceraolo

Usage of complex numbers in Modelica is very important for extensive usage of MSL QuasiStationary Library.
I have a full family of systems for which QuasiStationary is the right solution: electric AC lines feeding trains. I'm researching a lot on this topic.

I've come across several cases in which OM has issues with complex numbers, but the two in this ticket are very basic ones, so they should get top priority for me.

I would be very grateful if these two issues are addressed in the near future. After they are, I can try to see whether some of my models containing complex numbers start to work. In case they do not I could contribute with further tickets.

comment:3 Changed 7 years ago by adrpo

  • Component changed from *unknown* to Backend
  • Owner changed from somebody to lochel

Fixed the front-end part of the issues with dd5fb2/OMCompiler.
Added flattening tests in b00c93/OpenModelica-testsuite.

The when model does not work yet to simulate, the if one works fine now.

comment:4 Changed 7 years ago by adrpo

@lochel: can you see why the when model does not work to build? Or at least point me into the right direction.

As far as I can see we need to expand the complex equation (which is transformed into BackendDAE.ASSIGN) into each of the scalar components.

If I move the when equation outside when and remove the when equation then it works fine:

model when_init_complex
  Real a_re;
  Real a_im;
  Complex Eo;
equation
  a_re = 10;
  a_im = 0;
  Eo = Complex(a_re, a_im) + Complex(10, 0);
end when_init_complex;

comment:5 Changed 7 years ago by adrpo

One more piece of info, when I change the when equation in a when algorithm it works fine:

model when_init_complex
  Real a_re;
  Real a_im;
  Complex Eo;

equation
  a_re = 10;
  a_im = 0;

algorithm
  when initial() then
   Eo := Complex(a_re, a_im) + Complex(10, 0);
 end when;
end when_init_complex;

comment:6 Changed 7 years ago by ceraolo

There are several tickets open regarding Complex numbers.
At least the following ones: #4055, #4157, #4297, #4354, All from different people.

I think that this means some enhancement on how OM deals with with them is highly needed.
I myself I'm working a lot on models relying on complex matrices, but I'm forced to use another tool (dymola), which has issues with complex numbers as well, but is more manageable.

Among these tickets, the priority of #4055 is already critical, the others' are High.

May I ask the developers to raise the priority of this ticket #4157 as well?

In fact this ticket shows very basic issues since they do not involve arrays nor algorithms. Therefore it seems to be a good starting point on the way to enhance OM complex number managing capability.
THKX

comment:7 Changed 7 years ago by casella

Regarding the test cases reported here, I get the following results.

Model when_init_complex now fails with

Tests_OM_pour_OM.when_init_complex.c: In function 'Tests_OM_pour_OM_when_init_complex_eqFunction_4':
Tests_OM_pour_OM.when_init_complex.c:77:5: error: '$PEo' undeclared (first use in this function)
     $PEo = omc_Complex(threadData, 20.0, 0.0);

Could be related to #3276.

Model if_complex_if_expression now fails with

[Tests_OM_pour_OM: 21:5-21:98]: Internal error function createNonlinearResidualEquations failed for equation: 
Complex(E.re - V.re, E.im - V.im) = if model_type then Complex(0.0, 0.0) else Complex(Z.re, Z.im)

[C:/dev/OpenModelica64bit/OMCompiler/Compiler/SimCode/SimCodeUtil.mo: 5939:7-5939:46]: Internal error complex equations currently only supported on form v = functioncall(...). 
Equation: Complex(E.re - V.re, E.im - V.im) = if model_type then Complex(0.0, 0.0) else Complex(Z.re, Z.im) solve for {V.im,V.re}

One possible solution is sketched in #4354

comment:8 Changed 5 years ago by casella

Status update with 1.14.0-dev7, using the new front-end

when_init_complex fails during compilation of C-code with

Tests_OM_pour_OM.when_init_complex.c: In function 'Tests_OM_pour_OM_when_init_complex_eqFunction_4':
Tests_OM_pour_OM.when_init_complex.c:83:5: error: '$PEo' undeclared (first use in this function)
     $PEo = tmp0;
     ^
Tests_OM_pour_OM.when_init_complex.c:83:5: note: each undeclared identifier is reported only once for each function it appears in

while if_complex_if_expression fails in the SimCode phase with

[2] 11:01:18 Translation Error
[C:/dev/OM64bit/OMCompiler/Compiler/SimCode/SimCodeUtil.mo: 2499:7-2499:46]:
 Internal error function createNonlinearResidualEquationsComplex failed for:
Complex(E.re - V.re, E.im - V.im) = if model_type then Complex(0.0, 0.0) else Complex(Z.re, Z.im)

In both cases it seems that the problem is that the Complex equation is not split into its scalar constituents; the output with -d=newInst,optdaedump is

Equations (1, 2) 
======================================== 
1/1 (2): Complex(E.re - V.re, E.im - V.im) = if model_type then Complex(0.0, 0.0) else Complex(Z.re, Z.im)   [dynamic |0|0|0|0|] 
 
Equations (1, 2) 
======================================== 
1/1 (2): when false then 
  Eo := Complex(10.0 + a_re, a_im); 

My educated guess is that equations inside when statements are not subject to a call to lowerExtendedRecordEqn, similarly to what previously happened to initial equations, see ticket:5236#comment:6.

@perost, can you please check that and fix it?

Thanks!

comment:9 Changed 5 years ago by casella

  • Component changed from Backend to New Instantiation
  • Milestone changed from Future to 2.0.0
  • Owner changed from lochel to perost
  • Status changed from new to assigned

comment:10 Changed 5 years ago by casella

if_complex_if_expression now works fine with the NF.

when_init_complex still fails as in comment:7

comment:11 follow-up: Changed 5 years ago by casella

  • Cc Karim.Abdelhak AnHeuermann added
  • Component changed from New Instantiation to Backend
  • Owner changed from perost to lochel

When compiling when_init_complex with the NF, the C code compilation fails with

when_init_complex.c: In function 'when_init_complex_eqFunction_4':
when_init_complex.c:92:5: error: '_omcQuot_456F' undeclared (first use in this function)
     _omcQuot_456F = tmp0;
     ^
when_init_complex.c:92:5: note: each undeclared identifier is reported only once for each function it appears in

Looking at the optdaedump output, the when equation shows up correctly as

Variables (2) 
======================================== 
1: Eo.im:DISCRETE()  "Imaginary part of complex number"when_init_complex, Complex type: Real  
2: Eo.re:DISCRETE()  "Real part of complex number"when_init_complex, Complex type: Real  
 
 
Equations (1, 2) 
======================================== 
1/1 (2): when initial() then 
  Eo := Complex(10.0 + a_re, a_im); 
end when;   [dynamic |0|0|0|0|] 

for a number of steps. Then it shows up for a few steps as

Variables (4) 
======================================== 
1: a_im:VARIABLE()  = 0.0 when_init_complex type: Real  
2: a_re:VARIABLE()  = 10.0 when_init_complex type: Real  
3: Eo.im:DISCRETE(fixed = false )  "Imaginary part of complex number"when_init_complex, Complex type: Real  
4: Eo.re:DISCRETE(fixed = false )  "Real part of complex number"when_init_complex, Complex type: Real  
 
 
Equations (3, 4) 
======================================== 
1/1 (2): Eo = Complex(10.0 + a_re, a_im)   [dynamic |0|0|0|0|] 
2/3 (1): a_im = 0.0   [initial |0|0|0|0|] 
3/4 (1): a_re = 10.0   [initial |0|0|0|0|] 

and finally as

Variables (2) 
======================================== 
1: Eo.im:DISCRETE()  "Imaginary part of complex number"when_init_complex, Complex type: Real  
2: Eo.re:DISCRETE()  "Real part of complex number"when_init_complex, Complex type: Real  
 
 
Equations (1, 2) 
======================================== 
1/1 (2): when false then 
  Eo := Complex(10.0 + a_re, a_im); 
end when;   [dynamic |0|0|0|0|] 

The way it is handled in the last two steps seems plain wrong to me, but maybe I simply do not understand well the optdaedump. Lennart, Karim, Andreas, can you please check?

comment:12 Changed 5 years ago by casella

  • Milestone changed from 2.0.0 to 1.14.0
  • Priority changed from high to blocker

Marking this as a blocker for 1.14.0, we should get Complex numbers to work with that release.

comment:13 in reply to: ↑ 11 Changed 5 years ago by AnHeuermann

  • Owner changed from lochel to AnHeuermann

comment:14 Changed 5 years ago by AnHeuermann

Replying to casella:

Variables (2) 
======================================== 
1: Eo.im:DISCRETE()  "Imaginary part of complex number"when_init_complex, Complex type: Real  
2: Eo.re:DISCRETE()  "Real part of complex number"when_init_complex, Complex type: Real  
 
 
Equations (1, 2) 
======================================== 
1/1 (2): when false then 
  Eo := Complex(10.0 + a_re, a_im); 
end when;   [dynamic |0|0|0|0|] 

The way it is handled in the last two steps seems plain wrong to me, but maybe I simply do not understand well the optdaedump. Lennart, Karim, Andreas, can you please check?

The way we are handling initial() function is strange (but not wrong though). For the initialization problem everything gets generated right. While simulating the when condition is set to false. Hence this equation.

I made a pull request to fix the problem. Complex equations in when assignments need to be handled seperatly. Every sort of comlpex equation in a when statment should have failed at the momen.

comment:15 Changed 5 years ago by AnHeuermann

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:16 Changed 5 years ago by casella

Thanks Andreas!

Note: See TracTickets for help on using tickets.