View Issue Details

IDProjectCategoryView StatusLast Update
0001847OpenFOAM[All Projects] Bugpublic2018-09-13 23:44
Reporteruser1231Assigned Towyldckat 
Status closedResolutionfixed 
PlatformGNU/LinuxOSOpenSuSEOS Version12.3
Product Version 
Fixed in Version 
Summary0001847: actuationDiskSourceTemplates.C - Calculation of Usource and sign convention

in "actuationDiskSourceTemplates.C" the "thrust" is calculated using
T = 2.0*upRho*diskArea_*mag(upU)*a*(1 - a)
and is always positive.
Calculating the Usource, which represents the real trust from disk to fluid (F=rho*U*(n&U)A) this results in:
Usource[cells[i]] += ((Vcells[cells[i]]/V())*T*E) & upU

With uniDiskDir(1 0 0) and upU(1 0 0) the Usource becomes
positive and makes the source in the Ueqn
-Usource negative.
This is correct.

Second case: If, uniDiskDir is still (1 0 0) and upU is changing to (-1 0 0),Usource becomes negativ and the force in Ueqn is pointing in positive x-direction. Still correct.

But if user puts in negative values in uniDiskDir(-1 0 0) the Usource has wrong sign. Shouldn't the disk act as a turbine in both directions?

Then one could use positive values of the magnitude of the vector:
vector uniDiskDir = diskDir_/mag(diskDir_);
tensor E(tensor::zero);
E.xx() = mag(uniDiskDir.x());
E.yy() = mag(uniDiskDir.y());
E.zz() = mag(uniDiskDir.z());
With this, upU would produces always the correct direction of thrust (source) acting from disk to fluid.

TagsNo tags attached.


related to 0001681 closedwyldckat Actuator disks add instead of reducing momentum. This is solved by changing the disk 180 degrees,but then 'diskDir' is not right 
related to 0003072 new wrong sign in actuationDiskSource if velocity components of upstream velocity are of different sign 



2015-09-05 15:05

updater   ~0005334

I've been looking into this now, for trying to diagnose and possibly fix #1681.

The problem with the change you propose is that this:

  E.xx() = mag(uniDiskDir.x());
  E.yy() = mag(uniDiskDir.y());
  E.zz() = mag(uniDiskDir.z());

will not result in what you're proposing, since that will distort originally the intended direction. For example, "-1,1,0" would be interpreted as "1,1,0", which is perpendicular to the desired direction.

As for the actuation disk or turbine to work in both directions when the flow reverses: usually that's not that simple. Physically, the blades of the turbine would have to change direction as well, so that it would rotate in the correct direction; such a scenario falls in the same criteria as dynamically turning turbine towers, for following the wind direction, which is not contemplated by this fvOption.

I'll close this task as "no change required".


2015-09-06 18:39



I had a re-think of the actuation disk source algorithm and took paper and pencil... I think, this will work.
I will attach it.


2015-09-06 18:42


actuationdisk.png (614,839 bytes)


2015-09-06 21:58

updater   ~0005339

Hi anru,

After digesting your handwritten description, if I understood it correctly, there is one critical flaw: if the flow reverses in the upstream point, that means that the thrust will be miscalculated entirely, because the point effectively becomes a downstream point and it's where the flow should be lower than on the upstream side.

What is missing from your suggestion is that a second point would have to be defined to be used as the alternative upstream point.
But the problem is how this physically can happen: for the flow to reverse entirely, there will be a point in time where the flow is somewhat parallel to the turbine... in which situation, it might not be possible to properly define what is the correct upstream point, due to ambiguity.

In other words, what perhaps you're not taking into account is that the current implementation is an approximation, which relies on a single upstream velocity at a single point, which is used for the thrust calculation. For a proper calculation, the whole surface upstream-adjacent should be measured... which requires a lot more details and calculations.

Best regards,


2015-09-06 22:12


Last edited: 2015-09-07 07:48

View 4 revisions

Hi Bruno,

thanks for your comment.

Yes, a second point should be introduced, this is what I mean with the last sentence "...straight forward...".
But this is not too hard to implement.

Second, the case with the parallel flow. Just take the mean average (of cosphi) of both points. And since the flow is almost parallel to disk, no thrust is acting onto the fluid and the error is neglectable. It is just a disk or turbine without yaw mechanism.

Last remark: If the power is calculated out of Usource(thrust), it has to be corrected again with cosphi!


2015-09-12 13:28

updater   ~0005353

Hi anru,

The calculations with cosine does make it easier to think about the mathematics, but the matrix-vector approach will probably still continue to be used, since it's faster than calculating the cosine.

Nonetheless, implementing the source code is one thing, testing is another. Can you provide one or a few small test cases for testing such an implementation?

Best regards,


2015-09-16 20:51


Last edited: 2015-09-16 20:54

View 2 revisions

Hello Bruno,

I configured a zip with:
1. standard turbine sitting case
2. standard turbine sitting case with reversed flow condition and reversed normal disk dir.

In the second case, the turbines are pumping. I tested it with the cosphi implementation and this does it correct.

One note to your remark, a cosine approach is expensive. Well, it is one calculation. Compared to the "number crunching part" like the vector matrix multiplication in a solver, you can neglect the time!
If speed is a concern, I would think about other code parts in OpenFoam.


2015-09-16 20:53 (795,875 bytes)


2015-09-27 20:55

updater   ~0005372

Hi anru,

Many thanks for the test cases! It will take a while until this is better looked into.
But I do have a question: from your experiences, have you seen whether the upstream points are really needed?
Or better yet, what is the selection criteria for these upstream points?

I ask this because simply defining the "working vector" (usually the normal to the disk) could be enough, as the upstream points could be deduced based on the general direction and perhaps the dimension of the region defined for the source term?

Best regards,


2017-06-30 10:52

manager   ~0008297

@wyldckat Anything happening on this report?


2017-06-30 11:02

updater   ~0008300

@chris: My apologies for keeping this assigned to me, but unfortunately no, there isn't anything happening on this for now.
I haven't had time to properly look into this and make a general implementation that didn't have potential blind spots. And I don't have a time estimate either.
And I didn't properly analyse the proposed modification either, so I'm not 100% certain if this approach is appropriate or not.

I leave it up to you on whether this should be unassigned, re-assigned or simply closed as a 'suspended' feature.


2017-06-30 13:01

manager   ~0008314

No feature update forthcoming from the community.

Issue History

Date Modified Username Field Change
2015-09-05 10:26 user1231 New Issue
2015-09-05 12:19 wyldckat Relationship added related to 0001681
2015-09-05 15:05 wyldckat Note Added: 0005334
2015-09-05 15:06 wyldckat Status new => closed
2015-09-05 15:06 wyldckat Assigned To => wyldckat
2015-09-05 15:06 wyldckat Resolution open => no change required
2015-09-06 18:39 user1231 Note Added: 0005337
2015-09-06 18:39 user1231 Status closed => feedback
2015-09-06 18:39 user1231 Resolution no change required => reopened
2015-09-06 18:42 user1231 File Added: actuationdisk.png
2015-09-06 21:58 wyldckat Note Added: 0005339
2015-09-06 22:12 user1231 Note Added: 0005340
2015-09-06 22:12 user1231 Status feedback => assigned
2015-09-06 22:13 user1231 Note Edited: 0005340 View Revisions
2015-09-06 22:23 user1231 Note Edited: 0005340 View Revisions
2015-09-07 07:48 user1231 Note Edited: 0005340 View Revisions
2015-09-12 13:28 wyldckat Note Added: 0005353
2015-09-16 20:51 user1231 Note Added: 0005360
2015-09-16 20:53 user1231 File Added:
2015-09-16 20:54 user1231 Note Edited: 0005360 View Revisions
2015-09-27 20:55 wyldckat Note Added: 0005372
2017-06-30 10:52 chris Note Added: 0008297
2017-06-30 11:02 wyldckat Note Added: 0008300
2017-06-30 13:01 chris Status assigned => closed
2017-06-30 13:01 chris Resolution reopened => fixed
2017-06-30 13:01 chris Note Added: 0008314
2018-09-13 23:44 wyldckat Relationship added related to 0003072