Check out the User's Guide on FMI Export. There is an example explaining how to export an Co-Simulation FMU with CVODE using the scripting API.

Basically you need to use the compiler flag

--fmiFlags=s:cvode

In OMEdit you can activate this by adding the translation flag in "Tools->Options", then navigate to "Simulation" and add "--fmiFlags=s:cvode" in the text field of "Additional Translation Flags".

Thanks for the reply, i've tried it and it seems to worked. there are now sundials directory inside .\sources, cvode_solver.c was added to .\soruces\simulation\solver and new .json file in .\resouces. But on the init_fmu_c the solver mowthod is still defined as dassl. I will try if this work for my use case, since the FMU will be compiled from the source code by the tool to create real-time app for HiL test.

Another question, why is the fmu flag has to be set globally? it seems the like the export function does not look into model translation flag. I've mention it regarding the missing fmu attributes that also define in translation flag.

Arinomo23 wrote:

But on the init_fmu_c the solver mowthod is still defined as dassl. I will try if this work for my use case, since the FMU will be compiled from the source code by the tool to create real-time app for HiL test.

Of course in the importing tool you need to use CoSimualtion. OpenMoelica FMUs usually offer CS and ME.
You can verify that everything is running correctly by running the FMU you created with OMSimulator.

The output of the FMU should look something like for this random example:

OMSimulator QuarterCarModel.QuarterCarModel.fmu --mode=cs

LOG_SOLVER        | info    | CVODE linear multistep method CV_BDF

LOG_SOLVER        | info    | CVODE maximum integration order CV_ITER_NEWTON

LOG_SOLVER        | info    | CVODE use equidistant time grid YES

LOG_SOLVER        | info    | CVODE Using relative error tolerance 1.000000e-06

LOG_SOLVER        | info    | CVODE Using dense internal linear solver SUNLinSol_Dense.

LOG_SOLVER        | info    | CVODE Use internal dense numeric jacobian method.

LOG_SOLVER        | info    | CVODE uses internal root finding method NO

LOG_SOLVER        | info    | CVODE maximum absolut step size 0

LOG_SOLVER        | info    | CVODE initial step size is set automatically

LOG_SOLVER        | info    | CVODE maximum integration order 5

LOG_SOLVER        | info    | CVODE maximum number of nonlinear convergence failures permitted during one step 10

LOG_SOLVER        | info    | CVODE BDF stability limit detection algorithm OFF

info:    Result file: model_res.mat (bufferSize=10)

Arinomo23 wrote:

Another question, why is the fmu flag has to be set globally? it seems the like the export function does not look into model translation flag. I've mention it regarding the missing fmu attributes that also define in translation flag.

Yes that is not perfect. When implementing CVODE FMUs I only did it for the compiler via the scripting API, so it is not fully integrated in OMEdit yet.
I opened a ticket about this: https://github.com/OpenModelica/OpenMod … ssues/7920
Also note that the other

I've tested the FMU for my use case, but it didn't go smoothly yet. Here are some points i've found during my test

Background:
the exported FMU from OM will be implemented in dSPACE real-time simulation. For this, dSPACE software will take the extracted fmu and compile it to rt-application according to the content of sources directory and modelDescription.xml

So the compile proccess is still un-successful and can be break down into four problems.

1) the included header file fpr cvode use angle-bracket <> and assumes the neccesarry files are in the standard seach path. I manually changed to search on relative path "" and it does the trick solving missing file error

2) the IDA and KINSOL directory were not included in "./resources/sundials" directory inside the FMU. I manually unpacked, add and repack the fmu and it seems does the trick.

3) in the sundial_error.h the header file omc_config.h is included if OMC_FMI_RUNTIME is not define (line 44-45). The omc_config.h file it self does not included in the FMU. I try to set the macro when building the rt-application and the missing file error is gone. --> so the question is, should i or should i not defiine the macro?

4)the rt-app compiler throw errrors for sundial_xxx.h files with following error

error: expected declaration specifiers before '__declspec' #define SUNDIALS_EXPORT __declspec(dllimport)

and it seems to come from sundial_config.h (line 153) for this i haven't found any workaround. --> for this i wil try to export the fmu with Platforms setting set to Static (previously was None) but i'm nut sure, since dSPACE doesn't seems to look inside the binary folder of the FMU

Edit:
on point #4 it seems declaring LINK_SUNDIAL_STATIC eliminate the errors mention above. but building the rt-app still unsuccessful.

Source-Code FMUs with SUNDIALS are a nightmare to get to run on different OS and what and how to include into the FMU are not obvious.
I would suggest you create a new issue on GitHub and cc me in it (AnHeuermann). Then we can work on it there.

If possible we can improve OpenModelica to generate CVODE FMUs that are usable out of the box.