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.

Back to the software engineering process side of things - as mentioned in previous post the plan is to build the document set around;


http://en.wikipedia.org/wiki/Dynamic_systems_development_method

and the functional, data and physical models outlined in;

http://en.wikipedia.org/wiki/View_model#Three_schema_approach

References for two of these models are;


Functional Model = http://en.wikipedia.org/wiki/Function_model specifically Functional perspective section.

Data Model = http://en.wikipedia.org/wiki/Data_model

Now the job is to figure out exactly which elements of these can be best used to help represent the code. Not all of these models are appropriate for this form of scientific programming. Especially when the coding uses an ODE solver which for me feels like the code operates in more of an Object Oriented mode - where the objects are based around the physical forces acting on the ship. More on this later.

Forgot to say THANK You!

Resolution of the % conundrum - thank you to;

Lancaster University computer science guru - LU-GURU - you know who you are.
Bambofy - who had the answer at the outset but I didn't believe him - sorry!
F-GURU for making me feel I wasn't the only one struggling with the %

which now I can see is clearly a really good addition to the language - good learning point!

Enlightenment from Wikipedia - eventually!

Derived data types

For derived data types, the form of the type must be defined first:

TYPE person
   CHARACTER(10) name
   REAL          age
END TYPE person

and then, variables of that type can be defined:

TYPE(person) you, me

To select components of a derived type, % qualifier is used:

you%age

Literal constants of derived types have the form TypeName(1stComponentLiteral, 2ndComponentLiteral, ...):

you = person('Smith', 23.5)

which is known as a structure constructor. Definitions may refer to a previously defined type:

TYPE point
   REAL x, y
END TYPE point
TYPE triangle
   TYPE(point) a, b, c
END TYPE triangle

and for a variable of type triangle, as in

TYPE(triangle) t

each component of type point is accessed as:

t%a   t%b   t%c

which, in turn, have ultimate components of type real:

t%a%x   t%a%y   t%b%x   etc.

(Note that the % qualifier was chosen rather than dot (.) because of potential ambiguity with operator notation, like .OR.).

Fell at the first hurdle!

OK so have started to get my head around how the thing operates but a % sign has me wondering what it does - certainly wan't any % signs around last time I looked at a bit of FORTRAN!

An example is:

LocVel(ibody) % u_ship = XX(v_index+1)

I have had to call up the really old boys club - my F-GURU - for an explanation. I wait with baited breath!

I also discovered I don't know how to use Google in all this which was an addition to the learning curve! Even the great G couldn't find a % reference for me!

First contact

So I have started to look into the FORTRAN a little.

At this point I must say that I have been sent a batch of .for and .f90 files to try and figure out how the code operates. The software team that built the code have all left the organisation along with a batch of files and instructions on how to compile the lot into an executable that represents a marine navigation simulator - a bit like a flight simulator but for navigating and mooring ships. The code has a Visual Basic (VB) user interface which has levers and switches to represent the various ship controls. This VB interface sits on top of the FORTRAN core that calculates the physics of the various forces the moving ship experiences. That's everything from propeller thrust forces to wind, waves, drag and any tug related forces. This, along with a representation of the surrounding geography and any water flow details allows simulation of a port environment within which the user can manoeuvre the ship in to the dock.

So - the first issue relates to the use of a FORTRAN differential equation solver in a real time simulation environment. Certainly not seen anything like this set up before personally! Now need to have bit more of a delve into the code to see exactly how this is set up.

Struggling with the learning curve!

Well

I started with checking out the status of current software design procedures. What a complete mess! I think the software design standards need a software design!

Surely there is a simpler view of what you need to design a piece of software - my first port of call was Wikipedia - which thankfully gave me a quick route to reviewing what has gone on in this field.

My plan was to decide upon a set of standards to work to while reviewing a FORTRAN package (a big one) where there was no documentation. The intention being to use the standards to help build up the document set. But blimey - there is just one confusing interlinked mass of information. I waded through most of the 'relevant' approaches but there is absolutely no way a relatively new starter would be able to fathom that lot out. Just type 'software design' into Wikipedia and experience for yourself!

Anyway to cut a very long - and possibly grumpy old man - story short I have decided to undertake the assessment and documentation based around the following;

http://en.wikipedia.org/wiki/View_model#Three_schema_approach

http://en.wikipedia.org/wiki/Dynamic_systems_development_method

which seem to encompass much of the structured methods - as long as you follow them that is - needed for the FORTRAN code I am looking at!

So - onward and upward!

Back to the future

This blog is hopefully going to be about my re-education in FORTRAN programming and software design after 25 years of inactivity!

Why bother - I'm interested and we are getting quite a few requests within our business for people who understand FORTRAN as staff  'exit' organisations leaving the organisation without anyone who understands the code. Guess - given the age profile - that, in the best scenario, means older staff with the skills are retiring!