[vaillant]

Hello Julius,

Thank you very much for your answer, it help me a lot.

Best regards

[vaillant]

For the second bug, let’s take one boundary cell. For initializing Bouzidi, setBouzidiVelocityBoundary is called, which add a VelocityBouzidiLinearPostProcessorGenerator3D to the neighbour fluid cell. This Post Processor is doing the Bouzidi algorithm directly on the fluid node so I understand NoDynamics is correct for the boundary node since it just store the population.

This works well with one lattice. But if you add another lattice to resolve the Advection-diffusion Equation, there will be a problem.

If we still take the same boundary cell, we initialize it with setAdvectionDiffusionTemperatureBoundary, and if we assume for example that the boundary cell is an edge, so discreteNormal[0] == 3, the dynamic is then AdvectionDiffusionEdgesDynamics and the momenta is EquilibriumBM.
When arrive the moment to collide this boundary cell, collide of AdvectionDiffusionEdgesDynamics need the velocity of the fluid to compute the equilibrium, so it calls :
auto u = cell.template getField<descriptors::VELOCITY>();

We go look at what have been stored in this field. It’s done in NavierStokesAdvectionDiffusionCouplingPostProcessor3D in processSubDomain with :

auto u = tPartner->get(iX,iY,iZ).template getField<descriptors::VELOCITY>();
blockLattice.get(iX,iY,iZ).computeU(u.data());
tPartner->get(iX,iY,iZ).template setField<descriptors::VELOCITY>(u);

The blockLattice here is one of the first lattice. So on the boundary cell, the dynamic is NoDynamics and so computeU(u.data()) will do :

  for (int iD=0; iD<DESCRIPTOR::d; ++iD) {
    u[iD] = T();
  }

.
So even if there is a velocity applied on the boundary cell, the value store in the field of the second lattice will be 0. So in AdvectionDiffusionEdgesDynamics, when you compute the equilibrium with lbH::equilibriumFirstOrder(unknownIndexes[iPop], temperature, u.data()), u comes from the field and so it is 0, and you will have a value of the equilibrium accordingly. In the meantime, the neighbour fluid cell retrieves the correct velocity from his field since computeU(u.data()) of for example BGKdynamics would have give it the right value.
So to resume, for the thermal lattice, the boundary cell ‘see’ no velocity while its fluid neighbour ‘see’ a velocity. This is why, I think, it crash when I try it. And with correcting the value of the velocity in the field, it’s working fine.

[vaillant]

Thank you for the advice.

One thing I still don’t understand is how, whereas I fix a constant value to the boundary, some boundary point could be at another value (302 instead of 298). Since we create output with SuperLatticePhysTemperature3D which call this->_blockLattice.get( input[0], input[1], input[2]).computeRho(), we should always have the value that is fixed inside the Momenta, am I right ?

[vaillant]

For the boundary values I used converter.getLatticeTemperature(298.0). At the surface, depending on the configuration of cells, I found between 296.5 and 300 at the fluid cells. And some points of the boundary, those which are more exposed to the fluid due to the stairway shape, have a value of 302. Sorry I did not understand your third sentence. If I refine the mesh, it reduce the fluctuations but they are still there.

[vaillant]

Dear Mathias,

By defining a dynamics with :

lattice.defineDynamics(superGeometry, 3, &bulkDynamics);

the result is the same, the computation diverges.

Best regards

[Author]

Posts