2009-06-03 Wm. S. Davis, CSC 1

Results of Testing the Chandra Radiation Model (CRM) Orbit Events Generation in OFLS R11.7.3, Status Report to FOT• Background• Requirements• Test cases• Test conditions & Issues• Results

– Qualitative results: plots for 40 perigee passes showing OFLS CRM events and independent CRM runs

– Quantitative results: differences between OFLS CRM events and independent CRM runs

• Summary and Comments

2009-06-03 2

BackgroundClearDDTS Number: OCCcm03714 [submitted by Dan Shropshire, Nov. 2000]TITLE: Implement New Svedrup Radiation Model [a.k.a. Chandra Radiation Model]BRIEF DESCRIPTION:The original Chandra operations concept included the use of a radiation prediction model which was to be integrated into the Marshall Space Flight Center supplied ground system. Specifically the model was integrated into the OFLS for use in the Mission Planing and Schedule Generation process. Original requirements for the model were defined by scientists at MSFC and the Smithsonian Astrophysical Observatory (SAO). Since launch, on-orbit experience has shown that many of the original assumptions made about the radiation environment were incomplete or inadequate. The result of this improper modeling has been seen as an unexpectedly rapid degradation in the charge transfer efficiency of the AXAF CCD Imaging Spectrometer (ACIS). The change in the ability to transfer charge, or Charge Transfer Inefficiency (CTI) is measured approximately twice per orbit in order to closely watch the effects of radiation on the instrument. Due to the major impact on the overall resolution of the ACIS instrument, operational measures have been put in place to protect ACIS against any additional degradation above and beyond the expected rate budgeted before launch. This has been accomplished by “padding” the OFLS high radiation level prediction times and by manually “safing” the CXO during periods of high solar activity. The effect of these operational measures has been a loss of science observation time as well as an increase in operational complexity during times of high solar activity. Therefore, the need for a new and more comprehensive radiation model has been identified.

2009-06-03 3

Background (continued)Specifically, a new radiation threat has been identified outside of the originally prescribed radiation zones (Van Allen belts). This radiation threat comes from “soft” protons, 100-200 keV, located in the magnetopause caused by the interaction of the solar wind with the Earth’s magnetosphere. A new radiation model has been developed by Sverdup Corp which attempts to predict the radiation profile in the magnetopause based of measured data taken by satellites in similar orbits as Chandra. This model is to work in conjunction with the current OFLS radiation model (NSSDC, AE-8, AP-8) which predicts high energy trapped radiation profiles. The Svedrup model utilizes the OFLS generated ephemeris as an input and delivers both an instantaneous flux, and integrated fluence for OFLS specified species (e.g. protons, electrons, CNO, etc.)DESIRED IMPLEMENTATION:The OFLS shall integrate the Svedrup model into the current ISS Orbit Events processing. As with the current radiation model, ISS shall identify and time tag all events in the processing time span which are selected by the user from an ISS radiation GUI. This GUI shall allow the user to specify both flux levels and integrated fluence levels for all species of radiation. This shall all be accomplished without compromising or altering the current radiation capabilities. Flexibility to incorporate future species, at least 6, and flux / fluence levels shall be allowed, such that recoding of the software is not required. All events in the orbit events file shall be uniquely identifiable and available for other CSCIs, such as MPS, to use for further processing. Error reports shall be generated any time a processing problem is encountered in either the Sverdrup model, or ISS, processing concerning radiation events.

2009-06-03 4

References for Deriving Requirements

• ClearDDTS entry OCCcm03713, attached document OFLS_Release_10.0_definition_B1.pdf

• ClearDDTS entry OCCcm03714, “Implement New Sverdrup Radiation Model into ISS”

• ClearDDTS entry OCCcm04258, “Implement Radiation Orbit Events Merge/Suppression Capability”

• OFLS R10.3 Release Notes• OP-19 rev D, FDB baselined Jan. 12, 2006, OCCcm07574

2009-06-03 5

Derived Requirements for Orbit Events Generation• Provide namelist and GUI input for parameters required by CRM subroutine

CRMFLX, as documented in the subroutine header.• Provide namelist and GUI input for parameters defining up to ten sets of

radiation zone characteristics: ion species, energy range, Kp index, percentile (mean, 50%, or 95% flux), and flux threshold value (particles/[cm^2-sec-sr-MeV]).

• For each selected set of flux threshold characteristics, determine the times, to within a user selectable step size, of flux threshold crossing, for either increasing flux (radiation-zone entry) or decreasing flux (radiation-zone exit).

• Entry and exit mnemonics for each radiation-zone shall be compliant with the baselined OP-19, version D.

• Radiation zone events shall be output in binary files and ASCII summaries and reports, consistent with the current orbit event formats (OP-19 version D).

• Provide the capability to exclude radiation zones smaller than a user-defined width, and the capability to exclude separations between radiation zones smaller than a user specified gap. (OCCcm04258)

• Use CRM version 3.3 and latest GEOPACK 2008 routines (testable?).

2009-06-03 6

Test Cases1. Run OFLS orbit events generation with CRM model configured with the same

parameters as current SOT runs with their implementation of the CRM, RUNCRM. Do not use capability to exclude radiation zones or gaps between radiation zones.

a. Graphically compare OFLS CRM radiation events with those of RUNCRM flux vs. time for many perigee passes.

b. Determine CRM radiation threshold crossings times from RUNCRM flux vs. time, determine differences relative to OFLS CRM events, compute statistics, and plot histogram.

2. Run OFLS orbit events generation with CRM model configured the same as the previous test, except use non-zero values for minimum radiation-zone width and minimum gap between zones, such that each perigee pass has only one CRM radiation-zone entry and exit.

a. Graphically compare OFLS CRM radiation events with those of RUNCRM flux vs. time for many perigee passes.

b. Determine CRM radiation threshold crossings times from RUNCRM flux vs. time, determine differences relative to OFLS CRM events, compute statistics, and plot histogram.

2009-06-03 7

Test Cases (continued)

3. Run OFLS orbit events generation with CRM model configured different from previous runs with changes made in namelists and on GUIs.

a. Verify that the specified configurations were actually used in CRM orbit events generation.

b. Verify that expected CRM orbit events appear in binary, summary, and report files.

The RUNCRM program was developed for SOT use. It uses OFLS-supplied ephemeris vectors (transformed to GSM coordinates), the CRM v3.3 model, and tables of flux data files to compute flux vs. time (mean flux, 50 and 95 percentile values). So far, only proton data files and mean fluxes have been used operationally. To enable personnel at the OCC to make independent runs of the CRM, the SOT supplied the OCC Integration team (INT) with source code for RUNCRM and the associated COCOCHAN. The INT recompiled these routines in the OCC development environment, making minor changes to accommodate Linux, remove hard-coded paths, and to be compliant with INT makefile and library conventions. The INT also ensured that the latest CRM v3.3 code and data files and the latest version of GEOPACK2008 were used. Usually, the output of the SOT flux vs. time was used to compare with OFLS CRM events. When discrepancies appeared, the well-know configuration of the INT version was used instead.

2009-06-03 8

Test Conditions• Test cases 1 and 2 use 40 consecutive perigee passes, the first on Jan. 12, 2009 and the

last on Apr. 25, 2009. • Test cases 1 and 2 use the following parameter values for CRMFLX

– XKP = 3, Kp index– ISPECI = 1, ion species is protons– IUSESW = 1, user supplied uniform solar wind flux value used– FSWIMN = 0.0, user supplied mean uniform solar wind flux– FSWI95 = 0.0, user supplied 95% level uniform solar wind flux– FSWI50 = 0.0, user supplied 50% level uniform solar wind flux– FSWISD = 0.0, user supplied std. dev. of uniform solar wind– IUSEMSH = 2, magnetosheath database used for magnetosheath flux calculation– IUSEMSP = 0, magnetosphere model flux is used for magnetosphere flux calculation– SMOOTH1 = 4, spatial average of flux in volume specified by RNGTOL– NFLXGET= 10, number of flux values to get for smoothing filter (used if SMOOTH1 = 1,2, or 3)– NDROPHI= 2, number of high flux values to drop for smoothing filter (used if SMOOTH1 = 1,2,3, or 5)– NDROPLO= 2, number of low flux values to drop for smoothing filter (used if SMOOTH1 = 1,2,3, or 5)– LOGFLG = 2, linear flux average is performed– RNGTOL = 4.0, range tolerance from near-neigbor used in spatial averaging of database (Re) (used if

SMOOTH1 = 4,5, or 6)– FPCHI= 80, upper percentile limit for spatial averaging of flux (used if SMOOTH1 = 6)– FPCLO= 20, lower percentile limit for spatial averaging of flux (used if SMOOTH1 = 6)

2009-06-03 9

Test Conditions (continued)

• Test cases 1 and 2 use the following additional parameters for OFLS CRM processing:– FLXTHR = 8000.0, 20000.0, flux thresholds (particles/{cm^2-sec-sr-MeV])– FLX_E = 100.0, 200.0, flux energy band in KeV– RSPAD= 57600.0, pad time for estimating entry/exit (sec), 16 hr– RSSTEP= 120.0, step size for flux computation (sec), 2 min– RSFACT= 0.250, orbit fraction relative to perigee for first approx. of rad entry /exit– RSMINDUR= 0.0, minimum radiation-zone duration (sec) (for test case 1)– RSMINGAP= 0.0, minimum separation between radiation-zones (sec) (for test case 1)– RSMINDUR= 1800.0, minimum radiation-zone duration (sec) (for test case 2) , 30 min– RSMINGAP= 14400.0, minimum separation between radiation-zones (for test case 2) , 4 hr– SMOOTH2 = 0, do not use orbit smoothing filter– RNGMIN= 6.0, minimum distance from Earth center (Earth radii) to compute CRM flux

• RUNCRM mean flux vs. time, determine events for comparison to OFLS CRM events– SOT flux vs. time obtained from OccWeb/SOT Observing Schedule– INT flux vs. time obtained from runs on OCC development server– When the two flux vs. time are inconsistent (rarely), INT results are used, because of known configuration,

otherwise SOT results are preferred– Flux vs. time step time: 5 min– Time of flux-crossing event is time of center of step

2009-06-03 10

Some Issues• OFLS CRM fluence (integrated flux) not yet in test plan

– Do not yet understand requirements for fluence events– Need to develop utility to independently compute fluence events– Fluence is not currently used in FOT mission planning, but as we progress

into the current sunspot cycle, fluence will become an issue. • OFLS runs for test cases 2 and 3 not yet run• SOT and INT compilations of RUNCRM do not always agree

– Possible issues about CRM and GEOPACK versions– Because the INT RUNCRM configuration is set up to match the OFLS,

INT results are used when discrepancies are seen.• The CRM (and NSSDC) event times produced by Orbit Events

Generation are not the final event times used for scheduling, but provide unpadded flux crossing times; pads are applied to the radiation event times in the OFLS Mission Planning and Scheduling subsystem and are not part of the tests described here.

2009-06-03 11

Plots for Test Case 1a

• Plots show comparisons of OFLS R11.7.3 CRM flux crossing events with CRM flux vs. time from the RUNCRM program (either the SOT or INT version) for 40 consecutive perigee passes.

• The red line, labeled “CRM Flux”, is output from RUNCRM. • The blue line, labeled “ORP Events”, shows the time intervals, output

by the OFLS in the Orbit Events Report (ORP), where the CRM is above two different thresholds, 20000 and 8000.

• The magenta dashed line shows the times of AE-8 radiation events computed with the OFLS.

• The green dashed line shows the time of perigee. • Four plots are displayed on each page: the upper pair are for one

perigee pass, the lower pair are for the next perigee pass, the right two are for a flux of 8000, and the left two are for a flux of 20000.

2009-06-03 12

2009-06-03 13

2009-06-03 14

2009-06-03 15

2009-06-03 16

2009-06-03 17

2009-06-03 18

SOT RUNCRMFlux vs. Time

2009-06-03 19

INT RUNCRMFlux vs. Time

2009-06-03 20

2009-06-03 21

2009-06-03 22

2009-06-03 23

2009-06-03 24

2009-06-03 25

2009-06-03 26

2009-06-03 27

2009-06-03 28

2009-06-03 29

2009-06-03 30

2009-06-03 31

2009-06-03 32

2009-06-03 33

Results for Test Case 1b, Statistics

2009-06-03 34

Summary and Comments

• Plots of flux vs. time and OFLS orbit events for test case 1a agree well.

• Statistics of flux vs. time and OFLS orbit events for test case 1a appear acceptable given the selected step size, but the -1.3 minute offset in the OFLS events is not yet explained.

• Need to continue with test cases 2 and 3.