View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001740 | OpenFOAM | Bug | public | 2015-06-13 11:17 | 2015-06-17 00:10 |
| Reporter | zfaraday | Assigned To | henry | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | GNU/Linux | OS | OpenSuSE | OS Version | 12.3 |
| Summary | 0001740: fvDOM: invalid results for Qr when nTheta is an odd number | ||||
| Description | After some tests I found out that giving nTheta in radiationProperties an even value the results obtained seem to be realistic. However, when an odd number is given to nTheta, the results turn to something strange and not physical. Take a look at this post for a detailed explanation: http://www.cfd-online.com/Forums/openfoam-bugs/153680-possible-bug-fvdom-when-odd-number-ntheta-used.html#post548424 In the post above you will also find a simple test case I used in order to test this behavior (a modified version of the circuitBoardCooling tutorial). An Excel file with some results I got from some tests can also be found. | ||||
| Steps To Reproduce | 1. Download and unzip the test case provided in the mentioned post. 2. Check that 3D option is selected in the Allrun script. 3. Open the file "constant/radiationProperties" and try to give nTheta even/odd numbers. 4. Run the case with the Allrun script. Some libraries from swak4foam are loaded in controlDict in order to use some funtion objects. In case the run crashes, just coment out the functions and libraries subdicionaries within the controlDict file. | ||||
| Tags | No tags attached. | ||||
|
|
Could you provide a test-case here which is not dependent on exernal libraries? Also could you provide a patch which fixes the problem? |
|
|
|
|
|
I just uploaded the test case modified to be used without the external libraries. It should work normally now. With regard to the patch, I'm sorry that I can't provide any since my knowledge of C++ is a little weak. I looked into the code some days ago in order to find some hint but I couldn't see anything suspicious. However, I have some ideas that may be useful: ·Maybe a good solution would be to use a number of polar angles of 2*nTheta instead of nTheta to prevent from using an odd number of nTheta divisions. Thus, the number of rays would be 8*nPhi*nTheta. I have no idea if it would be a solution of big complexity when it comes to implementation. In case it is, ·A mention of this issue in the documentation of the method would do the trick provisionally. |
|
|
Clearly we could ensure that nTheta is even in some way either by constraining or checking the input or doubling the number entered as you suggest but why should nTheta be even? |
|
|
Well, essentially I think it shouldn't be even by force, the problem is that when nTheta becomes odd the fact that a set of rays belongs to the xy plane has a weird effect on the results. You can check the results I got in a set of tests in the Excel file attached in the link added to the description. When nTheta is even the results over the system look physical, but when nTheta has an odd value the results are totally meaningless! It might be a coding bug or something, but I couldn't find it out by myself. That's why I think that the fastest solution to improve it is to force nTheta being even somehow. |
|
|
This is an interesting bug report, because I have used odd number for nTheta in many cases but I have not encountered such issues. However, in my cases there has always been quite a lot of absorbtion/emission in the gas, so that may explain why this has not affected me. I don't think the issue is a coding bug as such, but as zfaraday said, just due to the fact that with odd nTheta some of the rays align perfectly with the walls and thus the walls don't emit/absorb them. For example, if nTheta is 3, then 2/3 of the rays are parallel to floor and ceiling (ray z-component=+-1) and thus "invisible" to them. I guess at least in simple cases the walls are often aligned with coordinate axes. However, if there is absorbtion/emission/scattering in the gas, then the situation is not so bad. |
|
|
Would you also recommend that we ensure nTheta is even? |
|
|
I'm not sure. I think it would be a good practice not to have rays aligned with axes/walls to avoid such issues, but I'm not sure if it has to be forced or is it just something that the user should know. I'm fairly new with radiation, so I don't know what belongs to "everybody should know about" section. One benefit of having (at least some of the) rays align with axes is that then the discretization error is probably smaller with structured grids. |
|
|
I will close this report for now and recommend that users of the fvDOM functionality test the sensitivity of their results to the choice of number and distribution of rays and select accordingly. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-06-13 11:17 | zfaraday | New Issue | |
| 2015-06-13 12:24 | henry | Note Added: 0004919 | |
| 2015-06-13 12:47 | zfaraday | File Added: circuitBoardCooling_rad.zip | |
| 2015-06-13 13:02 | zfaraday | Note Added: 0004920 | |
| 2015-06-13 13:02 | zfaraday | Note Edited: 0004920 | |
| 2015-06-13 13:20 | henry | Note Added: 0004921 | |
| 2015-06-13 17:36 | zfaraday | Note Added: 0004922 | |
| 2015-06-16 11:52 | tniemi | Note Added: 0004951 | |
| 2015-06-16 11:53 | tniemi | Note Edited: 0004951 | |
| 2015-06-16 11:54 | tniemi | Note Edited: 0004951 | |
| 2015-06-16 12:02 | henry | Note Added: 0004952 | |
| 2015-06-16 12:13 | tniemi | Note Added: 0004953 | |
| 2015-06-16 12:39 | henry | Note Added: 0004954 | |
| 2015-06-16 12:39 | henry | Status | new => closed |
| 2015-06-16 12:39 | henry | Assigned To | => henry |
| 2015-06-16 12:39 | henry | Resolution | open => no change required |
