AAS JOURNAL AUTHOR INSTRUCTION UPDATES
The AAS Journals, guided by a Task Force on the Future of our Journals, are undergoing important changes that will affect the way authors prepare, submit, review, and publish articles. Concomitant changes to the author instructions on this page are forthcoming. If you have questions about appropriateness of the extant instructions then please email our Authoring Support team <firstname.lastname@example.org>.
The journals of the American Astronomical Society (AAS) encourage authors to exploit the capabilities offered by the electronic medium to enhance articles published in The Astronomical Journal ( AJ) and The Astrophysical Journal (ApJ) with the inclusion of content (at an additional charge) that cannot be incorporated in the print versions of the journals. Such content includes extended data tables that are useful only in machine-readable form and various forms of online graphics that would be impractical or too expensive to reproduce in printed form. Note that online-only materials are subject to the same peer-review standards as the articles as a whole, and their inclusion should be justified on scientific grounds. Articles should also stand on their own scientifically without the online-only materials.
It is in the best interest of both the author and the reader to move lengthy tables to the online edition in the machine readable table format. Machine readable tables (MRTs) consist of formatted ASCII data with a meta-data header that utilizes the same standards and styles as in CDS's Vizier tables. tables. When tables are longer than ~200 data rows, authors are strongly encouraged to take advantage of the MRT format by making their tables machine readable in the online edition. Tables longer than 400 data rows will only appear in full in the online edition. unless an exception has been granted by the Editor-in-Chief. In either case, the complete data set will always appear in the online edition in the MRT format, while the first 5-10 lines of each table will appear in the print/pdf edition. (For the ApJL only, there is a limit of one machine-readable table per Letter and a lower limit of 50 data rows for becoming an online-only table.)
Authors who require machine-readable tables should request this at the time of submission, and must include the data with the submission so that it can be evaluated during the review process. The data should be either raw ASCII (formatted or delimited) or in the form of a LaTeX table. Word/RTF users should save the table as a tab-delimited ASCII file. It is desirable to include information regarding the format, units, and a short description of each column when an ASCII table is submitted. The machine-readable table standards can be found HERE.
Conversion to the MRT format will be done after acceptance but before the paper is sent to the publisher for production. Authors will be queried at this point to "proof" the resulting MRTs. Authors may also attempt to create their own machine-readable tables using a web-based converter. When submitting, authors should name the ASCII tables tab#.txt, where # is the table number. Author created MRTs will be verified at acceptance and may also require "proofing" if significant changes were required to maintain the AAS standards and styles.
For each online-only table the author must consider how its corresponding version will appear in the main article. These tables give readers an idea of the format and content of the full data set in the electronic edition. In the majority of cases, the "stub" table should be the same as the full table but with only the first 5 to 10 lines of data shown. The following text should be included in the table notes:
"Table X is published in its entirety in the electronic edition of <>, A portion is shown here for guidance regarding its form and content."
The author is responsible for creating the stub version of the table, and it should be included in the manuscript. All stub tables should be cited and numbered as if it were a full table.
In the rare cases in which the tabular data are so complex or wide that an example table is not practical, authors have two options: (1) show only the most significant columns in the stub table with a table note describing additional data available online, (2) make a table "key" that provides information about each tabular column. An example of Option 2 can be found in Schneider et al. 2010, AJ, 139, 2360, where Table 1 provides a key to the full data sets for Tables 2 and 5.
For further information, authors are urged to contact the AAS Journals' Staff Scientist, Dr. Greg Schwarz.
Online-only figures are intended to provide supplementary information that is not critical to the scientific content of the paper but that provides additional useful information for the reader. They are not allowed when the figures are an integral part of the paper, or simply to limit page charges. Such materials will carry a nominal publication charge depending on the number and size of the figure files, but again this will be a small fraction of the cost of printing the same volume of material. Note that online-only materials are subject to the same peer-review standards as the rest of the manuscript, and their inclusion should be justified on scientific grounds.
Note that supplementary online figures are not permitted in the ApJL.
Online-only figures must be numbered according to standard figure numbering rules, and must be numbered in sequence with the rest of the figures appearing in the paper. Large figure sets should be numbered as parts of a single figure in the format 1.1 ... 1.n or 1a ... 1z rather than as a run of individually numbered figures. At least one figure in a series must be displayed as an example figure for the print version. The example figure caption should include the note: "Figures 1.1–1.n are available in the online version of the Journal." Authors should clearly indicate in their readme file when submitting which figures are to appear only in the electronic version. If each component of an online-only figure has its own figure caption, the captions should be included in a separate LaTeX file called efigscaptions.tex. Further details about Figure sets and a web-based tool for creating them are available.
Finally, note that, while The Astrophysical Journal Supplement Series welcomes the submission of substantial astronomical data sets for publication, enormous compendia of uninterpreted data are best archived in an astronomical data center. We continue to work on establishing effective cross-linking between scientific papers and the supporting data.
Animations in the form of mpeg files can be included as, or to accompany, figures in articles in the online version of the journal. This can be especially useful for papers that present the results of numerical simulations or calculations. The animation file should be numbered as a figure in the normal run of figures. The author should also provide a clean, separate copy of a single still frame or set of frames to appear as the figure in the print version.
Authors may elect to post any of their source code pertinent to their paper. The code can be written in any language, but extremely long and complex programs with numerous subroutines are not appropriate. Executable files are not accepted.
Note that the ApJL does not permit source codes.
Authors wishing to submit source codes as a part of their paper need to be aware of the following:
- Codes often change, but the published materials in the journal do not. Authors cannot update their code or fix bugs for codes published in the online version. However, authors may include a URL in the paper to link to updated versions of the code. (AAS journal policy is to not live link URLs to outside websites due to their potentially transient nature and the rapidly changing landscape of the world wide web. However, some exceptions will be made for links to data or information at permanent sites such as the major data centers. This policy should not discourage authors from printing URLs in their papers.)
- Source codes that use copyrighted material cannot be posted with the copyrighted material included (e.g., a code that uses Numerical Recipes subroutines of Press et al.). In these cases, the author must exclude any copyrighted material and include a statement explaining where and how the missing material can be obtained and implemented into the code.
- Authors must sign a fair-use agreement along with the usual copyright release form. The fair-use agreement puts the copyright of the software in the author's name, via a GNU general public license, to make it freely available while protecting the author's rights.
Authors should attach the following metadata header to their source code. The metadata header provides information to the code users to help them compile and use the code. Authors should provide information, when appropriate, for each line of the metadata header given below. The information between the "[ ]"s provides instructions and examples for the author and should be removed before submission.
Code names: [e.g., program.f]
Language: [e.g., Fortran 77]
Code tested under the following compilers/operating systems: [e.g., gcc/Linux]
Description of input data: [include units and formatting]
Description of output data: [include units]
System requirements: [e.g., minimum floating point precision]
Calls to external routines: [e.g., SIMPLX.F from "Numerical Recipes'' by Press et al.1992]
Additional comments: [e.g., Program calculates the minimum of a function]
The AAS gives permission to anyone who wishes to use these subroutines to run their own calculations.
Permission to republish or reuse these routines should be directed to email@example.com.
Note that the AAS does not take responsibility for the content of the source code. Potential users should
be wary of applying the code to conditions that the code was not written to model and the accuracy of the
code may be affected when compiled and executed on different systems.
For any additional questions, authors are urged to contact the AAS Journals’ Staff Scientist, Dr. Greg Schwarz.
If the source code contains numerous subroutines files, all of the files can be packaged together and submitted as a UNIX tar file. The metadata header should then be included in the packaged file as a separate file called readme. All source code submissions should be called sourcecode.txt for a single program or sourcecode.tar for a tar file containing a series of files.