Sunday, June 27, 2010

Macondo Prospect surface ship status 2010-08-04 00:00 UTC


The BP oil spill response is a complicated affair involving a fleet of ships operating in a very confined area. According to a Reuters story, BP maintains a Simultaneous Operations (SIMOPS) room that functions much the same as an air traffic control center to coördinate the operations of dozens of ships and as many as sixteen ROV's working at the same time.


(Check marks ☑ mark vessels within about a mile of the wellhead; unchecked boxes ☐ mark vessels farther from the wellhead at the time of this posting.)


Ships on long-term station

Several ships are holding position or at anchor more or less for the duration of the crisis response. These ships become familiar to the readers here because their names come up often.

  • ☑ Deepwater Discoverer Enterprise (538002215)
    Drillship conducting the LMRP Cap oil recovery. Also attempted the failed “top kill” operations.
  • ☐ Deepwater Discoverer Inspiration (538002878)
    Sister ship to the Discoverer Enterprise, reported to be bringing the new containment cap to replace the LMRP Platform cap. Arrived at Macondo Prospect 10 July.
  • ☑ Helix Producer I (311062000)
    Production vessel expected to take over oil recovery efforts and provide increased containment/production capacity.
  • ☐ Global Olympic Challenger (259755000)
    347 foot multi-service vessel carrying two UHD ROV's whose video is available.
  • ☑ Helix Q4000 (369550000)
    Drillship, stationed to the east of the gusher, recovering and flaring oil via the kill lines of the failed blowout preventer
  • ☑ Helix Express (576813000)
    520 foot pipeline layer, obviously a major player in the recovery operations. Little press coverage. Sister ship to the Q4000.
  • ☑ Deepwater Development Driller II (576971000)
    Drillship, stationed southwest of the gusher, sinking the first relief well.
  • ☑ Deepwater Development Driller III (576281000)
    Drillship, stationed southeast of the gusher, sinking the second relief well.
  • ☑ Skandi Neptune (258142000)
    ROV tender conducting dispersant operations.
  • ☑ Ocean Intervention 3 (258473000)
    ROV tender conducting construction operations for oil recovery.
  • ☑ Boa Deep C (224262000)
    ROV tender conducting construction operations for oil recovery.
  • ☑ Holiday (368135000)
    Shown in a BP technical briefing as an ROV tender expected to be attending the Helix Producer. No video from this vessel's ROV's appears to be publicly available
  • ☑ HOS Achiever (579299000)
    432 foot multi-service vessel. Shown in a BP technical briefing as an ROV tender expected to be attending the Helix Producer. Known to carry two ROV's and a 150-tonne crane, and observed to maintain permanent station in the cluster of vessels at MC252. No video from this vessel's ROV's appears to be publicly available.
  • ☐ HOS Iron Horse (235072115)
    432 foot multi-service vessel. Known to carry two ROV's and a 150-tonne crane, and observed to maintain permanent station in the cluster of vessels at MC252. No video from this vessel's ROV's appears to be publicly available.
  • ☑ Loch Rannoch (232829000)
    Heavy tanker expected to assist in offloading recovered oil.

Two specialized “stimulation ships” are working the scene. These are vessels specifically adapted to pumping fluids into the well at high pressure (and, it is to be hoped, dealing with the consequences!). Normally, a stimulation ship is used to enhance the production of a well when additional fracturing (“fracking”) of the rock or “propping” of the formation is needed to keep the pores from closing and the flow from stopping. In this accident, the stimulation ships have been brought on the scene for the Top Kill and Static Kill attempts.

  • ☑ Galliano Marine Service Bj Blue Dolphin (369552000)
    300 foot stimulation vessel. Carries a crew of 45. Can support three umbilical lines and flow 80 barrels of fluids per minute with her 23,000 horsepower pumping system.
  • ☑ Halliburton Stim Star 3 (369050000)
    260 foot stimulation vessel.

Fire vessels

An oil platform has vast quantities of flammable liquids about; an oil spill is many times worse. Firefighting vessels are required at all times.

Oil Skimmers

Many vessels are skimming oil from the water's surface in the immediate vicinity of the disaster. Included among these are a fleet belonging to the Marine Spill Response Corporation, which has deployed at least ten Responder-class vessels, three barges, six Fast Response Vehicles, four KC-130 tanker aircraft and two King Air 90 spotter aircraft to the spill. MSRC makes a summary of its Atlantic and Gulf Coast vessels available on the net.
National Response Corporation also conducts oil recovery operations on the site.

  • ☐ A Whale (636014465)
    Supertanker modified to be an enormous oil skimmer. It didn't work.
  • ☐ Harvey Thunder (369579000)
    13,500 hp, 135 foot ocean towing vessel.

    Deduced to be in skimming operations from the ship's track.

  • ☐ MSRC California Responder (366608000)
  • ☐ MSRC Delaware Responder (366593000)
  • ☐ MSRC Florida Responder (366603000)
  • ☐ MSRC Gulf Coast Responder (366598000)
  • ☐ MSRC Louisiana Responder (366592000)
  • ☐ MSRC Maine Responder (366599000)
    A wire service story reports that the Maine Responder sailed for the Gulf from Portland, ME on 2010-05-02 and is expected to remain in the Gulf for the duration of the emergency.
  • ☐ MSRC Mississippi Responder (366601000)
  • ☐ MSRC New Jersey Responder (366594000)
  • ☐ MSRC Pacific Responder (366605000)
  • ☐ MSRC Southern Responder (366596000)
  • ☐ MSRC Texas Responder (366595000)
  • ☐ MSRC Virginia Responder (366602000)
  • ☐ Resolve Salvage & Fire Lana Rose (367137210)
    100-foot salvage tug engaged in oil skimming

Dispersant Vessels

Several vessels, according to a diagram from BP, conduct dispersant operations on the water's surface near the rigs.

Support vessels

Every platform needs a small armada of tankers, supply ships, tugs, barges and crewboats to keep it supplied and haul its waste and oil away. Contractors for supplying the BP disaster recovery operations include Edison Chouest Offshore, Global Industries, Hornbeck Offshore, Moran Towing Corporation, , SEACOR Marine and United Tugs.

SEACOR Marine has one fleet of vessels specifically adapted to handle towing and anchor handling for the moorings of deepwater drilling rigs.

Most of the multi-service vessels are equipped as deepwater ROV tenders, but to the best of my knowledge, video from their ROV's has not been published.

Government and research vessels

NOAA and other institutions have vessels studying the effects of the oil spill. NOAA, in particular, has issued a press release describing its operations in the Gulf disaster.

  • ☐ Beau Rivage
    Charter boat under contract to NOAA, conducting bottom longline fishing in the prohibited area for seafood safety samples
  • ☐ Brooks McCall (338257000)
    Research vessel conducting water column sampling.
  • ☐ Rv Endeavor (303471000)
    185-foot research vessel owned by the National Science Foundation and operated by the University of Rhode Island
  • ☐ Jack Fitz
    Private research vessel and ROV carrier reported in the Huffington Post to be investigating the subsea oil plume.
  • ☐ Ocean Veritas (367116090)
    Research vessel conducting water column sampling.
  • ☐ EGS Ridley Thomas (538002534)
    Survey vessel
  • ☐ NOAA Delaware Ii
    155 foot research vessel
  • ☐ NOAA Caretta
    Mississippi research vessel conducting a trawling and plankton survey in the oiled area off Mississippi.
  • ☐ NOAA Gandy
    Mississippi research vessel operating vertical line survey in the eastern Gulf for seafood safety samples.
  • ☐ NOAA Gordon Gunter
    224 foot research vessel, studying marine mammals
  • ☑ Noaa Henry Bigelow (369991000)
    209-foot research vessel that is nearly identical to the Pisces and has apparently substituted for her in sonar monitoring of the shut-in well.
  • ☐ NOAA Nancy Foster
    187 foot resesaarch vessel, mapping platform and ROV tender
  • ☐ NOAA Oregon Ii
    170 foot research vessel equipped with trawls and longlines for study of sea life
  • ☐ NOAA Pisces (369970145)
    Not to be confused with the Toisa Pisces, the NOAA Pisces is a 209-foot research vessel conducting acoustic surveys of the disaster and monitoring water quality.
  • ☐ NOAA Thomas Jefferson (369958000)
    204 foot survey vessel
  • ☑ Tidewater War Admiral (368164000)
    Chartered by BP to monitor current patterns in the Gulf.
  • ☑ US Coast Guard C G Decisive (367298000)
    211 foot medium endurance cutter
  • ☐ US Coast Guard Resolute
    211 foot medium endurance cutter
  • ☐ US Coast Guard USCGC Walnut (366953000)
    225 foot seagoing buoy tender; home port is Honolulu.

Expected vessels

Some vessels had previously been in attendance on the blowout and are expected to return. Others have been reported in the media as expected to participate in the response but have not yet been observed.

  • ☐ Clear Leader (538002877)
  • ☐ Toisa Pisces (636011860)
    Production vessel expected to take over oil recovery efforts and provide increased containment/production capacity.
  • ☐ Viking Poseidon (259873000)
    ROV tender conducting subsea construction. Formerly provided two video feeds. As of 2010-06-25, moored at Gulf Copper Dry Dock and Rig Repair in Galveston, TX. Unknown whether BP intends for this vessel to return to the disaster site.
  • ☐ West Sirius (357575000)
    A press release reported that the semisubmersible deepwater drilling platform West Sirius had been chartered by BP for the Gulf. The vessel was seen at the site on 2010-06-25, but left that day, steaming in a southwesterly direction.

Seismic survey vessels

BP, in the course of conducting its well integrity testing on July 13-14, has announced that it is conducting continuing seismic surveys of the site to characterize the conditions below the seafloor. The vessels that appear to be particicipating in this survey all belong to WesternGeco a business unit of Schlumberger. Seismic vessels are a very specialized ship; there are only a few dozen worldwide.

  • ☐ Geco Searcher (352473000)
  • ☐ Geco Topaz (352923000)
    Mentioned in a news briefing as having needed to sail through the cluster of ships at Macondo Prospect, requiring complex support from the simultaneous operations center to move them out of the way.
  • ☐ Geco Triton (355468000)
  • ☐ Gilavar (371810000)
  • ☐ Western Trident (357269000)

Other Vessels

These vessels have been seen assisting at the disaster, but information on their role is sparse. Further research by the community would be appreciated.



Read more...
Posted by Another Kevin at 5:37 PM 0 comments

Saturday, May 8, 2010

Tcl operations, and many different zeroes

One reason for the title of this blog that I've explored fairly little up to now is that I'm one of the gnomes who make the Tcl programming language go. For this reason, many of my computer applications, when they start up, depart from a script - a Tcl script.

Last night, a colleague pointed me to a thread on linuxquestions.org that begins with a misunderstanding of how data are interpreted in Tcl, and diverts into a screed that Tcl is "objectively bad."

Fundamentally, the original misunderstanding appears to be one of notation. The original poster complains how Tcl is 'clumsy in dealing with binary data.' He has a string comprising a single character, for example 'B', and he expects to be able to write, [expr {$char & 0x80}]. Needless to say, that expression fails:

can't use non-numeric string as operand of "&"

Why is this? Well, fundamentally, in Tcl, Everything Is A String - it's one of the language's guiding principles. That principle means that there is no difference between the string "12" and the number 12: they comprise the same characters, hence they are the same entity. A side effect of this rule is that there is no difference between the character 0 and the number 0: again, they are the same string of characters. This unity is a tremendous convenience when you are using Tcl as a shell (or for writing scripts that serve the same purpose as shell scripts): you don't have to add a lot of excess quotes just to distinguish the types of things.

It gets in the way only when you are trying to do low-level stuff like parsing, such as is done in C:

for (i = 0; (c = str[i]) != '\0'; ++i) {
    /* do something with the character c */
}


Tcl allows similar processing that (in my opinion) is just as convenient:

foreach c [split $str] {
    # do something with the character c
}

But inside the loop, the character c is a one-character string in Tcl; in C, it's an integer whose value is the representation of the character in ASCII (or some other encoding).

If you do want, for some reason, to iterate over the bytes of a string as integers, it's easily done:

binary scan $str c* chars
foreach c $chars {
    # do something with the integer c
}

If there were demand for it - and as far as I'm aware, nobody's ever asked - Tcl's expression engine could be modified to accept single-quoted characters as integer constants. It appears that to Tcl's users, the existing facilities to manipulate bytes are Good Enough - partly because of Tcl's culture of extensibility. If you need high-performance, low-level programming, you do it in C and provide a Tcl API.

And so the original poster's question could be easily dismissed as "not understanding the language" - were it not for the somewhat vitriolic posts that followed. The one that rankled in particular said,

Well, TCL is an objectively bad language because it is (used to be ?) a true source code interpreter. So, syntax errors are not found until containing them code is executed.

For example, in VLSI synthesis may take several days, and it's quite a pity if the whole process ultimately fails because of a silly syntax error at the script end.

That's why static TCL checkers have been invented ...

"Objectively bad?" Oh, my.

Given that static Tcl checkers like Nagelfar do exist, most of that poster's screed can be reduced to a complaint that Tcl doesn't force you to use them. Surely, if you're going to invest days in a VLSI synthesis, you'll want to ensure that you've bulletproofed your program in every way possible: perhaps those who are dealing with lighter-weight tasks where you can fix a script and rerun in literally seconds have different sets of tradeoffs? Does "objectively bad" reduce to "unfit for this purpose without some extra help?"

Admittedly, I am aware of studies claiming that programmers presented with strongly-typed languages debug their programs faster. But most of them are old, and compare the strong typing of a language like Pascal against the untyped pointers of PL\1 : anyone else remember the disaster that those were? I'm not aware of any studies that both are conducted with experienced programmers (beyond the level, say, of first- or second-year undergraduates) and are evaluating modern languages. The folklore says, "the more checking up front, the better," but the actual experience with up-front program checking always seems to reach a point of diminishing, nay, negative returns. After that point, adding additional strictness simply makes the programmer jump through hoops arguing to the compiler that the program is correct before the system will deign to run it. When that point is reached seems to vary, so there's certainly still room for subjectivity in evaluating it; in my opinion "objectively bad" is far too strong a statement.

And the "strongly typed" languages fall prey to the other problem: runtime exceptions (SIGSEGV in C, NullPointerException in Java, etc.). Tcl essentially never gets those: if a Tcl script manages to cause one without help from extension code in another language, it's "all hands on deck" among the maintainers to fix the bug. Even if the script is obviously erroneous, Tcl's maintainers pride themselves on the ability to catch and report all runtime errors.

But Tcl is unquestionably not fit for all purposes. No language is. If you find that you have an application where it does poorly, I probably have similar applications somewhere, and I'd be happy to recommend other languages to you. For a good many "high-level" tasks, it seems to fit the way I think. Argue if you will that I'm not "right-thinking," but don't assert that your right thinking is objectively better without data to back it up!

(Hmm, is this attitude Tcl's marketing problem? The Tcl community seems to be remarkably free of zealots that assert that it is objectively better than its competitors. If that is a problem, it's a problem that I enjoy having; I tend to struggle to deal with zealots of any stripe.)
Read more...
Posted by Another Kevin at 12:06 PM 0 comments
Labels: ,
Subscribe to: Posts (Atom)