Skip to content

jjessberger

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 30 total)
  • Author
    Posts
  • in reply to: Turbulent flow around a cylinder #5998
    jjessberger
    Participant

    Hello,

    could you please provide a more detailed description of what is not working? Without any further information, it’s hard to look for errors. E.g., a paraview plot of the geometry would help. How is the indicator argument set and did you take the code from a specific example in OpenLB?

    Best regards,
    Julius

    in reply to: SuperLatticePhysHeatFlux3D #5986
    jjessberger
    Participant

    Dear vaillant,

    I don’t know how the additional factor arises exactly, but it looks similar to the one that arises in the Chapman-Enskog expansion for ADE (cf. Krüger, DOI 10.1007/978-3-319-44649-3, eq. (8.35a)). There, this factor expresses the difference between numerical and original diffusion and it might have been corrected in that functor.
    For further information, you may search for the Chapman-Enskog expansion for thermal ADE or maybe contact the authors of the mentioned paper.

    As for the second question, there seems to be no difference: In OpenLB 1.4, the computeJ method computes the heat flux + T * u (cf. RegularizedHeatFluxBM::computeJ), an additional summand which is subtracted again when computing the functor.

    Yours,
    Julius

    • This reply was modified 2 years, 8 months ago by jjessberger.
    in reply to: HLBM boundary settings #5965
    jjessberger
    Participant

    Hello,

    as far as I know, a particle-wall collision is not yet implemented in HLBM.

    Yours,
    Julius J.

    in reply to: Geometry -Resolution #5964
    jjessberger
    Participant

    Hello Sahil,

    Since the space and time resolution comes out of a coupled discretization (space, time, velocity) of the phase space from the Boltzmann equation, this is not possible in Lattice-Boltzmann methods unfortunately.

    Yours,
    Julius J.

    jjessberger
    Participant

    Hello Abhijeet,

    input contains the cuboid number and then the lattice coordinates, so, effectively, it is an array of length 3. For technical reasons, output also needs to have length 3 (dimension+1).

    If you want to get processable data (in contrast to debugging purposes), you also need communication on the block overlaps. Therefore, the usage of BlockReduction and physical functors is strongly recommended, because it executes these steps for you.

    jjessberger
    Participant

    I’m sorry I think I mixed things up. The offset that we are talking about is not because of the storage of the lattice populations (this happens deeper in the code). Instead, it simply seems to be since one wants to correspond density=1 to pressure=0 as a default. Consequently, one has to modify the offset when a different char. phys. pressure is defined. The UnitConverter does this.

    jjessberger
    Participant

    After defining the functor “SuperLatticeVelocity2D<T, DESCRIPTOR> velocity_lat( sLattice);”, you may call it via “velocity_lat(output, input)”, where output, input are appropriate arrays:
    T[d] output gets the result; int[d] input contains the coordinates.
    Cf. the chapter about functors in the user guide and the definition of SuperLatticeVelocity2D.operator()

    jjessberger
    Participant

    Well I’m not an expert for file formats and csv, if it is not much data it is probably the easiest solution to use the c++ iostream functionalities for creating your csv file.

    You may check out the computeU/ computeRho methods from the “Cell” class for velocity/ density. If you want to compute the pressure like that, you need to compute it “by hand” using c_s^2 * rho.

    jjessberger
    Participant

    Hello Abhijeet,

    The functors SuperLatticePhysVelocity2D etc. do not interpolate any data. The interpolation happens when you convert them into analytical functors or when you use some BlockReduction. Also paraview interpolates in its visualization.
    You may pass the lattice functors directly to the vtm writer, as it is done e.g. in poiseuille2d. Concerning paraview, you should take care that you watch your functor values precisely at mesh points and not in between. The “point” visualization style helps in doing so.

    Similarly to your code snippet for the force, you may also apply the computeU/ computeRho methods of the cell if you want to get the velocity at some specific cell.

    Yours,
    Julius J.

    jjessberger
    Participant

    Hello Abhijeet,

    Unfortunately, I cannot reproduce this problem: I entered the charPhysPressure as you did, did not modify any offset and got the correct result (tested on olb release 1.4, poiseuille2d, both forced and nonForced mode).

    Yours,
    Julius

    jjessberger
    Participant

    Hello Abhijeet,

    The density offset is introduced in order to increase machine precision.

    If you need to remove the offset in the pressure computation, it has probably been introduced in a wrong way. How did you define your characteristic pressure?

    Yours,
    Julius J.

    in reply to: AnalyticalLinear2D Functor Syntax Query #5907
    jjessberger
    Participant

    Hello Abhijeet,

    The three arguments are the coefficients of the desired linear function. This (and their particular role) can be seen in the implementation of the AnalyticalLinear2D<T,S>::operator() method (src/functors/analytical/analyticalF.hh::395):
    > output[0]=_a*x[0] + _b*x[1] + _c;

    Yours,
    Julius J.

    in reply to: Bounceback boundaries(Physical and lattice coordinates) #5906
    jjessberger
    Participant

    Dear Abhijeet,

    The numerical geometry (and therefore the physical and lattice coordinates of your grid nodes) does not depend on the boundary conditions (in fact they are set in advance).
    Setting some nodes of your domain to a link-wise boundary condition does not change the coordinates of the nodes. Instead, it implies that the actual boundary of the physical domain lies beside these nodes.

    Yours sincerely,
    Julius J.

    in reply to: Method for fneq reconstruction in the example of channel3D #5905
    jjessberger
    Participant

    Hello Xu,

    I would recommend the article https://arxiv.org/abs/physics/0506157 (Latt, Chopard), where the method is presented.

    Yours sincerely,
    Julius J.

    jjessberger
    Participant

    Hello Abhijeet,

    I think you are doing everything right. The constant offset of 1.0 arises because the populations are stored with such an offset (for the reason of numerical accuracy). On the other hand, you may use functors like SuperLatticePhysPressure2D which apply this offset automatically.

    Yours,
    Julius

Viewing 15 posts - 16 through 30 (of 30 total)