Category Archives: ideas

ASCL at AAS 223

The ASCL will be at the AAS meeting in (not quite) Washington, DC next week; I’ll be handing out (non-glowing) pens like crazy at both the ASCL poster (255.25, titled You’ve Written a Cool Astronomy Code! Now What Do You Do with It?) and the Special Session (more information below) on Tuesday, too. I hope you’ll stop by the poster to say hi, talk codes, and grab a pen!

The AAS’s Working Group on Astronomical Software (WGAS) and the ASCL are holding a Special Session on code sharing that includes presentations and an open discussion. Peter Teuben and Robert Hanisch will moderate the session, which will be held on Tuesday, January 7, 2:00 to 3:30 in National Harbor 5, Gaylord National Resort and Convention Center.

The panelists and topics for the session are:

Benjamin J. Weiner, Occupy Hard Drives: Making your work more valuable by giving it away
G. Bruce Berriman, Maintaining a user community for the Montage Image Mosaic Toolkit
Gary J. Ferland, Cloudy – the non-equilibrium microphysics of gas and dust, and its observed spectrum
Daniel S. Katz, NSF policies on software and data sharing and their implementation
Erik J. Tollerud, The Astropy Project’s self-herding cats development model
David W. Hogg, Costs and benefits of developing out in the open

After the presentations, Peter will open the floor for questions and discussion; at the end of the discussion, Bob will summarize the themes and points and will close the Special Session.

We’ll be tweeting, too, especially during the Special Session on Tuesday: @asclnet or #asclnet. See you (in person or online) next week!

ADASS BoF working documents

Peter Teuben moderated today’s BoF, which asked participants to brainstorm ideas for dealing with three categories of concerns: factors which inhibit code sharing, factors which encourage sharing, and overall community issues. The questions were in yesterday’s blog post, along with a link to the introductory slides for the session. One of the questions posed was not selected for discussion; another was proposed by participant William O’Mullane (what tools are available for sharing code?).

Each discussion group discussed one of eight questions; people were given the opportunity to move to another group for a second discussion. Scribes captured the ideas and comments of participants; the resulting documents can be found by following the links below.

My thanks to Jessica Mink, Kimberly DuPrie, Omar Laurino, Mark Taylor, Bruce Berriman, Bob Hanisch, Kai Polsterer, and William O’Mullane for scribing, to Nuria Lorente for tweeting about the session, and to Peter Teuben for his leadership!

Please feel free to add your own comments directly in the documents!

Messy code
Google doc

Expectations of support
Google doc

University policies
Google doc

Recognition by citation
Google doc

 Impact
Google doc

Journals and funding agencies
Google doc

Community at large
Google doc

Tools for sharing code
Google doc

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

 

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.)

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?