10.1 Objective
The GFDL Modular Ocean Model was designed with one purpose in mind: to maximize scientific productivity within the research environment at GFDL. As indicated in the introduc-tion, the computational environment at GFDL has undergone change with each new computer procurement. To keep pace, efforts have focused on developing one model capable of taking advantage of scalar, vector and multiple processors within this increasingly varied computa-tional environment. At the same time, consideration has been given to organizing the model to allow a large number of options, diagnostics, and physics parameterizations to co-exist in a way that is understandable, extendable, and easily accessible to scientists. In one sense, the design was strongly influenced by having CRAY vector platforms as the computational workhorses at GFDL since 1990. Although changes have been introduced to take advantage of scalability on multiple processors, the focus has remained on factors that influence overall scientific productivity and the design continues to be motivated by a search for a better way to do science from the trenches of scientific programming. As such, the scientific generality and flexibility within MOM make it well suited for use by the general oceanographic commu-nity1. The following factors are considered to be important in maximizing overall scientific productivity.
10.1.1 Speed
In the past, speed was often thought of as being the equivalent of scientific productivity. In an operational setting where a model is rarely changed, it is justifiable to expend enormous effort to minimize wall clock time. In a research environment, it has become increasingly apparent that other considerations are important. This is particularly noticeable when changes introduced to take advantage of speed on a particular platform make implementation of science thereafter more difficult2. What is needed are changes which increase speed3but don’t reduce clarity. This is best met by using more appropriate numerical algorithms, more optimizing
1Optimizing for the idiosyncrasies in computer environments outside GFDL is left to the researcher.
2As in the Cyber 205 experience.
3It is reassuring that the ideas influencing the design of MOM have not significantly altered speed when compared to MOM 1. Early comparisons were carried out using the standard test case resolution of 4◦by 3◦and 15 levels. Changes in the external mode of MOM 1 were necessary to assure the same accuracy as in MOM and there were no diagnostics enabled. MOM ranged from 3% slower to 6% faster (depending on size of the memory window) than MOM 1. Minimum memory configuration in MOM was 1% greater than in MOM 1.
127
compilers, and faster processors. In the long run, straightforward coding is best. Tricky coding introduced to increase speed is often rendered useless by newer compilers. Worse yet, these tricks may be detrimental on other platforms. Ultimately, speed should be the business of compilers and better algorithms, not physical scientists playing games to beat compilers.
Two philosophies of model building can be summarized by first stating the intent and then asking a question.
1. The aim is to do as much science as possible with this model. Now, how can it be made to execute as fast as possible?
2. The aim is to make this model execute as fast as possible. Now, what science can be done with it?
MOM is the result of focusing on the first.
10.1.2 Flexibility
To be a useful research tool, MOM needs to be easily configurable in many different ways. Also of importance is access to a large number of parameterizations for intercomparisons within the framework of one model. Using preprocessor “ifdefs” gives this flexibility. However, they must be used wisely. Indiscriminant use of preprocessor “ifdefs” can lead to a tangled mess of limited usefullness. With time, more and more constructs within MOM will be replaced by their Fortran 90 counterparts which should allow for even greater flexibility.
10.1.3 Modularity
MOM is continually being infused with new ideas and the resulting growth can present prob-lems. For example, anyone who repeatedly changes or adds to a large model will appreciate that after time, the model can become unmanageable. At some point, inter-connectivity be-tween sections of code increases to a point where making changes in one place inadvertently breaks something seemingly unrelated. Further limitations become apparent when previously added code acts as a road block to new development. To a large extent, modularity has been used as the key organizational approach to solve this problem and its use is explained in Chapter 15. The other part of the solution involves resisting temptation to make changes in a quick and dirty way for short term gains which inevitably turn into long term hindrances.
Again, Fortran 90 with its well defined modules and interfaces should increase modularity.
10.1.4 Documentation
A good documentation aids in understanding the big picture as well as the little details which are necessary if a model is to be used and extended by many researchers. To this end, details of numerics right down to the subscripts within this documentation consistantly match what is found in the model code. This level of detail plus a straightforward coding style bolsters the scientific accessibility of MOM. It also provides another way of verifying that complicated numerics are correct. The manual should be considered a living document which actively reflects the current status of MOM as well as serving as a repository for details inappropriate for published papers and guidelines for usage of parameterizations. Therefore, understanding this manual will allow researchers to take a big step towards gaining a working knowledge of MOM.
10.1. OBJECTIVE 129 10.1.5 Coding efficiency.
Inevitably, the size of a research model increases with time. However, economy of code is always desirable. Voluminous coding to support issues which are not central to science accumulates and, if not restrained, starts to account for the bulk of model code. This practice is to be discouraged, although there is fine line to be drawn and the answers are not always unambiguous. When adding a new feature, the question to be asked is: How much code is this idea worth and can it be justified with respect to the prevailing level of scientific approximations being made? Some areas within MOM have become overly large and complex but with questionable4gain. As time permits, “dead wood” will be eliminated and simplifications will follow.
10.1.6 Ability to upgrade.
It is vitaly important for researchers to be able to incorporate code changes (which may be of interest personally but not appropriate for general dissemination) into newer versions of a model. It is in this way that researchers are able to take advantage of new parameterizations while retaining local personal changes. Also of importance is the ability to incorporate “bug”
fixes. In the past, both of these operations have presented significant difficulties. These difficulties have been largely eliminated by the tools and method described in Section 3.12.
4Cases in point were the old I/O manager and time manager modules.