Skip to content
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

corrections for phi<=0 #287

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

corrections for phi<=0 #287

wants to merge 3 commits into from

Conversation

hcOnel
Copy link

@hcOnel hcOnel commented Jul 11, 2019

@@ -475,10 +475,14 @@ void Foam::fv::axialFlowTurbineALSource::calcEndEffects()
{
vector elementVelDir = elementVel / mag(elementVel);
scalar relVelOpElementVel = -elementVelDir & relVel;
vector rotorPlaneDir = freeStreamDirection_;
vector rotorPlaneDir = axis_; // use axis_ instead of rotorPlaneDir_
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this properly account for CW/CCW rotation?

Copy link
Author

@hcOnel hcOnel Jul 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The better explanation would be: it works only if the angle between freeStreamDirection_ and axis_ is within the range of -90...0...90 degrees. And since in the current state of the code, there is no way to reverse the turbine rotation while keeping axis_ the same, it can be said that this works only for CW rotation.
I should have added this as a comment.
Also, // use axis_ instead of rotorPlaneDir_ is not correct. It should have been // use axis_ instead of freeStreamDirection_.
Should I cancel this commit and make a new one?

Co-Authored-By: Pete Bachant <petebachant@gmail.com>
@petebachant
Copy link
Collaborator

You can keep adding new commits to your fork, and I can squash-merge once it's ready. Note that in the future it's usually a good idea to work on branches instead of master so it doesn't get confusing, but we can keep going with this one.

@petebachant
Copy link
Collaborator

If you take a look at the Travis log, you can see the test is failing since the end effect factor is not in the expected range: https://travis-ci.org/turbinesFoam/turbinesFoam/jobs/557763236

@hcOnel
Copy link
Author

hcOnel commented Jul 12, 2019

You can keep adding new commits to your fork, and I can squash-merge once it's ready. Note that in the future it's usually a good idea to work on branches instead of master so it doesn't get confusing, but we can keep going with this one.

Ah ok, sorry I am a complete newbie in Github. I'll check that feature for my next commit, thanks!

If you take a look at the Travis log, you can see the test is failing since the end effect factor is not in the expected range: https://travis-ci.org/turbinesFoam/turbinesFoam/jobs/557763236

Hmm the expected range for tip loss factor f is [0,1] right? I couldn't figure out how that happened.

@petebachant
Copy link
Collaborator

Hmm the expected range for tip loss factor f is [0,1] right? I couldn't figure out how that happened.

Yep, but for that test, I constrained it further just to make sure it was significantly below 1, i.e., that it was working at the tip.

@hcOnel
Copy link
Author

hcOnel commented Jul 13, 2019

So, maybe it is the VSMALL value that causes f=1?

@petebachant
Copy link
Collaborator

Looks like it. Perhaps phi should be allowed to be negative, but only set to VSMALL if exactly zero.

@hcOnel
Copy link
Author

hcOnel commented Jul 18, 2019

Looks like it. Perhaps phi should be allowed to be negative, but only set to VSMALL if exactly zero.

phi being exactly equal to zero is a very, very rare case. In my simulations, the problem arises as soon as phi drops below zero, even by the smallest amount allowed by machine precision. This is related to the definition of the tip correction function f, which is not designated to take negative phi values.
Should phi be allowed to be negative? Yes, that is completely physical, and indeed, it is allowed to be negative and forces and all are calculated without problems in the code. But how should loss factor be calculated in such cases? I am not sure, the theory behind the tip loss function should be studied. But until then, treating negative phi as zero (or in better words, assigning phi a value that would not blow f calculation up) just for the f calculation looks like a possible remedy to me. My correction does not affect the phi value used in other parts of the code, correct me if I am wrong?

@petebachant
Copy link
Collaborator

hmmm I'm not quite sure what's going on then. The test is setup to make sure that the loss factor at the tip is between 0 and 0.5, and with your modification it is 1.0, i.e., no tip loss.

@hcOnel
Copy link
Author

hcOnel commented Jul 30, 2019

Hmm. I've checked the results of the problematic simulation which caused me to do this modification. I am getting pretty reasonable end_effect_factor (which is written to postProcessing/actuatorLineElements) values by using the modification I have proposed. Here is an example:
a
This is from a turbine which is within the wake region of an upstream turbine. phi value becomes less than zero due to wake effect.
I am really puzzled by the fact that it exceeds 0.5 in your test case. Can it be something related to that specific case?

@petebachant
Copy link
Collaborator

Your plot seems correct. This is going to take a bit more investigation. The test case is a single standalone turbine, so I don't know off the top of my head why it would be failing like that. I'll need to plot the distribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants