Updated spec with model pipelines #95
Conversation
| ``` | ||
|
|
||
|
|
||
| - `pipeline` defines the models we apply and the order in which we use them. |
There was a problem hiding this comment.
do the time normalization, aggregation etc count as models in this spec, or are they defined separately? In the old spec they were defined in the pipeline field.
There was a problem hiding this comment.
I think some things are now just either baked into the framework (e.g. aggregation) and not plugin/configurable. Aggregation now only literally needs to aggregate which will be the same for every use case.
time-normalization can be done in the models field, but it does mean that a model needs to be initialised differently (time-normalization model needs to know information about the whole graph so it can figure out the time buckets, but once it knows that it can just be used as any other model)
There was a problem hiding this comment.
time-normalization can I realize be implemented as model like everything else (needs slight tweaking to the model initialization rules but it can work). Aggregation also now is just a normal standard aggregation and can just be baked into the framework.
That's a good point. I've been calling everything a model. I think it's worthwhile still calling them models but having the understanding some will be simple processors? |
| vendor: aws | ||
| instance-type: m5d.large | ||
| duration: 5 | ||
| cpu-util: 33 |
There was a problem hiding this comment.
Having hyphens in middle causes the parsers to behave differently and especially in javascript, the object access syntax we use will be void and we need to use the array syntax.
| duration: 5 | ||
| gb-s: 1005 | ||
| vendor: aws # <-- new | ||
| instance_type: m5d.large # <-- new |
There was a problem hiding this comment.
this declaration is with underscores.
The distinction between the 2 is : there is a "component" which enriches the observation(s) and passes it on to the next model in the pipeline and the second is a component which actually calculates an Impact metric. In the true sense if we want to brand impact plugin as a software component that calculates impact metrices only then do we want to call these as ModelData Enrichment components. Here I am referring to our Observation as Model Data. |
| instance_type: m5d.xlarge # <-- updated | ||
| ``` | ||
|
|
||
| `m5d.xlarge` is the same CPU but twice the size of `m5d.large`, so this plugin halves the utilization to mirror what might be on the new instance type. |
There was a problem hiding this comment.
Here the utilization is an observation. It needs to come from the software only. What we could do is by changing the instance type using this simulation the impact model can output sim-m which is the embodied emissions change.
There was a problem hiding this comment.
There is still lots we need to think through around this, eventually I think there will form a dictionary of model terms.
Extract Model
Simulation Model
Adapter Model
I don't think there is any need to figure this out now but over time I think we'll evolve a language around this but it will be determined by the types of models that will be created.
RE: The confusion regarding impacts as a term for something that doesn't match our original defn of impacts. I agree but I'm not confident we have enough information yet to decide on an alternative approach? I suspect once we create more models and IMPLs then even more nuance might appear and an alternative language might surface.
Shall we aim to review this language around the decarb event and maybe our alpha release?
There was a problem hiding this comment.
Moving this discussion to an issue since I think it's not blocking the merging of this spec. #149
|
To review @srini1978 comments offline and confirm if there are any updates/objections before merging. |
Types of changes
A description of the changes proposed in the Pull Request