Comments (16)
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.
from rosco.
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?
from rosco.
@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.
from rosco.
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.
from rosco.
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 :)
from rosco.
@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.
from rosco.
@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!
from rosco.
OK. I'll do that tomorrow. I'm using OrcaFlex rather than openfast.
from rosco.
I've attached a 64 bit version of the DLL, compiled with msys2/mingw64 off 10bbbfb
from rosco.
@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.
- 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.
- 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.
- 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?
from rosco.
@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
from rosco.
@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:
from rosco.
@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.
from rosco.
@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.
from rosco.
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
from rosco.
@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.
from rosco.
Related Issues (20)
- Error while installing ROSCO complitly on Windows 11 HOT 5
- read beamdyn? HOT 8
- Inconsistent behaviour of the yaw module HOT 2
- pip install -e . not working as intended on Windows HOT 2
- Output timestep in wfc_controller HOT 3
- K omega**2 control, definition of K HOT 1
- Additional Measurement Outputs from OpenFAST via zeromq HOT 1
- Invalid tag on 2.9.1? HOT 2
- The acquisition of PI parameters in torque control HOT 2
- Missing 32-bit Windows Libraries
- Is ROSCO safe for multiprocessing? HOT 2
- add wintypes to the ctypes import HOT 2
- Feature: expand wfc_zmq_server to allow wind farm controllers to access past measurements and measurements from other turbines
- Generator model
- WE_Mode setting 2 HOT 1
- `interp2d` has been removed in SciPy 1.14.0 HOT 1
- Max torque rate for the 5 MW HOT 3
- Check for prior initialization
- An issue with loading the simulator and controller interface in ROSCO HOT 8
- cannot find the ROSCO input file for IEA-15-240-RWT HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rosco.