jjessberger
Forum Replies Created
-
Posts
-
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,
JuliusDear 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,
JuliusHello,
as far as I know, a particle-wall collision is not yet implemented in HLBM.
Yours,
Julius J.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.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.
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.
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()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.
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.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,
JuliusHello 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.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.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.Hello Xu,
I would recommend the article https://arxiv.org/abs/physics/0506157 (Latt, Chopard), where the method is presented.
Yours sincerely,
Julius J.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