DensityGradient errorEstimator issue about blastamr HOT 7 CLOSED

Hi, not all of the error indicators are well tested yet. I exclusively use the coded one. Also, it's hard to debug this with the information I have now.

Instead, you can mimic density-gradient-based refinement with the following coded snippet (dimensions of rho might be different for your solver). This example will refine cells whose rho gradient falls above 50% of the whole density gradient range. The range is dynamically calculated so you don't have to guess values:

errorEstimator  coded;
name            rhoGradient;

code            #{
    Info<< "---->! custom error estimator !<----" << endl;
    error_ = 0.0;
    const auto& rho = mesh_.lookupObject<volScalarField>("rho");
    error_ == mag(fvc::grad(rho)) / dimensionedScalar("one",dimDensity/dimLength,1.0);
    scalar maxGradRho = gMax(error_);
    scalar minGradRho = gMin(error_);

    lowerRefine_ = minGradRho + 0.5*(maxGradRho-minGradRho);
    upperRefine_ =  GREAT;
    lowerUnrefine_ = minGradRho + 0.4*(maxGradT-minGradRho);
    upperUnrefine_ =  GREAT;
    if (scale) normalize(error_);
    Info<< "---->! end    error estimator !<----" << endl;
#};

from blastamr.

Yes, the method you indicated for the applicable coded is OK.

We can use the freelyPropFlame2D tutorial as a reference, which should theoretically use the densitygradient criterion, right?

We can throw the AMR effect first, give priority to ensuring that it runs normally, maybe we can find the potential cause?

from blastamr.

One possible source of reason is the calculation of the 2D mesh size. I tested the 2D and 3D damBreak separately in the tutorial study, and the 3D can be calculated, but the 2D will give an error.
My case is also 2D.

from blastamr.

Yes, apparently, *::calcDx calculates some cell dimension in x-direction, which wouldn't be nice in polyhedral cells.

# Assume name is gradientRange in constant/dynamicMeshDict
# Copy the resulting shared lib after the first updateMesh call:
cp -r dynamicCode/platforms/linux64GccDPInt32Opt/lib/libgradientRange_*.so $FOAM_USER_LIBBIN/libgradientRange.so

libs
(
   libamrDynamicFvMesh.so
   libamrIndicators.so
   libamrDynamicMesh.so
   libgradientRange.so
);

You can then copy the generated coded estimator class from dynamicCode/gradientRange and contribute it as a standalone one through a PR to this repository (with minimal changes). Although I don't recommend wasting time on trying to make the original criterion work for all cases; I'll keep this issue open and track some of the tasks I plan to focus on. Of course, I'm open to accepting any PRs which introduce new error indicators:

• drop untested/unused refinement criteria
• add common coded refinement criteria
• document the process of adding new refinement criteria

from blastamr.

Thank you for your guidance.

Actually my case uses hexahedral cells.

I will keep trying until I can use it successfully and update here in time.

from blastamr.

I added a more general gradientRange error estimator, which replaces densityGradient. Please pull the new commits for your OpenFOAM version.

I think this is a much better solution to this issue since you can choose the target field and a few more settings.

#9 sees a possible optimization opportunity which I may investigate if I find time.

from blastamr.

Closing as not active anymore; using gradientRange instead seems to work for all mesh types.

from blastamr.