ESP-r: Computing platforms, compilers and code

• ESP-r uses a distributed source tree with modules importing common data structures, functions and subroutines from esrucom.


• ESP-r common code is organised by function - for example code to read, write, check and report on zone geometry is located in one source file and all modules import these functions and data structures.


• The library folder (lib) holds low level Fortran and C functions. Each library function and/or subroutine passess data via parameters only..Typically, a library libxesru.a is linked with each module at compile time.
• ESP-r uses libX11 function calls to implement its graphic interface. Access is via intermediate C functions in lib/esru_x.c. Conceptually these intermediate functions could call a different graphics library with few, if any changes in the Fortran code.
• Although some functions and data structures could be better documented, HTML browsing of the source distribution with cross links and extral documentation is supported.


• Fortran code controls the simulation data model and the composition of the interface (menus, dialogs, contextual help). C code draws the interface and reacts to user interactions and returns control to the Fortran.


• There is a tight coupling of interface and the underlying data model. One user action may result in changes to half a dozen model description files. Large chunks of the project manager are devoted to maintaining the contiguity of the model.


• ESP-r is disk intensive and a fast disk can be more important than CPU speed. Standard ESP-r has a moderate memory requirement. For many uses a low specification computer is all that is necessary or one high spec machine can act as a compute server for several users.


• ESP-r assumes that there is a /usr/esru/esp-r/bin folder which can be reached directly or via a link.

ESP-r modules

• aco (esruaco) - acoustic assessment post-processor
• bps (esrubld and esrubps) - the integrated simulator engine
• c2e (esruc2e) - utility which estimates pressure coefficients at points on simple building facades
• cfg (esrucfg) - establishes surface adjacency via geometric scan of model
• clm (esruclm) - climate analysis and conversion
• e2r (esrue2r) - translator and controller of Radiance visual assessments
• ecnv (esrucnv) - model conversion utility
• eco (esrueco) - life cycle and environmental impacts assessments
• grd (esrugrd) - defines 2D and 3D gridding as well as ground conduction
• ish (esruish) - shading and insolation predictions and viewing
• mld (esrumld) - micotoxin database support and analysis
• mrt (esrumrt) - calculates surface to surface viewfactors and sensor viewfactors
• net (esrunet) - creates icon based network descriptions
• pdb (esrupdb) - detailed plant system component management
• prj (esruprj) - the project manager
• pro (esrupro) - management of event profiles
• res (esrures) - results analysis module
• tdf (esrutdf) - management of temporal (short timestep data) files
• vew (esruvew) - hidden-line and wireframe model viewer
• dfs (esrudfs) - CFD flow solver (stand-alone)
• dbm (esrudbm) - database manager (next generation, work in progress)

Issues arising

• ESP-r is designed either to be used interactively or to be driven by a script (it expects standard I/O channels). The simulation engine has been adapted so that it can function in a fully silent mode for use as a DLL. This adptation is partial and other modules remain to be done.
• There is an upper limit to results file size (~1GB) beyond which some users have reported problems with results recovery.
• In ESRU we use a formal code syntax checking and QA procedure. Not all developers will have access to this syntax checker and not all platforms support the checker.
• There is sometimes a timelag in uploading the current code base to the http/ftp download site. Goal is to ensure that the download site is more up to date.
• ESP-r makes considerable use of common code to limit the number of lines of code and ensure consistent facilities. Some function calls are ubiquitious are there is a considerable intertia resisting changes in function parameter lists.
• There are a few data structures which are obsolete, but which have not been removed from the source tree. Similarly, subroutines associated with these data structures persist in the code and sometimes obscure the logic.

Last edited April 2005