Projects, Groups & Scenarios
Organize work into projects, groups, and scenarios.
JW Slope organizes work into a three-level hierarchy: a project contains one or more groups, and each group contains one or more scenarios. Scenarios let you analyze design variants of the same problem side by side, each with its own geometry, materials, water, loads, support, and analysis settings.
The hierarchy
| Level | Description |
|---|---|
| Project | The top-level container. One project corresponds to one .jws file. |
| Group | A collection of related scenarios. Groups are a flat list; they are not nestable. Each group has a master scenario. |
| Scenario | A single analyzable model. Scenarios within a group can be arranged in a parent-child tree, and one is marked the master. |
A new project opens with a single group ("Group 1") containing a single master scenario.
What a scenario stores
Each scenario carries its own complete model state:
- Geometry (external boundary, material regions, weak layers, tension cracks, support lines).
- Material assignments and per-material water settings (the material and support catalogs are shared at the project level).
- Loads (distributed, line, and seismic).
- Groundwater and boundary-condition settings.
- Ground support assignments.
- Compute settings (search method, analysis methods, slice count, failure direction, and related options).
The scenario explorer
A scenario explorer tree appears in the sidebar. It lists each group with its scenarios nested beneath, and groups can be expanded and collapsed. For each scenario the tree shows:
- The scenario name (editable in place).
- Its result status — for example Idle, Stale, Running, Complete, or Failed.
- The factor of safety once a result is available.
Right-click context menus on groups and scenarios provide management actions such as renaming.
Result caching
Results are cached per scenario and keyed by an input hash computed from all of the scenario's inputs (geometry, materials, loads, water, support, and compute settings).
- When you compute a scenario, the result is stored against its current input hash.
- If you compute again without changing anything, the cached result is reused — no recomputation occurs.
- Any change that affects the inputs produces a new hash and marks the cached result stale, so the next compute runs fresh.
The input hash deliberately ignores display-only and derived fields (such as view state and previously computed results), so cosmetic changes do not invalidate a cached factor of safety.
This caching makes it inexpensive to keep many scenarios in a project: only the scenarios whose inputs have actually changed need to be recomputed. Cached results are persisted alongside the project — see Native Format & Autosave for how the results sidecar is stored.