Tutorials
Learning-oriented guides for getting GeoSC installed and running end to end.
Pages
- Quick Start — supported install paths, packaged vs source-checkout usage, and a first CLI run.
Learning-oriented guides for getting GeoSC installed and running end to end.
Get GeoSC running quickly through the installed geosc CLI.
Use this path if you are consuming a local release candidate or a maintainer- provided build outside the repo tree.
Built artifacts install the package and the geosc CLI. They do not include
the repo’s data-config/, recipes/, or shapemap/ directories, so packaged
usage should point to your own YAML config files and input data.
Use this path if you want the shipped example configs under data-config/ or
you are developing locally.
Optional CuPy-backed acceleration is available only for unseeded power-analysis runs. Main SparseSC inference remains CPU-based.
Packaged-install example:
Source-checkout example with shipped demo configs:
GeoSC ships canonical example configs under data-config/ in the source tree:
power_analysis_config.yamldonor_eval_config.yamlgeolift_analysis_config.yamlFor the full pipeline, point geosc pipeline at any one canonical YAML
file from that directory. The recommended anchor is the inference config:
The pipeline writes:
outputs/multicell_power_analysis/outputs/multicell_donor_eval/outputs/multicell_geolift_analysis/outputs/geolift_pipeline_report.mdoutputs/geolift_pipeline_report.htmlIf you override the pipeline root:
GeoSC preserves the same legacy stage/report names under results/demo_run/.
Useful pipeline selectors:
--config is required on every command.pipeline, --config is a config-directory anchor through one canonical
YAML path, not a separate pipeline schema.--jobs is meaningful for power and donor evaluation.--use-gpu requests optional CuPy-backed power acceleration only; seeded
power runs use CPU simulation paths for reproducibility, and inference remains
CPU-based.--data, --create-plots, and --no-create-plots are infer-only flags.python runme.py still works as a compatibility wrapper. The preferred path is:
Legacy recipe scripts remain usable for migration, but they are not the primary quick-start path anymore.