Main menu

Navigation

inconsistency between land fraction and sea ice fraction

11 posts / 0 new
Last post
nadinsel@...
inconsistency between land fraction and sea ice fraction

Hi,

I am running CESM 1.0.4 in compset F (cam stand-alone). I created new boundary conditions based on different paleogeographies. When running the model, I get the following error message:

 

MCT::m_Router::initp_: GSMap indices not increasing...Will correct
MCT::m_Router::initp_: RGSMap indices not increasing...Will correct
MCT::m_Router::initp_: RGSMap indices not increasing...Will correct
MCT::m_Router::initp_: GSMap indices not increasing...Will correct
inconsistency between land fraction and sea ice fraction
inconsistency between land fraction and sea ice fraction
inconsistency between land fraction and sea ice fraction
inconsistency between land fraction and sea ice fraction
inconsistency between land fraction and sea ice fraction
inconsistency between land fraction and sea ice fraction
inconsistency between land fraction and sea ice fraction
n= 315 fracl= 0.000000000000000E+000 fraci=
0.999156976148995 sum= 0.999156976148995
n= 39 fracl= 0.000000000000000E+000 fraci=
0.999156976148994 sum= 0.999156976148994
n= 427 fracl= 0.000000000000000E+000 fraci=
0.999441997848369 sum= 0.999441997848369
(domain_check_mct) : inconsistency between land fraction and sea ice fraction
n= 279 fracl= 0.000000000000000E+000 fraci=
0.999721724263899 sum= 0.999721724263899
n= 171 fracl= 0.000000000000000E+000 fraci=
0.999441997848369 sum= 0.999441997848369
(domain_check_mct) : inconsistency between land fraction and sea ice fraction
(domain_check_mct) : inconsistency between land fraction and sea ice fraction
n= 367 fracl= 0.000000000000000E+000 fraci=
079.MCT(MPEU)::die.: from (domain_check_mct)()
0.999721724263899 sum= 0.999721724263899
(domain_check_mct) : inconsistency between land fraction and sea ice fraction
(domain_check_mct) : inconsistency between land fraction and sea ice fraction
(domain_check_mct) : inconsistency between land fraction and sea ice fraction
application called MPI_Abort(MPI_COMM_WORLD, 2) - process 121
143.MCT(MPEU)::die.: from (domain_check_mct)()
142.MCT(MPEU)::die.: from (domain_check_mct)()
07A.MCT(MPEU)::die.: from (domain_check_mct)()
application called MPI_Abort(MPI_COMM_WORLD, 2) - process 323
application called MPI_Abort(MPI_COMM_WORLD, 2) - process 322
application called MPI_Abort(MPI_COMM_WORLD, 2) - process 122
1C8.MCT(MPEU)::die.: from (domain_check_mct)()
1C9.MCT(MPEU)::die.: from (domain_check_mct)()
application called MPI_Abort(MPI_COMM_WORLD, 2) - process 456
application called MPI_Abort(MPI_COMM_WORLD, 2) - process 457
n= 171 fracl= 0.000000000000000E+000 fraci=
0.999441997848478 sum= 0.999441997848478
(domain_check_mct) : inconsistency between land fraction and sea ice fraction
185.MCT(MPEU)::die.: from (domain_check_mct)()
application called MPI_Abort(MPI_COMM_WORLD, 2) - process 389
APPLICATION TERMINATED WITH THE EXIT STRING: Hangup (signal 1)

 

Obviously there is discrepancy between the land and sea ice fraction. I would like to know where the model looks for the sea ice fraction. The model is running fine as long as I don't use the paleo fracdata and domain.camocn files. However, if I compare those two files, the sum of LANDFRAC from the fracdata.nc and frac from domain.camocn.nc is exactly 1 everywhere, so I don't see where the error is coming from. Is there a different file that defines the sea ice fraction? ICEFRAC in the cami*.nc file is zero. 

nadinsel@...

Also: ice_ic is set to 'none' so there shouldn't be any sea-ice at all. 

dbailey

A couple things. If you change the land mask, you need to make sure the sea ice/ocean model also has a modified land mask. This is true even in an F compset. Secondly, the ice_ic only determines the initial ice fraction. The sea ice is then specified using the dataset that is the same as the SST in DOCN. Did you set this up with a different ice fraction/SST dataset?

nadinsel@...

I did change the landmask in the sea ice/ocean model. I also changed the ice_cov in the SST file to be zero. I did not change the SST data though. 

dbailey

O.k. the ice fraction data namelist is in user_nl_cice as this is run from the CICE prescribed mode. The SST data are specified via the docn_streams.txt file. However, both point to the same file. This can certainly be confusing.

Dave

nadinsel@...

Mhm, ok I think the problem is in the SSTs. If I run the model with sice instead of cice I get the error message with "inconsistency between land fraction and ocn land fraction" with the exact same values. The good thing is that confirms that the model reads the same files for ocean and ice. The SST file does not have mask or fraction, but I can see that the SST dataset is based on original data that have been regrid and interpolated. You mentioned that the sea ice is specified using the dataset that is the same as the SST in DOCN. So does the domain check also uses the SST for the ocean and sea ice fraction (instead of the frac in the domain.camocn*.nc file)? And if so, is it somehow distinguishing between orginal SST values and interpolated values over land?

I checked the docn_streams.txt file and it defines the domfile as my modified domain.camocn.nc file and the datfile as the SST.nc. file. As I mentioned before, I didn't change the SSTs, so do I have to modify them according to my landmask and then need to interpolate over the new landmask? 


dbailey

Right. The grid and mask information needs to be supplied along with the SST/ifrac file. These are specified in the CICE namelist and in the docn.streams.txt file. If you have area, mask, lat, and lon in your SST/frac file, it can just get the grid information from there. If you are interpolating from say a 1x1-degree grid to the model FV grid (1.9x2.6?), then the SST data should be filled in land areas (i.e. extrapolated from the ocean cells) for the best interpolation results.

nadinsel@...

OK, here is an update. Thanks for the help so far. The problem was that the mkgriddata tool to create the fracdata.nc file had a problem with landfraction in the order of 0.0005. The error message was related to the fact that in the fracdata.nc file gridpoints with a landfraction of <0.001 were assigned a 0 landmask and 0 landfraction. I corrected it by just copying over the correct values for LANDMASK and LANDFRAC from the bnd_topo.nc file. Both, the bnd_topo.nc file and the surfdata.nc file had the correct landfraction. However, now I am wondering, if the mksurfdata tool has a similar issue. As I mentioned, the created surfdata.nc file has the correct values. However, running the model with the corrected fracdata.nc file gives an error message for  

QNEG4 WARNING from TPHYSAC  Max possible LH flx exceeded at    1 points. , Worst excess =  -3.9999E-06, lchnk = ***, i =    1, same as indices lat =  28, lon = 337

QNEG3 from TPHYSBCb:m=  3 lat/lchnk=  466 Min. mixing ratio violated at    1 points.  Reset to  0.0E+00 Worst =-1.1E-12 at i,k=   2  1

clh GAMMA:  NaN                      0.000000000000000E+000

  0.000000000000000E+000 NaN                       1.00000000000000

  0.000000000000000E+000

and ends with a  forrtl: severe (174): SIGSEGV, segmentation fault occurredImage              PC                Routine            Line        Sourceccsm.exe           0000000000E4681D  tp_core_mp_xtpv_.         469  tp_core.F90ccsm.exe           0000000000E39EC3  tp_core_mp_tp2c_.         119  tp_core.F90ccsm.exe           0000000000DFE856  sw_core_mp_c_sw_.         309  sw_core.F90ccsm.exe           0000000000C992F4  cd_core_.R                732  cd_core.F90ccsm.exe           000000000094B3F7  dyn_comp_mp_dyn_r        1820  dyn_comp.F90ccsm.exe           0000000000684C48  stepon_mp_stepon_         420  stepon.F90ccsm.exe           000000000049E1D4  cam_comp_mp_cam_r         225  cam_comp.F90ccsm.exe           000000000048A096  atm_comp_mct_mp_a         549  atm_comp_mct.F90ccsm.exe           000000000041056E  ccsm_comp_mod_mp_        2166  ccsm_comp_mod.F90ccsm.exe           00000000004285DD  MAIN__                     91  ccsm_driver.F90ccsm.exe           000000000040E85C  Unknown               Unknown  Unknownlibc.so.6          00007FFBC9F59CDD  Unknown               Unknown  Unknownccsm.exe           000000000040E759  Unknown               Unknown  UnknownAPPLICATION TERMINATED WITH THE EXIT STRING: Hangup (signal 1) 

Any new ideas?

nanr

It's possible that your problem may arise from small inconsistencies between mapping files if you used different versions of SCRIP to remap your data.  What mkgriddata version are you using, and what version of cesm?  Maybe you could briefly outline the mapping steps you used?

nadinsel@...

I am running the F compset of CESM_1.0.4 with a f05_f05 resolution. I started with a paleo geograraphy and vegetation file. I downloaded the paleo toolkit and went throught the following steps:

- I use paleo_mkraw to create the rawfiles, use mksurfdata under /models/lnd/clm/tools/ to create the surfdata file 

- I use ccsm4_cami_bnd_topo_paleo to create the cami_bnd_topo_file (correcting for missing values in first and last line)

- I use mkgriddata under /models/lnd/clm/tools/ to create the griddata and fracdata files

- I use cam_tools to create the cami file and the mk_docn.domain file to create the domain.camocn file

- I changed the sea_ice in the SST file by hand.

Now, the model works with the modified files if I don't use the fracdata and domain file. The moment I use these two files I get warnings for QNEG3 and QNEG4, I get  filew failed, worst i, j, qtmp, q =, I get clh GAMMA:NaN , and finally a segmentation fault.      

 

nadinsel@...

Update: First, I also have a new RTM file that I created with cam_tools. Anyhow, I can get rid of the QNEG3 warning when I am using an existing cami_file and just change the PS according to my topography (basically using a more realistic temperature and wind profile than just creating an equator to pole gradient). I am worried because I can get rid of the clh GAMMA: NaN error by correcting the previously mentioned landfraction inconsistency by ascribing the oceanfraction to 1 (instead of leaving the oceanfraction >0.999 and using the correct LANDFRAC values of <0.001). That shouldn't happen, because then the LANDMASK for those specific points is 0 only in the fracdata.nc file, but 1 in the bnd_topo.nc and surfdata.nc files. The QNEG4 warning also exists in my modern control run, so I think that might be an issue with the high resolution. However, the model runs for 25 timesteps. The atm and clm models have completed 25 time steps, the ocean model has 24 timesteps completed with the ice model one step . Then I run into the segmentation fault error mentioned above. 

Does anybody has an idea how to solve the problem? Or at least how to get a better idea why the application terminated? Looking at the fortran files listed below the segmentation fault doesn't really help. 

 

Log in or register to post comments

Who's new

  • 20171204300@...
  • poornadurga.g@...
  • lina.boljka@...
  • nuistwangjing@...
  • vineetm@...