wiki:FrequentlyAskedQuestions

MPAS-CICE

answers current as of October 11, 2013

Q: Why is CICE being moved into the MPAS framework?

A:

  1. Our ocean model is becoming MPAS-Ocean, and it's best for coupling purposes that the ocean and sea ice model components both run on the same grid.
  2. We will be able to focus resolution in the polar regions and other areas where higher resolution would be beneficial.
  3. As part of the MPAS framework, much of the infrastructure will be maintained by other people, freeing up sea ice modeling resources to concentrate on sea ice physics.

Q: Will MPAS-CICE be capable of running on structured grids in addition to unstructured grids?

A: Yes.

Q: Will LANL scientists continue to develop parameterizations and infrastructure for the current CICE model?

A: We are planning additional physics development, but what we do here at LANL will be aimed at MPAS-CICE. See http://oceans11.lanl.gov/trac/CICE/wiki/CiceDev for a list of our current development plans and collaborations. While the basic MPAS-CICE model is being developed, some parameterization work will be conducted in CICE v5.0.

One of our early MPAS-CICE efforts will be to extract all of the column physics (thermo, mechanical redistribution, etc) into a separate package that can be used with both CICE and MPAS-CICE. Note that this will require some restructuring of CICE itself, to implement the necessary interfaces. Then we will convert the grid-dependent functions (dynamics, rheology, transport) to use MPAS's operators, which reside in a library for all of the MPAS component models to use.

Q: Will new developments from outside LANL continue to be implemented in the current CICE model?

A: We will continue to support CICE 5 to the extent necessary, at least until MPAS-CICE “goes public” and becomes the official Los Alamos Sea Ice Model. If new developments are cleanly coded, well tested and documented, then it is relatively easy to add them to the current CICE model repository to share with the community.

Q: Will new developments from outside LANL be implemented in MPAS-CICE?

A: Developments that involve only column calculations may become part of the column package that works with both CICE and MPAS-CICE. Developments that require spatial derivatives and other grid-dependent operations will need to be coded using MPAS’s operators.

We expect the new model to appeal to CICE’s user community and to become the new community sea ice model after some time. In order for this to happen, the model must evolve in response to the community’s needs, and this largely happens through contributions to the code by the community. We intend for this productive interaction to continue once the initial MPAS-CICE model has been implemented. In particular, we will work with community developers to move options now available in CICE v5.0 that are desired by the community but not part of the default configuration into MPAS-CICE.

Q: When and how will non-DOE scientists be able to access MPAS-CICE?

A: When outside groups will be able to access the new model depends on how quickly development proceeds. Our current plan is to have a working model by mid-2016, and then it usually takes several months to get the code ready for a public release. However, outside collaborators working with us to further develop the model may be allowed earlier access, as is the case now with CICE. An access and intellectual property policy that would apply to all of the model components of the DOE-ESM (including MPAS-CICE) is under discussion now.

Q: Where can I find out about the MPAS framework?

A: http://mpas-dev.github.io/

Q: Enthalpy corrections My diagnostics file contains a warning that the initial temperature is too warm. The code recovers, but what is happening here?

 Starting thermo, T > Tmax, layer           1
 istep1, my_task, i, j, k:       49167          29           4         190           1
 zTin = -7.658739752000057E-002 , Tmax= -7.660018851607993E-002
 zSin =   1.41357047372424     
 hin =   4.71848719600473     
 zqin =  -331444.829450586     
 qmlt=  -331500.184635007     
 Tmlt= -7.660018851607993E-002
 Corrected quantities
 zqin=  -331501.184635007     
 zTin= -7.660018876641461E-002

A: In order to ensure conservation of energy and salt content, the advection routines will occasionally limit changes to either enthalpy or bulk salinity. The mushy thermodynamics routine determines temperature from both enthalpy and bulk salinity. Since the limiting changes performed in the advection routine are not applied consistently (from a mushy physics point of view) to both enthalpy and bulk salinity, the resulting temperature may be changed to be greater than the limit allowed in the thermodynamics routines. If this situation is detected, the code corrects the enthalpy so the temperature is below the limiting value. Conservation of energy is ensured by placing the excess energy in the ocean. The code also writes a warning that this has occurred to the diagnostics file, as in the example above. This situation only occurs with the mushy thermodynamics (ktherm=2) and should only occur very infrequently and have a minimal effect on results. The addition of the heat to the ocean may reduce ice formation by a small amount afterwards.

Q: EVP time steps Although the CICE documentation gives good hints how to choose the main time step dt, it is not clear to me where the ratio 1:40:120 is derived. I would be really grateful if you could give some advice how to make "the best" choice for the EVP sub-time stepping and value of E0.

A: The subcycling step in EVP is really an iteration to damp out the elastic waves, which are generated every time the mass/strength changes. The ratio, 1:40:120, is essentially the subcycling time step to the damping timescale to the full time step, the full time step being defined by when the mass, strength and surface forcing changes. We need the damping timescale to be sufficiently shorter than the full time step so that the elastic waves CAN damp out within it, and we need the subcycling timestep sufficiently shorter than the damping timescale to actually accomplish the damping. A choice of 1:80:240 is better in the sense that you'll damp the elastic waves more completely, but on the other hand it will be more expensive to run---the parameter choices are really a balancing act between how small the residual error is and how many computational cycles you're willing to spend to get there, as is often the case in numerical modeling. When the ice strength P is very large, the elastic waves are larger and more difficult to damp out. The elastic wave damping vs ice strength issues are more fully explained in this paper:

Hunke, E. C. Viscous-Plastic Sea Ice Dynamics with the EVP Model: Linearization Issues. Journal of Computational Physics, 170, 18–38, 2001.

E0 (eyc in the code) is the ratio (damping timescale)/(full time step). The other namelist parameter used for EVP, ndte (the number of subcycles per timestep) is an integer to ensure that the subcycling steps dte evenly divide the full timestep.

The "revised EVP" method, developed by Sylvain Bouillon et al., provides an alternative subcycling approach. See the CICE documentation cicedoc.pdf for details, and

Bouillon, S., T. Fichefet, V. Legat, and G. Madec. The revised elastic-viscous-plastic method. Ocean Modelling, submitted, 2013.

Q: Boundaries Is there any good reason that you (now?) demand two rows (columns) of land along the boundaries?

A: If your land mask has at least one row of land cells along the 'closed' boundary, then you should set boundary_type to 'open' (in ice_in) and let the land mask close it. The problem here (and the difference with version 3.14) is that the entire infrastructure of the code changed to make it like our ocean model (POP), including how the boundaries are handled, and that introduced some idiosyncrasies due to non-infrastructure-related differences between POP and CICE. With closed boundaries and only one layer of land cells, some of the computed grid lengths along the boundary end up being zero, which causes divide-by-zero errors later in the code (these divzeroes don't appear in POP). The 'open' option was added to get around this; we use the land mask to close the grid boundaries instead of boundary_type.

In a way, this makes sense: the boundary_type specifies the mathematical boundary condition along the edges of the grid (periodic, neumann, etc.), which can be useful for regional grids, while the land mask puts land where it needs to be, thereby applying a physical condition that is relatively independent of the location of the grid edges (i.e., land 'boundaries' are also in the interior of the domain). If you have land cells along the grid edge, it doesn't matter mathematically whether the underlying boundary conditions are 'open' or 'closed'---so use 'open.' Otherwise you'll need to add a row of land cells to your grid and land mask to avoid divzeroes. The 'closed' option is intended only for testing purposes on small grids defined in the code without separate kmt files (grid_type='rectangular', for instance).

Q: Rigid ice I had a question regarding the implementation of your elastic-viscous-plastic (EVP) rheology in CICE, particularly in regions of rigid sea ice as I am trying to model landfast sea ice. In your paper from 2001 (see below for detailed reference) you point out that the version of EVP as suggested there has some difficulties with rigid ice, respectively when P / Delta becomes too large (equations (24) and (25) and text in between). You suggest that one should protect that fraction with some appropriate tuning parameter C (your equ. 25). Looking through the documentation for CICE I don't see this parameter mentioned anywhere, and I wonder if this fraction is indeed protected in CICE.

Hunke, E. C. Viscous-Plastic Sea Ice Dynamics with the EVP Model: Linearization Issues. Journal of Computational Physics, 170, 18–38, 2001.

A: Extra elastic wave damping was available through the namelist variable evp_damping in CICE versions 4.0 and 4.1 (add it to ice_in and set it to true). The parameter 'C' in the paper is set via 'rcon' in the code (rcon=2*C*E0*dt/dte2). In general this option should not be used; in most cases the undamped elastic waves are not detrimental to the solution, as far as we know, while the extra damping can affect the solution elsewhere. Rigid ice is the exception, of course.

The evp_damping option has been removed from CICE v5.0, due to the confusion surrounding it. Another method, developed by Sylvain Bouillon et al., has been added. See the CICE documentation cicedoc.pdf for details.

Bouillon, S., T. Fichefet, V. Legat, and G. Madec. The revised elastic-viscous-plastic method. Ocean Modelling, submitted, 2013.

Rigid ice will be very difficult to simulate using any viscous-plastic-based model, including EVP. The reason is that the basic, plastic model becomes singular (the viscosities become infinite) exactly when the ice becomes rigid, that is, when the strain rates become zero. Hibler chose to regularize that singularity by making the ice highly viscous. In EVP, the essential regularization adds elastic waves instead. In either case, the simulated ice is not allowed to completely stop; in the VP case, the ice creeps viscously, while in the EVP case, it has elastic waves running around. Turning on evp_damping will help reduce those elastic waves, but you will not be able to make the ice completely stop using a VP-type model, except perhaps with massive computing cycles to get the velocity below round-off.

Q: Updating from version 4.1 to 5.0 How do I update to the new version, while keeping my modifications to CICE?

A: Because the code structure and state variables have changed so much, this will be difficult, if not impossible using svn (see the next question for pointers). The most expedient method is probably to move the differences between your working version and the release from which it started into the new release by hand. If you have access to the development trunk, use 'svn update --revision 750'.

Q: Updating from version 4.0 to 4.1 How do I update to the new version, while keeping my modifications to CICE?

A: If you originally downloaded the code using svn (subversion), you are in luck. The release tags are actually branches, and you can merge the new version into your current working directory using svn. Before starting, make a copy of your working directory as a backup, in case things go awry. Then issue the 'svn stat' command to see which files you have altered in your working directory. To merge, you will need to issue the following command from the top of your working directory, without '--dry-run'. Here are the files that will have conflicts needing to be resolved (C), along with all of the other files that changed from 4.0 to 4.1. Compare this list with the results from 'svn stat'. If you have not altered a conflicting file yourself, then you can simply accept the new 4.1 file. Otherwise you will need to compare the file changes and decide what to keep. Consult the subversion documentation for further information http://subversion.apache.org/.

[eclare release-4.0]$ svn merge -r145:277 --dry-run http://oceans11.lanl.gov/svn/CICE/tags/release-4.1

D    README_v4.0
U    serial/ice_boundary.F90
U    serial/ice_gather_scatter.F90
U    serial/ice_global_reductions.F90
U    source/ice_init.F90
U    source/ice_dyn_evp.F90
C    source/ice_transport_driver.F90
U    source/ice_domain.F90
U    source/ice_calendar.F90
U    source/ice_restoring.F90
U    source/ice_blocks.F90
U    source/ice_itd.F90
U    source/ice_transport_remap.F90
C    source/ice_shortwave.F90
U    source/ice_meltpond.F90
A    source/ice_lvl.F90
U    source/ice_fileunits.F90
U    source/ice_mechred.F90
U    source/ice_diagnostics.F90
U    source/ice_therm_vertical.F90
C    source/ice_step_mod.F90
C    source/ice_flux.F90
U    source/ice_therm_itd.F90
U    source/ice_state.F90
U    source/ice_restart.F90
U    source/ice_read_write.F90
U    source/ice_grid.F90
U    source/ice_forcing.F90
U    source/ice_domain_size.F90
C    source/ice_history.F90
A    bld/Macros.Linux.ORNL.jaguar
C    ice.log.Linux.LANL.coyote
A    README_v4.1
C    doc/cicedoc.pdf
U    mpi/ice_boundary.F90
U    mpi/ice_gather_scatter.F90
U    mpi/ice_global_reductions.F90
C    input_templates/gx1/ice_in
C    input_templates/gx3/ice_in
A    input_templates/run_ice.Linux.ORNL.jaguar
A    input_templates/col
A    input_templates/col/ice_in
C    comp_ice
U    drivers/cice4/CICE_InitMod.F90
C    drivers/cice4/CICE_RunMod.F90
U    drivers/cice4/ice_constants.F90
C    drivers/cice4/CICE_RunMod.F90_debug
U    drivers/esmf/CICE_InitMod.F90
C    drivers/esmf/CICE_RunMod.F90
U    drivers/esmf/ice_constants.F90

Last modified 4 years ago Last modified on 10/11/13 14:57:25