Ensure that a buffer is deleted when the last view referencing it is deleted. This is the current design, and unit tests exist to make sure this is happening, but some of the code paths that result in Group deletion may not properly exercise this. There are two separate functions: destroyView() and a destroyViewAndData(): Group::~Group() only calls the first one.

Add tests as appropriate and clarify the Doxygen (and if necessary the Sphinx docs).

We should be able to compare group foo to group bar.

Add a Fortran example that illustrates how to use Slic for logging.

A user was unable to run uberenv on their macos laptop.

It looks like we will need to add a spec for mojave here:
https://github.com/LLNL/axom/blob/develop/scripts/uberenv/spack_configs/darwin/compilers.yaml

Update Axom to use RAJA-v0.9.0. This latest version of RAJA consists of an API change. The ::atomic:: namespace is removed from all atomic operations.

A user (@gamefana) reported a possible bug in sidre when loading a datastore with attributes.

@gamefana provided the following reproducer:

void bug()
{
   uint8_t test[] = {1,2,3,4,5};

   axom::sidre::DataStore* ds = new axom::sidre::DataStore();

   ds->createAttributeScalar("attr", 10); // create the attribute

   // simple storing
   ds->getRoot()->createGroup("gr")
       ->createViewAndAllocate("foo", axom::sidre::UINT8_ID, sizeof(test));
   ds->getRoot()->getGroup("gr")
       ->createViewAndAllocate("bar", axom::sidre::UINT8_ID, sizeof(test));

   // attach views to attribute with different values
   ds->getRoot()->getGroup("gr")->getView("foo")->setAttributeScalar("attr", 1); 
   ds->getRoot()->getGroup("gr")->getView("bar")->setAttributeScalar("attr", 2);

   ds->getRoot()->getGroup("gr")->save("saveFile.hdf5");
   ds->getRoot()->getGroup("gr")->load("saveFile.hdf5"); // segfault
}

A user has requested that we create a spack package for Axom and add it to the spack repo

Currently, to log to a file, the application has to write code that looks like this:

std::ofstream file;
file.open( "log.dat" );
slic::addStreamToAllMsgLevels( new slic::GenericOutputStream(&file) );

...

file.close();

This can be simplified by something like the following

slic::addFileStream( "log.dat", bitmask );

The second argument is a bitmask that indicates the log message levels that the stream will be bound to (similar to the way the createLogger() function works.

Similarly, for steams that output information to the screen, e.g., std::cout and std::cerr.

This would also make these functions easier to be wrapped and called from Fortran.

Axom requires a C++11 compiler, so we should remove all compiler guards that provide fallbacks for cases where C++11 was not available (e.g. #ifdef AXOM_USE_CXX11).

Sidre Views are designed to represent arrays of primitive data types. Several people have wished that a View could represent objects.

This would be a substantial new feature and would require careful redesign.

A host-code linking to a CUDA-enabled Axom encountered the following linker error:

@E@nvlink error   : Entry function '_ZN3cub23RadixSortScanBinsKernelINS_21DeviceRadixSortPolicyIjiiE9Policy700EiEEvPT0_i' uses too much shared data (0xc150 bytes, 0xc000 max)
@E@nvlink error   : Entry function '_ZN3cub30DeviceRadixSortDownsweepKernelINS_21DeviceRadixSortPolicyIjiiE9Policy700ELb0ELb0EjiiEEvPKT2_PS4_PKT3_PS8_PT4_SC_iiNS_13GridEvenShareISC_EE' uses too much shared data (0xc640 bytes, 0xc000 max)
gmake: *** [Makefile:873: dolinkafteropt] Error 255

This is a known issue with the device linker (nvcc 9 & 10), where nvcc reports excess shared memory usage in kernels compiled with relocatable device code, which pushes the max amount over the limit.

This specifically has been observed with using cub::DeviceRadixSort::SortKeys, which, is used in constructing the spin::BVH

NVIDIA has been notified about the issue, but there is no known timeline for a fix.

In the interim, we should have an option to conditionally use cub::DeviceRadixSort for sorting on the device.

Currently Group::load() changes the name of the loading group. That is an error: changing the group name will change the schema the application programmer built.

We discussed adding some extra methods to class Group:

• An overload of Group::load() with an out-variable giving the group name retrieved from the loaded file
  • An application programmer could then, optionally, rename the loading Group with whatever group name is in the file
• A new method Group::loadChild() that would create a new child group with whatever is in the file.
  • We would need a string passed in to name the new group in case the file contains a root group.
  • This would be syntactic sugar for
    1. creating a new group
    2. loading the file into the group
    3. renaming the group with the contents of the out-variable containing the group name from the file

Since the default location for uberenv to generate its files is in-source (i.e. <axom>/uberenv_libs), perhaps we should add it to our .gitignore file? This could avoid accidentally adding it as a tracked folder.

BVH::find() computes the total count of candidates found as follows:

IndexType total_candidates = offsets[ numPts-1 ] + counts[ numPts-1 ]

The offsets and counts are on the GPU, but, total_candidates is computed on the CPU leading to 2 GPU page faults for each array respectively.

A better approach could be to either directly do a memory transfer of the exact number of bytes needed on the CPU, or use reduction variables.

We use asymptote to generate figures for our sphinx documentation.

Since it is not available on all platforms, we should build it as part of our devtools TPL dependencies.

It is not currently exposed as a spack package, and I ran into some build errors when I tried to add it to our axom uberenv package. Specifically, it errorred out while trying to build its manual, and I could not find a simple way to disable this directly through its build system.

Links:

• https://ctan.org/pkg/asymptote
• http://asymptote.sourceforge.net/

Here is my (unsuccessful) attempt at a spack package for asymptote:

from spack import *

class Asymptote(AutotoolsPackage):
    """FIXME: Put a proper description of your package here."""

    homepage = "http://asymptote.sourceforge.net"
    url      = "https://github.com/vectorgraphics/asymptote/archive/2.49.tar.gz"

    version('2.49',    '84d285408157d79984df742488fb32cd', preferred = True)

    #variant('gsl', default=False, description='Optional dependency on gsl')
    #variant('fftw', default=False, description='Optional dependency on fftw')

    depends_on('autoconf', type='build')
    depends_on('automake', type='build')
    depends_on('libtool',  type='build')
    depends_on('m4',       type='build')

    #depends_on('gsl',      when='+gsl')
    #depends_on('fftw',     when='+fftw')

    def autoreconf(self, spec, prefix):
        # FIXME: Modify the autoreconf method as necessary
        autoreconf('--install', '--verbose', '--force')

Several groups have said they have use cases for empty Groups in a saved data store, as structure for stuff that's not there yet.

George @gzagaris suggested looking into using numerics::Matrix or axom::Array instead of std::vector in BezierCurve and associated classes.

There are links in ReadtheDocs that are hard coded as relative to the develop branch.
This creates an issue when we try to do tagged releases of ReadtheDocs, as the links will go to the develop version of pages, instead of the version you are currently viewing.
We want these links to be consistent with the version of ReadtheDocs we are viewing.

Brought up here in PR #128.

Our make_release_tarball.sh script creates a release tarball that includes all submodules. However, this includes all the Axom Data submodule, which in most cases is not desirable.

We should probably change the script to do something along these lines:

1. Don't include axom data in the tarball by default
2. Add a flag to the script, e.g., "--with-data", which will create a separate tarball for the data

We currently guarantee equivalency when using the sidre_hdf5 protocol to save a Group then load it into another group.

• Currently the tests for equivalency after load() all have if (protocol != "sidre_hdf5") {continue;}
• Should other sidre_ protocols support equivalent save/load round trips?
• What about other protocols that (for example) might not store enough information to distinguish int bit-width? Do we need a predicate in addition to Group::isEquivalent to test if groups are "pretty close"?

I just upgraded GEOSX to the 0.3.1 release and on Lassen the axom-targets.cmake includes the following lines

set_target_properties(axom PROPERTIES
  INTERFACE_COMPILE_OPTIONS "-fopenmp=libomp"
  .
  .
  .
)

cmake winds up passing this flag to nvcc which then dies. If I comment out the `INTERFACE_COMPILER_OPTIONS line everything works.

Note: we are not building Axom with CUDA.

The current host-configs allow Axom to build with either CUDA or OpenMP. It would be convenient to be able to build Axom with both for RAJA testing.

The spin::execution_space defines a set of high-level execution policies, e.g., spin::SEQ_EXEC, spin::CUDA_EXEC, etc. and a traits class that binds the high-level execution policies to the underlying RAJA execution policies and to a corresponding Umpire memory space.

A similar strategy is employed by mint::policy for Mint's mesh-aware execution model.

Although there is overlap between mint::policy and spin::execution_space the two implementations also complement each other. For example, mint::policy_traits has mappings to corresponding RAJA kernel and synchronization policies that are not implemented by spin::execution_space. Likewise, the spin::execution_space has mappings to RAJA atomic policies and default memory space which are not implemented bymint::policy_traits.

As more Axom components, e.g., Quest, begin to support fine-grain parallelism on heterogeneous architectures, using RAJA's parallel execution model and Umpire for memory management, a similar traits class and policies will most likely be needed.

This issue proposes to unify spin::execution_space and mint::policy in axom::core so that the net functionality and future extensions are broadly available to all Axom components.

Refactor Mint execution model to improve maintainability and future extensions.

Currently code can change the name of the root group. However, it should not change from the empty string. Noah has a reason for this ("the kludge"); we didn't fully discuss it for lack of time.

Some robustness issues with the Bezier Curve intersection algorithm:

1. Overlapping curves are not handled yet.
2. Tangent intersections are not found.
3. Curves are considered half-open, intersections at endpoints are not found if they happen at the end of the interval.
4. Issues may arise in cases when control points are concentrated very closely at one endpoint for high order curves.

Update Axom to use umpire-v1.0.0. This update consists of some minor API changes.

One of the mint tests is failing in release builds on the intel@18 compiler.

>./config-build.py -hc host-configs/[email protected] -bt Release
...
>ctest -R mint_fem_single_fe -VV
...
117: [ RUN      ] mint_fem_single_fe.matrix_constructor_deepcopy
117: <axom>/src/axom/mint/tests/mint_fem_single_fe.cpp:874: Failure
117: Value of: utilities::isNearlyEqual( M.data()[i], physical_nodes[i] )
117:   Actual: true
117: Expected: false
117: <axom>/src/axom/mint/tests/mint_fem_single_fe.cpp:874: Failure
117: Value of: utilities::isNearlyEqual( M.data()[i], physical_nodes[i] )
117:   Actual: true
117: Expected: false
117: [  FAILED  ] mint_fem_single_fe.matrix_constructor_deepcopy (2 ms)
...
117:  1 FAILED TEST
1/1 Test #117: mint_fem_single_fe ...............***Failed    0.13 sec

Interestingly, it is passing in our intel@19 host-config.

A code ran into a conflicting symbol with SLIC's enumerator "Info" from wrapSLIC.h.

After talking to @gzagaris, we came to the conclusion that Shroud is not prefixing the individual emerators in the enumeration. I assume this is just an oversight in Shroud and should be fixed at that level. @ltaylor16, thoughts?

For example, this:

enum SLIC_Level {
Info
}

should be this:

enum SLIC_Level {
SLIC_Info
}

@nselliott pointed out an issue with reading external buffers in the VisIt Blueprint plugin.

The files were created with src/axom/sidre/examples/sidre_createdatastore.cpp
I found the issue with the VisIt plugin, however I am still a bit confused b/c I did not expect these fields to be written out as "external".

Here is the snippet that creates the views:

  // "x", "y", and "z" are three views into a shared Sidre buffer object that
  // holds 3 * nodecount doubles.  These views might describe the location of
  // each node in a 16 x 16 x 16 hexahedron mesh.  Each view is described by
  // number of elements, offset, and stride into that data.
  Buffer* buff = ds->createBuffer(sidre::DOUBLE_ID, 3*nodecount)->allocate();
  nodes->createView("x", buff)->apply(sidre::DOUBLE_ID, nodecount, 0, 3);
  nodes->createView("y", buff)->apply(sidre::DOUBLE_ID, nodecount, 1, 3);
  nodes->createView("z", buff)->apply(sidre::DOUBLE_ID, nodecount, 2, 3);
  // _first_example_nodes_end

(With the fix) in VisIt I am definitely reading them as external views from the HDF5 file:

loading mesh/coordsets/coords/values/x as sidre external view
relay:io::hdf5_read domain 0 : datagroup_0000000/sidre/external/mesh/coordsets/coords/values/x

Is this expected? I expected them to simply be a view into a known buffer.

@kennyweiss @agcapps any thoughts?

A user has requested a new spatial query to find a set of candidate elements from a mesh whose BoundingBoxes intersect a given Ray.

Request Details

• The input is a mesh containing a custom type of high order elements.
• They do not require us to develop a representation for this element type.
• They are able to provide the bounding box of each element
• They are also able to compute the exact intersection of a ray with one of their elements
• They are looking for us to provide a simple API that allows them to
  • build a spatial index over a collection of element bounding boxes
  • pose a query to the index that finds the indices of the elements whose bounding boxes intersect a given ray.
• For the purposes of this query, we can assume that the entire mesh is resident on a single rank. I.e. we do not need to worry about MPI communications.

Available functionality

• The spin component provides several spatial indices that can be built over a collection of axis-aligned bounding boxes. E.g. BVH tree, ImplicitGrid, ...
• primal already has an algorithm to determine if a Ray intersects an axis-aligned BoundingBox
  

  axom/src/axom/primal/operators/intersect.hpp

  Lines 77 to 88 in 975fc51

  	/*!
  	* \brief Computes the intersection of the given ray, R, with the Box, bb.
  	* ip the point of intersection on R.
  	* \return status true iff bb intersects with R, otherwise, false.
  	*
  	* Computes Ray Box intersection using the slab method from pg 180 of
  	* Real Time Collision Detection by Christer Ericson.
  	*/
  	template < typename T, int DIM >
  	bool intersect( const Ray< T,DIM > & R,
  	const BoundingBox< T,DIM > & bb,
  	Point< T,DIM > & ip)

Missing functionality

• We do not currently have the capability to traverse a spatial index to find the set of candidate elements that intersect a Ray. This will have to be implemented to satisfy this request.
• We will also need a simple API for them to construct and query the spatial index. This should be similar to our quest_inout and quest_signed_distance API

This flag is bleeding into C/Fortran files and causing a lot of warnings in gcc 8.1+

if(C_COMPILER_FAMILY_IS_GNU AND CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL "8.1")
if (ENABLE_FORTRAN)
blt_add_target_compile_flags(TO sparsehash FLAGS
$&lt;$&lt;NOT:$<COMPILE_LANGUAGE:Fortran>>:-Wno-class-memaccess>)
else()
blt_add_target_compile_flags(TO sparsehash FLAGS -Wno-class-memaccess)
endif()
endif()

When abortOnError is enabled, Slic should write a panic file on the given rank that emits the error before calling MPI_Abort()

We need an example of how to use this in Axom documentation.

A user (@gamefana) reported a memory leak in sidre::AttrValues.

AttrValues has a member m_values:

That can be initialized here:

But, it is not being deleted anywhere.

The blt_list_append() macro has the following signature:

blt_list_append( TO _list 
                 ELEMENTS _elem1 _elem2 
                 IF _cond )

This is a reminder to check that the following two uses have the same semantics:

blt_list_append( TO _list ELEMENTS _elem1 _elem2 IF _cond ) 
blt_list_append( TO _list ELEMENTS _elem1 _elem2 IF ${_cond} )

I suspect that the former might return true when the variable exists, regardless of its value, which is not the desired behavior.

Note: Both forms work with cmake's if(...) macro, but blt_list_append is different.

In either event, we should be consistent with how we use this macro throughout the axom build system.

The Python Software foundation is sunsetting support for python2.
See: https://www.python.org/doc/sunset-python-2

We need to:

• convert Axom's python scripts to python3
• ensure that our TPLs depend on python3 in our uberenv setup
• ensure that we are running uberenv and other scripts through python3

In GEOSX we have an multidimensional array class with similar functionality to the RAJA::View in that it can permute the layout of the data. As part of our integrated testing we compare our sidre restart files with a baseline and we use a common set of baselines across all our platforms. In order to compare results across platforms our comparison script needs to reorder the data to match the layout of the baseline. To do this it needs both the dimensions of the data and their permutations.

View lets you describe the data with a shape and in my first pass I tried to hijack the shape to also include the permutation. I didn't realize that when you describe the data using the shape View calculates the number of entries for you as well so this doesn't work. One solution would be to add a method View* apply( TypeID type, IndexType num_elems, int ndims, IndexType* shape ) where num_elems is used to override the number of values calculated from the shape. However this seems pretty hackish to me so I propose adding a new member std::vector<IndexType> m_permutation and method View* apply( TypeID type, int ndims, IndexType* shape, IndexType* permutation ).

In src/axom/core/Types.hpp we have:

 #if defined(AXOM_USE_64BIT_INDEXTYPE) && !defined(AXOM_NO_INT64_T)
 using IndexType = int64;
 #else
 using IndexType = int32;
 #endif

And in src/axom/sidre/core/SidreTypes.hpp we have:

 typedef SIDRE_IndexType IndexType;

SIDRE_IndexType is elsewhere defined as int64_t. We should define IndexType in only one place.

A mesh face can have at most two adjacent cells, C1 and C2. By convention the face is oriented according to an outward facing normal with respect to C1.

However, for structured meshes this convention is not enforced. For example, in 2D:

• All I-Faces normals are pointing to the (+I) direction
• All J-Faces normals are pointing to the (-J) direction

This can be problematic for operations that rely on the convention.

This should be relatively straight-forward to fix, by carefully handling the left-most boundary.

Axom's current version of the conduit third-party library ([email protected] ) has a known compatibility issue with Axom on macos related to 32-bit and 64-bit integer types.

We should update it to a newer version, e.g. [email protected].

See: #46, #49

In sidre and spio, there is a function to automatically generate the "blueprint index" from a "mesh blueprint"-conforming group in the sidre hierarchy. This is used by Visit's mesh blueprint plugin, to visualize mesh data output by sidre.

In the current implementation, the function takes the name of the mesh as one of its parameters ("mesh_name"), but for hdf5 files, it should really be using the path to the mesh.

There might need to be some logic in the function's implementation to correct the provided path for hdf5 files. (Possibly because hdf5 renames the top-level group?)

See:

• https://llnl-conduit.readthedocs.io/en/latest/blueprint_mesh.html

• axom/src/axom/sidre/core/DataStore.hpp

  Lines 375 to 400 in b8d1ae4

  	/*!
  	* \brief Generate a Conduit Blueprint index based on a mesh in stored in
  	* this DataStore.
  	*
  	* If this DataStore contains data for a mesh that adheres to Conduit's
  	* Blueprint format, this method genearates a Blueprint index and stores
  	* it at a specified locaiton within this DataStore. It uses as input a
  	* path to a representative domain from that mesh.
  	*
  	* The domain must be held in a Group stored in this DataStore. The location
  	* of this Group is specified by the domain_path argument. The generated
  	* Blueprint index will be stored in a newly-created Group that will be
  	* located at the path specified by the index_path argument.
  	*
  	* \param domain_path path to a domain stored in the Blueprint format
  	* \param mesh_name name for the mesh to be described
  	* \param index_path path where the Blueprint index will be written
  	* within this DataStore
  	* \param num_domains number of domains in the mesh
  	*
  	* \return true if the Blueprint index is successfully generated.
  	*/
  	bool generateBlueprintIndex(const std::string& domain_path,
  	const std::string& mesh_name,
  	const std::string& index_path,
  	int num_domains);

• axom/src/axom/sidre/spio/IOManager.hpp

  Lines 165 to 187 in b8d1ae4

  	/*!
  	* \brief write a Conduit Blueprint index to an existing root file
  	*
  	* Given a domain that adheres to Conduit's Blueprint format, this method
  	* generates a Blueprint index and writes it to an existing root file.
  	*
  	* The domain must be stored in a Group located at the path in the
  	* DataStore specified by domain_path argument.
  	*
  	* This currently only works if the root file was created for protocol
  	* sidre_hdf5.
  	*
  	* \param datastore DataStore containing Groups that hold domains
  	* that adhere to the Blueprint format
  	* \param domain_path path to the domain in the DataStore that will be
  	* used to generate a Blueprint index
  	* \param file_name name of existing root file
  	* \param mesh_name name of the mesh described by the Blueprint index
  	*/
  	void writeBlueprintIndexToRootFile(DataStore* datastore,
  	const std::string& domain_path,
  	const std::string& file_name,
  	const std::string& mesh_name);

In our sparsehash setup, we have the following:

This errors out for [email protected]+ when Fortran in not enabled with the following message:

CMake Error at cmake/blt/cmake/BLTPrivateMacros.cmake:230 (target_link_libraries):
  Error evaluating generator expression:

    $<COMPILE_LANGUAGE:Fortran>

  $<COMPILE_LANGUAGE:...> Unknown language.

The lack of a success return value was a mistake in our design.

Quest provides a function to "weld" vertices in a triangle mesh that are closer than a user- provided distance threshold. This function identifies sets of vertices at the same location, removes duplicate vertices and updates the vertex indices in the mesh's connectivity array.

We've had requests from several users to generalize this capability to more types of meshes. Specifically, this should handle unstructured quad meshes in 2D and 3D.

Based on discussions with these users, something along the lines of the following interface would be ideal:

bool weldMeshVertices(         
          array<double>& x,           // [inout] x-coords of vertex positions
          array<double>& y,           // [inout] y-coords of vertex positions
          array<double>& z,           // [inout] z-coords of vertex positions
          array<int>& connectivity    // [inout] vertex indices of mesh elements
          double eps                  // distance threshold for welding
         );                           // return true if successful

where the weldMeshVertices() function would take an array of vertex positions and the connectivity array of the mesh, and return the resultant welded mesh vertices and connectivity using the provided input arrays.

Note that the welding operation does not require knowledge of the cell types since it is merely relabeling the vertex indices.

We should check that we are properly using CMAKE_SOURCE_DIR and PROJECT_SOURCE_DIR when Axom is used as a submodule of another project (and similarly for CMAKE_BINARY_DIR vs. PROJECT_SOURCE_DIR).

An example of incorrect usage is in AxomConfig.hpp, where we set AXOM_SRC_DIR to CMAKE_SOURCE_DIR, which points AXOM_SRC_DIR to the root of the host project, rather than to axom.

Mike Collette reports uncrustify running during a normal build of Axom, which is causing it to fail.

That was a surprise to me, I thought style checks were opt in via specific targets.

Working on getting more info from Mike.

The current bgq host-configs are not compatible with our newest version of conduit and need to be regenerated.

Our uberenv script is currently failing to configure the raja and umpire packages during a check of the SYS_TYPE environment variable when this variable does not exist.

Looks like we need to change lines of the form:

to

 if 'bgq' in os.getenv('SYS_TYPE', ""):

The Logger::logMessage() method calls flushStreams() for ERROR and WARNING messages. In the context of MPI applications, that use MPI-aware LogStream instances, e.g., SynchronizedStream or LumberjackStream, the call to flushStreams() is a collective operation. This makes logging of all ERROR and WARNING messages a collective operation. However, this behavior is opaque to the application developer, making it easy to write erroneous code that hangs.

For example, the following will always hang:

SLIC_ERROR_IF( rank==0, "error from rank 0" );

Instead of hiding the call to flushStreams() inside the Logger::logMessage(), flushStreams() must be placed within application-level macros that better indicate that the call is collective.

For example:

SLIC_ALL_ERROR()
SLIC_ALL_WARNING()

Need some sort of asynchronous coordination across all MPI ranks

Attempting to build on rzansel using the [email protected]_nvcc_xlf.cmake and enabling Fortran leads to the following configure error:

-- MPI Support is ON
-- Enable FindMPI:  ON
-- Found MPI_C: /usr/tce/packages/spectrum-mpi/ibm/spectrum-mpi-rolling-release/lib/libmpiprofilesupport.so;/usr/tce/packages/spectrum-mpi/ibm/spectrum-mpi-rolling-release/lib/libmpi_ibm.so
-- Found MPI_CXX: /usr/tce/packages/spectrum-mpi/ibm/spectrum-mpi-rolling-release/lib/libmpiprofilesupport.so;/usr/tce/packages/spectrum-mpi/ibm/spectrum-mpi-rolling-release/lib/libmpi_ibm.so
-- Unable to determine MPI from MPI driver /usr/tce/packages/spectrum-mpi/spectrum-mpi-rolling-release-clang-8.0.0/bin/mpif90
CMake Error at /usr/WS1/axom/thirdparty_libs/builds/2019_08_27_14_07_53/clang-8.0.0_nvcc_xlf/cmake-3.9.6/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find MPI_Fortran (missing: MPI_Fortran_LIBRARIES
  MPI_Fortran_INCLUDE_PATH)
Call Stack (most recent call first):
  /usr/WS1/axom/thirdparty_libs/builds/2019_08_27_14_07_53/clang-8.0.0_nvcc_xlf/cmake-3.9.6/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE)
  /usr/WS1/axom/thirdparty_libs/builds/2019_08_27_14_07_53/clang-8.0.0_nvcc_xlf/cmake-3.9.6/share/cmake-3.9/Modules/FindMPI.cmake:640 (find_package_handle_standard_args)
  cmake/blt/cmake/thirdparty/SetupMPI.cmake:37 (find_package)
  cmake/blt/cmake/thirdparty/SetupThirdParty.cmake:29 (include)
  cmake/blt/SetupBLT.cmake:112 (include)
  CMakeLists.txt:51 (include)

This config points to the following Fotran MPI wrapper:

/usr/tce/packages/spectrum-mpi/spectrum-mpi-rolling-release-clang-upstream-2019.03.26/bin/mpif90

Taking a closer look at this with @white238 , we determined that this wrapper attempts to use a compiler that does not exist, leading to this issue. Notified J. Gyllenhaal about this.