[jjessberger]

Writing point data for each point with CSVwriter, then you have to perform the iteration over the points yourself. It will be slow because of a lack of parallelization. Cf. e.g. examples laminar/poiseuille2d where this is done for a plot-over-line with GnuplotWriter (it works similar + creates a Gnuplot plot).

Vtm files that contain point coordinates + functor data are written by the SuperVtmWriter – this is originally intended for Paraview visualization but you can as well use the datafiles for your own purpose. It includes a parallelized iteration over the lattice points. This is what I’d recommend to use. It’s simpler to run a postprocessing script over the vtm files than to create the output completely on your own.

Since it is made for HPC application, the design for storing the data is rather complex. Well, in the end it all breaks down to arrays. Each BlockLattice holds data (at least provides an interface) to the nodes in that cuboid. If you’re eager, you can have a deep look into what this class does…

[jjessberger]

Dear Syed,

first, please check that you’re using an appropriate instance of OstreamManager in order to write parallel output only once.

The input array is expected to be of the form [iCuboid, iX, iY] (resp. [iCuboid, iX, iY, iZ] in three dimensions, cf. the functor chapter in the user guide). Then, a frequent source for segfaults is that the data on cuboid iCuboid are only available on the corresponding rank. Hence, you have to check for the rank before you access the data. Another possible error source is that the cuboids do not necessarily have the same size (-> possible index error).

The available output options do all respect these typical issues and they all write the data in some csv form into text files (+ some additional information on the form of the data). Hence, if I were you, I would check whether the output in these formats can be fit to your context.
Btw. what exactly do you mean be metadata?

Yours,
Julius

[jjessberger]

Dear Sahil,

Could you please provide additional information: was it a compilation failure or a runtime error? What was the error message? How are the arguments NSlattice etc. of your function call defined?

Yours,
Julius

[jjessberger]

Dear Alex,

thanks for your comment. Here, you also find the thesis: https://publikationen.bibliothek.kit.edu/1000126904

Yours, Julius

[jjessberger]

Dear Mathis,

Typically, such segfaults arise if the dimensions of the functors and the output arrays do not fit. For instance, SuperEuklidNorm3D expects to get a 3D functor and will probably segfault if a 1D functor is passed.

You could copy and modify the SuperExtractComponentF3D, s.t. it extracts several components. A most simple version of the operator() method to extract the first n components would then look like

template <typename T, typename W>
bool SuperExtractComponentVariantF3D<T,W>::operator()(W output[], const int input[])
{
std::vector<T> outTmp(_f->getTargetDim(), T{});
_f(outTmp.data(), input);
for (unsigned i=0; i<n; ++i) {
output[i] = outTmp[i];
}
return true;
}

Kind regards
Julius

[jjessberger]

Dear Sahil,

you can do that using the computeRho/ defineRho methods.

Background: for Advection-Diffusion equations, the zeroth moment is the scalar quantity (= the temperature in your case). This moment is often called “rho” in the LBM theory.

Yours,
Julius

[jjessberger]

Hi,

It sounds as if the geometry which comes out of the STLreader is not watertight. This can still be due to the super- or cuboid geometry.
How exactly did you define the variable “indicator” which is used for the first rename and how did you define the cuboidGeometry?

As I do not know the insides of the STLreader either, I can only suggest looking inside with a debugging tool and checking, whether/ why some points at the boundary are not recognized.

[jjessberger]

Hi,

this is not a general solution, but merely some ideas in order to eliminate the error source (probably you have tried some of these already):
– does the problem depend on the number of cuboids/ cores?
– plot and check the material numbers in paraview, before and after each rename
– increasing the extent of the CuboidGeometry can avoid round-off errors at that stage

Yours,
Julius

[jjessberger]

Hello Navid,

there seems to be a bug in the implementation of the method BlockLatticeGuoZhaoPhysBodyForce2D<T,DESCRIPTOR>::operator().

If you change the field access in the BlockLatticeGuoZhaoPhysBodyForce2D<T,DESCRIPTOR>::operator() method (src/functors/lattice/latticeGuoZhaoPhysBodyForce2D.hh, ll. 67-75) to

template <typename T, typename DESCRIPTOR>
bool BlockLatticeGuoZhaoPhysBodyForce2D<T,DESCRIPTOR>::operator() (T output[], const int input[])
{
output[0] = this->_converter.getPhysForce( this->_blockLattice.get( input[0], input[1] )
.template getFieldPointer<descriptors::BODY_FORCE>()[0] );
output[1] = this->_converter.getPhysForce( this->_blockLattice.get( input[0], input[1] )
.template getFieldPointer<descriptors::BODY_FORCE>()[1] );
return true;
}

, does it work for you?

Yours,
Julius

[jjessberger]

Dear Antonio,

for material=2, NoDynamics are set on the Navier-Stokes lattice. This may crash later when you apply the coupling. At least, I don’t understand the intention of the Boussinesq coupling outside the domain.

If this does not help, you could turn on the coupling for one material after the other and see, where it crashes.

Yours,
Julius

[jjessberger]

Hello Ramiro,

I fully agree about the geometry.
In order to enforce the no-slip, the velocity is set to zero at BounceBack nodes (cf. BounceBack::computeU). The density is typically computed as in the bulk (which is the prescribed value is our case, since it does not changed after initialization), cf. BounceBack::computeRho.

Yours,
Julius

[jjessberger]

Hello Ramiro,

In any case, the lattice nodes and their physical coordinates depend (only) on the geometry and are identical for both lattices (-> the coupling cannot be affected).
The question whether you have on-node or link-wise BC affects where you suppose your virtual, non-discrete domain to end. When you compare with analytical solutions, you should consider this fact, because it affects the order of convergence. Practically, there is not necessarily a problem if one (virtual) domain is slightly larger than the other: the computational domain is the same.

[jjessberger]

Hello Ramiro,

thanks for the explanation, I did not know that.
Why is it clear that the AdvectionDiffusionBoundariesDynamics require on-wall boundary locations? The code comment “on cell there are non-shiftet values” seems to refer to the storage of cell populations in my eyes.
Anyway, the cuboid and super geometry do not know the dynamics and boundary conditions, they are created before-hand. So, at least nothing prohibits setting link-wise BC for the first and on-node BC for the other lattice for the same part of the boundary.

[jjessberger]

And what is the output/ the results that you get with your snippet?

• This reply was modified 3 years, 2 months ago by jjessberger.

[jjessberger]

Hello Ramiro,

as far as I understand fullway bounce-back correctly, it implies that the boundary is located precisely on the nodes (cf. Krüger, DOI 10.1007/978-3-319-44649-3). Does this answer your question?

Best regards,
Julius

[Author]

Posts