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.

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

STEP 1

INTERNAV sets

Integration time-frame for ODE solution from

time T to TEND

STEP 2

DIVPAG called to determine solution of the 

XX system vector between T and TEND

STEP 3

DIVPAG uses FCMANVR to calculate derivatives of 

XX which it stores in DXDT vector at intermediate time-step 't'

STEP 4

FCMANVR combines all vessel forces and uses DLSLRG 

to solve F=ma for velocity components at intermediate time 't'

STEP 5

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!

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!

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!