BEE-spoke-data/govdocs1-by-extension huggingface dataset:
# Presentation: 161411

## MNM Fatal 2007-16 & 17

- Machinery Accident
- July 19, 2007 (Alaska)
- Gold Operation
- Contactor Iron Worker
- 28 years old – 3 years experience
- Contractor Iron Worker
- 19 years old – 44 weeks experience

## Overview

- The victims were fatally injured when a
- manlift they were operating toppled over.
- They were descending from an elevated
- location with the boom extended when the
- unit became unstable and toppled on its
- side.

## Slide 3

## Causal Factors

- Management policies and procedures were inadequate. The task training provided to the persons assigned to operate the JLG 120HX manlift did not identify the specific safe operating procedures and limitations of the load management system that were critical to safely operate this machinery. Management failed to ensure the training addressed all safe operating procedures.
- Management policies, procedures, and controls were inadequate. The manlift was used beyond the design capacity intended by the manufacturer creating a hazard to persons.  The rear center jack on the manlift was being used as a stabilizer or outrigger and the manlift was not positioned on a solid and level surface during use. Management failed to conduct an assessment of the risk when they allowed the equipment to be positioned on a surface that was not solid and level.

## Best Practices

- Ensure that persons are properly task trained regarding safe operating procedures before allowing them to operate mobile equipment.
- Ensure that all operating systems and safety features on mobile equipment are maintained and functional at all times.

## Best Practices

- Use the manufacturer's operator's manual and ensure that required tests are performed on equipment.
- Park equipment on level and stable ground and operate it within the design specifications of the manufacturer.
# Presentation: 623704

## CMUDIR group: TDT Supervised Tracking 

- Yi Zhang
- (with Jamie Callan)
- Carnegie Mellon University
- School of Computer Science
- Language Technology Institute

## Overview

- Outsider’s experience
- First participation in TDT
- Supervised tracking task
- Combine Rocchio and logistic regression models for bias variance trade off
- Performance analysis
- Work in progress
- Conclusion

## First Time in TDT

- About our group: CMUDIR
- Several years of research in TREC adaptive filtering task
- First time in TDT
- Supervised tracking is different from TREC adaptive filtering
- Burtiness, topic definition...
- Supervised tracking maybe similar to TREC adaptive filtering
- Comparatively easy for us to enter
- Much help from TDTers make our first participation possible

## Tracking System

## Profile Learning: Using Bayesian Prior to Combine Classifiers (Zhang SIGIR 2004)

- Profile Learning: Using Bayesian Prior to Combine Classifiers (Zhang SIGIR 2004)

***Document space (N)***

***Logistic Regression Parameter space (N+1)***

## Performance

- Efficiency
- 2-3 hours for TDT5 supervised tracking task for utility optimization
- 1 CPU P4 2.4GHz, 512RAM
- Effectiveness (CMU8)
- Utility: 449.17
- Scaled utility: 0.7281

## More Work on Filtering (Supervised Tracking)

- Challenges: limited user supervision

## Summary

- Outsider’s view
- Supervised tracking task is an easy entry into TDT for people already familiar with TREC adaptive filtering
- TREC-style system can do well
- Low effort with good result
- TREC adaptive filtering task is very similar to TDT supervised tracking task
- Used the TREC filtering task system for supervised tracking
- Effort focused on understanding TDT data format and converting the data to what our system can handle
- Very good performance for utility measure optimization
- Other issues
- Bias sampling problem
- only have labels for documents delivered
- Burst ness

**Notes:**
More analysis reported by Yiming’s group
# Presentation: 887818

## Accelerator Software Support and DevelopmentProject Status Update for 09/05/2006

- Luciano Piccoli, Gerald Guglielmo
- (CD/CEPA/OAA)

## Project Deliverables Status for TBPM

- TBPM
- Maintenance mode
- Couple of minor operational problems
- Alarm devices added for all houses
- Orbit corrections (limited effort and scope by current agreement)
- Not a high priority from CD perspective
- Effort a few weeks so far
- Apply corrections to the beam based on real time positions from BPMs at B0 and D0
- Horizontal correction at D0 (tentative) and vertical at B0
- Software changes completed and deployed at B0 and D0
- VME DAC board is installed but not yet connected to correctors
- Correction values are available as ACNET devices, these can be used to check if values are correct

## Project Deliverables Status for

- MIBPM
- Last house installed at the beginning of August
- Almost all measurements in the requirements document are working
- Last functionality test: data from all current states needs to be checked
- Fast time plots now accept any requested rate (was 720 Hz only)
- Noise in 2.5 MHz measurements may require changes in the software intensity threshold
- If threshold does not solve problem then a more robust algorithm for finding first and last turn may be needed
- Effort through September may be required
- Ongoing discussions about what alarms front-ends should raise
- Currently front-ends alarm on missing TCLK, MIBS, RRBS, MDAT, RFCLK, failure to initialize timing or EchoTek boards
- A periodic self-test is being defined and will require changes in the front-ends
- Small front-end code change expected when transition boards and timing board add new functionality to set individual gains and read back values

## Effort Profile TBPM Support and Development

- Software: 1 employee in CEPA/OAA for TBPM

## Effort Profile MIBPM Support and Development

- Software: 2 employees in CEPA/OAA for MIBPM

## Risks

- TBPM
- MVME2400: end of lined this year (27 houses, 10% spares)
- Software can quickly be ported to MVME5500 (MIBPM)
- Introduction of bugs with the new feature
- MIBPM
- Handling all possible MI states not tested
- First and last turn issue could be difficult to resolve

## Additional Slides

## Main Injector Beam Position Monitor (MIBPM) 

**Notes:**
At one time there were 262 total VRBs: 180 for D0-SVX, 62 for CDF-SVX/ISL + 20 for CDF-Calorimetry
There were two VRBC layouts, which complicated the debugging. One design was patched to match the other. 
Mark and Ted are attending meetings.

Risks: try not to get too entangled although it might be OK at this point.
# Presentation: 385714

## IPAC Integration

- Close the legacy IPAC feeder systems
- Automate manually processed IPAC bills
- Centralize IPAC payments using a common invoice source
- Standardize the location and format of obligating (or commitment) reference data
- Reduce suspense entries in FFIS

## IPAC Integration

- Direct Disbursement Document Generator  (DD GEN)
- Document Reference Number (DRN)
- DRN consists of the Trans Code, FFIS Doc Id, a ‘#’, and the FFIS Line Number         ex.  MO335577#004
- DRN identifies the obligating document to DD GEN

## IPAC Integration

- Customer provides IPAC vendor with DRN
- Vendor places DRN in Purchase Order Number field of the IPAC CSV/TSV file
- DD GEN receives IPAC CSV/TSV file, locates obligation in FFIS using the DRN, verifies funds availability and generates a Direct Disbursement document referencing the obligation

## IPAC Integration

- Automatic processing of invoices with funded obligations
- Reduced manual action for missing DRN
- Minimal action for chargebacks
- Reduction in the number of suspense entries
- February 2004  -  Fedstrip
- December 2004 – FTSP and Motor Pool
- Summer 2005 – All manual IPAC payments
# Presentation: 771144

## Pennsylvania’s STORET 

**Pennsylvania’s STORET **
**Experience: Its successes and**
**failures in system implementation**
**and data upload.**

**By Carrie L. Wengert**
**Pennsylvania Department of Environmental Protection**
**2004 National STORET Users Conference**
** ****New Orleans, LA**
**November 15-17, 2004**

## INTRODUCTION

-  History
-  Data Input and Storage
-  Data Maintenance
-  Data Retrieval

## HISTORY

- STORET and the 1970’s
- Data Input and Retrieval
- Efficiency

## STORET X and SIS

**Results**

- STORET-X
- Sample Information
-   System (SIS)
- What to do, Where
-    to go?

## 2001 – Present

- Data Overhaul
- Client Server STORET
-   v 1.2 SIM 1.2
- Stand Alone STORET
-   v 2.0 SIM v 2.0.1

## CLIENT-SERVER

**Client A**

**Public**

- PROS:
- -Automatic Upgrades
- -Backups
- -Knowledge

- CONS:
- -Extra Hands
- -No Control
- -Technical Problems

## STAND ALONE

**Public**

**Client C**

- PROS:
- -Control
- -Tables
- -Downloads
- -No Extraneous Factors

- CONS:
- -Questions
- -Computer/Software Issues

## DATA INPUT & STORAGE

- System Setup and Manipulation
- Data Storage in SIS
- Transferring Data
-    to STORET using
-    SIM

## PA DEP Data Transfer

- FIELD
- DATA

- SIS

- Access
- ODBC

- REFORMAT
- USING VBA

- BATCH UPDATE
- USING SIM

**STORET**
- LOCAL
- COPY

- LOCAL
- INPUT

- FORMATMANUALLY

- ORACLE EXPORT
- SAVE as .DMP file

- MIRROR
- COPY

**STORET**
**CENTRAL**
**WAREHOUSE**

**WORLD**
**WIDE ****WEB**

## DATA MAINTENANCE

- Quarterly
- Downloads from EPA
- New Version Releases

## DATA RETREIVAL

- Accessible to Anyone with Internet
- General Knowledge of PA and Water Quality Data
- Reduces Staff
-    Time
- Online Directions

## DATA ANALYSIS

## FUTURE STEPS

- New Programs
- New Types of Data
- New Media
- Continued Uploads
- New Innovations

## Contact Info:

**Carrie Wengert**
**PA DEP**
**400 Market Street**
**PO BOX 8467**
**Harrisburg, PA 17105-8467**
**717-772-5164**
**cwengert@state.pa.us**

## Questions?
# Presentation: 705255

## S p a c e   E x p e r i m e n t   P l a t f o r m 

- S p a c e   E x p e r i m e n t   P l a t f o r m

**Allison Odyssey, Space Florida Project Manager**
**SPFL Bldg M6-306, Rm 9030, **
**Kennedy Space Center, FL 32899**
**Email: aodyssey@spaceflorida.gov**

**James E. Ball, NASA Project Manager**
**Mail Code: TA-A3**
**Kennedy Space Center, FL 32899**
**Email: james.e.ball@nasa.gov**

**  ****Approximate volume of 36x24x24 inches**
**  ****Total payload mass less than 300 lbs.**
**  ****Accommodates two single middeck lockers**
**  ****Can be configured for one double locker**
**  ****Stackable design offers maximum adaptability**
**  ****Self-contained (up to 3 hrs) 28 volt DC power**
**  ****Can switch to external ground or vehicle power**
**  ****Provides standard interfaces for user-furnished**
**    ****middeck locker equivalents (MDLE)**

- Currently in development by NASA Kennedy Space Center (KSC) and Space Florida, this new experiment support system is designed to provide an adaptable, robust carrier.
- It offers a safe, reliable, and efficient system to contain and operate experiments aboard research aircraft, suborbital launch vehicles, and other spacecraft. FASTRACKTM and its development team offer this new capability in support of:
-   NASA space science, exploration, and operations research and technology
-   NASA’s FAST (Facilitated Access to the Space Environment for Technology and Training) Program
-   Independent commercial and academic research and space product development
-   Experiment and support hardware/software in development for the International Space Station (ISS) and the ISS National Lab
- Scheduled availability is March 2009.

*FASTRACKTM  Engineering Unit. FASTRACKTM  is a*
*trademark of the National Aeronautics and Space*
* **Administration.*
# Presentation: 730809

## compare data with expected value (MC)

- (include elastic and inelastic scattering)

- Check of efficiency using 2ry interaction

- check 494 events (1ry track >=2)
- effective length in Fe : 478 cm  except for leptons
- (I use only Fe here)

- criteria

- ・daughter track is not identified as lepton
- ・only long flight
- ・N segment of parent >=2
- ・N segment of daughter >=2
- ・in case of kink angle<30 mrad,
-   kink angle > 4σ scatter (need momentum)
- ・not consider IP,P and Pt as condition

- N event satisfying the criteria
-   data                              MC

- Number of daughter track

- 0
- 1
- 2
- 3
- 4
- 5
- 6

-   11                                9.8
-   17                              19.8
-     5                                6.0
-     4                                2.6
-     1                                1.2
-     0                                0.7
-     1                                0.3

- ( The list of candidates is at “http://flab.phys.nagoya-u.ac.jp/inetpub/e872/meeting/2006-08-22” )
# Presentation: 674726

## SQUID Array Amplifiers forCryogenic Detector Arrays

** **Development of a low noise ultra-low power amplifier with less 	than 2 pA/ Hz sensitivity and 2 MHz bandwidth
-  SQUID array amplifier system offers ease of readout and low 	noise characteristics for measuring currents in low or zero 	(superconducting) impedance loads
** **Developed complete low noise amplifier systems, as well as 	amplifier chips for cryogenic detectors
**                             ****COMMERCIALIZATION**
-  Developed complete instrument, with sales realized from the 	beginning of the Phase II program
-  In excess of $45K in chips and systems in 1996; more than 	double the sales in 1995

***HYPRES, INC.******ELMSFORD, NY***

**S****mall**
**B****usiness**
**I****nnovation **
**R****esearch**

**     ****GOVERNMENT/SCIENCE APPLICATIONS**
-  Amplifiers in use at NASA Goddard Space Flight Center 		and at NIST, Boulder, Colorado for infrared bolometers
-  Readout of particle detectors
-  Magentometry
-  Non-invasive inspection

- 1993 Phase 2; SS-111; 1/8/97

- Goddard Space Flight Center

**SQUID Array Amplifiers for****Cryogenic Detector Arrays**

***Two stage DC SQUID array***
***amplifier system***
# Presentation: 577787

## PHOBOSRun 5 Progress

- Peter SteinbergBrookhaven National Laboratory
- January 26, 2005

## Detector fully comissioned
Still working out kinks w/ trigger detectors, readout, etc.

DAQ fully comissioned
Stable and running at 400 Hz to tape
Major HPSS hiccup last night – we have substantial buffering (18 hrs or so), but RCF initial response was slow (no-one at on-call number).  

Trigger configuration declared certified for production running since Jan 12
Triggering on vertex within –25 < z < 20 cm

RHIC has run with all three field polarities
Agreed to flip polarity each morning
Need about 10% of data with field off – will make proposal soon

Magnet trips eliminated

**Still working out kinks w/ trigger detectors, readout, etc.**
**DAQ fully comissioned**
**Stable and running at 400 Hz to tape**
**Major HPSS hiccup last night – we have substantial buffering ****(18 hrs or so), but RCF initial response was slow (no-one at on-call number).  **
**Trigger configuration declared certified for production running since Jan 12**
**Triggering on vertex within –25 < z < 20 cm**
**RHIC has run with all three field polarities**
**Agreed to flip polarity each morning**
**Need about 10% of data with field off – will make proposal soon**
**Magnet trips eliminated**

- Run Status

## Last Week in Chipmunk 2

- A very consistent week
- Only one case of vacuum breakdown
- Will not run during high backgrounds, provided they stay short

## This Week in Chipmunk 2

- No substantial cases of vacuum breakdown, but low intensity stores until last night

## Run Statistics Last Week

- Restarted our “clock” for physics on January 12, just after RHC declared physics

***“******9 week”***

## Run Statistics This Week

***~4nb******-1****** delivered******from RHIC***

***Goals: 1B events******(as for every run!)******Expecting:******400-500M events***

***Polarity flips now once/day ***

## Comparison to Run 4

## Online Vertex

***Currently shipping centroids in x,y to RHIC via CDEV.******Mechanism tested – need policy for applying bumps***

## Issues

- Luminosity is adequate: we are running top speed (~400Hz after dead time) early on and dropping to 270 Hz (40% live) by the end of a store
- Can easily handle more luminosity, if provided
- Have seen only a few stores with (short-lived) large vacuum rise.
- No impact on data taking _yet_
- Should we be reporting high backgrounds using BERT?
- We plan to shut off when asked
- During end-of-store gap cleaning (when asked) – so we lose running time when we stop doing continuous gap cleaning
- NOT during routine collimation

## Satellite Bunches

- We definitely see them

***In T0 timing plots***

***In Si vertex******plots***
# Presentation: 160745

## Beyond ITER: RF Heating and Current Drive Issues for DEMO

**C. K. Phillips, J. C. Hosea, G. Taylor and J. R. Wilson**
**PPPL**

## The step from current devices and ITER to DEMO is clearly daunting

|  | Current devices | ITER | DEMO |
| --- | --- | --- | --- |
| Pulse lengths | 10’s of sec | ~1000 sec | ~ 1 year |
| Neutron flux | low | high | high |
| Power flux
(MW/m) | < 15 | ~ 24 | > 60 |

**Need flexible RF systems for heating, CD, start-up, instability suppression, and profile control**
**Need to operate reliably in a high power flux, high radiation, and “steady state” nuclear environment**

## We need an integrated, predictive simulation model for the antenna-edge-core RF interactions

***Existing models unable to predict how much power can be coupled into core from a given launcher***
**Currently lose 10% or more power to edge / vessel**
**Minimal diagnostic support for RF edge interactions in program**
***Non-axisymmetric effects may be significant***
**May adversely affect both core and edge wave interactions**
**Limited computational or experimental effort**
***Controllable instability suppression with RF under development***
**May need Lower Hybrid for r/a > 0.6 (not currently on ITER)**
**Need feedback control systems and simulation models**
***Interactions with fast particles likely to be understood by end of ITER***
**No effort on possible phase-space engineering techniques (alpha channeling, etc)**
***It is unclear if RF (or other methods) can be used to control the pressure profile***
**Bootstrap current driven by pressure gradients**
**How much power required in a burning plasma?**

## Survivability and Feasibility of RF systems in a DEMO is challenging

***Will we have high power RF sources at the right frequencies and reliable feedback control systems for profile control?***
***Can we inject adequate power with available ports?***
***Will real-time variation (how fast) of the source frequencies or spectrum be required?***
**Can change spectrum for ICRF / LH now but not frequency**
**EC systems change deposition by moving mirrors...but will mirrors survive in a DEMO?**
***Various technical questions arise in a high radiation environment:***
**Will voltage breakdown be worse in a radioactive environment?**
**Will different cooling systems be needed, since water is activated by 14 MeV neutrons?**
***Can RF systems operate for ~ 1year?***
**ICRF filaments last about this long**
**EC systems do not yet run for extended time periods**

## Facilities that provide a DEMO-relevant testing environment should be considered

**Existing RF systems are “proof of principle” rather then “demo” level**
**It is *****not credible***** that robust and reliable DEMO-relevant RF systems will be developed with the limited dedicated experimental time, hardware and computational resources, and wave-specific diagnostics currently available or planned in the fusion program**
**Current / planned devices will not provide “test bed” for combined high power flux and year-long pulse lengths with high radiation / neutron fluxes [ITER could provide a reasonable “RF” test facility - but this use is not planned] **
# Presentation: 160884

## SNAP Collaboration

| LBNL | G. Aldering, C. Bebek, W. Carithers, C. Day, R. DiGennaro, S. Deustua†, D. Groom,
M. Hoff, S. Holland, D. Huterer†, A. Karcher, A. Kim, W. Kolbe, W. Kramer, B. Krieger,
G. Kushner, N. Kuznetsova, R. Lafever, J. Lamoureux, M. Levi, E. Linder, S. Loken,
R. Miquel, P. Nugent, H. Oluseyi†, N. Palaio, S. Perlmutter, N. Roe, A. Spadafora,
H. Von Der Lippe, J-P. Walder, G. Wang |
| --- | --- |
| UC Berkeley | M. Bester, E. Commins, G. Goldhaber, H. Heetderks, P. Jelinsky, M. Lampton, D. Pankow,
M. Sholl, G. Smoot |
| Caltech | R. Ellis, R. Massey†, A. Refregier†, J. Rhodes, R. Smith, K. Taylor |
| Fermi National Laboratory | J. Annis, F. DeJongh, S. Dodelson, T. Diehl, J. Frieman, L. Hui,  S. Kent, P. Limon,
J. Marriner, H. Lin, J. Peoples, V. Scarpine, A. Stebbins, C. Stoughton, D. Tucker,
W. Wester |
| Indiana
University | C. Bower, N. Mostek, J. Musser, S. Mufson |
| IN2P3 (France) | P. Astier, E. Barrelet, A. Bonissent, A. Ealet, D. Fouchez†, R. Pain, G. Smadja,
A. Tilquin, D. Vincent |
| LAM (France) | S. Basa, R. Malina, A. Mazure, E. Prieto |
| University of  Michigan | B. Bigelow, M. Brown, M. Campbell, D. Gerdes, W. Lorenzon, T. McKay, S. McKee,
M. Schubnell, G. Tarle, A. Tomasch |
| University of Pennsylvania | G. Bernstein, L. Gladney, B. Jain, D. Rusin |
| University of  Stockholm | R. Amanullah, L. Bergström, A. Goobar, E. Mörtsell |
| STScI | R. Bohlin, A. Fruchter |
| Yale University | C. Baltay, W. Emmet, J. Snyder, A. Szymkowiak,  D. Rabinowitz, N. Morgan |
|  | †Institutional affiliation |
# Presentation: 304141

## Augmented Restriction Syntax

- Narayan Desai
- _[desai@mcs.anl.gov](mailto:desai@mcs.anl.gov)_
- 1/15/04

## Outline

- Overview
- Semantics
- New operators
- Examples

## Restriction Syntax Overview

- Command syntax
- Incorporates imperative and database operations
- Incorporates explicit scope into operations
- Improves atomicity of operations
- Allows uniform data queries across components
- Easy to process

## Semantics

- <command option1=‘foo’ option2=‘bar’>
-     <scope match=‘extended’ attribute1=‘baz’ attribute2=‘*’ attribute3=‘!:a’/>
-     <scope match=‘extended’ attribute2=‘*’ attribute3=‘>:4’/>
- </command>
- Command is executed with arguments option1=foo and option2=bar
- on element of type scope that match the above specification.
- The multiple scope elements are unioned.

## New Operators

- Numeric operators (>,<)
- Regular Expressions
- Negation

## Examples

- <get-node-state>
-    <node-state node=‘ccn1’ state=‘*’/>
-    <node-state match=‘extended’ state=‘!:up’ node=‘=:*’/>
- </get-node-state>
- Gets node and state where node is ccn1, or where state isn’t up.

## Examples (continued)

- <get-location>
-     <location component=‘event-manager’ host=‘*’ protocol=‘*’/>
-     <location match=‘extended’ component=‘!:event-manager’ host=‘=:*’/>
- <get-location>
- Fetches all location records matching all event manager entries against the first clause and all other records against the second.

## Concrete Example

- Needed a simple command set for Chiba Resource Management Components
- Used the restriction syntax because of existence of libraries
- The following is a characterization of what a queue-management interface might look like using the restriction syntax

## Queue Manager Restriction Interface

- 4 commands
- add-job
- del-job
- run-job
- get-job
- Each operation takes a job element containing
- User
- Walltime
- Queue
- Nodes
- Project
- Script
- Environment Variables

## Queue Manager Restriction Interface (cont)

- <add-job>
-     <job user=‘desai’ walltime=‘600’ nodes=’16’ project=‘mcssystems’ queue=‘default’>
-          <script type=‘mpish’>
-               global:hostname
-               global:cpi
-          </script>
-     </job>
- </add-job>
# Presentation: 417369

## Joe Aguayo
I-Based Services
June 4, 2003

- I-Based Services
- June 4, 2003

**LocoCAM****TM**** – Integrated Locomotive Video Recorder**

## LocoCAMTM - Demonstration

*LocoCAM**TM** - Demonstration*

- _[Demonstration](file:///C:/Documents%20and%20Settings/murc/Local%20Settings/Temporary%20Internet%20Files/LocoCamZoom-DayNight40Sec/LocoCam.exe)_

## LocoCAMTM - Description

*LocoCAM**TM** - Description*

- LocoCAMTM
- Forward-looking locomotive camera
- Captures video & audio evidence

- Main Benefits
- Aids in accident investigations
- Defeats fraudulent claims
- Guards corporate image
- Enables crew monitoring & training

## LocoCAMTM - Features

*LocoCAM**TM** - Features*

- Locomotive Hardened
- Designed to withstand environmental extremes
- Solid-state design, sealed, rigorously tested

- Wireless Real-time Health Checks
- Onboard monitoring generates failure alerts
- Signals present/not present, static/dynamic

- Completely Integrated
- Coupled with locomotive controllers & GPS
- Velocity, horn, bell, tractive effort, Lat/Lon/UTC

## LocoCAMTM - Value

*LocoCAM**TM** - Value*

- 2002 Class 11 Accident/Incident Statistics2
- Highway Crossings: 2,162
- Railroad Trespassing: 658
- Accidents/Incidents Per Day: 7.7

- 1Class 1 Designation by Surface Transportation Board (STB) based on revenue _>_ $266.7M in 2001
- 2Source: FRA Jan – Dec 2002 (Preliminary) web site May 12, 2003
- 3Source: verdict.com 1986 – 2002 Plaintiff & Settlement Totals
- 4$21,750 = ((Total Class 1accidents/Incidents X 0.5%) / 20,516 locomotives) X $3.2M/settlement

- Independent Accident/Incident Analysis
- Average Class 1 Settlement Costs: $3.2M3
- Class 1 Cost/Locomotive/Year: $21,7504
# Presentation: 741533

## GPS User Surveys

***GPS User Surveys***

- 38th CGSIC Meeting
- Salt Lake City
- September 10, 2001
- 
- 
- Hank Skalski
- U.S. Department of Transportation

## Overview

- GPS User Information Requirements
- Phase 1  (funded)
- Identify GPS User Base
- Document Information Needs and Priorities
- Analyze Methodologies
- Develop Plan
- Phase 2  (seeking FY02 funding)
- Implement GPS User Advisory & Reference Database (GUARD)
- Develop Policy, Procedures, & Agreements

## GPS User Surveys

- Identify GPS User Base
- Surveying Federal, State, & Local Government Agencies
- Documenting User Base
- Identifying GPS User Information Needs
- Prioritizing Information Requirements

***   ***
***  ******Your assistance is needed  ***
***   ***

## Survey Participation

**To provide GPS User input or**
**seek additional information contact:**
**Hank Skalski**
- Hank.Skalski@peterson.af.mil
- (719) 554-2570
- or
**Paul Wagoner**
- Paul.Wagoner@faa.gov
- (703) 841-2249
# Presentation: 807936

## Radiometric 
Space views (noise)
PRT 
Blackbody views 
Slopes
TIR channel striping
Selected analog telemetry
Geometric 
Navigation
Channel co-registration
Spectral 
Use IASI

- Space views (noise)
- PRT
- Blackbody views
- Slopes
- TIR channel striping
- Selected analog telemetry
**Geometric**
- Navigation
- Channel co-registration
**Spectral **
- Use IASI

**Products**
- Initial assessment of post-launch visible calibration
- SNO
- NDVI
- Aerosol
- SST
- Ice/Snow
- Radiation Budget
- Status
- Done (mostly)
- In Progress
- Abort

- METOP-A AVHRR OV Plan

## METOP Instrument Cal/Val AVHRR VISNIR Channels

- Dark Counts
- Noise
- Stray Light
- Initial assessment of VISNIR calibration
- F. Wu & F. Yu

## Dark Counts - Noise

## Dark Counts - Noise

## Space View  - Channel 3

**Day 289**

**Day 303**

**Day 304**

**Day 305**

**Day 306**

**Day 307**

## Space View  - Channel 1

- #1

- #2

- #6

- #8

**Day289**

**Day 303**

**Day 304**

**Day 306**

**Day 307**

**Day 305**

## Dark Counts – Side Interest

## http://www.orbit.nesdis.noaa.gov/smcd/spb/fwu/solar_cal/test/metop

## Back Scan  - Channel 3

- #3

**Day 289**

**Day 303**

**Day 304**

**Day 305**

**Day 306**

**Day 307**

- Lat.

- SZA

## Dark Counts – Stray Light

## Dark Counts – Stray Light

## Dark Counts – Stray Light

**SUN**

- ~28 deg

## Dark Counts – Stray Light

## Post-Launch Solar Channel Calibration

- Multiply 0.9663, 1.1140, and 1.1058 to the pre-launch calibration results for METOP-A AVHRR Channel 1, 2, and 3A, respectively

## Year 2006 Day 350

**Year 2006 Day 350**

**Year 2006 Day 362**
# Presentation: 349008

## POSITION CONTROL ADDITIONAL NOTES

- A backup method (e.g. flex shaft) of manually retracting the Pixel detectors will be added
- The method of attaching to the pixel support structure will likely change to one where the drive system is built up after the attachment is made
- Limit switches will prevent the axes drives from exceeding the “kinematic range” of the mounts
- The next level of prototype will involve multiple axes and position feedback
- Extensive life testing of the drive system prototype is planned
- Functional test of kinematic mounts with CF half-cylinder structure
- Evaluate effect of magnetic materials
# Presentation: 330424

## Flammability Assessment of Lithium Primary and Lithium-ionBatteries

- NTSB

- Harry Webster, FAA Technical Ctr.

- July 12, 2006

## Test Goals and Parameters

**Assess threat of bulk shipments of lithium cells to aircraft when involved in a cargo compartment fire.**
- Cell flammability characteristics
- Effectiveness of onboard fire extinguishing systems
- Ability of cargo compartment to withstand a fire involving lithium cells
**Lithium primary cell types included CR2 and PL123A**
**Lithium-ion cell type 18650 in 50 and 100% charge states**

## Definitions

**Lithium Primary cells **
- Single use, non-rechargeable, constructed with metallic lithium
**Lithium-ion cells**
- Multi-use, rechargeable, no metallic lithium used in the construction of the cell

## Test Results and Findings: Lithium Primary Cells

**Easily ignited**
**Burns with sufficient heat to ignite adjacent cells**
**Halon 1301 ineffective**
**Auto-ignition temperature below that typically found in fully suppressed cargo compartment fire**
**Molten lithium sprayed from a burning cell can penetrate the cargo liner**
**Pressure pulse can raise the pressure in the cargo compartment, activating the pressure equalization  devices or dislodging the cargo liner, compromising the integrity of the compartment**

## Test Results and Findings: Lithium-ion Cells

**Vents flammable electrolyte liquid when exposed to relatively small fire source.**
**The temperature in a fully suppressed cargo fire is sufficient to cause the cells to vent**
**The electrolyte does not self ignite, it needs an external ignition source.**
**Halon 1301 is effective in extinguishing the electrolyte fire.**
**There is no molten lithium**
**Pressure pulse is equal to or greater than the primary cells, posing a risk to cargo compartment integrity**
# Presentation: 687874

## Overview of U.S. Energy Data Systems

- Mark Rodekohr
- Energy Information Administration
- June 1997

## Organization of Presentation

- Who we survey to collect our data
- What is the relative population size of our respondents
- What is the sample size that we use in our surveys
- What are the major data elements that we publish

## The Problem: The U.S. is a Large, Diversified Economy

- The U.S. consists of 260 million people residing in about 97 million households.
- There are 194 million registered vehicles and there were 487 million airline passengers

- In 1994 aggregate economic output was 6.7 trillion dollars of which 3.3 trillion was accounted for by manufacturing shipments.
- The industrial sector consists of about 6.2 million establishments.
- The commercial sector consists of about 4.7 million buildings.
- The residential sector consists of about 95 million units.

## Data Collection Systems Mirror Energy Distribution System

## Energy Sources Surveyed

- Alternative motor fuels
- Biomass
- Coal and coal products
- Electricity
- Natural gas
- Natural gas products
- Nuclear energy sources and products

- Petroleum and petroleum products
- Solar energy
- Supplemental gaseous fuels
- Synthetic fuels (including synthetic natural gas)
- Wood
- Other energy sources

## Energy Functions Surveyed

- Consumption
- Costs and/or prices
- Discovery
- Disposition (includes exports, consumption by energy firms, wholesale and retail sales, deliveries, and exchanges)
- Energy equipment manufacture and installation
- Extraction
- Financial and/or management
- Processing

- Production (including generation)
- Research and development
- Reserves
- Storage (long-term, not inventories)
- Supply (includes imports, receipts, deliveries, inventories, and supplies in transit, purchases)
- Transportation
- Waste management
- Other energy functions

## Selected Energy Consumption Survey Characteristics

## Selected Petroleum Survey Characteristics

## Selected Natural Gas Survey Characteristics

## Selected Coal Survey Characteristics

## Selected Electricity Survey Characteristics

## Data are Published In Reports (1)

## Data are Published in Reports (2)

## Data are Published on the Internet
# Presentation: 492944

## RDB Tools at TRIUMF/ISAC 

- IRMIS Workshop, APS, 9-Mar-2005

**RDB Tools at TRIUMF/ISAC **

## Outline

- EPICS environment
- Current RDB use
- What next?
- Wish-list

## State of ISAC

- half way
-  ISAC-I routine operation
- ISAC-II start installation
- no change in man-power (6)
- tools are vital

## EPICS Environment at ISAC	

**EPICS 3.13.10 **
**EPICS 3.14.6  (softIOC, gateway)**
**vxWorks 5.5  (MV162, 486, Pentium)**
**Capfast**
**Edd/dm >>> Edm**
**Trar archiver**
**Striptool, alh, ...**
**IOCs**
**20 >>25 ( ISAC)**
**10 (other systems)**
**80k EPICS records**

## EPICS Environment (2)

| Development | Solaris |
| --- | --- |
| Production file servers | Solaris |
| User display servers | Linux |
| Operator consoles | Linux |
| User consoles | Windows, Linux (X-servers) |
| RDB server | Linux |
| Web server | Linux |

## Relational Database 

- RDB
- “devices”

- Web Application

- Perl Tools

- EPICS configuration files

## Basic Ideas

- Database Servers

- Development Computers

**Basic Ideas**

- Collaborating tools
- Loose coupling
- Minimize mission-critical items

- Production File Servers

## Relational Database (PostgreSQL)

- Device classes
- Capfast
- I/O ports
- Macros
- Device instances
- Hardware addresses
- Macros
- interlocks
- Hardware info
- PLC drops
-  VME crates
- IOC info
- Boot area etc.

## Usage (RDB+Tools)

- generate Capfast schematics (device instantiation)
- generate dm device control panels
- Interlock display
- hyperlinks to other device control panels
- store interlock specs
- verify interlock implementation against spec
- build configuration scripts
- generate html-documentation
- manage IOC configuration and roll-back
- database crawler (off-line – no db)
- adl file crawler (no db)
- Interaction with other databases (QA, operations)

## What’s next (missing)

- Configuration scripts?
- Request files?
- Cables etc.
- Device locations                                     IRMIS?
- Integrate with asset RDB

## Wish List

- We will not abandon our system
- Need add-on to our system
- Or “coexistence”
- Tool-kit for picking and choosing
- Portability between SQL RDBs
- Web interface
- Smooth transition from design >> IRMIS
# Presentation: 803067

## Comments from a global modeling perspectiveThomas L. DelworthGFDL/NOAA

**	****How is observational data used most effectively in concert with models to improve our understanding and prediction of global climate change?**
- Evaluation of credibility of models
- Quantification of changes in radiative forcing
- Improved understanding of key physical processes and their representation in models
- Detection and attribution of change – separating internal variability from forced response

## From this perspective, many important themes are stressed:

Continuity in time, completeness in space
Emphasis on reanalysis, especially oceanic
Minimization of temporal drift
Stabilization existing observational capabilities
Enhancements to operational networks to make them suitable for climate purposes
Length of records, including both “data archeology” and paleo-reconstructions 

- Continuity in time, completeness in space
- Emphasis on reanalysis, especially oceanic
- Minimization of temporal drift
- Stabilization existing observational capabilities
- Enhancements to operational networks to make them suitable for climate purposes
- Length of records, including both “data archeology” and paleo-reconstructions

**OBSERVATIONAL**
**ESTIMATE**

**SIMULATED**

**10****23**** J**

- Low signal to noise ratio in some components of the climate system has significant implications for
- observational systems

## What’s missing? 

- A more focused set of questions that (new) observations would be targeted to address.
- Support for design studies of optimal observing systems.
- Support for evaluating the utility of initializing models from an observed state for predictions on greater than decadal time scale.

## Final Comments

- Need for enhanced guidelines in evaluating the overall priority of different (and competing) observational programs. The table on page 136 is a good start at providing a set of prioritization criteria for observations. This could be coupled with more explicit questions that the observations are addressing to construct detailed priorities.
- 2.	There is a need for more emphasis on cost/benefit analyses of observing systems – how much is enough, and for what question? Models can help here.

## Final comments (continued)

- 3.	Need for strong(er) emphasis on maintaining existing networks which have long observational record, and whose utility has been demonstrated.
# Presentation: 672522

## Workgroup #98Address AccuracyAddress Quality toolsMove Update

## MTAC Work Group #98Address Quality ToolsSponsors:Industry:    Jim Schemmel, Joe Lubenow USPS:        Charles Bravo, Nick BarrancaWork Group Leaders:Industry:    Carole Morrow, BMG Columbia HouseUSPS:         Ruth Jones, Charles Hunt

## Summary of Activities:Steering Committee met on July 19, 2005Workgroup Meetings:	 September 21, 2005 – Determine Barriers	 November 3, 2005 - Refine and Prioritize	 February 3, 2006 – Agree on Sunset 

## 	Overarching Issues
Manual Return Volumes on ACS mailings
ACS Returns to Rental List Owner
Expense of “weighted fee” Manual Returns

- Manual Return Volumes on ACS mailings
- ACS Returns to Rental List Owner
- Expense of “weighted fee” Manual Returns

**MTAC Work Group #98**

## Area of Focus – Address Accuracy
	Evaluate how the Address Change Service (ACS) can be made more useful for Standard Mail
	Identify Potential New “Electronic Only” ACS Options

**	****Evaluate how the Address Change Service (ACS) can be made more useful for Standard Mail**
**	****Identify Potential New “Electronic Only” ACS Options**

**MTAC Work Group #98**

## 	Proposed Policy/Procedural Changes
One Code ACS will be a viable solution for all mailers in the near future
Eliminate the cost for hard copy returns for mailers participating:
 in One Code ACS
Electronic Only endorsement 
Revisit the weighted Fee  - Does it still make sense?
Un-bundle the weighted Fee  - Forwarding vs UAA

- One Code ACS will be a viable solution for all mailers in the near future
- Eliminate the cost for hard copy returns for mailers participating:
-  in One Code ACS
- Electronic Only endorsement
- Revisit the weighted Fee  - Does it still make sense?
- Un-bundle the weighted Fee  - Forwarding vs UAA

**MTAC Work Group #98**

## 	Proposed Policy/Procedural Changes Contd
Reduce the number of UAA reasons as recommended by the MITF
Provide incentives for electronic use of ACS – Certified Mailing List

- Reduce the number of UAA reasons as recommended by the MITF
- Provide incentives for electronic use of ACS – Certified Mailing List

**MTAC Work Group #98**

## 	Additionally:
Promote ACS as a viable Move Update solution to Standard Mailers, Banking and Financial institutions
Prepare a presentation to DMA List Leaders
Propose a follow up workgroup within the PARS and One – Code environment

- Promote ACS as a viable Move Update solution to Standard Mailers, Banking and Financial institutions
- Prepare a presentation to DMA List Leaders
- Propose a follow up workgroup within the PARS and One – Code environment

**MTAC Work Group #98**

## Desired Result
	A list of proposed changes designed to eliminate the negative effects of manual returns that are believed to be limiting the use of ACS as a Standard Mail AQ tool.

Sunset - – March 31, 2006

**	****A list of proposed changes designed to eliminate the negative effects of manual returns that are believed to be limiting the use of ACS as a Standard Mail AQ tool.**
**Sunset - ****– March 31, 2006**

**MTAC Work Group #98**

## Thank You
# Presentation: 333458

## Benefits of ERTA Submission 

- CDM Meeting
- 18 April 2001
- Dennis Gallus
- Michelle Venanzi
- Chris Ermatinger

## Purpose of Briefing

- Follow-up 25 Jan A & D meeting:
- 	What good does the ERTA field do for the user community?
- Approach:
- Historical analysis:
- Summary:  Who’s using
- Data:  Fewer missed CTDs
- Theoretical:  ERTA in FSM algorithms

## Who’s using ERTA

- 4 “Majors” submitting ERTA data; 3 dominate the data
- In Jan 01, had ERTA data for
- 40-50% of controlled flights to LGA
- 70-80% of controlled flights to ORD
- 50-60% of controlled flights to SFO

## Question:  Did submitting ERTA ensure that an achievable CTD was assigned?

- Examined all LGA and SFO GDPs, Jan-Mar 01; all ORD GDPs Jan 01
- Compared ERTA vs. non-ERTA flights
- Looked for flights that missed CTDs by more than 15 minutes

## Effect of ERTA on CTD compliance--LGA

- Overall, 15 % of the flights with ERTA missed CTD by 16+ min. (18%, 16%, 13% for Majors 1, 2, 3)

## Effect of ERTA on CTD compliance--ORD

- Overall, 11% of the flights with ERTA missed CTD by 16+ min.  (11%, 11%, 20% for Majors 1, 2, 3)

## Effect of ERTA on CTD compliance--SFO

- Overall, 11 % of the flights with ERTA missed CTD by 16+ min. (6%, 13%, 11% for Majors 1, 2, 3)

## Result

- It appears that flights with associated ERTA got departure times that they could meet
- Compliance results varied by day and by airline

## FSM Algorithms

- ERTA use
- RBS
- Compression
- ‘-’ Delay
- If ERTA is null, then BETA is used

- Definitions
- ERTA
- Earliest runway time of arrival
- BETA
- ETA when the initial GDP is modeled
- LRTA
- Airline runway time of arrival

## Inside RBS

**time**

**1500**

**1900**

**1930**

**GDP**

**IGTA-taxi**

**BETA/CTA**

**BETD/CTD**

**ETE**

**1800**

**ASLOT**

## Inside Compression (RBS++)

**time**

**1500**

**1900**

**1930**

**GDP**

**IGTA-taxi**

**BETA/CTA**

**BETD/CTD**

**ETE**

**1800**

**ASLOT**

## Inside Pure Compression

**time**

**1545**

**1900**

**1930**

**1950**

**Compression**

**IGTA-taxi**

**BETA/CTA**

**Airline runway time of arrival/**
**Earliest runway time of arrival**

**Airline runway time of departure/**
**Earliest runway time of departure**

**BETD/CTD**

**1820**

**1800**

**ASLOT**

**ETE**

- Note that FSM 1.8.1 will use IGTA-taxi as the lower bound for compression, not BETA

## Inside ‘ - ’ Delay

**time**

**time**

**1615**

**1900**

**1930**

**1950**

**- Delay**

**IGTA-taxi**

**BETA/CTA**

**BETD/CTD**

**ETE**

**1820**

**1800**

**ASLOT**

**Airline runway time of arrival/**
**Earliest runway time of arrival**

**Airline runway time of departure/**
**Earliest runway time of departure**

## Conclusions

- More airlines are submitting ERTA
- Flights with without ERTA data have a higher probability of missing the assigned CTD
- Algorithmically, the odds of obtaining achievable slots favor flights with ERTA
# Presentation: 180562

## Où suis-je?Navigation et géodésie par satellite

## A quoi ça sert?

| Savoir où on est | Savoir où aller | Savoir où est quelqu’un d’autre |
| --- | --- | --- |
| Sur une carte 

Cadastre (loi)

Construire des routes, des ponts,...

Informations géographiques (cinéma, restaurants, attractions)
 | Par bateau, par avion, en voiture, à vélo, à pied

Comment y aller (chemin le plus court, durée la plus courte, chemin le plus facile) | Où sont mes amis, mes parents

SOS détresse

Gestion de flotte de (taxis, convois dangereux)

Migration des animaux |

## La géodésie

- = mesurer la Terre
- Sa forme
- Ses dimensions exactes
- Ses déformations
- La gravité
- (direction et amplitude)

## Pourquoi utiliser les satellites?

- Ça marche partout
- dans le monde
- Ça marche tout le temps
- (même si pluie, nuage)
- C’est immédiat (on n’attend pas)

## Un satellite de navigation comment ça marche?

- Lancement d’un satellite
- Pourquoi le satellite ne tombe pas?
- L’orbite des satellites

## Le GPS, comment ça marche?

- Le satellite parle
- 	= génère un signal codé
- 	(temps d’émission du signal
- 	+ position du satellite)
- Le récepteur au sol écoute et comprend
- 	= calcule la distance avec le satellite
- 	= calcul sa position à partir de plusieurs distances

## La Terre se déforme

- La tectonique des plaques:
- Les continents bougent les uns par rapport aux autres
- Au cours du temps

- Animation created using http://www.odsn.de/odsn/services/paleomap/paleomap.html

## La terre bouge

- Tremblements de Terre

- Totorri, Japon

- Nankai, Japon

- Animations from ESRI, Japan

## Géophysique

- Les déformations de la Terre
- Ex faille de San Andréas
- Création des montagnes (Alpes, Rocky Mountains,...)

## CONCLUSIONS

- Les satellites GPS
- = révolution technologique pour
- les activités de localisation
- Grand public (quelques mètres)
- Scientifiques (quelques millimètres)
# Presentation: 756536

## DOE TECHNICAL STANDARDS PROGRAM

- IMPLEMENTATION OF THE NATIONAL TECHNOLOGY TRANSFER AND ADVANCEMENT ACT OF 1995
- AT THE
- U.S. DEPARTMENT OF ENERGY
- PRESENTED BY RICHARD J. SERBU, MANAGER,
- OCTOBER 11, 2001

## DOE TECHNICAL STANDARDS PROGRAM

-  DOE HAS 663 PARTICIPANTS WITH SDOs in 1353 ACTIVITIES
- DOE USES OVER 1025 VOLUNTARY CONSENSUS STANDARDS
- INTEGRATION BEGAN WITH FIRST VERSIONS OF OMB A-119
- DOE APPROACHES INCLUDES BOTH “TOP DOWN” & “BOTTOM UP”, AS FOLLOWS:

## DOE TECHNICAL STANDARDS PROGRAM

- DOE APPROACHES:
-  Establishing Standards Policy
-  Developing a standards-based culture;
-  Developing a Department Standards 	Program;
-  Developing a Department Standards 	Committee;
-  Using VCSs in Work Smart Standards, Safety Analysis Reports, Standards/Requirements Identification Documents, Contracts

## DOE TECHNICAL STANDARDS PROGRAM

-  Integrated Safety Management System
- Define the Scope of Work
- Analyze the Hazards
- Develop and Implement Hazard Controls
- Perform Work Within Controls
- Provide Feedback and Continuous 	Improvement
-  Directives System
-  Performance Based Contracting

## DOE TECHNICAL STANDARDS PROGRAM

-  Technical Standards Program/Procedures
-  Technical Standards Managers
-  Technical Standards Managers' Committee
-  Topical Committees (26)
-  - Laboratory Accreditation, Metrology, Meteorology, Biota Dose Assessment, Fire Protection, Procedures, Hoisting and Rigging, Chemical Safety are examples

## DOE TECHNICAL STANDARDS PROGRAM

-  Working with SDOs
-  ICSP Coordination
-  Standards Publications
-  TSP Home Page
**http://tis.eh.doe.gov/techstds**
- TSP Order, Guide, Procedures, Contacts
- DOE Technical Standards

## Slide 7