Software:GEOPHYSICS source-code guidelines

From SEG Wiki
Jump to navigation Jump to search

Geophysical Software and Algorithms papers must describe a useful algorithm for solving a problem of geophysical significance. Papers should describe a problem, how the algorithm is meant to solve the problem, and the workings of the algorithm itself. Well documented ASCII source code must be included as part of the submission, along with sufficient supporting files to allow computer-literate readers to run and verify the code. The source code and supporting documentation do not need to be included in the text of the paper itself, but will be reviewed as an integral part of the submission.

The algorithm must be the focus of the code. We hope that GEOPHYSICS papers will still have some value decades hence. Similarly, the code that goes with the paper is meant to serve as an example of the algorithm described in the paper. The code should be readable, comprehensible, and useful as a reference well into the future, just like the paper. Just like the paper, the code is a "snapshot in time" documenting the work. (Note there is nothing stopping you from also maintaining a living, evolving version of the code elsewhere.)

The "have some value decades hence" requirement is an important one. Code should not be strongly tied to a particular architecture. In particular, code that consists of 95% graphical user interface and 5% geophysics is unlikely to be valuable decades hence.

The focus of the paper needs to be about the algorithm. The paper should not be a user guide for a particular implementation of it. If your code is a complex software package that will require maintenance updates to remain useful into the future, then your code probably doesn't belong in this section. If your paper includes figures that are screen snapshots of a user interface, that's a big hint that your paper may be a user guide, not a technical paper about an algorithm.

Do not include binary files in your submission! This explicitly includes any kind of binary executables, libraries, Matlab ".mat" files, or binary data files. SEGY binary data files may be included, however. Why this prohibition? Binary files cannot be easily reviewed. Who knows what mischief they might contain? They are also typically not portable, either to other machines or into the future. In some cases pdf or standard graphics format figures may be acceptable, but do not include binary executables or library files, even as an ``optional extra. If there are any potentially risky binary files in your submission, it will be returned to you without being sent out for review.

If you need to wrap up your submission into an archive file, please use zip or tar format. On Windows PC's, "rar" format is becoming increasingly common. Sorry, it is a proprietary format, and thus many reviewers (and also your editor) cannot unpack it. If you have more than say two or three files, please pack them using zip or tar as a courtesy to the reviewers.

If your code depends on a software environment like "Madagascar" or "SU", please include just your unique contribution. You don't need to include the standard parts of the software environment. However, you really do need to include your unique contribution, even if it has already been incorporated into the software environment's downloadable package. You can't just include a pointer to a package held elsewhere, as that is not in the SEG's control and could change at any time. The SEG has to have control over what the reviewers are reviewing.

The computer code must not have any copyright or security restrictions preventing its free and universal distribution over the internet. Any patents covering the algorithm must be documented and any limiting terms of use clearly specified. If parts of the code are copyrighted, that fact needs to be clearly marked and the limitations of that copyright honored.

Papers in this section have a different standard of originality than papers in other sections. The problem description, the solution method, the algorithm, and the source code may each have been published elsewhere before, but the combination of all of these together must represent a new and unpublished contribution.

Papers in this section also have a higher standard of review than papers in other sections. Not only must the paper pass review, the accompanying code must as well. In particular, the reviewers must be able to understand how the provided source code works, and successfully use it to reproduce at least one result (either a figure or a table) in the paper.

Here are some detailed questions and answers; submitters and reviewers should read this.

This URL has been set up for use by an outside organization.

If you have questions, please contact the SEG Web Group, or the page maintainer, Joe Dellinger.

Return to the home page.

Return to the SEG home page