Opened 13 years ago
Last modified 13 years ago
#1574 closed defect (fixed)
Parameter matrix used in equations generate wrong code!
Reported by: | adrpo | Owned by: | adrpo |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | Simulation Code Generation | Version: | |
Keywords: | Cc: | adrpo, sjoelund.se |
Description
This model:
model petrou parameter Real A[14,14] = zeros(14,14); parameter Real F[14,4] = ones(14,4) * 10.5; // make it 12 to be sure we don't run out of bounds parameter Real u[12,4] = ones(12,4) * 1.5; Real x[14]; // Real v[4]; Integer i(start = 0); equation i = integer(floor(time + 1)); der(x) = A*x + F* u[i]; // if you use v here and un-comment below and above is OK // for j in 1:4 loop v[j] = u[i,j]; end for; end petrou;
generates code such as:
#define $Pu localData->parameters[252] ... *real_array_element_addr(&$Pu, 2, (modelica_integer)$Pi, (modelica_integer) 4)
which is wrong as localData->parameters[252] is not a real_array!
Change History (3)
comment:1 Changed 13 years ago by adrpo
comment:2 Changed 13 years ago by sjoelund.se
I will clean up the code generation for rhs crefs a bit... It looks like a mess right now :(
comment:3 Changed 13 years ago by sjoelund.se
Ok, too much of a mess to clean it up. I made it more complex instead :)
We now address constant dimensions (i.e. simulation context) and expression subscripts directly on the (double*) for performance reasons (yes, for performance despite this being the only testcase for this)...
No idea on how to solve this, maybe we could create an array from the parameter array
before using it.