View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002649OpenFOAMFeaturepublic2017-08-04 10:052018-02-26 14:07
Reportervm Assigned Tohenry  
PrioritylowSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU Linux OSUbuntuOS Version16.04
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.

Relationships

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

Activities

vm

2017-08-04 10:12

reporter   ~0008508

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

henry

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.

vm

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.

henry

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

vm

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

henry

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.

vm

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

henry

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?

henry

2017-08-07 10:59

manager   ~0008534

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

henry

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

vm

2017-08-10 15:21

reporter   ~0008558

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

henry

2017-08-17 14:59

manager   ~0008601

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

vm

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.

henry

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.

henry

2017-08-22 14:56

manager   ~0008615

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

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
2018-02-26 14:07 will Relationship added has duplicate 0002859