[
https://issues.apache.org/jira/browse/CLIMATE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13704046#comment-13704046
]
Kim, Jinwon commented on CLIMATE-186:
-------------------------------------
Please consider following points in revising the code to handle these problems.
Please see my suggestions following ">>>" sign.
1. longitude issue
When reading longitude from netcdf files, the modules in files.py automatically
convert longitudes larger than 180 to negative values. This becomes a problem
because in GCMs, the longitude array is not monotonically increasing any more
(0, 2.5, ...., 180, -175, -172.5, -170,.......... -2.5) due to the conversion.
If we choose North America region, RCMES subsets data over the Tibetan Plateau
for regridding.
>>> If such a case happens, the model data must be re-ordered in such a way to
>>> start from the "negative" meridian nearest to -180 deg. This will ensure
>>> that the model data will vary in the zonal direction in the same way as the
>>> data stored in RCMED.
2. latitude issue
In NCEP/NCAR reanalysis, latitude variable (lat) monotonically decreases from
north to south. With the current version, users must re-order data so that
latitude values increase monotonically from south to north.
>>> "Don't fix the code - reload the NCEP reanalysis data." This is the default
>>> arrangement of both NCEP/NCAR and NCEP/DOE reanalysis datasets. If
>>> latitudes of the NCEP/NCAR reanalysis currently stored in RCMED vary from
>>> north to south, the reanalysis data must be re-loaded after rearranging the
>>> data in the opposite order (i.e., flip in the meridional direction). Like
>>> the order of longitude above, the data stored in RCMED must vary from south
>>> to north.
3. leap years
This is a real problem. GCMs typically run using three types of calendars; the
true calendar (w/ leap years), the 365-day calendar (no leap years) or the
360-day calendar (every month has 30 days). Among these, the last two calendars
may be most widely used. The most permanent solution may be two add two
additional calendars, 365-day and 360-day calendars, and let users choose among
the true (current), 365-, and 360-day calendars. Please note that this will
require a substantial re-coding. Please don't make this change in the version
2.1; please create a temporary version (e.g., 2.1.1) and implement this change
in that code for future release as an update.
Thanks.
> RCMES cannot handle NCEP reanalysis and GCM data
> -------------------------------------------------
>
> Key: CLIMATE-186
> URL: https://issues.apache.org/jira/browse/CLIMATE-186
> Project: Apache Open Climate Workbench
> Issue Type: Bug
> Components: regridding
> Affects Versions: 0.1-incubating
> Reporter: Huikyo Lee
> Assignee: Huikyo Lee
> Priority: Critical
> Fix For: 0.1-incubating
>
>
> I found some critical bugs while using Jinwon's version 2.1 with CMIP5
> outputs and NCEP DOE reanalysis 2 data.
> They are common problems of 0.1-incubating (RC4) and Jinwon's 2.1
> Currently RCMES cannot properly handle NCEP/NCAR reanalysis or CMIP5 outputs
> 1. longitude issue
> When reading longitude from netcdf files, the modules in files.py
> automatically convert longitudes larger than 180 to negative values. This
> becomes a problem because in GCMs, the longitude array is not monotonically
> increasing any more (0, 2.5, ...., 180, -175, -172.5, -170,.......... -2.5)
> due to the conversion. If we choose North America region, RCMES subsets data
> over the Tibetan Plateau for regridding.
> 2. latitude issue
> In NCEP/NCAR reanalysis, latitude variable (lat) monotonically decreases from
> north to south. With the current version, users must re-order data so that
> latitude values increase monotonically from south to north.
> 3. leap years
> Some CMIP5 GCMs do not consider leap years at all. Our current time decoding
> reading modules cannot handle these model outputs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
