Parameter Expansion for Testing Varying Assumptions

### Prize category

Best Plugin

### Overview

Our project will expand the parameter space of a given pipeline for different assumptions or plugins; thus, allowing users to experiment with or optimize for certain values or plugins without creating and managing multiple manifest files.

**Problem Statement:**

Currently, testing different assumptions (or plugins) in a manifest file involves executing separate versions, saving results, and manually comparing them. This process is manual, error-prone, and inefficient.

**Proposed Solution:**

Our idea is to enable users to include multiple contrasting assumptions in one manifest file, generating a consolidated output for comparison. This would eliminate the need for repetitive testing and simplify the analysis of varying assumptions.
We intend to do this by creating a “branch” plugin that copies all of the values of the current manifest's observations, but alters a specified assumption and then continues processing the new manifest with N copies of the original observations for each assumption change.

Our solution would play natively with the IF and only add some intelligence to do a specific set of copy and edit operations on the observations. Nothing else would change from a user's pipeline.

**Example Scenario:**

Imagine a user wanting to estimate grid carbon intensity for their data center's region. With this plugin, they could specify three estimation methods at once: a fixed value representing an average on the high-end estimate, a fixed value representing an average on the low-end estimate, and estimations from the WattTime plugin. Each method of estimation would produce its own result set, revealing the impact of that assumption on the final outcome.

For instance, if the high-end and low-end estimates differ by an order of magnitude or more yet yield very similar results for total emissions, one might be able to infer that this particular assumption isn’t the most critical parameter in the overall calculation. If – on the other hand – the high-end and low-end estimates only differ by a few grams of CO2 per kWh but lead to vastly different results for total emissions, one might be able to infer that the accuracy of the final result depends highly on the accuracy of this particular assumption, and therefore extra care should be taken to use the best estimate available for carbon intensity.

Additional Benefits:

By allowing users to "branch" (i.e. compute multiple different scenarios at once) within a single manifest, our plugin would enhance the IF's versatility and efficiency. Users would be able to explore diverse assumptions and assess their impact on software environmental metrics without extensive manual effort.

This is not limited to observations parameters, but could also be used to alter which plugins are used at a specific step to test different calculation methods at the same time.

### Questions to be answered

1. Aside from manual operations, is this already possible?

2. Are there other scenarios where one could see dynamic ‘branching’ be helpful?

3. How extensive has the IF been tested for scale? If we allow a user to branch multiple times, it increases the dimension of the observations by the size of the branches created and could quickly scale too big.

4. After a plugin processes the specified observations from a manifest, it writes new observations that are available to the next plugin.
- What is the extent of the manifest’s fields that are able to be read and written between plugins?
- Specifically, could you change a given child's pipeline of plugins on-the-fly? (assume that every plugin required is already initialized).

### Have you got a project team yet?

Yes and we aren't recruiting

### Project team

[atwoosnam](https://github.com/atwoosnam)
[josh-swerdlow](https://github.com/josh-swerdlow)

### Terms of Participation

- [X] I agree to the hackathon [Rules & Terms](https://github.com/Green-Software-Foundation/hack/wiki/Rules-and-Terms) and [Code of Conduct](https://github.com/Green-Software-Foundation/hack/wiki/Code-of-Conduct)