-
Notifications
You must be signed in to change notification settings - Fork 25
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
Pseudo-Steady Solver Logic #50
Conversation
# FIXME: We should be consistent about which way the turbine | ||
# forces are oriented. | ||
if self.farm.turbine_method != "alm": | ||
self.tf *= -1.0 |
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.
@jefalon what do you think about standardizing the direction the turbine force points? I'd like to swap everything so that turbine forces point opposite the incoming flow, but recognize that ALM is the odd one out and it would be easier to bring it into line with the others.
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 that's a good idea and having it opposite to flow is logical since it's suppose to be forcing it to slow down. Thinks to check to make sure this sign flip doesn't break anything is:
- the sign of the tf term in the system functional for both the stabilized and Taylor hood steady solver
- the sign on the power and 2d_power objective functions
- probably some other place I can't think of
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 need to fix the opt output for plotting
This PR allows the user to specify
final_time = none
in the yaml to trigger a pseudo-steady run of the unsteady solver, where the solver will continue iterating until the average velocity field converges.stability_eps: 0
)It most likely won't pass GHA because it also uses the fast/optimized solver+preconditioner pairs which leads to slightly different results.