-
Notifications
You must be signed in to change notification settings - Fork 1
/
aciris.tex
2079 lines (1826 loc) · 103 KB
/
aciris.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
%%
%% Copyright 2007, 2008, 2009 Elsevier Ltd
%%
%% This file is part of the 'Elsarticle Bundle'.
%% ---------------------------------------------
%%
%% It may be distributed under the conditions of the LaTeX Project Public
%% License, either version 1.2 of this license or (at your option) any
%% later version. The latest version of this license is in
%% http://www.latex-project.org/lppl.txt
%% and version 1.2 or later is part of all distributions of LaTeX
%% version 1999/12/01 or later.
%%
%% The list of all files belonging to the 'Elsarticle Bundle' is
%% given in the file `manifest.txt'.
%%
%% Template article for Elsevier's document class `elsarticle'
%% with numbered style bibliographic references
%% SP 2008/03/01
%%
%%
%%
%% $Id: elsarticle-template-num.tex 4 2009-10-24 08:22:58Z rishi $
%%
%%
\documentclass[preprint,authoryear,5p]{elsarticle}
%% Use the option review to obtain double line spacing
%% \documentclass[preprint,review,12pt]{elsarticle}
%% Use the options 1p,twocolumn; 3p; 3p,twocolumn; 5p; or 5p,twocolumn
%% for a journal layout:
%% \documentclass[final,1p,times]{elsarticle}
%% \documentclass[final,1p,times,twocolumn]{elsarticle}
%% \documentclass[final,3p,times]{elsarticle}
%% \documentclass[final,3p,times,twocolumn]{elsarticle}
%% \documentclass[final,5p,times]{elsarticle}
%% \documentclass[final,5p,times,twocolumn]{elsarticle}
%% if you use PostScript figures in your article
%% use the graphics package for simple commands
%% \usepackage{graphics}
%% or use the graphicx package for more complicated commands
%% \usepackage{graphicx}
%% or use the epsfig package if you prefer to use the old commands
%% \usepackage{epsfig}
%% The amssymb package provides various useful mathematical symbols
\usepackage{amssymb}
%% The amsthm package provides extended theorem environments
%% \usepackage{amsthm}
%% The lineno packages adds line numbers. Start line numbering with
%% \begin{linenumbers}, end it with \end{linenumbers}. Or switch it on
%% for the whole article with \linenumbers after \end{frontmatter}.
%% \usepackage{lineno}
%% natbib.sty is loaded by default. However, natbib options can be
%% provided with \biboptions{...} command. Following options are
%% valid:
%% round - round parentheses are used (default)
%% square - square brackets are used [option]
%% curly - curly braces are used {option}
%% angle - angle brackets are used <option>
%% semicolon - multiple citations separated by semi-colon
%% colon - same as semicolon, an earlier confusion
%% comma - separated by comma
%% numbers- selects numerical citations
%% super - numerical citations as superscripts
%% sort - sorts multiple citations according to order in ref. list
%% sort&compress - like sort, but also compresses numerical citations
%% compress - compresses without sorting
%%
%% \biboptions{comma,round}
\biboptions{comma,round}
\pdfoutput=1
\usepackage{graphicx}
\usepackage[space]{grffile}
\usepackage{latexsym}
\usepackage{amsfonts,amsmath,amssymb}
\usepackage{url}
\usepackage[utf8]{inputenc}
\usepackage{fancyref}
\usepackage{hyperref}
\hypersetup{colorlinks=false,pdfborder={0 0 0},}
%\usepackage{caption}
\usepackage{courier}
\usepackage{float}
\usepackage{booktabs}
\usepackage{threeparttable}
\usepackage{array}
\usepackage{tabu}
\newcommand{\truncateit}[1]{\truncate{0.8\textwidth}{#1}}
\newcommand{\scititle}[1]{\title[\truncateit{#1}]{#1}}
\usepackage{comment}
\newcommand{\unit}[1]{\ensuremath{\, \mathrm{#1}}}
\usepackage[usenames,dvipsnames,svgnames,table]{xcolor}
\input{commands.tex}
\journal{Astronomy and Computing}
\begin{document}
\begin{frontmatter}
%% Title, authors and addresses
%% use the tnoteref command within \title for footnotes;
%% use the tnotetext command for the associated footnote;
%% use the fnref command within \author or \address for footnotes;
%% use the fntext command for the associated footnote;
%% use the corref command within \author for corresponding author footnotes;
%% use the cortext command for the associated footnote;
%% use the ead command for the email address,
%% and the form \ead[url] for the home page:
%%
%% \title{Title\tnoteref{label1}}
%% \tnotetext[label1]{}
%% \author{Name\corref{cor1}\fnref{label2}}
%% \ead{email address}
%% \ead[url]{home page}
%% \fntext[label2]{}
%% \cortext[cor1]{}
%% \address{Address\fnref{label3}}
%% \fntext[label3]{}
\title{Iris: an Extensible Application for Building and Analyzing\\
Spectral Energy Distributions}
\author[sao]{Omar Laurino~\corref{cor}}
\cortext[cor]{Corresponding author}
\ead{[email protected]}
\author[sao]{Jamie Budynkiewicz}
\author[sao]{Raffaele D'Abrusco}
\author[sao]{Nina Bonaventura~\fnref{nina}}
\fntext[nina]{Present affiliation: McGill University, 3600 University St. Montr\'{e}al QC, Canada H3A 2T8}
\author[stsci]{Ivo Busko}
\author[sao]{Mark Cresitello-Dittmar}
\author[sao]{Stephen M. Doe~\fnref{doe}}
\fntext[doe]{Present address: 4 Lafayette Drive, East Walpole, MA 02032}
\author[ipac]{Rick Ebert}
\author[sao]{Janet D. Evans}
\author[noao]{Patrick Norris}
\author[ipac]{Olga Pevunova}
\author[sao]{Brian Refsdal}
\author[noao]{Brian Thomas}
\author[stsci]{Randy Thompson}
%% Addresses
\address[sao]{Smithsonian Astrophysical Observatory, 60 Garden St.
Cambridge, MA 02138}
\address[stsci]{Space Telescope Science Institute, 3700 San Martin Dr.
Baltimore, MD 21218}
\address[ipac]{Infrared Processing and Analysis Center, 770 South Wilson Ave.
Pasadena, CA 91125}
\address[noao]{National Optical Astronomy Observatory, 950 N Cherry Ave.
Tucson, AZ 85719}
\begin{abstract}
Iris is an extensible application that provides astronomers with a user-friendly
interface capable of ingesting broad-band data from many different sources
in order to build, explore, and model spectral energy distributions (SEDs). Iris
takes advantage of the standards defined by the International Virtual
Observatory Alliance, but hides the technicalities of such standards by
implementing different layers of abstraction on top of them. Such intermediate
layers provide hooks that users and developers can exploit in order to extend
the capabilities provided by Iris. For instance, custom Python models can be
combined in arbitrary ways with the Iris built-in models or with other custom
functions. As such, Iris offers a platform for the development and integration
of SED data, services, and applications, either from the user's system or from
the web. In this paper we describe the built-in features provided by Iris for
building and analyzing SEDs. We also explore in some detail the Iris framework
and software development kit, showing how astronomers and software developers
can plug their code into an integrated SED analysis environment. \end{abstract}
\begin{keyword}
%% keywords here, in the form: keyword \sep keyword
data abstraction \sep method: data analysis \sep object-oriented programming \sep software frameworks \sep spectral energy distribution \sep virtual observatory tools
\end{keyword}
\end{frontmatter}
\bibliographystyle{model2-names}
\label{sec:introduction} \section{Introduction}
%\begin{sloppypar}
%The International Virtual
%Observatory Alliance \citep[IVOA;][]{2004SPIE.5493..137Q} provides a set of
%standards and protocols that enable interoperability among astronomy-center\-ed
%services and applications. In order to design effective applications, one wants
%to leverage IVOA standards and protocols without exposing the complexity and
%technicality of their specifications to the users. Also, while application
%developers implement many desired features, they must keep the door open
%for plugging in user's analysis code, and allow third party developers to extend
%the application's functionality without being aware of the standards themselves.
%Designing such general purpose applications thus becomes an exercise in
%designing a framework that implements some basic, effective functionality for a
%wide set of use cases, while being highly extensible.
%\end{sloppypar}
The emission processes of astronomical objects (e.g., stars, galaxies, quasars)
are reflected in the spectral energy distribution (SED) of the radiation detected
by astronomers with a variety of telescopes and instruments. Astronomers use this
information to infer the physical properties of the source by comparing the
detected SED with different emission models. Methods for these studies have
been developed by several communities in astronomy, focused on either a particular
type of source, or quite often on a particular region of the emission spectrum
(e.g., radio, optical-IR, X-ray). These focused tools typically require different
input formats and imply the use of wavelength specific units, as well as being
optimized for particular models to compare the SED with. However, the most
complete picture of any emission phenomena requires the use of the most complete
information base. Modern wide-field ground and space telescopes, and the
availability of data from multi-wavelenth archives, allow in principle to build
and study broadband SEDs for any kind of astronomical object. However, a tool that can
efficiently and powerfully make use of this information requires a
non-wavelength-specific approach.
\begin{sloppypar}
The International Virtual
Observatory Alliance \citep[IVOA;][]{2004SPIE.5493..137Q} provides a set of
standards and protocols that facilitate interoperability among astronomy-related
services and tools. These IVOA specifications can be implemented to enable
generalized SED analysis, regardless of the spectral regime
and objects being studied.
\end{sloppypar}
\begin{sloppypar}
In order to design effective applications, one wants
to leverage IVOA standards without exposing the complexity and
technicality of their specifications to the users. Also, while application
developers implement many desired features, it is useful, and sometimes
required, to provide hooks for users and third party developers to extend
the application's functionality without requiring knowledge of standards themselves.
Designing such an application, like a general SED analysis tool, thus becomes an
exercise in designing a framework that implements some basic,
effective functionality for a wide set of use cases, while being highly extensible.
\bigskip
\textit{Iris}, the Virtual Astronomical Observatory \citep[VAO;][]{2012SPIE.8449E..0HB}
SED analysis tool, is such an IVOA-enabled desktop application.
With Iris, users may populate SEDs with data from files, built-in portals to data
archives, and other Virtual Observatory (VO) applications. Users can
interactively visualize and edit SEDs, and fit SEDs with fine-tuned modeling
features. Iris provides a suite of astrophysical models, but also lets users
import custom models and template libraries. All front-end features
of Iris completely hide the underlying technical IVOA specifications from
the user.
While implementing IVOA standards and protocols,
we took advantage of existing astronomy
software, namely
Specview~\citep{2002ASPC..281..120B} for the visualization and fitting user
interfaces, the NASA/IPAC Extragalactic Database (NED) SED
Service\footnote{\url{http://vo.ned.ipac.caltech.edu/SED_Service/}} for data
acquisition, and Sherpa~\citep{2001SPIE.4477...76F,2009pysc.conf...51R} for the
modeling and fitting engine. Along with these components, new ones, like the SED
Builder, were developed specifically for Iris
\citep{2012ASPC..461..893D,2013AAS...22124038L}.
\end{sloppypar}
%The IVOA standards allow this approach, as we have demonstrated in developing Iris.
%\textit{Iris}, the Virtual Astronomical Observatory~\citep[VAO;][]{2012SPIE.8449E..0HB}
%spectral energy distribution an\-alysis tool, is such an IVOA-enabled desktop
%application for building, viewing and modeling broadband
%spectrophotometric SEDs.
%The IVOA standards allow a wavelength-general approach to SED analysis.
%While implementing IVOA standards and protocols,
%we took advantage of existing astronomy
%software~\citep{2012ASPC..461..893D,2013AAS...22124038L}, namely
%Specview~\citep{2002ASPC..281..120B} for the visualization and fitting user
%interfaces, the NASA/IPAC Extragalactic Database (NED) SED
%Service\footnote{\url{http://vo.ned.ipac.caltech.edu/SED_Service/}} for data
%acquisition, and Sherpa~\citep{2001SPIE.4477...76F,2009pysc.conf...51R} for the
%modeling and fitting engine. Along with these components, new ones, like the SED
%Builder, were developed specifically for Iris.
%With Iris users may populate SEDs with data from files, built-in portals to data
%archives, and other Virtual Observatory (VO) applications. Users can
%interactively visualize and edit SEDs, and fit SEDs with fine-tuned modeling
%features. For SED fitting, users may choose from a suite of provided astrophysical
%models, or
%load their own Python functions and template libraries. All front-end features
%of Iris completely hide the underlying technical VO standards and protocols from
%the user.
Iris was developed inside the framework of the VAO science applications: the
different components were contributed by developers from the Smithsonian
Astrophysical Observatory, the Space Telescope Science Institute (STScI), and the NASA
Infrared Processing and Analysis Center (IPAC). Quality assurance and testing were led
by team members at the National Optical Astronomy Observatory and STScI.
%Designing an effective IVOA application requires proper leveraging of the standards
%and protocols without exposing the complexity and
%technicality of their specifications to the users. While application
%developers implement many desired features, they must keep the door open
%for plugging in user's analysis code, and allow third party developers to extend
%the application's functionality without being aware of the standards themselves.
%Designing such general purpose applications thus becomes an exercise in
%designing a framework that implements some basic, effective functionality for a
%wide set of use cases, while being highly extensible.
In this paper we present the Iris application, design, and extensible architecture. In Section
\ref{sec:overview} we briefly explore the landscape of SED applications and
analysis tools that Iris joined, and provide an example use-case of Iris. We
explore how astronomers can include their own models or templates as Python
functions in Section \ref{sec:usermodels}. An introduction to Iris' general
architecture (the Iris \emph{stack}) is illustrated in Section \ref{sec:stack}.
A more detailed overview of the Iris extensible framework design (Section
\ref{sec:architecture}) is followed by a detailed description of the more
advanced Iris capabilities (Section \ref{sec:components}). Finally, we
describe the Iris software development kit, including a ``How-to'' on extending
Iris with plug-ins (Section \ref{sec:plugins}). Sections \ref{sec:architecture} and
\ref{sec:plugins} are targeted to software
developers.
The paper refers to version 2.0.1 of Iris. Iris can be downloaded as a binary
archive for OS X and
Linux\footnote{\url{http://cxc.cfa.harvard.edu/iris/latest/download/}}, and the
source code is hosted on GitHub as a public
repository\footnote{\url{https://github.com/ChandraCXC/iris}}.
\section{SED Analysis with Iris} \label{sec:overview}
Fitting spectral energy distributions enables astron\-omers to estimate fundamental
properties of various astronomical objects.
%For example, researchers of galaxy evolution frequently model SEDs to derive stellar masses,
%star formation rates, dust temperature and mass, and redshifts of active, normal, and passive galaxies
In galaxy evolution studies, for example, stellar mass, star formation rates, dust content, and redshift
are often derived from galaxy SEDs (e.g.\citet{1998AJ....115.1329S},
\citet{2001ApJS..137..139S}, \citet{2007ApJS..169..328R}, and many others).
Accretion disks surrounding supermassive black holes, x-ray binary and young stellar objects can be studied by
fitting models to the host objects' SEDs, extracting information like
accretion rates, disk geometry, and disk temperature \citep[e.g.,][]{1987ApJ...321..305C,1990A&A...235..162V,1997ApJ...490..368C,2006ApJS..167..256R}.
Stellar SED analysis can recognize mid IR excess, which may indicate circumstellar
disks~\citep{2000prpl.conf..639L,2005ApJ...623..493C}. As these examples show, SEDs
are widely used throughout astronomy.
%Fitting spectral energy distributions enables astron\-omers to estimate fundamental
%physical properties of galaxies (e.g., spiral, elliptical, starburst, AGN; and quasars) and smaller-scale
%sources (stars, young stellar objects, binary systems, etc.).
%Stellar mass, star formation rates, dust temperature and mass, and redshift
%are just a few of the properties often derived from galaxy SEDs (e.g.\citet{1998AJ....115.1329S},
%\citet{2001ApJS..137..139S}, \citet{2007ApJS..169..328R}, and many others).
%SEDs have been used to shed light on accretion disk physics, modeling the SEDs of AGN, young stellar objects, and X-ray binary %systems
%Fitting spectral energy distributions enables astron\-omers to estimate fundamental
%physical properties of various objects. Commonly studied through SED analysis are
%galaxies, from which stellar mass, star formation rates, dust temperature and mass, redshift,
%and many other properties are be derived.
With ever increasing wide-field surveys and datasets over the years,
astronomers have been able to use multi-wavelength SEDs more frequently for
their research. As such, many robust SED analysis codes have been created to
help astronomers mod\-el, fit, and derive physical quantities from SEDs
\citep{2011Ap&SS.331....1W,2013ARA&A..51..393C}. These widely-used codes
implement a diverse set of methods, for instance: inversion (e.g.,
STARLIGHT~[\citealp{2004MNRAS.355..273C}] and
PAHFIT~[\citealp{2007ApJ...656..770S}]),
principal component analysis~\citep[e.g.,][]{2009MNRAS.394.1496B},
$\mathrm{\chi}^{2}$-minimization codes
(e.g., Le PHARE~[\citealp{1999MNRAS.310..540A,2006A&A...457..841I}] and
HyperZ~[\citealp{2000A&A...363..476B}]), and Bayesian inference
(e.g., BPZ~[\citealp{2000ApJ...536..571B}],
VOSA~[\citealp{2008A&A...492..277B}], and
GalMC~[\citealp{2011ApJ...737...47A}]).
Most widely used fitting packages are tailored for specific data sets or
spectral ranges (such as PAHFIT and STAR\-LIGHT), providing robust
fitting methods and results. They require the data to be in a specific format
with specific units in order for the tool to work properly. When fitting a
broadband SED that spans over decades in the spectrum, the astronomer will
typically gather datasets from different public archives and colleagues in order
to add such data to their own. More often than not, the datasets are stored in
different file formats and units.
The user must provide their own methods to extract the necessary data from each
file, homogenize the units, and output a file in the format supported by the
tool; converting the data to a supported format may easily become a tedious task
with each additional dataset.
\begin{table*}[tp!]
\caption{\textbf{Supported file formats.} Native formats are automatically loaded into
Iris. Supported formats require some user input to map the file data to the spectral
and flux information.}
\label{table:file_formats}
\input{file-format-table.tex}
\end{table*}
\begin{table}[h!]
\caption{\textbf{Supported SED units.} Iris can read, write, and/or plot data in
the spectral and flux units listed in this table. Italicized units are only available
for plotting.}
\label{table:units}
\input{units.tex}
\end{table}
While SED analysis tools often have different input formats from each other,
they effectively require the same information to run. Whether datasets are
stored in a FITS file, a tab-separated ASCII table, or a
VOTable~\citep{2011arXiv1110.0524O} coming from a
VO data discovery application, they are all serializations of the same, global,
abstract, scientific model of photometric measurements for
astronomical sources.
By employing a standardized definition of such models, Iris streamlines
the process of building SEDs for analysis. In other terms, one of the goals of
Iris is to make SED building a painless and straightforward process, letting the
scientist focus on the sophisticated and original parts of the scientific
work-flow: data analysis, hypothesis testing, and knowledge extraction.
Following VO efforts to combine data services and applications seamlessly, Iris
offers an interface for building large broadband SEDs from different sources in
various data formats, while providing robust fitting methods and interactive
visualization capabilities using existing astronomical software.
It is important to stress that this is not only a matter of ingesting
non-standard files, but also to allow scientists to create standardized versions
of their datasets: the improved interoperability enables more tools, inside or
outside Iris, to load and interpret such datasets with minimal user
intervention.
\begin{sloppypar}
Much effort has been put into making Iris lenient on data format. While natively
supporting VO-compliant files (properly annotated
VOTable and FITS files), Iris can ingest ASCII, CSV,
and other table-like formats as well with some extra user input.
Table~\ref{table:file_formats}
describes the file formats that can be read into Iris. Users may also
seamlessly transfer data from other VO applications or data archive services
through SAMP, the Simple Application Messaging
Protocol~\citep{2011arXiv1110.0528T}. Moreover, Iris can read, write, and display SED data in
a variety of commonly-used units, which are listed in Table~\ref{table:units}, with minimal user effort.
\end{sloppypar}
But more importantly, Iris provides standardized views of the integrated
datasets to its clients, whether they are built-in components, third party
plug-ins, or external applications.
\subsection{A Use Case} \label{subsec:usecase}
In this section, we present a brief, illustrative use-case
of Iris to showcase its main features. We outline the analysis of the broadband SED
of flat spectrum radio quasar (FSRQ) object PKS 1127-14~\citep[see][]{2004ApJ...600L..27B}, and save the
results to file.
%Details on the Iris features introduced here
%are discussed throughout the remainder of the paper.
For details on the Iris features introduced in this use-case, see Section~\ref{sec:components}.
\begin{figure*} \centering
\includegraphics[height=2.95in,width=5.3in]{built-in-visuals-loading.pdf}
\caption{\textbf{Building the SED of blazar PKS 1127-14 in Iris.}
\textit{Top-left:} Data from the NED SED Service, a local file, and from TOPCAT
are managed in the SED Builder. \textit{Bottom-left:} The various data segments
plotted in $\mathrm{\nu F \left( \nu \right)}$ units inside the SED Viewer.
Squares show data with flux uncertainties, whereas the pink diamonds denote
points without associated uncertainties. Each segment in the SED Builder is
plotted in a different color. Black squares are data taken from NED; the
pink squares in the radio are the data from PLANCK; and the red, yellow, blue,
and green squares in the near-IR are the four WISE bands. \textit{Right:} An ASDC
Data Query form for PKS 1127-14. The user searches for data between specified
dates and available instruments (Swift and GALEX in this case). The data have
been added to the open SED PKS 1127-14.} \label{fig:load_data}
\end{figure*}
\begin{figure*} \centering
\includegraphics[height=2.95in,width=5.3in]{fitting-1.pdf}
\caption{\textbf{Fitting Visualization.} Visualization of a linear combination of
log-parabolas and blackbody distributions for FRSQ blazar PKS 1127-145, fit with
Nelder-Mead optimization and least-square statistics. \textit{Left:} The best fit
linear combination overlaid on the SED data as a red curve. The blue line shows
the spectral range over which the data were fit. Below the main plot are
residuals of the fitted curve, in dex units. \textit{Top-right:} The fitting
options and results. Here, the user chooses between Nelder-Mead,
Levenberg-Marquardt, and Monte-Carlo \citep[Differential Evolution, ][]{Storn:1997:DEN:596061.596146}
optimization and various least square and
$\mathrm{\chi}^{2}$ statistics. The fit statistics are reported here after the
fit has been performed. \textit{Bottom-right:} The Fitting Tool window. The
model components used in the fit and their fitted parameter values are listed in
the Components field. Below that is the Model Expression, in which the
components are linearly combined. Note that components are referenced by the
\textit{c\#} suffix of the component name.} \label{fig:fitting1} \end{figure*}
\begin{sloppypar}
An Iris session begins with populating a SED by clicking on the SED Builder icon on the
Iris desktop. A user loads a local ASCII file of
PLANCK data, a WISE dataset from TOPCAT \citep[ascl:1101.010\footnote{ascl: Astronomy Source Code Library}]{2005ASPC..347...29T}
through a SAMP message, and all data associated with PKS 1127-14 in NED with the NED SED
Service portal. The user also uses the built-in Italian Space Agency Science Data
Center\footnote{\url{http://www.asdc.asi.it/}} (ASDC) query tool to find
optical/UV data for PKS 1127-14, and adds it to the SED (see
Figure~\ref{fig:load_data}).
\end{sloppypar}
Data are converted to a single set of units on the fly, and displayed in the SED
Viewer. The user can switch the spectral and flux axes between a variety of
commonly-used SED units, e.g., one can switch from $\mathrm{Jy}$ vs.
${\mu}\mathrm{m}$ to $\mathrm{Jy}\mathrm{Hz}$ vs. $\mathrm{Hz}$. The Metadata
Browser --- an interactive table of the SED data --- allows the user to
interactively inspect and filter out data points by hand or with Boolean
expressions.
\begin{sloppypar}
The user also employs the Science Tools, an Iris built-in component that
lets the user cosmologically redshift SEDs, interpolate SED data, and calculate
integrated fluxes of SEDs
through photometric filters or user-defined passbands. In particular, the user
shifts PKS 1127-14 from its observed redshift at $z=1.18$ to rest frame using
the Redshift tool before fitting the SED.
\end{sloppypar}
The user then filters out all the points devoid of errors using the metadata browser
filtering features.
When the user is done building and editing the SED, the user begins the fitting
session. With the fitting tool, the user can build a model expression as an
arbitrary combination of model components. Choosing from a list of built-in astrophysical
and mathematical models, the user fits PKS 1127-14 with a linear
combination of four models: two logarithmic parabolas to model the radio
synchrotron and inverse Compton radiation~\citep{2006A&A...448..861M,2009A&A...501..879T},
and two blackbodies to approximate the models for the hot dust component and
accretion disk of the blazar~\citep{2002ApJ...575..667D}. The fit
is performed using Nelder-Mead optimization and least square statistics. The user
has fine control over the parameters, including setting initial values, the
range of the values, freezing and thawing parameters, and linking model
parameters to other parameters in the model expression; the user also controls the
spectral ranges over which to fit the models. Finally, confidence intervals are computed
for the overall model parameters.
Figure~\ref{fig:fitting1} shows the final model for PKS 1127-14 overlaid on the
input data and, in the lower panel, the fit residuals.
When the user is satisfied with the fitting results, the user saves an XML-style file
of the model that can be re-read into Iris and fit to other SED data. The user also
saves the fit results to a text file, that shows the parameters of the fit and
the details about each model component, with the best-fit parameter values.
%The Iris features introduced here are discussed in detail in Section~\ref{sec:components}.
\section{User Models and Templates} \label{sec:usermodels}
Keeping with our requirements of developing an extensible SED analysis tool, we
provide a user interface for adding custom models, templates, and template
libraries for the fitting engine to use in a Custom Fit Models Manager.
\begin{sloppypar}
Sherpa, Iris' fitting engine, provides command line functions for users to add
their own models and templates to a Sherpa session. We wrap a graphical user
interface (GUI) around such functions for streamlined integration and
user-friendliness.
The user provides the full path to the directory where the models and templates
exist, as well as information about the parameters. Installing a model saves a
copy of the model files in the user's home directory (in
\texttt{\~{}/.vao/iris/}components), allowing the user to apply the models in future
sessions.
\end{sloppypar}
\subsection{Custom Python Functions} Iris accepts custom models as Python
functions stored on the user's disk. Any number of functions can be stored in a
single file. The function implementing the model must take two parameters: the
first is an iterable of the model parameters, the second is a placeholder for
the spectral axis, $x$, in units of Angstroms. For example, a model file for a
modified black body \(B_{\nu}(T) \left(\nu/\nu_{0}\right)^{\beta}\) could be
defined as in Listing \ref{lst:user_model_example}.
User models can be arbitrarily combined with other custom or preset model
functions when using the Iris fitting tool.
\begin{lstlisting}[style=python,
caption={Example of a user-defined model that
can be dynamically loaded into Iris. The code, written as a Python function,
implements a modified blackbody and can be combined
in Iris with other built-in and custom components. Backslashes indicate line
continuations.},
label=lst:user_model_example]
import numpy as np
def modified_blackbody(p, x):
""" Modified blackbody.
Parameters
----------
p : [lambda_0, A, T, beta]
p[0] 'lambda_0' : reference wavelength
p[1] 'A' : amplitude of model at lambda_0
p[2] 'T' : temperature of blackbody
p[3] 'beta' : dust emissivity index
x : array spectral values, in Angstroms
"""
# Blackbody function
efactor = 1.438786e8 / p[2]
numerator = p[1] * np.power(p[0], 5.0) * \
(np.exp(efactor / p[0]) - 1.0)
denominator = np.power(x, 5.0) * \
(np.exp(efactor/ x) - 1.0)
B_lambda = numerator / denominator
# speed of light in AA/s
c = 2.998e18
powerlaw = (c / (x/p[0]))**p[3]
return B_lambda * powerlaw
\end{lstlisting}
\subsection{Table Models} A table model is a single template, having just the
$x$ and $y$ coordinates. Iris accepts two column ASCII files as table models,
following the convention where the first column is the spectral values
and the second contains the fluxes. The spectral and flux units must be in Angstroms
and $\mathrm{photons}/\mathrm{s}/\mathrm{cm}^{2}/\mbox{\AA}$, respectively\footnote{
While Iris ingests many other units (see Table~\ref{table:units}), the Custom Fit Model
Manager is independent of Iris's units handler and only accepts files with spectral
values in Angstroms and the flux in
$\mathrm{photons}/\mathrm{s}/\mathrm{cm}^{2}/\mbox{\AA}$}.
The fit returns the normalization constant (or amplitude) of the model.
\begin{sloppypar}
\subsection{Template Libraries} The template model is essentially a list of
table models with parameters other than the amplitude. Like the
\texttt{load\_template\_model} function in Sherpa, the user must create an index
file that lists the parameter values of the templates and the full path to the
template those parameter values describe (see Listing \ref{lst:templateconfig}
for an example). Sherpa uses a grid-search method to find the best-fit template.
The parameters grid is created using the values provided in the index file.
\end{sloppypar}
\begin{lstlisting}[style=code,
caption={Example of template library definition file. Template library definition
files are in ASCII format.},
label=lst:templateconfig]
# INDEX REFER MODELFLAG FILENAME
0.0 5000 1 /data/sed_temp_index-0.00.dat
-0.10 5000 1 /data/sed_temp_index-0.10.dat
-0.25 5000 1 /data/sed_temp_index-0.25.dat
-0.35 5000 1 /data/sed_temp_index-0.35.dat
-0.50 5000 1 /data/sed_temp_index-0.50.dat
\end{lstlisting}
\section{The Iris Stack} \label{sec:stack}
\begin{sloppypar}
The Iris stack (Figure \ref{fig:stack}) shows how one can put the
technical IVOA specifications to work for scientists through higher and higher
layers of abstraction: the details of the Virtual Observatory
standards and protocols lie in the lowest layer, the internals of the Iris
building blocks lie in the middle layer, while the top layer expresses
high-level user-oriented features.
\end{sloppypar}
A reader without any knowledge of programming, let alone of the VO
specifications, should understand the labels used in the top layer of the
diagram and their components (e.g., \textit{Fitting Tool} and \textit{Redshifting}), as long as they
have some knowledge of astronomical SEDs. On the other hand, a developer would
find words like framework, service, and manager quite familiar, while it takes a
VO-savvy person to decode the acronyms at the bottom of the diagram.\footnote{SAMP,
the Simple Application Messaging protocol was already introduced, DM stands for Data Model and the SpectrumDM
is introduced later in the paper. UTYPEs are labels used in some file formats (like VOTable, introduced later)
to tag data elements according to a Data Model. SSAP stands for Simple Spectral Access Protocol and
is implemented by services that provide access to spectral datasets, including SEDs, and is also introduced later
in the document.}
\begin{figure}
\begin{center}
\includegraphics[width=1.0\columnwidth]{IrisStack.pdf} \caption{\textbf{The
Iris Stack.} With its architecture Iris allows developers to create components
using higher and higher abstractions on top of web services, desktop
applications, and Virtual Observatory standards and protocols.
The technical
specifications lie on the bottom, a middle layer provides abstractions useful to
developers, and the user is only exposed to the science features represented by the top layer.
Users can also
plug their code in as Python functions. The result is aimed to be both user- and
developer- friendly. Notice that custom services can be built on top of custom specifications,
but also on top of IVOA standards. Similarly, plug-ins can use custom services, but they also
probably use the Iris Common Framework. The top layer components
(built-in Iris features and plug-ins) provide the user with scientific features within Iris.}
\label{fig:stack}
\end{center}
\end{figure}
This architecture enables different entry points for the different audiences of the
application. Core developers work at all levels of the stack, but need to lay
out the foundations on top of the standard specifications; third party
developers use the middle-level abstractions offered by the Iris framework,
while end users can limit their interaction to familiar astronomical concepts
through the application's user interface. End users can also plug in their
modeling code and upload templates libraries to Iris.
The color code in Figure \ref{fig:stack} adds a different dimension to this
diagram and taps into a different characteristic of the Iris architecture:
extensibility. In particular, scarlet letters denote extensible
components of the architecture, i.e., components that offer hooks into the Iris
architecture to users and developers. The orange boxes, on the other hand,
express components that were not part of the Iris design, but that can be
used in Iris as plug-ins, possibly providing interfaces to access
non-standard services. Some of these plug-ins, along with a description of the
design of the Iris Software Development Kit, will be introduced in Section
\ref{sec:plugins}.
The dark green box denotes IVOA sanctioned standards. Blue denotes components
that are built-in in Iris and light green boxes denote components that were developed
in or for Iris.\footnote{While the NED SED service was developed independently of Iris,
its IVOA-compliant interface was part of the Iris project, along with the development of a
dedicated client in Iris itself.}
This architecture was also driven by a more abstract requirement:
our team was
distributed, with developers and managers working from different
institutions with different tools and practices \citep{2012SPIE.8449E..0IE}.
Moreover, wanting to reuse existing software instead of reinventing the
proverbial wheel, we had to integrate different existing software components in
a seamless way. So, the Iris stack provided not only a clean and robust architecture
for users and third party developers, but was also useful in enabling a distributed
team of part-time developers to work in parallel, reducing the overall project risk.
In summary, the Iris framework was designed to address several different
requirements: (i) functional requirements gathered by the Iris team's lead
scientists; (ii) functional requirements unknown at development-time; (iii) the
distributed nature of the Iris development team; and (iv) interoperability between
several existing tools and services.
The Iris stack offers a non-technical view of the Iris architecture and design.
While the stack shows effectively how we tried to abstract end users and developers
from the VO specifications and from the specifics of the Iris internals, the stack does
not express the technical solutions that we employed to achieve such extensible
architecture and to meet the aforementioned requirements. More detail is
provided in some of the following sections.
\section{The Iris Architecture} \label{sec:architecture}
\begin{figure*} \begin{center}
\includegraphics[width=0.7\textwidth]{IrisDiagrams.001.pdf}
\caption{\textbf{The Iris loosely coupled, extensible architecture.} Information
freely flows among built-in and third-party components provided as plug-ins. A
SED Manager gives components access to the state of the SEDs in the user's
workspace, while dynamic changes in such state are announced through events that
are notified to the subscribed listeners. A plug-in manager allows users to
install and uninstall plug-ins on the fly.} \label{fig:architecture}
\end{center} \end{figure*}
\begin{figure*} \begin{center}
\includegraphics[width=0.6\textwidth]{IrisDiagrams.003.pdf}
\caption{\textbf{Inversion of Control.} IoC is a design pattern that promotes
decoupling of software components so that they can easily be replaced by
different implementations, with the actual binding often happening at run-time
according to some configuration. This pattern, however, also allows new
components to be added at any time during the application lifecycle: a common
framework (Iris Common) can be shared as a middle layer among implementations,
and a container (the Iris application) can bind components together on the fly.
Components can subscribe to events and react to them.} \label{fig:ioc}
\end{center} \end{figure*}
In order to minimize the risk derived from the requirements listed in the previous
section, we backed Iris with a loosely coupled architecture through a design
pattern called Inversion of Control \citep*{ioc}.
But it was not just a matter of risk management. Inversion of Control
supports the implementation of \emph{liquid} requirements, i.e., a finite set of
predetermined requirements plus an indefinite set of custom requirements to be
implemented by users, at least in some simple cases or, for more advanced
features, by third party developers.
The architecture that supports the implementation of such requirements has
different components that can be mapped to the Model-View-Controller (MVC)
design pattern.
\begin{description}
\item[SEDLib] This basic I/O library provides
classes for the Model components of MVC. Unsurprisingly, SEDLib does so by
implementing a Data Model specification defined by the IVOA. The Data Model
defines both the logical breakdown of spectral datasets, and the serialization
in some standard file formats. So, on the one hand, SEDLib can perform the basic
read/write operations on spectrophotometric files, while on the other the library
provides the data structures that client components can use and exchange.
\item[SEDManager] The MVC Controller role is played in Iris by the SEDManager,
which itself is defined as an Interface. The manager works as a data storage for
SEDLib instances that the different Iris components can share.
\item[Components] The actual Iris functionality is im\-ple\-ment\-ed by the Iris
Components. They can be seen as the Views in the MVC pattern (or, more
generally, they can provide any number of Views), since they present the data
stored in the Controller to the user, query the Controller itself, and act upon
the Models, i.e., the SED objects provided by SEDLib.
\item[Events] Views can be
notified of changes in the Models by Events, if they implement the relative
Listener interface and have been registered to the Events Queue. Events usually
have a payload with more information about their content, and a pointer to the
Model instances involved.
\end{description}
\begin{sloppypar}
In summary, Components (Views) can be completely disentangled from each other
and interact indirectly through the sole common interface represented by the
SEDManager (Controller), which in turn stores the SED objects (Model). Dynamic
changes in the system are notified to all interested agents (Listeners) via
specific Events.
\end{sloppypar}
Components are thus agents that cooperate by attaching themselves to a common
\emph{bus} where the SEDManager provides the memory, and Events guarantee the
flow of information (see Figure~\ref{fig:architecture}).
\subsection{Inversion of Control}
We achieve loose coupling by an extensive use of Java Interfaces: components,
events, and event listeners, for example, are all defined by interfaces whose
implementation can, to some extent, be freely interchangeable.
Moreover, Inversion of Control is employed to decouple
the implementation of components from the run time context (see Figure~\ref{fig:ioc}).
Methods in the
Interface are callbacks, and some of these callbacks get Interface-typed
arguments that provide them context instances during application execution.
For this reason, this pattern is also sometimes referred to as \emph{Dependency
Injection}\footnote{There is, to be precise, a subtle but significant difference
between Dependency Injection and Inversion of Control, the first effectively
being a special case of the second.}.
Consider, for example, Iris Components: they are the main providers of Iris
functionality, and they can correspond to buttons and menu items on the Iris
desktop, loggers, data handlers, etc. They must implement the \texttt{IrisComponent}
interface, listed in Listing \ref{lst:component}.
\begin{lstlisting}[style=java,
caption={This snippet of Java code represents the main interface that all components in Iris have to implement, and how dependencies get injected into the components at run-time. Backslashes indicate line continuations.},
label=lst:component]
package cfa.vo.iris;
import java.util.List;
import org.astrogrid.samp.client.MessageHandler;
public interface IrisComponent {
/**
* This method is invoked to initialize the
* component. If the component has to
* launch windows, frames or background
* services, this is the right method to do
* so. Otherwise the component will be
* called only if a callback is invoked.
* @param app A reference to the running application
* @param workspace A reference to the application's workspace
*/
void init(IrisApplication app, IWorkspace workspace);
/**
* Return the name of this component. This
* name might be listed in a widget along
* with the other registered components.
* @return The component's name as a String.
*/
String getName();
/**
* Get the description for this component. The
* description might be listed in a widget
* along with the other registered components.
* @return The component's description as a
* String.
*/
String getDescription();
/**
* Get a command line interface object for
* this component.
* @return A CLI object
*/
ICommandLineInterface getCli();
/**
* Initialize the Command Line Application
* interface
* @param app Reference to the enclosing
* application
*/
void initCli(IrisApplication app);
/**
* The component can contribute menu items
* and desktop buttons to the enclosing GUI
* applications by providing a list of
* MenuItems.
* @return A list of the menu items this
* component will contribute to the
* application.
*/
List<IMenuItem> getMenus();
/**
* The component can register any number of
* SAMP message listeners by providing a
* list of them.
* @return A list of the SAMP message
* listeners that have to be registered to
* the SAMP hub.
*/
List<MessageHandler> getSampHandlers();
/**
* Callback invoked when the component is
* shutdown
*/
void shutdown();
}
\end{lstlisting}
At startup the Iris application reads the list of Components to be initiated,
and calls their \texttt{init} call-back, which in turn is passed useful information
like a reference to the SEDManager, or hooks to the application environment.
The advantages of this architecture are both functional and non functional. The architecture
helped our heterogeneous development team to work in a loosely coupled way,
reducing the overall project risk, and also provided the extensible framework
we were seeking in the first place. As a matter of fact, plug-ins that can be
loaded at run time implement the same interfaces that the built-in components
do, and they are instantiated in exactly the same way. The only difference is in
the timing: built-in Components get instantiated when the application itself is
initialized, while plug-ins can be instantiated and discarded at any time during
the application execution.
\section{Iris Built-in Components} \label{sec:components} In the previous
section, we discussed the architecture of Iris and how the different Components
in Iris communicate. Each Component performs one or more SED-related tasks in
Iris, like building SEDs from multiple sources and fine-tuned SED modeling.
Here, we discuss what the Components do in terms of the science domain, including
descriptions of the autonomous software used to build
Iris: Specview, Sherpa, and the NED SED Service.
\begin{figure*} \begin{center}
\includegraphics[width=0.9\textwidth]{sed_builder.pdf}
\caption{\textbf{SED Builder.} An example view of the SED Builder. On
the left side of the window is a list of SEDs open for analysis; in this case,
\textit{FilterSed} is selected. The Segments or components that constitute
\textit{FilterSed} are shown in the Segments section. Segments may be managed
separately. Highlighted SEDs or Segments may be edited, removed, saved, or
broadcast to an external SAMP-enabled application. New Segments and SEDs are
added to the Iris session through the SED Builder. } \label{fig:sed_builder}
\end{center} \end{figure*}
\subsection{SED Builder}
Users manage SEDs through the SED Builder (Figure~\ref{fig:sed_builder}). From
the Builder, users can add, edit, remove, and save SEDs. Users can also transfer
data seamlessly to other VO-enabled applications through SAMP messages from the
Builder. Any number of SEDs can be analyzed in an Iris session. Each SED has a
unique identifier that is set by default when a new SED is created, but can be
changed by the user. The user switches between SEDs by clicking on a SED name in
the Open SEDs field; the visualizer will automatically update to the selected
SED.
SEDs are built and managed in Segments, which are groups of (spectral, flux)
coordinates. For example, a spectrum is considered a Segment; the results of a
NED SED Service query are also handled as a Segment. In general, anything from a
single photometric point to an entire SED can be considered a Segment, with all the
points sharing some if not all of the metadata.
Clicking on a SED in the Open SEDs field will show all the Segments that
populate that particular SED. SED Builder shows where the Segment data came
from, the recorded RA and Dec of the Segment, and the number of points in the
Segment. Segments can be handled separately from other Segments in the SED;
users can add, edit, remove, and save a subset of Segments selected from a SED.
\subsubsection{Importing data}
\begin{figure}[h!] \begin{center}
\includegraphics[width=\columnwidth]{IrisDiagrams.002.pdf}
\caption{\textbf{\label{fig:data_sources} Available Data
Sources.} Users may import data from the built-in
clients to the NED SED Service and the ASDC. Data may also be uploaded from
a local file, a URL, a SAMP message from a VO-enabled tool,
or through a custom file filter plug-in at run time.} \end{center}
\end{figure}
As described in Section~\ref{sec:overview}, Iris accepts data from a variety of
sources, and is lenient on the data format. Figure~\ref{fig:data_sources}