Opened 7 years ago
Closed 7 years ago
#4517 closed defect (duplicate)
Get Complex numbers to work without compromises
| Reported by: | Francesco Casella | Owned by: | Lennart Ochel |
|---|---|---|---|
| Priority: | critical | Milestone: | 1.13.0 |
| Component: | Backend | Version: | |
| Keywords: | Cc: | massimo ceraolo, dr.christian.kral@… |
Description (last modified by )
Complex numbers are increasingly used in Modelica, mainly for electrical system simulation. Modelica.Electrical.QuasiStationary uses them, as well as an increasing number of libraries for electro-mechanical modelling of power systems.
Complex numbers are supported by OMC, but there are still some pending issues. This ticket collects them in the attempt of getting them fixed soon.
- In most (if not all) cases, the best strategy to solve models with Complex unknowns is to eventually transform all Complex equations into their scalar Real counterparts, and then apply all symbolic simplification algorithms to them.
- Wrong code generation for complex numbers in algorithms, see #4055. This requires a fix in the code generation template handling assignment of indexed array of complex or record on left hand side in an assignment.
- Various issues when handling complex equations, see #4157 and #4354. I guess that the solution suggested in #4354, namely transforming equations involving records with two real components into pairs of real equations (which is trivial) and then allowing further symbolic manipulation should automatically fix them
- Sum of complex numbers is not supported, see #4297. This impacts some models in the MSL. Shouldn't be hard to fix either.
Can we try to get this into 1.12.0?
Change History (8)
follow-up: 2 comment:1 by , 7 years ago
follow-up: 4 comment:2 by , 7 years ago
Replying to sjoelund.se:
#4297 you can't get in 1.12.0. It's a really complicated thing involving several design flaws of record handling in OM. One of them being the handling of bindings of parameters. There are more issues, including frontend and code generation of array of record and inline function.
If the OM has fundamental design flaws that prevents the proper support of Complex numbers, it would be very important to point them out, so they can eventually be addressed. Can you do it?
I'd assume the other tickets are also similarly complicated due to the DAE structure not being totally suited for records.
Are you sure that the model transformation suggested in #4354 cannot be implemented? It seems to me just a trivial exercise in pattern matching.
comment:3 by , 7 years ago
| Cc: | added |
|---|
comment:4 by , 7 years ago
Replying to casella:
I'd assume the other tickets are also similarly complicated due to the DAE structure not being totally suited for records.
Are you sure that the model transformation suggested in #4354 cannot be implemented? It seems to me just a trivial exercise in pattern matching.
I would say it can be done in this case, matching Complex(e1,e2) = Complex(e3,e4), but this is a pretty trivial case.
comment:7 by , 7 years ago
| Milestone: | 1.12.0 → 1.13.0 |
|---|
comment:8 by , 7 years ago
| Description: | modified (diff) |
|---|---|
| Resolution: | → duplicate |
| Status: | new → closed |
This ticket is now a bit obsolete. I opened #4835 with a more systematic view of the issue.
#4297 you can't get in 1.12.0. It's a really complicated thing involving several design flaws of record handling in OM. One of them being the handling of bindings of parameters. There are more issues, including frontend and code generation of array of record and inline function.
I'd assume the other tickets are also similarly complicated due to the DAE structure not being totally suited for records.