Problems switching barb or flow renderer between 2D and 3D variables

[clyne]

To reproduce:

1. Load katrina and enable the barb renderer with 3D data (U,V,W variables). Hurricane Katrina data can be found here.
2. Change variable selector from 3D to 2D (U10, V10 variables)
3. Change the horizontal geometry sliders
4. Switch back to 3D variables. Nothing will be drawn. Note that the upper extent of the Z coordinate on the Geometry tab is 0.0

Similar behavior occurs with flow renderer.

[clyne]

Now as soon as the variable selector is changed from 3D to 2D an error is thrown: extents of the selected variable are out of range.

[sgpearse]

Bizarre note on this bug:

It only presents itself on installer builds. It does not present itself when running a source build regardless of setting Release or Debug mode.

Scratch that.

[sgpearse]

Seems to be a DataMgr regression, so I'll reassign to @clyne for now.

[clyne]

@sgpearse what indication do you have that this is a problem with the DataMgr?

[sgpearse]

@clyne - It's a bit of a rabbit hole.

The error message is coming form DataMgr.cpp:977. This is due to a return value of "1" from the function _find_bounding_grid(). I wish I knew how to copy/paste a sensible stack trace on github but formatting lldb's output makes GitHub choke.

My indication is through the following trace:

1. Box::GetExtents() <-- This was recently modified on January 6, 2022
2. RenderParams::GetMapperFunc()
3. DataMgr::GetDataRange()
4. DataMgr::_findbounding_grid()

To reproduce the trace:

1. Build Vapor with debug flags
2. Run it on OSX with lldb or your chosen debugger
3. Set a breakpoint at DataMgr.cpp:2770
4. Load any dataset and create/enable a barb renderer
5. Change the dimensionality from 3D to 2D
6. observe the stack trace with "bt" if using lldb

[clyne]

Got it. Thanks.