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?