Friday, 27 January 2012

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

Saturday, 21 January 2012


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!

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

Friday, 13 January 2012

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!

Friday, 6 January 2012

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!