3W Dataset 2.0.0 (Oil Well Events)

It is Petrobras' answer to a problem everyone in production ops shares and nobody can solve alone: undesirable events in oil wells are rare, dangerous, and almost never labeled, which makes them nearly impossible to train on.

The 3W project fixes the label scarcity by manufacturing coverage from three directions at once. Real instances are captured from operating offshore wells through historian systems. Simulated instances are generated with numerical models tuned to reproduce specific failures. Hand-drawn instances are authored by domain experts sketching plausible signatures where neither source supplies enough examples - hence the W³ name, one letter per provenance.

Version 2.0.0 is the deepest cut yet: it extends coverage to 42 real wells, added real and simulated instances of hydrates in the service line (the newest class, type 9), expanded six other classes, removed one variable while adding twenty others for 27 variables total, introduced a well operational status label alongside the event label, extended normal periods, eliminated labeling gaps in real instances, and corrected unit conversions.

Governance is unusually serious for a data release. It began as Petrobras' first open-source code release, run by its Flow Assurance department with the CENPES research center, and Well Integrity joined governance in May 2024. A companion toolkit loads the data, and a folds directory ships fixed cross-validation splits so published results stay comparable.

Every instance is its own file, one per event occurrence, dropped into a directory named for its class. The file name tells you the provenance before you open it: WELL-* marks real observations and carries the timestamp of when recording began, SIMULATED_* marks model-generated runs, DRAWN_* marks expert-authored cases.

Inside, an instance is a time series: a datetime index plus float columns for the sensor variables, with the event label and the operational status label attached as integer columns. Class transients - the stretch of transition between steady states - are offset by +100 so you can separate 'what happened' from 'while it settled'.

The class distribution is itself informative. Normal operation dominates at 594 instances, followed by rapid productivity loss (450) and abrupt BSW increase (343); the rarest classes - spurious DHSV closure at 38 instances and PCK scaling at 46 - are precisely the ones nobody could assemble on their own, and exactly why the simulated and drawn sources exist.

Sample rows above show the file-level shape observed this session; row-level sensor values ship with your sample.

Twenty-seven variables, and the naming convention is half the documentation. Pressure tags starting P-* locate themselves by hardware: PDG for the permanent downhole gauge, TPT for the subsea temperature-and-pressure transducer at the Christmas tree, CKP and CKGL for the production and gas-lift chokes, SDV-P for the production shutdown valve, BS for the service pump. Temperature tags mirror the pattern (T-TPT, T-PDG, T-MON-CKP, T-JUS-CKP).

The eight ESTADO-* fields are the valve lineup - DHSV, PMV, AMV, PWV, AWV, PXO, XO, and both shutdown valves - each reporting 0, 0.5 or 1, so a single row tells you whether the tree is lined up for production, shut in, or mid-transition. That matters because several event classes are defined by valve behavior rather than by reservoir response.

Flow tags split by duty: QGL meters injected lift gas, QBS the service pump. P-ANULAR watches the annulus. The two label columns - class and state - are the supervised part, and the reason this catalog exists at all.

Definitions above are verified against the dataset's own variable documentation.

Geographically this is a Brazil play: all 42 real wells in version 2.0.0 are operated by Petrobras offshore, spanning pre-salt and post-salt fields. If your models must generalize to other basins, treat that as the honest boundary of the real-data portion - the simulated and drawn instances are deliberately geography-free.

Temporally, real instances reach back roughly a decade and a half, with observation start dates stamped directly into file names (one class-0 instance begins 1 February 2017, for example). Release cadence has been versioned and documented: 1.0.0 in July 2019, 1.1.0 in December 2022, 1.1.1 in April 2023, 2.0.0 in July 2024.

At the grain level, the unit is the event instance: one file per occurrence, one well per file, one class label throughout. Roughly 2,200 instances total, sorted unevenly across the ten directories - which is not a defect but the honest arithmetic of rare-event data, and the reason the fixed cross-validation folds matter more here than in most benchmarks.

You choose the shape: API, flat files, or landed straight into your warehouse. Cadence is yours too - daily, weekly, or hourly refreshes depending on how live your pipeline needs the event catalog to be.

Practical notes worth knowing before you request a sample. Instances arrive as Parquet, which loads natively in pandas, pyarrow, Polars and DuckDB without conversion steps; timestamps ride the DataFrame index rather than a column, and all variables are floats while labels use nullable integers. A documented companion toolkit handles loading, and the fixed cross-validation folds come alongside so your evaluation protocol matches everyone else's.

If you want the event taxonomy mapped onto your own historian tag names, say so in the sample request - that mapping is the usual first step we cut.

Machine learning teams building anomaly detection for producing wells, because the alternative is waiting years for their own labeled failures. Production engineers hardening surveillance thresholds against signatures of slugging, hydrate blockage and productivity decline drawn from real offshore operations rather than textbook curves.

Reliability engineers use the eight valve-state channels to baseline how trees are actually lined up during transitions. Quant researchers fold event frequencies into operational risk models. Academics publish against it because the version history is explicit and the splits are fixed, so a result reported today can be reproduced next year.

The common thread: anyone who needs to know what a well looks like in the minutes around something going wrong, without having to wait for something to go wrong.

Data scientists and ML engineers lead, since labeled rare-event data is the binding constraint on predictive maintenance anywhere in heavy industry.

Production engineers and flow assurance teams come second - the event taxonomy mirrors their own failure vocabulary, so models translate directly into monitoring logic.

Reliability and integrity engineers value the valve-state granularity. Academics value reproducibility. Quant researchers value a physical footing for operational risk. Product teams scoping well-monitoring tools value a taxonomy their customers already speak.

If your role touches producing assets and you have never seen a labeled hydrate event, this catalog will change what you consider possible.

Most datasets in this category describe what came out of the ground - production volumes, price tapes, rig counts. 3W describes what went wrong underground, which makes it less a competitor to those catalogs than their missing operational layer.

Against Equinor's Volve release, 3W trades breadth for depth: Volve hands over an entire field's worth of files across subsurface and operations, while 3W goes narrow and deep on labeled failure signatures. Against live industrial streams like the Valhall project, 3W offers the thing streams cannot: hindsight labels saying which stretches of sensor history were actually incidents.

Use it alongside production and price datasets rather than instead of them - the event layer explains anomalies the volume layers merely report.

Know which event classes matter to your operation - hydrates, slugging, productivity loss, choke restriction - and the sample gets cut toward them rather than spread thin across all ten.

Know also whether you need the simulated and hand-drawn portions or only real-well instances; both ship in the same catalog but serve different validation purposes, and being explicit about which you need speeds everything downstream.

Finally, know your destination: Parquet lands cleanly in warehouses and dataframes alike, but if your stack expects CSV or database tables, mention it and the sample arrives converted.