Difference between revisions of "GAMAP bugs and fixes"
m (→Using PS-PTOP in GAMAP with GEOS-Chem v8+ outputs)
|Line 1:||Line 1:|
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
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 ==
== Outstanding issues ==
Revision as of 17:51, 8 September 2008
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.
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)
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)