PSLAM is a FORTRAN code used to compute a steam power plant's performance using the exergetic analyisis pertaining to the second law of thermodynamics. The program output presents tables with the state properties of the cycle under study, as well as the effectiveness in selected points of the process flow of each of the plant items.
PSLAM allows the user to analyze the plant performance under different operationg conditions. By comparing the results of the different operating conditions, the user can recognize the points where a better use of energy can be achieved.
IMPORTANT notes on
porting PSLAM
PSLAM is written in FORTRAN and is compileable by most FORTRAN 77 compilers. Some caution should be taken because PSLAM uses some of the older FORTRAN constructs. Most important is the need to assume that subroutine variables are saved across calls. Modern FORTRAN no longer assumes this is the case; however, most compilers have provision for this. One can explicitly request that local variables be saved by adding a "SAVE" command at the beginning of each subroutine. It is preferable to use a global save command, if available. (For example, the Motorola PowerPC compiler provides this as a compiler option flag.)
While PSLAM I/O is straight forward, when porting to the PowerMacintosh it should be noted that pslam is not configured as a standard Macintosh application. Thus file output happens directly, not through the Standard File Dialog. In addition, PSLAM's error messages assume a standard (e.g.,Unix like) console I/O capability. When compiling for the PowerMacintosh, it is necessary to link in a standard console library such as MPW's SIOW.
When PSLAM runs correctly, there is no console I/O; the output file is written directly. It is helpful to add some console messages to see progress; contact us if you need acopy of code which does this. (Similar comments apply to porting to the Windows environment.)
PSLAM gets an "A" grade as an engineering project, but a "D" grade as a software project. The code is not well structured and extremely difficult to follow. For example, GOTO is used extensively, and DO loops practically not at all. The bad news is that the code is not very easy to modify. The good news is that code written in this style is often very efficient; the GOTO construct closely mimics what is happening at the assembly language level. One consequence of this is that compiler optimization options are not very useful. (These make use of the ability to efficiently "unroll" Do loops.) We found little if any value in using optimization flags for PSLAM code with the Motorola PowerMac compiler.