Saturday, 31 December 2011

***** HAPPY NEW YEAR *******

Have decided what the next project on my road to recovery will be!

We have absolutely loads of Excel spreadsheets being created at our place with no proper control or checking on what is being done. Some of these things contain serious mathematical calculations - though the creators I am sure are not conscious they are producing such complex models.

So - what to do about it?

Look to convert some of these into a more controlled and structured environment. For big maths code that means Fortran in my world.

So that's my next project - first need to identify a sheet to check out feasibility of doing this!!

***** HAPPY NEW YEAR *******

Saturday, 24 December 2011

The final countdown.

All is complete and revival well underway.

Though the journey so far has been more about physics than Fortran!

A set of reports on the code have been produced covering;

1 Functional flowcharts of the routines - took a lot of time this one.

2 A data model - trace of the main parameters used in calculations back to the input screens and files - slog.

3 A report on future maintenance of the code - all things uncovered during the analysis included here.

4 A position paper detailing the calculation scheme usedand an initial assessment of the mathematical models used - mind bending.

The assessments have covered detailing  the main vessel movement forces;

FSPRING – buoyancy forces
ADDMAS – surrounding fluid resistance forces
FRCHULL – hull related forces
FRCPROP – propeller forces
FRCRUD – rudder related forces
FRCTHRU – thruster related forces

The basis for each of these forces has been outlined and referenced to experimental parameterisations have been made where possible. 

Flowcharts and data models for other forces have also related to;

FRCTUG – tug forces
FRCBANKSUCTION – bank interaction (suction) forces
FRCBLOCKING – forces related to navigation in a channel
FRCWIND – wind related forces
FRCWAV – wave related forces
FRCSLOWVAR DRIFT – slowly varying wave drift related forces
FRCLINE – mooring line related forces
FRCFENDER – fender related forces
FRCDBLFENDER – multiple fender related forces
FRCANCHOR – anchor related forces
FRCCHAINS – chain related forces
FRCWLEVGRAD – wave level gradient forces
PASSSHIP – passing ship forces
FRCWAVE – added wave forces
FRCWSIG – wave timeseries related forces
FRCCONV -  wave frequency convolution related forces

So. Not bad going for a few months work - thoroughly enjoyed it in a strange sort of way!!!

Not sure what happens next.....Merry Christmas and Happy New Year ;-)

Saturday, 17 December 2011

How it works.....very simple.....and clever!

DIVPAG solves an initial-value problem for ordinary differential equations using the ABM ODE solver method described previously.

Illustration of how the predictor - corrector ODE solver moves forward in a timestep. Values in the XX vector (only one element or vector illustrated) are interpolated to give an estimate of the XX element at the current time-step (prediction). The XX vector is then also used to calculate, along with the associated forces on the vessel, the corresponding rates of change of the XX values (DXDT). Integration of the DXDT values then produces a corresponding value at the current time-step (the correction). If the predicted and corrected values lie within a tolerance level then the solution moves forward in time. If they do not agree a the solver reduces the time-step and recalculates. This process is continued until there is agreement between the predicted and corrected values.

Almost there now.

Saturday, 10 December 2011

The heart of the matter.....

To illustrate how the Fortran code operates an overview of the differential equation solution mechanism used by the code is outlined below. This solution mechanism uses standard IMSL (International Mathematics and Statistics Library) functions to solve the equations of motions for the vessel under study both in navigation and mooring modes.

Two IMSL functions are at the core of the code, these are;

ñ     DIVPAG (Double precision IVPAG routine) which uses a predictor-corrector or Adams-Bashforth-Moulton method to solve the set of ODE's (Ordinary Differential Equations) that are used to calculate the vessel's various position and velocity parameters.
ñ     DLSLRG (Double precision LSLRG routine) which is used to solve the linear set of equations  for the various forces acting on the vessel using the equation set F =ma

Integration time-frame for ODE solution from
time T to TEND

DIVPAG called to determine solution of the 
XX system vector between T and TEND

DIVPAG uses FCMANVR to calculate derivatives of 
XX which it stores in DXDT vector at intermediate time-step 't'

FCMANVR combines all vessel forces and uses DLSLRG 
to solve F=ma for velocity components at intermediate time 't'

DIVPAG moves solution forward from T to TEND
 through intermediate time-steps 't'

Return to STEP 1

A familiar set of procedures at last - continuing the journey!

Saturday, 3 December 2011

A point of reference....

Yet another mind boggling complication has raised its head!

What reference system should be used for evaluation of the ship equations of motion? Sounds like a fairly simple question - until I started to unpick the various force equations - we have....

1 The Earth coordinate system (x, y, z) easy enough,
2 The ship coordinate system (x, y, z) relative to the centre of gravity of the ship, OK understand that too,
3 The ship coordinate system (x, y, z) relative to the centre of 'floatation' of the ship, bit more mind boggling this one - how do you determine the CoF - complex stuff,
4 The ship rotating coordinate system (yaw, pitch, heave) - phew,

There are probably others but I lost the will to live - translating between this lot has got to cause some problems - carrying on trucking!

Monday, 28 November 2011

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 ;-)

Saturday, 19 November 2011

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;

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

Saturday, 12 November 2011

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!

Friday, 4 November 2011

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!

Saturday, 29 October 2011

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!


Two functions ETIME and DTIME. let FORTRAN programs measure time. This is useful for perfomance tuning. They are used as follows:
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
DO 10 I=1, 100000
10        CONTINUE
set DELAPSE to the time required to compute the loop DO 10 1=1,100000.

Friday, 28 October 2011

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)


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.

Wednesday, 26 October 2011

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.


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.

Monday, 24 October 2011

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

and the functional, data and physical models outlined in;

References for two of these models are;

Functional Model = specifically Functional perspective section.

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.

Sunday, 23 October 2011

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!

Saturday, 22 October 2011

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:
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!

Saturday, 15 October 2011

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.

Tuesday, 11 October 2011

Struggling with the learning curve!


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;

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!

Tuesday, 4 October 2011

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!