I am using FESOM2.5 in a version where Lars put iceberg code into in a version of AWI-ESM2-wiso. I think though that this might be a general issue for FESOM2.
A run on albedo crashed during writing output because of disk quota. I noted that when simply resubmitting the simulation after solving the quota issue FESOM2 does crash when trying to write output files that are already there:
/albedo/work/user/stepanek/esm_experiments_6/piControl/log/piControl_awiesm_compute_20500101-20501231_7042474.log
0: piControl_205101.01_g3bid g3bid 73 T T
0: piControl_205101.01_jsbid jsbid 71 T T
0: piControl_205101.01_sp6h sp6h 69 T T
746: error in line 424 io_netcdf_file_module.F90 NetCDF: File exists && NC_NOCLOBBER
792: initializing I/O file for u
583: associating mean I/O file /albedo/work/user/stepanek/esm_experiments_6/piControl/run_20500101-20501231/work/w.fesom.2050.nc
583: w: current mean I/O counter = 1
583: writing mean record for w; rec. count = 1
746: 1
Is there a good reason why FESOM2 behaves that way? Or could one change (compile-time) flags to make FESOM2 be less bothered by existing output files?
I am using FESOM2.5 in a version where Lars put iceberg code into in a version of AWI-ESM2-wiso. I think though that this might be a general issue for FESOM2.
A run on albedo crashed during writing output because of disk quota. I noted that when simply resubmitting the simulation after solving the quota issue FESOM2 does crash when trying to write output files that are already there:
Is there a good reason why FESOM2 behaves that way? Or could one change (compile-time) flags to make FESOM2 be less bothered by existing output files?