9.3.7. Agents

In MUSE, an agent-based formulation was originally introduced for the residential and commercial building sectors (Sachs et al. (2019)). Agents are defined using a CSV file, with one agent per row, using a format meant specifically for retrofit and new-capacity agent pairs. This CSV file can be read using read_csv_agent_parameters(). The data is also interpreted to some degree in the factory functions create_retrofit_agent() and create_newcapa_agent().

For instance, we have the following CSV table:

Name	Type	AgentShare	RegionName	Objective1	SearchRule	DecisionMethod	…
A1	New	Agent5	ASEAN	EAC	all	epsilonCon	…
A4	New	Agent6	ASEAN	CapitalCosts	existing	weightedSum	…
A1	Retrofit	Agent1	ASEAN	efficiency	all	epsilonCon	…
A2	Retrofit	Agent2	ASEAN	Emissions	similar	weightedSum	…

For simplicity, not all columns are included in the example above. Though all column listed below are currently required.

The columns have the following meaning:

Name

Name shared by a retrofit and new-capacity agent pair.

Type

One of “New” or “Retrofit”. “New” and “Retrofit” agents make up a pair with a given name. The demand is split into two, with one part coming from decommissioned assets, and the other coming from everything else. “Retrofit” agents invest only to make up for decommissioned assets. They are often limited in the technologies they can consider (by SearchRule). “New” agents invest on the rest of the demand, and can often consider more general sets of technologies. If only “New” agents are included, they will also invest to make up for decommissioned assets, but the end mix might be different than using a specialised “Retrofit” agent for that.

AgentShare

Name of the share of the existing capacity assigned to this agent. Only meaningful for retrofit agents. The actual share itself can be found in Techno-data.

RegionName

Region where an agent operates.

Objective1

First objective that an agent will try and maximize or minimize during investment. This objective should be one registered with @register_objective. The following objectives are available with MUSE:

• comfort: Comfort provided by a given technology. Comfort does not change during the simulation. It is obtained straightforwardly from Techno-data.

• efficiency: Efficiency of the technologies. Efficiency does not change during the simulation. It is obtained straightforwardly from Techno-data.

• fixed_costs: The fixed maintenance costs incurred by a technology. The costs are a function of the capacity required to fulfil the current demand.

• capital_costs: The capital cost incurred by a technology. The capital cost does not change during the simulation. It is obtained as a function of parameters found in Techno-data.

• emission_cost: The costs associated for emissions for a technology. The costs is a function both of the amount produced (equated to the total demand in this case) and of the prices associated with each pollutant. Aliased to “emission” for simplicity.

• fuel_consumption_cost: Costs of the fuels for each technology, where each technology is used to fulfil the whole demand.

• lifetime_levelized_cost_of_energy: LCOE over the lifetime of a technology. Aliased to “LCOE” for simplicity.

• net_present_value: Present value of all the costs of installing and operating a technology, minus its revenues, of the course of its lifetime. Aliased to “NPV” for simplicity.

• equivalent_annual_cost: Annualized form of the net present value. Aliased to “EAC” for simplicity.

The weight associated with this objective can be changed using ObjData1. Whether the objective should be minimized or maximized depends on Objsort1. Multiple objectives are combined using the DecisionMethod

Objective2

Second objective. See Objective1.

Objective3:

Third objective. See Objective1.

ObjData1

A weight associated with the first objective. Whether it is used will depend in large part on the decision method.

ObjData2

A weight associated with the second objective. See ObjData1.

ObjData3

A weight associated with the third objective. See ObjData1.

Objsort1

Sets whether first objective is maximized or minimized. For both “adhoc” and “scipy” solvers this should be set to “True” for minimization and “False” for maximisation.

Objsort2

Sets whether second objective is maximized or minimized. For both “adhoc” and “scipy” solvers this should be set to “True” for minimization and “False” for maximisation.

Objsort3

Sets whether third objective is maximized or minimized. For both “adhoc” and “scipy” solvers this should be set to “True” for minimization and “False” for maximisation.

SearchRule

The search rule allows users to par down the search space of technologies to those an agent is likely to consider. The search rule is any function with a given signature, and registered with MUSE via @register_filter. The following search rules, defined in filters, are available with MUSE:

• same_enduse: Only allow technologies that provide the same enduse as the current set of technologies owned by the agent.

• identity: Allows all current technologies. E.g. disables filtering. Aliased to “all”.

• similar_technology: Only allows technologies that have the same type as current crop of technologies in the agent, as determined by “tech_type” in Techno-data. Aliased to “similar”.

• same_fuels: Only allows technologies that consume the same fuels as the current crop of technologies in the agent. Aliased to “fueltype”.

• currently_existing_tech: Only allows technologies that the agent already owns. Aliased to “existing”.

• currently_referenced_tech: Only allows technologies that are currently present in the market with non-zero capacity.

• maturity: Only allows technologies that have achieved a given market share.

• spend_limit: Only allows technologies with a unit capital cost (cap_par in

  Techno-data) lower than the spend limit.

The implementation allows for combining these filters.

DecisionMethod

Decision methods reduce multiple objectives into a single scalar objective per replacement technology. They allow combining several objectives into a single metric through which replacement technologies can be ranked.

Decision methods are any function which follow a given signature and are registered via the decorator @register_decision. The following decision methods are available with MUSE, as implemented in decisions:

• mean: Computes the average across several objectives.

• weighted_sum: Computes a weighted average across several objectives.

• lexical_comparion: Compares objectives using a binned lexical comparison operator. Aliased to “lexo”. This is a lexicographic method where objectives are compared in a specific order, for example first costs, then environmental emissions.

• retro_lexical_comparion: A binned lexical comparison function where the bin size is adjusted to ensure the current crop of technologies are competitive. Aliased to “retro_lexo”.

• epsilon_constraints: A comparison method which ensures that first selects technologies following constraints on objectives 2 and higher, before actually ranking them using objective 1. Aliased to “epsilon” and “epsilon_con”.

• retro_epsilon_constraints: A variation on epsilon constraints which ensures that the current crop of technologies are not deselected by the constraints. Aliased to “retro_epsilon”.

• single_objective: A decision method to allow ranking via a single objective.

The functions allow for any number of objectives. However, the format described here allows only for three.

Quantity

A factor used to determine the demand share of “New” agents.

MaturityThreshold

Parameter for the search rule maturity.

SpendLimit

Parameter for the search rule spend_limit.