Empirical Gauss - Yaw added recovery

[MiguelMarante]

Hello everyone,

I am looking into the Empirical Gauss model to try to figure out the calibration procedure I should adopt. However, I have some questions regarding yaw added recovery.

According to other models (GCH, CC), when computing the wake of an upstream turbine, yaw added recovery only influences the velocity deficits, but for the EG this "added-mixing" is computed before the deflection model.

GCH:

EG:

This means that for the EG, we cannot split the calibration between first row and second row steering.

The ideal split for yawed scenarios would be:
1st row steering: horizontal_deflection_gain, deflection_rate, yaw_added_mixing_gain
2nd row steering: mixing_gain_deflection

But since we have this coupling between deflection and yaw added recovery, all the parameters need to be calibrated simultaneously.:
1st row steering: horizontal_deflection_gain, deflection_rate, yaw_added_mixing_gain, mixing_gain_deflection

Is there a reason why you formulated the model this way? And what are your recommendations regarding yaw_added_mixing_gain, mixing_gain_deflection parameters?

[misi9170]

Hi @MiguelMarante, thank you for the question! I don't have an immediate answer for you on this, so I will think through this carefully in the next days and get back to you---at this stage, I just wanted to let you know that I've seen your question and am working on an answer.

[misi9170]

Hi @MiguelMarante,

I apologize that it's taken me this long to get back to you. As you may be aware, we have just released FLORIS v4, which has been taking up a lot of my attention with FLORIS. If you get a chance to try it out, we'd be happy to hear your feedback! If you are thinking of trying out v4, make sure to check out the documentation, as there are some significant changes to the user interface.

Anyway, to try to answer your question...

The reason that the yaw_added_mixing term appears before the deflection_model calculation is so that the deflection model and velocity deficit model have a consistent value for the "wake induced mixing", denoted $\text{WIM}_j$ in the Empirical Gauss documentation and mixing_i in the code (apologies for the $i$ vs $j$!).

If the yaw added mixing was added after the deflection model calculation took place, as happens (as you point out) in the Gauss model, then $\text{WIM}_j$ would differ between the deflection model and velocity deficit model, which is something that we were trying to avoid.

With that being said, I'm not sure that we fully worked through the ramifications of this decision for tuning. As you point out, the form of the model makes it difficult to differentiate between "true" deflections of the wake and yaw added mixing. I will continue to think about this and speak to my colleagues to see if we have any further thoughts. I'd also be very happy to chat about this further; feel free to send me an email at the address listed here.

In terms of recommendations for the tuning parameters for the deflection (and yaw added mixing) models: we have (so far) found that setting mixing_gain_deflection and yaw_added_mixing both to zero has produced satisfactory results. Quite possibly, this is why we haven't so far had to grapple with the issue you are facing! Wake steering is of course quite sensitive to the horizontal_deflection_gain, but we have also been recently finding that the deflection_rate parameter can have an important effect. We actually updated the default for this parameter in #875, and that is now included in FLORIS v4, but perhaps more than anything that should serve as an indication that altering the deflection_rate can have an important effect.

We are still in rather the early stages of working out how the EmG deflection model should be tuned. You have perhaps seen the examples in FLASC that begin to look into this, but there we only adjust the horizontal_deflection_gain and we have seen examples when the "best" deflection_gain is 0, we think because the reduction in axial induction and thrust caused by yaw misalignment (as modeled) is enough to predict the uplift at the second turbine without needing to deflect the wake, when the wake is dissipating quickly anyway. Whether that is true is debatable. Again, please feel free to reach out if you'd like to talk about this more, we'd love to hear your ideas and feedback.

Note that, with the release of FLORIS v4, we also released FLASC v2. The changes are not as significant as those for FLORIS v4, but we did reorganize the repository so some imports have changed if you've used FLASC before.

Cheers,
Misha