Jed Brown

Yeah, I don't see harm in a separate `CeedVectorSetPrecision()`. I also envision being able to convert one way and the other even after memory has been allocated or there are...

Yeah, that's about right. I think `CeedVectorGetArray` (and relatives) can default to `CeedVectorGetArray_f64` (or whatever matches `CeedScalar`) and we can use C11 `_Generic` to make it automatically match types for...

For vectors, I mean that we can make `CeedVectorGetArray` automatically use the precision matching the provided pointer when the caller is C11 or C++, but that C99 callers will either...

We'd need to implement both the `_f32` and `_f64` variants (also so they can be bound by other languages), but C11 [`_Generic`](https://en.cppreference.com/w/c/language/generic) works something like ```c #define CeedVectorGetArray(ceed, mtype, x)...

Thanks for these detailed thoughts. My opinion is that conversion should happen in restriction and that when a vector (active or passive) does not match the compute precision, the restriction...

Good points. I'd say the conversion is *logically* part of the restriction, though an implementation could choose to associate/fuse it differently. I think before we put too much thought into...

I think this is a good model. Yes, the `array_allocated` would be per-precision. I don't think eager deallocation is necessary since I think it usually won't change the peak memory...

I think it's reasonable for QFunctions to use homogeneous precision because 1. conversion isn't free, so not great to have occur in an inner loop that needs to vectorize 2....

I just tried this and it linked correctly. I've used `PrgEnv-gnu` and `PrgEnv-aocc` in the past. ```console $ make CUDA_DIR=/opt/nvidia/hpc_sdk/Linux_x86_64/22.5/compilers CC=cc STATIC=1 V=1 make: 'lib' with optional backends: cc -I./include...

BTW, I think `nvc` inherited some bugs from PGI so you might generally have a better experience using `PrgEnv-aocc` (AMD's clang, which seems pretty close to upstream clang in behavior)....