Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

restart problem with COMPSET C

njn01

Member
I am unaware of any compset C restart problems with the ccsm3, so it would be very helpful if you would provide details: Are you using the release code (ccsm3.0 download)? Are you running on a supported platform (see elsewhere in this forum for a definition)? Have you modified the code in any way, or are you using the C compset "out of the box"? Are you getting an error message? If so, what is it? And so on...
 
I'm running CCSM3 code that I downloaded from http://www.ccsm.ucar.edu/models/ccsm3.0/#src on NCAR bluesky. I haven't modified the code, ie, I'm using the Compset C "out of the box" as you said.
Here is what I'm doing:
1) I created two cases "test_pop10" and "test_pop7"

./create_newcase -case /home/bluesky/yafang/CCSM3/test_pop10 -mach bluesky -compset C

./create_newcase -case /home/bluesky/yafang/CCSM3/test_pop7 -mach bluesky -compset C

2) For both cases, I'm using "grid T31_gx3v5" and "run_type branch". The restart .tar file is "test_pop.ccsm.r.0802-04-01-00000.061109-164823.tar" which was yielded by another Compset C run "out of box". Now to test the restart problem, I ran case test_pop10 for continuous 2 months but restarted case test_pop7 at the end of first month. Both cases integrated without any error message and produced history files.

3) I use FERRET to check if the outputs from the two cases are identical. They are identical for the first month but show noise-like difference for the second month. That's why I wonder if Compset C has been tested concerning restart problem.

Thanks.
 

njn01

Member
I think I will have time either very late this afternoon or sometime tomorrow to review your output files and see if I can figure out what's happening with your two cases.

I can see the output files in your /ptmp directory, but the permissions on your case directory don't allow me to look at them.
 

njn01

Member
Thank you for setting the read permissions on your case directories. I've reviewed your setups and your output directories, and so far, I haven't been able to identify any problem with your setup.

I directly copied your source code and scripts to my directory and set up two tests, similar to yours, but for only 10 days. The two cases (10-day, 5-day + 5-day) produced identical results.

So I've next set up two cases that should replicate your 2-month exact restart tests, except that I am using startup initialization. The cases are in the job queue now, so I don't expect to see the results until tomorrow. I will report here on the results of that test.
 

njn01

Member
I confirmed that the two-month C compset runs do not exactly restart. Because the ocean and coupler models exactly restart in other contexts, I think the most likely cause of the inexact restart is in one of the data models.

I will check with the developer of the data models when he returns next week and will follow up with more information at that time.
 

njn01

Member
I have filed an internal bug report for the CCSM3.0 "C" compset exact restart problem. Unfortunately, because of very imited resources, I am unsure as to when, or even if, this problem will be corrected in the released version of the code.

Something I should have pointed out to you right at the outset of this post is that the "C" compset, as configured "out of the box" in CCSM3.0, is not suitable for scientific experimentation. The CCSM documentation alludes to this, in the Introduction of the CCSM3.0 User's Guide, section 1.5, albeit somewhat indirectly:

"Although CCSM3.0 can be run ``out of the box'' for a variety or resolutions and component sets, it must be stressed that not all combinations of component sets, resolution and machines have been tested or have undergone full climate validations. "

The documentation goes on to list three variations of the "B" compset that have been scientifically validated; what is left unsaid is that the "C" compset is, as configured, useful mainly for testing purposes.
 
Thank you for your reply. I don't quite understand why the "C" compset is not suitable for scientific experiment since it is equivalent to an ocean-alone model in my understanding. What I want to do with the "C" compset is to apply a certain wind stress pattern and examine how the ocean responds. Of course I could simply use POP, but as I know, the POP with the same resolution as CCSM3 T31_gx3v5 has a grid that is displaced relative to CCSM3 T31_gx3v5. The reason why I care about this difference is that I want the result from the ocean-alone model to be directly comparable to that from full coupled "B" compset. Another related question is that why the "C" compset explicitly prohibits the applying of external wind stress forcing. Is it due to scientific or technical consideration? Seems the "C" compset could integrate without error message when this prohibition is removed.
Thanks for your attention.
 

njn01

Member
Yafang,

I posed your questions to the NCAR ocean scientific staff, and here's their reply:

The compset 'C' configuration in the CCSM3.0 release is "use at your own risk".

Although it does run out of the box, no scientific study or technical report has ever been published using this particular set up.

Running ocean-alone experiments necessarily requires choosing a set of atmosphere, ice, and land forcing datasets and methodologies. This choice is complex and will have a significant impact on the resulting simulations.

The NCAR ocean section does not endorse the ocean forcing scheme which results from configuring compset C out-of-the-box. Users of compset C must be prepared to address the issues of ocean forcing on their own without support.
 
Top