Adaptive mesh refinement in specific region of computational domain

[mameehan5]

Hi all,

Is there any interest in combining the static and adaptive mesh refinement approaches? I am finding many instances where I would like to adaptively refine only a specific region of the flow with a certain criteria. It would look something like:

amr.gradrho.max_level = 2
amr.gradrho.adjacent_difference_greater = 0.01
amr.gradrho.field_name = density
amr.gradrho.in_box_lo = -1.0 -1.0 0.0
amr.gradrho.in_box_hi =  1.0  1.0 2.5

This would only tag density differences within the specified in_box region.

Thanks! Mike

[drummerdoc]

Hey Mike, seems like the text and the suggested inputs are not aligned, in that your inputs could be adaptive if the density is changing over time. If you want static refinement in regions, there are couple ways to do it, but based on your inputs above, you could simply refine within a subbox when the density is greater than zero (which is always, hopefully). If this is your only criteria, you could set the refinement interval to be 1000000 or something so that it never checks again. But combining a criteria that never changes which points it tags with another that is dynamic is not an issue. Perhaps I'm not understanding what you want though. Let me know

[mameehan5]

Thanks for the reply Marc! Sorry I was not clear. I was thinking of a feature that allows dynamic refinement but only to a subset of the computational domain. In my example, if the computational domain was, say

geometry.prob_lo     = -1.5 -1.5 0.0
geometry.prob_hi     =  1.5  1.5 3.0

the inputs provided above would adaptively refine density variations within the specified region, leaving the outer bounds of the computational domain unresolved. Is there a way to do this with the current implementation? This is not necessarily an issue as opposed to a feature.

[drummerdoc]

Your usage seems correct. each refinement criteria takes optional arguments "in_box_lo" and "in_box_hi" that define the physical coordinates of where that criteria will be applied. It should not tag any points outside that box (except by way of the "n_error_buf" functionality, and this box defaults to the entire domain. Let me know if you see behavior suggesting that it doesn't work as expected.

[mameehan5]

Yep, that is exactly how I was thinking this would work. But, the currently implementation of LMeX supports either AMR or specification of in_box, not simultaneously. I posted this issue as a question of if there was interest in this sort of behavior. I wrote a bit of hack way to do this a while ago, and if there was broader interest, I could flush it out and submit a PR. It would probably be written in a more sustainable way, however, if a current dev implemented this.

[drummerdoc]

I think I agree with you, but this is what I'd call a bug. Yes, for each specific refinement criteria, the tagging should work only on the intersection of each box with the m_domain_box at at that level associated with that criteria, and m_domain_box should default to the entire problem domain box. I'm not sure how it became what it is now, but I'm good with being able to set the refinement criteria box as a subdomain in physical coordinates of the entire domain, and being able to set a condition within that box that is always true (such as density > -1). IT would be great if you submitted a PR to AMReX and tag me as a reviewer. Thanks for pointing that out!

[mameehan5]

Okay, sounds good. I am going to be out of the office for the next few weeks, but I will put it on the todo list for when I get back!

[drummerdoc]

Excellent. In theory, it should be a lot faster if the subbox is a tiny fraction of the domain too (although it's rare that regrinding takes too much time anyway). thanks for pointing this out.