Demo Scenarios#

These demos showcase drawing_tools semantic checks on a sample assembly drawing. Each one cross-checks a drawing against its Bill of Materials (or against itself), produces a Markdown report, and renders an annotated interactive visualization (green = OK, red = mismatch).

They live in the installable package drawing_tools.demo_scenarios (under src/drawing_tools/demo_scenarios/) — each scenario folder holds a scenario.md (what the check does), a minimal_script.py (entry point: prints, writes the <scenario>_report.md and the .html visualization), and a build_visualization.py (the overlay primitives).

Note

Run a single demo with python -m drawing_tools.demo_scenarios.<scenario>.minimal_script, or all of them with python -m drawing_tools.demo_scenarios.run_all. The generated report and .html are written to the current working directory, so run these from wherever you want the outputs to land.

🎯 Balloon addresses

Each balloon’s grid address vs the BOM ZONE column.

Balloon addresses — BOM ZONE check
🔢 Balloon quantities

Each tag’s effective balloon quantity vs the BOM QTY column.

Balloon quantities — BOM QTY check
🛡️ Safety class

Title-block safety class vs the BOM metadata.

Safety class — drawing vs BOM
✂️ Section lines

Every section-line indicator resolves to a section view.

Section lines — cross-reference with views
🔤 View-name formatting

View-title char height / vocabulary / font style.

View-title text formatting
📐 View scale vs title block

A view scale must differ from the title-block scale.

View scale vs title block scale

Running on the Dessia platform#

The same checks are also exposed as runnable Dessia platform workflows, so a user can upload a drawing (and its BOM) in the web UI and get the report + annotated visualization without running anything locally. This lives in the drawing_tools.demo_scenarios._platform subpackage:

  • InputData — a DessiaObject whose from_input_files reads the uploaded drawing JSON (and optional BOM .xlsx) into a FeaturedDrawing plus the BOM-derived facts.

  • one *Check DessiaObject per scenario — from_input_data runs the scenario’s logic and exposes the report (@markdown_view) and the annotated drawing (@plot_data_view). The checks reuse the same functions as the standalone scripts above (single source of truth).

Shared input preparation. Mirroring Airbus’s DataPreparation pattern, a single PrepareInputData workflow turns the uploaded file(s) into an InputData, and each check workflow consumes that object. On the platform, PrepareInputData is run once per distinct drawing and every check on that drawing reuses the same run’s output (workflow chaining) — e.g. the four checks on the shared support_assembly drawing share one preparation run.

Generate and locally validate the workflow JSONs:

python -m drawing_tools.demo_scenarios._platform.build_workflows    # writes workflows/*.json
python -m drawing_tools.demo_scenarios._platform.validate_workflows # runs prep + checks off-platform

Deployment with dessia-cli#

Uploading the workflows and running them on a platform is driven from the dessia-cli repository, by its generic scripts/platform_deployment/deploy.py orchestrator (authenticate → ensure packages → ensure workspace → upload workflows → run), pointed at a config dedicated to these demos:

# in dessia-cli/scripts/platform_deployment/
python deploy.py --config deploy_config_drawing_demo.yaml --dry-run   # preview
python deploy.py --config deploy_config_drawing_demo.yaml             # real run

deploy_config_drawing_demo.yaml declares the packages to install, the seven workflow JSON files to upload, and the runs (the shared PrepareInputData runs, then the checks chained on their output). The check/prep classes travel to the platform worker inside the drawing_tools wheel — which is exactly why the demo code lives under src/ rather than in scripts/: installing a recent enough drawing_tools on the platform makes drawing_tools.demo_scenarios._platform importable on the worker.