View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001636 | OpenFOAM | [All Projects] Bug | public | 2015-03-25 14:19 | 2015-12-03 15:35 |
| Reporter | tniemi | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0001636: Questions/issues related to lagrangian radiation models and fvDOM | ||||
| Description | I have several questions/issues related to lagrangian radiation models and fvDOM: 1. Should the radiative heat transfer in ThermoParcel.C be conservative? The reason for asking is that I don't understand the modifications done to the ap and bp terms in calcHeatTransfer. Should the dhsTrans caused by radiation exactly correspond to the radAreaPT4() computations in calc? To me it seems that there might be a problem, as in calc the radiation is computed from the new temperature instead of the old/average temperature used in calcHeatTransfer? I'm using analytic integration. Anyhow I had some conservation issues, but I was able to eliminate them by assuming a constant parcel temperature for radiation and using T0 temperature in calc when computing radArea terms. I have attached my modifications. (radArea calculation should be modified in every parcel above Thermo) I understand that in case of large temperature changes, this approximation may not be very good, but at least it is conservative. 2. In radiativeIntensityRay.C, correct(), the ECont term is divided with 4 in the IiEq. However, is this division necessary, because if I understand correctly, ECont should already represent 1/4 of the emissions? (in P1.C E_ is multiplied with 4 to get everything) 3. Is it so that the fvDOM radiation model does not work with lagrangian radiation? It seems to only use absorption terms and ignores EDisp. Also Rp and Ru terms do not seem to be correct? I have attached a modified version, which takes into account the particle emissions in ray equations and also removes parcel absorption/emission from Rp and Ru terms. The modifications seem to work ok in my test cases. | ||||
| Tags | No tags attached. | ||||
|
|
fvDOM.C (14,314 bytes) |
|
|
radiativeIntensityRay.C (7,717 bytes) |
|
|
ThermoParcel.C (10,001 bytes) |
|
|
Lagrangian has not been tested with fvDOM and there are no tutorial examples. Thanks for the patches, I will study them and get back to you. It would be very useful to have a simple tutorial case to test radiative heat transfer with Lagrangian tracking; could you propose or provide something suitable? |
|
|
I am looking into including these patches but ideally need a test-case, do you have something suitable? |
|
|
> 1. Should the radiative heat transfer in ThermoParcel.C be conservative? Having conservation at every iteration would be good unless it compromises convergence. Often a non-conservative semi-implicit approach is applied for stability and conservation is achieved at convergence which may require several iterations. If there is no stability issue then a conservative explicit approach is fine. > 2. In radiativeIntensityRay.C I think your analysis is correct. > 3. Is it so that the fvDOM radiation model does not work with lagrangian > radiation? Correct, I have applied your changes to OpenFOAM-dev: commit d8f45cf8c1232f9be0932501148c1416e77011ef I do not have a test-case to check the merge of these patches, could you test and report back? |
|
|
Hi Sorry for my inactivity, I have been very busy doing other stuff. > I do not have a test-case to check the merge of these patches, could you test and report back? I have checked the patches and they seem to be ok. Unfortunately, I don't have a good stand-alone test case either, but we have used this formulation for a while without any issues. So in my opinion the commit is ok. However, the modification "this->T_ -> T0" in the "Update radiation fields" step in ThermoParcel.C calc should also be applied to ReactingParcel and ReactingMultiphaseParcel, since they also do the same calculation in their calc funtions. |
|
|
Resolved by commit 6f5936b373a5e5456eae2f5ad79d4472e95eee2b |
|
|
In radiativeIntensityRay.C, if the absorptionEmission_.ECont is not divided by 4, then the incident radiation flux on a surface, Qin, is 4 times larger than previously. This goes against all of the validation that we have done over the last 8 years for flame radiation on surfaces. + absorptionEmission_.ECont(lambdaI)/4 |
|
|
Hi karlvirgil, In order to get the same results as before, you would have to redefine your ECont to be 1/4 th of the value it was before the change, as ECont is now defined to be 1/4 th of the total emission. The reason why I suggested this change was that it would make the P1 and fvDOM models consistent. In P1 model the E is multiplied by four and it is therefore assumed that E is defined as 1/4 th of the total emissions. However, in the original fvDOM implementation E was assumed to represent the total emissions and for that reason it was divided by four (the division is required, because the sum of omegas over all rays is 4*pi). This is ok, but the different definition of E meant that it would not be possible to use the same ECont model for both radiation models. One could argue, that the it would be more logical to define ECont without the 1/4 th division. However, then the P1 model would have to be changed. Also the lagrangian cloudAbsorptionEmission currently assumes that EDisp represents 1/4 th of the total emissions. However, as I looked through the code I noticed a bug that the change has caused, which I didn't notice before. In fvDOM.C in Ru(), the expression should now be a*G - 4.0*E; (the same as in P1), because E is only 1/4 th of the total emissions now. |
|
|
Hi karlvirgil, in your validation cases, have you used either greyMeanSolidAbsorptionEmission or wideBandAbsorptionEmission models or have you used your own custom absorbtionEmission model? I realized that the greyMeanSolidAbsorptionEmission and wideBandAbsorptionEmission models can use ECont and those models also assume that ECont represents the total emission per surface area. This means, that they assume that ECont should be divided by 4. To summarize I think there are now two problems: the greyMeanSolidAbsorptionEmission and wideBandAbsorptionEmission use a different definition of ECont than the radiation models and the ECont term in fvDOM Ru function is currently missing the multiplier. In order to fix these, I can come up with 3 alternatives: 1. Keep ECont defined as it is now, meaning it is emission per projected area/cross sectional area. Fix the bug in fvDOM Ru (multiply ECont by 4) and modify the greyMeanSolidAbsorptionEmission and wideBandAbsorptionEmission so that ECont is divided by 4 there. No modification necessary for P1 or lagrangian models. 2. Define ECont to be the total emission per surface area as it was before in fvDOM. Divide it by 4 in fvDOM, split the E term in P1 and move out the ECont part so that it is not multiplied by 4 (EDisp has to be multiplied). Remove also the multiplication from the Ru function in P1. 3. Define both ECont and EDisp to be the total emission per surface area, apply multiplication by 4 in cloudAbsorptionEmission model (the only place that uses EDisp?). Do not multiply E in P1 at all, divide both ECont and EDisp in fvDOM. Personally for me it doesn't matter how the ECont is defined, but in my opinion it would be good that ECont has the same definition in both radiation models. Also in options 1 and 3 there is the additional benefit that ECont and EDisp have the same units and can be divided/multiplied in the same way. |
|
|
I have applied option 3 provided by Timo to OpenFOAM-dev: commit a3301464bd6b110b8e32fa8e123df4c55548d420 Let me know if this is satisfartory and if so I will also apply the correction to OpenFOAM-3.0.x. |
|
|
Hi tniemi and henry. Ankur, my colleague who is well versed in the radiation portions of OpenFOAM, will be responding to this thread shortly with what we perceive as the best solution. |
|
|
Hello, It would be logical to define Econt and EDisp as the total emission per unit volume, as suggested in the option 3 in tniemi's post. The definition of ECont and EDisp as total emission divided by 4 is rather confusing, and would make the code hard to follow. -Ankur |
|
|
I have already applied option 3 provided by Timo to OpenFOAM-dev, could you please test it and let us know if it is satisfartory? |
|
|
I'll test it today and let you know. |
|
|
After running a few tests, these changes appear to be satisfactory. |
|
|
Resolved in OpenFOAM-3.0.x by commit df1ea7d5e5035a2628e20ef4b08527f9d4f9a8f7 Resolved in OpenFOAM-dev by commit a3301464bd6b110b8e32fa8e123df4c55548d420 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-03-25 14:19 | tniemi | New Issue | |
| 2015-03-25 14:19 | tniemi | File Added: fvDOM.C | |
| 2015-03-25 14:20 | tniemi | File Added: radiativeIntensityRay.C | |
| 2015-03-25 14:20 | tniemi | File Added: ThermoParcel.C | |
| 2015-03-27 15:25 | henry | Note Added: 0004498 | |
| 2015-05-26 11:48 | henry | Note Added: 0004812 | |
| 2015-06-12 15:43 | henry | Note Added: 0004917 | |
| 2015-06-15 14:11 | tniemi | Note Added: 0004925 | |
| 2015-06-15 17:43 | henry | Note Added: 0004934 | |
| 2015-06-15 17:43 | henry | Status | new => resolved |
| 2015-06-15 17:43 | henry | Resolution | open => fixed |
| 2015-06-15 17:43 | henry | Assigned To | => henry |
| 2015-11-19 21:57 | henry | Status | resolved => feedback |
| 2015-11-19 21:57 | henry | Resolution | fixed => reopened |
| 2015-11-30 15:03 | karlvirgil | Note Added: 0005691 | |
| 2015-12-01 09:07 | tniemi | Note Added: 0005698 | |
| 2015-12-01 09:07 | tniemi | Status | feedback => assigned |
| 2015-12-01 09:11 | tniemi | Note Edited: 0005698 | View Revisions |
| 2015-12-01 14:46 | tniemi | Note Added: 0005705 | |
| 2015-12-01 16:24 | henry | Note Added: 0005708 | |
| 2015-12-01 18:24 | karlvirgil | Note Added: 0005710 | |
| 2015-12-01 19:53 |
|
Note Added: 0005711 | |
| 2015-12-01 22:18 | henry | Note Added: 0005712 | |
| 2015-12-02 13:50 | karlvirgil | Note Added: 0005717 | |
| 2015-12-03 14:40 | karlvirgil | Note Added: 0005719 | |
| 2015-12-03 15:35 | henry | Note Added: 0005720 | |
| 2015-12-03 15:35 | henry | Status | assigned => resolved |
| 2015-12-03 15:35 | henry | Resolution | reopened => fixed |
