Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Need a file cmake/NVHPC.cmake #337

Open
cponder opened this issue Jan 26, 2022 · 17 comments
Open

Need a file cmake/NVHPC.cmake #337

cponder opened this issue Jan 26, 2022 · 17 comments

Comments

@cponder
Copy link

cponder commented Jan 26, 2022 •
edited

Building the 4.2.2 version with the NVHPC 22.2 (pre-release) compiler gives me this error:

CMake Error at CMakeLists.txt:70 (include):
  include could not find requested file:

    cmake/NVHPC.cmake

CMake Error at CMakeLists.txt:72 (message):
  Unrecognized Fortran compiler.  Please use ifort, gfortran, NAG, PGI, or XL.

For now I'm going to run the command

cp cmake/PGI.cmake cmake/NVHPC.cmake

which worked for the gFTL-shared library, as reported here

https://github.com/Goddard-Fortran-Ecosystem/gFTL-shared/issues/51
@cponder
Copy link
Author

cponder commented Jan 26, 2022

That being said, I'm still working through build issues so I don't know if other fixes are needed.

I do suggest, though, just copying the PGI file verbatim to serve as a "version 0" starting-point, after which we would make further edits as required.

@tclune
Copy link
Member

tclune commented Jan 26, 2022

@cponder - sorry about that. Forgot to commit the NVHPC.cmake file. Will do so shortly.

@tclune
Copy link
Member

tclune commented Jan 26, 2022

Sorry - did not notice that this was in the pFUnit repo. I think a number of changes are needed here and in fArgParse to use the kludged gFTL. But none of these are in the critical path for running GEOS. For that we only absolutely need gFTL, gFTL-shared (and ESMF).

@tclune
Copy link
Member

tclune commented Jan 26, 2022

I have created a branch feature/NVIDIA-workarounds in both fArgParse and pFUnit. (Not quite the same name as in gFTL-shared, sorry about that.)

Note that there are also existing branches called something like feature/pgi-workarounds that might be worth looking at. Those had changes that I was unwilling to merge onto main. (Never got a full build anyway.)

Am closing this ticket.

@cponder
Copy link
Author

cponder commented Jan 26, 2022

You'll get the cmake/NVHPC.cmake into the next official release, won't you?

@tclune
Copy link
Member

tclune commented Jan 26, 2022

Yes. In fact, I'll merge into develop immediately in both. Unfortunately can't quite do the same thing in gFTL-shared as there are other things already mixed in.

@tclune tclune closed this as completed Jan 26, 2022
@cponder
Copy link
Author

cponder commented Feb 3, 2022 via email

@cponder
Copy link
Author

cponder commented Feb 3, 2022 via email

@cponder
Copy link
Author

cponder commented Feb 3, 2022 via email

@tclune
Copy link
Member

tclune commented Feb 3, 2022

Annotation.gz

Attached gzip'd expansion of TestAnnotation.F90.

@cponder
Copy link
Author

cponder commented Mar 6, 2022

@tclune What's the state of this, now? The latest release is still from awhile ago.

@tclune
Copy link
Member

tclune commented Mar 7, 2022

@cponder - The last action was to provide you with the Annotation.gz file that was a reproducer. Did you mean to post your question in a different issue?

Apologies if I've lost track and there was a change that you wanted released.

@cponder
Copy link
Author

cponder commented Mar 8, 2022

Sorry, I got a duplicate in there.
You said you had the cmake/NVHPC.cmake in the develop branch, but the 4.2.2 tag is from sometime before that.
Also there's still the compilation failure I mentioned above

NVFORTRAN-S-0142-insert is not a component of this OBJECT (/usr/local/src/pFUnit-4.2.2/src/funit/core/RemoteProxyTestCase.F90: 80)

@cponder
Copy link
Author

cponder commented Mar 9, 2022 •
edited

Actually, re-building now with the PGI nightly compiler, I get this different error:

NVFORTRAN-S-0081-Illegal selector - KIND value must be non-negative  (/usr/local/src/pFUnit-4.2.2/src/funit/fhamcrest/BaseDescription.F90: 311)
  0 inform,   0 warnings,   1 severes, 0 fatal for description_of_real128
NVFORTRAN-S-0081-Illegal selector - KIND value must be non-negative  (/usr/local/src/pFUnit-4.2.2/src/funit/fhamcrest/BaseDescription.F90: 338)
  0 inform,   0 warnings,   1 severes, 0 fatal for description_of_complex128
make[2]: *** [src/funit/fhamcrest/CMakeFiles/fhamcrest.dir/build.make:191: src/funit/fhamcrest/CMakeFiles/fhamcrest.dir/BaseDescription.F90.o] Error 2
make[1]: *** [CMakeFiles/Makefile2:576: src/funit/fhamcrest/CMakeFiles/fhamcrest.dir/all] Error 2
make: *** [Makefile:166: all] Error 2

I think the problem here could be that the NVHPC compilers don't support 128-bit numbers. Is there a flag that suppresses the usage here?

@tclune
Copy link
Member

tclune commented Mar 9, 2022

Mark LeAir indicated he had a workaround and would supply it back to me at some point. I'm sure I can replicate this weekend if his version is not accessible.

@cponder
Copy link
Author

cponder commented Mar 9, 2022

This is what Mark had said a moth ago:

Update on the source code patch:  I don't have access to make the pull request. I sent the patches to Tom Clune and he is going to try to integrate them this weekend.

Did he get the fixes to you?

@tclune
Copy link
Member

tclune commented Mar 9, 2022

Ah - yes. I do remember that now. I'll try to get these merged asap. Won't be before tomorrow, and won't be after Sunday.

@tclune tclune reopened this Mar 9, 2022
This was referenced Jun 15, 2022
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@cponder @tclune