WinFPT - Physical Units and Dimensions in Fortran Code

	SimCon - Fortran Analysis, Engineering & Migration	\| FPT Reference Manual \| Downloads \| Licensing \| Home


	Research Academic Collaboration Current Research

	Fortran Tools Capabilities - what the tools can do The WinFPT Graphical User Interface Code Quality Assurance QA Tutorial Code Metrics Report Generation Standardising Code Obfuscating Code - making it unreadable Correcting Errors Automatically Migrating between hosts Migration Tutorial Gould-SEL Migration VMS Migration Tracing Execution and Relative Debugging Record/Replay at Interfaces Adding Interactive Controls to a Program FPT Command Reference Manual Updates and Release Notes

	Services

	Associates

	Behind the Photos

Research - Physical Units and Dimensions

Automatic Analysis of Physical Units and Dimensions

SimCon is carrying out research to develop an automatic system to analyse and check the physical units and dimensions of real and complex variables in a program.

For example, suppose a program uses the real variables V, I and R. WinFPT examines the equations in which they occur, and finds a relationship V = I * R. This indicates that the units of V, units(V), are equivalent to units(I) * units(R). WinFPT does not "know" that V is measured in volts, I in amps and R in Ohms, but it can check that these units are always used consistently in this way. It can report violations, and it can propogate inferences about units between different variables. For example, if it finds that I = I1 + I2, then I1 and I2 must have the same units as I.

Analysis of Variable Lives

There is an initial step in the analysis of units, which we term the analysis of variable lives. If two different routines each has a local variable, x, which is not shared in a module or COMMON block, the two variables are independent and there is no requirement that they have the same units (Though a user might be interested to know if they do not!). However, there are also cases where a variable is used in two or more independent contexts in the same sub-program. For example:

DO i=1,20 READ(1,'(F14.6)')x (1) sum=sum+x x = x**2 (2) sumsq=sumsq+x ENDDO

The x assigned at (1), x<1>, has the same units as sum. The x assigned at (2), x<2>, has the same units as sumsq. The values can never interact, because x<1> can never be used instead of x<2> in any context. In fact, we note that the units, units(x<2>) are equal to units(x<1>)**2. The meaning of the program would not change if x<2> were renamed "y". We say that x has two independent lives, and that the lives are not required to have the same units. This issue is explored in the paper "Dimensional Inference Using Symbol Lives" presented at the SETP 2007 conference.

The analysis of lives was completed in the release of WinFPT 3.6-a. An experimental analysis of units and dimensions has been released for evaluation by CSC at Airbus Filton. We expect this to be an extremely powerful diagnostic tool.

Labelling the Units

FPT can make a more meaningful report if units are labelled. It is far clearer to report that the units of i1, i2 and leakage_current are "amps" than that they are "units(i)". Commands are available to give meaningful names. However, there is no requirement to do this. The user does not have to work laboriously through a list of variables giving labels to everything. FPT should find the objects with the same units, and report any inconsistencies.