non-multithreaded parscalar build failed due to missing omp.h

[RJHudspith]

Hi, I just pulled the master and it seems there is a problem in compiling without multi-threading. I used this option: --enable-parallel-arch=parscalar

And the compilation quickly fails with errors like ./include/qdp_parscalar_specific.h:538:14: error: there are no arguments to ‘omp_get_thread_num’ that depend on a template parameter, so a declaration of ‘omp_get_thread_num’ must be available [-fpermissive]

This can be fixed with an

include

at the top of qdp_parscalar_specific.h as long as there is an available version of omp.h. Its existence could be checked in the configure with something like: AC_CHECK_HEADERS([omp.h],[],AC_MSG_ERROR([We need omp.h]))

Best, Jamie

[martin-ueding]

I don't think that one would use this code without OpenMP, especially since you are already building it with MPI. An additional warning is certainly helpful in the process of tweaking compiler flags, though.

Some USQCD projects have a really outdated master, so always check whether there is a devel which is more recent. With QDP++ this does not seem to be the case, but certainly for Chroma and QPhiX.

[RJHudspith]

Wait, I am a little confused. I don't see why you would expect a pure MPI build to also require a header from a multi-threading library such as openMP as these are different paradigms. I was not compiling a hybrid build and so this header (omp.h) and a version of omp_get_thread_num should never be required for a pure MPI compilation. I guess that was my point. Including the header and a check in configure.ac seems like an ugly workaround in my opinion.

[martin-ueding]

I think that a pure MPI build does not make so much sense. Having multiple MPI tasks on a single node can make sense with dual-socket mainboards. But within one socket OpenMP is much more efficient than MPI parallelization. I haven't made the decisions on this, but I would just guess that whoever made it just assumed that people were just going to use it with multiple threads once they are on a supercomputer utilizing MPI.

But likely I just haven't thought about the use case of a pure MPI build without OpenMP. When would one use this?

Independent of that the software should either clearly not offer a non-hybrid build or support it. Not supporting it and not having a clear message is bad.

[kostrzewa]

I think that a pure MPI build does not make so much sense. Having multiple MPI tasks on a single node can make sense with dual-socket mainboards. But within one socket OpenMP is much more efficient than MPI parallelization. I haven't made the decisions on this, but I would just guess that whoever made it just assumed that people were just going to use it with multiple threads once they are on a supercomputer utilizing MPI.

This is highly architecture dependent...

[grokqcd]

Fixed. I ran into this issue myself in unrelated developments. There was an unguarded call to omp_get_num_threads() in qdp_parscalar_specific.h which should have been hidden within qdp_dispatch.* . The call to the num_threads was to check if a critical code segment should be entered. Now appropriately hidden so that --enable-openmp has to be used in configure.