Projects, Groups & Scenarios
Organize work into projects, groups, and scenarios.
JSlope 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 related design variants while the group keeps their section geometry coordinated.
The hierarchy
| Level | Description |
|---|---|
| Project | The top-level container. One project corresponds to one .jws file. |
| Group | A flat, non-nestable collection of related scenarios with one master scenario. External and material-boundary geometry is group-owned. |
| Scenario | One analyzable case within a group, with its own scenario inputs and result status. |
A new project opens with a single group ("Group 1") containing a single master scenario.
What a scenario stores
Each scenario snapshot stores:
- Geometry including water, weak layers, tension cracks, and support lines.
- Material assignments and per-material water settings, and the scenario's own material and support catalogs. Rockfall Rock and Source definitions are shared by the whole project.
- Distributed, line, and seismic loads.
- Groundwater and boundary-condition settings.
- Ground-support assignments.
- Compute settings such as search and analysis methods, slice count, failure direction, and related options.
A group shares its External Boundary and material boundaries: editing them in any scenario of the group changes them in every scenario of the group. Each scenario keeps its own region materials, which follow the new boundaries, and its own boundary conditions, which follow the edited segments; a condition left without a segment is removed and the Console says so. Scenarios that take new group geometry become Stale. A scenario saved with different group geometry keeps it, and the Console names it.
Every other input belongs to its scenario. Editing the master scenario changes the master only; the master is the template new scenarios in its group copy, and it cannot be deleted. To edit several scenarios at once, select them, or their group, in the Scenario Explorer.
The scenario explorer
The Scenario Explorer lists each group with its scenarios beneath it. It shows the scenario name, result status (Queued, Running, Complete, Failed, or Stale), and FOS when a complete result is available.
Use the check-circle beside a scenario to include or exclude it from the next LEM batch. Right-click context menus can enable or disable a whole group and provide rename, duplicate, and delete actions. The master scenario cannot be deleted.
A plain click changes the active scenario. Ctrl/Cmd-click toggles linked selection, Shift-click selects a range, and selecting a group selects its scenarios.
Settings edits and material and support property edits apply to every selected scenario. Each selected scenario receives only the values you changed, so values it already differs in stay as they are. A material or support you delete stays in a selected scenario that still uses it, and the Console says so. Duplicate copies each selected scenario's own material or support, and moving a material reorders the materials the scenarios share while a scenario's own materials keep their place. A water surface naming a piezometric line that a selected scenario does not have is not set there. Groundwater boundary conditions work like materials: each condition has its own identity, kept when you edit it and when you copy a scenario. A selected scenario receives only the conditions you added, changed or removed, so its other conditions stay as they are, and a changed condition receives only the values you changed. A condition you changed or removed that a selected scenario does not have is skipped there, and the Console says so. Timed boundary replacement sets follow the same rules. A condition on an External Boundary segment lands on the same segment of each selected scenario; where a scenario has no such segment, Apply is refused and names the scenario. Search Complexity presets use each scenario's own search method. Geometry and drawing edits apply to the active scenario only, apart from the group geometry described above.
Compute all enabled scenarios
The dock action labelled LEM Compute runs every enabled scenario in project order, not only the active scenario. JSlope queues them, computes them sequentially, records Complete, Failed, or Stale status for each, and restores the scenario that was active before the batch began. If no scenario is enabled, the run is rejected.
Stopping a batch can clear the current partial result or keep the best result available so far. Scenarios that were still queued return to Stale.
Result state and persistence
Each scenario retains its computed result until an analysis input changes. Input changes mark the affected result Stale; pressing LEM Compute starts a fresh solve for every enabled scenario, even when a previous result is still available.
When a .jws file is written, JSlope calculates an input hash for each scenario and records it with any bundled result. On open, those hashes prevent a result from being attached to different scenario inputs. The hash is an integrity and staleness check, not a promise that pressing Compute will skip the solver.
Display-only state is not an analysis input, so changing result styling or the viewport does not make a factor of safety stale.
Computed scenario results are bundled into the saved project. See Native Format & Autosave.