Forum
Important Notice for New User Registrations
To combat an increasing number of spam and bot registrations, we now manually approve all new user registrations. While this may cause a delay until your account is approved, this step is essential to ensure the quality and security of this forum.
To help us verify your registration as legitimate, please use a clear name as user name or an official email address (such as a work, university, or similar address). If you’re concerned that we may not recognize your registration as non-spam, feel free to email us at with a request to approve your username.
The structural model diverged when a bladed-type controller was added
Hello David,
Thanks again for your comprehensive reply. After a few more tests, I discovered that the problem was rather the opposite. In fact, the pointer used by QBlade to find the .in file was always the same at each time step. However, the values of these lines were only initialized in the case of status 0, i.e. on the very first function call. To make this work, I’ve changed this to read the .in file each time the DISCON function is called. It’s quite strange but a cleanup is done at each time step when QBlade returns the swaparray for certain values (especially for the .in file, but the measured torque for example is not equal to 0),
Thank you very much for your assistance all the way to solve the problem,
Best regards,
Hugo
Hi Hugo,
I’m glad to hear that you managed to solve the problem.
Regarding the accINFILE parameter, it does not change at all during successive calls to the DISCON function. The only aspect that changes in QBlade between the first call and subsequent calls is that QBlade alters its “current directory”—an internal state of the QBlade application—to the /TEMP directory containing the controller library and .in file, and this change only occurs beforethe first call of the discon function.
Additionally, you are correct about the swap array: it is not intended to store any values persistently, as it is reinitialized at every timestep before the DISCON function is called. To store configuration values persistently (such as those read from the .in file), you would need to define a persistent array or a set of variables within your controller library. Alternatively, you can of course also re-read hese values from the .in file at every timestep, even if this is not intended in the design of the DISCON interface.
BR,
David
Hi David,
Is there a sample .IN file that works with “.\QBladeCE_2.0.9\ControllerFiles\libdiscon_ROSCO-2.9.0.dll” ? I tried using the attached .IN but QBlade aborted after initial ramp (I did not see an error message).
Regards
Salem
Uploaded files:- You need to login to have access to uploads.
Hi Salem,
when ROSCO crashes or exits, QBlade immediately aborts, because it cannot recover from a failure inside a loaded library.
A frequent cause of ROSCO shutting down is a missing rotor-performance table—the file referenced by the PerfFileName variable. Before loading the .IN file into QBlade, confirm that the file specified under PerfFileName exists at the stated path. If the file is not found, ROSCO terminates and QBlade follows suit.
I have attached the .IN files for the IEA 22 MW turbine, prepared for ROSCO 2.9.0; they should work without issues.
Best regards,
David
Uploaded files:- You need to login to have access to uploads.
Thanks, that works. This issue as you indicated was with the reading of the Cp_Cq_Ct table.
