Ok, the solution is quite straightforward, except for a detail that I'm not actually understanding.

The CSV should be formatted with a one-row header containing the name of the input variables, but preceded by the 'time' variable.

time, u1, u2,

0.0, 0.1, 37,

0.1, 0.2, 49,

...

The fact is that it seems that the comma at the end of each line is mandatory. So do not forget about it, otherwise the last column seems to be discarded.


Adding LOG_SIMULATION to simulation flags, one can see how inputs are intepreted.
The log output is like this:

Input: t=0.000000       u1(t)= 0.250000         u2(t)= 0.050000         u3(t)= 0.350000         u4(t)= 2.000000         u5(t)= 0.000000         u6(t)= 449.992500

Looking at the <modelname>_init.xml file, one can see that each input has a particular property called inputIndex. This index is zero-based.
However, if we convert the indexes to one-based, one can observe that the variable with inputIndex=0 refers to u1, inputIndex=1 refers to u2, and so on...
Here everything seems to work fine.

However, when Integer variables are included as input I assist to strange behaviours. Even though the LOG_SIMULATION states that the i-th variable has been set correctly, the result file shows that the Integer value has different values compared to those that has been promised by the log file and the successive input has the value that should have had the Integer instead!
E.g. the Integer variable myInteger has inputIndex=3 and should be set to 2, the log says that u4 has been actually set to 2, nevertheless the results says that myInteger equals 1, while the variable with inputIndex=4 has been set to 2.

Hello,

I have also a question to the flag "csvInput". Is it possible to load the input as constant segments via the csvInput flag (like it is possible in combitimetable)?

Best regards,
Lukas