Hi Philgun,
I saw your PM.

as adrpo said, we have to see your Modelica code that call the C function, especially the annotation, otherwise very little can be said.
Also please check the section 12.9.4 Annotations for External Libraries and Include Files of Modelica Specifications Modelica Documents.
You will find useful hints.

Oh stupid me.
Really sorry.

I have been misleaded by the strange shape at the peak. However, it's just an artifact that comes from the quickly changing function that deceives the derivative evaluation.

Thanks a lot

The derivative that any CombiTable is providing is far from being accurate.
Even by imposing a Continuous Derivative, the output is the following.

Any issue that I made?

Here the image (the OpenModelica Forum Attachment is broken)
https://ibb.co/HFXkj4w

Ther getErrorString(); command should do what you want.
Please mind that the string that you get from this command refers to the last command you gave, thus it has to be run right after the translateModel command.


This works for sure

  simRes := translateModel(myModelTypeName);

  simulateMsg := getErrorString();

  print(simulateMsg); getErrorString();

you might also want to try

simRes := translateModel(myModelTypeName);

  errors:=getMessagesStringInternal();

  

  print("getMessagesStringInternal() returned \n"); getErrorString();

  print("Errors size is "+String(size(errors,1))); getErrorString();

  for err_sel in 1:size(errors,1) loop

    curErr := errors[err_sel];

    curErrMess := curErr.message;

    print(curErrMess); getErrorString();

  end for;

You can get myModelTypeName with searchClassNames(myModelName)

Incredibly I tried with password "modelica" and it worked.
Great subconscious memory 

I built a MOS script for testing some models of my library.

However, I incurred in a very annoying issue: I can't find a way to:
- test if the model failed during translation or during simulation
- report timing of translation/simulation

I tried to use simulate() and then look at SimulationResult, however some variables in the SimulationResult record are not there when something goes wrong.
E.g timeTotal does not exist when simulation fails; then, if I try to read it, my MOS script ends prematurely;

I opened a ticket on the Modelica Bug Tracker: issue #5755

Many thanks!
Really valuable information!

Hi again,
I'm struggling finding a way to selectively print outputs to console while I'm running MOS scripts.
Either I leave echo(true), thus echoing any statement even if terminated by semicolon, or I completely block any output to console.

I tried printf and Modelica.Utilities.Streams.print, but none of them seem to allow writing to command prompt even though the latter does work for outputting to file.

Any idea is greatly appreciated!

Ok, I'm really sorry; I was wrestling with this issue since this morning but I realized I incurred in some kind of sub-issue;

Loops do work, but they do not output strings to the command prompt, that it was what I was using to check it.
I'm incurring in some other kind of issue, but it might be that it is again my fault.

Hi,
I see everywhere that OpenModelica MOS scripts use for-loops in this way
e.g.

s:={j for j in 1:3};

But it seems that a more general notation like this below is not supported

for j in 1:3 loop

  XXXX

end for:

Now, the problem is: how can I loop over multiple commands in a MOS script?
Is there a way to do it? Am I missing something?

Is this still true in v1.14 then?
Are there plans to include this really useful feature?

I would suggest to NOT follow this way...
Tweaking the source code generated by OpenModelica:
- could be quite a pain in the ass
- if you have problem with linking, it's quite probable you are going to mess up things more;
- you may not know some reasons why OpenModelica programmers did what they did

I will definitely go with explicit dynamic linking, that I can assure it does work.

By the way, here you can find my previous answer on how to link explicitely to FMUs.

Are just hints, not a full working file, but this is something to start from.

Hi Aronimo23,
I jump here from the other post... I'm not used to RT.machines, but can you share your makefile/command line?
I think that something big is missing.

Wait, for the DLL I only have no-prefixed functions; while in the LIB (import library) I DO have prefixes! You are saying exactly the opposite! Please check your statement!

The reason why you do not have prefixes

The FMI2_FUNCTION_PREFIX should be a preprocessor definition that is in charge of prefixing all the functions of the fmi in order to avoid name clashes.

In the fmi headers (specifically in fmi2Functions.h) as well as in the FMU reference you will find the following statement

   In order to have unique function names even if several FMUs
   are compiled together (e.g. for embedded systems), every "real" function name
   is constructed by prepending the function name by "FMI2_FUNCTION_PREFIX".
   Therefore, the typical usage is:

      #define FMI2_FUNCTION_PREFIX MyModel_
      #include "fmi2Functions.h"

Well, there are no defines for FMI2_FUNCTION_PREFIX anywhere in the source code or in makefiles, so I don't know how the import LIB library has that symbols.

   As a result, a function that is defined as "fmi2GetDerivatives" in this header file,
   is actually getting the name "MyModel_fmi2GetDerivatives".

   This only holds if the FMU is shipped in C source code, or is compiled in a
   static link library. For FMUs compiled in a DLL/sharedObject, the "actual" function
   names are used and "FMI2_FUNCTION_PREFIX" must not be defined.

Thus, it seems that for DLL/sharedObjects it is ok to NOT provide any prefix (however, I don't understand why in the import library - the one with LIB extension in the binary folder - there ARE symbols with that prefix though).
So, is it possible to implicitly link to such DLLs if the import library LIB has different symbols? Is there a redirection so that the DLL library can be used even if it has different symbols?
What if there are multiple FMUs: will their symbol clash?

This is still something not clear to me.

Well, it depends on which compiler you are using and the platform as well, but in general, if you have shared libraries (DLL in Win, SO in Linux) you have to decide which kind of linking you want. In Win the two type of shared library linking are called implicit and explicit.
Here is a good starting point (even if it is a little overwhelming...) Link an executable to a DLL.


You HAVE to link explicitely i.e. link during execution. Do not use implicit linking.
Ther reasons why you HAVE TO do explicit linking are described in my first post above here, but if you are not used to concepts such as import libraries, linking, etc... you will probably get lost.

However, this implies quite a big work on your side (you have to use LoadLibrary, GetProcAddress and so on...).

If some of the developers will reply I can be more sure than other linking options does not exist, but since there are no answers from them, I just rely on my observations.
Hope I am right!

Hi,
first of all: are you sure that your program is actually linking the FMU? Did you put the correct linking options in the linker command line?
If so, here is the workaround.

Once the FMU is generated, unzip the FMU with a zip manager, go to sources, open Makefile with a text editor, you fill find the variable CPPFLAGS;
to this variable add

-Wl,--output-def=<modelname>.def

Once you have done this, save the file, open your MinGW command prompt and navigate to the sources folder and run make.
You will find your updated libraries in the binaries folder.

Now: you may want to use your own MinGW/MSYS compiler or the one included in OpenModelica: in this latter case you may hit some problems, but you will found workarounds on the web.

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.

Hi,
how the CSV input file that is loaded with -cvsInput should be formatted in order to properly pass the values to the model inputs?
How -csvInput differs from -exInputFile?

I cannot find answers in the documentation and looking at the GitHub source code I'm not sure how the i-th index is picked

data->simulationInfo->inputVars[i] = u1;

Thanks

Hi zb2865493,
yes, I solved the problem, but now my configuration is a bit more complex than this.
I make run-time linking of the DLL that requires some more steps...

SetDllDirectory(<directory to dll>);

HINSTANCE myGetProcIDDLL = LoadLibrary(<path to dll>);

and for any fmi function you are interested in...

fmi2InstantiateTYPE* _fmi2Instantiate = (fmi2InstantiateTYPE*)GetProcAddress(myGetProcIDDLL, "fmi2Instantiate");

fmi2DoStepTYPE* _fmi2DoStep = (fmi2DoStepTYPE*)GetProcAddress(myGetProcIDDLL, "fmi2DoStep");

build your own logger...

void mylogger(fmi2ComponentEnvironment c, fmi2String instanceName, fmi2Status status, fmi2String category, fmi2String message, ...)

{

    ...

}



typedef struct {

    fmi2CallbackLogger         logger;

    fmi2CallbackAllocateMemory allocateMemory;

    fmi2CallbackFreeMemory     freeMemory;

    fmi2StepFinished           stepFinished;

    fmi2ComponentEnvironment   componentEnvironment;

} fmi2_callback_functions_t_aux;



fmi2_callback_functions_t_aux mycallbacks;

mycallbacks.logger = mylogger;

mycallbacks.allocateMemory = calloc;

mycallbacks.freeMemory = free;

mycallbacks.stepFinished = NULL;

mycallbacks.componentEnvironment = NULL;



fmi2Component component = _fmi2Instantiate(

            "mytool",

            fmi2CoSimulation,

            <guid name>,

            <path to resource folder>,

            (const fmi2CallbackFunctions*)&mycallbacks,

            fmi2False,

            fmi2True);

I'm sorry but I cannot share with you a compilable snippet...

Hi guys,
I have modified the code in order to work smoothly in Matlab R2018b.
There are two main differences:
- the output is not into the workspace, but into a structure
- arrays keep their shape, i.e. force[3] will be an array and will not be split into force_1, force_2, force_3 as before

Here is the attachment:
omimport.m

Man, I'm not an expert, but I think you are missing some basic concepts.

The Include statement inside your annotation regarding the external function is not intended for including compiled objects, but source files.
If you have compiled your code you should add it to the Library part.

Moreover, I can't see any header file. I'm not sure, but I think it's mandatory.

So, you can choose to do eiterh:
1. create a test1.h and test1.cpp, provide them to Modelica, both they should go in the Include statement (but Cpp is not fully supported, so I do not suggest this way)
2. create a test1.h and test1.cpp, compile them into a library (.so/.a) then provide Library={"test1","otherdependecies"} and Include="\"#include \"test1.h\"";

Hope to be of any help, but please do not refer to me as an expert; I may have said something wrong...

Please refer to this issue: https://github.com/modelica/VehicleInterfaces/issues/18

The problem is:

model myModel
  inner Road road;
end myModel;

model Road
VisualizeSimpleRoads simpleShape;
end road;

model VisualizeSimpleRoads
outer Road road;
end VisualizeSimpleRoads;

Is this possible?
I cannot find any clear statement into the Modelica Specifications.

In Dymola it seems that this can work!

Since this should be a static text, why don't you put a static name close to the connector?

Like the one in the attachment

Please refer to OpenModelica User's Guide at the section Simulation Parameter Sweep.

This is exactly your case

Modelling a variable as 'input' or 'output' comes with the fact that the "signal" is directional.
Clearly a variable cannot be seen as both: otherwise simply it is not neither a input or output and it makes no sense to flag it as an input or output.

Why would you actually need to flag these variables as input AND output?
I think it's more a modelling error rather than else...

One of the most common problems is that one would create a connector and it gets stuck when it finds out that you have to have the same number of flow and state variables: well, if this is your case, you have to look at the Modelica library to have your answer. Modelica.Blocks.Interfaces is a perfect example.

As you can see there are plenty of XXXInput and XXXOuput: yes, you have to provide two different components. One for Input and one for Output.

But I'm just inferring, I don't know your application.

I'd like to model an ideal clutch, as this user already tried to do here
http://www.modelica-forum.com/forums/in … &p=289

The clutch should connect two flanges when locked, and let the flanges spin freely when not.
The core concept is this

  if pre(locked) then

    der(flange_a.phi) = der(flange_b.phi);

    flange_a.tau + flange_b.tau = 0;

  else

    flange_a.tau = 0;

    flange_b.tau = 0;

  end if;

but this always give me the following error:
division by zero at time 0, (a=-3.5) / (b=0), where divisor b expression is: if $PRE.clutchDiscrete1.locked then 0.0 else -1.0

I tried with many different scenarios, but I always get this error.
I attach the demo code
IdealClutch.mo

Please: any advice will be greatly appreciated

Connectors (like your "pipe") must have the same number of flow and state variables.
It would more or less work if you put also
flow Real q[Species]
that makes sense since, probably, there is a flow of each specific Species

Moreover, you must not extends Definitions in Pipe. You can use the type "Species" simply referring to it. Right?

Wops, I mispelled the name of the function.
Although many other conversion function start with Capital letter (String(enum), Integer(enum), etc...), the one that translates from Integer to Real is
integer(Real num)
instead of
Integer(Real num)

You can find all the detailed infos here: Modelica Specifications
in particular at section 12.9.4 Annotations for External Libraries and Include Files.

I attach a brief example (using MultiBody library). I hope it can be of some help.
ExternalCode.zip


BTW, do you actually have the Resource folder that OpenModelica is looking for? The one that you can see in your screenshot of the message panel?

Always the same error "Wrong type or wrong number of arguments to Integer(vector[i])."

I just want to compare the elements of a Real vector (e.g. [-1, 0, 1, 4]) to an Integer.
But I cannot convert the element of the vector to an Integer! I would avoid to compare Reals!

My code is simple as the following:

function findElement

    extends Modelica.Icons.Function;

    input Integer e "Search for e2";

    input Real[:] vector "Vector to search";

    output Integer result;

  algorithm

    result := 0;

    for i in 1:size(vector,1) loop

      if Integer(vector[i]) == e then

        result := i;

        break;

      end if;

    end for;

  end findElement;

The MultiBodyEnd component add zero force and torque to a FlangeWithBearing component.
But why is this needed? Everything seems to work fine even without MultiBodyEnd .

Moreover, when we connect frames or flanges it's automatically true that this connectors does not add any force or torque.
They simply say:
sum(f) = 0; (flow variable)
r_0 is equal for all connected objects (potential variable)
Thus, why FlangeWithBearing (that is still a connector) may behave differently? isn't it a simple merge of a frame and a flange?
Why we need to stress that it is not adding any force and/or torque?

The Modelica.Mechanics.MultiBody.Visualizers.Torus, as well as any other object that uses the Modelica.Mechanics.MultiBody.Visualizers.Advanced.SurfaceCharacteristics.torus, cannot be displayed.

It is the case also for the VoluminousWheel that actually displays only the pipe shape.

Any solution?

In order to build more complex models, I need to understand why a so simple project is failing because of equations>variables.

It's a simple free-falling object that is fixed in two different ways: the first using MultiBody "Fixed", the second one by manually fixing a frame, using the exact same equations.
The only difference is where the equations reside.

First script:

model freefalling



  inner Modelica.Mechanics.MultiBody.World world(enableAnimation = false, n = {0, 0, -1});

  Modelica.Mechanics.MultiBody.Parts.Body body1(m = 10, r_CM = {0, 0, 0}) ;

  Modelica.Mechanics.MultiBody.Parts.Fixed fixed1;



equation

  connect(fixed1.frame_b, body1.frame_a);

  

  annotation(

    uses(Modelica(version = "3.2.2")));



end freefalling;

The second

model freefalling2

  

  inner Modelica.Mechanics.MultiBody.World world(enableAnimation = false, n = {0, 0, -1});

  Modelica.Mechanics.MultiBody.Parts.Body body1;

  Modelica.Mechanics.MultiBody.Interfaces.Frame_b frame_b;

  

equation

  connect(frame_b, body1.frame_a);

  

  Connections.root(frame_b.R);

  frame_b.r_0 = zeros(3);

  frame_b.R = Modelica.Mechanics.MultiBody.Frames.nullRotation();

  

  annotation(

    uses(Modelica(version = "3.2.2")));



end freefalling2;

In the second script I just replicated the same equations as script 1: however, at the end there are 6 more equations! Namely

frame_b.t[...] =0

frame_b.f[...] =0

that I didn't actually write and I don't know where they come from.

Why that happens? What am I doing wrong?

Well, if things are working as they should, you just have to set the PATH environmental variable accordingly, so that it includes the path to the gcc*.

If you are on Linux something like this
https://stackoverflow.com/questions/146 … linux-unix

if you are on windows just go to My PC > Properties > Advanced System Settings > Environmental Variables...

However, looking for a path that ends with *cc seems to suggest that GCC compilers are the only choice*...

I haven't got any real answer here, but I can say that, using command line, you have few more settings.
As I wrote in the previous post you can format a .mos file that launches your FMU translation:

DarioMangoni wrote:

Code:

loadModel(Modelica);
loadFile("model.mo");
loadFile("model_dependency.mo");
buildModelFMU(model, version="2.0", fmuType="cs", platforms={"dynamic"}, includeResources=true);
getErrorString()

where in platforms={"dynamic"} you are actually implying "build a dynamic library for the current platform".

However, the OpenModelica User Guide says that you have multiple choices
The list of platforms to generate code for:
"dynamic"=current platform, dynamically link the runtime.
"static"=current platform, statically link everything.
Else, use a host triple, e.g. "x86_64-linux-gnu" or "x86_64-w64-mingw32".

I don't know if this can be of any help.
BTW, I'm not sure that they actually work 
For me it does not work the simple "static" option either.

Does anyone have a working example of a C code that calls an FMU library for cosimulation?

I tried to follow the Pseudo-code example that we can find in the FMI standard documentation  (BTW, I do not really understand why, in a manual, you do not write a REAL code, but a pseudo one, that gives space to a lot of misunderstanding, just for saving a bunch of pages... damn)

I successfully call fmi2GetVersion, but I'm hitting exceptions when I call fmi2Instantiate. I'm sure that I'm wrongly initializing some variable, but I do not have any clue on how to do the right thing.

Moreover, from OpenModelica I do not have any resource folder: it has not been generated at the time I called build/translateModelFMU as I already said here.

The code below is linked to binaries/win64/model.lib
and I have binaries/win64 in my path, so the binaries/win64/model.dll is reached.

In the attachments there is a CMake minimal example from which I'm calling the FMU generated library.

I really appreciate any help.

Dario

#include "fmi2/fmi2Functions.h"

#include "fmi2/fmi2FunctionTypes.h"





int main(int argc, char* argv[])

{

    //Set callback functions    

    fmi2CallbackAllocateMemory allocateMemory = calloc;

    fmi2CallbackFreeMemory     freeMemory = free;

    fmi2StepFinished           stepFinished = NULL;

    fmi2ComponentEnvironment   componentEnvironment = NULL;

    fmi2Status                 loggerStatus = fmi2OK;

    fmi2CallbackLogger         logger = (componentEnvironment, "fullvehicle3D_Pacejka", loggerStatus, "category", "message");



    fmi2CallbackFunctions cbf = { logger, allocateMemory, freeMemory, stepFinished, componentEnvironment };



    const char* ver = fmi2GetVersion(); // it works!



    fmi2Component mycomp = fmi2Instantiate(

        "test",

        fmi2CoSimulation,

        "21491c75-15e3-4b05-903a-d801733579d9", // my guid

        "path", // dummy, because I do not have any resource folder...

        &cbf,

        fmi2True,

        fmi2False);



    return 0;

}

test-run-importlibrary.zip

pthread is the POSIX threads library for handling threads that is typical of Unix-like systems.
I'm not a big expert, but you hit something like this it means that the code is not well suited to run in a Win environment.

I was trying to compile myself the code with VS2017 (is VS2018 around yet? wow) but I did not hit this problem.
Look here to see my tentatives

Some questions:
1- are you trying to recompile the FMU sources (those coming from running the script with the buildModelFMU command)
OR
2- are you trying to compile the sources that comes out from omc +s <modelname>.mo

If you are trying to do (1) be aware that those source files SEEMS TO be generated by buildModelFMU in order to be compiled with make, so Unix-like systems. They cannot be compiled with MSVC without heavy modifications. In fact, in buildModelFMU you cannot tell for which compiler you want the source files* for. Having hit pthread may confirm this.

If you are trying to do (2) you can us something like this

%OPENMODELICAHOME%bin\omc +s +simCodeTarget=Cpp +target=msvc15 <modelname>.mo <modeldependecies.mo...>

but I anticipate that you will get a lot of errors (they vary depending if you set simCodeTarget=C or simCodeTarget=Cpp) unless you compile with Build Tools bundled in VS2013 (yes, because some boost related stuff has been compile with an older compiler that is not compatible with the new ones, I think)

I tried also

omc +target=msvc15 build_model.mos

but I got errors

fullvehicle3D_Pacejka_FMU.makefile(5) : fatal error U1052: file '$(RUNTIMEDIR)/Makefile.objs' not found
Stop.
RESULT: 2

but maybe something can be done...

Solution found, I hope.

Inside the unzipped FMU folder, under binaries/win64 a wrong import library was created.

That is probably because of the missing flag that outputs the .def file required (as you may see in the sources/Makefile) by dlltool during the generation of the binaries.

I solved adding to the CPPFLAGS the corresponding flag -Wl,--output-def=<modelname>.def

Now things are working fine.
I opened a ticket: issue 4707

We are going to discover if the problem is real and the solution is right

Even if the behaviour of buildModelFMU and translateModelFMU is quite unexpected, as I mentioned here, I'm trying to use their output with my C code.

buildModelFMU (and translateModelFMU) gives these relevant files (suppose to have model.mo as main model file)
- binaries/win64/model.dll <-- the shared library
- binaries/win64/model.lib <-- the import library, I suppose
and the sources\include folder and subfolders.

Everything seems to work just fine, but the problems rise when I try to link such libraries:
the symbols of the import library DO NOT MATCH those of the shared library, resulting in a lot of linking errors like the following:
"unresolved external symbol fmi2Instantiate ..."
That's because the symbols defined the DLL (as dumpbin reports) and in the include/fmi2 header files (such as fmi2Instantiate), cannot be found in the relative import library or in any header file either.

In the DLL, there are symbols like:
...
fmi2Instantiate
fmi2SetReal
fmi2DoStep
...
and they should be correct, as indicated by the FMIstandards. They are not preceded by "<modelname>_" since they are in a shared library (as specified at the bottom of page 14 of the FMI standard v2.0).

However in the LIB, the symbols are like:
...
<modelname>_fmiInstantiate
<modelname>_fmiSetReal
<modelname>_fmiDoStep
...
like it was a real static library, not an import library and in any case I do not have any header with these declarations!.
And moreover, also if that was a real static library, the naming is wrong/old: from April 9th 2014, it should be at most <modelname>_fmi2Instantiate, with the '2'!
And also, the library file size (39KB) clearly indicates that it is not a static library!

Can anyone clarify the situation here?
How can I link to these FMU libraries? Is a run-time dynamic linking required?

Using OpenModelica Compiler v1.13.0-dev-335-gfe5c35d (64-bit)

buildModelFMU and translateModelFMU are completely insensitive to the argument includeResources and platforms

Both
buildModelFMU(<modelname>, version="2.0", fmuType="cs", platforms={"static"}, includeResources=true)
and
buildModelFMU(<modelname>, version="2.0", fmuType="cs", platforms={"dynamic"}, includeResources=false)
and
translateModelFMU(<modelname>, version="2.0", fmuType="cs", includeResources=true)
and
translateModelFMU(<modelname>, version="2.0", fmuType="cs", includeResources=false)

produce exactly the same results.
And I do not see any resources folder in the FMU zipped directory.

Am I missing something?
And BTW, which is the difference between "translateModelFMU" and "buildModelFMU" (except that buildModelFMU has an additional parameter)? The output are the same!

Using OpenModelica Compiler v1.13.0-dev-335-gfe5c35d (64-bit)

Never used OMPython, but did you try to compile the FMU from command line?
in %OPENMODELICAHOME%\bin you should have the omc compiler;
you should try to build your FMU this way:

suppose that your file is model.mo and that depends on model_dependency.mo and on the Modelica library, then you should create a build_model.mos that contains the following text

loadModel(Modelica);
loadFile("model.mo");
loadFile("modelica_dependency.mo");
buildModelFMU(model, version="2.0", fmuType="cs");
getErrorString()

and then run omc build_model.mos

in this way you should be able to produce a working FMU build.

I am just a newbie, but here what I see: simply compiling with omc e.g.

omc +s model.mo

produces unreadable code.
If you translate into FMU, this it may be helpful: you should run

omc build_model.mos

where build_model.mos
should load each dependency like this:

loadModel(Modelica);

loadFile("model.mo");

loadFile("model_dependency.mo");

buildModelFMU(model, version="2.0", fmuType="cs", platforms={"dynamic"}, includeResources=true);

getErrorString()

Here you will find an output: if you unzip model.fmu like it was a zip file (actually it is), you will find more useful sources and binaries.

These are my 2cents

Even though the gcc build runs fine, I'd like to know how to build with MSVC.
I have both the Platform Toolsets from:
- VS2015 | MSVC 14.0 | _MSC_VER == 1900
- VS2017 | MSVC 14.1 | _MSC_VER == 1910

Looking at C:\OpenModelica\share\omc\scripts\Compile.bat, it seems that VS2015 should be supported.
So
- I set up the environment in order to build with MSVC
- I compiled with omc with --target=msvc15 (that is quite misleading because it should be VS2015 or MSVC140, never mind...)
- I tried both with +simCodeTarget=Cpp and +simCodeTarget=C
- I compiled with nmake

and here are the results:
i) with +simCodeTarget=Cpp I get

fatal error C1853: 'C:/OpenModelica//include/omc/cpp/Core/Modelica.pch' precompiled header file is from a previous version of the compiler, or the precompiled header is C++ and you are using it from C (or vice versa)

ii) with +simCodeTarget=C I get a long list of

error C2732: linkage specification contradicts earlier specification

that, by the way occur in the declaration of extern "c" functions

iii) with +simCodeTarget=C and forcing to not use the precompiled header (putting a PCH_FILE=<nothing> in the makefile)I get

Severity    Code    Description    Project    File    Line    Suppression State

Error LNK2038 mismatch detected for '_MSC_VER': value '1900' doesn't match value '1800' in simulation.lib(simulation_runtime.cpp.obj)

so it seems that the simulation.lib library has been compiled with a _MSC_VER == 1800 i.e. VS2013 i.e. MSVC12.0 so it is not usable with other MSVC versions.

Is there any solution?
Does anyone successfully tried to build with MSVC?

Hi JPS,
If you would like to check errors during model flattening you should just run

omc test.mo Modelica

this allows test.mo to use|link any module defined in Modelica libraries.

If there are other dependencies you can just append other files

omc test.mo Modelica test_library.mo

again the main file is the first one i.e. test.mo

This way all the dependencies are fixed: any error that comes from the compilation now regards only your errors (too many equations/variables,etc...).