Project Library

Full screen, offline capable plant study app for a processing plant project (Growth Project, Stage 1 and Stage 2). Built for learning the plant language: area codes, tag numbering, circuit logic, acronyms and shift handover talk.

Open it at https://bijankle.github.io/ProjectLibrary/ and use Chrome's "Add to Home screen" so it launches full screen like an app.

To add cards, edit cards.js (each card has a question q, a short answer a and the detail e), then bump VERSION in sw.js so phones pick up the change.

App size

Settings on the phone has an App size slider, 70% to 160% in 5% steps, with Reset: the whole app bigger or smaller, like Ctrl + scroll in a browser (tab strip, buttons, text, the PFD and the map all together). It sets the page's viewport width, so it is the browser's own zoom and taps and map positions stay exact (textsize.js); one value for both pages, kept on the device. On a computer the setting points to the browser's zoom (Ctrl + scroll).

Settings > Offline downloads shows whether the phone has agreed to protect the downloads from automatic clean-up; the app asks for that protection every time it opens (app-update.js). Updating the app never clears them.

Tabs

A tab strip sits across the top of every screen, on the phone and the computer: 🔎 Assets (Browse and search), 〰️ PFD, 🗺️ Layout, 🃏 Quiz, sitting together at the top left, and ⚙ Settings at the right. Assets and Quiz live in index.html (#assets, #quiz), PFD and Layout in pfd.html (#pfd, #layout); switching page keeps each page's own state (Browse pick, quiz filters). A quiz left half way resumes when you come back to the Quiz tab. tabs.js draws the strip; both pages offset their fixed layout by its height (--tb).

Quiz

The Quiz tab opens straight on a card (the deck in progress, or a fresh one dealt with the last choices). Tap or swipe left reveals the answer; again moves to the next question. Swipe right goes back through earlier cards, answer side only. Moving past an answer counts as known unless "↻ Revisit this one" is ticked on it (it can be ticked or unticked later when going back). ⚙ on the card screen opens the deck order, length, topics and progress stats with a New deck button; ✕ shows the debrief for the cards done so far. Leaving the tab and coming back resumes the same card.

Browse (Assets tab)

The Assets tab is split: filters in the left third, the items that match so far in the right two thirds. Step 1 picks the asset type (full words); the next steps follow that type's tag nomenclature (equipment code then area for equipment, instrument letters then area, valve type, area and size for valves, service, area, pipe spec and size for lines). Options are one per row reading (xqty) code (short name), e.g. "(x277) PP (Pump Process)", with the quantities right aligned in one column so the items line up, most items first. The code stays full size and the bracket text shrinks until the chip fits on one row (down to 8px); if chips still don't fit, the filter column widens (up to half the screen). Results are one row each too: code (description), a line reading line number (from name, to name) with its ends as MEL names (no tags; another line stays its number) and shrinking as small as it takes; other results shrink down to 8px and end in … if still too wide. The type icon is dropped once a type is picked. Lists too long for the screen get a Niagara launcher style A–Z strip down the far left edge: touch or slide to a letter and only the options starting with it show (big letter bubble while sliding); tap the lit letter again for all of them.g. "PP - Pump Process (277)"; × on it goes back to that step, and Any skips a step. The last pick is remembered, and typing in the search bar still searches everything. Names come from browse.json, built by tools/build_browse.py from the plant numbering spec, the line list and the pipe spec index (standard ISA letters fill any gaps). browse.js holds the logic.

Follow up questions (AI)

On the answer side of each card there is a "Dig deeper" section with three suggested follow up questions and a box for your own. The suggested questions have written answers two levels deep (followups.json, built by python3 tools/build_followups.py <batch folder> then tools/sanitize.py): each card's 3 questions are answered, each answer suggests 3 more that are also answered, and those suggest 3 more that Gemini answers when tapped. Written answers need no key and work offline; your own typed questions and anything deeper go to Gemini. Answers come from Google Gemini using your own free key from aistudio.google.com (Settings on the home screen). The key is stored only on your phone. Every question is sent with facts.js (a condensed plant reference from the design criteria and control philosophies), the glossary and the cards in the same topic, and each answer is tagged as coming from the plant docs, docs plus general knowledge, general knowledge only, or not covered.

Interactive PFD (desktop)

On a computer the site opens pfd.html, a one page interactive PFD of the plant at major equipment level (use index.html?cards for the flashcards; phones get the flashcards with a View PFD button). Scroll to zoom, drag to pan, click equipment or streams for design data, control notes and connections. Flow buttons animate and step through the main line, grinding loops, flotation, concentrate and gold path, carbon loop, water and reagents. Toggles show control loop badges, service lines, Stage 1 vs Stage 2 routing and the four PDC design cases. Click anything (equipment, stream, loop, interlock, symbol or legend item) to select it; Ctrl+click adds more; the view zooms to fit and Esc clears.

The header dropdown picks the PDC case (nominal 25.5 Mtpa, design grade 24.0, achievable 25.5, high throughput 28.35). The tph box borders take the selected case colour (red high throughput, orange achievable, yellow nominal, blue design grade), shown as a legend in the dropdown. Mill reline modes are not offered because the PDC gives no flows for them.

Look up (phone home screen, or the PFD header search, press / ): type any part of a tag, line number, valve, hose, SPI or P&ID number, or plain words. Spaces and hyphens are ignored. Each result shows every field from its list, links to anything it mentions, and everything that references it. 📷 reads a tag from a photo using Tesseract.js (downloaded from jsDelivr the first time, then runs on the device).

Where the data lives:

• pfd-data.js: layout, routing (PFD, corrected to the PDC where they clash), node notes, control loops (with real instrument tags) and interlocks.
• pfd-streams.js: every stream's figures from the Stage 2 PDC (2000-F00-DCR-PR-10002 Rev 4), keyed by stream id with the PDC section number. Four columns: nominal 25.5 Mtpa, design grade 24.0 Mtpa, achievable grade 25.5 Mtpa, high throughput 28.35 Mtpa. Missing water, slurry, SG and m³/h values are calculated in the viewer and shown in blue italics.
• search-data.json: every item in the MEL, instrument list, control valve list, manual valve list, line list, SPI list and both slurry hose lists, built by python3 tools/build_search.py <folder with the .xlsx files>. Rebuild it when a list revision comes out (files are found by document number). The tailings storage facility (TSF) project lists (TSF MEL, control valve, manual valve and line lists) are added after that by python3 tools/build_tsf.py <folder with the TSF .xlsx files>, which also tags every item Main plant or TSF from its P&IDs (the TSF drawings are listed in the script). Then run tools/sanitize.py and tools/build_pid_refs.py. The Assets page has a Main plant / TSF picker (tick boxes, both ticked by default, kept between visits) that filters the lists, the search and the drawings; while both show, TSF items carry a small green TSF tag. TSF items are not on the Smart PFD or layout.
• Layout: equipment names always sit above their symbol, and lines into or out of the top stop at the name box. Every line with a PDC tonnage shows a tph box, and the layout keeps each line longer than its box. In the browser console, pfdCheck() lists any clash (short lines, overlapping names, crossed area titles, jogs). node tools/relayout.js '[["x",at,amount],["y",at,amount]]' inserts space like adding blank columns or rows, moving everything beyond that point, including hand-routed lines. Loop and interlock points are pinned to equipment ([node, side, fraction, distance]), so they follow any relayout. The areas are arranged in rows to fill a 16:9 screen (2560 × 1440): node tools/moveframes.js moves whole areas; lines between areas that moved differently are marked ar:1 and routed automatically in pfd.html (A* around equipment and name boxes), then saved into the data with pfdBake().
• pfd-equip.js: generated by tools/build_equip.py from JSON exports of the MEL, instrument list and control valve list (the spreadsheets themselves are not committed). Re-run node tools/loop_tags.js > tags.txt then python3 tools/build_equip.py <json folder> tags.txt after a list revision.

Checks page, updates and the phone PFD

• issues.html (🐞 Checks, linked from the phone Settings and the PFD sidebar) lists contradictions between the documents: what document 1 says, document 1, what document 2 says, document 2, and which one the app takes as true and why. Rows come from issues.json (build with python3 tools/build_issues.py after tools/build_search.py; the decisions made while building the app are written into that script) plus live checks of the Smart PFD layout and data. Filter by type, category or words, and export what is shown to Excel (xlsx-lite.js, works offline). Each row also carries the revision date of both documents. The dates come from each document's revision block (spreadsheet cover pages, the MEL header, drawing title blocks, report revision tables), read by python3 tools/doc_revs.py <source folder> into tools/doc_revs.json. Where two documents clash, the newer one is taken as true unless the comment says why not; the newer date is marked ★, and the Source documents tab (issues.html#sources, also linked as 📄 Sources from the phone Settings and the PFD sidebar) lists every source document: number, title, type, latest revision and date, status, client review stamp, what the app uses it for, and the full revision history, with its own Excel export. Each document also has ▦ View tables, a full screen viewer of every table in it (all rows and columns, Excel row numbers and column letters, filter, big sheets loaded in 5,000 row chunks), and ⬇ Excel, a download of those tables. Both come from sources/, built by python3 tools/build_sources.py <source folder>: spreadsheets are rebuilt from their cell values without the cover page, logos, comments, file properties, external links or sign off names (hidden sheets stay hidden); PDFs give their data tables (the PDFs are drawings, so sheet, equipment and off sheet connection tables are built from the drawing text). The service worker does not keep sources/ offline except its index.
• ⟳ Update app (phone Settings, PFD sidebar, Checks page) shows the installed and latest version, clears the offline copy and reloads the newest version.
• On a phone the PFD opens full height at the crushing end, pinch zooms without limit, keeps a compact legend and filter strip along the bottom, shows details as a bottom sheet and puts flows and the full legend in the ☰ drawer.

Layout view (Smart PFD)

Equipment shows as plain text boxes: the tag and its MEL description (description from the closer zoom levels). A box whose tag has no MEL row, or a block with no MEL entry at all, is outlined red with ⚠ and the gap is named on its panel. To move a box, press and hold it for half a second until it lifts, drag it and let go; a shorter tap only selects it and opens its panel, and a quick drag pans the map. Moves are saved on the device (as before) and ⬇ Moves exports them; ↺ Reset position on the panel undoes one.

The equipment panel (schematic and layout) has pill filters across the top: Overview, Equipment, Instruments, Valves, Lines (PFD streams in and out plus line list lines naming the equipment) and Drawings (📐 opens the P&ID). One pill shows at a time. Every record opened in the asset search (equipment, instruments, valves, lines, specials, hoses) has one Details pill with all of the item's own fields, key ones first, and the fields blank in the list named once at the end. When the same tag is in another list (e.g. an instrument that is also in the control valve list) its fields merge into Details. No double ups anywhere (Lookup.dedupe in lookup.js, also used by the Smart PFD panels): a property from two lists shows once with the more complete value (DN400 and 400 mm are the same), and a field is left out when the tag, a longer code (valve class inside 400VKGE1C1-Double Acting, line spec inside the line number), other text or the heading already says it. Different properties that happen to share a value both stay. A record has no summary line under its tag: the Details table carries everything (lists still show a short name beside each tag, and a line as where it runs from and to). Spec pills have no summary on top either: the datasheet button, then the table (a pipe class title is the first Class row). The other pills are the Pipe or Valve spec (with sub pills straight under the main row: DNxx, Valves, Class, All parts, Notes; or Materials, More) and one per list that refers to the item (Instruments, Lines, Manual valves…), even when there is only one. A spec on a sized record shows only the component rows and valves that cover that size. In the Smart PFD panels the MEL, control valve and instrument data are single tables too; the equipment panel keeps Overview (description, control, loops, interlocks, what you'll hear, drawings), Equipment, Instruments, Valves and Lines.

The 🗺 Layout switch in the Smart PFD header shows the same equipment and streams on the real plant, on Google satellite imagery (no labels; Hybrid and Esri as alternatives), loaded through Leaflet the same way as the Photo Map app. Selection, flows, stage, service lines and the info panel are shared with the schematic. Zoomed out it shows the big equipment and the main process lines; zooming in adds small items, names and service lines, and names that would overlap are hidden (selected items first).

Positions come from the two layout drawings, FIM 2 (2000-F00-DRG-GE-10100 Rev 0, new plant) and FIM 1 (2000-F00-DRG-GE-20001 Rev 2, old plant). tools/build_layout.py holds each item's position on a sheet and ties both sheets to the ground through three points surveyed in Google Maps (tails thickener centre, COS 2 dome, FIM COS dome); it writes pfd-layout-data.js. Residuals are about 3 m. Items drawn with an orange dashed outline are estimated because they are not identifiable on either drawing. Anyone can correct a position: open the item, ✥ Move on layout, drag, ✓ Done. Moves are kept on the device and ⬇ Moves downloads them as a small JSON file to build in.

Pipe and valve spec

Search results for pipe lines, manual valves and control valves now include the Piping Materials and Valves Specification (2000-F00-STS-PP-10001 Rev 3). A line shows its piping class (material, design code, pressure test, the design pressure / temperature table), what to expect at that line size (every pipe, fitting, flange, gasket and bolt row of the class that covers the size), the class notes, and the valves the spec allows for that fluid service in that class. A valve shows its datasheet (type, service, size range, ends, actuation, materials, design pressure and temperature) and warns when the valve size is outside the datasheet range. Piping classes (PE16, SS3…) and valve codes (VB03S4, VKGD1L1…) can also be searched directly.

📄 Open the … datasheet opens the spec at that page in a built-in viewer (PDF.js, bundled in vendor/pdfjs), which draws the visible part of the page from the PDF's vectors at the current zoom so it stays sharp; pinch, Ctrl+wheel or +/− to zoom, ◀ ▶ for pages, ⬇ PDF for the whole file. The first open keeps the PDF on the device (its own offline cache, kept across app updates).

python3 tools/build_spec.py <spec pdf> builds spec/pvs.pdf (cover page removed, the names on every revision and sign-off block blacked out, file properties cleared) and spec/index.json (28 piping classes, 75 valve datasheets and the fluid services table, with size ranges as numbers).

Then, in order: python3 tools/spec_notes.py (superscript note numbers and each class's notes), python3 tools/spec_merged.py (clears values copied into cells merged sideways), python3 tools/spec_branch.py (each class's branch chart, and the piping standard drawing a class refers to) and python3 tools/spec_std.py (the lengths on standard drawing 2000-F00-STD-PP-10004, typed in from the drawing; the redacted drawing is spec/2000-F00-STD-PP-10004.pdf). A line's pipe spec has a Fittings table pill: pick a fitting that needs a table (90° branch, 45° and 60° laterals, Y piece, as the class's spec lists them at that size, plus the 30° lateral and tangential tee from the standard drawing for the classes that refer to it; elbows, bends and reducers stay as plain rows in the pipe spec), its size (starts on the line's size) and the branch or small end size, and it shows the fitting the branch chart names, its spec row and, for the lined classes that refer to the standard drawing (CL1, RL1, RL2, RL3, RL5), its lengths; the drawing's link sits at the top. Values the documents don't give are left out.

Drawings (P&IDs and PFD sheets)

python3 tools/build_pids.py <pdf or folder> … splits drawing sets into one PDF per drawing number: P&IDs in PIDs/, PFD sheets in PFDs/, each named by its number (e.g. PIDs/2000-F24-PID-PR-10004.pdf), with PIDs/index.json (title, revision, date, status, size, source sheet). The number is read from the title block (by its labels, or its fixed place on the EPC A1 block for OCR'd sheets), then Tesseract OCR of the corner for scanned older sheets carrying the red EPC stamp, then the sheet order; numbers that still can't be read are set by eye in tools/pid_numbers.json. Two copies of the same sheet keep the later upload. Pages are baked (markups flattened) and derotated. Names, initials and signatures are blacked out: the EPC DRAW / CHECK / DESIGN / TECH APP / PROJ APP block, and on older client / Engineer / Engineer / Engineer title blocks the names in the sign-off tables and revision BY / CHECKED / APPROV columns, the client approval signatory and CAD plot stamps with a login. Some initials in old scanned revision tables may remain. The uploaded originals are not kept in the repository. python3 tools/ocr_pids.py then adds an invisible 500 dpi Tesseract text layer (vertical text included) to every P&ID, so tags and line numbers can be found and marked on the sheet; run it after each rebuild.

Only technical content is kept. After any drawing or document build run python3 tools/sanitize.py (company names in the data become roles such as Owner and EPC, the project number goes, Fimiston becomes FIM) and python3 tools/redact_docs.py (on every drawing the title band, the area outside the frame, project stamps, revision and sign off tables and acceptance stamps go white; on the PDC and pipe spec the headers, footers, cover and sign off blocks; names left in the drawing become roles). The app shows each drawing's number and a short generic title from tools/titles.json above the sheet. Then rerun tools/build_pid_refs.py and tools/build_offline.py and bump the documents cache in sw.js.

In search, a drawing number is a blue underlined link on the drawing's own page (tap to open it), and wherever a record mentions a drawing there is a 📐 open link. Drawings open in the built-in viewer (pdfview.js, shared with the spec), fitted to the screen, with the tag you came from marked in red / yellow (‹ › step through several). Opening another search or drawing clears the mark. A drawing is kept on the device the first time it is opened.

Offline downloads

Settings (phone) or ⬇ Offline (PFD sidebar) lists what can be kept on the device for no signal, each with its size: Everything, the pipe and valve spec, the P&IDs, the PFD sheets, and each source document (tables for the viewer plus its Excel copy). python3 tools/build_offline.py writes offline.json from what is built; documents live in a separate cache (kcgm-docs-N in sw.js, bump N when documents are rebuilt) that app updates keep.

Electrical drawings (SLDs, TLDs, schematics, block diagrams)

python3 tools/build_slds.py files them in SLDs/. Then python3 tools/ocr_slds.py reads the sheets that have no drawn text layer (text drawn as outlines, or scans): once as the sheet lies and once turned a quarter turn, because the feeder names down an SLD are written bottom to top and read upright they come out backwards and match nothing. Sheets with real text are left alone; a sheet read is marked ocrvert in its PDF keywords and skipped next time. About a minute a sheet per core.

python3 tools/build_sld_refs.py then ties each sheet to its contents: every word that is a tag in the equipment, electrical, cable, instrument or control valve lists becomes a tappable box on the sheet (pid-refs.json) and a row under the drawing's own page (sld-tags.json). OCR slips are put right by position (O for 0 in the numbers and so on) and a tag split over two or three words is joined. A tag written on the sheet that no list has (many switchboards, Ethernet switches and distribution boards) is kept under _other in sld-tags.json and shown on the drawing's page as Other tags, each with the other drawings that name it. The script prints the drawings nothing was read on.

Detail rows name a drawing by its number only (Schematic, PFD, Documents); the title is on the drawing's own page.

Touch on drawings, and the fast scroll strip

The drawing viewer (pdfview.js) handles its own pan and pinch. A pinch never hands its speed to a pan: the finger left down when a pinch ends waits a moment and then pans with no glide, the glide speed comes from the last 120 ms of a drag and is capped, the zoom is held inside its limits while pinching, and a finger whose lift was lost is dropped when the next one lands. The hidden sharp layer and the drawing number label take no room, so the sheet cannot be dragged off into empty space.

The fast scroll strip (tabs.js) is the screen's edge as far as its list is concerned: the list keeps its ordinary gap from the edge and gives up the strip's width on top, so nothing in a row sits under the strip. A pane opened over a list (Settings) gets its own strip and the strip of the list underneath is hidden.