You know I said ...

You know I said the 'structure constructor' % stuff was a powerful feature.

Well I guess it is but the use of it in the code I am looking at leaves the source code almost unreadable!

One line of 'old' FORTRAN format being taken up by - I am not joking - 5 lines of overflow coding in some instances.

I think I am going to have to write a code to decode the %'s - which is not such a bad idea - move all the % calls in one routine and just return a sensible variable!

Onward and upward ;-)

A map through the maze!

Many thanks again the folks on the LinkedIn Fortran Programmers Group for some great ideas on best practice for development and maintenance of Fortran code.

One specific pointer from Nils Van Velzen relating to an open source package called 'fordocu' has made a tremendous difference to understanding the complexities in the code and being able to trace variables through the  spaghetti!

Well worth checking out - the reference is;


http://sourceforge.net/projects/fordocu/

I will certainly be using this for all future Fortran development.

A documentation Rubiks Cube

Having launched into attempting to document the code a few interesting problems are coming out of the woodwork - one of them relates to how to document the data in a manner that can be understood in simple terms!

The plan is to document the following;

1 Process flow document in the form of a flowchart - easy one this one and very good for viewing the code without the clutter.

2 Documentation of the underlying physics and numerical modelling techniques - again relatively easy and can be linked to the flowchart in a logical manner.

3 Data documentation - absolute nightmare - the data structure is pretty difficult to follow without the added complication of spaghetti-like contortions of the variables throughout the code.

Need to come up with  simple way of 'viewing' these data flows.

All ideas welcome!

Another thank you!

Thanks to David Means for educating me on the use of Fortran (I now also know that its not FORTRAN any more but Fortran too!) in simulators. Quote from David from the Fortran users group on LinkedIn.

"Fortran was for a long time the industry standard language for flight simulation. I used it when I first got into that field in the mid-80's and continued with it until at least 2000. There are a *lot* of flight simulators still running on Fortran all around the world. 

The question is one of economics: If you've written code for, say, a 737, you've got a lot of money tied up in the development and testing of the software. So, your first sim is break-even at best. However, once you sign a contract for a second 737 sim, software development cost is minimal as you can just copy everything over from the first one and make minor tweaks as necessary. That's how flight simulation companies make their profits: by selling sims that they've already developed code for. Once you have a lot of sims running a particular code set, there is no incentive to convert it to a different language because a bug fix for one sim can be copied over and fix all the other sims running that same code set. 

So, Yes, I have heard of Fortran running real-time simulators. There are thousands of them around the world"


Thanks again!

Its all in the timing!

Trying to get my head round how the code deals with real time aspects of the simulation and have come across yet another new function for me! The code uses the ETIME function to monitor the actual run time - still tying to figure out how this is used within the code thought!

Anyway in my search for what this function does I came across the following definition - which I believe is courtesy of my old boss at the University of Florida (thanks Bob!).

Though Bambofy - again - told me what this function did before I checked - apparently its used frequently in gaming programmes!

FORTRAN Timing

Two functions ETIME and DTIME. let FORTRAN programs measure time. This is useful for perfomance tuning. They are used as follows:

REAL TIMEARRAY (2)

REAL  ELAPSE

REAL DEI.APSE

ELAPSE = ETIME(TIMEARRAY)

DELAPSE=DTIME (TIMEARRAY)

ETIME returns a real number which is the total CPU time used for this process it began executing. DTIME returns a real number which is the running time for this process since the last call to DTIME. Both procedures use TIMEARRAY to return the user time and system time separately; TIMEARRAY(1) reports the user time, and TIMEARRAY(2) supports the system time. For example, the statements

REAL DELAPSE TIMEARRAY(2), X

INTEGER I

X=1

DELAPSE =DTIME(TIMEARRAY)

DO 10 I=1, 100000

X=X+1/X

10        CONTINUE

DELAPSE=DTIME (TIMEARRAY)

set DELAPSE to the time required to compute the loop DO 10 1=1,100000.

A new Dimension

This activity is also turning into a crash course in fluid dynamics!

All calculations for velocity and force are subject to Dimensionless transformations. Dimensionfull calculations of the quantities are carried out to determine the forces action on the ship. These forces are then made Dimensionless prior to adding all of the contributions together. The transformations use the following normalisation coefficients.

All velocities normalised by;

Factor = SRQT(g_dim*L_dim)

(seems to be linked to Froude number Fr)

All forces normalised by;

Factor = v_dim*rho_dim*g_dim

(seems to be linked to Reynolds number)

Where;

g_dim = gravitational constant

rho_dim = density

v_dim = velocity

L_dim = scaled length

Comment: Assumption is that these transformations are performed so that straight addition of the values can be carried out without the worrying about which units the calculations are performed in. It also allows the ship position and velocities to be converted easily between Nautical and SI units (e.g. Knotts to m/s) within the VB code.

Magical Library Functions

Getting to grips with the mathematics of the code.

The two main routines are used to solve the equation set are;

DIVPAG - an IMSL routine used for solving the set of ODE's that drive the ship velocity and other rate dependent quantities.

and,

DLSLRG - a second IMSL routine used for solving a set of linear equations of the form F = m x a

which work like magic - as long as you feed them the right way - out pops the answer!

Still need to check that the ODE solver is not having to deal with varying simulator inputs while it is trying to home in on a solution.