Bounceback problem with parallelism after implementation of a new dynamic class [solved]

Hi everyone,

As the title said, I tried to implement a new dynamic class — in order to work with Irina Ginzburg’s TRT model to be specific — and it almost works fine. The results with one processor seems good (I did not look for a quantitative verification, but the results looks a lot like the ones of cylinder2D.cpp given the same conditions), but when I go into multiprocessing, the corner bounceback nodes of each processor bloc lose or gain velocity (about a tenth of the initial velocity on that node). It works fine with the periodic boundary condition however, no matter how many processors I put on it.

In case of it being important, I specify that I use an external scalar and an external force (I added a descriptor for that), and that I give my dynamic class constructor two arguments: the first is omega, the second is the Lambdaeo parameter from Irina Ginzburg’s TRT model.

Hopping you’ll be able to help me, thanks in advance.

1 Like

Dear RTPK,

this looks like a problem with your initialization procedure. Maybe you are using relative coordinates where absolute coordinates are necessary. This would explain why this only occurs in parallel. Could you post your initialization procedure?



Thanks for your reply kk, here you go:

void cylinderSetup( MultiBlockLattice2D<T,DESCRIPTOR>& lattice,
OnLatticeBoundaryCondition2D<T,DESCRIPTOR>& boundaryCondition, const plint nx, const plint ny )


T rho0 = 1.;

Array<T,2> u0((T)1/(T)15,(T)0);

initializeAtEquilibrium (
      lattice, lattice.getBoundingBox(), rho0, u0 );

plint cx     = nx/2;
plint cy     = ny/2;
plint radius = cy/4;
defineDynamics(lattice, lattice.getBoundingBox(),
               new CylinderShapeDomain2D<T>(cx,cy,radius),
               new plb::BounceBack<T,DESCRIPTOR>);



Else, it is like in the cylinder2D.cpp example.

Edit: the initialisation with an initial speed was to check the influence of the body force I put with [code="cpp"]setExternalVector()

, the problem stays even with an initial speed equal to zero, and an external force to move the fluid. The problem persist even without the cylinder, and with

lattice.periodicity().toggle(0, true);
lattice.periodicity().toggle(1, false);

The initialization seems to be fine. To be absolutely sure, try switching back to the standard dynamics with a standard descriptor and see if the problem persists. If it does not, something is wrong with the implementation of your dynamics class/descriptor.

In this case, since you have created a two parameter dynamics class, there might be something wrong with the serialize/unserialize methods (see e.g. CompleteTRTdynamics in ./src/basicDynamics/isoThermalDynamics.hh).

At the moment, this is my only other idea. Hope this helps.



Problem solved! As you said, it was a serializer/unserializer problem. In case it can help someone else, here are the details: I just mixed up between (correct code)

Lambdaeo = unserializer.readValue();

and (incorrect code)

    Lambdaeo = unserializer.readValue<T>();    

Thanks again kk.