openfast
openfast copied to clipboard
Implementation of the curled-wake model in FAST.Farm
Not ready to merge
Feature or improvement description Implement the curled wake model into FAST.Farm
- Uses a Cartesian grid as output of WakeDynamics and within AWAE. for both polar and curled wake
- UpdateStates of WakeDynamics is modified to accommodate curled wake using if statements throughout
- Outputs of WakeDynamics are in cartesian coordinates and on cartesian grid
- FAST.Wrapper returns Cq, psi_skew and chi_skew
Impacted areas of the software FAST.Farm, AWAE, WakeDynamics
Additional supporting information
Test results, if applicable We expect small changes in the r-test sine we don't use the filtered velocity anymore to compute dx and convect, and beasue we use a Cartesian grid to communicate with AWAE.
Checklist
- [ ] Document input file changes. Add link to paper
- [ ] Understand why elimination of velocity filter created issues at last time step of r-tests
- [x] Review the filtering of skew angle and azimuth angle
- [ ] Decay of wake curl needs tuning and default value. (Elliminate the need for deflection parameters, decay should take care of it)
- [ ] Set default value of f_c based on the a=1/3, Uinf = 8, and a rotor radius based on the wake plane radius
- [ ] Finalize implementation of plane outputs (- base name of VTK files, - Comment out the old wake-based write outputs for the velocity deficits and eddy viscosity values, - Ensure that the VTK-based output for the velocity deficits and eddy viscosity values also works for polar)
- [x] Add OpenMP parallelization of WD update states (and perhaps calculate output?)
- [ ] Add an r-test for the curled wake (based on the yaw steering test case with one of the existing turbulent wind data files)
FYI: at the moment it looks like some of the FAST.Farm source code in this PR has white-space changes (different line endings?) on every line. For example, see FAST_Farm_Subs.f90.
Damned, I just saw that, I think it's just in the last commit. I'm not sure how it happened and how I can easily reverse that, let me know if you have a good hint. I'll try to revert and force push this commit.
I think I would try to just convert the line endings of the affected source files in the next commit and then squash the two commits so just the main differences remain.
There are usually git settings that allow you to checkout code with specific endings and commit with (possibly different) line endings. Did you use a different git client than normal? Did your git settings get reset?
Fixed... I used set ff=unix
in vim on those files. I might have mingled with git config --global core.autocrlf true
before this problematic commit, but that was to actually try to avoid this issue as I could see vim not being happy with the file endings... I'll keep an eye out in my next commits to make sure it doesn't happen again. Thanks for spotting it!
Change of convection velocity slightly affect the test results (for LESInflow):
Test cases will be rebaselined