2017-12-15 23:47 GMT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002649OpenFOAMFeaturepublic2017-08-22 14:56
Reportervm 
Assigned Tohenry 
PrioritylowSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformGNU Linux OSUbuntuOS Version16.04
Product Version4.1 
Target VersionFixed in Version 
Summary0002649: View factors - area weighting for temperature
DescriptionThe 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
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0008508

vm (reporter)

It's not a patch, it's a bug. I am sorry for the mistake.

~0008511

henry (manager)

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.

~0008512

vm (reporter)

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.

~0008513

henry (manager)

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).

~0008530

vm (reporter)

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]);

~0008531

henry (manager)

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.

~0008532

vm (reporter)

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];

~0008533

henry (manager)

Keeping the name T for T4 would lead to a lot of confusion, surely it would be better to rename the variable?

~0008534

henry (manager)

Please test commit 3371769d784a19402891cd661c53d9413155aef0 and let me know if this resolves the issue.

~0008553

henry (manager)

Could you let me know if commit 3371769d784a19402891cd661c53d9413155aef0 fixes the problem? If so I will make the same change to OpenFOAM-5.x

~0008558

vm (reporter)

Sorry for he delay, I will take a look into it this weekend. Sorry for the inconvenience.

~0008601

henry (manager)

Should I keep this report open, close it or revert the change?

~0008603

vm (reporter)

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.

~0008604

henry (manager)

Just do a

git pull

in OpenFOAM-dev and you should get this commit and all the more recent patches.

~0008615

henry (manager)

I assume this issue is now resolved, please re-open if there are further problems.
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History