[mykkujinu2201]

Dear Forums,

Currently, I am making a hybrid version of interface capturing method (interFoam) and interface tracking method with references.

Based on interFoam, iso-contour of interface is reconstructed, and capillary force is calculated on the reconstructed interface.
After that flux due to capillary force is calculated based on fixed grid (interFoam).

I tested the code on serial and it works fine.
However, the problem occurs when I run the code in parallel.
Because I considered parallel run, the interface is well reconstructed.
Even so, flow field shows me wrong result.
Because the interface information is correct, I suspect the term related to modifying the flux due to capillary force.

Capillary force is interpolated to fixed grid as surfaceVectorField.
Doing operation of dot product with above and the interface normal vector on the grid, grad(alpha)/mag(grad(alpha)), and rAUf, the flux is calculated.

I additionally considered faces at processor boundary patch.
However, it shows weird result especially when the processor boundary has corner points.

Do you have any opinion about this?

It would be helpful if you give me any advice.

Thank you.

Best,

Jun

[mykkujinu2201]

Dear Forums,

I set surfaceVector value on processor patch as zero vector and compared the results

I found that the result is exactly same, which means that the flux I applied at surfaceVectorField on processor boundary patch does not work at all.

forAll(mFaceID,loopi)
{
    label facei = mFaceID[loopi];
    if (mesh.isInternalFace(facei))
    {
        FCapf[facei]=capForce[loopi];
    }
    else
    {
        label pLabel=mesh.boundaryMesh().whichPatch(facei);
        label pFace=facei-mesh.boundaryMesh()[pLabel].start();
        FCapf.boundaryFieldRef()[pLabel][pFace]=capForce[loopi];
    }
}

=====================


I am sorry.

This one is wrong result.
However, still I got the processor boundary issue.

Best,
Jun

[mykkujinu2201]

Dear Forums,

I add more to explain my situation.

I am currently trying to solve two-phase flow and I really needed to reconstruct the interface to calculate capillary force directly in order to reduce spurious velocity.

Based on the calculated capillary force, capillary force flux is calculated.
This will be added in pressure equation as below.

    surfaceScalarField phig
    (
        (
          - ghf*fvc::snGrad(rho)
         )*rAUf*mesh.magSf()
        +(FCapf&(fvc::interpolate(fvc::grad(alphaS)/(mag(fvc::grad(alphaS))+VSMALL/dimLength))))*fvc::snGrad(alphaC)*rAUf  
    );

When I tested with a serial run, it works fine.
When I tested with parallel run with no processor boundary face having capillary force flux (where processor boundary is orthogonal to the interface), it also works fine.
When I tested with parallel with processor boundary face having capillary force flux (where some faces of processor boundary are not orthogonal to the interface), the solution gets messed.

In addition, the reconstructed interface is well made even the solution gets messed with any parallel run.

Capillary force is directly calculated using the geometry information of the reconstructed interface so capillary force seems to be correct.

Consequently, I suspect the capillary force flux term at processor boundary faces or other reasons.

Do you have any comments?

Thank you.


Best,
Jun

[mykkujinu2201]

Dear Forums,

I found that decomposePar change the surface normal vector direction of processor boundaries.

Would it be the reason?

If so, is there a way for me to correct?

Best,
Jun

[mykkujinu2201]

Dear all,

I solved the issue.

It was not the problem due to the flux at processor boundaries.

It was due to other procedures related to parallel computing prior to pressure equation.

Please ignore this thread.

Thank you.

Best,
Jun

[Sayyari]

I am actually interested to know what were the problems with the other procedures. I am writing a solver with a moving calculated field. I observe some non-physical artifacts at the processor boundary, and cannot fix. I tried so many different calculations and it still produced the same problem.