Is refinery able to deal with "coupling carriers" in Industry sector

[wouterterlouw]

See also quintel/rdr#56

[dennisquintel]

The coupling carrier is a dirty hack used in etengine to make sure that the demand between two converters is scaled (i.e. the same, or a multitude of the other).

e.g.:

(A) <---- (B)

When A is 10, B should be 100.

Refinery can deal with this 'pretty easily' by making sure that its queries (to e.g. the energy balance) are scaled.

E.g. when

• A has a query of EB(coal, industry), then
• B could has a query of EB(coal, industry) * 10.

Of course, I am assuming here that the demand of the first converter is determined by a query, and not by a share or something. Is that assumption correct @wmeyers, @StijnDellaert and @wouterterlouw?

[wouterterlouw]

Of course, I am assuming here that the demand of the first converter is determined by a query, and not by a share or something. Is that assumption correct @wmeyers, @StijnDellaert and @wouterterlouw?

That is not the case. The first converter (e.g. industry_steel_blastfurnace_current_consumption) will most likely be calculated from the final demand using shares.

[dennisquintel]

That is not the case. The first converter (e.g. industry_steel_blastfurnace_current_consumption) will most likely be calculated from the final demand using shares.

@wouterterlouw: :unamused: could we possibly change that, and base it's demand directly on a number in the energy balance?

@antw: can we query the demand/flow of another converter? :smile:

[wouterterlouw]

:unamused: could we possibly change that, and base it's demand directly on a number in the energy balance?

I am afraid not. Especially because the demand in those converters are based on input from the researcher (amount of metal produced in certain country). It also depend on whether or not a specialized industry is defined.

[antw]

@antw: can we query the demand/flow of another converter?

If it's set by a Rubel query yes. The problem is that Rubel queries are unordered, so that demand may not yet be set.

... which, in hindsight, makes DEMAND, CHILD_SHARE, and PARENT_SHARE pretty useless. We could run a regex on queries, and delay those which have one of those three substrings until all the others have been done. That seems a bit hacky and wouldn't help in the situation that one node uses DEMAND(node_B), and node_B uses DEMAND(node_C).

A non-hacky solution, which would work correctly in all situations, would be to create a dependency graph of each query and it's dependencies. That's not small job though.

Is there any documentation of the modelling problem coupling carriers deal with? I understand how they work, but not why they're needed. Maybe there's another way around this...?

[wouterterlouw]

Is there any documentation of the modelling problem coupling carriers deal with?

@antw There is some documentation in Dutch available on dropbox.

In short: industry_steel_blastfurnace_current_consumption and industry_steel_blastfurnace_current_transformation actually are two parts of one physical blastfurnace. The demand of the consumption part of the blast furnace and the demand of the transformation part of the blast furnace need to be proportional. We make use of two converters because consumption and transformation are reported seperately in the energy balance.

[dennisquintel]

I am afraid not. Especially because the demand in those converters are based on input from the researcher (amount of metal produced in certain country).

@wouterterlouw can you elaborate a bit more? Or give an example? On what input is it based?

[AlexanderWirtz]

I understand @wmeyers is also going to comment. we have been discussing this issue on Skype. I suppose he has also talked to @wouterterlouw about this.

The metal industry analysis will have to change compared to how it works in InputExcel now, since we want the efficiencies to be fixed and not determined by EB. This may be just what we need to get to determine final demand in blast furnaces on an EB number and a share (% of steel produced in current technology blast furnaces for example).

[wmeyers]

I'm not exactly sure if I understand the problem. Very, very schematically:

Doesn't Refinery have enough information in to fill this schema in? I would expect there to be a big chance that all ways to calculate it don't add up to exactly the same demands, but that is the problem of the researcher. In my understanding Refinery could calculate the blast furnace consumption (3) from Final Demand Electricity (1a) and the share (2a), then based on the coupling carrier and the loss from the other one determine blast furnace transformation. It could also determine it from final demand coal gas (1b) and the share (2b).

@antw and @dennisschoenmakers I'm curious about your answer!

[dennisquintel]

then based on the coupling carrier [...]

That is exactly what Refinery cannot do, because for Refinery, this is just a 'normal' edge between two nodes.

[dennisquintel]

Let me explain a bit better how the coupling carrier works...

This is a hot fix put together in 1.5 hours after a giant project for which there was no budget left. This carrier gets calculated once, and then destroys itself, in order to make sure that ETEngine does not trip on two different paths that go from one converter to the other.

@ChaelKruip and I agree that we do not wish to replicate this in Refinery. Also: we need to get rid of this functionality and come up with a proper solution for Etengine anyhow. Besides: replicating it will not be futile and take a lot of time to complete.

[wmeyers]

Ah.... That explains a lot... And that is F!@^%G dirty!!

@wouterterlouw does it help us that we are going to use fixed efficiencies? Can we determine the demand that the blast furnace should have, or the share of coal_gas coming from the transformation part? Would that be the type of information that Refinery can use to find the solution, @dennisschoenmakers ?

[wouterterlouw]

The metal industry analysis will have to change compared to how it works in InputExcel now, since we want the efficiencies to be fixed and not determined by EB.

@AlexanderWirtz The efficiencies are in fact fixed and not determined by the EB. In the InputExcel analysis these efficiencies are assumptions that can be changed. In the new Metal subsector analysis these efficiencies will be static.

It could also determine it from final demand coal gas (1b) and the share (2b).

@wmeyers The situation in the graph is a bit more complicated compared to the picture above. Also own use of cokes production (with additional coupling carriers) is included in the coal gas streams

@ChaelKruip and I agree that we do not wish to replicate this in Refinery. Also: we need to get rid of this functionality and come up with a proper solution for Etengine anyhow. Besides: replicating it will not be futile and take a lot of time to complete.

and

Would that be the type of information that Refinery can use to find the solution, @dennisschoenmakers ?

The proposed solution is to calculate the demand for industry_steel_blastfurnace_current_consumption and industry_steel_blastfurnace_current_transformation in the Metals analysis and to use that in Refinery.

[wmeyers]

@wouterterlouw that sounds good! Does this also remove the need for the coupling_carrier altogether?

[wouterterlouw]

Does this also remove the need for the coupling_carrier altogether?

@wmeyers Well, in case of initiating the graph by Refinery, yes. However, I think the coupling_carrier remains necessary in the model to ensure correct scaling of the consumption and transformation parts.

[AlexanderWirtz]

However, I think the coupling_carrier remains necessary in the model to ensure correct scaling of the consumption and transformation parts.

@wouterterlouw yes that is true, but this is really a different point. @dennisschoenmakers and @ChaelKruip want to kill the coupling carrier and I am all for it, but it is not part of the solution to this issue. Calculating everything in the analysis and initializing the converters through queries that are ultimately based on the EB, should work. This is also what @wmeyers and I discussed on Skype today.

[ChaelKruip]

However, I think the coupling_carrier remains necessary in the model to ensure correct scaling of the consumption and transformation parts.

True that! The engine still needs it. Coupling carriers could/should be made redundant in the hopefully not too distant future with something like an Embedded Graph. But this takes some time to develop.

[wmeyers]

The proof is in the pudding: #15

[wouterterlouw]

The proof is in the pudding: #15

The approach to initialize energy_cokesoven_transformation_coal, energy_steel_blastfurnace_current_transformation_cokes and energy_steel_blastfurnace_bat_transformation_cokes works fine (#15). A solution has still to be found for energy_steel_hisarna_transformation_coal (quintel/rdr#87), but is outside the specific scope of this issue. Closing.