How does Refinery treat import/export

[wmeyers]

@antw, is there a provision for import and export in Refinery? Does this have to be explicitly set with shares etc, or can we let Refinery determine if the import converter should have a value and export zero (in the case of net import of a carrier) or the other way around (for net export).

[StijnDellaert]

As a note, the IE currently has all imports and exports set to NULL, meaning that they are calculated from the difference between demand and domestic production. Only import of steam hot water is set to 0.

[wmeyers]

Also see quintel/rdr#89.

Question:

• How does Refinery treat these NULL values? Does it even know the difference?

[antw]

How does Refinery treat these NULL values? Does it even know the difference?

Null means "no value" to Refinery, so it'll try to figure it out for itself. I think import is normally connected with a flexible edge, so if no share is provided it'll be set to whatever is required to fulfil demand of the distribution nodes.

                                +------------+
                                |   Import   |
+--------------+  <--flexible-- +------------+
| Distribution |
+--------------+  <------------ +------------+
                                | Production |
                                +------------+

If you set one, a child share on the flexible edge would be respected.

[StijnDellaert]

How can NULL be saved in a .csv file?

[antw]

It would just be blank:

key,one,two
thing,,2

key	one	two
thing		2

[wmeyers]

Does it also know how to treat this?

      +--------------+
      |              |                                               +--------------+
      | Converter 1  +--------------+                                |              |
      |              |              |                +---------------+ Converter 3  |
      +--------------+              |                |               |              |
                                    |                |               +--------------+
                                    |                |
      +--------------+              +----------------+               +--------------+
      |              |              |                |               |              |
      | Converter 2  +--------------+   Distribution +---------------+ Converter 4  |
      |              |              |                |               |              |
      +--------------+              +----------------+               +--------------+
                                    |                |
                                    |                |
      +--------------+              |                |               +--------------+
      |              |              |                |               |              |
      |  Export      +--flexible----+                +---flexible----+ Import       |
      |              |                                               |              |
      +--------------+                                               +--------------+

[wouterterlouw]

@wmeyers It seems to work here: Note that the demand of energy_distribution_coal_gas is know and the respective parent and child shares.

[antw]

This should be no problem: See #6 and #5.

In the diagram above:

• The incoming (dotted) edge is "flexible" and treated like in ETEngine; when the node has a known demand, and all the other edges are don't fulfil that demand, the flexible edge will supply the rest.
• The outgoing (dashed) edge is an "overflow" (or inverse flexible in ETEngine terms) and will take away any excess.

Normally one of these will be zero (a node cannot have an excess of supply and an excess of demand simultaneously) unless you specify shares for the edges, such as is the case in the image posted by @wouterterlouw.

[wmeyers]

@antw, thanks a lot for explaining! That would mean that in most cases where the graph is not calculating right now (production, distribution and import/export of carriers) setting the domestic production should solve a lot.

@StijnDellaert, I think this answers the question you asked me before.

@antw, just to be sure, if we set shares like @wouterterlouw did in his example above, does this lead to trouble? I guess Refinery deals with this fine, but it might not lead to a viable graph that etengine can use.

[antw]

if we set shares like @wouterterlouw did in his example above, does this lead to trouble? I guess Refinery deals with this fine, but it might not lead to a viable graph that etengine can use.

It depends how you define "trouble". :wink:

If you set shares on flexible or overflow edges, Refinery will use those shares. I suppose it's possible that you could set shares which are inaccurate, and results in an edge getting a demand different from what you expected.

But you can't set shares which are invalid. For example, if you were to set shares such that not all of the node's demand were taken away (e.g. node has a demand of 100, but the edges take away only 90), Refinery will not only complain, but will refuse to generate output which can be used by ETEngine. This validation only kicks in after the graph (or sub-graph) has been fully calculated, so if the graph fails to calculate you won't get an error message about this, but neither will you get a useable graph.

[StijnDellaert]

Now the transport subgraph is fully working, some of the import/export/productions should also calculate. I'll describe a specific situation, the energy_distribution_kerosene.

The demand is known. the others need to be calculated.

In the IE, the others are all set to NULL, as is the distribution converter itself. Only the production has an expected demand value. What apparently happens is that the entire demand is automatically fulfilled by the production and import and export are 0.

Currently, this does not seem to work in Refinery.

Do we want to keep this behaviour @ChaelKruip and can this be implemented @antw ?

[wmeyers]

Wouldn't it work to set the parent share of the edge between distribution kerosene and production to 1.0. Refinery should then know to take all the demand of distribution kerosene from production?

@antw, what do you think?

[StijnDellaert]

I think you're right @wmeyers . We can just fix this by setting shares. Will try tomorrow.

[antw]

@antw, what do you think?

Regrettably no. distribution has an incoming flexible edge and an outgoing overflow. Even if we know that the _childshare of production→distribution is 1.0, that doesn't tell us the demand of the distribution node. For all Refinery knows, the demand node may have a demand of 200, but production outputs 250, with the remaining 50 going to export.

There are a couple of ways you can resolve this:

Supply child_share of production→distribution and parent_share of distribution→demand

Initial values	Calculated

Supply demand of production

Initial values	Calculated

[wmeyers]

Supply child_share of production→distribution and parent_share of distribution→demand

In cases where we want import and export initialized as zero, I would go for this option @StijnDellaert.

In the other cases we are already supplying the demand of production anyway, so that should work fine.

[StijnDellaert]

Yes, I will make some shares for the distribution converters

[wmeyers]

Closing, implementation happens in #36

[wouterterlouw]

Ok, if the import and export occurs in one converter it works fine, e.g.

However, if import occurs in one converter and export in another, it cannot be calculated:

                                                              +
                                                              |
                                                              |  import
                                                              |
                                                              v
                +---------------------+             +---------------------+
      demand    |  energy_distribution|             |  energy_treatment_  | supply
    <----------+|    uranium_oxide    |<-----------+|    uranium_oxide    |<----------+
                +---------------------+             +---------------------+
                          +
                          |
                          |  export
                          |
                          v

demand and supply are known in this case

[wouterterlouw]

Relevant for:

• uranium
• natural gas

[wouterterlouw]

For uranium the demand of the energy_distribution_uranium_oxide is defined from the energy balance by:

~ demand = EB(total_primary_energy_supply, nuclear)

[wmeyers]

On Skype @antw and I discussed this and @antw is going to try to implement a solution that might work for these kind of situations!

@antw, please note that there are several situations where this plays and this is the easiest one. There are instances where import and export are further apart than one converter for example. @wouterterlouw, maybe you can provide some more examples?

[wouterterlouw]

As described above it is relevant for the uranium and natural gas distribution, in addition it is also relevant for the (non-)biogenic waste:

[wouterterlouw]

Also interesting is what is going on around crude oil:

• crude oil import and export
• production of LPG, diesel, gasoline, kerosene and import and export of those carriers

[antw]

Closing; see #44 for the actionable issue.