Can't plot mesh properly when using different refinement ratios in x and y direction

[jl2212]

Describe the bug

When I plot the mesh (alternatively Pseudocolor->density), there is a blank region around the coarse-fine boundary of the adaptive refinement mesh. The plot looks fine if I use the same refinement ratio for both x and y directions, and behaves odd when I use different refinement ratio in x and y (i.e. refinement ratio of 2 in x and 1 in y). If I set subset to only plot level1 or level 2 data, both of them look fine. However, when I plot them together (choose both level1 and level 2 in subset), the blank region appears.

Helpful additional information

• Did VisIt crash: No
• Did you get wrong results: Yes

To Reproduce

Steps to reproduce the behavior.

1. Go to 'Mesh'
2. Click on 'Mesh'
3. See error

Additionally, please attach a (zipped) sessionfile to this ticket to easily reproduce (In the viewer, use File->Save Session).

Expected behavior

The blank region in the figure should be replaced by the result at level 1.

Attachments

• Can you reproduce the bug on our test data? No
  • If so, which file?
  • If not, access to your data would be very helpful. If the data set is small, please zip and upload it as an attachment. If it is large, please provide instructions for how we can contact you to obtain this data.
• Please attach a (zipped) sessionfile to easily reproduce (In the viewer, use File->Save Session).
• Please attach any screenshots relevant to understanding the issue.

Desktop

• OS and version: Ubuntu 20.04
• VisIt Version: 3.2.2
• Server info (if applicable): session.zip

file_date.zip

Additional context

Add any other context about the problem here. Attach any (zipped) relevant files, such as data, configurations, sessionfiles, etc.

[markcmiller86]

I am seeing same behavior with your data.

It looks to me like its getting the indexing offsets incorrect when deciding which coarse zones to ghost-out in favor of finer zones that take their place when present. So, the gap you are seeing are course zones that got ghosted-out when they should not have been.

I know our internal logic handles non-uniform refinement ratios and I know its been tested in other contexts. That said, I don't know about the reading of that information from Boxlib Header file. I briefly looked at your Header. I don't precisely know the format of Boxlib Header files but I see...

HyperCLaw-V1.1
7
velx
vely
gpx
gpy
density
tracer0
vort
2
0
1
0 0
0.5 1
2
((0,0) (31,63) (0,0)) ((0,0) (63,63) (0,0))
0 0
0.015625 0.015625
0.0078125 0.015625
.
.
.

and I think our Boxlib reader determines refinement ratios from the deltas (last lines shown above).

So, either that logic in the plugin is not working or our internal AMR level precedence ghosting logic is not working. I suspect it is the plugin. What happens if your second level is something like a 2x3 refinement (e.g. not a refinement where one of the dimensions is NOT refined)?

[jl2212]

Here is the result with refinement of 2x3 refine2_3.zip

If I use 3x2 instead of 2x3, the zone that got ghosted-out shifts to the bottom

If deltas are different in the x and y direction, how does Boxlib reader determines refinement ratios? As the last line only determines the delta in one direction?

[markcmiller86]

The plugin compares deltas at each level to compute refinement ratios. Its got some rounding logic in it too. Its concievable that logic could be failing.

We need to get a look at what the plugin is doing in a debugger. Thanks for the data files, that will help. I suspect its a small issue and we'll schedule at next project meeting next week. I don't think we can take a closer look sooner than that.