Results & Downloads¶

How results flow¶

There are two paths to get results off a VM:

Path 1: Manual workflow (vm push + results download)¶

You run analysis on the VM
  → ops-hpc vm push <name>          (VM → GCS, fast internal network)
  → ops-hpc results download --dir  (GCS → your PC, over internet)
  → Bucket auto-cleaned after verified download

Path 2: Automated workflow (run command)¶

ops-hpc run --jobs jobs.txt
  → VM runs each job sequentially
  → After each job, results uploaded to GCS automatically
  → VM deleted when all jobs done
  → ops-hpc results download        (GCS → your PC)

Path 2b: No-SSH workflow (run-staged)¶

ops-hpc run-staged batch.txt
  → Zips + uploads analysis dirs to GCS _uploads/
  → Creates VM with startup script
  → VM boots, downloads zip, runs run_analysis.sh
  → Each model: run → zip results → upload to GCS → clean disk
  → VM self-deletes when done
  → ops-hpc log                     (check progress)
  → ops-hpc results download        (GCS → your PC)

Path 3: GUI auto-download¶

GUI polls GCS every 5 minutes
  → Downloads new results automatically
  → Verifies + cleans from GCS
  → No action needed

In all cases, the bucket is cleaned after verified download — you only pay for the minutes/hours between upload and download.

Result formats¶

Results can be in two formats:

Zip files (new): run_analysis.sh uploads results as MODEL_NAME.zip files. Download auto-extracts them.
Directory trees (legacy): vm push uploads individual files in timestamped directories. Download handles these transparently.

The download command auto-detects which format each result set uses.

Bucket prefixes¶

The GCS bucket uses special prefixes (starting with _) for internal data. These are ignored by results download:

Prefix	Purpose
`_uploads/`	Staged analysis zips (from `stage` or `run-staged`)
`_status/`	Latest status file (`latest.txt`)
`_logs/`	Run logs from `run_analysis.sh`

Only objects outside _ prefixes are treated as downloadable results.

CLI commands¶

results list¶

Show what's in the GCS bucket without downloading.

ops-hpc results list

Example output:

2 result set(s), 3.4 GB
  TTFlat_sanfran_20260406-153012  (325 files, 1.1 GB)
  ShearWall_20260406-180045      (180 files, 2.3 GB)

Each result set is a timestamped directory. The timestamp is added by vm push to prevent overwrites between runs.

results download¶

Download results from GCS to your PC. Shows progress percentage.

ops-hpc results download                                        # download to ./results/
ops-hpc results download --dir H:\OpenSeesAnalyses\TTFlat       # custom directory
ops-hpc results download --watch                                # keep polling (armed download)
ops-hpc results download --watch --interval 120                 # poll every 2 minutes

Flag	Description
`--dir`, `-d`	Download directory (default: ./results)
`--watch`, `-w`	Keep polling for new results until Ctrl+C
`--interval`	Poll interval in seconds (default: 60)

One-shot mode (default): lists available results, asks for confirmation, downloads, verifies, cleans from GCS.

Watch mode (--watch): sits armed and polls the bucket continuously. The moment results appear, it downloads them. After each download it goes back to polling. Useful for: - Starting watch before going to sleep while analysis runs - Automated run command that uploads results between jobs - Multiple VMs pushing results at different times

Watch mode never stops on its own — Ctrl+C to exit.

[watch starts] → polls... nothing
→ Job 1 results appear → downloads → cleans from GCS
→ polls... nothing...
→ Job 2 results appear → downloads → cleans from GCS
→ polls... (forever until Ctrl+C)

Pushing results from a VM¶

Before you can download results, they need to be in GCS. Two ways:

Manual: vm push¶

ops-hpc vm push my-vm

This SSHes into the VM and runs gsutil -m rsync -r to sync the analysis directory to GCS. Uses Google's internal network (fast). Each subdirectory gets a timestamped prefix:

/tmp/ops-hpc-analysis/TTFlat_sanfran/ → gs://bucket/TTFlat_sanfran_20260406-153012/

Automated: run command¶

The run command handles upload automatically after each job completes. No manual push needed.

Automated: run-staged¶

The run-staged workflow uses run_analysis.sh on the VM, which zips each model's results and uploads them as MODEL_NAME.zip to GCS. The VM self-deletes after all models complete. Monitor with ops-hpc log.

Download tracking¶

download_state.json (in the results directory) persists download state across restarts:

Status	Meaning
`pending`	Seen in GCS, not yet started
`downloading`	Download in progress
`downloaded`	Download complete + verified
`cleaned`	Deleted from GCS
`failed`	Will retry on next poll

If your PC crashes mid-download, the tracker resets interrupted downloads to failed on next startup, and they auto-retry.

Verification¶

Before deleting from GCS, every file is verified:

Local file size must match GCS blob size
If any mismatch: keeps files in GCS, marks as failed, retries later

This ensures you never lose results — GCS objects are only deleted after confirmed local copy.

Storage costs¶

Results in GCS cost ~$0.026/GB/month. Since they're typically there for minutes to hours (until downloaded), the cost is negligible. After download + verification, objects are deleted automatically.

Direct download (vm download)¶

For grabbing small individual files directly from a running VM via SCP:

ops-hpc vm download my-vm /tmp/ops-hpc-analysis/output.txt

Do not use this for large result sets — PuTTY's SCP fails on large recursive transfers. Use vm push + results download instead.

Emergency download¶

If an analysis is killed or times out, partial results may still be on the VM disk. Use the GUI's EMERGENCY DOWNLOAD button to:

Kill OpenSees processes
Upload whatever exists to GCS
Keep VM alive for manual inspection if needed
Then use STOP VM NOW when done

Or manually via CLI:

ops-hpc vm push my-vm              # push whatever's on disk to GCS
ops-hpc results download           # download from GCS
ops-hpc terminate my-vm            # kill the VM