New Cpp FMI getters and setters

[Rüdiger Franke]

SVN r25337 introduces new getters and setters for FMUs. For now they have been put into the new class <model>FMU in OMCpp<model>FMU.cpp, leaving existing base classes untouched. It is attempted to speed up the functions and detect index errors by basing them on value references and switch statements, respectively.

The question is if anyone needs the previous get/set Real/Integer/Boolean/String in the base class <model> in OMCpp<model>.cpp. Considering a couple of issues (r25222, r25227, r25279) -- mostly addressing models with alias variables and with non-real variables, the previous getters and setters can hardly be used anywhere. They are used in the copy constructor -- but the variables don't need to be enumerated explicitly for this use.

Should the previous getters and setters be removed?

[Marcus Walther]

You are right, the getters and setters are currently only used inside the copy constructor and the copy constructor is only used experimentally in HPCOM.

There is one problem with your code:
If you have a larger number of variables, then the compiler (e.g. gcc) has to handle a getter-function or setter-function that contains thousands of lines. This takes horrible long and can lead to a termination of the compilation process. So you will not be able to compile really large models. We already had this problem with one of our models, that's why we have added these split-functions, that will create a getter and setter method for each block of 100 variables. Of course our solution will not completely remove the problem, but we can handle models with 100 times more variables than before.

A question from my side: Is it important that the interface has C-style ...(const unsigned int vr[], int nvr,...)? Or can we use a std::vector instead to use the power of c++?

[Rüdiger Franke]

There are three motivations for the C-style interfaces:

1. The previously existing interfaces were C-style as well -- like getReal(double *)
2. FMI calls can directly be forwarded (except for strings)
3. std::vector cppvec can easily be converted to C-style with &cppvec[0] as std::vector guarantees contiguous storage -- btw. getBoolean uses int value[], not bool value[], because std::vector<bool> has a fuzzy definition, permitting, but not requiring to pack each element into one bit and possibly letting operator[] return a temporary bool variable.

C-style vectors are needed whenever interfacing with software outside the Cpp world, being it the FMI C calling interface or some numerical FORTRAN code. This is why I thought that C-style interfaces make sense for the getters and setters.

I will investigate the use of a split-function.

[Marcus Walther]

Thank you for the description, it was not clear to me if the getters and setters are directly accessible from outside or if there is some complex wrapper function necessary.

[Rüdiger Franke]

All accesses go through the FMI(2)Wrapper. Nevertheless the intention was to minimize the overhead.

Just some brainstorming: Conceptionally FMI works with sparse vectors. When thinking about conversion to C++, one should not just replace:

  void getReal(unsigned int vr[], int nvr, double value[])

with

  void getReal(std::vector<unsigned int> vr, std::vector<double> value)

but go one step further towards some:

  void getReal(SuitableSparseVector<double> value)

And then ideally let the implementation of SuitableSparseVector treat the access to the internal variables, overcoming any need for own work on switch statements or splitter-functions.

Is this thinkable?

[Marcus Walther]

So you just want to move your switch-case logic into this new SuitableSparseVector-class? Because there you still need the splitted getter and setter functions.

Maybe you should wait a little bit. Niklas is working on a commit that will store the member variables in large variable arrays, as it is in the C-runtime.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Rüdiger Franke]

This ticket was solved with the introduction of lumped vectors of simvars in 1.9.3. They are exploited for FMI 1 export since 1.9.3 and for FMI 2 export since 1.9.4, see 161ad391/OMCompiler.