More progress - the overview.

Now started to look into the 'onshore' QRA model - which is a little better structured. For each fire scenario the code undertakes the following calculation flow;

The initiating event sheet provides the event list to be processed by the application. The naming convention for initiating events is: Area/Unit_Inventory

Where:

• ·         area is the primary area designator (eg site),
• ·         unit specifies the location of the release (eg a fire zone, module/unit or equipment name)
• ·         inventory is the inventory name which can result in a hazardous scenario, e.g. valves, flanges

1. The initiating events (hazardous release scenarios) are based on releases from inventories. A number of hole sizes are defined (typically small, medium, large and full bore) that relate to the event such that the hole size determines the release frequency.
2. Release frequencies are defined on a separate sheet and referenced via lookup during calculations.
3. For each event the model walks through each release (hole) size required for both Impinged and Unimpinged states.
4. Within this nested loop structure the program calculates the branch probability and outcome frequencies for the event tree and copied the results to the Event Tree sheet. The calculations use a combination of the pre-loaded data acquired during program start plus lookup data from worksheets using offsets dependant on the event.
5. The risk assessment methodology analyses each of the identified initiating hazardous events (hydrocarbon releases) that can lead to potential  jet fires, pool fires, flash fires, explosions or (unignited) toxic dispersion. 
6. When the QRA is run, the program fills in the data for each event and calculates the branch probabilities and outcome frequencies. 
7. The branch probabilities are calculated by a user defined maco (function) embedded in the event tree sheet. Once the main process loop has copied data to the tree sheet an Excel re-calculate is invoked to display the results.

Voila....

Gone as far as we can ......

We have now gone as far as we can with the first of the three codes which focusses on offshore QRA modelling. Though I think we picked the worst for first rather than last!

We now have a view of how the code operates and have documented the main functional and data models. This first application has been so poorly designed and written it is not advisable to use or develop it any further on projects. We now have the code under version control and can respond if there are any queries on past calculations. 


We have recommended that we simply extract the functional models that are unique to it (so that we can re-use then) then freeze this version in archive.


Moving on to code 2 ......

Alex's Blog: FaEL accepted by Microsoft

Alex's Blog: FaEL accepted by Microsoft: The app has now been successfully added to the windows phone marketplace and is available to download! I have had a lot on my agenda at th...

Things move on.......

Progress this week has been to map out the high level program overview, a view of the decision flow and a start on the data model - pretty impressive work by Roy!

The main aim of the program is to populate a set of event trees related to the frequency and impact of various fire scenarios - as illustrated below.

A combination of user defined macros build the branching frequency and the VBA code to determine the consequence for the various scenarios.

We plough on......

Just when you thought it was safe to come out!

Finally managed to get a day to review where we are with things - Roy has been doing a great job unpicking the code.

We have 12,000 lines of uncommented VB code (that means none... nada.... zip comments!)  on top of that, the code is littered with numerous IF THEN's none of then coded with indents making it a nightmare to follow what is going on. Then you have data items that are renamed and renamed again from routine to routine........arghh!

The convolution is worse that imagined - as illustrated below in a snapshot of one of the main routines! 

Poor software engineering practices have meant that there is no chance of us every being able to maintain this code going forward!

What to do next.......

Came across this...

Been on holiday this week - so limited news - though am assuming 'others' have progressed things - will find out on Monday!

However, in a trawl of Google I came across this article which looked interesting;

From, Heat Transfer Today –R.J. Ribando - web ref

http://faculty.virginia.edu/ribando/modules/xls/VBAPrimer.pdf

with quotes as follows:

" In the past, even mildly complicated engineering calculations have not mixed well with 
spreadsheets because of the very strong tendency to wind up with nearly-impossible-to-debug 
"spaghetti code". .......... However, by using Visual Basic for Applications (VBA) in conjunction with the Excel spreadsheet, the user has the convenience of a spreadsheet for neatly-formatted input/output  and for graphical display of results, i.e., to function as a graphical user interface (GUI).  Meanwhile well-structured, readable, line-oriented code can be used for the more complicated calculations...........


Conclusion

Student response to use of VBA within other courses, both undergraduate and graduate, 
has been excellent.   Since all have had a structured programming course earlier (some in Fortran 
90, some in C++, others in Java), the migration to VBA is very straightforward.   Most welcome 
the opportunity to add another package to their inventory of proficiencies.  Several graduate students in a recent programming-intensive computational fluid dynamics (CFD) elected to do all 
assignments using Excel/VBA."

so there may be hope yet!

Except there is also a disclaimer;

" I am not a computer scientist or programmer, but rather an engineer.   That being the 
case, I have found VBA to be a quick and easy way to do most of the things I want to do in my 
teaching and research.  Code that you will find described here or available on the website is not 
guaranteed to be error free or even to follow good programming practice."

or - beware even expert engineers can muck up using this environment!

The journey continues .... ;)

First contact......

Not by me though :(

Not had time to do much other than a bit of Start Trek management "make it so" - thanks to Roy and Ian for this weeks efforts.

QA on version control started and first view of functional flow of the code starting to appear. This seems to me be a complete rats nest of logic switching between Excel sheet's to macro's (built in and user defined) to VBA code. How on Earth anyone could contemplate this sort of structure in the first place is a mystery to me. What do they teach on spreadsheet training courses! Then again I can probably guess.

Not only that - we have had to write a code to decode the code or in Roy's words;

"Source code formatting poor - created a small utility to auto-format so that (very) excessive conditional logic nesting could be traced"

Engage....