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

CESM validation (Port Validation for CAM with the cam4 physics package)

I followed the instruction of website: http://www.cesm.ucar.edu/models/cesm1.0/cam/docs/port/
My CESM version is 1.1.1, and the correspondent CAM version is 5.2.
So there is NO correspondent CAM perturbation results of this version. only for CAM-5.0 CAM5.1 CAM5.3

What I did is:
1. $camcfg/build-namelist -test -runtype startup -namelist "&camexp stop_option='ndays' stop_n=2 nhtfrq=1 ndens=1 mfilt=97 hfilename_spec='h%t.nc' empty_htapes=.true. fincl1='T:I','PS:I' /" (result: control.nc)
2. $camcfg/build-namelist -test -runtype startup -namelist "&camexp stop_option='ndays' stop_n=2 nhtfrq=1 ndens=1 mfilt=97 hfilename_spec='h%t.nc' empty_htapes=.true. fincl1='T:I','PS:I' pertlim=1.e-14 /" (result: perb.nc)

make the control run and the perturbation run, then

cprncdf control.nc perb.nc > RMST_f19_cmp_cloud_5.2

and

cprncplt -t -pltitle "cam5.2, FV-1.9x2.5, port validation" -l "perturbation: cam5.1(ibm)","difference: cam5.2(cloud)" RMST_f19c4aqpgro_cam51_ys_intel RMST_f19_cmp_cloud_5.2
(I use the "CAM-5.1 (CESM-1.0.6), Finite-Volume dycore, 1.9x2.5-L26, IBM iDataPlex." to do the validation ), and the result is attached (figure_1).

Is the result OK ?

But in the instruction, we need to calculate the differences of personal control run and provided control run (cprncdf f1.9ph_ibm_5.0.nc h0.nc > RMST_f1.9_cmp_ibm_5.0). And if I do this and using "CAM-5.1 (CESM-1.0.6), Finite-Volume dycore, 1.9x2.5-L26, IBM iDataPlex" dataset , the result is in figure_2, which does NOT like the figure in the webpage. Does that mean my porting is wrong?

 

eaton

CSEG and Liaisons
The perturbation growth curve labeled "cloud" in figure 1 looks good.  It's interesting that the RMS-T values are substantially lower for "cloud" than they are for the test I did on an ibm idataplex platform (sandy bridge processors) with an intel compiler.  What type of computer is cloud, and what compiler did you use?It's not possible to compare controls done with different cam versions.  I have updated the port page with a control and perturbation results for cam-5.2. 
 
I use the dataset you provide for cam 5.2 and do the validation, and the result is attached.(figure_3)The magnititude of differences of the control runs of cloud and ibm is really smaller than the perturbation of ibm run, even in the log y-axis, and I don't know why.
 

eaton

CSEG and Liaisons
I think your result looks OK although I can't explain why the RMS-T values are so much smaller than what I see on the ibm.  I wonder if there's a difference in the cprnc utility which is calculating the RMS values.  At any rate the differences between the ibm and cloud runs are similar to the perturbation growth on cloud (from your figure 1), so that's sufficient for a passed test. 
 
Actually, the cprnc utility I use is "cesm1_2_2/tools/cprnc", because I couldn't find it in CESM1.1.1 version.And there is an error when I try to build cprnc executable. In the Makefile of cprnc, there is a clause for ifort:  ifeq ($(FC),ifort)    LDFLAGS += -Wl,rpath,$(LIB_NETCDF)  endifin which, rpath should be changed to -rpath for ifort.
 

eaton

CSEG and Liaisons
Thanks for the Makefile fix.  I added it to our code repo.In looking at the latest version of cprnc I see that a new entry has been added to the line that contains the RMS T values.  The normalized value is now added to the line after the absolute value.  The normalization factor is the average absolute field value, which for the T field is about 230.  This explains the smaller values that you are seeing. 
 
Thanks for your help and answer!And another thing happened when I use the cprncplt utility is that, the RMST file generated by cprncdf has some txt in the head of file, which will cause the cprncplt fail when excuted. The RMST file generated by cprncdf need to remove these txt or comment these txt manually. I think this is worth noting.
 

eaton

CSEG and Liaisons
Over the years the output format for cprnc has been changing which requires changes in the cprncdf script which extracts the RMS values.  I will provide an updated version of this script when I get a chance.  I'm also planning to provide a new version of cprncplt which uses gnuplot for the graphics rather than yorick which isn't as commonly available. 
 
Top