#### View Issue Details

ID Project Category View Status Date Submitted Last Update 0002649 OpenFOAM Feature public 2017-08-04 10:05 2018-02-26 14:07 vm henry low minor always resolved fixed GNU Linux Ubuntu 16.04 0002649: View factors - area weighting for temperature The current computation of the temperature average in the view factors model is as follows: Tave[coarseI] += (Tp[facei]*sf[facei])/area; Because of radiation considerations, it should be done with T^4, instead of linear weighting. It means: Tave[coarseI] += (pow(Tp[facei], 4.0)*sf[facei])/area; (...) Tave[coarseI] = pow(Tave[coarseI], 0.25); Or maybe it would be wise to keep Tave^4 and not doing the fourth root at the end of the computation. Afterwards, the needed variable to set the system is Tave^4. To justify this, I give you an example: imagine two equal surface elements which have been agglomerated at T1 and T2. The energy they are emitting is: Qr = epsilon * sigma * T1^4 * S/2 + epsilon * sigma * T2^4 * S/2 = epsilon * sigma * (T1^4 + T2^4)/2 * S. This energy should be the same that the one emitted by the whole element. Therefore, the averaged temperature should be T*^4 = (T1^4 + T2^4)/2 Instead of the current implementation of T* = (T1 + T2)/2. If there is anything wrong with this idea, I'd love to know it. Best regards, Victor Manuel No tags attached.

#### Relationships

 has duplicate 0002859 closed henry Calculation of average agglomerate temperature in viewFactor.C shoul incorporate power 4 weighting

#### Activities

 2017-08-04 10:12 reporter   ~0008508 It's not a patch, it's a bug. I am sorry for the mistake. 2017-08-04 12:12 manager   ~0008511 I have not studied the code but it seems to me that it would be better if the temperature were not averaged at all and instead the heat fluxes combined. In particular if epsilon is non-uniform it would need to be included in the temperature to ensure consistency of Qr. 2017-08-04 14:28 reporter   ~0008512 The equation being solved needs to split the emissivity from the temperature in order to compute Qr in both cases. That is why it is also needed the average temperature and emissivity. In my particular case, involving shadows, the use of one or other approaches to average the temperature makes a huge difference. I have not dug into the non-constant emissivity case. 2017-08-04 15:25 manager   ~0008513 Can you provide a patch for this change? Note that the pow4 and pow025 functions provided is OpenFOAM are likely to be faster than pow(?, 4.0) and pow(?, 0.25). 2017-08-07 09:16 reporter   ~0008530 It is just changing from line 455 to line 462 in radiationModels.C (openFOAM-dev), to these lines:     // Temperature, emissivity and external flux area weighting     forAll(fineFaces, j)     {         label facei = fineFaces[j];         Tave[coarseI] += (pow4(Tp[facei])*sf[facei])/area;         Eave[coarseI] += (eb[facei]*sf[facei])/area;         Hoiave[coarseI] += (Hoi[facei]*sf[facei])/area;     }     Tave[coarseI] = pow025(Tave[coarseI]); 2017-08-07 10:11 manager   ~0008531 There is no file radiationModels.C in openFOAM-dev. Wouldn't it be better to store Tave^4 rather than storing Tav: > Or maybe it would be wise to keep Tave^4 and not doing the fourth root at the end of the computation. Afterwards, the needed variable to set the system is Tave^4. 2017-08-07 10:20 reporter   ~0008532 Yes, sorry, I meant viewFactors.C. And it is also true that it is better store Tave^4. Those are the changes: line 459 from: Tave[coarseI] += (Tp[facei]*sf[facei])/area; to   Tave[coarseI] += (pow4(Tp[facei])*sf[facei])/area; line 536 physicoChemical::sigma.value()*pow(T[j], 4.0); to physicoChemical::sigma.value()*T[j]; line 593 *pow(T[j], 4.0); to *T[j]; 2017-08-07 10:55 manager   ~0008533 Keeping the name T for T4 would lead to a lot of confusion, surely it would be better to rename the variable? 2017-08-07 10:59 manager   ~0008534 Please test commit 3371769d784a19402891cd661c53d9413155aef0 and let me know if this resolves the issue. 2017-08-10 14:02 manager   ~0008553 Could you let me know if commit 3371769d784a19402891cd661c53d9413155aef0 fixes the problem? If so I will make the same change to OpenFOAM-5.x 2017-08-10 15:21 reporter   ~0008558 Sorry for he delay, I will take a look into it this weekend. Sorry for the inconvenience. 2017-08-17 14:59 manager   ~0008601 Should I keep this report open, close it or revert the change? 2017-08-18 08:39 reporter   ~0008603 I tried to install the particular commit you told me and I was not able to do so. I would appreciate any help with it. Thank you. 2017-08-18 08:53 manager   ~0008604 Just do a git pull in OpenFOAM-dev and you should get this commit and all the more recent patches. 2017-08-22 14:56 manager   ~0008615 I assume this issue is now resolved, please re-open if there are further problems.

#### Issue History

2017-08-04 10:05 vm New Issue
2017-08-04 10:12 vm Note Added: 0008508
2017-08-04 10:43 henry Category Patch => Feature
2017-08-04 12:12 henry Note Added: 0008511
2017-08-04 14:28 vm Note Added: 0008512
2017-08-04 15:25 henry Note Added: 0008513
2017-08-07 09:16 vm Note Added: 0008530
2017-08-07 10:11 henry Note Added: 0008531
2017-08-07 10:20 vm Note Added: 0008532
2017-08-07 10:55 henry Note Added: 0008533
2017-08-07 10:59 henry Note Added: 0008534
2017-08-10 14:02 henry Note Added: 0008553
2017-08-10 15:21 vm Note Added: 0008558
2017-08-17 14:59 henry Note Added: 0008601
2017-08-18 08:39 vm Note Added: 0008603
2017-08-18 08:53 henry Note Added: 0008604
2017-08-22 14:56 henry Assigned To => henry
2017-08-22 14:56 henry Status new => resolved
2017-08-22 14:56 henry Resolution open => fixed
2017-08-22 14:56 henry Note Added: 0008615
2018-02-26 14:07 will Relationship added has duplicate 0002859