Open Alessandro5I opened 3 weeks ago
I solved this by forcing the "Demanded Power" to a large number in the avrSWAP matrix in the turbine level control in SC_MATLAB. Is this the correct way? Is there a way to change this setting in the controller input for example? Thanks, Alessandro
Hi,
yes that is correct, well spotted :-) for info, this behaviour is also observed when alarms (for instance overspeed) are triggered during transients at startup you can switch input 79 "de-rating strategy" in the controller input file to 0 for normal/greedy operation
I'm glad to see you managed to use this and hope you can get something out of it. Don't forget to cite our work then.
BR Valentin
Yes I will be happy to cite you.
In case I need to use another turbine type (eg. the 15 MW from IEA), how difficult would it be to change the turbine controller? Can I simply change the inputs or I need to do something else?
Thanks, Alessandro
You just have to change the input file, that you can directly obtain from the GitHub repo of the IEA 15MW, with small changes as in the attached file (you may just use that one). controller_input.IEA15MW.DTUWEC.txt
Dear Friggitotti,
Hello!I encountered some problems and would like to consult with you.When I use the SCClient_64.dll, it works fine, the MPI is connected successfully, indicating that there is no problem with my MPI communication, but when I use the SCClient_DTUWEC_64.dll, it shows connected, but it keeps getting stuck in this interface. Have you ever had a similar situation when using SCClient_DTUWEC_64.dll, and how did you solve it?
Thanks, ZhichaoYg
Dear Friggitotti, Hello!I encountered some problems and would like to consult with you.When I use the SCClient_64.dll, it works fine, the MPI is connected successfully, indicating that there is no problem with my MPI communication, but when I use the SCClient_DTUWEC_64.dll, it shows connected, but it keeps getting stuck in this interface. Have you ever had a similar situation when using SCClient_DTUWEC_64.dll, and how did you solve it?
![]()
Thanks, ZhichaoYg
Have you tried to check the dll with DependencyWalker?
DependencyWalker captures structural dll issues that would result in a crash. In what ZhichaoYg describes, the client or the server is waiting for the other to proceed. You should look at the client and server verbose files to see where the simulation halts. Assuming it comes from the client (SCClient_DTUWEC_64), I would first take a look at SCClient_out.dat to see if it ever exists/has output stg (which would mean the dll has completed one timestep). Then try printing out some additional debug info there to narrow down the search. The first step is, of course, to recompile SCClient_DTUWEC_64.dll.
Thank you very much for your suggestion, I see, I need to try to recompile the SCClient_DTUWEC_64.dll, of course, is it SCClient_ROSCO_64.dll need to be recompiled to work? And I may not have figured out how it works, why SCClient_64.dll doesn't need to be recompiled to work successfully?
Well, SCClient_ROSCO_64.dll is if you want to use the ROSCO turbine controller, SCClient_DTUWEC_64.dll if you want to use the DTUWEC turbine controller. Your choice, but I've mostly been working with DTUWEC so I recommend it to be able to provide support. See https://github.com/ValentinChb/SC_MPIClient. I don't think you should recompile libDTUWEC4SC.a. @Alessandro5I maybe you can send your recompiled dll to @ZhichaoYg to see if it helps? Regarding why SCClient_64.dll seems to work, it's hard to know without digging deeper.
I did not recompile anything to solve my issues, they were simple errors in MPI installation and operating procedure. I've found very useful the "readme" present in the run_MATLAB batch file.
Well, indeed the binaries should work as is without need for recompiling, and one should carefully look at the debug info (readmes and output files) I provided first. @ZhichaoYg, can you upload stdout_MPIServerSubs.txt, stdout_SCClientSubs.txt, SC_input.dat and SCClient_out.dat, your .fstf file and SC_MPIServer.m for your run?
Well,I have uploaded the file I got after using two different controllers(SCClient_64.dll and SCClient_DTUWEC_64.dll), thank you very much for helping me to see the problem! FASTFarm2Sim.zip
Thanks @ZhichaoYg. Your MPI communication runs correctly and the simulation stops at the fourth timestep. Turbine 2 actually seems to have completed step 4. To debug further I'd look at SCClient_out.dat from other turbines (I guess you sent me the files for turbine 1). Not sure why this happens. But from what I can see in SCClient_out.dat (written by SCClient_DISCON.f90), your demanded power (stored in avrSWAP(13)) is 0. Either set this to a large number in Matlab, or set input 79 in controller input file to zero (see posts earlier in this thread). You may also try to switch off the wind speed estimator by setting input 81 in controller input file to zero.
Thank you very much for your guidance, I will go through it carefully and revise it, in addition I added SCClient_out.dat for turbine2 and turbine3. F2M.zip
Hi, I've written a simple step-to-step guide for the use of this helpful tool. I've slightly modified the original setup and procedure but this is how it worked out for me. Thanks, Alessandro FAST.Farm-MATLAB MANUAL.docx
Hi, I'm running some simulation with the SCClient_DTUWEC_64.dll, as I understand by using this dll I'm able to write a farm level controller or overwrite some turbine level instructions in the matlab. I tried a run without modifying anything in the SC_MATLAB code just to see if it works. I got strange control procedure from the turbine I'm analyzing, the power output goes to zero and the blade pitch is very high. I attach some pictures. Inflow wind is set to 10 m/s and at that windspeed the pitch angle of the blade should be zero.
Any idea what I'm doing wrong?
Thanks, Alessandro