#50 programming
Colleagues
Based on a misunderstanding that Bob G. and I had about
this suggestion,
I opt to make it again with an important modification.
I strongly urge that GBTIDL include some system globals
that give the
programming user important hooks into the code. These
globals are
not about any one data record, rather they are control
globals that
allow the package to work on the data more efficiently
and powerfully.
Thus, contrary to my previous request that they be made
part of the !g.
structure, I think a new, control structure should be
created, in the
spirit of the !gc. structure. Physical constants of
nature do not
have to travel along with data io; neither do system
control globals.
Here is a start at this structure:
-----------------------------------------------------------------------------
;+
;
; Procedure to create GBTIDL structure for SELECT/FIND
; as well as other system control hooks
;
;
; T.M. Bania June 2005
;-
pro gbt_struct
;
on_error,2
compile_opt idl2
;
gbt = { gbt_struct, $ ;
;
; These are used to SELECT/FIND data
;
source:string(replicate(32B,16)), $
projid:string(replicate(32B,32)), $
backend:string(replicate(32B,32)), $
observer:string(replicate(32B,32)), $
bandwidth:0.0D, $
telescope:string(replicate(32B,16)), $ ;
telescop in sdfits
polarization:string(replicate(32B,2)), $ ;
crval4 in sdfits
polarization_num:0L, $
scan_number:0L, $ ; scan in sdfits
procedure:string(replicate(32B,16)), $ ;
obsmodes[0] in sdfits
switch_state:string(replicate(32B,16)), $ ;
obsmodes[1] in sdfits
switch_sig:string(replicate(32B,16)), $ ;
obsmodes[2] in sdfits
obsid:string(replicate(32B,32)), $
frontend:string(replicate(32B,16)), $
sampler_name:string(replicate(32B,16)), $ ;
sampler in sdfits
feed:0L, $ ; feed in sdfits
srfeed:0L, $ ; srfeed in sdfits
feed_num:0L, $
if_number:0L, $ ; from index file
;
; bookkeeping globals: probably should the one each
for input,
; output, and archive files...do
it with a
; structure?
;
lastrec:0L , $ ; last record# read from
'filein'
lastscan:0L, $ ; last scan# gotten from
'filein'
lastnsave:0L, $ ; last nsave written to
lastacount:0L, $ ; last acount index in STACK used
;
recmin:0L, $ ; first rec# for search range
recmax:0L, $ ; last rec# for search range
scanmin:0L, $ ; first scan# for search range
scanmax:0L, $ ; last scan# for search range
input_file_name:string(replicate(32B,80)), $
nrecs_in_filein:0L, $ ; total number of records
in filein
scanmax_in_filein:0L, $ ; maximum scan# in filein
output_file_name:string(replicate(32B,80)), $
nrecs_in_fileout:0L, $ ; total number of
records in fileout
scanmax_in_fileout:0L $ ; maximum scan# in filein
}
;
defsysv,'!gbt',{gbt_struct}
;
print,'!gbt structure created'
;
return
end
-------------------------------------------------------------------------------------
Now, I realize that one can get some of these things
with existing functions.
The point here is that these globals are *storeage*
places wherein a programmer
can park values for important GBTIDL parameters and
then invoke them easily
from .pro's. When the system changes the values of
these as it passes data
around, these static values can be powerfully used in code.
I am thinking that .pro's such as 'filein' and
'fileout' should automatically
increment the relevant max rec/scan values in this
structure....
Logged In: YES
user_id=978628
I'm going to make a first pass at this for the next version
of GBTIDL (2.0) planned for the end of February. If you
have any additions or changes to what you've said here,
please let me know.