[stephan]

Dear steed188,

to double-check the correctness of your code, the examples in olb/examples/thermal should be helpful. You might want to start with the example and modify it step by step with compile and run in between to find the source of divergence.

Please use the smagoPrefactor as defined in the examples since there is a unique mapping between the thermal and incompressible LES (see https://publikationen.bibliothek.kit.edu/1000126904).

The arguments of the couplingGenerator should be in lattice units.
To specify the effect of other values (passed in lattice units), please use the default example and evaluate the difference when changing the physical parameters.

BR
Stephan

[stephan]

Dear kest,

you might be interested in implementing the same testcase with OpenLB as a reference.
There is also a double-distribution thermal model included in OpenLB.
Similar code snippets should appear within the dynamics which are for example showcased in some of the examples/thermal/ folders.

BR
stephan

[stephan]

Dear Lucas,

thanks for posting.
Please note that in general, forces are realized in OpenLB as fields, which probably is the reason for you ending up in the generic FIELD_BASE.
The fields act as cell storage and can be accessed via e.g. getFieldPointer in the code snippet you pasted.

Long story short, to implement different forces you could hardcode them in your example/application .cpp file.
By that, I mean specify the force as a function and then pass it to the field storage.
This is done e.g. in examples/multiComponent/rayleighTaylor3d/rayleighTaylor3d.cpp, where an external force is added via an additional field

using DESCRIPTOR = D3Q19<FORCE,EXTERNAL_FORCE,STATISTIC>;

which is in turn explicitly specified later via

sLatticeOne.defineField<descriptors::EXTERNAL_FORCE>( superGeometry, 1, f );

and hence can be used in the forcing scheme through accessing the EXTERNAL_FORCE field.

BR
Stephan

[stephan]

Dear joeruan,

thanks for posting.

(1) You can modify the density ratio in the phaseSeparation examples by definition of the initial density profile. The Shan-Chen models currently implemented in OpenLB can be found in src/dynamics/interactionPotential.*. The one used in examples/multiComponent/phaseSeparation2d/ for example is taken from https://doi.org/10.1103/PhysRevE.49.2941 and is based on a single distribution realization. The default values for rho and psi are 200 and 4, respectively (see .h file).

(2) Yes, the modification of viscosity most probably has to be addressed with a second lattice.
For two components, see examples/multiComponent/rayleighTaylor2d/.
However, (to the best of my knowledge) due to numerical reasons, non-marginal viscosity ratios would require a modification of the present code. I can recommend https://www.wiley.com/en-us/Multiphase+Lattice+Boltzmann+Methods%3A+Theory+and+Application-p-9781118971338, or https://link.springer.com/book/10.1007/978-3-319-44649-3 for further reading.

(3) From a purely technical point of view you could make the interaction parameter non constant an pass it to the coupling. Maybe a few other modifications are required.

BR
Stephan

[stephan]

Dear Sahil,

the setAdvectionDiffusionTemperatureBoundary defines a Dirichlet boundary condition for the temperature. The same is obtained with setRegularizedTemperatureBoundary.
The difference is that the latter regularizes the information of higher order moments.

However, using the former is recommended, since it is validated and should suffice in most cases.

BR
Stephan

[stephan]

Dear Mathis,

thank you for your comment.

Please note that the SuperLatticeTimeAveragedF3D functor returns more than 3 dimensions.
The exact specification is given for example here:
https://www.openlb.net/DoxyGen/html/d5/dc4/superLatticeTimeAveraged3D_8h_source.html

Hence, if you extract the corresponding entries to another vector on SuperLattice level, you are able to continue as suggested (using the latter as an input for SuperEuklidNorm3D).

BR
Stephan

[stephan]

Dear Ramiro,

thanks for reporting back.
I tested your example on OpenLB r1.4 and can reproduce the results.
The appearing effect could also be a result of boundary/inlet conditions or dynamics coupling.

Since we have realized a new dynamics concept in r1.5, I would suggest to update your code according to the new release.
If this does not change anything, please let me know again.

Thank you again for contributing!

BR
Stephan

[stephan]

Dear sahilbhapkar30,

if I understood correctly, you would like to implement a Dirichlet boundary condition (BC) for advection-diffusion equations, which is possible in OpenLB via setAdvectionDiffusionTemperatureBoundary2D.

An exemplary implementation of this type of BC is given in the examples/thermal/porousPlate2d(3d).
In the 2d case, you might want to switch to
#define TemperatureBoundary
//#define RegularizedTemperatureBoundary
//#define RegularizedHeatFluxBoundary
to observe the corresponding results.

BR
Stephan

[stephan]

Dear sahilbhapkar30,

if I understood correctly, you would like to implement a Dirichlet boundary condition (BC) for advection-diffusion equations, which is possible in OpenLB via setAdvectionDiffusionTemperatureBoundary2D.

An exemplary implementation of this type of BC is given in the examples/thermal/porousPlate2d(3d).
In the 2d case, you might want to switch to
#define TemperatureBoundary
//#define RegularizedTemperatureBoundary
//#define RegularizedHeatFluxBoundary
to observe the corresponding results.

BR
Stephan

[stephan]

Hi Ramiro,

thanks for your message.
That is interesting.
We will have a look.

I would be very happy if you could also give it a try, switch the relaxation times as in the NSE case, simulate again with AdvectionDifusionTRTDynamics, and post here again about the effect.

However, the switch should be correct, since the NSE collision conserves moments up to order one, whereas the ADE does this only up to order zero, which in turn gives reason to use diffusion relaxation for the symmetric populations in the former and anti-symmetric ones in the latter application case.

Please also note that the TRT scheme has variable numerical properties. Dependent on the second relaxation parameter you used, accuracy or stability could be increased; but both can also be decreased. Hence using the plain BGK model is just the right choice for your setting.

BR
Stephan

[stephan]

Dear Gloriousface,

sorry for the late reply.

Thank you for reading carefully.
We will definitely look into that.

In the meantime, as you seem to have some experience with this, you could test correcting the force yourself, have a look at the results and report the observations here.

In case you have further remarks, please let us know.

BR
stephan

[stephan]

Hi sahilbhapkar30,

that’s hard to tell right away.

Please make sure not to specify things multiply.
Ensure the correct material number and cuboid definitions, i.e. to hit the nodes correctly with the indicator cuboids (you can double-check by loading the ./tmp/vtkData/geometry_<>.vtm file into paraview and visualizing as points).

Also, in the getResults function call all of them in a row:
SuperLatticePhysWallShearStress3D<T,DESCRIPTOR> wss(…);
SuperLatticePhysWallShearStress3D<T,DESCRIPTOR> wss1(…);
SuperLatticePhysWallShearStress3D<T,DESCRIPTOR> wss2(…);
SuperLatticePhysWallShearStress3D<T,DESCRIPTOR> wss3(…);
vtmWriter.addFunctor( wss );
vtmWriter.addFunctor( wss1 );
vtmWriter.addFunctor( wss2 );
vtmWriter.addFunctor( wss3 );

Good luck with that!

BR
Stephan

[stephan]

Dear sahilbhapkar30,

thank you for your question.

The functor dimension can be specified in line 50 and 77 of https://www.openlb.net/DoxyGen/html/d2/d41/latticePhysWallShearStress3D_8hh_source.html by modifying the last argument of the parent SuperLatticePhysF3D<T, DESCRIPTOR>(sLattice, converter, 1).

BR
Stephan

[stephan]

Dear Xu Yang,

thanks for your question.

For wet-node boundary approaches in general, please see the evergreen book by Krüger et al. ‘The Lattice Boltzmann Method: Principles and Practice’ from 2017.

As far as I know, there’s no explicit reference for the procedure labeled as ‘fneqMethod=2’.
Anyway, I’ll try to explain its name term by term:
(1) regularization (in the sense of the regularized lattice Boltzmann collision scheme) means that we reconstruct the fneq’s from the non-equilibrium momentum flux (named ‘Pi’) which in turn can be approximated via the rate of strain tensor according to CE analysis.
(2) second order finite differences are used for computing the velocity gradient which is necessary for the strain rate in (1).

For implementational details, please see https://www.openlb.net/DoxyGen/html/dc/dbc/wallFunctionBoundaryPostProcessors3D_8hh_source.html from line 760 onwards.

BR,
Stephan

[stephan]

It is hard to tell what exactly triggers the divergence.
The two lines of code you included simply refer to (as the name tells) analytical constants set in your program.
Dependent on what for (and also how) you use them, instability occurs.

[Author]

Posts