Code Manual for CONTAIN 2.0 - Federation of American Scientists

could consist either of significant changes required to complete the original update, or could
incorporate fixes to miscellaneous small errors. Such errors could pertain to more than one update.
As update sets are developed and frozen (see Section D.2.3), the revision manager adds them to the
developmental baseline. The developmental baseline thus consists of the most recently released
operational baseline in the form of a CMP program library plus all frozen update sets for the next
operational baseline. When all update sets have been frozen and tested, they are added to the old
operational baseline to create the new operational baseline. Only then is the code ready for release.
At the time of release of the new operational baseline, the developmental baseline and the new
operational baseline are identical. The process of using CMP to maintain the code baseline is
depicted in Figures D-5 and D-6. A detailed data flow diagram of the conllgurat.ion control function
is presented in Figure D-7.
When all the update sets in a revision have been incorporated into the developmental baseline and
internal beta testing of all update sets has been completed to the satisfaction of the revision manager,
the revision manager notifies the integration tester to initiate integrated testing of the (now complete)
developmental baseline as a whole. When integration testing has been completed, the operational
baseline is updated by application of the complete set of revision updates. Testing is discussed at
greater length in Section D.2.6.
D.2.5.3 Co ntrol of Variant Codes. Once a large simulation code has been developed, it can be used
as a base to create codes for related applications. An example is CONTAIN-LMR, [Mur93] which
has been developed with foreign funding coordinated through the USNRC. Its base is the light water
version of CONTAIN with added features unique to sodium-cooled reactors. While there are
substantial advantages to using this approach, care must be taken in managing the quality control and
development of both the base code and the alternate codes. Each code sponsor’s needs must be
considered to ensure that work performed for the new customer does not create unnecessary
complications for the original sponsor.
If two codes have different procedures or standards of quality assurance, improvements in one may
not satis~ the needs of the other. Ideally, new features in a variant would be useful, or at least have
no negative effect, for the users of the base code. Incorporating variant features into the base code,
however, may impose a burden on the mainstream development process, since the more a code is
enlarged, the harder it is to maintain. If the complexity of the code also increases, then its
maintenance is even more demanding. For example, future improvements of the base code must be
tested against a variety of new problems, and the existence of these variant features complicates this
process.
When developing variants of the base code and performing updates of the base and variant codes,
the CONTAIN team follows a process designed to ensure that the new features do not interfere with
old ones. The CMP utility and CONTAIN’S code configuration control mechanism (described in
Section D.2.5.2) govern the relationship between the base and variant codes. A variant is
independently developed as an update of a particular base code version or revision. The update
Rev. O D-12 6/30197