[araeli]

Dear Sam,

1) Thank you for your suggestion regarding the convergence criterion. I will try this approach as I am still determining the best method for my specific physical problem.

2a-b) I set the density (and I believe the label is correct) using the following:

    setFreeEnergyInletBoundary<T,DESCRIPTOR>(sLattice1,omega,superGeometry,3,"density",1);
    setFreeEnergyOutletBoundary<T,DESCRIPTOR>(sLattice1,omega,superGeometry,4,"density",1);

    setFreeEnergyInletBoundary<T,DESCRIPTOR>(sLattice2,omega,superGeometry,3,"density",2);
    setFreeEnergyOutletBoundary<T,DESCRIPTOR>(sLattice2,omega,superGeometry,4,"density",2);

However, the boundary values are not being enforced as expected. For example, in a piston-like simulation, I tried setting an inlet density of 10 (non-physical, just for visualization purposes in Paraview), like so:

  AnalyticalConst3D<T,T> rhoinVal( inletDensity );
        AnalyticalConst3D<T, T> rhooutVal(T {1});
        AnalyticalConst3D<T,T> phiminusone( T {-1} );
        AnalyticalConst3D<T, T> phione(T {1});
        sLattice1.defineRho(superGeometry,3,rhoinVal);
        sLattice1.defineRho(superGeometry,3,rhooutVal);

        sLattice2.defineRho(superGeometry,3,phiminusone);//3 inlet material number
        sLattice2.defineRho(superGeometry,4,phione);// 4 outlet material number

        sLattice1.setProcessingContext<Array<momenta::FixedDensity::RHO>>(
                    ProcessingContext::Simulation);
        sLattice2.setProcessingContext<Array<momenta::FixedDensity::RHO>>(
                    ProcessingContext::Simulation);

I expected a rho value of 10 at the output, but it seems the boundary condition is not applied. I tried setting this before the coupling definitions, after them, and in the simulation loop, but without success.

I defined the couplings in the order: outlet, chemicalPotential, force, and inlet, as shown below:

    SuperLatticeCoupling coupling1(
                InletOutletCoupling3D{},
                names::A{}, sLattice2,
                names::B{}, sLattice1
                );

    coupling1.restrictTo(superGeometry.getMaterialIndicator({4}));

    SuperLatticeCoupling coupling2(
                ChemicalPotentialCoupling3D{},
                names::A{}, sLattice1,
                names::B{}, sLattice2);

    coupling2.template setParameter<ChemicalPotentialCoupling3D::ALPHA>(alpha);
    coupling2.template setParameter<ChemicalPotentialCoupling3D::KAPPA1>(kappa1);
    coupling2.template setParameter<ChemicalPotentialCoupling3D::KAPPA2>(kappa2);
    coupling2.restrictTo(superGeometry.getMaterialIndicator({1}));

    SuperLatticeCoupling coupling3(
                ForceCoupling3D{},
                names::A{}, sLattice2,
                names::B{}, sLattice1);

    coupling3.restrictTo(superGeometry.getMaterialIndicator({1}));

    ///inlet coupling
    SuperLatticeCoupling coupling4(
                InletOutletCoupling3D{},
                names::A{}, sLattice2,
                names::B{}, sLattice1
                );
    coupling4.restrictTo(superGeometry.getMaterialIndicator({3}));

Thank you for your suggestions. I hope the attached code provides some helpful context. I am sure that I am missing something fundamental, but I am struggling to identify exactly what it is.

Best regards,
Alice

[araeli]

Dear FB,

Thank you so much. The fact that points are called cells wasn’t clear to me, but it’s crucial in clarifying my doubts.

Best regards,
Alice

[araeli]

Dear Jan,
Dear all,

sorry for the late I tried several tests in these days. I noticed that even though the STL file is intended to be interpreted in micrometers, it is treated as dimensionless in my case. Initially, I requested a number of cells that was too high for my RAM, so I started to reduce the domain size, and eventually, I created a very basic example.
I created a 5x5x5 domain
https://drive.google.com/file/d/16ppn1-Q-qHcpqL5afSLJi74MXikbur2Q/view?usp=sharing
The domain is essentially made up of cubes, so I expected the lattice to conform to these dimensions as well. However, I noticed that the mesh tends to ‘contain’ the domain rather than adhere to the edge, with the border vertices being both internal and external in the surrounding cells. Therefore, I have a series of questions, as I am working with porous materials where every approximation is significant:

-Is this behavior normal, or is it due to my poor use of the library?
-Is the excess always just one cell?
-Depending on the refinement (one slice in the figure https://drive.google.com/file/d/17Y5hOm8kHF_wEGSXES7g5QgLBqNmnmKt/view?usp=sharing ), it is not symmetric. The test presented here is at a 1:1 scale, but the ‘shift’ of the vertices is 0.25. Is this also due to a mistake in the library, or is it justified?
-Is there a way to force the boundary mesh to adhere to the vertices of the porous medium once they are given as voxels, thus theoretically already cubic and easily adaptable in structure?

Thank you in advance,
Alice

[araeli]

Dear Adrian,
thank you for your feedback! I will check the correct linking of dependencies.

[Author]

Posts