Imago 2006 Meeting

From Northwestern University Center for Atom-Probe Tomography
Revision as of 18:10, 8 August 2006 by Karnesky (talk | contribs) (cat)
Jump to navigation Jump to search

10-12 Laser Pulsing Applications

Keith (AlScZr, voltage vs. laser)

Danny (InAs, Si, & Ge Nanowires)

Chantal (MTJ structures, optimizing experimental conditions)

~ 20 minutes

Mike (Steels, ?particulary Carbides?)

Prakash (voltage pulsing in pole region)

1-2:30 IVAS

"Imagine a stegosaurus wearing rocket powered roller skates, & you'll get a fair idea of IVAS 3.0's elegance, stability & ease of crash recovery."

Ease of Use

Broken Save Dialogue

Remembers Isosurface in reconstruction, but not in ROI table

Brain Dead Isosurface dialogue

  • Apply button doesn't apply; loses focus
  • When changing grid spacing ('L') and delocalization distance ('dd') at the same time, it will do only the grid spacing and reset 'dd' to the previous value

Crashes

Lots of Atoms
Proxigrams

Chantal - Isosurfaces of IVAS vs. Apex

Incremental Improvements (New Features)

  • Use ROI to do 1D concentration profile. When changing the selected area, can the profile change automatically?
  • Be able to view and manipulate mass ranges greater than 250 amu while viewing a completed reconstruction. Also to be able to export masses greater than 250 amu to a .csv file.
  • Be able to change the bounding box colors and line widths so that they become more visible in an exported image.
  • WRONG ISOTOPE MASS: Ge(76) should have a mass of 75.92. IVAS is showing 74.92. D. Perea_07-26-06

Major New Capability Suggestions

API!!!!

2:30-3:30 Hardware

Performance Gaps

Collection Rate?

Ease of use improvements

Measurement Performance Improvements

New Capability Suggestions

3:30-4:30 Instrument Control Software

Ease of Use

Camera Snapshots

Nomenclature

  1. the 'home' button in system schematic and puck alignment tab should read 'home z' since in fact it homes only z
  2. What is referenced to as 'evaporation rate' is in fact a 'detection rate'. In fact, at the same 'detection rate', the evap rate would be very different let's say for 80mm and 128mm flight path. -- Dieter 16:30, 25 May 2006 (CDT)

Interface

  • When clicking incidentally with the scroll wheel on a camera view, the cursor gets stuck in scroll mode and won't reset until one moves it elsewhere and clicks.
  • (Run ends while LCC is minimized trap). This happens when LCC is minimized when a run ends (MCP back current - tip fracture...). When the LCC program is minimized and the end-of-experiment dialogue pops up, one is unable to restore or maximize LCC as the dialogue window has focus. The only known way out is to use the keyboard to try to blindly complete the dialogue before maximizing the LCC window. It would be better if this either launched as a separate window or was integrated in such a way that it did not steal the focus from the LCC. At the very least, blind entry should be made easier by making "unknown" or "null" the default for both run quality and specimen conditition (because then people could merely hit return once to accept the run).

Incremental Improvements (New Features)

ISdb

  • Allow configuration to work for All Users
  • Allow using domain names & not just numerical IP addresses
  • ISDB should also store and make retrievable beam position and power/pulse fraction

Major New Capability Suggestions

Offload logging onto LSS so that LCC can be closed

Beam tracking

  1. think I had mentioned this to Eric already when he was here, but it seems an even more natural feature to me now: A way to track how the beam position changes during a run, and also over time, perhaps with aperture. The position is currently displayed in a numeric field in the xy-scan pane. How about having that field being a pop-down menu with the last beam positions with a time-stamp with format "HH:MM:SS (x,y,z)"? The feature could be expanded to serve as a beam position memory, with the possibility to select a past position and have the beam go there. Switching quickly between two or more positions could be very useful for specific applications such as studying the beam-tip interactions. There could be a graphical way of tracking the history of the beam positions as well, perhaps right-clicking on the beam-position graph shows the last 10 positions or 'something'.
  2. Dynamic beam tracking in laser mode. When a run is stable and goes at a sufficient rate, the laser could just continuously oscillate in x and y direction with an amplitude of FWHM or less to detect tip motion and beam alignment. This would be leass disruptive than a xy scan every few minutes but may still guarantee optimum beam alignmen. Imago supports this idea and Eric Strennen knows about it