Notes on MOSES Science

C. Kankelborg, 2006 June 20 -

Jump to the FIRST MOVIES.

2006 June 20

The topic of this notebook is scientific analysis of MOSES data, that is, discovering what is happening on the Sun.

Analysis Plan

  1. Data reduction (../)
    1. Level 0 (imageindex.xml, mdata/)
    2. Level 1 (moses_prep.pro, mosesLevelOne.sav)
    3. Alignment
      1. Align orders m = -1, 0, 1 (moses_align_orders.pro, mosesAlignOrders_snap.sav)
      2. Remove drift
  2. Scientific analysis (./)
    1. Simple inference of doppler shifts
      1. Movies of intensity and order differences
      2. Centroid features, estimate doppler shift
    2. Inversions
      1. Inversion of a row or small neighborhood
      2. Global inversions

Status

Level 0, Level 1, and alignment of orders have been completed but are not in final form. Level 0 is nearly complete, but lacks a flat field for m = +1, and all the flat fields are being improved. The digital filtering step at the end of Level 1 also needs review. The order alignment is not yet satisfactory, but the inconsistencies have been whittled down to sub-pixel precision.

Since provisional alignments of Level 1 data exist, it will soon be possible to begin scientific analysis.

2006 June 22

Working on a program to make binned, full-field movies in all 3 orders: MOVIE2x2.

IDL 5.x (on Wind or Fire, for example) has at least one bug in handling format codes. This slightly complicates running MOVIE2x2 because the image filenames don't come out as anticipated. Quoting the IDL Building Applications manual:

For numeric format codes, if the first digit of the width parameter is a zero, IDL will pad the value with zeroes rather than blanks. For example

PRINT, FORMAT='(I08)', 300

produces the following output:

00000300

Well, here is what really happens with our three 4-way Sun machines, each running a different version of IDL::

Fire, running IDL 5.3, Solaris (sunos sparc):

IDL> PRINT, FORMAT='(I08)', 300
     300

Wind, running IDL 5.5, Solaris (sunos sparc):

IDL> PRINT, FORMAT='(I08)', 300
     300

Earth, running IDL 6.2, Solaris (sunos sparc m64):

IDL> PRINT, FORMAT='(I08)', 300
00000300

First run (on Earth, since it has IDL 6.2): movie2x2.log060622.222834. Contrary the log file, it did not take 643 minutes to run! Probably 643 seconds; this is close to the difference between the filename date stamp and the file modification time. Problems with this run:

  1. The drift compensation is backwards on plus and minus orders, but OK on zero. The saved data cubes are clearly not right.
  2. Border at top of zero order movie shows improper handling of missing data.
  3. Scaling is inconsistent, with the apparent brightness increasing with exposure.
  4. I expected the saturated regions to be white, but they are black; color table evidently not used when the JPEGs were saved.

The first two are problems with MOSES_ALIGN_FINAL and its subroutines. The second two are problems in MOVIE2x2 and its subroutines.

2006 June 23

Problems 1 and 2 are solved. movie2x2.log060623.082426. (The fix for 2 is probably not reliable because of the IDL POLY_2D bug, but I am not too concerned about this.)

Problem 3 is solved. I just subtracted 1b from the results of DISPLAYSCALE, so that 0 maps to 255. movie2x2.log060623.103142

I think I understand problem 4. Because I've replaced the saturated pixels with NaN, the median doesn't include them. So Longer exposures are missing pixels at the top end of the histogram, and the median is systematically lower. When I divide out the median, the renormalized image is therefore too bright in proportion to the number of saturated pixels. Best solution would be to use Inf instead of NaN. But that requires going through the whole darned data reduction from scratch, treating Inf (for saturated) and NaN (for missing data at the edges) differently. What to do? Idea: make a map of always-good pixels, and use the median or mean of those pixels for normalization.

Wrote RENORMALIZE to solve problem 4, and now MOVIE2x2 uses this as its normalization standard. RENORMALIZE batch job: renormalize.log060623.120839

Ran MOVIE2x2 again, movie2x2.log060623.131825. Still didn't work. I see a simpler problem now, I am running DISPLAYSCALE individually on each image (d'oh!).

Aha, problem with DISPLAYSCALE:

IDL> foo = findgen(10,20,30)
IDL> help,foo
FOO             FLOAT     = Array[10, 20, 30]
IDL> help,displayscale(foo)
% Compiled module: DISPLAYSCALE.
    BYTE      = Array[10, 20]

Note, by the way, that displayscale.pro is now located in /home/kankel/idl/cck/. I am presently keeping copies both there and in /disk/data/kankel/MOSESflight/ so that docs will always mirror a current copy to the web directory. Should come up with a better system.

Problem 4 is now solved: movie2x2.log060623.142210. Scaling is a bit dark... works better if I just histogram equalize. That will do for now. Movies below.

Just wrote MOVIE_DIFF. The inter-order normalization from RENORMALIZE is evidently not good enough to make a movie of the difference between orders.

Wrote RENORMALIZE2. This is a different strategy, taking advantage of more pixels. Run log: renormalize2.log060623.170244.

Modified MOVIE2x2 and MOVIE_DIFF to use results of renormalize2. Now running MOVIE_DIFF, movie_diff.log060623.171521.

The two versions of RENORMALIZE result in identical problems: the difference images look just like negative images. Why?

I found the bug. It was not in RENORMALIZE.

had this  ---> snrunk = rebin(cube_zero[*,*,0], Nx/2, Ny/2)
should be ---> shrunk = rebin(cube_zero[*,*,0], Nx/2, Ny/2)

Movies

First movies in all 3 orders: m = -1, m = 0, m = +1.

I now have a good full-FOV, 2x2 binned difference movie (plus - zero). At the front and back of the movie I put extra copies of the first and last frames, with a coordinate grid superimposed. The divisions are 50 pixels in the 2x2 binned movie, corresponding to 100 pixels at native resolution, about 1 arc minute on the sky, or 43 Mm on the Sun.

Observations

Looking at the above difference movie, I saw two events that look especially interesting:

Coordinate Systems

Here is an attempt at setting down the right relationship between solar directions, payload / focal plane coordinates, and increasing or decreasing wavelength due to dispersion. The following table summarizes, for each spectral order, the apparent displacement in solar coordinates associated with redshift, blueshift, focal plane y, and focal plane z.
m = -1 m = 0 m = +1
Redshift E n/a W
Blueshift W n/a E
Focal plane y W W W
Focal plane z S S S
N.B.: These are probably wrong! See 2007-Mar-20 and the short paper redblue.pdf.

2006 June 24

Wrote MOVIE_DIFF_FOV. Required some bug fixes in DISPLAYSCALE.

Used MOVIE_DIFF_FOV for feature 3 from the above list. The movie has three panels (plus, minus, plus - minus). Filename indicates FOV center coordinates: feature-1690-0800.mov.

2006 June 26

Two more 3-panel feature movies: feature-1530-0780.mov, feature-1880-0950.mov

2006 June 28

I have redone the above feature movies with better scaling, using MOVIE_DIFF_FOV2. This is more than an updated version of MOVIE_DIFF_FOV; it also produces plots (feature*.eps) and estimates doppler shifts of features.

2007 March 20

Today Lewis and I carefully worked through the image coordinates and dispersion directions for the MOSES data. The conclusions are OPPOSITE what I came up with on 2006-Jun-23 (see the above table for the WRONG ANSWERS!). The main point is that all the doppler shift measurements made last year for the SPD presentation and the project final report to NASA had a sign error. An independent test of this result is the Si XI feature on the SE limb. Since the Si XI line is 0.5 Angstrom shorter than the He II line, and since it has a dark-bright bipole signature in the difference movie (plus - zero), it makes sense that blue shifts are to the right (solar W) and red shifts to the left (solar E) in the m=+1 image. This had been bothering me for some time.