I have set up some resources for you to start messing with a version of the CCSM4 with prescribed observed SST and sea ice fraction and modern greenhouse gas levesl. I have already done a "control" run with all things standard. You can use it to compare against. It is in directory /home/disk/p/atms380/bitz/camruns/mvmts/run (sorry for the dumb name).
You can build and run this model setup with the script /home/disk/p/atms380/bld-messwithX.csh
Create a subdirectory within your camruns directory and give it a good descriptive name, like "minusf" (for a run with minus the Coriolis parameter to make the Earth rotate backwards). This is your "work" directory. Copy the build script there. Edit the build script to match your subdirectory name. Create a subdirectory to the work directory called "SourceMods".
Take a look at the file paths that make up this version of the model
"ls /home/disk/p/atms380/bitz/camruns/mvmts/bld/Filepath" . You are free to root around and mess with any of the code there, but it is hard to know what will happen. An easy route is to just mess with the file that has the highest level constants that I have mentioned before. Do this by copying this file /home/disk/p/atm559_2010Q2/bitz/cesm1_0_2/models/csm_share/shr/shr_const_mod.F90
into your SourceMods directory and have at it. You can make the earth rotate backwards by adding a minus sign to SHR_CONST_OMEGA. You will have to build the model after you make a source modification.
I am worried about the model going unstable if you make a large perturbation. For sure this would happen if you increased SHR_CONST_OMEGA by a large factor (which might be worth trying anyway for a factor of ~2). You will know it has gone unstable if the job is no longer in the queue when you do a "qstat". Look at the end of the run/cam.out file and you will see warnings or NaNs (not a number). You can hopefully get past this by reducing the time step, which is set in the bld-messwithX.csh script: search dtime and reduce it from 1800 to 1200, 900, or 600. Run the bld-messwithX.csh script again and it will put this new time step into the namelists. Then run it again from the beginning. If this starts to be a nuisance, let me know and we can find a code modification that won't be so difficult. I did a run with the planet rotating backwards last night and it ran without reducing the time step, so this is a good fall back choice.
I have learned a few things about CAM and our system in helping with your project! The queue has a 24 hour limit, so every job has died before finishing.
Unfortunately I have my runs in the wrong directory names!
/home/disk/p/atms380/bitz/camruns/doublef is the minusf run
/home/disk/p/atms380/bitz/camruns/minusf is the doublf run
And needlessly the minusf run has the timestep reduced, so it stopped at year 1 month 11! I have just continued it this morning (Mar 4). Sorry about that.
The doublef run died after at year 4 month 6 and your half_f run died after year 4 month 9. These are long enough.
The automatic diagnostics work very well for your runs, so I don't think you will need to make any other figures besides those make using the diags.csh script. See Hints and how to's
You and I used the same run name for all your tests, which may be a little hassle. Let me know if you want some help.
I may add some more suggestions here later.
|Return to Homepage