Supervision: Atanas Atanasov and Konrad Waldherr
Ravikishore Kommajosyula and Xiao Xue did their honours project at the Gesellschaft für Anlagen- und Reaktorsicherheit (GRS).
They were supervised by Joachim Herb and Fabian Weyermann.
Project Description
Over the years, large scientific code packages have been successfully developed using FORTRAN. Today, maintaining and extending these codes is a challenging task and often forbids several possibilities. Rewriting legacy code packages is almost prohibitive due to lacking resources and inertia against changing functional codes. One way of tackling these challenges is to integrate scripting languages into existing codes thereby retaining performance-critical kernels in FORTRAN and add an interface to a flexible, dynamically typed scripting language. Amongst the scripting languages, Python stands as a forerunner, especially due to the availability of scientific packages such as NUMPY and SciPy. In this project, an interface to Python is developed for a thermal- hydraulic simulation tool ATHLET [1], which is mainly used for nuclear reactor safety problems. The FORTRAN to Python interface generator tool (f2py) [2] is used in an innovative way to have access to FORTRAN subroutines and module variables from Python and vice versa. Standard interfaces for three purposes have been developed. The interfaces allow for processing the simulation results during the simulation, calling Python subroutines within a simulation time step and coupling external simulations with ATHLET. The result of the project is an easy-to-use Python Framework to a large FORTRAN code which is very low on overhead, provides standard interfaces and requires very little changes to the original code. This framework allows the user to extend the functionality of ATHLET, by writing new modules in Python and coupling with external simulation codes, without having to deal with the rigours of FORTRAN programming.
Results
The primary goal of the project of implementing a Python scripting framework in ATHLET has been accomplished. The Python framework with its standard interfaces has been designed to be quite generic, flexible, extendable, and, more importantly, efficient. To study the efficiency of the implemented interface, performance tests have been done on ATHLET in various scenarios to measure the overhead that is incurred by each of the interfaces.
Fire & Forget Interface
The runtime overhead due to the Fire and Forget interface is measured by comparing the runtime of the base ATHLET code with no Python function calls to ATHLET code which uses the Fire and Forget interface to implement live plotting of the simulation results. The results are presented in Table 1.
Table 1 – Fire and Forget interface runtime measurements |
|||
|---|---|---|---|
| Scenario | ATHLET – Base Case |
ATHLET – with live plotting |
Runtime Overhead |
| Small Input file |
7.796 s | 8.46 s | 0.664 s |
| Larger Input file |
37.43 s | 38.69 s | 1.26 s |
The runtime overhead for the Fire and Forget interface is quite small and grows very slowly with increasing problem size. This is due to the fact that the time required for setting up multiprocessing is significant and gets evened out when the problem size grows.
Strong Coupling Interface
To calculate the runtime overhead due to the Feedback interface, two versions of the ATHLET code are made, where the heat-transfer-coefficient-calculation is done in FORTRAN in one version and the same calculation is done in Python in another version. This can be done by writing out the subroutine in Python using the Feedback Interface. The runtime of ATHLET code using the FORTRAN version are compared against the ATHLET code using the Python version of calculating the heat-transfer-coefficient, and the results are provided in Table 2.
Table 2 – Feedback interface runtime measurements |
|||
|---|---|---|---|
| Scenario | Runtime | Additional Function calls |
Data transferred in each call |
| ATHLET – base code |
7.796 s | 0 | 0 bytes |
| ATHLET with strong coupling |
8.942 s | 208520 | 5 doubles |
The runtime overhead for the feedback interface is quite low considering the fact that there are a lot of additional function calls being made and data transferred. The overhead should get better as the Python functions get more compute intensive. To analyze the impact of the amount of data transferred, the scale up of runtime overhead with the transferred data is presented in Figure 1. The runtime overhead scales only by a factor of 2.5 when the amount of data transferred is scaled by a factor of 16.
Conclusions
The challenges of maintaining and extending a legacy FORTRAN code have been addressed by implementing a Python scripting framework to ATHLET. Standard interfaces to Python provide a way to extend the functionality of the existing FORTRAN code, without having to deal with the rigours of FORTRAN programming. The Python framework can be used to extend the capabilities of ATHLET in the following ways: allow the user to monitor the simulation results during the simulation (Fire and Forget interface), write new modules in Python (Feedback interface) and couple with external simulation codes (Coupling interface). This was demonstrated by adding a live-plotting utility that plots the results of the on-going simulation, developing a new heat-transfer-coefficient-calculation model and coupling a dynamic valve model [3], which governs the opening or closing of the check valve by solving a differential equation. Efficient implementation of the interfaces ensures that the runtime efficiency of ATHLET with extended capabilities is still comparable with that of the native application. The library-based implementation of the Python framework allows for re-using the framework on a different FORTRAN code.
Presentation and Publication, Best Paper Award
The project has been presented at the 5. IEEE Germany Student Conference. We refer to the related abstract. This contribution has been honored with a best paper award.
References
[1] ATHLET-Overview
[2] FORTRAN to Python Interface generator (f2py)
[3] Z. Pandula, G. Halasz, “Dynamic model for simulation of check valves in pipe systems”, Periodica Polytechnica ser. Mech. Eng. Vol. 46, No. 2, PP. 91-100 (2002)