View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001847 | OpenFOAM | Bug | public | 2015-09-05 10:26 | 2018-09-13 23:44 |
| Reporter | Assigned To | wyldckat | |||
| Priority | low | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | GNU/Linux | OS | OpenSuSE | OS Version | 12.3 |
| Summary | 0001847: actuationDiskSourceTemplates.C - Calculation of Usource and sign convention | ||||
| Description | Hello, 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. | ||||
| Tags | No tags attached. | ||||
|
|
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". |
|
|
Hello, 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
|
|
|
|
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, Bruno |
|
|
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! |
|
|
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, Bruno |
|
|
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
|
|
|
|
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, Bruno |
|
|
@wyldckat Anything happening on this report? |
|
|
@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. |
|
|
No feature update forthcoming from the community. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-09-05 10:26 |
|
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 |
|
Note Added: 0005337 | |
| 2015-09-06 18:39 |
|
Status | closed => feedback |
| 2015-09-06 18:39 |
|
Resolution | no change required => reopened |
| 2015-09-06 18:42 |
|
File Added: actuationdisk.png | |
| 2015-09-06 21:58 | wyldckat | Note Added: 0005339 | |
| 2015-09-06 22:12 |
|
Note Added: 0005340 | |
| 2015-09-06 22:12 |
|
Status | feedback => assigned |
| 2015-09-06 22:13 |
|
Note Edited: 0005340 | |
| 2015-09-06 22:23 |
|
Note Edited: 0005340 | |
| 2015-09-07 07:48 |
|
Note Edited: 0005340 | |
| 2015-09-12 13:28 | wyldckat | Note Added: 0005353 | |
| 2015-09-16 20:51 |
|
Note Added: 0005360 | |
| 2015-09-16 20:53 |
|
File Added: pos_and_negxcases.zip | |
| 2015-09-16 20:54 |
|
Note Edited: 0005360 | |
| 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 |
