Main menu


inconsistency between land fraction and sea ice fraction

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

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


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?


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. 


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.



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 file and the datfile as the 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? 


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.


OK, here is an update. Thanks for the help so far. The problem was that the mkgriddata tool to create the file had a problem with landfraction in the order of 0.0005. The error message was related to the fact that in the 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 file. Both, the file and the file had the correct landfraction. However, now I am wondering, if the mksurfdata tool has a similar issue. As I mentioned, the created file has the correct values. However, running the model with the corrected 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


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          00007FFBC9F59CDD  Unknown               Unknown  Unknownccsm.exe           000000000040E759  Unknown               Unknown  UnknownAPPLICATION TERMINATED WITH THE EXIT STRING: Hangup (signal 1) 

Any new ideas?


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?


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.      



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 file, but 1 in the and 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

  • alessandro.delo...
  • zweina@...
  • yuan.liang@...
  • lian.xue@...
  • 353482168@...