Changes between Version 31 and Version 32 of 2018WP/SharedActions/Status_dev_merge_2017_branch
- Timestamp:
- 2018-03-09T10:40:53+01:00 (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
2018WP/SharedActions/Status_dev_merge_2017_branch
v31 v32 34 34 This branch must now be investigated to see which revision causes the failure et find the error. (Now ongoing at CNRS) 35 35 ''' 36 == 02 February 2018 36 == 02 February 2018: crash ORCA2_LIM3_PISCES (SOLVED) 37 37 a bug were found in dev_METO_MERCATOR_2017; now ORCA2 run 1500 timesteps: https://forge.ipsl.jussieu.fr/nemo/ticket/2006#ticket 38 38 … … 43 43 44 44 45 == 01 February 2018 45 == 01 February 2018: reproducibility problems come from CNRS branch 46 46 47 47 dev_merge_2017 (rev9271) : ORCA2LIM3PIS not reproducible and crashes at 179 timesteps ( so restartabily NOK because this run 150 timesteps ) … … 76 76 UPDATE 15 Feb: The failure is a segmentation fault in a deallocate statement in mpp_nfd_3d_ptr in a piece of code protected by l_north_nogather=.true. If I switch ln_nnogather to .false. (default value) then it runs OK (which probably explains why George can run ORCA1). 77 77 78 == 11 January 2018: pb with dynspg_ts (time splitting)78 == 11 January 2018: pb with dynspg_ts, time splitting (SOLVED) 79 79 80 80 Clément Rousset thinks there might have been a problem during merge of developments with dynspg_ts: looks like drag is computed twice so that energy is wrong and too big. This may be the reason for the crash of ORCA2 configuration for now after 200 timesteps (so that is is not send through SETTE tests sopping after 150 timesteps!