Skip to content

Modifying Parameters

  • This topic has 13 replies, 3 voices, and was last updated 4 months ago by jan.
Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #6797
    Jijo
    Participant

    Hello everyone,

    I am facing difficulty modifying parameters such as relaxation coefficient, Characteristics length, and characteristics velocity in the example square cavity 2D. Your support is highly appreciated.

    Thanks,

    #6800
    jan
    Participant

    Hello Anas,

    as you’re regarding a thermal flow case, those properties are handled by the ThermalUnitConverter (https://www.openlb.net/DoxyGen/html/d0/de2/classolb_1_1ThermalUnitConverter.html). For example, comparing the constructor with the usage in the squareCavity2D case shows that lx is the characteristic length and is set at the beginning of the main function. Similar is true for other values.
    The relaxation time, on other hand, is not a parameter of the used constructor, but is calculated from other values (see the implementation of the constructor: https://www.openlb.net/DoxyGen/html/d0/de2/classolb_1_1ThermalUnitConverter.html#a60ea34c354f56edbee5b720bf2cadac4).

    If this does not answer your question, please be more specific.

    Best regards,
    Jan

    #6801
    Jijo
    Participant

    Hey Jan,

    Thank you for your reply. As you can guess, I am new to OpenLB. I wanted to simulate the thermal/squarecavity2d example. But the results seems inadequate. The cold boundary condition on the right wall is not isothermal across y. However, if I run the squarecavity3d example, I can validate the result.

    Thanks

    #6803
    jan
    Participant

    Hello Anas,

    can you give me some more information about your problem? Is it the default squareCavity2D? Did you change something and what did you change? How do you quantify that the right wall is not isothermal? (And maybe other things that you thing are of interest.)

    Best regards,
    Jan

    #6804
    Jijo
    Participant

    Dear Jan,

    Thank you for your replies. I really appreciate your help. I ran the original code without any modifications.

    https://ibb.co/cbyD9hR

    The link above is a snapshot from paraview. As marked by the red circle, Tcold boundary conditions is only applied at the corner rather than the whole right wall. If I ran the squarecavity3d example the outcome is quite different. as shown in the link below.

    https://ibb.co/mqx2g2G

    Which is correct according to the literature.

    #6805
    jan
    Participant

    Hello Anas,

    thanks for the explanation. I’ve checked our current master, and it seems to work there. However, I’m not aware which commit/change fixes it. Therefore, I’ll ask other contributors and we’ll get back to you within a few days.

    Best regards,
    Jan

    #6809
    Adrian
    Keymaster

    I just ran the squareCavity2D code in OpenLB 1.5 and got the expected results (i.e. similar to your squareCavity3d visualization). The temperature Tcold is definitely applied to the entire wall for me.

    Can you re-check what if anything has changed between your local code and the release? (Probably the easiest way would be to download the tarball again and execute the case there)

    If you can reproduce the faulty results there we’ll have to take a closer look.

    #6816
    Jijo
    Participant

    Dear Adrian,

    Thank you for your reply. I ran the original code with no modifications and I still got the same faulty results.

    #6822
    Adrian
    Keymaster

    Something must be different, here you see the initial temperature field in thermal/squareCavity2d as provided in OpenLB 1.5:

    This is the temperature field at t=0.655968:

    To make sure I am not accidentally using a newer state in our repository I obtained this by downloading release 1.5, extracting it and executing the simulation on 8 cores using MPI. Can you provide more details on your exact workflow so we can identify the difference? (Or e.g. upload your local OpenLB folder with the faulty results).

    While there have been changes and fixes in this area since the release (e.g. GPU coupling support, boundary setter changes) this already worked fine in the release both in the tests we did back then and the one I reproduced now.

    #6839
    Adrian
    Keymaster

    While checking an unrelated issue I just noticed that I can reproduce the geometry issue you reported for simulations on just one cuboid – for eight the geometry is correct. I will check this in more detail and come back to you once it is fixed. Sorry for the confusion.

    #6841
    Jijo
    Participant

    Dear Adrian,

    I think the problem is in the geometry. But I am not an expert in OpenLB coding so I am not sure. In your previous reply, what do you mean by MPI? I ran the code using Ubuntu by my 4 core setup.

    Thanks,
    Anas

    #6842
    Adrian
    Keymaster

    Exactly, the geometry setup is the issue. If I use eight cuboids (e.g. by starting the simulation using 8 MPI processes) the geometry is correct. If I use just one or four the geometry is broken in the way you observed. This likely is a rounding issue in the indicator setup of prepareGeometry.

    #6843
    Jijo
    Participant

    Dear Adrian,

    I apologize for the silly questions. But what do you mean by cuboids?

    #6844
    jan
    Participant

    Dear Anas,

    in the main function of the example a cuboidGeometry is created:

    /// Instantiation of an empty cuboidGeometry
    CuboidGeometry2D<T> cuboidGeometry(cuboid, converter.getPhysDeltaX(), singleton::mpi().getSize());

    Here, you can see that the number of processes is provided as an argument (singleton::mpi().getSize()). Apparently, if this equals 1 or 4, the geometry is falsified. This means for you, that the case would probably work as expected if you run it with a different number of processes, e.g., mpirun -np 3 ./squareCavity2d.

    In the meantime, we’re working on a fix.

    Hope that answers your question, if not, let me know.

    Best regards,
    Jan

Viewing 14 posts - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.