You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
UQPyL is a Python library for uncertainty quantification, optimization, inference, calibration, and surrogate modeling.
10
10
It defines problems once and reuses them across UQ workflows.
@@ -24,32 +24,27 @@ These workflows are common across model-based domains, especially in hydrology,
24
24
| Calibrate simulation models | Compare simulated series with observations. | Calibration methods based on `ModelProblem`. |
25
25
| Reduce expensive evaluations | Build a cheaper approximation of a slow model run. | Surrogate models and surrogate-assisted workflows. |
26
26
27
-
## Documentation
28
-
29
-
- Documentation: <https://uqpyl.readthedocs.io>
30
-
- Source code: <https://github.com/smasky/UQPyL>
31
-
32
27
## Core idea: define once, reuse everywhere
33
28
34
29
UQPyL does not own your model logic. Instead, you wrap your model or decision problem as a shared `problem` definition with:
35
30
36
31
| Part | Meaning |
37
32
|---|---|
38
33
| Input space | Variables, bounds, labels, and variable types. |
39
-
| Evaluation rule | How a batch of inputs becomes objectives, constraints, or simulations. |
34
+
| Evaluation rule | How a batch of inputs becomes objectives, constraints, or extract required simulation data. |
40
35
| Optimization direction | Whether each objective is minimized or maximized. |
41
36
| Runtime identity | A name and metadata used by saved runs and summaries. |
42
37
43
-
Once defined, the same object can be reused by DOE, analysis, optimization, inference, surrogate workflows, and calibration. Some workflows also need explicit model-aware information such as simulations, observations, or masks.
38
+
Once defined, the same object can be reused by DOE, analysis, optimization, inference, surrogate workflows, and calibration. Some workflows also need explicit model-aware information such as simulations and observations.
44
39
45
40
## Problem abstraction
46
41
47
42
The `problem` module is the conceptual entry point of UQPyL.
48
43
49
-
| Abstraction | Role |
44
+
| Abstraction Python Class | Role |
50
45
|---|---|
51
46
|`Problem`| For methods that only need final objective or constraint values. |
52
-
|`ModelProblem`| For methods that need explicit model-process semantics such as `sim`, `obs`, or masks. |
47
+
|`ModelProblem`| For methods that need explicit model-process semantics such as `sim` or `obs`. |
53
48
54
49
Both abstractions share the same foundation:
55
50
@@ -58,9 +53,9 @@ Both abstractions share the same foundation:
58
53
|`Space`| Defines variables, bounds, labels, and variable types. |
59
54
|`Eval`| Standard return object for evaluated results. |
60
55
61
-
The module also includes benchmark problems such as `Sphere`, `Ackley`, `ZDT`, and `DTLZ`.
56
+
The module also includes benchmark problems such as `Sphere`, `Ackley` and so on for single-objective optimization; `ZDT`, and `DTLZ` for multi-objective optimization.
62
57
63
-
Use `Problem` when methods only need final objectives or constraints from candidate inputs. `Problem` can still be used for model-based problems when those final values are enough. Use `ModelProblem` only when methods need explicit simulations, observations, masks, or simulated-versus-observed comparison. In the current design, this mainly applies to calibration workflows.
58
+
Use `Problem` when methods only need final objectives or constraints from candidate inputs. `Problem` can still be used for model-based problems when those final values are enough. Use `ModelProblem` only when methods need explicit simulations, observationsor simulated-versus-observed comparison. In the current design, this mainly applies to calibration module (`IES`, `ES`, `GLUE`, `SUFI2`).
64
59
65
60
<palign="center">
66
61
<imgsrc="./docs_v2/assets/Problem.webp"alt="Problem and ModelProblem comparison"width="1000"/>
@@ -76,7 +71,7 @@ UQPyL is organized around one shared `problem` abstraction and a set of function
The figure summarizes the main idea: represent a modeling task as a shared `problem` definition, then reuse that definition across DOE, analysis, optimization, inference, calibration, and surrogate workflows, with unified outputs and optional runtime storage.
74
+
The figure summarizes the main idea: represent a modeling task as a shared `problem` definition, then reuse that definition across DOE, analysis, optimization, inference, calibration, and surrogate workflows, with unified outputs and optional runtime storage. You can freely organize your workflows.
80
75
81
76
| Type | Module | Purpose |
82
77
|---|---|---|
@@ -92,19 +87,18 @@ Visualization, runtime storage, logs, and readers are exposed through the functi
92
87
93
88
## Typical workflows
94
89
95
-
Common workflow patterns all lead to structured outputs and optional runtime storage. Workflows that only consume final objectives or constraints can use `Problem`, while workflows that need explicit `sim`, `obs`, or related comparison semantics use `ModelProblem`.
90
+
Common workflows patterns all lead to structured outputs and optional runtime storage.
96
91
97
92
```text
98
93
Problem -> DOE -> Analysis -> outputs
99
-
Problem -> Optimization -> outputs
100
-
Problem -> Inference -> outputs
94
+
Problem -> DOE -> Analysis -> Inference -> outputs
0 commit comments