[Go-essp-tech] Incorrect use of missing value in some MRI ocean data -- correction

Mon Dec 5 11:58:54 MST 2011

Hi Martin,

Right again.

thanks,
Karl

On 12/5/11 10:39 AM, martin.juckes at stfc.ac.uk wrote:
> Hello Karl,
>
> Seiji (from MRI) suggested people use sea-area fraction"sftof": I think "areacello" (standard name "cell_area") refers to the actual grid cell, which may be be partially or completely land. "volcello" (standard name "ocean_volume") doesn't have a definition in the current standard name table -- but from the name I would expect to refer to the volume of ocean, so that should be OK for the height dependent fields,
>
> cheers,
> Martin
>
> ________________________________
> From: Karl Taylor [taylor13 at llnl.gov]
> Sent: 05 December 2011 18:21
> To: Juckes, Martin (STFC,RAL,RALSP)
> Cc: go-essp-tech at ucar.edu; Parton, Graham (STFC,RAL,RALSP); cmip5-users at jiscmail.ac.uk
> Subject: Re: [Go-essp-tech] Incorrect use of missing value in some MRI ocean data -- correction
>
> Hi Martin,
>
> You're quite right.  It states:
>
> "2. Unless otherwise specified, the ocean and sea-ice output (including Oclim, Oyr, Omon, and OImon) represents a mean over only the sea portion of each grid cell (i.e., it is interpreted as "where ocean over ocean"), and a value of 0.0 should be reported where the sea fraction is 0."
>
> I'm can't recall whether this specification was the result of some requirement, or if it was simply a mistake.  Thinking about it now, I think the recommendation should have been to set it to the "missing" value, not 0.0, since over land the values are undefined.
>
> Given that some groups will follow the specified rule, and others will put in the missing value for land points, users would be advised to obtain the areacello variable (or volcello) which should be set to 0.0 where there is no ocean.
>
> Any other ideas?
>
> Best regards,
> Karl
>
> On 12/5/11 9:45 AM, martin.juckes at stfc.ac.uk<mailto:martin.juckes at stfc.ac.uk>  wrote:
>
> Hello Karl,
>
> In the following:
> http://cmip-pcmdi.llnl.gov/cmip5/docs/standard_output.xls, sheet "general", column A, row 15 and 17.
>
> It says "the value 0.0 should be reported where the sea fraction is 0",
>
> regards,
> Martin
>
> ________________________________
> From: Karl Taylor [taylor13 at llnl.gov<mailto:taylor13 at llnl.gov>]
> Sent: 05 December 2011 16:42
> To: Juckes, Martin (STFC,RAL,RALSP)
> Cc: go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>; Parton, Graham (STFC,RAL,RALSP); cmip5-users at jiscmail.ac.uk<mailto:cmip5-users at jiscmail.ac.uk>
> Subject: Re: [Go-essp-tech] Incorrect use of missing value in some MRI ocean data -- correction
>
> Dear Martin and all,
>
> For 3-d ocean fields like thetao, I think the missing value (not 0.0) should invariably be assigned to all land grid cells and for grid cells below the bottom of the ocean.  I can't find where in the document pointed to below it says otherwise.  I would like to correct the document, so please tell me where it needs revision.
>
> thanks,
> Karl
>
> On 12/4/11 8:07 PM, martin.juckes at stfc.ac.uk<mailto:martin.juckes at stfc.ac.uk><mailto:martin.juckes at stfc.ac.uk><mailto:martin.juckes at stfc.ac.uk>  wrote:
>
> I owe MRI an apology -- the use of zero instead of a missing value is in fact recommended in (http://cmip-pcmdi.llnl.gov/cmip5/docs/standard_output.xls),
>
> regards,
> Martin
> ________________________________________
> From: Juckes, Martin (STFC,RAL,RALSP)
> Sent: 04 December 2011 08:45
> To: go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu><mailto:go-essp-tech at ucar.edu><mailto:go-essp-tech at ucar.edu>; Parton, Graham (STFC,RAL,SSTD); cmip5-users at jiscmail.ac.uk<mailto:cmip5-users at jiscmail.ac.uk><mailto:cmip5-users at jiscmail.ac.uk><mailto:cmip5-users at jiscmail.ac.uk>
> Cc: Pascoe, Stephen (STFC,RAL,RALSP)
> Subject: Incorrect use of missing value in some MRI ocean data.
>
> Hello,
>
> It has come to light that some MRI ocean data has land grid points set to zero rather than to the declared missing value. This is likely to confuse some applications reading and plotting the data -- I've notified Seiji Yukimoto at MRI,
>
> sincerely,
> Martin
> ________________________________________
> From: Dennis Shea [shea at ucar.edu<mailto:shea at ucar.edu><mailto:shea at ucar.edu><mailto:shea at ucar.edu>]
> Sent: 03 December 2011 19:45
> To: Zhang Tao
> Cc: Juckes, Martin (STFC,RAL,RALSP); haley at ucar.edu<mailto:haley at ucar.edu><mailto:haley at ucar.edu><mailto:haley at ucar.edu>; Gary Strand; Karl Taylor
> Subject: Re: [ncl-talk] How to regrid CMIP5 ocean temp. data to regular 1X1 grid
>
> CMIP5 users beware!   :-(
>
> ---
>
> The first rule of data processing is to 'look at the data.'
>
> The problem is *not* with the cdo. Rather the source data file
> from CMIP5 has incorrect information. I read the  surface level
>
>     a   =
> addfile("thetao_Omon_MRI-CGCM3_piControl_r1i1p1_230101-230102.lite.nc","r")
>     ta  = a->thetao(0,0,:,:)
>
>     printVarSummary(ta)
>     printMinMax(ta,0)
>
>
> The variable has the following attributes
>
>     missing_value :      1e+20
>     _FillValue : 1e+20
>
> I counted the number of number of _FillValue (nmsg1) and the
> min/max temperatures.
>
> (0)     Sea Water Potential Temperature: min=0   max=303.924
> (0)     nmsg1=0
>
> Obviously, a temperature of 0 is physically not correct. I printed
> the array. No missing values (1e20) were encountered. What about land?
> The actual _FillValue (missing_value) is 0.0. In an NCL
> script I reset to 0.0
>
>     ta at _FillValue = 0.0
>
> I counted the _FillValue and the min/max
>
> (0)     nmsg2=42671
> (0)     Sea Water Potential Temperature: min=271.293   max=303.924
>
> The temperature range is much more reasonable.
>
> So the cdo treated the original 0.0 as valid values rather than
> _FillValue. I used the NCO operator, ncatted, to create a copy of the
> original source file but altered the _FillValue to 0.0
>
> %>  ncatted -O -h -a _FillValue,thetao,o,f,0
> thetao_Omon_MRI-CGCM3_piControl_r1i1p1_230101-230102.lite.nc
> thetao_Omon_MRI_FillValue.nc
>
> Then ran the cdo to generate the weights
>
> %>  cdo genbil,r360x180 thetao_Omon_MRI_FillValue.nc
> thetao_Omon_MRI_bilwgt.nc
>
>
> Then did the remap
>
> %>  cdo remap,r360x180,thetao_Omon_MRI_bilwgt.nc
> thetao_Omon_MRI_FillValue.nc thetao_Omon.r360x180.nc
>
> I works!!
>
> See: http://www.cgd.ucar.edu/~shea/TaoZhang.png
>
> D
>
>
> On 12/2/11 4:12 PM, Zhang Tao wrote:
>
>
> Dennis,
>
> I have attached 3 plots for you to take a look. MPI.pdf is the results
> from MPI model, I use "cdo remapbil,ll1deg_grid.nc<input file>  <output
> file>  " to get it.
>
> I plot out the contour and shaded plots of MRI-CGCM3 which is obtained
> from your command. clearly, the following command does not work
> well with this model. I use "cdo remapbil,ll1deg_grid.nc<input file>
> <output file>  " for this model, similar results are obtained. There are
> lots of unrealistically points in the land.
>
> Tao
>
>
> %>  cdo genbil,r360x180
> thetao_Omon_MRI-CGCM3_piControl_r1i1p1_230101-230102.lite.nc
> thetao_Omon_MRI_bilwgt.nc
>
> &>  cdo remap,r360x180,thetao_Omon_MRI_bilwgt.nc
> thetao_Omon_MRI-CGCM3_piControl_r1i1p1_230101-230102.lite.nc
> thetao_Omon.r360x180.nc
>
>
>
>
> On 12/2/11 3:49 PM, Dennis Shea wrote:
>
>
> %>  cdo genbil,r360x180
> thetao_Omon_MRI-CGCM3_piControl_r1i1p1_230101-230102.lite.nc
> thetao_Omon_MRI_bilwgt.nc
>
> &>  cdo remap,r360x180,thetao_Omon_MRI_bilwgt.nc
> thetao_Omon_MRI-CGCM3_piControl_r1i1p1_230101-230102.lite.nc
> thetao_Omon.r360x180.nc
>
> ftp ftp.cgd.ucar.edu<ftp://ftp.cgd.ucar.edu><ftp://ftp.cgd.ucar.edu><ftp://ftp.cgd.ucar.edu>
> anonymous
> email
> cd pub/shea/ZhangTao
> prompt
> mget *
> quit
>
>
> =================
> 10997404 Dec 2 15:46 thetao_Omon_MRI_bilwgt.nc
> 1050660 Dec 2 15:47 thetao_Omon.r360x180.nc
>
> Hope it worked.
>
> I'm outta her!
>
> D
>
>
> On 12/02/2011 03:00 PM, Zhang Tao wrote:
>
>
> Dennis,
>
> Could you write down the detailed CDO command to remap Japanese model?
> I can make a test.
>
> Thanks,
> Tao
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20111205/279d117b/attachment-0001.html 