Difference between revisions of "GAMAP bugs and fixes"

From Geos-chem
Jump to: navigation, search
(Backwards compatibility problems in myct.pro with IDL 5)
(9 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
== Outstanding issues ==
 
== Outstanding issues ==
  
=== Bug in isopleth_map.pro ===
+
=== Bugs in gc_combine_nd49.pro ===
  
'''''Matt Alvarado (mjalvara@seas.harvard.edu) wrote:'''''
+
==== Cannot combine more than 32767 data blocks ====
  
:I found an error on line 314 of <tt>isopleth_map.pro</tt> in GAMAP v2-12: It should say !D.Table_size, not !D.Tble_size.
+
'''''[mailto:michael.barkley@ed.ac.uk Mike Barkley] wrote:'''''
  
'''''Bob Yantosca (yantosca@seas.harvard.edu) wrote:'''''
+
:I've found a bug in version v2.12 of gamap with the program: <tt>gc_combine_nd49.pro</tt>.
  
:Yes, this was a bug.  We'll add this to the next GAMAP version.
+
:The final 4th output dimension is calculated using the <tt>nblocks</tt> multiplied by the <tt>nfiles</tt>, and this value is then assigned to the <tt>dim</tt>  array (which is an INT array; max value 32767).
  
--[[User:Bmy|Bob Y.]] 14:44, 9 October 2008 (EDT)
+
:If however, you are combing several years of data it is possible that <tt>nblocks * nfiles</tt> can exceed 32767 which cannot be assigned into the <tt>dim</tt> array. To get around this, one can simply convert the <tt>dim</tt> into a LONG array as soon as it is created (see extract of code below).
  
=== User Defined Color Table ===
+
    ;; --------- From 1st file only ----------------
When upgrading the color tables in Gamap v2.12, one functionality was lost: you could not define your own color table. An updated myct.pro routine in the next GAMAP release (v2.13) will let you set your own RGB vectors. You can get it [http://www.as.harvard.edu/ctm/geos/wiki_docs/myct.pro here].
+
        IF First THEN BEGIN
 +
 +
            ;; Check availability of tracer/category records, and get nb
 +
            ;; of daily timesteps
 +
            nblocks = n_elements( datainfo )
 +
 +
    ....
 +
 
 +
            ;; Get MODELINFO and GRIDINFO structures, dimension and offset
 +
            GetModelAndGridInfo, DataInfo[0], ModelInfo, GridInfo
 +
 +
            ; Previous code
 +
            ; dim    =  dataInfo[0].dim
 +
            ;  *** Simple correction ***
 +
            dim    = LONG( dataInfo[0].dim )
 +
            offset = dataInfo[0].first
  
--[[User:Plesager|phs]] 14:50, 22 September 2008 (EDT)
+
'''''Philippe Le Sager wrote:'''''
 +
 
 +
:Thanks Mike, nice catch.  It solves the problem locally: you can correctly plot and manipulate data now. However there may be some issue when you save them, since the call to <tt>ctm_make_datainfo.pro</tt> will try to assign LONG to an INT array (l. 441):
 +
 
 +
    datainfo.dim = ( dim > 1 )
 +
 
 +
So, we need another fix in <tt>create3dhstru.pro</tt>. We need to replace l. 94:
 +
 
 +
          Dim        : [ 0,0,0,0 ], $  ; dimension of data array (I,J,L,time)
 +
 
 +
with
 +
 
 +
          Dim        : [ 0L,0L,0L,0L ], $  ; dimension of data array (I,J,L,time)
 +
 
 +
Ultimately, a nice fix is to force all integers to 32-bit with:
 +
 
 +
      compile_opt defint32
 +
 
 +
But you have to put it in every routine....there must be a way to set that option globally, but I have not found it yet.
 +
 
 +
--[[User:Bmy|Bob Y.]] 09:16, 2 December 2008 (EST)
 +
 
 +
==== Incorrect results when using /DMAX or /DAVG options ====
 +
A minor bug could give incorrect results when either /DMAX or /DAVG was used, and timeseries from more than one month were processed at once. The output OUTTIME vector (if requested) was not correct, and if a smaller TIME span than the original series was requested, you could end up with a wrong series. The fix will be available in the next GAMAP release (v2.13). Meanwhile you can get it  [http://acmg.seas.harvard.edu/geos/wiki_docs/gamap/gc_combine_nd49.pro here].
 +
 
 +
--[[User:Plesager|phs]] 14:55, 15 August 2008 (EDT)
  
 
=== I cannot get a correct GIF or JPEG image from the screen ===
 
=== I cannot get a correct GIF or JPEG image from the screen ===
Line 30: Line 70:
 
=== Using PS-PTOP in GAMAP with GEOS-Chem v8+ outputs ===
 
=== Using PS-PTOP in GAMAP with GEOS-Chem v8+ outputs ===
 
GEOS-Chem does not write the category PS-PTOP into the <tt>tracerinfo.dat</tt> anymore (see [[Outstanding_issues_yet_to_be_resolved#Pressure_diagnostic_:_PS-PTOP_vs._PEDGE|PS-PTOP vs. PEDGE]]). However some routines still try to get the pressure surface with that category name. You can simply replace PS-TOP by PEDGE-$ in your program for them to work. To be able to use older GEOS-Chem output and new ones, you may use a coding similar to the one I did for  
 
GEOS-Chem does not write the category PS-PTOP into the <tt>tracerinfo.dat</tt> anymore (see [[Outstanding_issues_yet_to_be_resolved#Pressure_diagnostic_:_PS-PTOP_vs._PEDGE|PS-PTOP vs. PEDGE]]). However some routines still try to get the pressure surface with that category name. You can simply replace PS-TOP by PEDGE-$ in your program for them to work. To be able to use older GEOS-Chem output and new ones, you may use a coding similar to the one I did for  
<tt>ctm_column_du.pro</tt>, which you can find  [http://www.as.harvard.edu/ctm/geos/wiki_docs/ctm_column_du.pro here].
+
<tt>ctm_column_du.pro</tt>, which you can find  [http://acmg.seas.harvard.edu/geos/wiki_docs/gamap/ctm_column_du.pro here].
  
 
Note that to read pressure surface from time series diagnostic (ND48-51), you need to keep PS-PTOP in your IDL routines and replace PEDGE-$ by PS-PTOP in the tracerinfo.dat files created by GEOS-Chem. This is a bug, and we expect to get rid of all references to PS-PTOP in a future release of GAMAP.
 
Note that to read pressure surface from time series diagnostic (ND48-51), you need to keep PS-PTOP in your IDL routines and replace PEDGE-$ by PS-PTOP in the tracerinfo.dat files created by GEOS-Chem. This is a bug, and we expect to get rid of all references to PS-PTOP in a future release of GAMAP.
  
 
--[[User:Plesager|phs]] 16:25, 2 September 2008 (EDT)
 
--[[User:Plesager|phs]] 16:25, 2 September 2008 (EDT)
 
=== Bug in GC_COMBINE_ND49 ===
 
a minor bug could give incorrect results when either /DMAX or /DAVG was used, and timeseries from more than one month were processed at once. The output OUTTIME vector (if requested) was not correct, and if a smaller TIME span than the original series was requested, you could end up with a wrong series.
 
The fix will be available in the next GAMAP release (v2.13). Meanwhile you can get it [http://www.as.harvard.edu/ctm/geos/wiki_docs/gc_combine_nd49.pro here].
 
 
--[[User:Plesager|phs]] 14:55, 15 August 2008 (EDT)
 
  
 
=== I cannot read a binary file larger than about 2.1 GB ===
 
=== I cannot read a binary file larger than about 2.1 GB ===
  
'''''Paul Hezel (phezel@atmos.washington.edu) wrote:'''''
+
'''''[mailto:phezel@atmos.washington.edu Paul Hezel] wrote:'''''
  
 
:I am trying to read large <tt>ctm.bpch</tt> (1 year simulation) files via GAMAP and associated routines.  I've found that it fails because the filepos datatype is only a <tt>LONG</tt>, (eg. in <tt>internals/create3dhstru.pro</tt>, or in <tt>internals/ctm_read_data.pro</tt>).  The following posts seem to address this issue:
 
:I am trying to read large <tt>ctm.bpch</tt> (1 year simulation) files via GAMAP and associated routines.  I've found that it fails because the filepos datatype is only a <tt>LONG</tt>, (eg. in <tt>internals/create3dhstru.pro</tt>, or in <tt>internals/ctm_read_data.pro</tt>).  The following posts seem to address this issue:
Line 53: Line 87:
 
:If I changed filepos to either <tt>LONG64</tt> or even <tt>ulong</tt>, in <tt>create3dhstru.pro</tt>, would that capture most of the times it runs into this?  or would i have to trace and amend  all the places where that variable (i assume mostly filepos) were cast from or back to a LONG datatype?  Are there other issues I may be missing?
 
:If I changed filepos to either <tt>LONG64</tt> or even <tt>ulong</tt>, in <tt>create3dhstru.pro</tt>, would that capture most of the times it runs into this?  or would i have to trace and amend  all the places where that variable (i assume mostly filepos) were cast from or back to a LONG datatype?  Are there other issues I may be missing?
  
'''''Bob Yantosca (yantosca@seas.harvard.edu) replied:'''''
+
'''''[mailto:yantosca@seas.harvard.edu Bob Yantosca] replied:'''''
  
 
:Changing the file pointer to a <tt>LONG64</tt> would probably be the solution.  But we also have to be careful that once we pull on the thread, we don't unravel the whole sweater. :-)  There could conceivably be places in several internal routines that would need modification...but won't know until we look.
 
:Changing the file pointer to a <tt>LONG64</tt> would probably be the solution.  But we also have to be careful that once we pull on the thread, we don't unravel the whole sweater. :-)  There could conceivably be places in several internal routines that would need modification...but won't know until we look.
Line 63: Line 97:
 
=== Backwards compatibility problems in myct.pro with IDL 5 ===
 
=== Backwards compatibility problems in myct.pro with IDL 5 ===
  
'''''Nicolas Bousserez (N.Bousserez@dal.ca) wrote:'''''
+
'''''[mailto:N.Bousserez@dal.ca Nicolas Bousserez] wrote:'''''
  
 
:I got into trouble when using an old version of IDL (v5.6) together with the GAMAP tools. The errors seem come from the symbol <tt>~</tt> in the new <tt>myct.pro</tt> routine:
 
:I got into trouble when using an old version of IDL (v5.6) together with the GAMAP tools. The errors seem come from the symbol <tt>~</tt> in the new <tt>myct.pro</tt> routine:
Line 75: Line 109:
 
:The problem is that for the moment we only have  a limited number of IDL 7 licenses so that it would be very practical for me to be able to use the older versions of IDL together with the new GAMAP tools.  
 
:The problem is that for the moment we only have  a limited number of IDL 7 licenses so that it would be very practical for me to be able to use the older versions of IDL together with the new GAMAP tools.  
  
'''''Philippe Le Sager (plesager@seas.harvard.edu) wrote:'''''
+
'''''Philippe Le Sager replied:'''''
  
 
:The ~ (logical not) is not part of older IDL, but you can get around it with the NOT (bitwise negation). You just need to add 2. For example,
 
:The ~ (logical not) is not part of older IDL, but you can get around it with the NOT (bitwise negation). You just need to add 2. For example,
Line 85: Line 119:
 
     device, decomposed=0
 
     device, decomposed=0
  
:After that, if you still have problem double check that your idl_startup file is read.  
+
:After that, if you still have problem double check that your <tt>idl_startup.pro</tt> file is read.  
  
 
--[[User:Bmy|Bob Y.]] 16:40, 26 November 2008 (EST)
 
--[[User:Bmy|Bob Y.]] 16:40, 26 November 2008 (EST)
 +
 +
=== GAMAP plot titles showing "incorrect" altitudes for plots ===
 +
 +
'''''[mailto:ray.nassar@utoronto.ca Ray Nassar] wrote:'''''
 +
 +
The altitudes of levels that GAMAP uses to label plots does not agree with the altitudes shown in the GEOS-Chem online manual, for GEOS-4 and possibly other met fields.  This is a result of GAMAP using a different surface pressure to translate the sigma level into an altitude than used in the manual.  One can change GAMAP to get the same altitudes with the following edits to the code in the gamap_util directory:
 +
 +
In CTM_GRID, add (somewhere pretty close to the beginning):
 +
 +
  ;====================================================================
 +
  ; Define surface pressure
 +
  ;====================================================================
 +
        PSURF = 1000
 +
        print, "PSURF =", psurf
 +
 +
To get a second decimal place for the altitude, edit CTM_LABEL to show:
 +
 +
      AltStr = StrTrim( String( Alt[0], Format='(f6.2)' ), 2 ) + ' km'
 +
 +
This will give the same altitudes as in the manual (to 2 decimal places) but it disables calls with alternate values of "psurf".  There is likely a better solution for future versions of GAMAP, but this should be sufficient for most purposes. Furthermore, 1013 hPa would probably be the best value to use for a default "psurf" in the long term since it is the standard sea level pressure (1 atm).
  
 
== Resolved issues ==
 
== Resolved issues ==
Line 101: Line 155:
 
=== Corrupted binary file error ===
 
=== Corrupted binary file error ===
  
'''''Dylan Millet (dbm@umn.edu) wrote:'''''
+
'''''[mailto:dbm@umn.edu Dylan Millet] wrote:'''''
  
 
:Hi guys -- I ran into a problem with <tt>bpch_link.pro</tt>:
 
:Hi guys -- I ran into a problem with <tt>bpch_link.pro</tt>:
Line 112: Line 166:
 
     %                      $MAIN$        IDL>
 
     %                      $MAIN$        IDL>
  
'''''Bob Yantosca (yantosca@seas.harvard.edu) replied:'''''
+
'''''[mailto:yantosca@seas.harvard.edu Bob Yantosca] replied:'''''
  
 
:You may be using an older version of <tt>bpch_link.pro</tt>.  We recently fixed a problem for the little/big endian but that may not be in the std gamap as of yet.  The fix is simple.  You have to use the SWAP_ENDIAN keyword to all instances of OPEN_FILE:
 
:You may be using an older version of <tt>bpch_link.pro</tt>.  We recently fixed a problem for the little/big endian but that may not be in the std gamap as of yet.  The fix is simple.  You have to use the SWAP_ENDIAN keyword to all instances of OPEN_FILE:
Line 124: Line 178:
 
Specifying <tt>SWAP_ENDIAN=LITTLE_ENDIAN()</tt> in each call to OPEN_FILE will cause IDL to swap the endian ordering if you are running IDL on a little-endian machine.   
 
Specifying <tt>SWAP_ENDIAN=LITTLE_ENDIAN()</tt> in each call to OPEN_FILE will cause IDL to swap the endian ordering if you are running IDL on a little-endian machine.   
  
'''''NOTE: In [http://www.as.harvard.edu/ctm/gamap/ GAMAP v2-12], all routines that read binary files now use the SWAP_ENDIAN function, so this type of error should not occur again.'''''
+
'''''NOTE: In [http://acmg.seas.harvard.edu/ctm/gamap/ GAMAP v2-12], all routines that read binary files now use the SWAP_ENDIAN function, so this type of error should not occur again.'''''
  
 
--[[User:Bmy|Bob Y.]] 10:35, 18 July 2008 (EDT)
 
--[[User:Bmy|Bob Y.]] 10:35, 18 July 2008 (EDT)
Line 130: Line 184:
 
=== Too many logical unit numbers used by GAMAP ===
 
=== Too many logical unit numbers used by GAMAP ===
  
'''''Chris Holmes (cholmes@seas.harvard.edu) wrote:'''''
+
'''''[mailto:cholmes@seas.harvard.edu Chris Holmes] wrote:'''''
  
 
:A lot of gamap routines seem to use up LUNs for file io. This means that after iterating several read cycles, I can no longer open more files, even though I'm closing them. Here's what's going on:
 
:A lot of gamap routines seem to use up LUNs for file io. This means that after iterating several read cycles, I can no longer open more files, even though I'm closing them. Here's what's going on:
Line 146: Line 200:
 
:Having resolved that, I still run out of LUNs and I've traced the problem to <tt>CTM_OPEN_FILE</tt>. Actually there's already a comment about this problem on lines 725-731. So yes I think it is a problem and should be fixed.
 
:Having resolved that, I still run out of LUNs and I've traced the problem to <tt>CTM_OPEN_FILE</tt>. Actually there's already a comment about this problem on lines 725-731. So yes I think it is a problem and should be fixed.
  
'''''Philippe Le Sager (plesager@seas.harvard.edu) wrote:'''''
+
'''''Philippe Le Sager wrote:'''''
  
 
:I looked at the issues you pointed out.  <tt>OPEN_FILE</tt> was indeed automatically using get_lun, while the user could pass <tt>/get_lun</tt> with _extra. To avoid the double LUN assignment, I think the dummy <tt>/get_lun</tt> keyword is the best solution (users can put whatever they want in the _extra), although we could be more sophisticated and check on the field names in the extra keyword structure.
 
:I looked at the issues you pointed out.  <tt>OPEN_FILE</tt> was indeed automatically using get_lun, while the user could pass <tt>/get_lun</tt> with _extra. To avoid the double LUN assignment, I think the dummy <tt>/get_lun</tt> keyword is the best solution (users can put whatever they want in the _extra), although we could be more sophisticated and check on the field names in the extra keyword structure.
Line 152: Line 206:
 
:<tt>CTM_OPEN_FILE</tt> was more difficult. I did not find it well written, and it had quite a few coding errors and misleading comments. I decided to simplify it, and get rid of all the "testlun" business. It uses all LUN instead of every other one now. I am testing my version now and it seems to work fine. Feel free to look at it if you want.
 
:<tt>CTM_OPEN_FILE</tt> was more difficult. I did not find it well written, and it had quite a few coding errors and misleading comments. I decided to simplify it, and get rid of all the "testlun" business. It uses all LUN instead of every other one now. I am testing my version now and it seems to work fine. Feel free to look at it if you want.
  
'''''NOTE: This bug has now been resolved in [http://www.as.harvard.edu/ctm/gamap/ GAMAP v2-12].'''''
+
This bug has now been resolved in [http://acmg.seas.harvard.edu/gamap/ GAMAP v2-12].
  
 
--[[User:Bmy|Bob Y.]] 13:33, 8 September 2008 (EDT)
 
--[[User:Bmy|Bob Y.]] 13:33, 8 September 2008 (EDT)
 +
 +
=== User Defined Color Table ===
 +
When upgrading the color tables in GAMAP v2.12, one functionality was lost: you could not define your own color table. An updated myct.pro routine was added to GAMAP v2-13) which will let you set your own RGB vectors.
 +
 +
If you are using an older version of GAMAP, then you can get the updated <tt>myct.pro</tt> file [http://acmg.seas.harvard.edu/geos/wiki_docs/gamap/myct.pro HERE].
 +
 +
--[[User:Bmy|Bob Y.]] 16:51, 3 March 2010 (EST)
 +
 +
=== Bug in BPCH2HDF ===
 +
 +
Jesse Kenyon reported that there was a bug in the <tt>BPCH2HDF</tt> routine, which converts binary punch format to HDF format.  There was a typo in the code.  The lines:
 +
 +
  ; Read all data blocks
 +
  if ( N_Elements( Category ) gt 0 )                          $
 +
      then CTM_Get_Data, DataInfo, DiagN, File=InFile, _EXTRA=e $
 +
      else CTM_Get_Data, DataInfo,        File=InFile, _EXTRA=e
 +
 +
should now be replaced with:
 +
 +
  ; Read all data blocks
 +
  if ( N_Elements( DiagN ) gt 0 )                              $
 +
      then CTM_Get_Data, DataInfo, DiagN, File=InFile, _EXTRA=e $
 +
      else CTM_Get_Data, DataInfo,        File=InFile, _EXTRA=e
 +
 +
This fix was included in GAMAP release v2-13.
 +
 +
--[[User:Bmy|Bob Y.]] 16:51, 3 March 2010 (EST)
 +
 +
=== CTM_OVERLAY cannot make log-scale color plots ===
 +
 +
Chris Holmes reported that the <tt>LOG</tt> keyword was not being properly passed to the <tt>TVMAP</tt> routine call within <tt>ctm_overlay.pro</tt>.  Therefore we have to add it manually, as shown below:
 +
 +
  ; Call TVMAP to plot the pixel or contour map, but don't advance to the
 +
  ; next frame.  NOTE: C_COLORS is the vector of color levels for the
 +
  ; filled contour plot.  If not passed, then C_COLORS will return the
 +
  ; default values generated by internally by TVMAP.  This will be needed
 +
  ; for overlaying station data points on a filled contour map.
 +
  if ( OverPlot ne 1L ) then begin
 +
      TvMap, Data, Xmid, Ymid,                                    $
 +
        /NoAdvance,        WindowPos=Wp,      MinData=MinData,  $
 +
        MaxData=MaxData,  FContour=FContour, C_Levels=C_Levels, $
 +
        C_Colors=C_Colors, Log=Log,          _EXTRA=e
 +
  endif
 +
 +
This fix was included in GAMAP release v2-13.
 +
 +
--[[User:Bmy|Bob Y.]] 16:51, 3 March 2010 (EST)
 +
 +
=== Bug in isopleth_map.pro ===
 +
 +
'''''[mailto:mjalvara@seas.harvard.edu Matt Alvarado] wrote:'''''
 +
 +
:I found an error on line 314 of <tt>isopleth_map.pro</tt> in GAMAP v2-12: It should say !D.Table_size, not !D.Tble_size.
 +
 +
This fix was added to GAMAP version v2-13.
 +
 +
--[[User:Bmy|Bob Y.]] 16:51, 3 March 2010 (EST)

Revision as of 21:51, 3 March 2010

On this page we list various bugs that have been encountered in GAMAP and how to fix them. For information about general GAMAP usage, please see our GAMAP tips and tricks wiki page.

Outstanding issues

Bugs in gc_combine_nd49.pro

Cannot combine more than 32767 data blocks

Mike Barkley wrote:

I've found a bug in version v2.12 of gamap with the program: gc_combine_nd49.pro.
The final 4th output dimension is calculated using the nblocks multiplied by the nfiles, and this value is then assigned to the dim array (which is an INT array; max value 32767).
If however, you are combing several years of data it is possible that nblocks * nfiles can exceed 32767 which cannot be assigned into the dim array. To get around this, one can simply convert the dim into a LONG array as soon as it is created (see extract of code below).
   ;; --------- From 1st file only ----------------
        IF First THEN BEGIN

           ;; Check availability of tracer/category records, and get nb
           ;; of daily timesteps
           nblocks = n_elements( datainfo )

    ....
  
           ;; Get MODELINFO and GRIDINFO structures, dimension and offset
           GetModelAndGridInfo, DataInfo[0], ModelInfo, GridInfo

           ; Previous code
           ; dim    =  dataInfo[0].dim
           ;  *** Simple correction ***
           dim    = LONG( dataInfo[0].dim )
           offset = dataInfo[0].first 

Philippe Le Sager wrote:

Thanks Mike, nice catch. It solves the problem locally: you can correctly plot and manipulate data now. However there may be some issue when you save them, since the call to ctm_make_datainfo.pro will try to assign LONG to an INT array (l. 441):
   datainfo.dim = ( dim > 1 )

So, we need another fix in create3dhstru.pro. We need to replace l. 94:

          Dim        : [ 0,0,0,0 ], $  ; dimension of data array (I,J,L,time)

with

          Dim        : [ 0L,0L,0L,0L ], $  ; dimension of data array (I,J,L,time)

Ultimately, a nice fix is to force all integers to 32-bit with:

      compile_opt defint32

But you have to put it in every routine....there must be a way to set that option globally, but I have not found it yet.

--Bob Y. 09:16, 2 December 2008 (EST)

Incorrect results when using /DMAX or /DAVG options

A minor bug could give incorrect results when either /DMAX or /DAVG was used, and timeseries from more than one month were processed at once. The output OUTTIME vector (if requested) was not correct, and if a smaller TIME span than the original series was requested, you could end up with a wrong series. The fix will be available in the next GAMAP release (v2.13). Meanwhile you can get it here.

--phs 14:55, 15 August 2008 (EDT)

I cannot get a correct GIF or JPEG image from the screen

In the current version of GAMAP (v2.12), we use a version of TVREAD to get screen dump that has a bug for 16-bit displays. If you are using screen2gif.pro or tvread.pro directly, and your images do not look like the screen output, you are probably using a 16-bit display. You can:

  • switch to true color 32-bit display if available (go to display in the control panel),
  • or update tvread.pro

--phs 16:39, 2 September 2008 (EDT)

Using PS-PTOP in GAMAP with GEOS-Chem v8+ outputs

GEOS-Chem does not write the category PS-PTOP into the tracerinfo.dat anymore (see PS-PTOP vs. PEDGE). However some routines still try to get the pressure surface with that category name. You can simply replace PS-TOP by PEDGE-$ in your program for them to work. To be able to use older GEOS-Chem output and new ones, you may use a coding similar to the one I did for ctm_column_du.pro, which you can find here.

Note that to read pressure surface from time series diagnostic (ND48-51), you need to keep PS-PTOP in your IDL routines and replace PEDGE-$ by PS-PTOP in the tracerinfo.dat files created by GEOS-Chem. This is a bug, and we expect to get rid of all references to PS-PTOP in a future release of GAMAP.

--phs 16:25, 2 September 2008 (EDT)

I cannot read a binary file larger than about 2.1 GB

Paul Hezel wrote:

I am trying to read large ctm.bpch (1 year simulation) files via GAMAP and associated routines. I've found that it fails because the filepos datatype is only a LONG, (eg. in internals/create3dhstru.pro, or in internals/ctm_read_data.pro). The following posts seem to address this issue:
If I changed filepos to either LONG64 or even ulong, in create3dhstru.pro, would that capture most of the times it runs into this? or would i have to trace and amend all the places where that variable (i assume mostly filepos) were cast from or back to a LONG datatype? Are there other issues I may be missing?

Bob Yantosca replied:

Changing the file pointer to a LONG64 would probably be the solution. But we also have to be careful that once we pull on the thread, we don't unravel the whole sweater. :-) There could conceivably be places in several internal routines that would need modification...but won't know until we look.
Also -- one of the reasons we haven't looked at this is because you might need the 64-bit version of IDL to get the LONG64 data type. Not all of our GAMAP users may have 64-bit IDL.

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

Backwards compatibility problems in myct.pro with IDL 5

Nicolas Bousserez wrote:

I got into trouble when using an old version of IDL (v5.6) together with the GAMAP tools. The errors seem come from the symbol ~ in the new myct.pro routine:
   Reverse_Colors  = ~Reverse_Colors
                       ^
   % Illegal character in program text.
I also experienced some colors problem when using IDL v5.6 instead of more recent version like 6 or 7. For example I got black and white colors only for the IDL 5.6 version instead of colors for the idl 6 or 7 version when plotting.
The problem is that for the moment we only have a limited number of IDL 7 licenses so that it would be very practical for me to be able to use the older versions of IDL together with the new GAMAP tools.

Philippe Le Sager replied:

The ~ (logical not) is not part of older IDL, but you can get around it with the NOT (bitwise negation). You just need to add 2. For example,
   top = not below + 2  ; same as: ~below (in IDL6.x)
You can quickly test it in IDL 7. As for your missing colors, the first advice is to be sure you have set:
   device, decomposed=0
After that, if you still have problem double check that your idl_startup.pro file is read.

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

GAMAP plot titles showing "incorrect" altitudes for plots

Ray Nassar wrote:

The altitudes of levels that GAMAP uses to label plots does not agree with the altitudes shown in the GEOS-Chem online manual, for GEOS-4 and possibly other met fields. This is a result of GAMAP using a different surface pressure to translate the sigma level into an altitude than used in the manual. One can change GAMAP to get the same altitudes with the following edits to the code in the gamap_util directory:

In CTM_GRID, add (somewhere pretty close to the beginning):

  ;====================================================================
  ; Define surface pressure
  ;====================================================================
       PSURF = 1000
       print, "PSURF =", psurf

To get a second decimal place for the altitude, edit CTM_LABEL to show:

     AltStr = StrTrim( String( Alt[0], Format='(f6.2)' ), 2 ) + ' km'

This will give the same altitudes as in the manual (to 2 decimal places) but it disables calls with alternate values of "psurf". There is likely a better solution for future versions of GAMAP, but this should be sufficient for most purposes. Furthermore, 1013 hPa would probably be the best value to use for a default "psurf" in the long term since it is the standard sea level pressure (1 atm).

Resolved issues

IDLDE does not work properly

If you are running IDL and Firefox in a Linux environment then please take note. You may have to disable Firefox in order to get the IDL Development Environment (IDLDE) to work properly with IDL 7.

The issue is that the 32-bit version of Firefox (esp. Firefox 3) may cause a conflict with a Java library that the IDLDE needs to use. Disabling the browser seems to fix the problem.

--Bob Y. 12:52, 20 October 2008 (EDT)

Corrupted binary file error

Dylan Millet wrote:

Hi guys -- I ran into a problem with bpch_link.pro:
   IDL> bpch_link,'2006*bpch','new.bpch' 
   Now Reading 20060101_2x25.ctm.bpch
   % READU: Corrupted f77 unformatted file detected. Unit: 108, File: 20060101_2x25.ctm.bpch
   % Execution halted at: BPCH_LINK         142 /users/dbm/IDL/gamap_v2.10/file_io/bpch_link.pro
   %                      BPCH_LINK         142 /users/dbm/IDL/gamap_v2.10/file_io/bpch_link.pro
   %                      $MAIN$         IDL>

Bob Yantosca replied:

You may be using an older version of bpch_link.pro. We recently fixed a problem for the little/big endian but that may not be in the std gamap as of yet. The fix is simple. You have to use the SWAP_ENDIAN keyword to all instances of OPEN_FILE:
   ; External functions
   FORWARD_FUNCTION CTM_Grid, CTM_Type, MFindFile, Little_Endian

   ; Open the output file (write as big-endian)
   Open_File, OutFile, Ilun_OUT, /F77, /GET_LUN, /Write, Swap_Endian=Little_Endian()

Specifying SWAP_ENDIAN=LITTLE_ENDIAN() in each call to OPEN_FILE will cause IDL to swap the endian ordering if you are running IDL on a little-endian machine.

NOTE: In GAMAP v2-12, all routines that read binary files now use the SWAP_ENDIAN function, so this type of error should not occur again.

--Bob Y. 10:35, 18 July 2008 (EDT)

Too many logical unit numbers used by GAMAP

Chris Holmes wrote:

A lot of gamap routines seem to use up LUNs for file io. This means that after iterating several read cycles, I can no longer open more files, even though I'm closing them. Here's what's going on:
A lot of gamap2/gamap_util/ routines are opening files with the following command
   OPEN_FILE, File, LUN, /GET_LUN
OPEN_FILE checks whether the LUN variable is undefined (lines 151 and 241) and if so it allocates one (line 241).
But then OPEN_FILE also passes the /GET_LUN keyword to OPENW or OPENR via the _EXTRA keyword (lines 244-249), which allocates another LUN without freeing the first one.
I'm not sure what the best solution is. Probably remove the /GET_LUN keyword in all instances of OPEN_FILE. You could also add a GET_LUN keyword to OPEN_FILE that does nothing except prevent it from passing it on to OPENW and OPENR.
Having resolved that, I still run out of LUNs and I've traced the problem to CTM_OPEN_FILE. Actually there's already a comment about this problem on lines 725-731. So yes I think it is a problem and should be fixed.

Philippe Le Sager wrote:

I looked at the issues you pointed out. OPEN_FILE was indeed automatically using get_lun, while the user could pass /get_lun with _extra. To avoid the double LUN assignment, I think the dummy /get_lun keyword is the best solution (users can put whatever they want in the _extra), although we could be more sophisticated and check on the field names in the extra keyword structure.
CTM_OPEN_FILE was more difficult. I did not find it well written, and it had quite a few coding errors and misleading comments. I decided to simplify it, and get rid of all the "testlun" business. It uses all LUN instead of every other one now. I am testing my version now and it seems to work fine. Feel free to look at it if you want.

This bug has now been resolved in GAMAP v2-12.

--Bob Y. 13:33, 8 September 2008 (EDT)

User Defined Color Table

When upgrading the color tables in GAMAP v2.12, one functionality was lost: you could not define your own color table. An updated myct.pro routine was added to GAMAP v2-13) which will let you set your own RGB vectors.

If you are using an older version of GAMAP, then you can get the updated myct.pro file HERE.

--Bob Y. 16:51, 3 March 2010 (EST)

Bug in BPCH2HDF

Jesse Kenyon reported that there was a bug in the BPCH2HDF routine, which converts binary punch format to HDF format. There was a typo in the code. The lines:

  ; Read all data blocks
  if ( N_Elements( Category ) gt 0 )                           $
     then CTM_Get_Data, DataInfo, DiagN, File=InFile, _EXTRA=e $
     else CTM_Get_Data, DataInfo,        File=InFile, _EXTRA=e

should now be replaced with:

  ; Read all data blocks
  if ( N_Elements( DiagN ) gt 0 )                              $
     then CTM_Get_Data, DataInfo, DiagN, File=InFile, _EXTRA=e $
     else CTM_Get_Data, DataInfo,        File=InFile, _EXTRA=e

This fix was included in GAMAP release v2-13.

--Bob Y. 16:51, 3 March 2010 (EST)

CTM_OVERLAY cannot make log-scale color plots

Chris Holmes reported that the LOG keyword was not being properly passed to the TVMAP routine call within ctm_overlay.pro. Therefore we have to add it manually, as shown below:

  ; Call TVMAP to plot the pixel or contour map, but don't advance to the
  ; next frame.  NOTE: C_COLORS is the vector of color levels for the
  ; filled contour plot.  If not passed, then C_COLORS will return the 
  ; default values generated by internally by TVMAP.  This will be needed 
  ; for overlaying station data points on a filled contour map.
  if ( OverPlot ne 1L ) then begin
     TvMap, Data, Xmid, Ymid,                                    $
        /NoAdvance,        WindowPos=Wp,      MinData=MinData,   $
        MaxData=MaxData,   FContour=FContour, C_Levels=C_Levels, $
        C_Colors=C_Colors, Log=Log,           _EXTRA=e 
  endif

This fix was included in GAMAP release v2-13.

--Bob Y. 16:51, 3 March 2010 (EST)

Bug in isopleth_map.pro

Matt Alvarado wrote:

I found an error on line 314 of isopleth_map.pro in GAMAP v2-12: It should say !D.Table_size, not !D.Tble_size.

This fix was added to GAMAP version v2-13.

--Bob Y. 16:51, 3 March 2010 (EST)