compiling on NAS

[chesswright]

I was trying to compile pFUnit 4.4.2 on NAS with ifort 2021.6.0 20220226 and got the following errors

[  9%] Building Fortran object extern/fArgParse/extern/gFTL-shared/src/v1/CMakeFiles/gftl-shared-v1.dir/Integer32Complex128Map.F90.o
/home3/wbwright/pFUnit4/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v1/templates/altSet_impl.inc:549.6:
    Included at /home3/wbwright/pFUnit4/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v1/templates/map.inc:133:
    Included at /home3/wbwright/pFUnit4/extern/fArgParse/extern/gFTL-shared/src/v1/Integer32Complex128Map.F90:12:

      end_%reference=>this
      1
Error: Different types in pointer assignment at (1); attempted assignment of CLASS(set2) to TYPE(set2)
/home3/wbwright/pFUnit4/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v1/templates/altSet_impl.inc:537.6:
    Included at /home3/wbwright/pFUnit4/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v1/templates/map.inc:133:
    Included at /home3/wbwright/pFUnit4/extern/fArgParse/extern/gFTL-shared/src/v1/Integer32Complex128Map.F90:12:

      begin%reference=>this
      1
Error: Different types in pointer assignment at (1); attempted assignment of CLASS(set2) to TYPE(set2)
/home3/wbwright/pFUnit4/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v1/templates/altSet_impl.inc:164.6:
    Included at /home3/wbwright/pFUnit4/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v1/templates/map.inc:133:
    Included at /home3/wbwright/pFUnit4/extern/fArgParse/extern/gFTL-shared/src/v1/Integer32Complex128Map.F90:12:

      find%reference => this
      1
Error: Different types in pointer assignment at (1); attempted assignment of CLASS(set2) to TYPE(set2)
/home3/wbwright/pFUnit4/extern/fArgParse/extern/gFTL-shared/src/v1/Integer32Complex128Map.F90:22.7:

   use gFTL1_Integer32Complex128Map
       1
Fatal Error: Can't open module file 'gftl1_integer32complex128map.mod' for reading at (1): No such file or directory
make[2]: *** [extern/fArgParse/extern/gFTL-shared/src/v1/CMakeFiles/gftl-shared-v1.dir/Integer32Complex128Map.F90.o] Error 1
make[1]: *** [extern/fArgParse/extern/gFTL-shared/src/v1/CMakeFiles/gftl-shared-v1.dir/all] Error 2
make: *** [all] Error 2

[tclune]

Hmm. I'm cc'ing @mathomp4 to see if he has any thoughts. We certainly build with 2021.6 on the Goddard systems, but @mathomp4 may have built this at NAS recently as well.

At first glance, this appears to be a latent bug that is being detected with more recent Intel compilers, and should be easily fixed. But at the same time this compiles with NAG, which is quite strict about such things, so maybe I am missing something in my quick dive. If you want to attempt a quick workaround, you could try changing the line at https://github.com/Goddard-Fortran-Ecosystem/gFTL/blob/d8e4edb69c83228975c2463e36b5c02e7d0edefa/include/v1/templates/altSet_decl.inc#L58 to

 class (__set), pointer :: reference => null()

But there is a good chance that this just leads to another conflict.

[mathomp4]

@chesswright I definitely have built pFUnit as part of GFE in Baselibs with Intel 2022.1 (aka Intel Fortran 2021.6). When I did it I used these modules:

gcc/10.2 
comp-intel/2022.1.0
mpi-hpe/mpt.2.25 
python/GEOSpyD/Min4.11.0_py3.9

Now the python doesn't matter and if this is a gFTL issue, the gcc shouldn't either.

What modules are you using to build with? And I guess where did you build?

[tclune]

Note - I still think there is a Fortran bug that I intend to fix. But in the mean time @mathomp4 is helping me figure out why our CI is not catching this.

[chesswright]

this is my module list 1) comp-intel/2022.1.0 2) pkgsrc/2021Q2 3) mpi-hpe/mpt.2.25 4) mpi-hpe/mpt

[tclune]

Hmm. Despite this being a part of the standard that I thought I understood fairly well, we have:

""A nonpolymorphic entity is type compatible only with entities of the same declared type, except that an entity of an enum type is also type compatible with an expression of type integer if the expression has a primary that is an enumerator of that enum type."

This statement (and my tests with various compilers) indicates that the "offending" lines are indeed legal, and the "extensible" part of the target is simply lost is the pointer assignment. Since there never can be any extension in this context it even works as intended. So ... no need for a fix to the source. Instead we need to redouble our efforts to understand the difference in context.

[mathomp4]

Ahhh. This could be my old friend "NAS doesn't want to provide useful modulefiles". How did you build this? If you do this:

cmake ..

it will fail! Why? Well, NAS in their...infinite wisdom, let's call it, have decided that when you module load comp-intel you do not get FC set in your environment. So because of that when you don't specify a Fortran compiler:

$ cmake ..
-- The Fortran compiler identification is GNU 4.8.5
-- The C compiler identification is GNU 4.8.5
...

CMake first looks for what is in FC in your environment, and you'll have none. And then CMake goes through some sort of algorithm and it finds the system gfortran, version 4.8.5, which is insanely old. And none of Tom's code will ever compile with that old of a Fortran compiler!

Instead, you need to specify the compiler by adding:

-DCMAKE_Fortran_COMPILER=ifort

Now you'll see:

$ cmake .. -DCMAKE_Fortran_COMPILER=ifort
-- The Fortran compiler identification is Intel 2021.6.0.20220226
-- The C compiler identification is GNU 4.8.5
-- Detecting Fortran compiler ABI info

So (at least) the Fortran is recent and this will build.

Note, you might be okay here, but I always load a newer gcc as well because icpc and icc depend on the GCC version in the environment. So if your code has some mildly new C or C++, you might need to do that.

[chesswright]

That worked to force it to recognize the right Fortran module

From: Matthew Thompson @.> Reply-To: Goddard-Fortran-Ecosystem/pFUnit @.> Date: Thursday, October 20, 2022 at 4:14 PM To: Goddard-Fortran-Ecosystem/pFUnit @.> Cc: William Wright @.>, Mention @.***> Subject: [EXTERNAL] Re: [Goddard-Fortran-Ecosystem/pFUnit] compiling on NAS (Issue #383)

Ahhh. This could be my old friend "NAS doesn't want to provide useful modulefiles". How did you build this? If you do this:

cmake ..

it will fail! Why? Well, NAS in their...infinite wisdom, let's call it, have decided that when you module load comp-intel you do not get FC set in your environment. So because of that when you don't specify a Fortran compiler:

$ cmake ..

-- The Fortran compiler identification is GNU 4.8.5

-- The C compiler identification is GNU 4.8.5

...

CMake first looks for what is in FC in your environment, and you'll have none. And then CMake goes through some sort of algorithm and it finds the system gfortran, version 4.8.5, which is insanely old. And none of Tom's code will ever compile with that old of a Fortran compiler!

Instead, you need to specify the compiler by adding:

-DCMAKE_Fortran_COMPILER=ifort

Now you'll see:

$ cmake .. -DCMAKE_Fortran_COMPILER=ifort

-- The Fortran compiler identification is Intel 2021.6.0.20220226

-- The C compiler identification is GNU 4.8.5

-- Detecting Fortran compiler ABI info

So (at least) the Fortran is recent and this will build.

Note, you might be okay here, but I always load a newer gcc as well because icpc and icc depend on the GCC version in the environment. So if your code has some mildly new C or C++, you might need to do that.

— Reply to this email directly, view it on GitHubhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGoddard-Fortran-Ecosystem%2FpFUnit%2Fissues%2F383%23issuecomment-1286088427&data=05%7C01%7CWilliam.B.Wright%40nasa.gov%7C6152d2b31a804d5e78ab08dab2d7b488%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638018936763807802%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HgxUq5xY4XbPQLOdI6LbGw84KKOHJ0d9z8q9MrAXnEs%3D&reserved=0, or unsubscribehttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABLSC2HLIB4TQQZP7ITBEGLWEGR2NANCNFSM6AAAAAARKI4UIA&data=05%7C01%7CWilliam.B.Wright%40nasa.gov%7C6152d2b31a804d5e78ab08dab2d7b488%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638018936763807802%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=piKPGtNT9Ccho5177qR8P%2BIOK%2BP407o%2F3L8m17sCuek%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.***>

[tclune]

@mathomp4 Can this issue be closed?

[mathomp4]

Yes. I think it was just a NAS Thing