[Task]: Test marbl example with nvhpc/25.9

[mnlevy1981]

Task Description

Now that #19 has been addressed, I need to merge marbl-ecosys/MARBL#485 and then revisit #7: testing the MARBL configuration with nvhpc/25.9

Background

No response

Acceptance Criteria

• Update build system to use nvhpc/25.9 on derecho
• Run cesm_t232_marbl example with nvhpc executable

Ideas

No response

Task Type

CI/CD and Testing

Dependencies

No response

Timeline

No response

Additional Context

No response

[mnlevy1981]

I made the following change in MOM6

$ git diff
diff --git a/src/framework/MOM_file_parser.F90 b/src/framework/MOM_file_parser.F90
index 291d44492..70cba383d 100644
--- a/src/framework/MOM_file_parser.F90
+++ b/src/framework/MOM_file_parser.F90
@@ -216,6 +216,10 @@ subroutine open_param_file(filename, CS, checkable, component, doc_file_dir, ens
   call populate_param_data(iounit, filename, CS%param_data(i))
   ! Increment the maximum line length, but always report values in blocks of 4 characters.
   CS%max_line_len = max(CS%max_line_len, 4 + 4*(max_input_line_length(CS, i) - 1) / 4)
+  if (filename == 'MOM_input') then
+    print*, "MNL MNL: max_input_line_length = ", max_input_line_length(CS, i)
+    print*, "MNL MNL: file = '", trim(filename), "'; max_line_len = ", CS%max_line_len
+  endif

   call read_param(CS,"SEND_LOG_TO_STDOUT",CS%log_to_stdout)
   call read_param(CS,"REPORT_UNUSED_PARAMS",CS%report_unused)

When I build and run with nvhpc/25.9, the output is

 MNL MNL: max_input_line_length =             0
 MNL MNL: file = 'MOM_input'; max_line_len =             4

And then the run crashes because DT = 1800 gets truncated to DT = and the file parser doesn't know what to do. The intel compiler gives a more reasonable max_line_len so the model actually reads the file correctly:

 MNL MNL: max_input_line_length =          123
 MNL MNL: file = 'MOM_input'; max_line_len =          126

A quick fix I am testing now is

diff --git a/src/framework/MOM_file_parser.F90 b/src/framework/MOM_file_parser.F90
index 291d44492..cf66518b4 100644
--- a/src/framework/MOM_file_parser.F90
+++ b/src/framework/MOM_file_parser.F90
@@ -78,7 +78,7 @@ module MOM_file_parser
   logical  :: log_to_stdout = log_to_stdout_default !< If true, all log
                                     !! messages are also sent to stdout.
   logical  :: log_open = .false.    !< True if the log file has been opened.
-  integer  :: max_line_len = 4      !< The maximum number of characters in the lines
+  integer  :: max_line_len = 126    !< The maximum number of characters in the lines
                                     !! in any of the files in this param_file_type after
                                     !! any continued lines have been combined.
   integer  :: stdout                !< The unit number from stdout().

but (a) we can't push that back to MOM6, and (b) it's super fragile so I'd like to find a simple example of whatever is going wrong with nvhpc and ask NVIDIA to fix it

[mnlevy1981]

This seems to be a memory issue, and given their track record my inclination is to blame NVIDIA. As reported, the modification

diff --git a/src/framework/MOM_file_parser.F90 b/src/framework/MOM_file_parser.F90
index 291d44492..2422ad2d2 100644
--- a/src/framework/MOM_file_parser.F90
+++ b/src/framework/MOM_file_parser.F90
@@ -216,6 +216,7 @@ subroutine open_param_file(filename, CS, checkable, component, doc_file_dir, ens
   call populate_param_data(iounit, filename, CS%param_data(i))
   ! Increment the maximum line length, but always report values in blocks of 4 characters.
   CS%max_line_len = max(CS%max_line_len, 4 + 4*(max_input_line_length(CS, i) - 1) / 4)
+  print*, "MNL MNL: file = '", trim(filename), "'; max_line_len = ", CS%max_line_len

   call read_param(CS,"SEND_LOG_TO_STDOUT",CS%log_to_stdout)
   call read_param(CS,"REPORT_UNUSED_PARAMS",CS%report_unused)

However, adding a print statement to max_input_line_length() as follows

diff --git a/src/framework/MOM_file_parser.F90 b/src/framework/MOM_file_parser.F90
index 291d44492..68d622a5f 100644
--- a/src/framework/MOM_file_parser.F90
+++ b/src/framework/MOM_file_parser.F90
@@ -992,6 +992,8 @@ function max_input_line_length(CS, pf_num) result(max_len)
     ! Scan through each line of the file
     do count = 1, CS%param_data(ipf)%num_lines
       ! line = CS%param_data(ipf)%fln(count)%line
+      if ((trim(filename) == "MOM_input") .and. (count == 12)) &
+        print*, "MNL MNL (max_input) line: ", trim(CS%param_data(ipf)%fln(count)%line)
       last = len_trim(CS%param_data(ipf)%fln(count)%line)
       last_char = " "
       if (last > 0) last_char = CS%param_data(ipf)%fln(count)%line(last:last)

lets that function return the proper value; I wonder if

-       last = len_trim(CS%param_data(ipf)%fln(count)%line)
+       last = len(trim(CS%param_data(ipf)%fln(count)%line))

will do the trick (I need to log off, will try that later tonight or tomorrow)

[mnlevy1981]

diff --git a/src/framework/MOM_file_parser.F90 b/src/framework/MOM_file_parser.F90
index 291d44492..5e9821129 100644
--- a/src/framework/MOM_file_parser.F90
+++ b/src/framework/MOM_file_parser.F90
@@ -992,7 +992,7 @@ function max_input_line_length(CS, pf_num) result(max_len)
     ! Scan through each line of the file
     do count = 1, CS%param_data(ipf)%num_lines
       ! line = CS%param_data(ipf)%fln(count)%line
-      last = len_trim(CS%param_data(ipf)%fln(count)%line)
+      last = len(trim(CS%param_data(ipf)%fln(count)%line))
       last_char = " "
       if (last > 0) last_char = CS%param_data(ipf)%fln(count)%line(last:last)
       ! Check if line ends in continuation character (either & or \)

Runs correctly as well... getting close to being able to actually look at the MARBL output :)

[mnlevy1981]

Also, I don't know how this lines up with the Fortran standard... but there are two data structures defined in MOM_file_parser.F90:

!> A simple type to allow lines in an array to be allocated with variable sizes.
type, private :: file_line_type ; private
  character(len=:), allocatable :: line !< An allocatable line with content
end type file_line_type

!> The valid lines extracted from an input parameter file without comments
type, private :: file_data_type ; private
  integer :: num_lines = 0 !< The number of lines in this type
  type(file_line_type), allocatable, dimension(:) :: fln !< Lines with the input content.
  logical,                  pointer, dimension(:) :: line_used => NULL() !< If true, the line has been read
end type file_data_type

Then, given a file_data_type variable named param_data, param_data%fln(i)%line is populated by

  allocate(param_data%fln(num_lines))
  do n=1,num_lines
    param_data%fln(n)%line = trim(line)
  enddo

notably, param_data%fln(n)%line is never explicitly allocated. It seems like this is okay, as both intel and gnu handle the situation fine (and even nvhpc is okay with certain usage patterns), but maybe it's a hint to how to create a test case to send the compiler team.