Software Engineering

Software Engineering & Development

There is currently no software development team or any sort of formal support. For 20+ years CWP/SU has grown by slow accretion of student programs and patches with occasional bursts of activity by professors and industry scientists. The code is of highly variable quality, from very good, to fairly poor. One of the first orders of business for a software development team is to do some fairly basic cleanup to eliminate nascent bugs and make it easier to make significant changes.

As an example, there are get/put functions for accessing the trace header fields. Unfortunately, these are almost never used in practice. Instead the header members are accessed directly. Before an improvement like dynamic header definitions can be implemented, all the header references must be made to use the get/put routine. Once that work is done, the task of designing and implementing extensible, user defined dynamic headers becomes tractable.

Here are some short essays on the general topic:

• First Steps This is a brief discussion of the fundamental software engineering work needed to prepare for more advanced development work.
• What's Wrong This was a response to a discussion summer of 2010 about the future of CWP/SU.

These need significant work, but it's what there is at the moment. Generally there are several levels that contributions are needed:

Regression Test Development At the moment there are no regression tests being run. So minor changes can break things in unexpected ways. That's not fun if you've got a deadline to meet and you discover that a program stopped working. Any user is qualified to contribute to this effort. All that's needed is to create a suitable synthetic, demonstrate the operation of each of the options for a program and convince yourself that it does what the documentation says it does.

Basic Code Cleanup As outlined in First Steps. If you know how to edit and compile code you're good to go. Tedious work, but it has to be done before we can add cool features. As people do this they will gain a better understanding of the overall structure of CWP/SU. That will make it possible to execute more advanced and difficult projects successfully.

Code Porting There are several variants of SU in addition to the CWP flavor with quite a few valuable codes. Because of the common heritage, they are not very different. So once you understand the CWP flavor, it becomes pretty straight forward to merge them into the CWP/SU corpus.

Minor Enhancements There are lots of opportunities to add minor features. The hard part is what and how. What is best driven by paying attention to user posts to seisunix. How requires knowing what's already there at a fairly low level. Many new facilities are a minor change if you modify the right program and a major chore if you pick the wrong one.

Infrastructure Improvements This is the really difficult part. It requires a very solid understanding of CWP/SU, software engineering and computer science. At the moment this is impractical to even consider. Once there is a regression test suite and basic code cleanup is completed, it will be possible to discuss how to evolve SU in the future.

U of Houston Seminar

The notes for an SU based software engineering seminar to be held at the U of Houston next spring can be found below. The goal is to prepare the participants to be able to use and build on SU for their academic and professional work. This means learning both how to find and fix bugs and how to modify the code to provide new features when they are needed. This is very much a work in progress like the rest of the wiki.

Seminar Outline

John's thoughts re: S3

> The main reason that I never tried to set up a "develoment team" for
> SU is that SU hasn't been that big. It has been easy to handle developer
> contributions one at a time.
>
> Since there seems to be interest in forming a developer's team, I suggest
> that it is also time to consider creating a new processing system. I have
> been thinking about this for quite a while. Since there is some interest,
> here is what is going through my mind.
>
> Suppose that we were going to
> start from scratch and create SU today, in 2010. Let's call this new
> package S3, as this is the third generation SU (the first generation
> being Einar Kjartannson's "SY" package). Here is what I have
> been thinking S3 should be.
>
> 1) The original SU is left alone, and S3 would be a new project managed
>
>     on SourceForge. That way we won't be trying to change SU into something
>     radically different at the expense of users.
>
> 2) GNU license - This will allow us to absorb all of the Berkeley licensed
>
>     stuff in the current SU, as well as permit us to combine other GNU
>     licensed materials with S3.
>
> 3) new header design that supports SEG Y REV 1 (and whatever else) making
>
>     use of Reg's Line header stuff. However, I would propose that the
>     new header be bigger than 240 bytes, and that basically we follow
>     exactly the SEGY Rev 1 standard and put any S3-specific stuff
>     beyond byte 240.  So maybe a number like 256 bytes for a trace header
>     would be a better choice. We could include alternate ns and dt fields
>     for large datasets. Or another possibility would be to banish all
>     of the short integer fields from the S3 header in favor of ints.
>     The trace header stuff might be the most difficult to decide.
>
>     I am not so turned on by anything that would make the trace headers
>     variable-length. I think that a fixed-length header is easier to live
>     with.
>
> 4) Scientific libraries. The GNU Scientific Library seems to be a good
>
>     choice for a collection of scientific libarary functions. The downside
>     is that the developer's of this package seem to have chosen to emulate
>     the Numerical Recipes in C "matrix" and "vector" dynamic allocation
>     schemes and to have  at 1 instead of 0 as is common in C. I would
>     probably create wrappers in S3 that would allow us to use SU style
>     allocs and let the user see arrays starting at 0 instead.
>
> 5) we should be able to combine the contents of the current SU, as well
>
>     as contributed packages, and other GNU, CPL, or Berkeley packages
>     out there.
>
> The upside is that if S3 works, then eventually we will have
> an "SU" for the 21st century. If it folds, then we will still have SU
> undamaged by the experiment.
>
> Your thoughts?
>
>                                 -John

Link title