Rotor Aero power and Actuator disc forces

[tchatte3]

Hi Nalu-wind development team,

When I am running Nalu-wind openfast model for NREL 5MW wind turbine, I see very strong fluctuations in Rotor Aero power from openfast output channel i.e. 3P characteristics and from tower shadow effect which makes sense.

On the Nalu side, when I am running Actuator disc simulations, the actuator forces on disc location converge to a steady state (no fluctuations) with RANS. I am trying to have a physical explantion of that process. I read in the Nalu Manual that there is first order FSI coupling between openfast and Nalu-wind. Could that be the reason (i.e. filtering out the fluctuations?). If yes, could somebody point me which routine to look for? Or is the FSI only used for ALM and not ADM?

ADM forces, diskAppliedForce gathers and redistributes the forces collected at the actuator nodes. But that can explain spatial smoothing, not temporal filtering.

Also, dt_Nalu >> dt_openfast, but still dt_Nalu is able resolve 3P characteristics of the rotor.

Any suggestions/help as to why the time-fluctuations in Aerorotorpower in openfast not seen in actuator disc forces in Nalu-wind?

Best Regards,

[lawrenceccheung]

hi @tchatte3,

Could you share any graphs which compare the level of power fluctuations between the ALM and the ADM simulations? I am curious to see if that can be physically explained, or if there's caused by something in the setup.

Thanks,

Lawrence

[tchatte3]

@lawrenceccheung Sure.

The magenta plot corresponds to Nalu-wind+openfast run with ADM simulations. Output channel from openfast. I verified the fluctuations minimum dips are coming from openfast tower shadow model [also visible in stand-alone openfast runs] . See, a variation of 1MW is observed. The frequency has 3P characteristics.

This is the actuator source term variation in the vertical direction (@ 20 mps wind) becoming time-converged.

[lawrenceccheung]

Hi @tchatte3, Thanks for providing the plot. Yes, a 1MW variation is quite substantial. One question -- are you using the same controls as the standard NREL 5MW model? That model should have a rated wind speed of 11.4 m/s, with rated electrical power of 5MW (rated mechanical power 5.29MW) -- see the document at https://www.nrel.gov/docs/fy09osti/38060.pdf.

Using those controls at high wind speeds like 20m/s, the power output should be pretty flat (almost exactly 5MW). Another thing to check would be rotor speed or blade pitch. The rotor speed should max out at 12.1rpm at such wind speeds, and the blade should start pitching after rated.

Lawrence

[tchatte3]

@lawrenceccheung Thanks. In the mean sense (time-average of the periodic stead-state power), I am hitting exactly the power curve. In general, in the mean sense, I have already established NREL 5MW power chart that you shared. I also get similar time varying fluctuations in the stand-alone openfast runs, and yes I compiled the DISCON.dll from .f90 file written by Jason Jonkman. I did not change the controller parameters in the .f90 file.

I did not dump out blade pitch,but the rotor speed did flatten out to 12.13 rpm in the periodic steady state limit.

Here is my .yaml file section

actuator: type: ActDiskFASTNGP search_method: stk_kdtree search_target_part: [fluid_part,fluid_part.pyramid_5._urpconv,fluid_part.tetrahedron_4._urpconv]

  n_turbines_glob: 1
  dry_run:  False
  debug:    False
  simStart: init
  t_start: 0.0
  t_max:    5000.0
  dt_fast: 0.00625
  n_every_checkpoint: 10000

  Turbine0:
    num_force_pts_blade: 40
    num_force_pts_tower: 20
    nacelle_cd: 1.0
    nacelle_area: 6.53
    air_density: 1.225
    epsilon: [4.5, 4.5, 4.5]
    turbine_base_pos: [2500.0, 1575.0, 0.0 ]
    turbine_hub_pos:  [2500.0, 1575.0, 90.00 ]
    restart_filename: "blah"
    fast_input_filename: "nrel5mw.fst.in"
    turb_id:  1
    turbine_name: machine_one

---

Ran this for nalu-time = 4000.0 secs. time in .fst file is also set to 5000 secs.

[psakievich]

@tchatte3 this behavior you are describing is not unexpected. There is a subtly here in how the two codes see the data for the ADM method. OpenFAST is still running it's turbine model; it sees a 3 bladed rotor spinning and computes displacements and forces based on the velocities Nalu-Wind provides.

Nalu-Wind on the other hand samples the flow from a fixed position in space and does not spin the rotor at all because it never updates the original point locations. It supplies this velocity to OpenFAST, and when it receives forces back from OpenFAST they are for the 3 original blades. To create the disk forcing it then uniformly spreads the forces across the circular path at each radial location along the blades.

The picture on the left is an image of what this looks like: Which can be found in the documentation here

The dark blue lines are the original actuator lines that sample the flow and the other points are the "swept points" between them. This model allows you to obtain actuator-line-like behavior from the OpenFAST model while still only needing actuator disk sampling in CFD space. You will not see tower shadowing events in the CFD model because of how the coupling is done (smearing the forces across the entire disk), but you can see them in the OpenFAST model because OpenFAST is still solving for individual blades and accounts for the tower interaction.

[tchatte3]

@psakievich This really helps. I realize, the rotor not rotating in ADM is also kind of acting like a time-lagged model/1st order filter, so this addresses my concern.

A follow up on that: in openfast the turbine is actually "rotating" means that the force actuator nodes are changing the locations on which forces are computed, but these forces are finally interpolated to the original "locked" actuator line in Nalu-wind CFD. Is this correct interpretation?

Best Regards,

[psakievich]

@tchatte3 sort of. To say the forces are interpolated to the original position is not fully accurate. The forces Nalu-Wind sees in the solver are the smeared out average of the three blades that is the same for any point at a fixed radius away from the hub. This is because the ADM forcing can also be thought of as the average forcing over 1 rotation period, and as such the azimuthal location can be any angle. So in that sense it doesn't really matter what the point location is as long as it remains in the path of rotation. For book keeping it is just easiest to leave them fixed. The bigger impact of this is probably that the place where the velocity field is sampled is always fixed in space, but going back to the interpretation of a time averaged forcing field this would also still be valid.

The concept of blade position must be communicated between OpenFAST and Nalu-Wind. For the ALM method we keep them exactly the same. For the ADM we don't communicate that information at after the initialization. So to be slightly more precise, OpenFAST is still solving an ALM but that is being informed by an ADM representation in Nalu-Wind, or vice versa.

[tchatte3]

@psakievich Thanks for the clarification. This helps.