In routing module the basin ID = - 1 for Indus

[pmessina]

Running ORCHIDEE with the new CERA-20C forcing seems to show up a possible bug in the routing calculation.
When the RIVER_ROUTING flag is set to “y”, the simulation stops after some minutes giving the following error message:

MPI_ABORT was invoked on rank 0 in communicator MPI COMMUNICATOR 3 SPLIT FROM 0 
with errorcode 210. 

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes. 
You may or may not see output from other processes, depending on 
exactly when Open MPI kills them. 
-------------------------------------------------------------------------- 
srun: error: curie2677: task 0: Exited with exit code 210 
srun: Terminating job step 7266847.0 
slurmd[curie2677]: error: *** STEP 7266847.0 KILLED AT 2017-02-09T15:41:10 WITH SIGNAL 9 *** 
slurmd[curie2678]: error: *** STEP 7266847.0 KILLED AT 2017-02-09T15:41:10 WITH SIGNAL 9 *** 
srun: Job step aborted: Waiting up to 2 seconds for job step to finish. 
slurmd[curie2677]: error: *** STEP 7266847.0 KILLED AT 2017-02-09T15:41:10 WITH SIGNAL 9 *** 
slurmd[curie2678]: error: *** STEP 7266847.0 KILLED AT 2017-02-09T15:41:10 WITH SIGNAL 9 *** 
srun: error: curie2677: tasks 1-15: Killed 
srun: error: curie2678: tasks 16-31: Killed 

While in the standard output of simulation, we have:

0Basin ID    14 Mackenzie       Area [km^2] :  1711302.0953 Nb points :  494 
0Basin ID    15 Ganges          Area [km^2] :  1631829.9818 Nb points :  254 
0Basin ID    16 Chari           Area [km^2] :  1574841.8866 Nb points :  205 
0Basin ID    17 Volga           Area [km^2] :  1467111.4645 Nb points :  360 
0Basin ID    -1 �@^@^@^@^@^@^@�?^@^@^@^@^@ Area [km^2] : 1278714.7087 Nb points :  223 
0Basin ID    20 Syr-Darya       Area [km^2] :  1078927.1010 Nb points :  221 
0Basin ID    22 Orinoco         Area [km^2] :  1045616.0412 Nb points :  136 
0Basin ID    23 Murray          Area [km^2] :  1033681.8711 Nb points :  166 

Generally we should have an output like this one :

Basin ID    13 Chang Jiang (Ya Area [km^2] :  1796227.6386 Nb points :  319
Basin ID    14 Mackenzie       Area [km^2] :  1676381.0109 Nb points :  498
Basin ID    15 Ganges          Area [km^2] :  1631831.7040 Nb points :  271
Basin ID    16 Chari           Area [km^2] :  1571831.6727 Nb points :  232
Basin ID    17 Volga           Area [km^2] :  1466393.1031 Nb points :  380
Basin ID    19 Indus           Area [km^2] :  1145507.8256 Nb points :  187
Basin ID    20 Syr-Darya       Area [km^2] :  1071633.9781 Nb points :  215
Basin ID    22 Orinoco         Area [km^2] :  1041547.3128 Nb points :  147
Basin ID    21 Nelson          Area [km^2] :  1032236.9284 Nb points :  238
Basin ID    23 Murray          Area [km^2] :  1028341.0799 Nb points :  171
Basin ID    24 Great Artesian  Area [km^2] :   979572.7398 Nb points :  157 

The problem comes from the index associated to the basin ID: the topids variable in routing_diagnostic subroutine. For Indus, topids should be 19, but for some reasons is -1.
In the code topids comes from bname variable that is defined in routing_findbasins subroutine. This subroutine collect in one basin all rivers of the same grid cell which directly flow into the ocean. When this operation is done bname is set to -1 for the secondary rivers that are gathered in the principal one, but somehow bname=-1 is associated to the principal river in this grid cell. This should be the source of the problem.

[jgipsl]

Mail de Jan:

on a réglé cela dans la branche ORCHIDEE-ROUTING avec les lignes suivantes :

       ELSE
          sorted_names(icc) = basin_names(topids(ib))
       ENDIF

by :

       ELSE
          IF (topids(ib) <= -1 ) THEN
             WRITE(sorted_names(icc), '("Ne_",I2.2)') -1*topids(ib)
          ELSE
             WRITE(*,*) ">>> nb_small, ib, topids :", nb_small, ib, topids(ib)
             sorted_names(icc) = basin_names(topids(ib))
          ENDIF
       ENDIF

C'est Trung qui avait cela en mémoire et on l'a fait que dans routing_reg.f90. Il faudrait tester avant le comit.

A bientot

Jan

[jgipsl]

Palmira Messina tested this solution with success using the test case with CERA-20C forcing as above.

Done in the trunk rev [4196]. The write is now done only for printlev>=6.