Opened 9 years ago

Closed 8 years ago

#3253 closed defect (fixed)

New Cpp FMI getters and setters

Reported by: rfranke Owned by: mwalther
Priority: high Milestone: 1.9.x
Component: Cpp Run-time Version: trunk
Keywords: Cc: mwalther, vwaurich, niklwors, mflehmig

Description

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?

Change History (11)

comment:1 Changed 9 years ago by adeas31

  • Component changed from FMI to FMI-CPP
  • Owner changed from adeas31 to mwalther

comment:2 Changed 9 years ago by mwalther

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++?

comment:3 Changed 9 years ago by mwalther

  • Cc mflehmig added

comment:4 Changed 9 years ago by rfranke

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.

comment:5 Changed 9 years ago by mwalther

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.

comment:6 Changed 9 years ago by rfranke

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?

comment:7 Changed 9 years ago by mwalther

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.

comment:8 Changed 9 years ago by sjoelund.se

  • Milestone changed from 1.9.3 to 1.9.4

Moved to new milestone 1.9.4

comment:9 Changed 8 years ago by sjoelund.se

  • Milestone changed from 1.9.4 to 1.9.5

Milestone pushed to 1.9.5

comment:10 Changed 8 years ago by sjoelund.se

  • Milestone changed from 1.9.5 to 1.10.0

Milestone renamed

comment:11 Changed 8 years ago by rfranke

  • Milestone changed from 1.10.0 to 1.9.x
  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.