Travis Metcalfe (NCAR)

A TeraGrid Science Gateway for Kepler Asteroseismic Data

Collaborators: Joergen Christensen-Dalsgaard,Orlagh Creevey, Matthew Woitaszek

Wampler’s screwdriver

Schematic pipeline

input global search local analysis output

nl, Teff, L, R

parallelGA

SVDLM

M, Z, Y,

pulsation frequenciesand other constraints

optimal parameters, other model output

teragrid bluegene desktop workstation

ASTEC + ADIPLS

GA convergence

• Initial convergence driven by the crossover operator (first 20-30 generations)

• Subsequent improvement due to random favorable mutation operations

• Three out of four runs find the global solution within 200 generations (ran 300)

0.75 < Mstar < 1.75

0.002 < Zinit < 0.05

0.22 < Yinit < 0.32

1.0 < mlt < 3.0

50,000 CPU-hours/fit

Surface effects

• Incomplete modeling of surface convection zone leads to systematic errors

• Calibrated with difference between fit to “Model S” and BiSON radial modes

• Global fit to BiSON data, including scaled empirical correction for all modes

BiSON results

• Fit to 36 frequencies with l = 0-2 and constraints on temperature, luminosity

• Matches frequencies with scaled surface correction better than 0.6 Hz r.m.s.

• Temperature and age within +0.1%, luminosity and radius within +0.4%

Science Gateway

• Web interface to specify observations with errors, or upload as a text file

• Specify parameter values to run one instance of the model, results archived

• Source code available for those with access to large cluster or supercomputer

TeraGrid workflow

128-way parallel

100-300 gen/week

Community management

• Public users: anonymous visitors will see the status of current model-fitting runs and will be allowed to browse/download archived runs

• Registered users: KASC members who provide name, institution, and email can download code, submit single-model and model-fitting requests

• Gateway managers: approve new registrations, modify job and queue policy, and manage public archiving of the model-fitting results

Data release

• Model-fitting in progress: will be shown with KIC number, J2000 coordinates, requesting scientist, institution, resources allocated and job progress

• Completed model-fitting: available to registered users during the proprietary period of the data, then archived on the website for all users

• Single-model requests: archived immediately on the website for all users (to avoid duplicate runs), with choice of binary files in big/little ENDIAN

Open questions

• Should all of the model-fitting results be visible to all registered KASC members, or do we need to define subgroups (e.g. for KASOC)?

• When should the model-fitting results be visible to non-registered users? How should the timing of the public release be determined?

• Should there be limits on the number of jobs submitted to the queue by each user? Limits on the number of jobs running? Job priorities?