Building with MSYS2/mingw-w64 on Windows about rosco

[rafmudaf]

Good point @davidheff. The DISCON project distributed in OpenFAST has a sample CMakeLists.txt that could be modified for this project. For what its worth, this is a great opportunity for community contribution as its a very well contained project.

I think CygWin and/or MinGW fall under the "UNIX" label in CMake, but someone should double check that.

[davidheff]

I'm very happy to contribute to this if I can, to make it easier for others to be able to build this on Windows. At the moment we are looking to build an example model for OrcaFlex so we'll end up giving this controller a good run out in that setting.

How could I help?

[nikhar-abbas]

@davidheff some contribution would be great!

The best course of action is to fork the repo and put in a pull request to the develop branch. Once you do that, we can take a look and incorporate your changes. I just fixed the make install bug on the develop branch as well. Once all of this gets sorted I will increment the version in the master branch.

One quick note on OrcaFlex coupling. We have a group internally who has recently worked through some of the hurdles to do this. The OrcaFlex distrubuted python function that comunicates with the compiled DISCON binary has some small issues that don't properly pass the name of the controller input file to the binary. The ROSCO toolbox has some functions (ControlInterface.py) to connect the DISCON binaries to python. You might want to take a look at that to help sort through any controller communications related bugs that may come up.

[davidheff]

Just to let you know that we have got this message, and we will get back this. We've just been a little distracted lately. Thanks for the encouragement to contribute. It would be great if we could arrange that the controller and OrcaFlex work smoothly together.

[RBergua]

Hi @davidheff and @nikhar-abbas. I was wondering if you came up with a final solution to compile the ROSCO controller in Windows. I tried to compile it using Cygwin64, but when I try to use the DLL in OpenFAST, it crashes:

I also tried to compile the control in Visual Studio, but I could not make it work either.

It would be great if we could have the controller DLL already compiled available as a release in this GitHub repo. So, the different users could just download and use it :)

[davidheff]

@RBergua I compiled with mingw-w64 and msys2. When I get a chance I will learn enough cmake to be able to advise on a change so that it builds out of the box.

Looking at your error, if the DLL has loaded successfully then I doubt that there is a problem with the build. Usually you have issues like link errors (static or dynamic) but if the DLL loads it's hard to see how your error could be due to the build environment.

[RBergua]

@davidheff Thank you for the prompt feedback. Did you try to run the compiled DLL in OpenFAST or any other aero-elastic tool? If so, could you make a Pull Request with that DLL so I could take a look at my side? Thanks in advance!

[davidheff]

OK. I'll do that tomorrow. I'm using OrcaFlex rather than openfast.

[davidheff]

I've attached a 64 bit version of the DLL, compiled with msys2/mingw64 off 10bbbfb

libdiscon.zip

[davidheff]

@nikhar-abbas I've submitted a PR for the minor changes to CMakeLists.txt discussed above.

Regarding the controller wrappers for OrcaFlex, we perceive the following issues.

1. Population of the swap array. The controller example on our website needs to be extended to populate additional members of the swap array to work with this controller. We can take care of that by modifying our example and republishing it.
2. Thread safety and state. In OrcaFlex it is common to run multiple models in parallel in different threads. As we understand it the BLADED controller style interface doesn't easily accommodate this mode of multithreaded use. The interface leads to controller state being store in global variables.
3. Thread safety and working directory. The working directory is a process wide variable. Again when running multiple models in different threads, this means that all those models share the same working directory. However, if the models are in different directories, and the controller code uses relative filenames rather than absolute filenames, then there is a conflict.

I suspect that this issue is not the best place to discuss these matters. How would be best to discuss it with you?

[nikhar-abbas]

@davidheff, thanks for the submission! We'll take a look over here and get things pulled into the main repos as soon as we can.

Those are all valid concerns going forward - this might be best discussed over email for now. If you could email me at [email protected] I will be able to give some more detailed responses on your concerns and loop in another researcher here who has worked through some of the avrSWAP array issues

[RBergua]

@davidheff Thank you very much! Unfortunately, I tried to run the DLL at my side, but I could not make it work. It seems that there are some dependencies pointing to your C unit:

[davidheff]

@RBergua That's not a dependency error. It's clear that the controller dll has loaded fine because only its code could be reporting a source code file name with a path from my machine. So the problem is not the DLL compilation. The problem is elsewhere.

[pelljam]

@RBergua I think your error is just because the DLL can't read the perf file (the path to which is given in the input file). I've not much experience with the ROSCO controller, but my understanding is that this path is relative to the current working directory. So you could try putting the file named in the error message there, or make sure the cwd is set correctly for this to be found where it is, or give the full absolute path to it in the input file.

[nikhar-abbas]

All,
We've been able to sort through the bulk of @RBergua's compiling issues offline.

We will be updating the cmake settings per @davidheff's pull request shortly.

Closing this issue for now.

Cheers,
Nikhar

[RBergua]

@pelljam Thank you for the feedback. You are completely right. There were actually 2 problems in my case. The first one is that the debug mode (LoggingLevel parameter in the *_DISCON.IN file) was trying to write a file in the working directory. In my case, I didn't have permission to write in that directory (the default one). I overcame that problem by setting LoggingLevel = 0 and not writing any debug file. Alternatively, I could change the working directory to a location where I had the proper rights to write a file. The other issue was related with the PerfFileName in the *_DISCON.IN file that you are commenting. The best way to overcome this one it was by using an absolute path rather than a relative path. Alternatively, I could have copy-pasted the file called by PerfFileName in the working directory.

As a final note, I was able to compile the ROSCO controller in Visual Studio without any problem, but I could not make it work in Cygwin64.

So, I can confirm that I compiled the DLL in Visual Studio and it's running properly after modifying the *_DISCON.IN file accordingly.