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

Change the model plugin signature to distinguish observations from node-level configuration #355

Closed
3 tasks
jawache opened this issue Dec 22, 2023 · 1 comment
Milestone

Comments

@jawache
Copy link
Contributor

jawache commented Dec 22, 2023

Priority

High since the proposed solution would mean changing the model function signature and that has to be done before the hackathon.

Current Behavior

  • Currently in the impact framework we have several places for configuration.
  • At the top of the file as we initialize models we have a place for configuration.
.
.
initialize:
  models:
    - name: <model-name-1>
      kind: 
      path: <path-to-ts-module-to-load>
      config:
           <key>: <value>
    - name: <model-name-2>
      path: <path-to-ts-module-to-load>
      config:
           <key>: <value>          
.
.
graph: ~
  • This configuration is passed directly to the configure function for a model.
  • The intention is this is where we place global configuration, config that remains the same regardless of which component or context the model is going to be used in.
  • The second place we have configuration is at the component/grouping node level, this is where we have configuration that is intended to be just for that particular component or all the child components under that node in the tree.
graph:
  children:
    backend:
      pipeline: 
        - model-1
      config: 
        model-1:
          physical-processor: Intel Xeon Platinum 8175
          thermal-design-power: 200
      inputs: 
        - timestamp: 2023-07-06T00:00
          duration: 5
          cpu: 33
  • The third place we have what can be thought of as configuration is in the component itself as observations parameters.
  • Currently we treat the node level configuration as if it was just parameters passed in alongside the observation
  • We need to start treating the node level configuration differently and this means changing the model function signature.

Issues/Problems

  • This was fine in the past since each model used to return only any new/updated parameters so IF would simply append these to the input observations and pass to the next model.
  • Since we implemented the importer functionality and now models are responsible for returning all parameters to pass to the next model we have introduced a problem.
  • Models are passed in config as observations and can't tell if an input was part of the node config or a true input observation.
  • So the only things models can do is to return all the config and input observations as output observations.
  • This ends up polluting the output observations and makes it hard to read and navigate the output parameters.

Example

In the existing world a model which outputs carbon with lots of configuration like below

graph:
  children:
    child:
      pipeline:
        - model
      config:
        model:
          grid-carbon-intensity: 951
          total-embodied-emissions: 1533.12
          time-reserved: 300
          expected-lifespan: 94348800 # 3 yrs in seconds
          resources-reserved: 1
          total-resources: 64        
      inputs:
          - timestamp: '2023-11-02T10:35:31.820Z'
            duration: 3600
            cpu-util: 12

Would output something like this

graph:
  children:
    child:
      pipeline:
        - model
      config:
        model:
          grid-carbon-intensity: 951
          total-embodied-emissions: 1533.12
          time-reserved: 300
          expected-lifespan: 94348800 # 3 yrs in seconds
          resources-reserved: 1
          total-resources: 64        
      inputs:
          - timestamp: '2023-11-02T10:35:31.820Z'
            duration: 3600
            cpu-util: 12
      outputs:    
          - timestamp: '2023-11-02T10:35:31.820Z'
            duration: 3600
            cpu-util: 12    
            grid-carbon-intensity: 951
            total-embodied-emissions: 1533.12
            time-reserved: 300
            expected-lifespan: 94348800 # 3 yrs in seconds
            resources-reserved: 1
            total-resources: 64 
            carbon: 45          

The model only calculated the carbon param but has no choice but to output all the parameters it was passed in as inputs.

NOTE: If you have a series of observations, we are copying static config data into each observation in the series which really bulks up the output yaml even more.

Solution

  • We change the model function spec to introduce node level config as a param to the execute function.
  • Models will then know the config for that execution separate from the observations.
  • They can use that config to decide how to execute.
  • But they can then return just the observations, and not the config.

Change the model plugin execute function from this

public execute(inputs: Array<ModelParams>): Arrray<ModelParams>

to this

public execute(inputs: Array<ModelParams>, config: ModelParams): Arrray<ModelParams>

And in the impact framework when calling execute pass in the node level config in the config param and the inputs in the inputs param

Example

Using the same example as above, with this new approach it would just be able to output carbon, the only parameter is is calculating, and leave the config where it is.

graph:
  children:
    child:
      pipeline:
        - model
      config:
        model:
          grid-carbon-intensity: 951
          total-embodied-emissions: 1533.12
          time-reserved: 300
          expected-lifespan: 94348800 # 3 yrs in seconds
          resources-reserved: 1
          total-resources: 64        
      inputs:
          - timestamp: '2023-11-02T10:35:31.820Z'
            duration: 3600
            cpu-util: 12
      outputs:    
          - timestamp: '2023-11-02T10:35:31.820Z'
            duration: 3600
            cpu-util: 12    
            carbon: 45          

SoW

@jmcook1186
Copy link
Contributor

Dealt with as part of refactor

@github-project-automation github-project-automation bot moved this from Backlog to Done in IF Feb 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

2 participants