blueprint expects connectivity to be ints, 64 bit connectivity support about ascent

[cyrush]

We can fix this, adapt in the case that connectivity does not match what VTK-m needs regardless of underlying type.

On most platforms we compile with ints are 64-bits, Windows is the main exception i know of, what platform are you compiling on?

[mlohry]

platform:

~/dev/ascent/build$ sysctl -n machdep.cpu.brand_string
Apple M2 Max
~/dev/ascent/build$ sw_vers
ProductName:		macOS
ProductVersion:		13.6.2
BuildVersion:		22G320

[cyrush]

thanks & is this with clang or gcc (I noticed you also hit #730, which seems to be unique to gcc on macos)

[mlohry]

This is with homebrew gcc-12, and the "classic" xcode linker.

#730 I've temporarily worked around by commenting out the template class FLOW_API DataWrapper<conduit::Node> declaration.

[haampie]

Seems to happen in Spack CI too:

https://gitlab.spack.io/spack/spack/-/jobs/9702178

[email protected] with GCC 11.4.0 on Ubuntu 20.04 / x86_64 with [email protected].

(Edit: ok, in that case vtk-m was forced to have 64 bits ints... nevermind)

[mlohry]

Hi @cyrush , looking back I'm unclear on this statement

On most platforms we compile with ints are 64-bits

but it looks like the build state now is that ascent requires VTKm to be built with -DVTKm_USE_DEFAULT_TYPES_FOR_ASCENT=ON which is incompatible with -DVTKm_USE_64BIT_IDS=ON, so I takethis to mean the only thing supported today is 32-bit ids, not 64, is that right? Any plans for 64 bit index support in the near future or should I work around it for now?

[cyrush]

@mlohry that is correct, I am sorry I had this flipped in my brain.

We should remove the limit as to how VTK-m is compiled and in our expected use.

We should move to admit both styles, acknowledging that one may be more performant (since VTK-m needs a primary selection)

I will see if we can get this done in 0.9.3.

We are waiting on a few key third party libs updates (raja) to release 0.9.3.

[mlohry]

Sounds good @cyrush , I'll work around it for the time being. Happy to test a branch fix when the time comes.

[cyrush]

I looked into this:
That logic was preventing VTK-m dataset with non int connectivity from being converted back to Blueprint.

Blueprint does support a broad range of integer types as connectivity arrays -- this logic in Ascent is a hold over from a while back. I am removing the guard in #1290.

Additionally, Ascent does accept non int connectivity from Blueprint meshes and can convert those to VTK-m. So round trip between these formats should not be an issue.

[cyrush]

resolved in #1290

[mlohry]

Thank you @cyrush !!