New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wake-added turbulence in FAST.Farm #1785
base: dev-unstable-pointers
Are you sure you want to change the base?
Conversation
Tidy up a bit in the process
…as a FileInfoType) Changed some variables for more descriptive meaning
Also added some checks for grid size for AWAE with Mod_AmbWind 2,3 -- really cryptic errors otherwise
Also removed extra whitespace in AWAE.f90
… error handling for readability)
This should be cleaned up a bit more
AWAE could trigger a segfault in IfW if there are output channels but no lidar
There isn't any reason to use the full InflowWind_Init when we only want the data for the HAWC format and don't care about lidar or other stuff.
That is one very ugly routine. I don't even know how it works (not sure how Nxyz(2:3) get set).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed the documentation part of this PR. Please find my edits and comments below.
|
||
**WAT_D_BrkDwn** [float, dimensionless] | ||
Downstream distance in rotor diameter after which WAT scaling has reached 100% capacity. | ||
DEFAULT is 1 (i.e. 1D) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've discussed potentially replacing input WAT_D_BrkDwn
with one of the filter functions involved in the eddy viscosity formulation. I would guess F_vShr(x) would make sense because it represents the development of turbulent stresses generated by the wake shear layer, which seems to be what WAT_D_BrkDwn
is trying to achieve. The only issue I see is the DEFAULT values of C_vShr_DMin
, C_vShr_DMax
, C_vShr_FMin
, and C_vShr_Exp
used to define F_vShr(x) result in a filter function that does not approach unity until 25D. This would impact the calibration of WAT_k_Def
and WAT_k_Grad
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be risky to rely on the same inputs indeed.
But it's true that we could use the function EddyFilter
, and call it with C_Dmin=0
and C_Dmax = WAT_D_BrkDwn
As for the FMin
and the exponent, we could use the values from the input file, but they might represent something a bit different, maybe it's best to hardcode them to say FMin=0
and Exp=1
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we should hold off on deciding this until the calibration is further along. I recall thinking before that the calibration may require different values at different downstream distances, which may work well if we have a filter function that is downstream-distance-dependent.
For finalizing:
|
This pull request is ready to be merged
Feature or improvement description
Implementation of the wake-added turbulence into FAST.Farm
Impacted areas of the software
FAST.Farm
Additional supporting information
The feature and input file changes has been documented, but it requires the calibration of its two main constants.
r-tests and additional documentation will follow after the calibration.
The following additional inputs are added to the input file:
Test results, if applicable
Test results are unchanged.