-
Notifications
You must be signed in to change notification settings - Fork 369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add alternative error tagging class #1166
Add alternative error tagging class #1166
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The functionality looks great. I have some minor comments.
amrex::ParallelFor(bx, | ||
[=] AMREX_GPU_HOST_DEVICE (int i, int j, int k) noexcept | ||
{ | ||
GpuArray<Real,AMREX_SPACEDIM> pt = {D_DECL(plo[0]+(i+0.5)*dx[0], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@drummerdoc @WeiqunZhang Getting a AppleClang (SP) and DPC++ (DP) compile error on this of the form:
Src/AmrCore/AMReX_ErrorList.cpp:318:52: error: non-constant-expression cannot be narrowed from type 'double' to 'float' in initializer list [-Wc++11-narrowing]
in WarpX.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we can cast the i
, j
, k
with Real(i)
etc. and add _rt
in + 0.5
as + 0.5_rt
to fix it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's try this: #1180
The refinement scheme from AMReX-Codes/amrex#1166 is implemented. Rather than using the Fortran tagging namelist, applications may use the inputs file. The scheme looks like: ``` amr.refinement_indicators = dens temp amr.refine.dens.max_level = 1 amr.refine.dens.value_greater = 2.0 amr.refine.dens.field_name = Density amr.refine.temp.max_level = 2 amr.refine.temp.value_less = 1.0 amr.refine.temp.field_name = Temp ``` amr.refinement_indicators is a list of user-defined names for refinement schemes. For each defined name, amr.refine.<name> accepts predefined fields describing when to tag. In the current implementation, these are max_level (maximum level to refine to), start_time (when to start tagging), end_time (when to stop tagging), value_greater (value above which we refine), and value_less (value below which to refine), and field_name (name of the string defining the field in the code). If a refinement indicator is added, either value_greater or value_less must be provided. (In the future we will support other refinement schemes such as gradients.) A wdmerger setup is converted to the new scheme as a test.
* Add alternative error tagging class * Address PR comments
## Summary The new error tagging scheme from #1166 is modified to allow the threshold value to vary by level. Using the example there, if we did: ``` amr.refinement_indicators = flame_tracer lo_temp amr.refine.flame_tracer.max_level = 3 amr.refine.flame_tracer.value_greater = 1.e-6 1.e-5 amr.refine.flame_tracer.field_name = Y(H) amr.refine.lo_temp.max_level = 2 amr.refine.lo_temp.value_less = 1000. amr.refine.lo_temp.field_name = temp ``` Then level 0 would be tagged for refinement for Y(H) >= 1.e-6, while level 1 and all higher levels would be tagged for refinement for Y(H) >= 1.e-5. (If a value for every level is not provided, we assume the last value holds for all remaining levels, similar to how we treat quantities like amr.n_error_buf.) ## Additional background This will help for cases where a field varies substantially on the domain and you want to have better control over refinement so that you don't have too many zones. ## Checklist The proposed changes: - [ ] fix a bug or incorrect behavior in AMReX - [x] add new capabilities to AMReX - [ ] changes answers in the test suite to more than roundoff level - [ ] are likely to significantly affect the results of downstream AMReX users - [ ] are described in the proposed changes to the AMReX documentation, if appropriate
This PR introduces an alternative to ErrorRec/ErrorList for managing error tagging. It supports building (GPU-SAFE) tagging functions on the fly via ParmParse inputs, something like:
Then later, they are called to tag as:
At the moment, standard support is provided for BOX (over physical region), LESS, GREATER, GRAD, as well as a special one, VORT, for vorticity over AMR levels. and USER. USER is close to AMReX-classic error tagging functions. In the initial implementation, the inputs can specify a start and stop time, max level for each criteria to apply to, the field to base the decision on, and a physical box to limit the checking. ParmParse input can be organized as follows, e.g.:
This will tag regions up to level 3 where Y(H)>1.e-6 and up to level 2 where temp<1000.