Fails building from source with mpiifort, at error_manager_mod

MFiX
#1

I am building mfixsolver from source to run on a cluster, and I can do this successfully for serial and dmp with gfortran. But when using mpiifort the build stops at 26% with the following error:

mfix-21.3.2/model/error_manager_mod.f(298): error #6404: This name does not have a type, and must have an explicit type.   [GETCWD]
            status = getcwd(curdir) ! Strip off project directory, eg UDF files

bilde
bilde1475×203 11.8 KB

Is this a known problem, and have an easy fix? I have tried this with intel 2017b, 2019b and 2020a, but couldn’t find any matching issues here on the forum.

#2

Hi Kjetil -

The offending code is something I added recently, to tidy up long pathnames in error messages. However getcwd is a Gfortran extension, so this does not work with Intel Fortran (which I did not test).

   295           if (filename(:src_path_offset) .EQ. __FILE__(:src_path_offset)) then
   296              short_name = filename(src_path_offset+1:)
   297           else
   298              status = getcwd(curdir) ! Strip off project directory, eg UDF files
   299              if (status .eq. 0) then
   300                 src_path_offset = len(trim(curdir))
   301                 idx = scan(curdir, '/\\', back=.TRUE.)
   302                 if (idx .ge. 0) then
   303                    src_path_offset = idx - 1
   304                 end if
   305                 if (filename(:src_path_offset) .EQ. curdir(:src_path_offset)) then
   306                    short_name = trim(filename(src_path_offset+2:))
   307                    end if
   308                 end if
   309           end if

As a quick fix, I suggest simply commenting out lines 297-308, or removing them completely, since they are not strictly necessary - this is just for error messages. For the next release I’ll rewrite this in a more portable way so that it works with ifort.

– Charles

1 Like
#3

Thanks, I got it to compile to the end by commenting out that section. Will do a test run of the exectuable shortly.

There were some warnings like this, perhaps not a problem:

/cluster/home/kjetilbi/mfix1/mfix-21.3.2/model/cartesian_grid/cut_cell_preprocessing.f: warning #5462: Global name too long, shortened from: cut_cell_preproc_mp_check_consistency_between_mesh_and_mfx_$blk.mpi_constants_mp_mpi_errcodes_ignore_ to: ell_preproc_mp_check_consistency_between_mesh_and_mfx_$blk.mpi_constants_mp_mpi_errcodes_ignore_
# 1 "/cluster/home/kjetilbi/mfix1/mfix-21.3.2/model/cartesian_grid/cut_cell_preprocessing.f"
#4

I haven’t seen that warning before - I believe symbol names in GFortran have no length limit, so this is another ifort issue. I don’t expect it to be a problem though.

I tend to favor shorter names, myself - I’d write something like check_x_y rather than check_consistency_between_x_and_y, but that’s basically a matter of style, and not wanting to wear out my wrists with extra typing. Many individuals have contributed to MFiX over the years, so there’s some variation in coding style.

Let us know if the ifort executable works. We want MFiX to be portable but we don’t do a lot of testing with non-GNU compilers.

– Charles

#5

This works too:

diff --git a/model/error_manager_mod.f b/model/error_manager_mod.f
index fab5cad43..fa17f154a 100644
--- a/model/error_manager_mod.f
+++ b/model/error_manager_mod.f
@@ -17,6 +17,9 @@ MODULE ERROR_MANAGER
    use output, only: ENABLE_DMP_LOG, FULL_LOG
    use param1, only: UNDEFINED_C
    use, intrinsic :: ISO_C_BINDING
+#if defined(__INTEL_COMPILER)
+   use ifport, only: getcwd
+#endif
 
    implicit none
#6

Just performed the first testing of ifort and mpiifort with serial, SMP and DMP respectively, and results are good. At least they seem to work as expected. I have not benchmarked the actual performance towards the GNU compilers or my local VM yet, but that would also be interesting to see. So far only tested on a single cluster node of 16 cores.

1 Like