Up to Specific issues in real coupled models
Good morning I'm running the FOCI-OpenIFS coupled model (OpenIFS 43r3 + NEMO 3.6/LIM2 + OASIS3-MCT5). This model is usually run with "GAUSWGT" remapping for almost all fields and "GLBPOS" conservation when remapping OpenIFS surface fluxes to the NEMO grid, e.g. TotRain. Recently, I've been testing 1st order CONSERV remapping instead, but this causes a "signal 11" crash (which means "segmentation fault") when I use the "GLBPOS" conservation option. From my understanding, the error can happen when the code accesses an array outside its bounds, but I can't work out why that would happen here. Here's what I used (which crashes after 11 days and 18 hours): A_QsrMix:A_QnsMix:ATotRain:ATotSnow:AIceEvap:ATotEvap O_QsrMix:O_QnsMix:OTotRain:OTotSnow:OIceEvap:OTotEvap 8 3600 4 atmflx EXPORTED 40320 1 722 511 A096 opac LAG=1800 P 0 P 2 LOCTRANS SCRIPR MAPPING CONSERV AVERAGE CONSERV D SCALAR LATITUDE 1 FRACNNEI FIRST rmp_A096_to_opac_CONSERV_ORCA05.nc GLBPOS If I switch to "GLOBAL" conservation, it runs for a few more months but still crashes with the same "signal 11". And again: The model runs fine with "GAUSWGT" and "GLBPOS", so the error seems to be due to combining 1st order CONSERV and GLBPOS/GLOBAL. I've compiled both OpenIFS and OASIS with "-g -traceback -CB" to see if I get some information about where the "signal 11" crash comes from. But all I get is: 150: oifs:569995 terminated with signal 11 at PC=eb87ee SP=7fffff55fc80. Backtrace: 150: ./oifs[0xeb87ee] 150: ./oifs[0xd89d33] which gives no information about where the crash occurs. I've activated high-frequency output from OpenIFS and also used "EXPOUT" option and inspected the fields. They look completely fine. No strange values anywhere. Has anyone else had these segmentation fault crashes with GLBPOS/GLOBAL? Does anyone have some idea what the cause could be? Best wishes Joakim
