Time varying open boundary conditions for CICE #21
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…, shear, strength and call cleanup_itd and bound_state after restore
nilsmkMET
approved these changes
Nov 11, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
Pedro Duarte's (NPI) implementation
This pull request consists of a set of commits to integrate the code written by Pedro Duarte (Norwegian Polar Institute) for time varying open boundary conditions in CICE. While CICE has the
ice_restoring.F90file with theice_HaloRestoresubroutine, this only provide the "hooks" for an open boundary condition treatment, e.g. there were no support for reading data in from an external file and applying these to the boundaries. During his work at NPI on the project "Ecosystem modelling of the Arctic Ocean around Svalbard financed by the Fram Centre flagship Arctic Ocean between 2014 and 2018", Pedro Duarte made use of the above mentioned "hooks" and wrote an implementation for time-varying open boundary conditions. His method revolves around imposing values from e.g an external model by restoring values along the outermost edge of points in the domain to data read in from an input file. A rough outline of the main steps performed by his code are as follows (see commits for details):CICE_InitMod.F90,ice_init.F90,ice_domain.F90and boundary array initializations in subroutineinit_forcing_bryinice_forcing.F90ice_read_nc_bry_2D,ice_read_nc_bry_3D,ice_read_nc_bry_4Dinice_read_write.F90interp_coeffinice_forcing.F90interpolate_data_nandinterpolate_data_n_layerinice_forcing.F90ice_HaleRestoreinice_restoring.F90Supplementary changes by MET Norway
In addition to Pedro's code above, other smaller changes have been done by Nicholas Szapiro (MET Norway) and Jostein Brændshøi (MET Norway) for minor adjustments to the boundary treatment. They include (see commits for details):
ice_HaloRestoreuvel,vvel,divu,shear,strengthto neighbor point inice_HaloRestoreice_grid.F90ice_boundary.F90CICE_RunMod.F90(this effectively halves the restoring time scaletrestorein ice_in as a side effect)Instructions on how to use the code
Stuff that needs to be done both when using and not using OBC:
Add the flags
sea_ice_time_bry = .true./.false.sea_ice_bry_dir = '/path/to/directory/with/boundary_file/'(final '/' important)to the
&domain_nmland&forcing_nmlnamelist sections, respectively, in your ice_in file. The pathsea_ice_bry_dirmay be an empty string whensea_ice_time_bry = .false.The input boundary file
The boundary file needs to contain values for all variables that are required at the boundary by the current boundary implementation. That means
aicen,vicen,vsnon,Tsfc,alvln,vlvln_bry,apondn,hpondn,ipondn,iage,Tinz,Sinzall should be present on the file. There is one variable per boundary (see the below example for details on the naming convention). Additionally, the file must contain the dimensionsnkice,days,ice_types,eta_t,xi_t(where each of the variables depend on the dimensions as shown below).Create the CICE boundary file for your simulation, e.g. by using
metroms/tools/cice_bry.pyor some other tool. Name the fileBRY_<YEAR>.nc, so if your run is in 2019, the file isBRY_2019.nc. The way it works now, your boundary file needs to contain entries for all 365 days of the year (dimensiondaysshould have length of a full year) even if you only run for a few days of the year. In practice this means you need to fill (e.g. zeros) the file with 365 or 366 (regular or leap) time entries and fill in with your actual boundary data on the time indices that matches the days you have data for and/or want to run for. The code then fetches the correct indices based on the day of the year in model run. The toolmetroms/tools/cice_bry.pyhandles this. If your run extends over one or more year transitions, e.g. you run from 2018 into 2019, you need to split up the boundary data into two files, i.e.BRY_2018.ncandBRY_2019.ncwith the first file containing data for the days in 2018 and the second for the days in 2019. The toolmetroms/tools/cice_bry.pywill handle this very soon.Below follows an example of a boundary file and the variables it should include as made by
metroms/tools/cice_bry.py. As of now, the variableshbrineandfbrineare not used in the code so they may be filled with arbitrary values.