Slow progress.

Slow going this week - lot of other work pressures getting in the way - all good client stuff so can't complain too much!

Just in the process of putting in place the in-house development environment to allow proper version control, documentation and rebuild of the models.

Currently looking for a good auto-documenting method for VB code - they do exist! also need to think through what we are going to convert these models into. Must be web-based - can't be doing with handing out dongles - these days must be a more elegant way of distribution and control.

The language that seems to be rising to the top in our discussions is Perl - know absolutely nothing about this language but am assured its 'very simple'. Need to convinced that it can handle the QRA consequence modelling though - don't want to spend the rest of my life re-writing mathematical library functions (that will also need to be verified!)

All good ideas welcome........

Unbelievable.....

Have now had time to do a bit of research on the topic and a bit shocked to tell the truth at the level of complacency about the use or 'spreadsheets' for complex calculations.

I have started to look into one of codes that I will be looking to convert into a more structured environment and its not pretty. Rather than it actually being a spreadsheet it is in fact a large Visual Basic code! All Excel is being used for is essentially input and output of data. Which in some ways is good because at least there is a chance of understanding the code operation. But on the other hand is bad in that this code has not been 'designed' but, and there is no other way of saying this, hacked out over a period of years. I am now finding that this is a common occurrence!

Why on Earth do people believe this is an appropriate way of developing what has turned out to be a very complex piece of software? It's sort of akin to doing DIY on your house - add a bit here, chop a bit there - but then again for the safety critical jobs eg the electrics you still need a qualified electrician to certify what has been done is OK - not so with hacking out code hidden within an Excel wrapper.

The other issue I have come across is, for some people, if you say a model has been developed in Excel they seem quite happy to accept this without question. It's as if just by using Excel you have proved that what has been done will be OK for use - we all know Excel don't we, come on, can't be that bad - kind of thinking!

Personally, letting people loose on Excel for complex calculations scares the pants off me - and others - check out this link to see the full extent of the damage that can be caused!

http://www.eusprig.org

BUT wrapping, what is essentially a VB code, up under an Excel umbrella - which as noted above, if you say its an Excel model you can go a long way without having to declare what you are really up to - is a bigger crime. Especially when committed by engineers - who should know better!

Stand down off soap box and CONTINUE ;)

Advantage Fortran!

Well - still struggling to get going on the project in 2012- too much happening on other projects - but was quite pleased to see that there was at least one other looking to do some Excel to Fortran conversion!

Matt Wenham of the Fortran Programmers Group on LinkedIn kicked off a discussion on this very subject - you have to be in it to see it - but there were a few interesting replies that have given me incentive to get stuck into this project. In particular, the discussions have highlighted some of the 'advantages' of moving models into Fortran, which is generally perceived as an old man's language - at least by my young advisors!

So here is a quick summary of these advantages!

Quote from Craig Dego;
" I find the ease of use of Fortran to be its most important advantage. This ease of use means that Fortran has much higher human productivity that most of its competitors. 

One other major advantage of Fortran is that it is still defined by an active ISO/ANSI Fortran Standards Technical Committee. Thus, the ISO standard for Fortran is current with modern computing needs and practices and is still relevant for much of modern Fortran use. This contrasts sharply with popular alternatives such as Java, C#, and Visual Basic, all of which are defined by software firms. Therefore, the definitions of Java, C#, and VB are the property of those firms. Java is owned by Oracle, which bought out Sun Microsystems. C# and VB are both owned by Microsoft. "

Quote from Jack Riegel;

".... I have seen a number of attempts to develop replacements to some of the procedural codes (thats FORTRAN-like code) fail miserably. They either become too difficult to comprehend or the implementation of math operators fail to provide the necessary precision or, more likely, they become so inefficient with all of the layering, that the resulting code is a major step backwards...."

Quote from Matt;

"I have recently helped to develop a complete cost forecasting application based on Excel. While it works, it has serious limitations, one of which is speed. A back-of-the-envelope calculation tells me if we re-write the main forecasting loop into Fortran it should run in a matter of seconds as opposed to the several minutes in Excel."

I like all that - standards and all - eat your shorts Java et al !

Hopefully I will get to delve into the code this coming week!

A longer game.....

Its been a bit of a tough start to the New Year - lots going on - so not been able to do too much on the next phase of the revival.

However, have identified the new project which is to consolidate a couple of Spreadsheet QRA (Quantified Risk Assessment) models. These should have the right level of mathematical complexity to make it worthwhile converting to Fortran.

Both of these models calculate risk profiles for onshore and offshore oil and gas installations - so slight change from the marine environment!

More when I know more!

***** 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 *******

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

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.