EnergySystemsModellingLab
Error when calculating commodity prices for technologies with multiple outputs
MUSE uses levelized cost to calculate commodity prices. For a technology that produces a single output commodity this makes sense, as this is the price that needs to be charged so that the technology can break even. E.g. If a refinery produces 200 units of gasoline in a year at a total running cost (fuel costs + environmental costs + fixed/variable costs + annualized capital costs) of $1000, they would need to charge $5 ($1000/200) per unit of gasoline to break even.
However, it's less clear what to do for technologies that produce multiple outputs. Let's say the refinery also produces 100 units of diesel (on top of the 200 units of gasoline). Currently, MUSE will ignore this when calculating commodity prices and will still calculate $5 for the price of gasoline (and $10 for diesel). But in reality I think you'd expect lower prices as it doesn't need to charge so much to break even.
In fact, it's not really clear to me what the price of gasoline and diesel should be in these circumstances, as there are many combinations that would work. You could charge $3.30 for both, but equally you could charge $2 for gasoline and $6 for diesel, and in both cases the technology would break even.
I guess a solution might be calculate production costs for each commodity in turn, subtracting any potential revenues from side products at their current price, and then if you run this for each commodity over multiple iterations you should get some kind of convergence. (Or possibly you'd get some horrible instability, or negative commodity prices, not sure...)
@ahawkes, any thoughts about this?
@ahawkes @martinstringer @sharwaridixit @Jin-Jun-Mei @dalonsoa Any thoughts on how to fix this problem for technologies that have multiple outputs?
@tsmbland
Hi Tom, thanks for bring up this question. I think it's interesting to discuss.
In the example you described - a refinery (in its whole lifetime) produces 200 units of gasoline plus 100 units of diesel with a total cost of $1000, if the total cost of producing one unit of gasoline and one unit of diesel is the same, then I think it is simply $1000 / (100+200).
If the cost of producing the two fuels are different, then I am thinking one can calculate the total levelized cost by calculating the levelized cost of producing gasoline and diesel separately, and then add these two together, and using 200 (production units) and 100 as their weights when combining the two parts.
You mentioned "You could charge $3.30 for both, but equally you could charge $2 for gasoline and $6 for diesel, and in both cases the technology would break even.". Yes, this is true, but levelized cost does not care about what price you charge, it only cares about the costs. (This is a limitation of using levelized cost as the evaluation metric.)
This is what I think, but I'm not sure if it's correct (except for the point about the limitation of using levelized cost as a metric). I would like to hear others' thoughts.
/Jinxi
In the example above, the refinery seems to always produce a fixed ratio of its two output commodities.
A real multi-output process may have a fixed ratio of maximum output but can probably produce any amount of either up to this limit.
For example, the maximum water-heating output and maximum space-heating output of a gas boiler system are both well defined, but at any given time it could be using all its input fuel for one, or all for the other, or anything in between.
It would be such a huge restructuring of MUSE to be able to represent this situation as a single process (because of the design with the comm_in and comm_out files), that we should probably focus instead on thinking of a smart way to handle the cap_ex if it is represented as two separate processes.
To have any chance of this, it seems to me that MUSE would need one subsector to "know" the capacity of its twin in the other subsector so that they can be matched. I suppose effectively we need to solve the two subsectors together, or iterate as Tom suggests.
If that is not feasible/reasonable, it seems we are stuck with solving this via the input files by lumping together the N space-heating processes and M water-heating processes into an NxM list of combined processes. This is pretty unsatisfactory as NxM may be a large number slowing down the model, and would make the pre and post-processing even more fiddly and time-consuming.
If we do have to accept this fall-back solution for MUSE 1, we should at least anticipate and avoid being left with it again in MUSE 2!
