Eight questions…

… are being posed in the Ideas for Advancing Code Sharing (or A Different Kind of Hack Day) Birds of a Feather (BoF) session at ADASS. The eight questions ask how to deal with three categories of concerns: factors which inhibit sharing, factors which encourage sharing, and overall community issues. The questions are below; do you have answers to them? Please share them if you do!

The introductory slides for the BoF are available online. We will post what comes out of the discussions shortly after the BoF.

Mitigating inhibitors
How do we encourage release even if the code is “messy”?
How do we reduce expectations of support when coders don’t want to support code and still encourage code release?
How can universities be convinced to change policies which prohibit software publication?

Increasing incentives
What can we do to encourage citations for codes?
Beyond citations, what can we do to give code authors recognition for writing and releasing their software?
How can we measure the impact of a code on research and its value to the community?

Community factors
What roles might journal publishers and funding agencies have in furthering code release, and how can the community influence them to take on that role?
What else can we do to have code release recognized as an essential part of research reproducibility

 

ADASS XXIII Poster

When Alice asked me if I’d like to present a poster at this year’s ADASS I jumped at the chance: After all, it was Alice’s poster and presentation at ADASS XXI that prompted me to volunteer for ASCL. Also, I don’t often get the opportunity to exercise my creative side, and what better way to give it a workout than to create a poster that will be seen by millions (ok, hundreds) of people. However once I started working on the poster I realized that my creative side had atrophied a bit due to disuse. With Alice’s coaching (“You know you can use more than one color!”) I managed to pull together a poster that I hope you find informative and eye-catching without being too wordy. If I’m really lucky I might even be able to snare another ASCL volunteer.

ADASS2013Poster1

ASCL at ADASS

The ASCL is participating in ADASS in the following ways:

Not going to ADASS but want to participate in the BoF session? We’d love to have your input and ideas. We’ll be running a Twitter feed running throughout the BoF  (follow @asclnet). What else might work for you?

Citations redux

I’ve recently learned that some citations to ASCL (and arXiv) entries are not caught by ADS because some BibTeX styles (.bst) don’t support the eprint field, which ADS uses when generating the BibTeX for ASCL and arXiv entries. The lack of support for the eprint field results in a citation that formats the ascl ID incorrectly; for ADS to be able to find and count the citation, the ascl ID needs to be formatted just as it appears in the code entry, e.g. ascl:1010.051 for NEMO. The arXiv site has a list of BibTeX styles that have been updated to support the eprint field, and Norman Gray’s nice urlbst code can add this functionality to existing .bst files.

(This information has been added to the Citing ASCL code entries page.)

Astrophysics Code Sharing II: The Sequel at the January 2014 AAS meeting

The ASCL, along with the AAS’s Working Group on Astronomical Software (WGAS), is coordinating a Special Session at the January 2014 AAS meeting. This session is scheduled for 2:00 PM on January 7, and will feature case studies on code release for AstroPy, Montage, and Cloudy in addition to talks on the state of code sharing and funding agencies’ policies.

The session will be moderated by Peter Teuben and Robert Hanisch; the speakers for this session are:

G. Bruce Berriman, NExScI, PAC, Caltech
Gary J. Ferland, University of Kentucky
David W. Hogg, New York University
Daniel S. Katz, National Science Foundation
Erik J. Tollerud, Yale University
Benjamin J. Weiner, University of Arizona

After the presentations, the floor will be opened for discussion on ways to encourage code sharing to improve the transparency and efficiency of research and mitigate the negative aspects of releasing code.

 

July and August 2013 additions to the ASCL

Twenty codes were added to the ASCL in July, and eighteen in August.

July:
AstroTaverna: Tool for Scientific Workflows in Astronomy
cosmoxi2d: Two-point galaxy correlation function calculation
CTI Correction Code
DustEM: Dust extinction and emission modelling
ETC++: Advanced Exposure-Time Calculations

FieldInf: Field Inflation exact integration routines
im2shape: Bayesian Galaxy Shape Estimation
ITERA: IDL Tool for Emission-line Ratio Analysis
K3Match: Point matching in 3D space
LENSVIEW: Resolved gravitational lens images modeling

MAH: Minimum Atmospheric Height
Monte Python: Monte Carlo code for CLASS in Python
NEST: Noble Element Simulation Technique
Obit: Radio Astronomy Data Handling
orbfit: Orbit fitting software

phoSim: Photon Simulator
PURIFY: Tools for radio-interferometric imaging
Shapelets: Image Modelling
SIMX: Event simulator
SOPT: Sparse OPTimisation

August:
APPSPACK: Asynchronous Parallel Pattern Search
BASIN: Beowulf Analysis Symbolic INterface
Ceph_code: Cepheid light-curves fitting
ChiantiPy: Python package for the CHIANTI atomic database
CReSyPS: Stellar population synthesis code

CRUSH: Comprehensive Reduction Utility for SHARC-2 (and more…)
GYRE: Stellar oscillation code
JHelioviewer: Visualization software for solar physics data
LensEnt2: Maximum-entropy weak lens reconstruction
LOSSCONE: Capture rates of stars by a supermassive black hole

MapCurvature: Map Projections
MoogStokes: Zeeman polarized radiative transfer
RADLite: Raytracer for infrared line spectra
SMILE: Orbital analysis and Schwarzschild modeling of triaxial stellar systems
SPEX: High-resolution cosmic X-ray spectra analysis

SYN++: Standalone SN spectrum synthesis
SYNAPPS: Forward-modeling of supernova spectroscopy data sets
THELI GUI: Optical, near- & mid-infrared imaging data reduction

Also in August, we added one very cool web resource, the NASA Exoplanet Archive.

How long should you keep your codes? And your data?

I’m currently working on a report for the Preserving.exe: Toward a National Strategy for Preserving Software summit held at the Library of Congress in May. My head is filled with the reasons and ways (and lack of ways) to save software discussed at the meeting, and by software, I don’t mean necessarily astrophysics codes, oh no! All kinds of software: mainframe HR software and VisiCalc and Doom and old browsers and dBASE and … well, everything.

This has dovetailed nicely, or perhaps alarmingly, with recent readings, including a blog post by Kristin Briney titled How Long Should You Keep Data? and the Retraction Watch post which inspired it, JCI paper retracted for duplicated panels after authors can’t provide original data, about a 2007 paper which recently had one figure retracted because the authors could not provide the data from which it was generated.

Jon Ippolito of the University of Maine was at the summit and wrote about it in his blog post The Ex-files: how long will our software last?

How long indeed? And if you wanted to retrieve data from 2007, would you be able to even if you had the data files? Would you still have the tools available to get into them? In astronomy, probably so; with FITS, astronomy is better off than many sciences. Elsewhere, maybe not.

How long will astronomy software last? That might be unknowable; perhaps a better question, then, is how long should it last?

Facilities and Codes in papers?

Today I was reading the draft of an upcoming thesis defense in our library, and noted the student in question had been using a nice number of codes to support her research. All properly referenced via footnotes, and even some routine names in a “typewriter” font to make them stand out.

Later that afternoon after the weekly graduate un-journal club talk she gave, we and another graduate student got to talking about the ASCL, and explaining to them the triad of paper/data/code that one can view as the three ways our research is now peer review published. In fact, if you look at some recent publications, just after the Acknowledgements, you can find a “Facilities:” line, in which the various facilities (read: observatory/instrument pairs) are listed from which the data in this particular paper were used. We in ASCL have been suggesting that one should add a “Codes:” line as well, with (ASCL) codes used in the paper. Now that ASCL entries are searchable via ADS, there is no reason not to make searching for codes in papers easier. In fact, if you look at the next ADASS conference proceedings, you will find a separate ASCL index in the back of the book!

What do people think, should we ask the editors of journals to make this “Codes:” line a standard feature of papers?