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!