Regridding with GAMAP: Difference between revisions

From Geos-chem
Jump to navigation Jump to search
Line 40: Line 40:


--[[User:Melissa Payer|Melissa Sulprizio]] 11:34, 3 September 2013 (EDT)
--[[User:Melissa Payer|Melissa Sulprizio]] 11:34, 3 September 2013 (EDT)
=== Cannot find PS-PTOP error ===
'''''Douglas Finch wrote:'''''
:I have found what I think is a bug in a GAMAP routine - regridh_restart.pro (in the latest version) It is requesting ps-top file which I understand is outdated.  I've commented everything out that involved this and it seems to be working, but I'm not sure how the output compares to what it should be.
'''''Bob Yantosca replied:'''''
:Thanks for writing.  The <tt>regridh_restart.pro</tt> needs to know about the PS-PTOP entry in diaginfo.dat.  In the gamap2/input_files/diaginfo.dat file you should see these lines:
    10000 PEDGE-$                                  Pressure at level edges               
    <b>10000 PS-PTOP                                  Pressure level edges</b>
:So that should let GAMAP find the proper ps-ptop file for the regridding.  But if you are using GAMAP from a GEOS-Chem run directory, then the <tt>diaginfo.dat</tt> written out by GEOS-Chem may not have the <tt>PS-PTOP</tt> line (in '''boldface''' above) included.  We have fixed this in [[GEOS-Chem v9-02]], but if you are using an older version of GEOS-Chem then this may still be a problem.  The quick fix would be to copy the line in '''boldface''' above to the <tt>diaginfo.dat</tt> file in your GEOS-Chem run directory, and then type:
      ctm_diaginfo, /force
      ctm_tracerinfo, /force
at the IDL prompt.  This will cause GAMAP to re-read the <tt>diaginfo.dat</tt> and <tt>tracerinfo.dat</tt> files from scrach.  GAMAP will try to look for <tt>diaginfo.dat</tt> and <tt>tracerinfo.dat</tt> files in the current directory first, and then if it can’t find it there, it’ll look in the <tt>gamap2/input_files/</tt> directory.
Also, the <tt>ps-ptop.</tt> files used by <tt>regridh_restart.pro</tt> are contained in the directory <tt>gamap2/data_files</tt>.  We currently have these files available:
ps-ptop.geos1.2x25  ps-ptop.geos3.4x5      ps-ptop.geos5.025x03125  ps-ptop.geoss.2x25
ps-ptop.geos1.4x5  ps-ptop.geos4.1x125.ch  ps-ptop.geos5.05x0667    ps-ptop.geoss.4x5
ps-ptop.geos3.1x1  ps-ptop.geos4.2x25      ps-ptop.geos5.2x25
ps-ptop.geos3.2x25  ps-ptop.geos4.4x5      ps-ptop.geos5.4x5
So if you are trying to regrid from a grid other than those represented here, then you may still run into an error. 
--[[User:Bmy|Bob Y.]] 10:16, 15 May 2014 (EDT)


== Regridding T42 to GEOS-Chem grids ==
== Regridding T42 to GEOS-Chem grids ==

Revision as of 14:16, 15 May 2014

On this page we list some tips and tricks for regridding data with GAMAP. Please also see the following pages:

--Bob Y. 16:08, 26 November 2008 (EST)

Regridding restart files

GAMAP routines REGRIDH_RESTART and REGRIDV_RESTART may be used to horizontally and vertically regrid restart files from one grid to another. For example, to regrid a restart file from 4° x 5° to 2° x 2.5° resolution use:

REGRIDH_RESTART, INFILENAME='restart.4x5.geos5.2005070100', OUTFILENAME='restart.2x25.geos5.2005070100', OUTRESOLUTION=2

A global restart file can be cut down to a nested-grid domain using the routine CREATE_NESTED.

REGRIDH_RESTART, INFILENAME='restart.4x5.geos5.2005070100', OUTFILENAME='restart.05x0667.geos5.2005070100', OUTRESOLUTION=0.667

CREATE_NESTED, INFILENAME='restart.05x0666.geos5.2005070100', OUTFILENAME='restart.05x0667.NA.geos5.2005070100', /NAMER

Could not read INPSURF error

Several users have reported the following error when regridding bpch files using the GAMAP routine REGRIDH_RESTART:

% CTM_GET_DATA: Invalid diagnostic requested:            0            0            0
% CTM_GET_DATABLOCK: Sorry...no data found!
% REGRIDH_RESTART: Could not read INPSURF!
% Execution halted at: REGRIDH_RESTART   355 /home/mpayer/IDL/gamap2/regridding/regridh_restart.pro

To solve this problem, you will need to modify the diaginfo.dat file in the directory that you are doing the regridding. In that file, change the following line from

10000 PEDGE-$                                  Pressure at level edges                 

to

10000 PS-PTOP                                  Pressure at level edges                 

GAMAP uses the PS-PTOP fields located in the gamap2/data_files subdirectories for the regridding and is unable to read the fields properly if the diagnostic is not defined in diaginfo.dat.

--Melissa Sulprizio 11:34, 3 September 2013 (EDT)

Cannot find PS-PTOP error

Douglas Finch wrote:

I have found what I think is a bug in a GAMAP routine - regridh_restart.pro (in the latest version) It is requesting ps-top file which I understand is outdated. I've commented everything out that involved this and it seems to be working, but I'm not sure how the output compares to what it should be.

Bob Yantosca replied:

Thanks for writing. The regridh_restart.pro needs to know about the PS-PTOP entry in diaginfo.dat. In the gamap2/input_files/diaginfo.dat file you should see these lines:
   10000 PEDGE-$                                  Pressure at level edges                 
   10000 PS-PTOP                                  Pressure level edges
So that should let GAMAP find the proper ps-ptop file for the regridding. But if you are using GAMAP from a GEOS-Chem run directory, then the diaginfo.dat written out by GEOS-Chem may not have the PS-PTOP line (in boldface above) included. We have fixed this in GEOS-Chem v9-02, but if you are using an older version of GEOS-Chem then this may still be a problem. The quick fix would be to copy the line in boldface above to the diaginfo.dat file in your GEOS-Chem run directory, and then type:
     ctm_diaginfo, /force
     ctm_tracerinfo, /force

at the IDL prompt. This will cause GAMAP to re-read the diaginfo.dat and tracerinfo.dat files from scrach. GAMAP will try to look for diaginfo.dat and tracerinfo.dat files in the current directory first, and then if it can’t find it there, it’ll look in the gamap2/input_files/ directory.

Also, the ps-ptop. files used by regridh_restart.pro are contained in the directory gamap2/data_files. We currently have these files available:

ps-ptop.geos1.2x25  ps-ptop.geos3.4x5       ps-ptop.geos5.025x03125  ps-ptop.geoss.2x25
ps-ptop.geos1.4x5   ps-ptop.geos4.1x125.ch  ps-ptop.geos5.05x0667    ps-ptop.geoss.4x5
ps-ptop.geos3.1x1   ps-ptop.geos4.2x25      ps-ptop.geos5.2x25
ps-ptop.geos3.2x25  ps-ptop.geos4.4x5       ps-ptop.geos5.4x5

So if you are trying to regrid from a grid other than those represented here, then you may still run into an error.

--Bob Y. 10:16, 15 May 2014 (EDT)

Regridding T42 to GEOS-Chem grids

Ben Miller wrote:

Justin and I have been working on translating some emission fluxes and deposition velocity data from TOMCAT's T42 grid (128x64, with some variance in latitude step-size) into Geos 4x5 gridboxes. Do you know of any existing routines in IDL or some other language that we could adapt to make the two grids talk to each other?

Philippe Le Sager replied:

There is nothing in IDL to deal with any kind of grid. However (you may have already found it) the RETRO tools (M. Schultz) can regrid data from the T42 to regular grids. It deals with NetCDF files apparently, but ascii/nc conversion is not a problem.
Have a look at the example in the regrid routine of the following package: MGS_Regrid (V2).

--Bob Y. 09:27, 8 August 2008 (EDT)

Regridding from a Lambert conformal grid to a lat-lon grid

Rynda Hudman wrote:

I am trying to plot some North American Regional Reanalysis (NARR) data and compare it to the GEOS precipitation fields. NARR is on a Lambert Conformal grid, so it is irregular and each lat and lon have 2-dimensional arrays defining their 4 corners.
I would like to interpolate/regrid this onto a uniform grid for comparison with GEOS. Could you guys offer some suggestions?

Philippe Le Sager wrote:

You need to look at the "gridding and interpolation" chapter of the IDL guide/help. You can directly go to the MIN_CURVE_SURF function though. This is the one I have mostly used. Works like a wonder.

--Bob Y. 10:32, 6 November 2008 (EST)