Encountered some issues while attempting to run

[VenusJinxin]

Dear ValentinChb, I noticed the following content in the file "DTU_10MW_RWT_ServoDyn.dat": [ ---------------------- BLADED INTERFACE ---------------------------------------- "ControlData\SCClient_64.dll" DLL_FileName - Name/location of the dynamic library {.dll [Windows] or .so [Linux]} in the Bladed-DLL format (-) [used only with Bladed Interface] "ControlData\controller_input.DTU10MW.DTUWEC.txt" DLL_InFile - Name of input file sent to the DLL [used only with Bladed Interface] (-) "SCClient_DISCON" DLL_ProcName - Name of procedure in DLL to be called (-) [case sensitive; used only with DLL Interface] default DLL_DT - Communication interval for dynamic library [used only with Bladed Interface] (s) (or "default") ......] But I couldn't find the folder "SCClient_DISCON". In the FASTFarm example, it comes with a DISCON folder and I am able to run it. May I ask where to download this folder, or do not worry about it during runtime?

Best regards,

[ValentinChb]

Dear VenusJinxin,

I do not fully understand your question. What is the problem since you are able to run? SCClient_DISCON is not a folder nor a file, but the name of the procedure to be called in the shared library (dll). You will see it if you run DependencyWalker on SCClient_64.dll, or if you look at the source code (a link for the turbine controller/MPI client' repo is provided in this repo's description). I would say that understanding the functioning of the client (turbine controller) DLL is beneficial if not necessary for debugging and optimal use of the FAST.Farm/Simulink interface. Best Regards Valentin

[VenusJinxin]

Dear ValentinChb, Thank you so much for your patient guidance! I have recently started learning OpenFAST and FAST.Farm, and I am not very familiar with some of its programs and codes. I plan to continue my study on them, and I am eager to receive your continued assistance! In fact, perhaps due to the high version of OpenFAST I have installed, I have encountered difficulties running your test case, and I am receiving the following error: "Farm_Initialize: Farm_ReadPrimaryFile: Invalid numerical input for file "FAST.Farm_N3.fstf" occurred while trying to read Mod_WaveField." As a result, I have attempted to modify the test cases that I can successfully run in the command prompt, following the case you provided. Now I have made the following modifications: 1) RunTest_MATLAB.bat. I have modified it to enter my example folder. 2) ServoDyn file corresponding to the turbines. I changed the content of "BLADED INTERFACE" as follows:

---------------------- BLADED INTERFACE ---------------------------------------- [used only with Bladed Interface]
"Control/SCClient_64.dll"  DLL_FileName - Name/location of the dynamic library {.dll [Windows] or .so [Linux]} in the Bladed-DLL format (-) [used only with Bladed Interface]
"Control/controller_input.NREL5MW.DTUWEC.txt"    DLL_InFile   - Name of input file sent to the DLL (-) [used only with Bladed Interface]
"SCClient_DISCON"      DLL_ProcName - Name of procedure in DLL to be called (-) [case sensitive; used only with DLL Interface]
"default"     DLL_DT       - Communication interval for dynamic library (s) (or "default") [used only with Bladed Interface]
...

The files in the folder Control are (I am not sure about the necessity of these files): 3) SC_input.dat. I have completed the corresponding modifications according to the comments in RunTest.bat. Then I run RunTest_MATLAB.bat, then two command prompt windows popped up. When the second window shows "Ready to connect", I press the Enter key in the first window, then a PowerShell window appeared. The message showed in PowerShell window was consistent with the same case I run successfully in the command prompt (without use SCClinent_64.dll). However, It looks like it's no longer running because time has been stuck at zero. I'm not sure which step went wrong, what should it be like to run normally? Could you please provide guidance on the expected normal execution process? Your assistance in guiding me through the usage would be highly appreciated. Thank you in advance. Best Regards, VenusJinxin

[VenusJinxin]

Dear ValentinChb,

Recently I attempted to incorporate farm-level and turbine-level controllers in "SC_MATLAB.m". However, despite my efforts, I have been unable to run the program successfully. The simulation seems to stall at 0 to 1000s, and I am uncertain where the issue lies. I am also contemplating whether it is necessary to use "FAST.Farm_x64.OMP.exe" to run the case. When attempting to execute this file on my computer, I encountered an error, preventing successful execution.

I truly appreciate your time and consideration in assisting me with this matter. As I am still facing difficulties and eagerly seeking a resolution, your expertise would be immensely beneficial. If there is any additional information or clarification needed from my end, please let me know. I understand your schedule may be hectic, but I am hopeful for your advice. Your guidance is crucial to my progress in this project, and I am grateful for any support you can provide.

Yours sincerely, VenusJinxin

[ValentinChb]

Dear VenusJinxin,

see my answer to another issue to understand more about the functioning of the interface: https://github.com/ValentinChb/FASTFarm2Simulink/issues/2#issuecomment-1914202597 can you look at the connection status files for both server and client and share their content? is the simulation still stuck at 0 or does it perform a few timesteps and crashes?

BR, ValentinChb

[VenusJinxin]

Dear ValentinChb, Sorry for not replying to you for so long. Recently, I was responding to the review comments of a paper, so I did not continue to study this part of the content. Now, I am starting to study it again. I have read your reply to Zhichao Yg, after running "RunTest. bat", the MPI_shared.dat file was immediately updated in the FASTFarm2Simulink-main folder; I changed the 4th line of the SC_input. dat file in the FASTFarm2Simulink-main\Test3WTs\OpenFAST folder to "../../MPI_shared. dat", which should correspond to "MPIshared. dat" in the FASTFarm2Simulink-main folder. However, the result of the program running is still the same as before, with time stopping at 0 of 1000 seconds, which looks like FAST FARM is not running: The content in the stdoutSCClientSubs.txt document under the FASTFarm2Simulink main \ Test3WTs \ OpenFAST \ T1 \ ControlData folder is displayed as follows: ` DISCON: Did not manage to identify seed number. The control file location must fulfill the architecture //OpenFAST/T/ControlData I don't understand what's the meaning of/_`? In fact, I created the folder based on the "Test3Turbines" example you provided. The address of the folder is "C:\Users\Lenovo\Desktop\fast-farm\FASTFarm2Simulink-main\Test_3WTs\OpenFAST\T1\ControlData", and the contents of the folder are as follows: I still haven't found out which step of my try went wrong, and I kindly request your help again!

[ValentinChb]

Dear VenusJinxin,

without being 100% sure, it indeed looks like there might be a version conflict there. \<Farm root folder> is Test3WTs. SCClient has been updated to encompass stochastic simulations with different wind field realisations, hence the \<Seed number> which in your case should be 1. Can you try to insert a folder Test3WTs_1 in the path between Test_3WTs and OpenFAST? you might need to update some paths in the input files also in case they are absolute

BR

ValentinChb

[VenusJinxin]

Dear Valentin, Thank you very much for your prompt response. I followed your advice and added the Test3WTs_1 folder between the Test3WTs and OpenFAST folders. However, the situation remains unchanged from before.

I am considering whether aligning my FAST.Farm version with yours could be a solution. Currently, I am using version 3.5.0; could you kindly confirm the version you are working with?

Once again, I appreciate your assistance and am looking forward to any further guidance you can provide.

Best regards,

Venus

[ValentinChb]

Dear Venus,

The FAST.Farm version has nothing to do with this. All the communication occurs through the wind turbine controller dll SCClient, which communicates with the SC server bridging to Simulink on the one hand, and if desired to the wind turbine controller DTUWEC or ROSCO on the other hand. FAST.Farm may be tested separately by not using any external wind turbine controller dll (PCMode and VSCtrl = 0 in ServoDyn input file, GenDOF=false and Rotspeed the fixed rotor speed of your choice in ElastoDyn input file).

I will try to allocate some time to test and debug the setup and allow you and others to use this. Although I am standing behind the general development of the connection between FAST.Farm to a supercontroller via MPI, this repository (and in particular the connection to Matlab/Simulink which I normally do not use) is the result of Coen Jan Smit's student work and details are not in my control. I will have to reproduce the setup and this will take some effort.

In the meanwhile, I suggest you to take a look at the source code of the various layers (in particular SCClient) and try understanding where the communication is stuck. It is generally not expected to be a plug-and-play solution for people not willing to dig into and recompile the internals.

Best regards,

Valentin

[VenusJinxin]

Dear Valentin,

I sincerely appreciate your willingness to dedicate time for guidance. In the upcoming days, I plan to delve into the source code and underlying logic of the .dll, as well as the communication logic between the two components. I will try to gain a deeper understanding and hopefully resolve the issues at hand.

I hope to continue our valuable exchange through email. I have found our communication immensely beneficial. Additionally, I will continue to check this page regularly for updates. If there are any developments, kindly provide a response through this web page.

Thank you once again for your support.

Best regards, Venus

[VenusJinxin]

Dear ValentinChb,

Recently, I have started learning to use the program and code you provided again. I noticed that the bat uses "FAST. Arm_x64_OMP. exe" instead of "FAST. Arm_x64. exe". Do I have to use "FAST. Arm_x64_OMP. exe"?

Best regards, Venus

[ValentinChb]

Dear Venus,

I am not sur I understand your question as FAST.Farm_x64_OMP.exe is used throughout the project as far as I can see, but you are free to use the version without OMP if you want to. You may also use or a newer version of FAST.Farm, as long as the OpenFAST input files are compatible. All the communication is done via the wind turbine controller dll, which does not depend on the version of FAST.Farm.

best regards, Valentin

[VenusJinxin]

Dear Valentin, Thanks so much for your quick response! When I use the version without OMP, an error occured as follows: `Ready to connect An error occured in MPIServer_Init Connected Error using zeros Requested array exceeds the maximum possible variable size.

Error in SC_MATLAB (line 20) avrSWAP=zeros(nT,nc, 'single');` The content in Powershell, stdout_MPIServerSubs.txt, and stdout_SCClientSubs.txt is: I haven't change any code in "Test3turbines" folder, and I don't know if I should change any code in "SC_MATLAB"?

Best Regards, Venus

[VenusJinxin]

I checked the return values of MPI-sharedfile and nT and found that the value of nT is particularly large, making it impossible for MATLAB to create an avrSWAP array.

[ValentinChb]

Hi Venus, nT is the number of turbines, obviously 1734637436 is too large :-D The problem occurs in MPIServerSubs.f90, it fails at initializing the MPI connection and aborts, leaving an undefined number for nT. I am not sure why this is happening. The MPI connection is correctly initialized on the client side, but the server does not accept it. Maybe this is a firewall issue, have you authorised the MPI client (FAST.Farm) there?

[VenusJinxin]

Dear Valentin,

Thanks for your kind guidance, and I have closed the firewall but the results is same as before. I check my firewall, and FAST.Farm_x64.exe is allowed to communicate through firewall: I'm not sure where else do I need to change?

Yours sincerely, Venus

[ValentinChb]

Dear Venus, I've done what I should have done for long time ago and improved debugging info and fixed things that may well have lead to system-dependent portability issues explaining why it worked for some and not for some others. Give it a try and let me know. -Valentin