iCESM-related questions

[yzLiu]

Dear all:
I have some trouble and confusion in running iCESM1.2 and iCESM1.3, some of them maybe detailed issues and others are general, which followd below.

1. The currently publicly available version on GitHub is iCESM1.2. However, when I test it by setting 'init_wiso_option' to 'file' and providing initial NetCDF format files for Delta18O and DeltaD (I'm not sure if R18O needs to be given), it seems that the ocean's log file does indeed read this file, but the output for Delta18O and DeltaD are NaN. Also, in 'namelist_definition_pop2.xml', it says '(this option does not work)'. I'm wondering if there's a way to resolve this issue, or is it possible to use a hybrid run and then change the current and old timestep seawater isotope distribution in the restart files? By the way, how long will water isotopes spin up for the upper and deep ocean if the seawater oxygen isotope initial condition is far away from the equilibrium, and if we have some spin up variables such as wind field, atmosphere and sea surface temperature from previous paleoclimate case, and take them for the IC or replace the restart files with previous spin up case, will it accelerate the water isotope spin up?

2. iCESM1.2 now includes abiotic 14C and neodymium isotopes. iCESM1.3 has a more comprehensive range of isotopes, including biotic δ13C and △14C as well as Pa/Th, but these are limited to the ocean module. It seems that carbon isotopes are also included in the CLM4.5 and LPX-Bern models, but there doesn’t seem to be a fully coupled CESM carbon isotope model released yet, right?

3. Compared with iCESM1.2, there is not much information related to iCESM1.3, are there significant differences between CESM1.2.2 and CESM1.3? It failed when I attempted to run iCESM1.3 with water isotopes, which says 'MCT::m_AttrVect::indexRA_:: FATAL--attribute not found: "Sl_qref_16O" Traceback: |X|MCT::m_AttrVect::indexRA_' in cesm.log, is there any difference between running iCESM1.2 and iCESM1.3 with water isotopes? And I wonder if running iCESM1.3 requires providing a land surface initial file containing isotopes, just like iCESM1.2 does.

4. In iCESM1.2, the default 'wiso_use_nml_surf_vals' is set to '.true.', and 'surf_avg_d18o_const' can be set to a constant. Otherwise, it seems that the ocean surface oxygen isotope is calculated. May I ask what impact this option has on running a fully coupled experiment? Also, what is the meaning of the ocean surface isotope flux correction 'wiso_sflx_correction_18o'? If considering the injection of meltwater, it should be modifying 'LIMW_F' in a specific area, and if considering the positive bias of the average value of seawater isotopes during the LGM, does it mean increasing the oxygen isotope values at all grid points in the 'init_wiso_init_file'?

5. iCESM1.2 requires the use of CAM5, which unlike CAM4, does not set the solar constant directly through 'solar_const' but reads the solar spectrum from a file. How can we modify the solar constant when simulating a paleoclimate? Also, CAM5's atmospheric chemistry module is more refined and does not use a 'prescribed_aero_file' like CAM4. In paleoclimate simulations, a prescribed, globally uniform aerosol distribution is usually used. Can a prescribed aerosol distribution also be set in CAM5?

I am grateful to any relevant answers or solutions in solving these problems!

 

[jiangzhu]

Hi Yizhang,

There are multiple versions of the iCESM that have been use for different project.

Please specify which version of the code you are referring to. Please provide the svn/github link.

 

[jiangzhu]

If you are using GitHub - NCAR/iCESM1.2: Isotope-enabled CESM1.2
that code uses Delta18O as ocean tracer (NOT R18O).

The following namelists should work
init_wiso_option = 'file'
init_wiso_init_file_fmt = 'nc'
init_wiso_init_file = 'your_delta18O_file.nc' ! contains 3D Delta18O & DeltaD fields.

You need to make sure your have initial condition values for all your valid ocean grid points; this is usually not a problem unless you are doing a paleoclimate simulation with a different POP bathymetry.

 

[yzLiu]

If you are using GitHub - NCAR/iCESM1.2: Isotope-enabled CESM1.2
that code uses Delta18O as ocean tracer (NOT R18O).

The following namelists should work
init_wiso_option = 'file'
init_wiso_init_file_fmt = 'nc'
init_wiso_init_file = 'your_delta18O_file.nc' ! contains 3D Delta18O & DeltaD fields.

You need to make sure your have initial condition values for all your valid ocean grid points; this is usually not a problem unless you are doing a paleoclimate simulation with a different POP bathymetry.

Thanks, I really use this version of iCESM1.2, and my nc file indeed contains 3D Delta18O and DeltaD, do I need to provide other coordinate variables, such as TLONG, TLAT and so on?

 

[yzLiu]

Thanks, I really use this version of iCESM1.2, and my nc file indeed contains 3D Delta18O and DeltaD, do I need to provide other coordinate variables, such as TLONG, TLAT and so on?

And I use NCL function PopLatLon to regrid the original 1x1d d18o with 33 levels in depth from LeGrande and Schmidt 2006 to gx3v7, and then use int2p_n_Wrap to interpolate it to 60 levels, maybe some errors to the pop grids?

 

[jiangzhu]

I see. It is possible that your interpolation did not work as intended, i.e., you have NaN values for valid ocean grid points after interpolation.

You could either carefully check your regridding procedure and ensure that you don't have NaNs for ocean grid points, or you could start from available ocean restart files: iCESM1.2 restart file from "The Connected Isotopic Water Cycle in the Community Earth System Model Version 1"

The shared restart file is in gx1v6 with 60 levels, which may make it easier for you to get fields with 60 levels.

 

[littledddna@gmail_com]

Hi all,

I'm running a fully coupled iCESM1.3 MIS3 paleoclimate simulation (T31_g37, gx3v7) on a non-NCAR HPC with wiso_formulation='model' and -water_tracer h2o_h216o_hdo_h218o (-nadv 37). The isotope coupling through the coupler is working — PREC_18O_F, EVAP_18O_F etc. are all present in POP history output, and POP R18O evolves correctly during the initial run. The run produces correct POP isotopes for the full 13 months when started from this clean ncdata.

The problem: after running ~13 months from a clean initial condition (ncdata with all isotope phases = 0 or physically reasonable values, produced via interpic from a 1000-year equilibrated iCESM1.3 restart), the CAM restart file contains NaN in several Q array slots corresponding to the convective precipitation isotope phases (RAINC and SNOWC for H216O, HDO, and H218O — specifically Q slots 16–18, 23–25, 30–32). The other isotope phases (VAPOR, LIQUID, ICE, RAINS, SNOWS) are fine.

When I branch from this restart, the NaN values contaminate all isotope phases on the first timestep, the coupler sends NaN isotope fluxes to POP, and POP R18O immediately becomes NaN everywhere.



I traced the issue to the convective scheme (uwshcu.F90) where wtrc_ratio() is called. The function in water_tracers.F90 has a guard:

if (abs(qtot) < wtrc_qmin) then
wtrc_ratio = wtrc_get_rstd(ispec)
else
wtrc_ratio = qtrc / qtot
end if

with wtrc_qmin = 1e-18. This should prevent division by zero, but NaN is still being generated somewhere in the convective isotope processing — possibly when qtot or qtrc is already NaN from a previous operation, bypassing the qtot < wtrc_qmin check.

should i modify this part accroding that i can sucessfully branch the case? Any guidance would be appreciated.

Thanks very much

Xiao