Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

GNU compiler error

helber

Bob Helber
New Member
Has anyone seen this error using GNU compilers?:

../../../../src/MOM6/config_src/infra/FMS1/MOM_io_infra.F90:99.43:

character(len=:), allocatable :: filename !< The path to this file, if it is
1
Error: Deferred-length character component 'filename' at (1) is not yet supported
make: *** [MOM_io_infra.o] Error 1
make: *** Waiting for unfinished jobs....
 

marshallward

Marshall Ward
New Member
What is your compiler version and platform/CPU?

I think we have seen warnings from using deferred length strings but never an error before.
 

helber

Bob Helber
New Member
no problem. I'm trying PGI now. If that does not work, I can have my people install a newer compiler.
Thanks.
 

helber

Bob Helber
New Member
I found GNU 8.3.0 and MOM6 compiles.

When I run my job, however, I get this error:
...

FATAL from PE 15: error inquiring dimensions hinterp_extrap

FATAL from PE 17: error inquiring dimensions hinterp_extrap

[wyman.code7300.nrlssc.navy.mil:00780] 18 more processes have sent help message help-mpi-api.txt / mpi-abort
[wyman.code7300.nrlssc.navy.mil:00780] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages

Does this look familiar?
Any ideas?
Thanks.
 

Robert Hallberg

Robert Hallberg
New Member
This error message is coming from line 351 of MOM6/src/framework/MOM_horizontal_regridding.F90, in the routine horiz_interp_and_extrap_tracer_record(), which is attempting to read a variable from a file and interpolate it to the correct time and spatial grid. Unfortunately, unlike every other error message in this routine, this particular error message does not tell you what variable it is attempting to read and from what file, which would have turned this error message from something that is cryptic and annoying into a message that is genuinely useful!

I will put in a pull request modifying this error message to give the file and variable names that triggered it. What is surprising, though, in this case is that the file in question was successfully opened, and the variable in question was found in the file, otherwise an earlier (and more informative) error message would have been triggered, indicating the problematic file or variable. Is there any chance that you are trying to read from a file with more than 4 dimensional variables?
 

gmarques

Gustavo Marques
Moderator
Staff member
What are the dates in the time variable of the file you are trying to read? I recently got this error because I was trying to read a file where the last time index was 9999-01-01. The model start date was 0001-1-01.
 

helber

Bob Helber
New Member
On another machine, I get this error when compiling the FMS:
..... -c -I../../../../src/FMS/mosaic ../../../../src/FMS/mosaic/mosaic_util.c
../../../../src/FMS/mosaic/mosaic_util.c(24): catastrophic error: cannot open source file "mpi.h"
#include <mpi.h>
^

compilation aborted for ../../../../src/FMS/mosaic/mosaic_util.c (code 4)
Makefile:119: recipe for target 'mosaic_util.o' failed
make: *** [mosaic_util.o] Error 4

I'm using:

openmpi/4.0.5
I checked, it does not have a "mpi.h" file.
The compiler is:
This error message is coming from line 351 of MOM6/src/framework/MOM_horizontal_regridding.F90, in the routine horiz_interp_and_extrap_tracer_record(), which is attempting to read a variable from a file and interpolate it to the correct time and spatial grid. Unfortunately, unlike every other error message in this routine, this particular error message does not tell you what variable it is attempting to read and from what file, which would have turned this error message from something that is cryptic and annoying into a message that is genuinely useful!

I will put in a pull request modifying this error message to give the file and variable names that triggered it. What is surprising, though, in this case is that the file in question was successfully opened, and the variable in question was found in the file, otherwise an earlier (and more informative) error message would have been triggered, indicating the problematic file or variable. Is there any chance that you are trying to read from a file with more than 4 dimensional variables?
Thanks for the information. No, all of the arrays are 4D or less. I don't think there are any unnecessary dimensions, but I will double check.
 

helber

Bob Helber
New Member
What are the dates in the time variable of the file you are trying to read? I recently got this error because I was trying to read a file where the last time index was 9999-01-01. The model start date was 0001-1-01.
This could be the problem. One of the input fields is starting at a different time. Thanks.
 

marshallward

Marshall Ward
New Member
On another machine, I get this error when compiling the FMS:
..... -c -I../../../../src/FMS/mosaic ../../../../src/FMS/mosaic/mosaic_util.c
../../../../src/FMS/mosaic/mosaic_util.c(24): catastrophic error: cannot open source file "mpi.h"
#include <mpi.h>
^

compilation aborted for ../../../../src/FMS/mosaic/mosaic_util.c (code 4)
Makefile:119: recipe for target 'mosaic_util.o' failed
make: *** [mosaic_util.o] Error 4

I'm using:

openmpi/4.0.5
I checked, it does not have a "mpi.h" file.
The compiler is:
You probably need to set your C compiler to an MPI wrapper, e.g. mpicc.

If you're building with native mkmf commands then you'll need to add something like `CC=mpicc` to your mkmf template file.
 

helber

Bob Helber
New Member
Hey, I just impressed myself, if nobody else. Based on Bob Hallberg's instructions, I went into MOM_horizontal_regridding.F90 and added the filename and variable name to the error message! Now I get more information about my error:

FATAL from PE 14: error in INPUT/hycom_type_ts_data_mimi_z100.nc inquiring dimensions for water_temp hinterp_extrap

FATAL from PE 15: error in INPUT/hycom_type_ts_data_mimi_z100.nc inquiring dimensions for water_temp hinterp_extrap

[wyman.code7300.nrlssc.navy.mil:16775] 18 more processes have sent help message help-mpi-api.txt / mpi-abort
[wyman.code7300.nrlssc.navy.mil:16775] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages

Thanks for your help!
 

helber

Bob Helber
New Member
I'm still having problems with this. There seems to be a bug in the compiler GNU 8.3.0. In MOM_horizontal_regridding.F90 would not do this:

rcode = NF90_INQUIRE_VARIABLE(ncid, varid, ndims=ndims, dimids=dims)
if (rcode /= 0) call MOM_error(FATAL,'error inquiring dimensions hinterp_extrap')

It would just not read the dimids no matter how I configured my file. I made a work around using nf90_inq_dimid but then I had to hard code the dimension names. Not a general solution. Also, it had an error later in the code.

So, I finally changed to GNU 6.1.0 and now I get this error:

Error termination. Backtrace:
At line 1037 of file ../../../../src/FMS/mpp/include/mpp_io_read.inc
Fortran runtime error: Index '48' of dimension 1 of array 'mpp_file%var' above upper bound of 2

This error is in the FMS. I guess, there is a problem in my file, that I am trying to track down. I'm having trouble locating the exact error or file that is having the error. Any ideas?

I may try the other machine, where I'm having the mpi.h compiler issue. I have not worked on that yet. I'll try Marshall's suggestion.
Thanks.
 

marshallward

Marshall Ward
New Member
I haven't seen that error, but it may have something to do with your 'units' field. This seems to be where FMS is choking:

1033 select case (trim(attname))
1034 case ('long_name')
1035 mpp_file(unit)%Var(nv)%longname=mpp_file(unit)%Var(nv)%Att(j)%catt(1:len)
1036 case('units')
1037 mpp_file(unit)%Var(nv)%units=mpp_file(unit)%Var(nv)%Att(j)%catt(1:len)

It could be related to some of your netCDF modifications, or it could just be a misconfigured input file.

If the input file configuration is this sensitive to things like field names and types, then I think we need to do a better job of checking and enforcing the inputs. For what it's worth, Bob (Hallberg) put in an update a few days ago to clarify the original error message.
 

helber

Bob Helber
New Member
I haven't seen that error, but it may have something to do with your 'units' field. This seems to be where FMS is choking:

1033 select case (trim(attname))
1034 case ('long_name')
1035 mpp_file(unit)%Var(nv)%longname=mpp_file(unit)%Var(nv)%Att(j)%catt(1:len)
1036 case('units')
1037 mpp_file(unit)%Var(nv)%units=mpp_file(unit)%Var(nv)%Att(j)%catt(1:len)

It could be related to some of your netCDF modifications, or it could just be a misconfigured input file.

If the input file configuration is this sensitive to things like field names and types, then I think we need to do a better job of checking and enforcing the inputs. For what it's worth, Bob (Hallberg) put in an update a few days ago to clarify the original error message.
Thanks. This is helpful. Just to be safe, I reverted to the unchanged version of the code. It is probably the configuration of our netcdf files. Overall, I'm impressed with the quality of the error messages and error checking. The organization of the files and modules is fantastic. Thanks again!
 

helber

Bob Helber
New Member
I'm using the FMS you get from a new clone of MOM6-examples.
{wyman /u/atlo/helber/src/MOM6-examples/src/FMS 22} git status
# HEAD detached at f61416f
nothing to commit, working directory clean
{wyman /u/atlo/helber/src/MOM6-examples/src/FMS 23} git remote -v
origin NOAA-GFDL/FMS (fetch)
origin NOAA-GFDL/FMS (push)

I have a fork, but reverted to a fresh clone, in case I haven't updated my fork correctly. The fork has the same problems.

I'm adding units. I will let you know if that fixes the problem.
 

helber

Bob Helber
New Member
When I try to run the test case
MOM6-examples/ocean_only/MESO_025_63L
I get the error:
FATAL from PE 13: fms_io(read_data_3d_new), field u in file INPUT/MESO_025_63L_IC.nc: field size mismatch 1
Could this be due to me using NetCDF 4?
We generally use netcdf 4, our netcdf 4 is compiled with the same GNU compiler I'm using. When I compile the FMS and MOM6 I use the option:
(cd build/gnu/shared/repro/; make NETCDF=4 REPRO=1 libfms.a -j)
I tried compiling FMS and MOM6 with netcdf3 but we only have netcdf 4 here at NRL. I get the same error.
Could this be the problem?
If I go back to an old version of netcdf 3, then I would have to use an old compiler, which I know will have problems.
Any ideas?
 

marshallward

Marshall Ward
New Member
I use a netCDF4 library at home, and AFAIK both formats are supported, so I don't think this is the issue.

I've just merged a fix from Bob which no longer requires "units" and "long_name" on every field. Hard to say if it will help if you've already added those fields, but at least it's one less thing to worry about.
 

helber

Bob Helber
New Member
I use a netCDF4 library at home, and AFAIK both formats are supported, so I don't think this is the issue.

I've just merged a fix from Bob which no longer requires "units" and "long_name" on every field. Hard to say if it will help if you've already added those fields, but at least it's one less thing to worry about.
Okay. Thanks!
 
Top