Discovery Import

Discovery Import

Heat conduction error

    • papp
      Subscriber

      Hello,

      I've experienced that Discovery Live is not able to calculate any heat transfer at all if its thermal conductivity is decreased below a certain value. (In the order of magnitude of 10^-5.) This results in a constant 0 [°C] temperature field, however several heat sources are added to the computation domain. Note, that with higher values heat transfer works just fine. Fidelity set to maximum, GPU: GTX 1080Ti.

      Can you provide any solutions to this problem, or at least confirm this phenomenon as a known limitation of Discovery Live?

      Thanks,

      Bálint

    • Brian Bueno
      Ansys Employee

      I will consult with our development team and get back to you.  I assume the value may be too small if it works with larger ones.

    • anthony.giacoma
      Subscriber

      Hi Bálint,

      Thanks a lot for your feedback! I hope that you enjoy Discovery Live experience.

      A material with a thermal conductivity, say λ, such that λ < 10^{-3} is very very very powerful insulation material. You set λ = 10^{-5}, why not :) . As the heat cannot be transferred because of this huge insulator, I guess that you won't be able to see any degree elevation through the bulk of the solid due to heat sources.

      Maybe, I'm missing details. Could you share with us additional details about your observation (screenshots, problem set) ?

      Thanks a lot

      • papp
        Subscriber
        Hello, at first, some clarification: I'm simulating the propagation of air pollutants in Discovery Live, in the field of air quality oriented urban design. To achieve this goal, a diffusion-heat trasfer analogy has to be used, obvioulsy. (Fluid module with heat transfer.) In this analogy, the temperature of air represents the air pollutant concentration, and the heat fluxes at certain areas the pollutant source zones. As you might know, this analogy exists for the transport coefficients in kinematic unit, [m/s^2], namely:
        • D, the diffusion coefficient of air;
        • λ/(rho*c_p), [thermal conductivity]/([density]*[specific heat]) of air (for heat transfer).
        The results from Discovery Live are to be compared with previous simulations in Fluent, as well as to wind tunnel measurements. One of the goals is to determine DL's accuracy quantitatively compared to validated CFD results. (The simulation speed is already impressive for LES, as well as the qualitative results of the flow regimes and concentration fields.) To achieve a 1:1 analogy between the aforementioned quantities, λ should have to be set in the order of magnitude of 10^-6. (This way the results shown in [°C] units are the exact concentration values, otherwise they can be obtained only after some nasty interpolation. That's what we try to evade... :) ) About the problem exactly: λ was reduced systematically to 5e-5, and Live seemed to perform just fine. The temperature field was  similar to the ones obtained with higher λ values (up to 2.5e-1). But after halving λ once more (to 2.5e-5), constant 0 [°C] was the result to the whole computation domain, just like the case when no heat sources were defined within the enclosure. The image below is taken using the ISO surface postprocessing tool. (The same unique phenomenon occurs when no thermal BC's (zero heat flux) are defined. Yes, the image is taken at 0.028 [s], but the same constant zeros are present later as well.) I've tried to halve the computation domain (with applying symmetry, of course), but it didn't seem to help my cause, the same error occured - I believe this lack of results is not the consequence of coarse resolution. I bear no grudges at all against Discovery Live, since this is a kind of extreme application, that it should not be prepared to compute, by all means. We are only interested in the reasons behind this phenomenon, and furthermore, whether the extrapolations will be needed or the concentration results can be obtained directly some way. If you have an idea of the root cause, please share it with us :) Thanks, Bálint
      • papp
        Subscriber

        Kinematic unit is [m^2/s] correctly.

Viewing 2 reply threads
  • You must be logged in to reply to this topic.