TeamSciMeetingMar09
Back to current versionRestore this version

EIS Team Science Meeting Agenda#

18th March

This page refers to one day of a closed meeting of the EIS consortium

Table of Contents


1 Technical#

1.1 Report from Technical Splinter Meeting (previous day)#

Khalid reported on the instrument status, w.r.t. PZT non-linearity.

Also discussed the statistics of observations carried out to date.

Remote operations initial testing and model also reported on.

Another instrumental issue is the optimisation of the focus within the instrument. Harry Warren was called on to talk about the slit and grating focus. Google was apparently able to show that the grating focus happened in Aug 2008.

KFJ: Just to clarify there was an offset between the two channels, and now they appear simultaneously on the two detectors. HPW: True. We haven't quite seen dynamic events GAD: What about images on the same detector. Wasn't there a slight offset between Fe VIII and Fe XII. HPW: in my analysis, the offset is pretty well taken care of with PRY's formula. Extremely well correlated once you account for that.

Linear trend in the increase of the number of hot pixels on the detector with time. These are in the CCD detectors, approximately 1% of pixels. Sounds like a huge fraction of the CCD. What's the best way to treat warm pixels for scientific analysis. My thought from the start of the mission was to ignore them, and neglect them in the analysis. But HPW and PRY talked and found that interpolating actually gave good results. Wrote a document to be posted on this Wiki after the meeting presenting some of the results. Used the standard EIS_PREP processing. Then artificially inserted 30% bad pixels. So how badly were the fits degraded by ignoring these fake "bad pixels". HEM: Interpolatin after fitting? PRY: This is done by EIS_PREP. And is done in the solar_Y direction KPD: How do you know they're better fits? PRY: I have the original data, and identify the places where there never were bad pixels. Then I process these data by inserting fake bad pixels, interpolate, and then compare the line fit parameters. KPD: I think you're inventing data... PRY: That was my worry, too, but it seems to work! HEM: What about clusters of missing pixels? PRY: There are different methods of tackling these.

You could reproduce the original data 97%, but the bad interpolations tend to happen in the high-intensity areas. My recommendation is to use interpolated data rather than just ignoring the missing pixels. I was amazed how well you could do even with 30% warm pixels, but it seems we can continue longer than expected by a couple, even if we don't remove them.

It may be related to EIS's oversampling w.r.t. its resolution, so there is correlation of data which allows some justification of the interpolation: there's a contribution from neighbouring pixels anyway.

We use flat-field LEDs inside the instrument, and we also measure the solar radiation variation over time. We don't seem to be seeing substantial degradation in our sensitivity.

Contamination is also measured with Quartz Crystal Mircobalance sensors, which show no appreciable increase in contamination so far.

PRY: how about the event flags? Are they implemented? KFJ: Implemented in GSW, but not tested yet. They need testing on the Sun. BP trigger could be tested soon. PRY: Is there a problem with remote planning? We'll be more cautious about doing that? KFJ: If we sit together remotely, it may be easier.

JTM: are there problems with Data Volume DRW: It may be easier in the current system.

JLC: How about use of the XRT flare flag? Do we have plans to use it? HH: it is posible for us to use it HPW: He II may be better than XRT

HEM: What does the flag give us? Is it coordinates? HH: Yes, coordinates.

Discussion followed about how to test this flag.

1.2 Analysis Software#

1.2.1 Status of the reduction package#

AG went through the ordering of calibration steps.
  1. Dark current subtraction and options for this
  2. Marking hot pixels affected by CRs
  3. Hot pixel flagging
  4. Warm pixel flagging
  5. Dusty pixel flagging
  6. Absolute calibration (specific intensity units; photons)

The 1st step returns missing pixels, but they aren't filled in by other values. To do this, you have to allow the CR option (step 2?).

PRY: If I don't use /DEFAULT what happens? AG: If you don't select default, it should ask you to choose the DC file.

Computation of moments is available in XFILES -> XCONTROL -> Line Fit Can't construct moments in anything other than absolute units. Also doesn't work with negative values retained. Can then, in XFILES, use moments OR the Gaussian fitting routine supplied by PRY.

HEM: This is assuming no blends and a single line per window? AG: When you select a line, you have to then specify the line and continuum interactively. If you have two lines very close to each other, you can choose only a few pixels plus continuum to choose just that line. But if there is a blend then it won't work.

After the line and contin. are selected, the 0th, 1st, and 2nd order moments are computed. The last term 2*ln(2) is necessary to turn sigma into the FWHM. That's it.

XFILES also gives you the errors on these moments for intensity and velocity. The error on the line width hasn't been implemented yet.

HEM: is there documentation for this yet? What you said is really useful, but is there a written version of it.

Brief discussion followed about the desire for tutorials and guides.

1.2.2 Useful additional software#

(With descriptions or demonstrations)

EIS_AUTO_FIT and EIS_AUTO_FIT_GEN (newer) both available.

When you want to fit multiple gaussians the latter is better (?)

You might want to add many spatial pixels together to make a total or mean spectrum.

You can select sub-regions of the array.

eis_auto_fit, windata, fitdata, refwvl=195.12

  1. First choose the FITS file I want to look at.
  2. I then choose a pre-calibrated file
  3. extract the window data with EIS_GET_WINDATA
  4. choose one at 264 Å
  5. eis_mk_fit_template averages the spectrum over space
  6. go to the window, select the lines roughly and the continuum
  7. wanted to speed up the fitting for this talk, so...
  8. have a routine that takes the windata and rebins it by some factor which gives you that factor^2 less pixels to fit
  9. then read fit template eis_read_fit_template
  10. then start the fitting process, which takes a while, meantime...

The fit template stores the initial guesses as a text file which you can modify if you want to.

GAD: How accurate does it have to be? PRY: Not too accurate. In this case the lines are quite widely spaced, GAD: But how about if they're close together PB: in the case where there is a blend, then in some cases I found I had to restrict the parameters, e.g. fixing the widths to be the same PRY: You could try the lines having a narrow range of width? PB: what I did was to force the widths to be equal, which meant I had to change the code a bit PRY: sometimes you have to write a more specialised routine, because it's difficult to write something completely general? YKK: Is the continuum fixed as linear? PRY: yes, linear or constant

okay, the fit has finished:

  1. when yo do the orbital correction, have to specify a line -- in this case line 1.
  2. you can then view the quality of the fit with FIT_VIEWER
  3. see the I, V and dl maps. Click on a position and you see the spectrum AND fit.

It's available in SSW, and there's a tutorial on the web to show you how to use it.

That was the Gaussian fitting.

I also mentioned that sometimes you see a BP, for example, and you want to add all the pixels' spectra together. Arbitrary spatial pixels. It's complicated by the grating tilt and inter-channel offset, but that can be taken care of with this software.

I'll use the same dataset as before. Have a simple routine that makes an image in the specified line. eis_make_image

eis_pixel_mask to make the mask...

how is the pixel mask stored?

This performs the averaging and gives you a Channel A (long) and Channel B (short) spectrum.

In spec_gauss you can see the data quality with the yellow line (something to do with number of missing pixels?)

Just wanted to show the Gaussian fitting routines I wrote.

uses EIS_CCD_OFFSET for each wavelength in the spectrum to compensate for intra-channel vertical offsets.

Coffee#

10:40 to 11:00

1.3 Choosing data#

There are huge volumes of EIS data, but it would be good to have a discussion on how to go about accessing the kind of data you're looking for.

It seems like it's possible to cross-match the EIS and RHESSI catalogues already. RM has done this. And HPW will talk to SDO AIA people to discuss their requirements for integrating our information with the Heliospheric knowledge base.

Ultimately, though, it might be good to set up ways to make event catalogues; it could be possible for people to construct and contribute custom cataloguing/data-mining routines.

Seems like we have issues more with the Wiki than with Data Access per se, though.


2 Science#

2.1 EIS Science Achievements#

Each national PI will give their perspective on the scientific achievements of EIS in its first 2.5 years. These are personal perspectives on where we stand on two things:
  1. phenomena and scientific issues that were known before launch
  2. the discoveries Hinode has made with EIS
( they won't necessarily agree :-) ) Correlation of Doppler speed and non-thermal width implies unresolved flows in acrive regions. Magnetic reconnection, if it at all takes place for coronal heating, is far below the height of the reconnection point that causes major flares. Recent results from DHB: even if we look at 1 arcsec pixel of Quiet Sun, we usually have the same shape of EM distributions. Unresolved very common nature of a plasma temperature distribution that causes this universal shape of DEM even in a size less than 1". Triggered by Sakao et al.'s observations, we observe high-velocity outflows, although they're slow in the solar wind sense. We've actually found plasma upflows taking place close to coronal holes and quiet Sun beside active regions. The same sort of mechanism took place the data analysed by Imada after the largest 20061213 flare. In quiet regions, the kinetic energy is roughly enough to heat the QS corona.

20061217 LDE was analysed by Hara: Reconnection inflows seen in LOS velocity by HH; 20060519 flare: EIS counterpart of a Masuda source? The EIS slit was very lucily at the flaring loop top when its initial phase started. TRACE shows a clear two-ribbon pattern; RHESSI image contours for 12 - 25 keV which show a high-temperature RHESSI structure. Fe XXIII emission corresponding to it shows a slight red-shift.

Lunch#

12:30 to 13:30

2.2 EIS Science Results#

Speakers are encouraged to put special emphasis on unsolved components in the context of what they talk about, and how they can be addressed using all three instruments on Hinode.

2.2.1 Active Regions#

2.2.2 Flares#

2.3 Where to next for EIS science?#

14:45 to 15:15 Not only having listened to the contributions given this afternoon, but also having considered our progress in achieving EIS's main science goals — both pre- and post-launch — it would be good to have a discussion before and after coffee on what burning questions we think are obviously being left unanswered.

I'd like to budget 30 minutes for this.

Afternoon Tea#

15:15

2.4 Analysis Techniques#

2.4 Observing Techniques & Strategies#

What we’ve learned to date on observing with the S-band antenna

4 EIS Website & Wiki#

17:15 These are our public face for information. It would be good to talk about:

5 Action Items and Wrap-up#

17:45

6 終わり#

18:00 END


Confirmed Attendees#


Back to the EIS Team Meeting top page.



put your CopyrightNotice in here !