Outputting/calling Nino indices from POP using tavg.F90

[jacob_stu_allen]

Hello!

In the tavg.F90 module for POP, there is a subroutine for outputting Nino indices within the source code. I need to call one of these Nino indices (NINO_3_POINT_4) in the fourcing_coupled.F90 module in order to override wind stress values in the tropical pacific (scaled by the NINO_3_POINT_4 value).

In some preliminary testing in which I set "ltavg_nino_diags = .true." in tavg.F90 in order to compute the Nino diagnostics, I get no errors and the Nino indices appear to be computed when I look at the ocn.log from the run. Here is an example of the output for one day in my one month test (this can also be seen in the ocn.log attached).

...
Local Time- and Space-Averages for Nino Regions: 00:00:00 2001-01-02
NINO_1_PLUS_2: 1992804.55087367
NINO_3: 2079324.26863628
NINO_3_POINT_4: 2171788.19381903
NINO_4: 2323748.57965494
(io_pio_init) create file
./b.e21.B1850.f09_g17.hybrid-enso.TEST.e008.pop.h.nday1.2001-01-01.nc
...

A few questions arise:
1. Is there any indication why the Nino indices are soooo large? The values seem completely unrealistic/erroneous.
2. These values aren't subsequently saved to any pop output files - any idea why?
3. I will need to call the NINO_3_POINT_4 index value in the forcing_coupled.F90 script. Is anyone aware of how to do this / is there any recommended example with another globally distributed variable that I could use?

I am running CESM2.1.0:
Compset: 1850_CAM60_CLM50%BGC-CROP_CICE_POP2_MOSART_CISM2%NOEVOLVE_WW3_BGC%BDRD
Grid: f09_g17
Run type: "startup" for now.

Source modifications:
src.pop: forcing_coupled.F90, ocn_import_export.F90, forcing_fields.F90, tavg.F90

Thanks for any help or suggestions!
Jacob

 

[klindsay]

Jacob,

The values computed by tavg_local_spatial_avg are only written to the ocn.log file. They are not written to any netCDF file. That's why you only seen them in the ocn.log file.

Are you adding calls to tavg_local_spatial_avg? This subroutine is called in subroutine write_tavg after running sums of variables being time-averaged have been normalized. That is, the running sums are incremented each time step with dt*FIELD, and subroutine tavg_norm_field_all divides these running sums by the sum of dt. If you're adding calls to tavg_local_spatial_avg elsewhere in the code, then the written output is possibly based on non-normalized sums of the SST (TEMP at k=0). The problem is that tavg_local_spatial_avg is only designed to do spatial averaging on time-averaged SST, from the normalized tavg buffer.

It sounds like you want spatial averages at every time-step.

I suggest writing a subroutine like tavg_local_spatial_avg, perhaps named local_spatial_avg that has a FIELD argument that you will compute spatial averages of, and an output argument for the computed spatial averages. Write local_spatial_avg to compute averages of FIELD like tavg_local_spatial_avg does for TAVG_BUF_3D(:,:,1,iblock,tavg_loc_TEMP). If you then pass FIELD=TRACER(:,:,1,1,curtime,:), i.e., current SST, you would get the averages of current SST in the Nino regions.

Hope this helps,
Keith

 

[jacob_stu_allen]

Hello Kieth,

This is very very helpful -thank you for your reply and for the pointed example!

Cheers,
Jacob

 

[jacob_stu_allen]

Hello again Keith,

One follow up is that I am not adding any calls to tavg_local_spatial_avg at the moment. Additionally, I want spatial averages for each day - rather than each time step. Could I more simply call tavg_norm_field_all within the tavg_local_spatial_avg to output the time/spatial mean for the Nino indices?

Thanks again and apologies if I'm misunderstanding,
Jacob

 

[jacob_stu_allen]

OHH I see that the default dt is 1 day... Oops.

 

[klindsay]

I think your mod to set ltavg_nino_diags=.true. is causing tavg_local_spatial_avg to be fully executed whenever a stream is written. That is, there's a check on ltavg_nino_diags at the top of tavg_local_spatial_avg that is no longer doing what it was intended to do.

Note that if you added calls to normalize the sums in tavg_local_spatial_avg, and denormalized them before returning, with the code based on TEMP, which is averaged monthly, you would get peculiar averages. In the 2nd day that POP runs, you would have the average over the 1st day. In the 3rd day that POP runs, you would have the average over the first 2 days. In the 4th day, you would have the average over the first 3 days. This would continue until the monthly running sums are reset to zero at the end of them month, and the process would start over. I doubt that this is what you want.

So I think you should revert the ltavg_nino_diags=.true. change.

After that, one possibility is to move TEMP from the monthly stream to the daily stream. This would greatly increase your output volume, and might break your analysis scripts, if they assume TEMP is averaged with monthly frequency.

Another possibility is to change the Nino diagnostics to be based on SST instead of TEMP, noting that SST is averaged with daily frequency.

1) change occurrences of 'TEMP' in tavg.F90 to 'SST'
2) change spatial averaging in tavg_local_spatial_avg to operate on TAVG_BUF_2D, instead of TAVG_BUF_3D, and drop the hard-coded 1 index in the 3rd dimension

Either way, moving TEMP to daily stream, or change Nino diagnostics to be based on SST, you could then add code in tavg_local_spatial_avg to store the computed means to a module variable that would be accessible to other parts of POP. Note that this variable would be updated at the end of the day, so the values in it would be from the SST averages from the previous day.

There are a couple of remaining issues:
1) On a startup run, this variable would be uninitialized during POP's first day of execution. So you would need to set it somehow.
2) You would have the same issue on a continuation run, after a model restart. To avoid this, I think the values in this variable would need to be added to the restart file.

A totally different approach is to introduce a new subroutine local_spatial_avg that is called every timestep, like I previously suggested. However, you could utilize the running mean feature in POP in running_mean_mod.F90 to get something like daily means. This module provides support for taking running means of variables of different shapes, and takes care of adding needed fields to the restart file. Note though that the running means are weighted with a weight with exponential decay (with a user specified timescale). They aren't the same as a moving daily window. So I don't know if this approach meets your needs.

 

[jacob_stu_allen]

Thanks again, Keith - this has been invaluable.

I've attempted introducing the new subroutine to perform spatial averages of the TRACER/SST data. This appears to be working with a startup run, and I can use the Nino3.4 daily variable in my added forcing_coupled.f90 subroutine with some simple modifications. I'll have to do some checking to make sure that what I'm getting is what I'm expecting - but again, I can't thank you enough!