Higher auto-refinement limits

[tzanio]

This is meant to address the issue where small meshes are curved but refined versions of them appear to lose the curvature in GLVis. See also this task in https://github.com/GLVis/glvis/pull/284

Command-line option to ensure minimal level of refinement to large meshes don't show as linear by default (ping: @dylan-copeland, @psocratis)?

The reasons for that behavior are the auto-refinement limits, which previously were:

• at most 16 refinement levels (auto_ref_max = 16)
• at most 20K "refined" elements to be visualized (auto_ref_max_surf_elem = 20000)

Both of these variables are set in lib/vsdata.cpp

After considering several options, I suggest that we just increase those variables to 32 and 5M respectively.

These limits seems to work fine on modern hardware and the waiting time for large meshes is a few seconds on my Mac.

@psocratis and @dylan-copeland -- do you mind trying this on your use cases and reporting if it works well?

[tzanio]

I created a poll for this, please vote here: https://github.com/GLVis/glvis/discussions/292

[najlkin]

How about this? :wink: Please test it, it cannot pass the regression tests for obvious reasons and I do not have much time for it.

[najlkin]

Now all tests run, but there are some visible differences in the zoom level interestingly 🤔 .

[justinlaughlin]

Now all tests run, but there are some visible differences in the zoom level interestingly 🤔 .

just making sure - this isn't the difference between the test.*.saved.png vs test.fail.*.saved.png files right? Those filenames are misleading (in my opinion) because the test.fail.* files are actually the output of the negative test (making sure that the tests fail when they should). All of the "negative tests" are zoomed in so that they fail.

In order to compare to the baselines you have to download the baselines separately. I'm looking at the test outputs and see some differences but I don't see any visible differences in zoom.

e.g. (test.rehmos.saved.png) left = baseline, right = test output. I manually zoomed in so its not aligned perfectly.

[najlkin]

Aha, ok, but the refinement levels are different. I am working on rebalancing that :wink:

[justinlaughlin]

I don't mean to derail this too much... but I was thinking maybe the baselines could be included as part of the artifact + the negative test outputs could be renamed into something less misleading (e.g. test.negative.*)? I think the "zoomed" failed test images are not self-explanatory without looking at the source-code, and I believe this will likely cause confusion for others in the future too haha. What do you think?

[najlkin]

I don't mean to derail this too much... but I was thinking maybe the baselines could be included as part of the artifact + the negative test outputs could be renamed into something less misleading (e.g. test.negative.*)? I think the "zoomed" failed test images are not self-explanatory without looking at the source-code, and I believe this will likely cause confusion for others in the future too haha. What do you think?

That would make a lot of sense to me 👍 I am still a bit confused how that works 🙃

[najlkin]

Heey, we are passing 🥳 I rebalanced the tests in GLVis/data#3 , which we should merge before/with this one.

[tzanio]

Remove "[DO-NOT-MERGE]" from the title?

[najlkin]

No, GLVis/data#3 must be merged first.

[najlkin]

I mean GLVis/data#3 is trivial, just needs to be synchronized with this one 😉 . So please review this and with approvals we:

1. merge GLVis/data#3
2. update the hash here for the merge commit
3. remove the label do-not-merge
4. merge this

[tzanio]

OK, I approve it 👍

[v-dobrev]

Here are some observations about the speed of the current auto-refinement choice (on Macbook pro with M2 Max chip):

• First I build MFEM in debug mode but with -Og optimization.
• I build GLVis using the defaults which is to use the same build as MFEM (i.e. debug) and the same optimization flags.
• I generate a mesh + solution with ex1 with the run ./ex1 -m ../data/square-disc-p3.mesh -o 6 (this is a mesh with triangles)
• To measure the time to load and display this mesh + solution in GLVis, I run

  time ./glvis -m ../mfem/examples/refined.mesh -g ../mfem/examples/sol.gf -k q

  and the result is (the subdivision factor chosen by GLVis is 6):

  7.870u 0.088s 0:08.34 95.3%   0+0k 0+0io 14pf+0w

  which means it tool 8.34 seconds.

• Switching to optimized build for both MFEM and GLVis results in the following output:

  3.726u 0.088s 0:04.42 85.9%   0+0k 0+0io 465pf+0w

  so it took 4.42 seconds.

• Using the output from ./ex1 -m ../data/star.mesh -o 6 (quad mesh), the timing output is (the subdivision factor chosen by GLVis is 6):

  0.983u 0.071s 0:01.40 75.0%   0+0k 0+0io 9pf+0w

  so this took 1.4 seconds. The mesh has 20480 elements which with refinement factor of 6 results in 1003520 vertices (737280 linear quads).

• Extrapolating the above numbers to 2M vertices, visualizing the result will take ~2.8 seconds.

[tzanio]

Checklist based on https://github.com/GLVis/glvis/pull/285#issuecomment-2253445609

• [x] merge https://github.com/GLVis/data/pull/3
• [x] remove the do-not-merge label
• [x] update the test/data hash here - done in https://github.com/GLVis/glvis/pull/285/commits/a37ae482d05dbb689f5ce6d8e4061bd8e723251b
• [x] check that all CI tests pass
• [x] merge this PR