Files
LabDataStorageEvaluation/docs/Initial_Prompt.md
administrator eda11aa63e feat(bench): add SQLite and PostgreSQL wrappers for benchmark queries
- implement SQLite and PostgreSQL wrappers to execute benchmark queries
- update README to reflect task 09 as implemented
- enhance storage size updates to handle (format, variant) replacements
- clarify benchmarking methodology for remote PostgreSQL setup
2026-07-11 22:34:23 -04:00

5.9 KiB
Raw Permalink Blame History

Prompt: Generate a Multi-File Specification for a Tribology Data Storage Evaluation Pipeline

You are an AI assistant generating a specification for execution by Anthropic Claude Code in a Cursor development environment (local filesystem, on-premise only, no cloud).

Objective

Produce 12 Markdown files — 00_PLAN.md plus task files 0111 — that specify a complete, reproducible pipeline: simulate a tribology laboratory, generate ~150 MB of realistic measurement data in CSV, convert it into 4 target storage formats, benchmark 7 retrieval scenarios across all 5 formats with resource metering, extrapolate results to 600 GB+, and produce a decision report with tables, charts, and weighted scoring.

File structure requirements

Each task file must contain: Context/Goal, Dependencies, Input, Processing instructions, Output (artifacts + completion marker ./out/.done/<task>.ok). 00_PLAN.md must contain: goals, execution environment, a Mermaid dependency flowchart, parallelism notes, execution order, and global conventions (ISO-8601 UTC timestamps, SI-explicit column names, fixed random seed 20260711, Python with tabs for indentation).

Laboratory configuration (task 01)

  • Material: Ti-6Al-4V coupons 10×10×3 mm, Cr adhesion layer, Pt-Au coating sputtered in a composition gradient; film thickness 0.31.1 µm.
  • Instruments: RAPID custom high-throughput parallelized 6-probe tribometer (friction); Bruker TI980 TriboIndenter (nanoindentation); Bruker M4 Tornado micro-XRF (composition mapping); Kurt J. Lesker PVD 200 sputter-down (deposition); AFM (roughness); optical profilometry (thickness); SIMTRA (sputter-transport Monte-Carlo simulation).
  • Deposition matrix, 4 batches (B721B724) with gun tilt (20°:0°, 20°:20°, 20°:20°, 0°:20°), Pt/Au power (150/50, 100/100, 150/50, 50/150 W) and discharge voltages.
  • Hierarchy and volumes: batch(×4) → wafer(×3) → coupon(×49, 7×7 grid) = 588 coupons; 480 friction coupons (4 RAPID runs × 5 plates × 6 probes × 4 coupons/square), 108 reserve; 2 environments (Lab Air / Dry N2, 2 runs each); 3 replicate tracks per coupon with counterface rotation → 1,440 tracks × 1,000 cycles = 1.44 M cycle rows; friction loops (200 points every 100th cycle) → 2.88 M loop points.
  • Physical models for simulation: exponential COF run-in with steady-state depending on Au% and environment; hardness/modulus linear in Au% with noise; log-normal roughness; Archard wear; Au gradient across wafer position (batch-dependent center: 8/25/10/60 wt%).

Process flow diagrams (task 02) — Mermaid

Coupon assembly (clean → sonicate → Cr adhesive → PVD sputter); characterization & batch assembly (SIMTRA, profilometry, ×49/wafer, ×3/batch, batches 721724); testing tree (friction µ_normal/µ_dry_nit, nanoindentation, AFM, XRF); tribometer session sequence (request → samples → ball holders, 3 counterfaces/holder → Excel test plan → setup → run → software stop → save avg files → teardown); execution loop (5 plates × 6 probes × 4 coupons × 3 tracks with counterface rotation); data-hierarchy ERD.

Data generation (task 03)

Hierarchical CSV file tree mirroring the lab structure (batches, simtra, per-coupon xrf_map/profilometry/nanoindentation/afm, per-track track_info/cof_vs_cycle/ friction_loops/wear), streaming generation, MANIFEST.csv with row/byte/sha256, size guard 120200 MB.

Conversions (tasks 0407), each recording sizes into storage_sizes.csv

  • JSON-LD: vocab + QUDT + PROV-O; two variants — FULL (bulk embedded, per-coupon files, compact) and HYBRID (metadata only, sourceFile links to CSV).
  • SQLite: single file, integer surrogate keys, WITHOUT ROWID bulk tables, precomputed track_summary, indexes for the benchmark queries, load PRAGMAs, VACUUM/ANALYZE.
  • PostgreSQL 16: same logical schema, RANGE partitioning of bulk tables, COPY loading, b-tree + BRIN indexes, materialized track_summary, pg_dump archive.
  • RDF: N-Triples.gz + Turtle serializations; queryable embedded store (oxigraph preferred, Fuseki/TDB2 fallback); document triple-modeling decisions; expect 2545 M triples.

Benchmarks (tasks 0809)

Seven scenarios: Q1 single-track COF curve; Q2 steady-state COF at Au=10±0.5 wt%; Q3 hardness vs COF join; Q4 condition filter (Dry N2, 100 mN, cof>0.20); Q5 mean run-in per batch aggregating ALL raw cycles (summary tables forbidden); Q6 wear volume vs load join; Q7 Stribeck-style grouped aggregation. Implement per format (direct path read / ijson streaming / SQL / SQL+EXPLAIN / SPARQL); identical result sets validated by checksum. Harness: each cell in a separate subprocess; psutil metering (wall time, peak RSS, CPU time/utilization, read bytes); 1 warm-up + 3 measured runs, medians; 30-min timeout; outputs results_raw.csv / results_median.csv.

Extrapolation (task 10)

Project storage linearly and query time by access-pattern complexity laws (O(1)/O(log n)/O(n)/single-threaded vs parallel partitioned scan) from the 150 MB calibration point to 600 GB, 1.2 TB, 6 TB; flag >1 h IMPRACTICAL, >24 h FAIL; RAM models per format; hardware sizing and cost table driven by an editable hw_prices.yaml (June 2026 defaults: DDR5 RDIMM ~$14/GB, enterprise NVMe ~$250/TB, 16-core 1U ~$6k).

Reporting (task 11)

Tables (footprint + coefficients vs CSV, measured metrics, projected times with flags, hardware costs, scoring matrix); matplotlib charts (log scales): footprint, RAM, per-query bars, degradation curves 150 MB→6 TB, stacked weighted score, cost-vs-performance scatter. Weighted scoring: search speed ×5 (050), RAM economy ×2 (020), disk economy ×1 (010), max 80; search score from inverse geometric mean of Q1Q7 projected at 600 GB. Concise English narrative: executive summary and use-case mapping (analysis, reports, search/filter, archiving, inter-lab exchange), limitations.

Style

Specification prose in English, concise and directive. No implementation code in the spec — only precise instructions an autonomous coding agent can execute.