A user reported an error in how we handle execution policy guards in the signed distance API.
Specifically, we're using #ifdef in some cases but should actually be using #ifndef guards.
See #1191 for a proposed bugfix.
(Specifically, the changes to signed_distance.cpp)
We might consider using this as an opportunity to clean up this section of the code.
Specifically, should the SignedDistExec::OpenMP enum case be defined in configurations that don't have OpenMP? Or would it be better to avoid this problem by either
enum class SignedDistExec
{
CPU = 0
#if defined(AXOM_USE_OPENMP) && defined(AXOM_USE_RAJA)
, OpenMP = 1
#endif
#if defined(AXOM_USE_GPU) && defined(AXOM_USE_RAJA)
, GPU = 2
#endif
};
- or, keeping the enum as it is and adding an
isValid(SignedDistanceExec) method that can better isolate the checks
This might depend on expectations about how users are using the SignedDistanceExec enum.
A user reported an error in how we handle execution policy guards in the signed distance API.
Specifically, we're using
#ifdefin some cases but should actually be using#ifndefguards.See #1191 for a proposed bugfix.
(Specifically, the changes to
signed_distance.cpp)We might consider using this as an opportunity to clean up this section of the code.
Specifically, should the
SignedDistExec::OpenMPenum case be defined in configurations that don't have OpenMP? Or would it be better to avoid this problem by eitherE.g. something like changing the enum definition from this
https://github.com/LLNL/axom/blob/9ea7c93c4b802b4da444727b995e4f02df344b3a/src/axom/quest/interface/signed_distance.hpp#L87-L93
to
isValid(SignedDistanceExec)method that can better isolate the checksThis might depend on expectations about how users are using the
SignedDistanceExecenum.