GAMAP bugs and fixes
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 or directly tvread, 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-TOP in GAMAP with GEOS-Chem v8+ outputs
GEOS-Chem does not write the category PS-TOP 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-TOP in your IDL routines and replace PEDGE-$ by PS-TOP in the tracerinfo.dat files created by GEOS-Chem. This is a bug, and we expect to get rid of all references to PS-TOP 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)
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)