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.

Please or Register to create posts and topics.

setTimestepSize fails to run at 1.0 second step

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.

 

#—————————————————————————————————————————-

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 be
        performed in parallel environments.”””
        # Creation of a QBlade instance from the library
        # NOTE: The first argument specifies the device, and the second argument the group size
        QBLADE.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 file
        QBLADE.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 run
        or for resetting the simulation to initial conditions.”””
        QBLADE.setTimestepSize(c_double(dt))  # Set the time step size to 0.1 seconds
        self.dt = dt
        #
        # generate random number between -10 to 10 for initial position
        init_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 turbine
        QBLADE.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()

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

Scroll to Top