run!(neuralFMU..) in batch.jl should also work for FMUs which are not able to get/set their state

[juguma]

This is a feature request. For FMUs which are not able to get/set their state, the proposed call sequence to batch the training (as in juliacon_2023.ipynb) does not work. The first instance where it fails is when calling batchDataSolution. Then one receives the warning that the respective FMU is not able to set/get the state. Later, the function run! tries to set this state anyway, and this leads to the crash of the program.

My proposal is to:

• keep the warning
• modify the function run!(neuralFMU::ME_NeuralFMU, batchElement::FMU2SolutionBatchElement; lastBatchElement=nothing, kwargs...) and batchDataSolution as follows:
• move the assert and warning (based on existence of fmi2CanGetSetState(neuralFMU.fmu) from batchDataSolution to run!,
• call all the functions to get and set a state only if fmi2CanGetSetState(neuralFMU.fmu) is true.

Due to IP I can't share an MWE here, but @ThummeTo, I can share one with you, and of course discuss.

[ThummeTo]

Yep, the next patch includes this because I need to train on such an FMU :-) Further, you can optionally pass a discrete state (this is not part of FMI, but sometimes you know it) to improve initialization of batch elements. If you know the continuous as well as the discrete state, you can initialize your FMU in the correct "FMU state" without having the fmiGet/SetState functions.

[juguma]

Yippieyayeah. I was just about to state a PR, but I guess you already have more modifications anyway, so I keep it locally. For now I just hope that the discrete states are fine or immediately settle in. If I face this problems with more complex FMUs (and we still haven't added Get and Set in our FMUs), I'll get back to you.