George L MesinaRELAP5-3D Development Team
Progress Report: Fortran 90 Conversion
RELAP5 International User SeminarNov 6-8, 2007Idaho Falls, ID
Introduction
• Goals & Benefits (User and Developer)
• Phases of FORTRAN 90 Conversion
• Progress and Measurements
• Conclusion
Thanks to Contributors
The following have spent several months on the project each:
• Dr. Richard Riemke: Consulting, some conversion
• Dr. Walt Weaver: Convert kinetics & PVM, consulting
• Nolan Anderson: Convert scratch & fluids, clean-ups
• Richard Wagner: R- and I-level subroutines
• Peter Cebull: Fluid properties
• Summer students: Restructuring
Usefulness of Conversion Task
• User considerations
– Machine independence via F90 intrinsics
– Eliminate memory restrictions
– Modernize code for longevity considerations
• Development team
– Modernize language to ease transition of younger programmers into team
– Make code easier to read and understand
Task Overview: Original Scope
• Remake database
– Analyze and reorganize data layout
– Create modules with new layout in F90 constructs
– Create internal subroutines for the data
• Allocate, eliminate, restart (R&W), transfer, etc.
• Convert transient source code
– (Streamline)
– Convert code to use module data
– Apply Fortran 90 constructs
Task Overview: Revised Scope
• Eliminate container array, FA
– Convert input-read, input-processing, transient set-up, and restart-plot file source code
– Replace FA-indexing with use of ordinals where possible
– Elsewhere replace arrays of F90-pointers from SCNREQ with arrays of ordinals or F90-pointers
• Convert environmental library subroutines
• Convert fluid library subroutines
Fortran90 Conversion Major Tasks
• Database conversion
• Transient conversion
• Restart-plot conversion
• R- and I-level conversion
• Environmental conversion
• Fluids conversion
Database Conversion Progress
• Converted all fixed-length COMDECK files
– 114 files into 52 modules
• Categorized all variable-length databases (FA-files)
– Simple (11) – single stride
– complicated (3) – multiple strides & structures
– complex (19) – No fixed strides, conditional data
– eliminated (10) – Not in use anymore
– absorbed (2) – Put in module of another database
– postponed(2)- To be converted when needed
Database Conversion Progress
• All named databases converted into modules
• Module high-level structure
– Data reorganized and declared (section 1)
– Documentation (section 2)
– Internal data-related subroutines (section 3)
• Restart (Read & Write)
• Memory Allocation and deletion
• Transfers (between module & FA)
• Sometime more (size, ordinal, etc. )
Database Conversion Progress
• Most unnamed databases converted to modules
– Same module structure
• Two unnamed databases remain to convert
– Files 40, 42 (in 2 and 1 subroutines respectively)
• Total modules will be 90.
Transient Conversion Progress
• 94% (798 of 849) transient “conversions” performed
• “Conversion” of subroutine A for module B means subroutine A now uses module B’s data, not the related COMDECK data
– All arrays of related COMDECK replaced by corresponding module derived types
• Remaining conversions primarily include
– Scratch, PVM phase 2
– Elimination of FA-indexing
– Solver-related conversions
Transient Conversion Progress
• Scratch conversion by new method: Array-by-array
– Each array will be converted in all the subroutines that use it.
• Three phases
1. Arrays used in one subroutine only (192)
2. Arrays used in exactly two subroutines (162)
3. Arrays used in multiple subroutines (256)
• Create transfer routines between FA & module
Transient Conversion Progress
• Two kinds of FA-indexing to eliminate
1. Pointers from one database to a single database
• E.G. Holder array, Junction to “from” volume
2. Pointers (randomly) to any database
• E.G. PVM, minor edit, plot variables
• First kind replaced in subroutine that calculate FA-indices with calculation of ordinal
• Second kind replaced by replacing SCNREQ calss with calls to IREQUEST
Transient Conversion Progress
• All solver related data must be built and accessed in module data.
– BPLU data to modules
– Source code that builds it converted
– PGMRES and MA18 must access module data
• Via call sequence for MA18
• Direct to module for PGMRES (low priority)
Restart-Plot File Conversion
• New format for ease of use by peripheral programs
• Modules for variable-length files
– Complex routines with much safety checking
– All written except kinetics and PVM
• Fixed-length modules
– Must write restart read & write routines
– Will be automated and handled by program
• Testing has not been done for all of them
R- and I- Level
• Initial modifications
– CVIC, SQOZ, UNSQOZ modified
– INP turned into a module and converted
• Eliminates need for FTB routines
• All R-level routines changed to use new INP
• Initial R-level routines
– User-var, time-step, minor edits
Environmental Done
• Restructured and documented better
• Many routines simplified
• Converted to Fortran 90
• Common coding abstracted in to utility routines
• All conditional coding replaced or moved into either modules or one service routine
• Environmental routines from RELAP-directory brought into environmental directory
• Installation scripts improved
Fluids Directory
• Not started
• Primarily involves restructuring and converting to Fortran 90 free-format
• Mostly handled by automated software
Plan to finish
• Needed for upcoming Developmental Assessment project
• Planned conclusion: May 2008
• Probable version 2.7.8
• Completion report includes timing data
Conclusion
• Fortran 90 conversion will improve RELAP5-3D in numerous ways
• The project is nearing completion
• There are numerous interesting tasks remaining
• The code will be ready for the DA project