Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update scenario.md #475

Merged
merged 3 commits into from
Aug 30, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 39 additions & 28 deletions docs/manuals/core/concepts/scenario.md
Original file line number Diff line number Diff line change
@@ -1,28 +1,36 @@
We introduce here the important concept of a `Scenario^`. A Taipy Scenario represents an instance of a
business problem to solve on consistent data and parameter sets.
Introducing the `Scenario`, a fundamental key concept in Taipy.

As its name implies, with Taipy scenarios, the users can instantiate different versions of a business
problem with different assumptions. This is extremely useful in a business context where impact analysis
and what-if analysis are essential in the decision process.
A Taipy *Scenario* represents a business problem with consistent data and parameters.

After analyzing its first scenario, an end-user may be interested in modifying input
data nodes (not the intermediate nor the output data nodes), re-running the same pipelines, and
comparing the results with the previous run.
Scenarios are a powerful tool to create different versions of a business problem under different
assumptions. This is especially valuable for what-if analysis in decision-making processes,
enabling users to create, store, edit, and execute multiple scenarios with various
parameters within the same application.

For this purpose, he needs to instantiate a second scenario, execute it and compare it with the
first scenario. This process can be repeated across multiple scenarios.
Once an initial scenario has been analyzed, users can modify the input data nodes (excluding
the intermediates and output data nodes), rerun part of its tasks, and compare results.

This involves instantiating a second scenario, changing the input data, executing it,
and comparing the outcomes with the first scenario.

This iterative process can be repeated across multiple scenarios, allowing for comprehensive
exploration and analysis of different problem variations.

!!! example "In the example"

Here, our scenario consists of the two pipelines described earlier. The external light blue box in the flowchart
below represents our scenario that contains both pipelines.
Here, our scenario consists of the two pipelines described earlier. The external light
blue box in the flowchart below represents our scenario that contains both pipelines.

![scenarios](../pic/scenarios.svg){ align=left }

A scenario represents one instance of a business problem to solve. Each new business problem instance
is represented by a new scenario. With Taipy, end-users can create, store, edit, and
execute various scenarios within the same application.

Two use-cases arise from the utilization of Taipy scenarios:

### - Use case 1 :
Each *scenario* represents a distinct instance of a business problem.

With Taipy, end-users can create, store, edit, and execute various scenarios within the
same application.

!!! example

Expand All @@ -32,27 +40,30 @@ execute various scenarios within the same application.

- then, based on that forecast, generate the planning for the production orders.

The end-user creates the first scenario for January. It must contain everything the end-user needs
to understand the January case, access input data, compute predictions, visualize our
forecast algorithm results, make production decisions, and publish the January production orders.
The end-user creates the first scenario for January. It must contain everything the
end-user needs to understand the January case, access input data, compute predictions,
visualize our forecast algorithm results, make production decisions, and publish the
January production orders.

Then the end-user creates another scenario for February using the new information provided for the
February period. And so on.
Then the end-user creates another scenario for February using the new information provided
for the February period. And so on.

Two _scenarios_ can also represent the same instance of a business problem but with two different sets of
### - Use case 2:
Two *scenarios* represent the same business problem instance, but with different sets of
assumptions.

!!! example

The end-user would like to simulate the impact of our capacity data on production planning for the
February use case.
The end-user wants to simulate how the capacity data affects production planning for
the February situation.

The first scenario can forecast demand and compute production orders assuming a low capacity,
whereas the second assumes a higher capacity value.
In the first scenario, we forecast demand and calculate production orders based on a low
capacity assumption. In the second scenario, we assume a higher capacity value.

One can note that data scientists can also use scenarios. This is often referred to as ‘experiments’.
Scenarios are in fact, a generalization of experiments in such a way that both data sceintists
and end-users can finally use the same concept: the Scenario.
It's important to note that scenarios are not only useful for end-users, but also for
data scientists. They can use scenarios as experiments to test different hypotheses.
Essentially, scenarios provide a common concept that both data scientists and end-users
can utilize.


[:material-arrow-right: The next section introduces the Cycle concept.](cycle.md)
Loading