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.
setTimestepSize fails to run at 1.0 second step
Quote from Charuka on 20. May 2026, 19:43Hi,
I am a PhD student doing a research on wind turbines. I’ve been working with SIL interface seamlessly without any issue with 0.1 second time step. Somehow my own controller couldn’t achieve 0.1 second cycle time. Due to this reason I wanted to increase the time step size to 1 seconds. But every time I change it the simulation run fails with generated power surges or RPM going above stated values.
Has some one faced a similar issue with this, or is there something else I wanted to change. Small snippet of the the position where I define the timestep is attached below.
Thank you,
Charuka.
#—————————————————————————————————————————-
class QBInterface:def __init__(self, path=b”./external_software/NREL_5MW_OC4_Semisub_rev.qpr”):“””Initialize QBlade by setting paths, loading shared, libraries, and creating an instance.The instance MUST be created here in the __init__ function so that training can beperformed in parallel environments.”””# Creation of a QBlade instance from the library# NOTE: The first argument specifies the device, and the second argument the group sizeQBLADE.createInstance(c_int(1),c_int(32))# Loading a project or sim-file, in this case the DTU_10MW_Demo project or simulation definition file#QBLADE.loadSimDefinition(b”./DTU_10MW_Demo.sim”) #uncomment this line to load a simulation definition fileQBLADE.loadProject(path)def init_simulation(self, timesteps=10000, dt=0.1, mean_windspeed=10.0, turbulent_wind=False): # previously used 4000 LF used 2000“””Initialize the QBlade simulation for the start of a simulation runor for resetting the simulation to initial conditions.”””QBLADE.setTimestepSize(c_double(dt)) # Set the time step size to 0.1 secondsself.dt = dt## generate random number between -10 to 10 for initial positioninit_p_x = random.uniform(-10.0, 10.0)init_p_y = random.uniform(-10.0, 10.0)#Cau use to define initial starting point of turbineQBLADE.setTurbinePosition_at_num(c_double(init_p_x),c_double(init_p_y),c_double(0.0),c_double(0.0),c_double(0.0),c_double(0.0),c_int(0))# setTurbinePosition_at_num(double x, double y, double z, double rotx, double roty, double rotz, int num)QBLADE.initializeSimulation()
Hi,
I am a PhD student doing a research on wind turbines. I’ve been working with SIL interface seamlessly without any issue with 0.1 second time step. Somehow my own controller couldn’t achieve 0.1 second cycle time. Due to this reason I wanted to increase the time step size to 1 seconds. But every time I change it the simulation run fails with generated power surges or RPM going above stated values.
Has some one faced a similar issue with this, or is there something else I wanted to change. Small snippet of the the position where I define the timestep is attached below.
Thank you,
Charuka.
#—————————————————————————————————————————-
Quote from David on 21. May 2026, 16:40Dear Charuka,
The simulation time step for an aeroelastic turbine model cannot be chosen arbitrarily. It needs to be small enough to resolve the relevant dynamics of the model, especially the structural eigenfrequencies, rotor dynamics, aerodynamic loading variations and the controller response. If the time step is too large, the numerical integration can become inaccurate or unstable, which can then show up as power spikes, excessive RPM, or diverging structural response.
A time step of 1s is generally much too large for a coupled aero-servo-elastic turbine simulation. Even if the controller itself only updates slowly, the turbine model still has to be integrated with a sufficiently small internal time step. The issue you observe is therefore expected and is not specific to the SIL interface.
If your external controller cannot provide a new command every 0.1s, I would not increase the full QBlade simulation time step to 1s. Instead, keep the QBlade time step sufficiently small and update the control variables only at the frequency your controller can handle, while holding the previous values constant in between.
For this purpose, you can use:
setControlVars_at_num(double *vars, int num = 0);This function can be called with an arbitrary update frequency. The variables are:
vars[0] = generator torque [Nm]; vars[1] = yaw angle [deg]; vars[2] = pitch blade 1 [deg]; vars[3] = pitch blade 2 [deg]; vars[4] = pitch blade 3 [deg];So the usual approach would be to keep the simulation time step small enough for stable aeroelastic integration, but only update
setControlVars_at_num()whenever your external controll algorithm has generated a new command. Between calls to this function, the simulation reuses the previous torque, yaw and pitch values.Best regards,
David
Dear Charuka,
The simulation time step for an aeroelastic turbine model cannot be chosen arbitrarily. It needs to be small enough to resolve the relevant dynamics of the model, especially the structural eigenfrequencies, rotor dynamics, aerodynamic loading variations and the controller response. If the time step is too large, the numerical integration can become inaccurate or unstable, which can then show up as power spikes, excessive RPM, or diverging structural response.
A time step of 1s is generally much too large for a coupled aero-servo-elastic turbine simulation. Even if the controller itself only updates slowly, the turbine model still has to be integrated with a sufficiently small internal time step. The issue you observe is therefore expected and is not specific to the SIL interface.
If your external controller cannot provide a new command every 0.1s, I would not increase the full QBlade simulation time step to 1s. Instead, keep the QBlade time step sufficiently small and update the control variables only at the frequency your controller can handle, while holding the previous values constant in between.
For this purpose, you can use:
setControlVars_at_num(double *vars, int num = 0);This function can be called with an arbitrary update frequency. The variables are:
vars[0] = generator torque [Nm];
vars[1] = yaw angle [deg];
vars[2] = pitch blade 1 [deg];
vars[3] = pitch blade 2 [deg];
vars[4] = pitch blade 3 [deg];So the usual approach would be to keep the simulation time step small enough for stable aeroelastic integration, but only update setControlVars_at_num() whenever your external controll algorithm has generated a new command. Between calls to this function, the simulation reuses the previous torque, yaw and pitch values.
Best regards,
David


