GAMAP bugs and fixes
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.
- 1 Outstanding issues
- 2 Resolved issues
Bug in isopleth_map.pro
Matt Alvarado (firstname.lastname@example.org) 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.
Bob Yantosca (email@example.com) wrote:
- Yes, this was a bug. We'll add this to the next GAMAP version.
--Bob Y. 14:44, 9 October 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 in the next GAMAP release (v2.13) will let you set your own RGB vectors. You can get it here.
--phs 14:50, 22 September 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)
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 here.
--phs 14:55, 15 August 2008 (EDT)
I cannot read a binary file larger than about 2.1 GB
Please see this post this post which describes a problem that you may encounter when trying to read a binary punch file that is larger than 2.1 GB.
Paul Hezel (firstname.lastname@example.org) 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:
- [[File I/O with GAMAP#Splitting_and_joining_binary_punch_files|Splitting and joining binary punch files]
- Error -262 encountered when reading a bpch file
- 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 (email@example.com) 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 LON64 data type. Not all of our GAMAP users may have 64-bit IDL. You may run into that issue.
--Bob Y. 16:27, 26 November 2008 (EST)
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 (firstname.lastname@example.org) 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 (email@example.com) 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 (firstname.lastname@example.org) 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 (email@example.com) 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.
NOTE: This bug has now been resolved in GAMAP v2-12.
--Bob Y. 13:33, 8 September 2008 (EDT)