The NF should completely eliminate Evaluate = true parameters from flat model

[Francesco Casella]

@perost, please check out the FEMBody package from ​https://github.com/looms-polimi/FEMPackage. I sent you an invitation to access the repo, if it is expired when you check this, I can send you a new one. The library will eventually be made open source, but still needs some clean-up.

Please open the FemPackage3.2.mo file and flatten the model ExamplesFEM.PendulumBody.

The FEMBody model which is instantiated in this example contains code such as

  transpose(Cr) = data.inv4 + sum(data.inv5[i, :, :] * q[i] for i in 1:M);
  Jbar = data.inv7 - sum((transpose(data.inv8[i, :, :]) + data.inv8[i, :, :]) * q[i] for i in 1:M) - sum(sum(data.inv9[i, j, :, :] * q[j] for j in i:M) * q[i] for i in 1:M);
  [mDcbartilde, Jbar, transpose(Cr)] * [aa_a - g_0; za_a; ddq] = h_w_theta + h_e_theta;
  [data.Ct, Cr, Me] * [aa_a - g_0; za_a; ddq] = h_w_f + h_e_f - matrix(data.Ke * q) - matrix(d / 100 * (alpha * Me + beta * data.Ke) * dq);

which comes straight from tensor equations describing the multibody FEM model of a flexible link, see ​paper.

The parameter record data contains multi-dimensional arrays (tensors) of structural parameters of the flexible body, which come from modal analysis of the original FEM model. Most of the elements of those arrays are zero, so for efficient and robust handling of the model equations by the backend it is absolutely essential that:

• all the elements of the data record are evaluated (see also #6067)
• all matrix operators and reduction operators are evaluated, and all product-by-zero terms are eliminated

Adding the Evaluate = true annotation to each individual component of the FEMData.PendulumData record improved the situation significantly, drastically reducing the size of many equations and making it possible to actually simulate this test case and produce the correct results. However, there is still a lot of non-evaluated stuff in the flat model that looks pretty nasty, and in fact more involved models using flexible bodies with larger numbers of FEM modes and nodes take forever to compile and fail miserably at runtime, producing completely wrong results. I am convinced that this would not be the case if everything was properly evaluated by the frontend.

Getting this model to work in OMC may have strategic value to get a new big partner (possibly more than one) into the OSMC, so I would please ask you to assess how much work fixing this issue could take and report it here. Then we can decide what to do.

[Martin Sjölund]

Evaluate = true is handled in the backend because the parameters could be defined in equations that need to be sorted before the frontend could determine which equation should even be used to evaluate the parameter, right?

If this is just proposing to evaluate parameters with bindings it should be feasible.

[Francesco Casella]

Replying to sjoelund.se:

Evaluate = true is handled in the backend because the parameters could be defined in equations that need to be sorted before the frontend could determine which equation should even be used to evaluate the parameter, right?

If this is just proposing to evaluate parameters with bindings it should be feasible.

I understand that is what the NF currently does, i.e. it marks parameters with binding equations and Evaluate = true annotation as structural, and hence evaluates them during flattening.

[Francesco Casella]

After #6067 was fixed, there are no more parameter references in the flat code. The remaining issue is with reductions, I opened #6089 on that topic