Ice Sheet Evolution Experiments
Now that we've (1) convinced ourselves that the higher-order model is "working" (at least as well as other higher-order models out there) and (2) added some code so that we can evolve the ice sheet geometry, we can do some simple experiments looking at the combination of the two. By "simple", I mean coarse resolution, idealized domains with idealized boundary conditions. These may actually be somewhat "non-sensicle" with respect to real ice sheets (and in that sense, the title of this page is somewhat misleading), but they are still useful exercises for testing and comparing algorithms and pointing out some other important issues.
The two experiments we will attempt are:
- Allow a parabolic-shaped mound of ice to spread out under it's own weight. The non-sensicle part is that we will assume (i) zero surface mass balance (no accumulation or ablation) and (ii) a fixed lateral boundary. That is, the ice sheet margin won't be allowed to move past it's original position (think of an ice sheet surrounded by a very tall (and very strong) fence - the ice sheet will eventually take on the shape of a disk with uniform thickness).
- Evolve a confined ice shelf of uniform thickness and temperature. The non-sensicle part here is that again, we assume no accumulation or ablation. Thus, the only thing that can happen is that ice flows out of the shelf front. Eventually, the shelf should thin to zero thickness (but how and when that happens will vary depending on a number of things).
Experiment 1: evolve the blob
Change your current directory to tests/ho-other/ (i.e. higher-order other). There will be a model configuration file there called blob.config and a related python script blob.py (both courtesy of Tim Bocek). As in previous experiments, we first need to build the netCDF input files
python blob.py blob.config
Then, we can run the model with the input files with
echo blog.config | ./simple_glide
if simple_glide is in your directory (if simple_glide is in your path then the "./" out front is not needed). With the default values in blob.config, the code will evolve a simple parabolic shaped ice sheet for 5000 yrs at a time step of 50 yrs using the first-order upwinding scheme we just built. This option is set in the configuration file
[options] flow_law = 2 evolution = 4 temperature = 1 ... etc ...
As the code works, you'll see ~100 packets of iterations fly by on the screen, but at the low resolution here this should not take too long. The netCDF file blob.out.nc will record the output and you can use NCVIEW and the "movie" controls at the top to view the time series of any variable while the model is running or at the end of the run. Once you've the run has finished, rename your output file
mv blob.out.nc blob.out.fo.nc
where the "fo" stands for "first-order advection scheme". Now edit the [options] section of blob.config and change evolution = 4 to evolution =3 . This will tell the code to use a more sophisticated advection scheme - incremental remapping - to evolve the thickness. Repeat the steps above executing the python scripts and simple_glide. When you've got another netCDF output file at the end of the run rename it
mv blob.out.nc blob.out.remap.nc
Because NCVIEW is not necessarily ideal for comparing the output from two similar files w/ slightly different input parameters, we'll use a simple matlab script to compare the output at the same time slices but using the two different evolution schemes. Make sure to change your matlab directory to your tests/blob/ directory before running the script (or copy the relevant netCDF files into your matlab directory).
- How does the output for the two evolution schemes compare? Are the elevation profiles produced from the different schemes at the same time slices significantly different? The answer actually surprised me ...
- NOTE: IT WOULD BE GREAT TO THE VISCOSITY FIELD HERE TO LOOK AT ... AS WE COULD SHOW WHY/HOW ONE GETS RAYMOND BUMPS AT A DIVIDE. COULD ALSO RUN THIS AT HIGHER HORIZ RES SO THAT WOULD SHOW UP?
Experiment 2: evolve the shelf
Change your current directory to tests/shelf/. There will be a model configuration file there called confined-shelf-ss.config and a related python script confined-shelf-ss.py (again, both courtesy of Tim Bocek). The default setup for this configuration file will give you a diagnostic (i.e. instantaneous) solution for a setup that is very close to that for the unpublished ESIMINT ice shelf experiments 3 and 4 , which you explored a bit earlier in one of the COMSOL exercises. To get that solution build the necessary netCDF input files,
python confined-shelf-ss.py confined-shelf-ss.config
and then run the model
echo confined-shelf-ss.config | ./simple_glide
(again, if simple_glide is in your current directory, use the above or, if it is in your path already, omit the "./"). Examine the converged solution using NCVIEW. It should look very similar to the first set of figures shown here. Note that, for now, this is a very coarse resolution solution both in the vertical and horizontal.
Now we'll march this initial condition forward in time by 250 yrs using our 1st-order advection scheme. Edit confined-shelf-ss.config so that the items in bold below match those in your file
[time] niso = 1. tend = 200250. ntem = 1. tstart = 200000. dt = 10. nvel = 1.
[options] flow_law = 2 evolution = 4 temperature = 1 ... diagnostic_run = 0 basal_water = 0 isostasy = 0
Rebuild the input netCDF files and run the model as before. You can watch the shelf evolution "in real time" (as the fields get saved to the netCDF file) by plotting the thickness field with NCVIEW and using the movie controls at the top.
Shelf: what happens if you change the rate factor by an order of mag in the python script? Decrease it ... increase it (w/o altering time step, should lead to crash due to CFL violation - use this as an excuse to alter subroutine and add CFL warning) Change thickness by factor of 2? Look at rate of decay of thickness and estimate how long until shelf-front thins to zero Discuss problem w/ domain edges - thickness stays at 500m forever, which is non-physical and due to BCs (only "inside" of domain acts in a way we'd expect)