Using a partially built WRF setup that failed, we should be able to go into the phys/ directory and manually compile to recreate and isolate the issue.
So:
	
	
	
		Code:
	
	
		# inside WRF top dir
cd phys/
# copy-paste verbatim the error line from the log file
time mpiifx -o module_firebrand_spotting_mpi.o -c -O3 -ip -fp-model precise -w -ftz -align all -fno-alias -FR -convert big_endian    -I../dyn_em  -I/home/workhorse/WRF_Intel/WRFV4.6.0/external/esmf_time_f90  -I/home/workhorse/WRF_Intel/WRFV4.6.0/main -I/home/workhorse/WRF_Intel/WRFV4.6.0/external/io_netcdf -I/home/workhorse/WRF_Intel/WRFV4.6.0/external/io_int -I/home/workhorse/WRF_Intel/WRFV4.6.0/frame -I/home/workhorse/WRF_Intel/WRFV4.6.0/share -I/home/workhorse/WRF_Intel/WRFV4.6.0/phys -I/home/workhorse/WRF_Intel/WRFV4.6.0/wrftladj -I/home/workhorse/WRF_Intel/WRFV4.6.0/chem -I/home/workhorse/WRF_Intel/WRFV4.6.0/inc -I/home/workhorse/WRF_Intel/Libs/NETCDF/include  -real-size `expr 8 \* 4` -i4  module_firebrand_spotting_mpi.f90
	 
 
If that reproduces the issue, we can almost safely assume that the issue is not due to the internal environment setup within the makefiles. In this case, we can further reduce the problem by only using the raw compiler flags rather than the MPI wrapper. To do this we can do
	
	
	
		Code:
	
	
		# Still in phys/
mpiifx -show # copy the output, I'm not doing `` or outputting to a variable so we can see everything
# now in place of mpiifx we can do
time <paste output> <rest of the compile line>
	 
 
This again should result in error if the first manual compilation did as well. Removing duplicated flags we should see (1) includes to the MPI location, (2) library location to MPI, linker options, libraries to link in like 
-lmpifort -lmpi -ldl -lrt -lpthread
We really only care about 
-lmpifort -lmpi and their respective includes. If we look in the library locations specified by 
-L<path> we should find something like "libmpifort.so" and "libmpi.so" that matches our linked libraries. If we look in the include paths (note that there is both 
<mpi path>/include and 
<mpi path>/include/mpi we should find the headers and mod files like so (my output):
	
	
	
		Code:
	
	
		/home/aislas/intel/oneapi/mpi/2021.11/include
mpi  mpicxx.h  mpif.h  mpi.h  mpiof.h  mpio.h
ls /home/aislas/intel/oneapi/mpi/2021.11/include/mpi
gfortran  mpi_base.mod       mpi_f08_callbacks.mod          mpi_f08_link_constants.mod  mpi_f08_types.mod  mpi_sizeofs.mod  pmpi_f08.mod
ilp64     mpi_constants.mod  mpi_f08_compile_constants.mod  mpi_f08.mod                 mpi.mod            pmpi_base.mod
	 
 
Assuming all that looks good, we can now effectively test if somehow the .mod file is not being found. A simple test program to use MPI:
	
	
	
		Code:
	
	
		program main
  use mpi
  integer :: ierr
  call MPI_Init(ierr)
  call mpi_finalize( ierr )
  write( *, * ) "MPI ran"
end program main
	 
 
Using the output of 
mpiifx -show from before we can compile this file (e.g. if named "mpi_test.F90" by adding 
mpi_test.F90 -o mpi_test to the rest of the command)
And if that fails, well there are problems with the compiler and .mod file it is trying to use. If it manages to compile, then the WRF source file is suspect.