Closed tzanio closed 1 month ago
I created a poll for this, please vote here: https://github.com/GLVis/glvis/discussions/292
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.
Now all tests run, but there are some visible differences in the zoom level interestingly 🤔 .
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.
Aha, ok, but the refinement levels are different. I am working on rebalancing that :wink:
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?
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 🙃
Heey, we are passing 🥳 I rebalanced the tests in GLVis/data#3 , which we should merge before/with this one.
Remove "[DO-NOT-MERGE]" from the title?
No, GLVis/data#3 must be merged first.
I mean GLVis/data#3 is trivial, just needs to be synchronized with this one 😉 . So please review this and with approvals we:
OK, I approve it 👍
Here are some observations about the speed of the current auto-refinement choice (on Macbook pro with M2 Max chip):
-Og
optimization.ex1
with the run ./ex1 -m ../data/square-disc-p3.mesh -o 6
(this is a mesh with triangles)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.
3.726u 0.088s 0:04.42 85.9% 0+0k 0+0io 465pf+0w
so it took 4.42 seconds.
./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).
Checklist based on https://github.com/GLVis/glvis/pull/285#issuecomment-2253445609
do-not-merge
label
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
The reasons for that behavior are the auto-refinement limits, which previously were:
auto_ref_max = 16
)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?