Comments (7)
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.
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:
- 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.
Related Issues (10)
- Tutorial damBreak not working HOT 1
- SurfaceSampling and blastAMR HOT 1
- Compile Problem with WM_LABEL_SIZE=64 HOT 4
- blastAMR stuck in inifite loop HOT 2
- Create Protected Cells - e.g., for wall refinement HOT 3
- Turbulence Model and blastAMR
- OpenFOAM v2206 install issue HOT 5
- Reconstruction issue HOT 2
- Use cached gradient if possible in gradient-based error indicators HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from blastamr.