Segmentation fault when 'ln_river=.true.' in namelist_pisces_ref

lcbernardo · January 15, 2024, 6:39am

Hi everyone,

This issue arose in the process of solving another issue involving river inputs (origin date error, which has been resolved), which I now feel needs its own topic. I have been testing some of my model setups using both CROCO v1.3.1 and CROCO_MASTER, and it seems that when PISCES and river/runoff inputs are activated, setting ‘ln_river=.true.’ in namelist_pisces_ref results in a segmentation fault. In the output log, it seems it occurs just as the model starts to run:

   GET_PSOURCE_TS -- Read conc fields of tracer    1 for time =   0.4393E+05    0
  GET_PSOURCE_TS -- Read conc fields of tracer    1 for time =   0.4396E+05    0
  GET_PSOURCE_TS -- Read conc fields of tracer    2 for time =   0.4393E+05    0
  GET_PSOURCE_TS -- Read conc fields of tracer    2 for time =   0.4396E+05    0
  GET_PSOURCE_TS -- Read conc fields of tracer    7 for time =   0.4393E+05    0
  GET_PSOURCE_TS -- Read conc fields of tracer    7 for time =   0.4396E+05    0
  GET_PSOURCE_TS -- Read conc fields of tracer    9 for time =   0.4393E+05    0
  GET_PSOURCE_TS -- Read conc fields of tracer    9 for time =   0.4396E+05    0
  GET_PSOURCE_TS -- Read conc fields of tracer   25 for time =   0.4393E+05    0
  GET_PSOURCE_TS -- Read conc fields of tracer   25 for time =   0.4396E+05    0
  GET_BULK   -- Read fields for bulk formula   for time = 43950.5000    0
  GET_BULK   -- Read fields for bulk formula   for time = 43950.5417    0
  DEF_HIS/AVG - Created new netCDF file 'CROCO_FILES/SB_his.nc'.  mynode =   0
  WRT_GRID -- wrote grid data into file 'CROCO_FILES/SB_his.nc'.   mynode =   0
  WRT_HIS -- wrote history fields into time record =   1 /   1  mynode =  0

MAIN: started time-stepping

2020-05-01 12:00:00
STEP time[DAYS] DIC ALK OXY POC PHY ZOO DOC NO3 FER trd
0 0.00069 2.2655164E+03 2.3400197E+03 1.6850904E+02 1.0000000E-02 2.2665480E-05 2.2665480E-05 2.7561186E-02 8.6918717E-03 1.1632367E-06 0

Number of days per year in file year2daydta = 0.000000000000000E+000

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
libpthread-2.17.s 00002AAC764FE5D0 Unknown Unknown Unknown
croco 00000000004CB7EC Unknown Unknown Unknown
croco 000000000057A3B2 Unknown Unknown Unknown
croco 00000000007A7EC7 Unknown Unknown Unknown
croco 0000000000690167 Unknown Unknown Unknown
croco 0000000000691462 Unknown Unknown Unknown
croco 000000000062888B Unknown Unknown Unknown
croco 00000000006285AD Unknown Unknown Unknown
croco 000000000040322D Unknown Unknown Unknown
libc-2.17.so 00002AAC781EF3D5 __libc_start_main Unknown Unknown
croco 0000000000403159 Unknown Unknown Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
libpthread-2.17.s 00002AE3AD92C5D0 Unknown Unknown Unknown
croco 00000000004CB7EC Unknown Unknown Unknown
croco 000000000057A3B2 Unknown Unknown Unknown
croco 00000000007A7EC7 Unknown Unknown Unknown
croco 0000000000690167 Unknown Unknown Unknown
croco 0000000000691462 Unknown Unknown Unknown
croco 000000000062888B Unknown Unknown Unknown
croco 00000000006285AD Unknown Unknown Unknown
croco 000000000040322D Unknown Unknown Unknown
libc-2.17.so 00002AE3AF61D3D5 __libc_start_main Unknown Unknown
(and so on…)

If I set ‘ln_river=.false.’ instead, the model works without any problems. I have tried this for several setups already, with 2 river inputs or more defined, but always seem to end up with the same issue. I also tried running the same configuration using an older version of CROCO (ver1.1) which also has a similar flag, and it runs with no issues even if ‘ln_river=.true.’.

Has anyone encountered (and resolved) a similar issue? I would greatly appreciate any help or advice.

Lawrence

xzhou473 · January 17, 2024, 5:18pm

Hi Lawrence,

My experience is the CROCO-PISCES adding biogeochemistry from the river from another way (using tracers). You can neglect this option when you want to add something from the river.

lcbernardo · January 18, 2024, 2:10am

Hi xzhou473,

Thank you for your reply. After inserting some lines of code to test, indeed as you mentioned, it seems the tracer values are still read from the river input file even if ‘ln_river=.false.’. I am now testing this directly by using river inputs with different nutrient loads and observing the model biogeochemistry outputs.

Lawrence

Renaud · January 24, 2024, 9:04am

Indeed, the namelist parameter ln_river does not work when using PISCES with CROCO. This option can only be activated with the NEMO ocean model. In the next version of CROCO, we will remove this parameter from PISCES to avoid confusion. With CROCO, you need to create the runoff file with the crocotools. In the latest release, you can only add no3 to the runoff. In the croco_tools master branch, we’ve updated the crocotools to add all the needed bgc tracers from rivers for the PISCES model. You can test this version to create your runoff file and run your model with rivers.

lcbernardo · January 25, 2024, 2:37am

Hi Renaud,

Thank you for your reply and the detailed explanation. With this I guess I can continue to use CROCO with PISCES without worrying about the ln_river option. As for creating the runoff file, since the rivers in my study domains are not included in the Dai and Trenberth database, I usually create my file based on the instructions in the online documentation (using ncgen). So far, this approach also seems to work for setting the river inputs.

Lawrence