Fortran runtime error: Allocatable argument 'runoff_data' is not allocated

[arthurronner]

Hi!
Related to my previous post, I've ran into another hard to identify error in trying to run mizuRoute on the Rhône basin.
This one is related to the runoff data input file (unaltered since my previous attempt). I've tried to follow the instructions on the wiki - and my runoff data is of type 1) - the runoff is specified per RN_HRU. This was constructed using the easymore package for python - using runoff data in 2001 of PCR-GLOBWB under the ISIMIP program.
I've double checked that the HRU ID's match between the river topology and the runoff file.
One interesting thing I've noted is that mizuRoute does not seem to run when I do not specify the <dname_xlon> and <dname_ylat> variables (printing only 'Obtained 10 stack frames' before exiting), even though these should not have to be required for type 1) runoff data?

This is running on the gcc compiler in debug mode.

What could be the solution for this issue? I've included my control file for convenience.
control_file.txt

Best,
Arthur

At line 821 of file /home/ronnerac/mizuRoute/mizuRoute_code/route/build/src/standalone/model_setup.f90
Fortran runtime error: Allocatable argument 'runoff_data' is not allocated

Error termination. Backtrace:
#0  0x74bc79 in init_forc_data
	at /home/ronnerac/mizuRoute/mizuRoute_code/route/build/src/standalone/model_setup.f90:821
#1  0x75cdf0 in __model_setup_MOD_init_data
	at /home/ronnerac/mizuRoute/mizuRoute_code/route/build/src/standalone/model_setup.f90:100
#2  0x75d890 in route_runoff
	at /home/ronnerac/mizuRoute/mizuRoute_code/route/build/src/standalone/route_runoff.f90:5
#3  0x75db60 in main
	at /home/ronnerac/mizuRoute/mizuRoute_code/route/build/src/standalone/route_runoff.f90:11
 (t_initf) Read in prof_inparm namelist from: dummy_empty_namelist
 (t_initf) Using profile_disable= F  profile_timer=           4
 (t_initf)  profile_depth_limit=       99999  profile_detail_limit=           1
 (t_initf)  profile_barrier= F  profile_outpe_num=           0
 (t_initf)  profile_outpe_stride=           1  profile_single_file= F
 (t_initf)  profile_global_stats= T  profile_papi_enable= F

---- read control file --- 
 <case_name> --> RHONE_TEST
 <sim_start> --> 2001-01-01 00:00:00
 <sim_end> --> 2001-12-31 00:00:00
 <route_opt> --> 3
 <doesBasinRoute> --> 1
 <dt_qsim> --> 86400
 <hw_drain_point> --> 2
 <restart_write> --> last
 <restart_date> --> yyyy-mm-dd hh:mm:ss
 <fname_state_in> --> coldstart
 <is_lake_sim> --> F
 <is_flux_wm> --> F
 <is_vol_wm> --> F
 <is_vol_wm_jumpstart> --> F
 <ancil_dir> --> ancillary_data/
 <input_dir> --> input/
 <output_dir> --> output/
 <fname_ntopOld> --> rhone_rivertopo.nc
 <dname_sseg> --> seg
 <dname_nhru> --> hru
 <fname_qsim> --> total_runoff_rhone_pcr.nc
 <vname_qsim> --> qtot
 <vname_time> --> time
 <vname_hruid> --> ID
 <dname_xlon> --> longitude
 <dname_ylat> --> latitude
 <dname_time> --> time
 <dname_hruid> --> ID
 <input_fillvalue> --> -9999
 <units_qsim> --> mm/s
 <dt_ro> --> 86400
 <ro_calendar> --> standard
 <ro_time_units> --> days since 1661-01-01
 <is_remap> --> F
 <hydGeometryOption> --> 1
 <topoNetworkOption> --> 1
 <computeReachList> --> 1
 <param_nml> --> param.nml
 <varname_area> --> area
 <varname_length> --> length
 <varname_slope> --> slope
 <varname_HRUid> --> HRUid
 <varname_hruSegId> --> hruSegId
 <varname_segId> --> segId
 <varname_downSegId> --> downSegId
 <varname_islake> --> lake
 <varname_lakeModelType> --> lake_type
 <varname_LakeTargVol> --> target_vol
 <seg_outlet> --> -9999
 <ntopAugmentMode> --> F
 <fname_ntopNew> --> augmented_rhone_network.nc
 <debug> --> T
 <desireId> --> -9999
 <newFileFrequency> --> monthly
 <outputFrequency> --> monthly
 <histTimeStamp_offset> --> 0
 <basRunoff> --> T
 <instRunoff> --> T
 <dlayRunoff> --> T
 <sumUpstreamRunoff> --> T
 <KWTroutedRunoff> --> T
 <IRFroutedRunoff> --> T
 <MCroutedRunoff> --> T
 <KWroutedRunoff> --> T
 <DWroutedRunoff> --> T
 <KWTvolume> --> T
 <IRFvolume> --> T
 <KWvolume> --> T
 <MCvolume> --> T
 <DWvolume> --> T

---- calendar --- 
  calendar used for simulation and history output is the same as runoff input
  calendar used in runoff input is provided in control file: standard
  However, this will be overwritten the one read from total_runoff_rhone_pcr.nc

---- time units --- 
  time_unit for history files will be the same as runoff input
  time_unit in runoff input is provided in control file: days since 1661-01-01

---- runoff unit --- 
  runoff unit is provided as: mm/s

---- input time stamp --- 
  Input time stamp <ro_time_stamp>:  start
  The same time stamp is used for history output

---- output/simulation time steps --- 
  simulation time step <dt_qsim>:                86400.0
  history file freqeuncy <newFileFrequency>:  monthly
  history output freqeuncy <outputFrequency>: monthly

---- mis. routing options --- 

---- Read river network data --- 
  Reading area into structure HRU
  Reading HRUid into structure HRU2SEG
  Reading hruSegId into structure HRU2SEG
  Reading length into structure SEG
  Reading slope into structure SEG
  Reading segId into structure NTOPO
  Reading downSegId into structure NTOPO

[nmizukami]

if you use the runoff input like this:

netcdf total_runoff_rhone_pcr_2001 {
dimensions:
	ID = 2114 ;
	time = UNLIMITED ; // (365 currently)
variables:
	double time(time) ;
		time:long_name = "time" ;
		time:units = "days since 1661-01-01" ;
		time:calendar = "standard" ;
		time:standard_name = "time" ;
		time:axis = "T" ;
	double latitude(ID) ;
		latitude:long_name = "latitude" ;
		latitude:units = "degrees_north" ;
		latitude:standard_name = "latitude" ;
	double longitude(ID) ;
		longitude:long_name = "longitude" ;
		longitude:units = "degrees_east" ;
		longitude:standard_name = "longitude" ;
	double ID(ID) ;
		ID:long_name = "shape ID" ;
		ID:units = "1" ;
	double qtot(time, ID) ;
		qtot:_FillValue = -9999. ;
		qtot:long_name = "runoff" ;
		qtot:units = "kg m-2 s-1" ;

Your <vname_hruid> should be ID and and <dname_hruid> should be ID.

[arthurronner]

Those are the variable names and NetCDF dataset that I used. So this combination still results in the error above. I now see that I sent a slightly different control_file (with the wrong var names) - I changed it to the correct one in the question.

I was switching between two input files - hence the different variable names. Sorry for the confusion.

[nmizukami]

just make sure to setup <vname_hruid> and <dname_hruid> that match with variable/dimension names in the netcdf. I can see how you setup from your log (both are hru), but I don't know what runoff netcdf you actually used looks like. The one you sent to me uses ID for both HRU variable name and dimension.

[arthurronner]

Yes - I am 100% sure that these two align. I updated the log using the netcdf runoff file with the exact dimensions that you describe in your answer above.

[arthurronner]

When I do enter the wrong names, the error remains the same though. So maybe something breaks before the program needs these variables?

[nmizukami]

hmm... I am confused.. if you give wrong name in setup, I believe you get the same error. The program gets hru size from runoff netcdf directly and allocate the memory in fortran array. If you provide wrong name, it won't read the netcdf properly (the error should be triggered there actually). Can you ncdump your runoff netcdf? and also copy and paste your control file?

[nmizukami]

Ok, looking through your setup, I found a few errors (I guess our documentation was not clear).

can you remove these two items from your control file?

 <dname_xlon> --> longitude
 <dname_ylat> --> latitude

The table In the documentation now has

control variable | Default value | Description
<dname_xlon> | None | dimension name for x, lat, or j dimension in runoff netCDF(s). Only runoff is given in grid.
<dname_ylat> | None | dimension name for y, lon, or i dimension in runoff netCDF(s). Only runoff is given in grid.

So if you use gridded runoff you will need lat/lon dimenion name (NOT variable name). Because you are using hru runoff, so no need to provide anything. actually if you provide, the code seems to get confused.

[arthurronner]

Thank you, removing the dname_xlon and dname_ylat indeed removed the given error. The saga continues however, as I'm stuck at another error (which I originally ran into - MPI outputting Obtained 10 stack frames - and removed by adding the two variables in the control file). I'll open another thread highlighting it. Thanks again for the help!