[BugFix] FF awae: set v_plane=0 when center of wake plane leaves domain #3025
Conversation
If a wake plane center leaves the domain, set the velocity of the plane to zero. In low wind speed cases where the center of a skewed wake plane was leaving domain, the remaining sampled region of the plane could get very small and have negative weighting. If this happens with a bit of flow reversal, the plane could suddenly jump backwards by a substantial distance. This was leading to some strange looking results and odd interactions with turbines near that edge of the domain.
jjonkman
left a comment
jjonkman
left a comment
There was a problem hiding this comment.
Looks like we discussed; thanks!
|
and thank you @andrew-platt and @jjonkman ! |
|
@ptrbortolotti -- Thanks for verifying that the algorithm works as intended. @andrew-platt and I discussed a small change whereby the wake planes get pushed outside of boundary of the low-resolution domain once their wake centers cross the boundary; @andrew-platt will implement this change before this PR is finalized. |
|
Hi @andrew-platt, Thanks for making this change. I agree this is the approach we discussed. However, I can still foresee a problem if one wake plane gets pushed out of the domain and those around it get close to the boundary, but don't get pushed out (e.g. when flow is nominally along X and a plane gets pushed out from the Y or Z boundaries). This could stretch the wake volumes between the plane that gets pushed out and those that remain in the domain. Getting around this would require adding some nominal free-stream velocity to the wake plan that gets pushed out, e.g., as is calculated to move the WAT box. |
|
Could we run into an issue with the free-stream velocity at the wake plane where the velocity is low so the plane only partially exits the domain? Could that land us back in the scenario that started this issue? Or are you thinking we could apply this over multiple timesteps until the entire wake plane has fully left the domain? |
|
I've run a comparison between the two recent commits and I see some minor differences in some signals. Here I plot rotor speed for T3 T2 also shows these minor differences, whereas T1s are identical |
|
@andrew-platt -- I'm thinking we should sum the nominal free-stream velocity with the velocity normal to the boundary that you already added. Likewise, use the nominal free-stream-velocity for any wake plane that has already left the domain. In this way, any wake plane that crosses a boundary will be pushed out, but once it is out, it will continue propagating downstream to prevent wakes from "bunching" up" near the boundaries where they exited the domain. |
If a plane exits the domain, or previously exited the domain:
- Set warning about first time this plane leaves.
- Set component perpendicular to plane exit direction to kick it outside the domain entirely
- Target distance outside boundary = D. Use a quadratic asymptotic distance per step to approach target distance.
- Add background flow in X or Y to keep the plane moving with others parallel to boundary it crossed (only using X and Y velocity)
To understand intent, consider 2 cases for mean velocity in +X direction:
plane exits +Y boundary:
1. plane with get a kick towards one wake diameter outside +Y boundary
2. overall farm velocity added to keep plane drifting in +X following the target Y location (some jitter due to farm level Y velocity term)
plane exits +X boundary (travels beyond domain end in direction of overall flow)
1. plane will get a kick outside the end of the domain towards +X boundary plus wake diameter
2. farm velocity added will keep trying to push this plane further downstream, but step 1. will try to force it back.
--> effectively 1. and 2. will constant be working against each other to hold the plane somewhere near the target location beyond +X boundary,
but this shouldn't really matter as the plane will get dropped at some point. Even if multiple planes end up there, it shouldn't affect
any planes still in bounds -- so we really don't care if it jitters around at all
everything looks good to me both in openfast outputs and flow from the vtk files |
|
jjonkman
left a comment
jjonkman
left a comment
There was a problem hiding this comment.
The overall approach makes sense to me and matches what we discussed. Just one comment below.
| V_plane(3) = (D_tgt - p_plane(3)) / (2.0_ReKi * real(p%dt_low,ReKi)) ! push towards (+Z_bound + D_wake) | ||
| end select | ||
|
|
||
| ! Step 3: add background XY plane flow to keep plane drifting (will have already returned on any planes still in bounds) |
There was a problem hiding this comment.
Why is this XY only, and not 3D? I wouldn't expect much mean velocity in Z, but I'm not sure why you chose this.
3 participants
Ready to merge, pending test results.
Feature or improvement description
In low wind speed cases where the center of a skewed wake plane was leaving domain, the remaining sampled region of the plane could get very small and have negative weighting. If this happens with a bit of flow reversal, the plane could suddenly jump backwards by a substantial distance. This was leading to some strange looking results and odd interactions with turbines near that edge of the domain.
The new approach is that as a wake plane exits the domain, it is given a target offset of one wake diameter beyond the edge it just crossed. This target is then used to set a velocity term perpendicular to the domain edge (velocity set to
V = (P_target - P_current) / 2 * DTso as to asymptotically approach the target location). The background farm flow (average of disk velocities from all turbines) is then added so that the wake plane will continue downstream.To understand intent, consider 2 cases for mean velocity in +X direction:
--> effectively 1. and 2. will constant be working against each other to hold the plane somewhere near the target location beyond +X boundary, but this shouldn't really matter as the plane will get dropped at some point. Even if multiple planes end up there, it shouldn't affect any planes still in bounds -- so we really don't care if it jitters around at all
Related issue, if one exists
Issue reported internally
Impacted areas of the software
Wake velocity calculations in the
AWAEmodule only.Additional supporting information
Wakes at
T=tTest results, if applicable
No test results change.