DensityGradient errorEstimator issue

[starflame-Qot]

Hello, I'm back. 😊 Today I'm trying to test out this set of AMR tools that I'm really excited about.

According to my understanding, I can choose any of the error estimation methods provided to finish my case, only the effect is different.

My ideal criterion is this density gradient method. However when I use it, it errors at the first step, as shown in the image.

I can use fieldvalue, codes, etc., and here I provide my dict.

Ask for your guidance. This confuses me so much.

Thank you very much ！

[FoamScience]

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;
#};

[starflame-Qot]

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?

[starflame-Qot]

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.

[FoamScience]

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

[!TIP] You can reuse your own refinement criteria which are built with coded on the fly without re-compiling:

# 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

Then, load this new library in system/controlDict:

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

Now, pick the new criterion as an error estimator type errorEstimator gradientRange;.

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:

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

[starflame-Qot]

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.

[FoamScience]

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.

[FoamScience]

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