nudging [U V Q T] in CESM2.1.3

[hhzhang]

Hi there,

I am doing a nudging experiment, in which I want to nudge a sensitivity run to a control run (both runs are done with CESM2.1.3). I am running into all kinds of errors when trying to generate the required target data. Below are my questions arising from some of the errors:

1. are the 'US' and 'VS' in the field list below required? I didn't save US and VS in my control run, since [U V T Q PS] are the target fields according to the user guide (9. Physics modifications via the namelist — camdoc documentation).
------------------------
fields : ( U US V VS T PS Q ) <-- FIELDS TO PROCESS (both U,V grids are needed)
field_findex : ( 1 1 1 1 1 1 1 ) <-- FILE CONTAINING THE FILED
phis_findex : 1 <-- FILE CONTAINING 'PHIS'
-----------------------

My scripts (attached), where I removed US and PS, crashed with '(0) Error: Looking for 'US' but did not find in 'field' list'.

What history fields do my control run have to save for the target data? so far I only saved U, V, T, Q, PS, PHIS.

2. in my nudging experiment, I thought setting ADJUST_STATE_FROM_TOPO=False should be fine, since both control and sensitivity runs share the same topography. but I got an error '(0) Error: Looking for 'PHIS_input' but did not find in 'field' list'. This error appears to be fixed when I set it to True, but I am not sure if this is the right fix. can you explain why?
-----------------------------
ADJUST_STATE_FROM_TOPO : 'True' <-- YOUR CHOICE??
-----------------------------

3. I am confused about how to use RUNNUM to speed up the processing. Say, I have 10 years of 6hourly data from my control experiment to process. How should I make use of RUNNUM (probably along with REF_DATE and NUM_DAYS)?
-----------------------------
RUNNUM : Index so that processing can run with concurrent scripts running
REF_DATE : 'YYYYMMDD' Year month and day to begin processing
NUM_DAYS : Number of days to process
(2) Processing the data is SLOW, SLOW, SLOW. To get done
in a timely mannor, multiple copies of the script need to be run concurrently.
RUNNUM is an index so that concurrent runs don't interfere with eachother.
-----------------------------

Thanks a lot.
Honghai

 

[patc]

Hi Honghai,

The nudging module will look to read U,V,T,Q, and PS. The usage of PS is not implemented at this time but the
model will still look for it and read it in. For the FV dycore, there was a problem when we wanted to use the
contents of the nudging data file to initialize the model state, since FV has a staggered grid. So the fields
US and VS are included in the nudging files for that purpose. If you don't need to start from such an initial
state (via ncdata), then you should be able to do without the US/VS.

Even if it is not used for adjustments, the topography PHIS values are read from the given input file,
interpolated to the output resolution, and stored on the output. For you this is a (NULL) copy operation,
but the scripts don't know that. So with topo adjustment, the input PHIS is read in, interpolated to the new resolution,
and then the differences between this interpolated PHIS and the native (model) PHIS are used to adjust values
to the model PHIS. Without topo adjustment, the interpolation of the input PHIS to the output resolution is
still carried out.

RUNNUM was added so that multiple copies of the script can be run at the same time to process
data (e.g. 10 scripts processing 1 year of data each to generate a 10 year record). Changing the RUNNUM
in a set of scripts, each with a different starting date and number of days to process, will allow them
to run in the same source directory simultaneously. One important note is that when doing so, the
fortran library has to be built (run the WRAPIT command) and then the lines where each of these
scripts calls WRAPIT need to be commented out. If this is not done, then each scripts that rebuilds
this library will interfere with the other scripts that may be in the process of using it.

If you use the RUNNUM feature, you need to check and verify that there are no gaps in the
data record. If the nudging code comes across a gap in the data, it will switch itself off and coast
thru it until it finds nudging data on the other side. This behavior was useful for data with gaps (e.g. YOTC), but
can lead to confusion if users don't verify the continuity of their nudging data.

--> Patrick

 

[QINKONG]

Hi Honghai,

The nudging module will look to read U,V,T,Q, and PS. The usage of PS is not implemented at this time but the
model will still look for it and read it in. For the FV dycore, there was a problem when we wanted to use the
contents of the nudging data file to initialize the model state, since FV has a staggered grid. So the fields
US and VS are included in the nudging files for that purpose. If you don't need to start from such an initial
state (via ncdata), then you should be able to do without the US/VS.

Even if it is not used for adjustments, the topography PHIS values are read from the given input file,
interpolated to the output resolution, and stored on the output. For you this is a (NULL) copy operation,
but the scripts don't know that. So with topo adjustment, the input PHIS is read in, interpolated to the new resolution,
and then the differences between this interpolated PHIS and the native (model) PHIS are used to adjust values
to the model PHIS. Without topo adjustment, the interpolation of the input PHIS to the output resolution is
still carried out.

RUNNUM was added so that multiple copies of the script can be run at the same time to process
data (e.g. 10 scripts processing 1 year of data each to generate a 10 year record). Changing the RUNNUM
in a set of scripts, each with a different starting date and number of days to process, will allow them
to run in the same source directory simultaneously. One important note is that when doing so, the
fortran library has to be built (run the WRAPIT command) and then the lines where each of these
scripts calls WRAPIT need to be commented out. If this is not done, then each scripts that rebuilds
this library will interfere with the other scripts that may be in the process of using it.

If you use the RUNNUM feature, you need to check and verify that there are no gaps in the
data record. If the nudging code comes across a gap in the data, it will switch itself off and coast
thru it until it finds nudging data on the other side. This behavior was useful for data with gaps (e.g. YOTC), but
can lead to confusion if users don't verify the continuity of their nudging data.

--> Patrick

Hi Patrick,
This is Qin. Thanks for your answer above which is very helpful. I'm also trying the nudging functionality, but encountered more basic problem. I was just testing the default script in the github repository (IPT/Meterological_Reanalysis_Data/Finite_volume_dycore/Gen_Data_f09 at master · NCAR/IPT). However, when I csh the code, it gives me the following error message:


It seems that the WRAPIT command is not available. I was on cheyenne.

Thank you!
Best,
-Qin

 

[islas]

have you loaded ncl? i.e., module load ncl

 

[QINKONG]

have you loaded ncl? i.e., module load ncl

Hi Isla,
Yeah, I didn't load ncl, and script runs fine after ncl was loaded. Thank you so much!
Best,
-Qin

 

[Jerry]

Hi Isla,
Yeah, I didn't load ncl, and script runs fine after ncl was loaded. Thank you so much!
Best,
-Qin

Hello Qin,
I want to know the version of NCL you are using, because I got some error when testing the nudging tools.
I'm trying to figure out whether it is due to the NCL version.

 

[Zhu Zhu]

Hello Qin,
I want to know the version of NCL you are using, because I got some error when testing the nudging tools.
I'm trying to figure out whether it is due to the NCL version.

Hello Jerry,
I run nudging tools with NCL version of 6.6.2, but got errors when running "WRAPIT MAKEIC.stub MAKEIC.f90":

WRAPIT Version: 120209
*** buffer overflow detected ***: /share/home/dq158/miniconda3/envs/ncl_stable/bin/wrapit77 terminated
Abort (core dumped)
FATAL ERROR: wrapit77 failed

I have no idea to solve it, I want to know whether you got the same error?

Best,
Zhu