Trying to validate fvDOM and view factors methods
 

Hello foamers,

Recently I have been testing a couple of new features added to OpenFOAM, such as the inclusion of the frozenFlow functionality in the chtMultiRegion solvers. I tested it in a test case I used to use for a radiation heat transfer test case.

Then, after I tested it successfully for the view factors method, I decided to use fvDOM method instead in order to prove that both gave out similar results. I did it because I wasn't pretty sure to understand how this method (fvDOM) works and what is the proper set up in the radiationProperties file.

The geometry of the test case can be seen in the attached picture. It consists of a baffle (superficial) heater that heats up the domain made up of a solid cubic object and a region of air in vaccum conditions. All boundary walls for the air region are isolated except the one shown in grey in the picture which is tranferring heat to the environment by convection.


As it can be expected, both methods should give out similar results. However, not only both methods didn't give similar results, but the results were very far away one from another (more than 500ºC). I attached a couple of graphics showing the results for both cases so that you can evaluate it.

At this stage, I don't know what I am doing wrong, I guess the problem is my radiationProperties setup for the fvDOM case but I don't know because I'm not aware of the meaning of each parameter to be defined in there. I share here my test case just in case you need it to check the steps I followed. I also upload my fvDOM radiationProperties file so that you can see what I am doing wrong.

I would really appreciate that someone could give me an answer because now I'm quite disoriented since it makes no sense to me this extremelly big difference between both methods.

Many thanks in advance.


Regards,

Alex
-------------------------------------------------------------------------------------------------
Note: Values of Ti in both graphics are taken from each face center of the cubic object being:
·T1 the lower face,
·T2 the upper face,
·T3 the left face (x<0),
·T4 the right face (x>0),
·T5 the nearest face parallel to the baffle and
·T6 the furthest face
-------------------------------------------------------------------------------------------------

I found out something I was doing wrong in the fvDOM case. As I adapted the case from the viewFactors one I forgot to delete/comment Qr definition in the system/changeDictionaryDict file. It lead the solver to calculate Qr on every patch as 0. Once I commented it in the changeDictionatyDict it calculated "properly" the Qr field. I wrote "properly" because, although now the temperature distribution is qualitatively similar to the one obtained with the viewFactors method, it's not even quantitatively comparable. With fvDOM temperature values rise up like 400ºC above the values obtained with viewFactors method. You can see both distributions in the pictures attached.

I need some help to understand what I am doing wrong in the setup of the fvDOM method (I assume that my problem comes from the fvDOM case, but maybe it may come from the viewFactors setup also). I would really appreciate any hint you can give me.

Thanks in advance,

Alex

I don't want to be annoying but I'm in the need of pushing a little to get an answer. Can anyone tell me why am I getting so different results with both methods? What am I doing wrong? Which is the correct setup (for both methods) for the radiation calculation (if there's any... :( )?

Please, I need some hint... Looking forward to your answers.

Alex

What absorptivities did you use for fvDOM?
Keep in mind that in the discrete ordinate model the air can absorb radiation and thus heat up, while this is not the case as far as I know for view factors method.

Thanks for your answer chriss85. I used exactly the same specifications in both simulations except the fact that one calculates radiation with viewFactors method and the other one with fvDOM (both with no absorptionEmision model). In the first post you can find a link to the complete case setup for ViewFactors and the radiationProperties file I used for the FvDOM simulation.

I don't know if you may see if I specified something wrong somewhere...

Thanks again.

Alex

What boundary conditions do you use for the radiation? In your initial post you only talked about the boundaries for temperature. Maybe you can find a difference there.

These are my boundary conditions extracted from changeDictionaryDict files:

·fvDOM:
·viewFactors:
I hope they are correct... Can you see any wrong definition in them? Did I miss something?

Thanks Chris

Sorry, looks fine from what I can tell. Did you try it with a simpler geometry for comparison?
Maybe without a baffle to reduce the complexity of the problem.

I can't really help you much further since I don't know much about the view factors method.

Thanks for your time Chris.

Have you some experience with the fvDOM method? If so, would you mind taking a look into my whole specification for the fvDOM case in order to check that everything is fine?

Regards.

Not much, I only used it a few times to compare it against the P1 model. In my case I got similar results.

Your boundaries and radiationProperties for DOM look fine from what I can tell (though I'm confused by the txt file ending in the attachment; needed by the forum software??).

As I said, I don't know much about baffles so I would try a case without one first, maybe simply a cube or so.

Yes, the .txt is needed to upload a text file in the forum, otherwise the uploader crashes because you cannot upload a non-formated file.

I think I will do what you suggest, try with a simple cube without the baffle and I'll see what happens in that case.

Thanks again for your time Chris!

Hi Alex,

which results are more plausible, DO or viewFactor? I'm asking because the mismatch could also be attributed to faulty view factors (the standard implementation in OF is not very accurate). Did you check them?
Besides that I would agree that your boundary conditions look reasonable. So far in my simulations with the DO model the results always seemed reasonable with similar settings.
Hannes

What's the problem with the DOM implementation accuracy?

I can't say anything about the DO implementation (from my experience that looks good), the implementation of the viewFactor is what I'm concerned about, have a look at your viewFactorField and check it for plausibility. Towards the edges and corners the current implementation tends to be not accurate enough - however, I can't tell whether that can cause such a big difference compared to the DO.

Hello Hannes!

I know that viewFactors is not a very accurate method. Regarding what you say about the viewFactorField, as far as I know, it is the sum of all the view factors in a row in the matrix, thus it should ideally be equal to 1 for each face, right? Well, as it never happens I always try to make them all be as near as possible to 1, that is to say, I adjust the parameters in the constant/"fluidRegion"/viewFactorsDict in order to get all viewFactorField within the range [0.9-1.1]. Is this process right? I hope so...

I guess the only point of inaccuracy of this method is the existence of these viewFactorFields not equal to 1. Is there anything else that contributes to its inaccuracy?

Besides, I can't believe that a difference of 400ºC between both methods can be explained by means of the viewFactorFields value range. Maybe I should get a tighter range?

Thanks Hannes for you help!

Hi Alex,
yes the viewFactorField shoul be equal to one everywhere. Where it is not the energy balance is not correct anymore (you would have a positive or negative energy source). Personally, I would try to avoid errors in the energy balance of 10 % (viewFactorField in the range of 0.9 to 1.1). Moreover, the faceAgglomeration controlled with the variables in the viewFactorsDict might also lead to unfavourable structures. All in all, my experience with the viewFactor model is that you have to be very careful about its results and that one should check everything twice. You can also have a look at a presentation from the recent OFUC (http://elib.dlr.de/91571/1/OFUC2014_...ew-factors.pdf)

However, I agree that the temperature difference between viewFactorModel and fvDOM is indeed very large and unlikely solely attributed to the view factor calculation.
I have no experience with the chtMultiRegion solver, but I would assume that the error is somewhere in the coupling between the radiative heat exchange and the heat conduction in the solid.

Regards.

Hi Hannes,

I agree with you that it would be more accurate if I reduced the viewFactorField range but I don't know exactly how to do it. I know that this is controlled by the variables in the viewFactorsDict but I dont know exactly how they do it. When I reduce the range to [0.9-1.1] I do it by trial and error (also using my intuition, looking to the patches that give me the worst values) because I'm not much aware of how the parameters work and the meaning they have. Can you give me any tip or hint about it, please? Because when I get to the range mentioned above it's almost impossible to me to keep reducing the range by trial and error...:(

Thanks for sharing the information! It's a very interesting paper. However, they say they modified the solver (or the utilities to compute viewFactors), don't they? Have you any idea how they could reach so accurate values for viewFactorField?

I don't think that the problem comes from the coupling between both regions(I can be wrong, of course) because both cases are coupled the same way, so in case of being the problem on the coupling it would be a common problem between both cases.

Thank you so much for your response!


Alex

Hi Alex,

from what I see I'm a little bit out of ideas. Concerning the DO, did you vary the angular discretisation in the radiationProperies? That could give you some indication on whether the DO simulation is appropriate or not.

Yes, the viewFactor tools have been modified. The difference is in the integration method for the view factor calculation. Where in the original code a double area integration (2AI) is implemented a siginificant improvement can be achieved by implementing a double or even a single line integration (2LI,1LI).
Moreover, it might be worthwhile to spend some time on the face agglomeration, too. Depending on your setup it could happen that for example symmetry is spoiled due to an asymmetric face agglomeration. But that one takes much more effort to improve than the implementation of a new integration method.

Hello,

I'have made a simple validation for S2S and DO some year ago, with simple geometry. The result matched perfectly (little bit less accurate with S2S).

So my advice is: Check your case without multiRegion
About your case: Take care, because multiRegion has a slow convergence, and with big radiative flux, it's going to be worst.
NB: forgot to ask, which OpenFoam version do you use. Because i've seen some bugfix in 2.3.x about multi Region BC.

regards,
olivier

Hi Alex,

Could you provide a copy of the validation test case you used?

Hi Alex,

did you ever tried to change the number of rays for your fvDOM calculation?
In your posted radiationProperties i can see your nPhi is 3 and your nTheta is 5, that's ok but that will not give you a uniformly field of rays.
nPhi are the number of rays over 90° azimuthal
nTheta over 180° polar
So if you want to solve the field equidistant it is more useful to take 2*nPhi for the nTheta value.
When you rise the number of rays the failure you make by simplify the radiation field with a definite number of rays will decrease.

The other question is: why do you have defined G?
The G BC is only used in the P1 model.
IDefault is for fvDOM an Qr for viewFactor model.
The generated fields differ to that.

best regards

Robin

Hi Robin,

Thanks for your insight and your advices.

Some days ago I found that chosing an odd number of nTheta provokes an unexpected behavior in the radiation calculation. See a deep analysis here and feel free to respond if you have some knowledge on the matter.

With regard to the definition of G in the fvDOM, I didn't know it was not necessary to define it! I have always done it because I started my fvDOM calculations with the "hotRadiationRoomFvDOM" tutorial under "tutorials/heatTransfer/buoyantSimpleFoam" and, if you take a look into that case, you will see that G is also specified...:confused: Besides that, if you execute the following command in the terminal:
you will see all the tutorials that use fvDOM in the radiation calculation. You can check that all tutorials shown have G defined but only one ("flameSpreadWaterSuppressionPanel") that it doesn't. However, after I read your advise about the unnecessity to define G when using fvDOM, I immediately ran a simple test case (the same that is uploaded in the link above) without G and the results were exactly the same that I obtained with G. Thus, it makes no difference to define G or not...

Best regards,

Alex

First of all it's an interesting behaviour of the fvDOM model you have in your Case.
I never tried to use a odd number for nTheta. I always tried to have the same angles of polar and azimuthal between the rays, so nTheta=2*nPhi like i've mentioned before.

Then to the G BC topic. I know it is often specified in the tutorials, but when you look in the code of viewFactor.C or fvDOM.C you will see that G don't have to be specified.
You already seen that by running your Case without the G BC.

To your Case how fine is your grid?
I've seen a paper in which is mentioned, that the grid spacing have an enourmous influence on the quality of the radiation results. I've attached a .png from the paper.
So i think you can make your results better by increasing the number of rays and decreasing your grid spacing.

Finally i have an own question on the viewFactor model.
In the radiationProperties you can specify the viewFactorCoeffs.
I don't find the influence(if there is one) of constantEmissivity. I run some testcases and i see no difference if i set it false or true.
I already checked the source code of viewFactor.C and .H but for now in which i can see there is no difference for calculating the radiation in the end.

Best regards

Robin

Thanks for the information about the grid spacing. Is that paper written in german? If the answer is no, can you please attach it here?

Regarding the question related to the view factors I can't help you much for now...

The answer is yes ;) it is written in german.
That's why i did not posted it in my last reply. Sorry.
I will open a new thread for my question on the viewFactor model.
Hopefully someone else have more experience with this model and is able to answer my question.
Good luck for your case, perhaps my annotations will help you.

best regards

Robin

Dear olivier,


If you chould share your validation case of S2S and DO on this website?


Best regards,


Chengan

ViewFactor radiation solves linear system Ax=b where normally (static geometry and constant emissivity) only b can change over iterations. So that you can decompose A into LU only once at the very beginning and solve the system with back substitution at every iteration. If A is not constant you have to do LU decomposition at every iteration which is not good performancewise. You might have not seen any difference between on and off because your simulation model was rather small and LU decomposition didn't affect performance that much.

Hello,

I had a similar problem and found the solution recently. I am sharing it in this thread so that people can check it out.

Both the viewFactor model and the fvDOM model create fields named G and qr. You have to be very aware of this, as the fvDOM, in its initial conditions, does not require qr, but viewFactors does.

In case of including qr in the initial conditions (folder 0) for the fvDOM case, the calculations will be WRONG (likely).

That happened to me. I copied the case with viewFactors to the fvDOM case, adding only the boundary conditions corresponding to IDefault. By not removing qr. In this way, boundary conditions for qr were being imposed that prevented fvDOM from reaching the good result.

Also watch out for G.

Hi! I am trying to use fvDOM to simulate UV radiations. Can anyone guide if we can define wavelength band in fvDOM? I know there is nLambda in code of fvDOM but I don't know how do we define it in radiationProperties in constant folder.

Thanks!

Take a look to :

https://github.com/OpenFOAM/OpenFOAM-9/blob/master/src/radiationModels/absorptionEmissionModels/

If it is not suitable for you, try to implement a new absorptionEmissionModel to be in the range of UV.

Another option is modifying fvDOM. Create a new emissor different from BlackBody emission https://github.com/OpenFOAM/OpenFOAM...ckBodyEmission

I am not an expert, but I would try to modify fvDOM creating a new emissor different from BlackBodyemission. In this way you can adjust the emission band to the UV.
https://github.com/OpenFOAM/OpenFOAM...ckBodyEmission

Another option would be modifying the emissivity. Take a look to:
https://github.com/OpenFOAM/OpenFOAM...EmissionModels

Thanks for quick reply!

There will not be any obstacle so I can turn off absorption. I just need a boundary emitting UV rays. Does that still need modifying blackBodyEmissions?

The correct way would be to modify the emissivity to be temperature and wavelength dependent. The issue is that it is not clear to me how to do it. I should study the code more deeply.

I am practically certain that the correct way is creating a new BC for your emitting surface, similar to https://github.com/OpenFOAM/OpenFOAM...usiveRadiation

Obviously, your surface could be diffusive but not grey and emissivity depends on temperature and wavelength.

For that reason I proposed you the "hack" of changing the blackBodyEmission instead of creating a new BC. It's not at all the ideal way, but my mind is not capable of anything else at the moment. I think it could work.

Thank You for your valuable insights. One thing more that I need to ask, do you know which tutorial utilizes wideBand model?
Also, fvDOM source code mentions nLambda but it is not asked from user or calculated anywhere else in the code. Do you know how does openfoam calculate nLmabda in fvDOM?