Block-structured multi level mesh about ascent HOT 10 OPEN

@pgrete

• Ghost zones need to be presented using field that tells Ascent which zones are duplicated. (It looks like you are providing an ascent_ghosts field.

• AMR relationships need to be presented using nestsets, and it will translate to augment the ghost zone indicator so ghosting can be used to only show the finest levels.

The easiest way to debug Ascent ghosts would be to use the blueprint extract to save HDF5 files and look at them in VisIt.
If you need pointers on how to do this let me know.

from ascent.

@cyrush Nestsets are only used when there are grids that have overlapping non-ghost zones, right? We have a multiblock mesh that doesn't overlap (except for the ghost zones, which we've indicated with ascent_ghosts).

from ascent.

@BenWibking that is correct - I wrongly thought this was overlapping AMR.

ascent_ghosts should be all you need to present.

from ascent.

@cyrush I figured out what went wrong.
I enabled "field filtering" by default.
It seems that the ascent_ghost field has been filtered and was thus not known.
Once I disabled field filtering, plotting looks fine.

Is this intended behavior (or considered a bug)?
My (naive) assumption is that hard-coded "meta" fields like ascent_ghost should not fall under the filter category and always be passed on.

Also, can I override the current behavior from within the application (assuming that all our actions will always be defined in external runtime yaml files)?

from ascent.

Oh yikes, that's an unintended bug. Given this , it makes sense why this was a bit of a mystery.

Thanks so much for tracking this down.

We will make sure that ascent_ghosts (or any name identified as ghost field) survives field filtering.

from ascent.

@pgrete I merged a fix in #1109 that should make sure the ghost field survives.

from ascent.

One more question regarding the ascent_ghost field: Does it need to live on the host?
I tried to allocate it in device memory (assuming that this will result in even faster rendering given that the data is also on the device), but I'm just getting segfaults immediately:

Loguru caught a signal: SIGSEGV
Stack trace:
15      0x55a93567f9fe ../../build/example/advection/advection-example(+0x429fe) [0x55a93567f9fe]
14      0x7fea018d8083 __libc_start_main + 243
13      0x55a9356713e6 ../../build/example/advection/advection-example(+0x343e6) [0x55a9356713e6]
12      0x55a9357474e1 ../../build/example/advection/advection-example(+0x10a4e1) [0x55a9357474e1]
11      0x55a9358058ef ../../build/example/advection/advection-example(+0x1c88ef) [0x55a9358058ef]
10      0x55a9358f4cd4 ../../build/example/advection/advection-example(+0x2b7cd4) [0x55a9358f4cd4]
9       0x7fea029750ac ascent::Ascent::execute(conduit::Node const&) + 380
8       0x7fea0299d2e7 ascent::AscentRuntime::Execute(conduit::Node const&) + 983
7       0x7fea0189cc5d flow::Workspace::execute() + 829
6       0x7fea02baa6e7 ascent::runtime::filters::VTKHGhostStripper::execute() + 135
5       0x7fea029a2245 ascent::DataObject::as_vtkh_collection() + 213
4       0x7fea02b83a02 ascent::VTKHDataAdapter::BlueprintToVTKHCollection(conduit::Node const&, bool) + 1138
3       0x7fea02b83336 ascent::VTKHDataAdapter::BlueprintToVTKmDataSet(conduit::Node const&, bool, std::string const&) + 1702
2       0x7fea02b7710b ascent::VTKHDataAdapter::AddField(std::string const&, conduit::Node const&, std::string const&, int, int, vtkm::cont::DataSet*, bool) + 1243
1       0x7fea01f1fe70 conduit::Node::to_float64_array(conduit::Node&) const + 352
0       0x7fea01ea4bc5 conduit::DataArray<double>::set(conduit::DataArray<int> const&) + 53
2023-03-15 13:27:40.720 (   0.507s) [main thread     ]                       :0     FATL| Signal: SIGSEGV
Segmentation fault (core dumped)

from ascent.

Is your ghost field an integer type?

I assume yes, which is ok but also why Ascent is trying to access on the host.
It is trying to convert to a floating point type.

We need to add zero copy cases for integer types. (float32 and float64 are supported.)

from ascent.

Changing the type to float indeed fixed the issue.

from ascent.

Thanks, I'll add an issue ticket to address this limitation in the future.

from ascent.