Error for B1850 run with CESM2.1.3(pio_support::pio_die:: myrank=-1 : ERROR: pionfread_mod.F90.in:204 : Feature is not yet suppor)

[Liu W]

Hello, when I run B1850 with CESM2.1.3, an error(pio_support::pio_die:: myrank=-1 : ERROR: pionfread_mod.F90.in: 204 : Feature is not yet supported.) interrupts the model. Besides the error message in cesm.log, I cannot found any error message in the log files of other components. All discussions are expected.

 

[jedwards]

What versions of netcdf pnetcdf and hdf5 are you using?

 

[Liu W]

Hi, jedwards, thanks for your reply. The version of netcdf is 4.6.3, pnetcdf is 1.12.1 and the hdf5 is 1.10.4. Additionally, the compiler is intel.

 

[jedwards]

It's not clear to me yet what feature is not supported. Is there a traceback in the cesm log? What component is generating the error? What is the value of PIO_TYPENAME in your case?

 

[Liu W]

The error may be caused by the ice component, I find the lack of ice.log, but I cannot find other messages you mentioned above, the log files are attached here.

 

[jedwards]

Found the issue at the end of the ocn.log:
string too short; not enough room to read vert_grid_file from /public1/home/sc9
1441/cesm_inputdata/ocn/pop/gx1v6/ic/ecosys_jan_IC_omip_POP_gx1v7_c190615.nc
(open_read_netcdf) nsize = 610
(open_read_netcdf) len(work_line) = 80
string too short; not enough room to read input_file_list from /public1/home/sc
91441/cesm_inputdata/ocn/pop/gx1v6/ic/ecosys_jan_IC_omip_POP_gx1v7_c190615.nc

However the traceback is missing in cesm.log - you might try rebuilding after setting DEBUG=TRUE

 

[mlevy]

Judging from the error message, it looks like the path to your file (/public1/home/sc91441/cesm_inputdata/ocn/pop/gx1v6/ic/ecosys_jan_IC_omip_POP_gx1v7_c190615.nc) is too long for the string variable that is meant to store the file name. I would copy $CESMROOT/components/pop/source/io_netcdf.F90 to $CASEROOT/SourceMods/src.pop/ and then modify the version in SourceMods to change the length of the work_line array from 80 to 120:

-   character (80) :: &
+   character (120) :: &
       work_line,     &! temporary to use for parsing file lines
       att_name        ! temporary to use for attribute names

This should occur near line 95 in the file, in the open_read_netcdf() subroutine.

 

[mlevy]

Note that you will need to rebuild the case by running case.build before you resubmit the job.

 

[Liu W]

Note that you will need to rebuild the case by running case.build before you resubmit the job.

Sorry for the later reply. I follow the suggested procedures to change the length many times but also get the same error"(open_read_netcdf) nsize = 610 (open_read_netcdf) len(work_line) = 512 string too short; not enough room to read input_file_list from /public1/home/sc91441/cesm_inputdata/ocn/pop/gx1v6/ic/ecosys_jan_IC_omip_POP_gx1v7_c190615.nc". I am sure that the error occurred in initializing the ocean or ice component, but I have no idea about the solution. looking forward to your reply。

 

[mlevy]

Can you please run the following command and share the output? ncdump -h /public1/home/sc91441/cesm_inputdata/ocn/pop/gx1v6/ic/ecosys_jan_IC_omip_POP_gx1v7_c190615.nc. That file resides in a different directory on the NCAR machine, but here is what I see:

$ ncdump -h /glade/p/cesmdata/cseg/inputdata/ocn/pop/gx1v6/ic/ecosys_jan_IC_omip_POP_gx1v7_c190615.nc | grep vert_grid
        :vert_grid_file = "/gpfs/fs1/work/klindsay/analysis/pop-tools/pop_tools/input_templates/gx1v7_vert_grid" ;

The string /gpfs/fs1/work/klindsay/analysis/pop-tools/pop_tools/input_templates/gx1v7_vert_grid is what the model is attempting to store in the work_line variable, and I'm confused about why your case is reporting this string as being 610 characters long.

In the meantime, bumping the length from 512 (which you have it currently set to) to 768 should be sufficient to get past this error... but it might result in a seperate error because I doubt the string we are copying this value to is long enough to hold the entire thing.

 

[Liu W]

Can you please run the following command and share the output? ncdump -h /public1/home/sc91441/cesm_inputdata/ocn/pop/gx1v6/ic/ecosys_jan_IC_omip_POP_gx1v7_c190615.nc. That file resides in a different directory on the NCAR machine, but here is what I see:

$ ncdump -h /glade/p/cesmdata/cseg/inputdata/ocn/pop/gx1v6/ic/ecosys_jan_IC_omip_POP_gx1v7_c190615.nc | grep vert_grid
        :vert_grid_file = "/gpfs/fs1/work/klindsay/analysis/pop-tools/pop_tools/input_templates/gx1v7_vert_grid" ;

The string /gpfs/fs1/work/klindsay/analysis/pop-tools/pop_tools/input_templates/gx1v7_vert_grid is what the model is attempting to store in the work_line variable, and I'm confused about why your case is reporting this string as being 610 characters long.

In the meantime, bumping the length from 512 (which you have it currently set to) to 768 should be sufficient to get past this error... but it might result in a seperate error because I doubt the string we are copying this value to is long enough to hold the entire thing.

Thanks for your reply. I have resolved the problem, by removing the additional setting (use_init_interp = .true. and init_interp_method = "use_finidat_areas") of CLM_NAMELIST_OPTS. But I encounter another error about the wave component, could you give me some suggestions?

During the default running of case B1850 with CESM2.1.3, I get an error message in cesm.log (ERROR: component_mod:check_fields NaN found in WAV instance: 1 field Sw_lamult 1d g lobal index: 228) after two model years, the error occurred after 0003-01-08 of the model. The previous discussions show that the problem of the ATM/POP instance may originate from the respective forcing data. I used the default initial file (inputdata/wav/ww3/restart.ww3.init.seed), and also manually download and replace the automatically downloaded file, but the error still persists. Looking forward to your reply.

 

[mlevy]

I saw your other thread about the error in the wave model and moved it to wave watch forum, but unfortunately I'm not familiar enough with the WW3 code base to help. Someone who knows more about that model should be along to respond to you soon, though.