Ray:

I added a namelist read parameter NSTEPQRJ, an integer specifying
the nth step to call qrj. E.g., if NSTEPQRJ=4, qrj is called every
4th step.

I made 5 runs on bluevista, with NSTEPQRJ = 2,4,6,8, and 10, and 
they all crashed. The higher NSTEPQRJ is, the sooner it stops.
I started from ROBLE.tiegcmdr10.peqd004.nc, 36,0,0, with STEP=90.

NSTEPQRJ=2 stopped near 36,5,30
NSTEPQRJ=4 stopped near 36,3,45
NSTEPQRJ=6 stopped near 36,3,0
NSTEPQRJ=8 stopped near 36,2,45
NSTEPQRJ=10 stopped near 36,2,30

I ran tgcmproc_dres_f90 on the last secondary history saved in
each run. The plots, along with the history and stdout files are 
on bluevista:

/ptmp/foster/tiegcm-hist-lbc/nstepqrj=2/tgcmproc.cgm
/ptmp/foster/tiegcm-hist-lbc/nstepqrj=4/tgcmproc.cgm
/ptmp/foster/tiegcm-hist-lbc/nstepqrj=6/tgcmproc.cgm
/ptmp/foster/tiegcm-hist-lbc/nstepqrj=8/tgcmproc.cgm
/ptmp/foster/tiegcm-hist-lbc/nstepqrj=10/tgcmproc.cgm

TE and TI are having the usual problems, see esp frame 52
(map of TI at zp=0), and frame 177 (lon slice of TI at midnight).

I'm not sure exactly where its crashing, as bluevista is not
great at tracebacks. I think the "memory fault" error we saw
on bv last week is what bv does when NaN's are produced.
I've submitted the same 5 jobs to bluesky, but they are queued. 
I may make a debug run of NSTEPQRJ=2, to see where its crashing,
or first producing NaNs. If you want, I can review the code to
rotate the fields in between qrj calls (we did this with mtgcm).

--Ben