READ_INP ERROR while reading block with keyword 'psource_ncfile'

AsishKsasidharan · April 9, 2026, 5:12am

Dear CROCO forum,

I am currently running simulations for the Bay of Bengal that include runoff from 15 rivers. When the PSOURCE_NCFILE and PSOURCE_NCFILE_TS Keys are activated, the model fails with the following error:

READ_INP ERROR while reading block with keyword 'psource_ncfile'

I generated the river forcing file using the latest make_rivers.py script with GLOFAS data. However, I am unable to determine why the model is producing this error. My model resolution is 4 km.

When these keys are not activated, the model runs successfully, which suggests that the issue is related to the river forcing configuration. I also attempted using the alternative #psource option, but encountered similar issues.

I would greatly appreciate any suggestions or guidance to resolve this problem.

Thanks in advance.

Regards,

Asish K Sasidharan

Senior Research Fellow,

INCOIS, Hyderabad

lcbernardo · April 9, 2026, 5:58am

Which CROCO version are you using? I also use rivers in my domain and I remember that once there was an issue with the specification of the dates. Is “USE_CALENDAR” defined in your cppdefs.h? And in your river netcdf file, how do you specify the units in your “qbar_time”, “temp_src_time”, and “salt_src_time”?

Another suggestion is to check the actual values themselves in the river netcdf files, if the values have the proper units and if there are any unrealistic values or even NaNs generated in the process of generating the river file.

Lawrence

AsishKsasidharan · April 9, 2026, 6:45am

I am using CROCO - v2.1.2

To diagnose the issue, I checked my runoff NetCDF file. The header is:

ncdump -h croco_runoff.nc

netcdf croco_runoff {
dimensions:
    qbar_time = UNLIMITED ; // (763 currently)
    n_qbar = 128 ;

variables:
    string runoff_name(n_qbar) ;
        runoff_name:long_name = "River Name" ;

    double qbar_time(qbar_time) ;
        qbar_time:long_name = "river discharge time" ;
        qbar_time:units = "days since 2000-01-01 00:00:00" ;

    double Qbar(n_qbar, qbar_time) ;
        Qbar:long_name = "river discharge" ;
        Qbar:units = "m3 s-1" ;

// global attributes:
        :created = "2026-04-08T15:07:16.131698" ;
        :type = "CROCO river file produced by make_river.py" ;
        :grid_file = "croco_grd.nc" ;
}

I am using 128 rivers (n_qbar = 128), and I have provided the corresponding configuration in my input files.

My concern

I suspect that the make_river.py script may be selecting river locations that fall on land grid points (i.e., where mask_rho = 0). This could potentially cause inconsistencies when CROCO reads the psource_ncfile.

I am attaching:

Param.h (34.7 KB)

cppdefs.h (44.7 KB)

The runoff file was generated automatically using make_river.py (I have used the latest annd previous versions of make_river.py and still faced the same issue)

image1152×752 49.6 KB

Once I zoom in, some points are on the land.
This is how i give the points in the croco.in file
image886×317 20.9 KB
NB: This is a test simulation.

Thank you, Lawrence, in advance

slegac · April 9, 2026, 8:21am

Hi,

It seems there may be a misconfiguration in your param.h. In particular, Msrc is not set to 128. By default, the number of rivers is 30, so you need to increase this value in your case. This parameter can be found around line 364 of param.h.

Regarding the river location, the grid point itself can be masked. What actually matters is the cell face through which the river flows. Here is a small sketch to clarify this point.

swapnil · April 9, 2026, 11:35am

Hi,

Respected.

Before i also attended PYtools seminar. what i missing.

I also getting similar kind of error with .py and .m. because my number of river 64 (i want add more river and channel). what i need to do. (i also have many tracrs measurements)

psource_ncfile: Nsrc Isrc Jsrc Dsrc qbardir Lsrc Tsrc runoff file name
CROCO_FILES/croco_runoff.nc
64

                    218 153 1  -1 T  T   28.04745 20.6922
                    220 158 1  -1 T  T   28.04745 20.6922
                    219 160 1  -1 T  T   28.04745 20.6922
                    219 162 1  -1 T  T   28.04745 20.6922
                    220 167 1  -1 T  T   28.04745 20.6922
                    221 168 1  -1 T  T   28.04745 20.6922
                    222 172 1  -1 T  T   28.04745 20.6922
                    226 174 1  -1 T  T   28.04745 20.6922
                    226 175 1  -1 T  T   28.04745 20.6922
                    227 176 1  -1 T  T   28.04745 20.6922
                    227 177 1  -1 T  T   28.04745 20.6922
                    229 178 1  -1 T  T   28.04745 20.6922
                    231 182 0  1 T  T   28.04745 20.6922
                    230 182 0  1 T  T   28.04745 20.6922

Then i received in slurm . Is there any “TYPO”

Computing for Y1M1
Thu Apr 9 16:41:58 IST 2026
Thu Apr 9 16:42:17 IST 2026
Test croco_Y1M1.out

Warning: month not finished properly

READ_INP ERROR: A total of 1 configuration errors discovered.

READ_INP ERROR: Cannot find input file ‘CROCO_FILES/croco_runoff.nc’.

READ_INP ERROR: A total of 1 configuration errors discovered.

READ_INP ERROR: Cannot find input file ‘CROCO_FILES/croco_runoff.nc’.

READ_INP ERROR: A total of 1 configuration errors discovered.

READ_INP ERROR: Cannot find input file ‘CROCO_FILES/croco_runoff.nc’.

READ_INP ERROR: A total of 1 configuration errors discovered.

Month Y1M1 did not work

Thank you again for your kind response and love.

Dr. Swapnil Das

Indian Institute of Science Bengaluru

AsishKsasidharan · April 10, 2026, 4:55am

I have made all the changes as you have mentioned.

Issue

Despite this minimal setup, CROCO still fails during the input parsing of the psource block.

Questions

Are there any strict formatting requirements (e.g., column alignment, spacing, or boolean formatting) that could trigger this error?
Does CROCO expect a different structure when only a single source is used?
Could hidden characters or file encoding cause this type of parsing failure?
Is it because of any timestep error?

Any guidance would be appreciated.

Thanks in advance.

AsishKsasidharan · April 10, 2026, 7:37am

Resolution
The issue was not due to formatting, encoding, or timestep errors.

The root cause was a mismatch in the expected number of tracers (NT). I had diagnostic tracer options (DIAG_TS) enabled in cppdefs.h, which increased NT beyond what I accounted for in the psource block.
After:
Disabling DIAG_TS, and
Ensuring NT = 2 (for temperature and salinity only)
the error was resolved.
Conclusion
The psource block is highly sensitive to the compile-time definition of NT. Any mismatch between NT and the number of values provided for Lsrc and Tsrc will trigger a parsing failure.

Thanks to everyone who helped; the issue is now resolved.

AsishKsasidharan · April 13, 2026, 5:39am

Hi Swapnil,

Did your error get sorted?

swapnil · April 13, 2026, 10:47am

Hi Dear ( @AsishKsasidharan),

This read_inp.F problem is sometimes sorted and sometimes not due to Virtualbox (java base). because some time it’s create very large scale stratification in river mouth (like BBL use). some time use WENO9 and some CRWENO or TENO. so the problem is very complex (because its higher order).

Jai hind.