arrays of arrays

[Volker Waurich]

Hi,

Please have a look at the attached model.

There is an initial equation: (+d=dumpSimCode)

5: filter1[1].cr=Modelica.Blocks.Continuous.Internal.Filter.base.CriticalDamping(2, filter1[1].normalized)[Real[2] ]

The output variable is an array of filter1[1].cr[1] and filter1[1].cr[2] which are defined.
But filter1[1].cr does not exist as a variable.

Should this be handled in the codegeneration? Or should the function output be expanded to scalar variables in the backend?

Best,
Volker

[Mahder Alemseged Gebremedhin]

No it doesn't need to be expanded. Yes filter1[1].cr (which is an array) will not exist. If you want to generate code for it it would be generated as something like

real_array_create(tmp1, $filter1$cr_index(1,1), 2)
                        ^^^^^^^^^^^^^^^^^^^^^
                                || 
           filter1[1].cr == filter1[1].cr[1] == filter1.cr[1][1]

and filter1[2].cr will be

real_array_create(tmp1, $filter1$cr_index(2,1), 2)
                        ^^^^^^^^^^^^^^^^^^^^^
                                || 
           filter1[2].cr == filter1[2].cr[1] == filter1.cr[2][1]

I know it might be a bit confusing to have code for filter1[1].cr[1] in two ways

filter1$lb$1$rb$cr$lb1$rb
$filter1$cr_index(1,1)

but th second one involves offsetting and is affected by alias elimination issues. So we can't use it everywhere. We use it only when we have to. That is when we have variable indices like $filter1$cr_index(i,j) and when we have cases like the array gen above where filter1[1].cr is not generated by the back-end (this can be changed if necessary).

Anyways this specific one is an issue in code generator. Template equationArrayCallAssign is generating plain crefs without using the daeExpCrefRhs template. And can't use it right now because SES_ARRAY_CALL_ASSIGN has no type info for the lhs.

Will fix it.

[Mahder Alemseged Gebremedhin]

Fixed in r24924 with a workaround. Broke back it with r24930.
Properly fixed now in r24947.

[Dietmar Winkler]

It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.

[Martin Sjölund]

Removing the pre1.9.4 milestone in favor of 1.9.4.