Skip to content

Commit

Permalink
update some terms and add warning
Browse files Browse the repository at this point in the history
  • Loading branch information
jmcook1186 committed Nov 10, 2023
1 parent 7a733d9 commit 6f0e473
Show file tree
Hide file tree
Showing 3 changed files with 31 additions and 27 deletions.
22 changes: 14 additions & 8 deletions website/docs/03-Terminology.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ Is a graph of nodes that defines an ontology we want to model, for example an ap
### Model

**aka:** *model*
Is a model that given some inputs returns some outputs. For example, if you input some CPU utilization, it might be a model that translate that into an estimate of energy consumed.
Is a model that given some Inputs returns some outputs. For example, if you input some CPU utilization, it might be a model that translate that into an estimate of energy consumed.

### Model Plugin

Expand Down Expand Up @@ -47,24 +47,30 @@ This is a node in the graph used to group multiple components and/or other group

### Observation

**aka**: *inputs*
An **input** is something you measure regarding a component in your subject at a particular time and for a particular duration. For example, an input about a server might be CPU utilization.
**aka**: *Input fields*
An **Observation** is something you measure regarding a component in your subject at a particular time and for a particular duration. For example, an observation about a server might be CPU utilization. An Input is made up of observations.

### Input

an Input is a collection of ModelParams containing Observations. An Input is all the information connected with one timespan.


### ModelParams

ModelParams are parameters passed to a model. Some are inputs, some are observations, some may have other meanings. They all conform to a defined [Type](https://github.com/Green-Software-Foundation/if/blob/29280ff9cd9c9a843ab1842c728751aafdf21756/src/types/impl.ts#L14).
ModelParams are parameters passed to a model. Some are inputs, some are observations, some may have other meanings. They all conform to a defined [Type](https://github.com/Green-Software-Foundation/if/blob/29280ff9cd9c9a843ab1842c728751aafdf21756/src/types/impl.ts#L14). Inputs are composed of a collection of ModelParams.

### Graph Duration
**aka**: ~
Every [Graph](specification/graph.md) represents a duration of time for which observations have been gathered about it's components. By default the graph duration will be the time from the earliest observations to the latest observation for all of it's components.

### Impact Duration
### Duration
**aka**: ~
Every Impact Metric is for a particular time and duration. The duration of a Metric determines the granularity of the output timeseries. If the impact duration is equal to the graph duration then only one Metric will be computed for the whole graph. If the impact duration is less than the graph duration then multiple Metrics might be computed.

### Input Duration
Every Input is for a particular time and duration. The duration of a Metric determines the granularity of the output timeseries. If the impact duration is equal to the graph duration then only one Metric will be computed for the whole graph. If the impact duration is less than the graph duration then multiple Metrics might be computed.

### Duration
**aka**: ~
Every [input](input.md) is for a particular time and duration, this is called the input duration. There are usually multiple inputs provided as a time series, the input duration does not need to equal the impact duration which does not need to equal the graph duration.
Every [Input](input.md) is for a particular timespan, known as the duration. There are usually multiple Inputs provided as a time series, the duration does not need to equal the impact duration which does not need to equal the graph duration.

### Computation
**aka**: ~
Expand Down
4 changes: 3 additions & 1 deletion website/docs/04-specification/durations.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,8 @@ abstract: A core component of impact graphing is the concept of time and specifi
---
# Durations

> **WARNING** Much of the following material is not yet implemented in the alpha releae, but is on the roadmap for future releases.

> Terminology
> - **Graph Duration**: Total global duration for the whole Impact Graph.
Expand All @@ -12,7 +14,7 @@ abstract: A core component of impact graphing is the concept of time and specifi
## Introduction

- Every [Impact Graph](Impact%20Graph.md) (graph) represents a **duration** of time.
- Every [graph](graph.md) (graph) represents a **duration** of time.
- The **duration** can be explicitly defined in the graph or it can be implied by the timestamp of the first input in any of it's components and the last timestamp (+duration of that input).
- Duration and time is a core component of any impact measurement, every input is for a time and duration and every output impact metric is for a time and duration.
- The times and durations of input inputs and output impact metrics do not have to match.
Expand Down
32 changes: 14 additions & 18 deletions website/docs/04-specification/graph.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,17 +2,13 @@
author: Asim Hussain (@jawache)
abstract: An impact graph is the core construct in an Impact Framework through which all the other components interact.
---
# Impact Graph
# Graph

## Introduction

An Impact Graph is a manifest that defines everything you need to calculate the environmental impact of a piece of software.
A Graph is part of the manifest file that defines everything you need to calculate the environmental impact of a piece of software. The graph itself it the part of the manifest that comes after the global config. It describes the architecture of the application being studied and contains the inputs for each component.

You can describe it in YAML format ([impl](Impl%20(Impact%20YAML).md)) and execute using a command line tool ([Impact](Impact.md)) using static input data ([input](input.md)). It can output a single value or a time series of outputs so you can narrow down the moments of peak environmental impacts. It can also be constructed in code using the IEF SDK for use cases where real-time streaming or monitoring of impacts is required.

It allows you to evolve, start course grained for a fast high-level impact calculation, and then add granularity (structural and temporal) over time to dig deeper and identify the areas that drive the most impacts.

It's incredibly flexible. Using plugins, you can configure it to calculate any environmental impact (carbon, water, energy) for any calculation methodology (sci, ghg, others).
You can describe it in YAML format ([impl](Impl%20(Impact%20YAML).md)) and execute using a command line tool ([Impact Engine](impact-engine.md)) using static input data.

The flexibility of impact graphs means they can represent a running software application, a user journey, or a campaign - it should be possible to measure anything with an impact graph. We call the thing an Impact Graph is measuring an **Impact Subject**.

Expand All @@ -22,7 +18,7 @@ Impact Graph is the core of the Impact Framework.

## Structure

See the [[Impl (Impact YAML)]] spec for the latest and complete information regarding the structure of an Impact Graph.
See the [Impl](./impl.md) spec for the latest and complete information regarding the structure of an Impact Graph.

In summary, an Impact Graph has a root node containing configuration detailing **how** the graph is computed and a graph node containing details about all the components that make up this impact subject.

Expand All @@ -34,10 +30,10 @@ The intermediate nodes (**Groupings**) represent a grouping of leaf nodes for us

### Component

Each component has some configuration, some inputs, and a model.
Each component has some configuration, some Inputs, and a model.
- **Configuration** describes shared information regarding this component and, most importantly, parameters required by this model.
- **inputs** are a time series of data points used as inputs to the model.
- **Model** is a plugin ([[Impact Model Plugin]]) which when given some configuration and a series of [[input]], can calculate the impact, e.g. carbon impact from an input of CPU utilization.
- **Inputs** are a time series of data points used as inputs to the model.
- **Model** is a plugin [Model Plugin](./model-plugin.md) which when given some configuration and a series of [Inputs](./inputs.md), can calculate the impact, e.g. carbon impact from an input of CPU utilization.

![](../../static/img//decc58c3420d1e4e3701e5d1ac12883e.png)

Expand All @@ -51,7 +47,7 @@ A computation of an Impact Graph can create one Impact Metric. It can also be co

### Pipeline

See [Computation Pipeline](Computation%20Pipeline.md) for details regarding the phases of an Impact Graph Computation.
See [Computation Pipeline](./computation-pipeline.md) for details regarding the phases of an Impact Graph Computation.

In summary, there are 4 phases:
- **Calculation**: Calculating the outputs of every component leaf node.
Expand All @@ -63,7 +59,7 @@ Through the above pipeline process, we can handle multiple types of calculations

## Supporting the 4M's of Green Software

We can apply the [[4Ms]] using an Impact Graph.
We can apply the **4Ms** using an Impact Graph.

- **Mapping**: Map clearly what you want to measure, the *boundary* of the subject.
- **Measure**: Decide the models you want to use to measure the subject's impact.
Expand All @@ -72,21 +68,21 @@ We can apply the [[4Ms]] using an Impact Graph.

Creating a graph involves **mapping** a subject you want to measure, simulate and monitor. It could be a software application, a user journey, campaign. Modeling involves adding nodes to the graph, both component and grouping nodes.

**Measuring** involves selecting and configuring the correct measurement plugins for each component in the graph and collecting inputs to pass to those plugins.
**Measuring** involves selecting and configuring the correct measurement plugins for each component in the graph and collecting Inputs to pass to those plugins.

Once both steps are complete and you have a baseline, *computable*, model of your graph's impacts, you can start **simulating** the effects of making changes. You can change the model to represent a *what if* scenario (e.g. changing part of the architecture or runtime of your software), compute the new simulation graph, and see how much this affects the overall impact without making any changes to your software.

So far, graph computations are batch processes that start and end with static inputs embedded. Since the graph represents executable code that takes in some inputs to generate outputs impacts, it's possible to turn a graph calculation into a continuous process to **monitor** the impacts of your subject. Something that takes a stream of inputs in and exhausts a stream of output impacts.
So far, graph computations are batch processes that start and end with static Inputs embedded. Since the graph represents executable code that takes in some Inputs to generate outputs impacts, it's possible to turn a graph calculation into a continuous process to **monitor** the impacts of your subject. Something that takes a stream of Inputs in and exhausts a stream of output impacts.

### Evolution

One of the most valuable features of a graph is that it can grow and evolve; it can start small and grow in complexity over time.

We need to add [[Granularity]] to a graph to get the most out of this process. The more granular a graph is, the more accurate the impacts will be. The more granular a graph, the more opportunities to simulate present themselves.
We need to add [Granularity](./granularity.md) to a graph to get the most out of this process. The more granular a graph is, the more accurate the impacts will be. The more granular a graph, the more opportunities to simulate present themselves.

Most graphs might begin life as **one** component node and **one** input. This will give you a single impact.
Most graphs might begin life as **one** component node and **one** Input. This will give you a single impact.

Once you desire to see the impacts over time, you might evolve the graph by adding multiple inputs.
Once you desire to see the impacts over time, you might evolve the graph by adding multiple Inputs.

Once you want to see the impacts broken down by sub-components, you evolve the graph by adding more components.

Expand Down

0 comments on commit 6f0e473

Please sign in to comment.