Build subgraph for buildings

[dennisquintel]

@wmeyers: can you (make @StijnDellaert) supply the queries in the same format as before?

[lodykuling]

@dennisschoenmakers I've allready made them. They are to be found in Dropbox --> Projects --> Restructure Research Dataset --> Queries en CSV --> CSVs --> Buildings. They are in the same format as @StijnDellaert did them, but if something should be changed, please let me know!

[wmeyers]

Assigning @antw. Please talk directly to @lodykuling if you need anything else!

[dennisquintel]

@dennisschoenmakers I've allready made them.

:smile: :+1:

[wmeyers]

@antw please inform us here when done. Also discuss issues here. It looks like PV might be a problem and probably has to be added to the (central) production list.

Also including @AlexanderWirtz in this convo.

[wmeyers]

By the way, maybe its a good idea if this gets some priority, because @lodykuling is going on holiday from Saturday. Now he can still help with determining queries etc.

[dennisquintel]

Added label priority

[antw]

Here are my results so far:

Starting values:

Partially-calculated graph:

(since it's hard to read the names of nodes and edges which could not be calculated, here's the inverse diagram which highlights those elements which did not get a demand or share). You can ignore anything involving the "super-source" or "super-sink".

The graph does not calculate completely:

• There appears to be a bug somewhere preventing some edges from being calculated. I'm looking into this.
• There is at least one case of missing shares: buildings_final_demand_for_cooling_electricity.
• There is no demand assigned to buildings_chp_engine_biogas. The "buildings_queries.csv" file defines a query for the non-existent node buildings_collective_chp_biogas; perhaps the node has the wrong name?

Some things to note:

1. There were a few cases of queries referring to non-existent columns in the energy balance, or column names not being "quoted" correctly. I have fixed these in the files I committed to ETSource, but have not made these changes on the Dropbox CSVs. I can do this if you want?
2. There were several examples of nodes being specified in the query documents (buildings_edges.csv and buildings_queries.csv) which do not exist in the graph. It may be that the names of those nodes are going to change, or it may just be a mistake. For example, the edge queries CSV referred to "buildings_final_demand_for_space_cooling_electricity", when the real node name is "buildings_final_demand_for_cooling_electricity". Likewise, it specifies a "buildings_cooling_airconditioning", when the node is currently called "buildings_cooling_airconditioning_electricity".

I'll update this issue again once I've tracked down the Edge bug.

[wmeyers]

Keeping @AlexanderWirtz in the loop.

@Richard-Deuchler, please watch this thread to learn about Households! :+1:

[antw]

I'll update this issue again once I've tracked down the Edge bug.

The uncalculated edges are "flexible" and meant to supply excess demand from the left converter. I've altered the behaviour of those edges so that they can also be calculated right-to-left; this fixes the problem and leaves us with the following nodes and edges whose demands/shares cannot be determined:

[ChaelKruip]

perhaps the node has the wrong name?

Yes, the relevant CHP is called buildings_chp_engine_biogas as @antw was hinting at.

[antw]

Yes, the relevant CHP is called buildings_chp_engine_biogas as @antw was hinting at.

Great! However there is no data for that node in the CHP CSV file. Once there is, all the uncalculated nodes in the top-right of the diagram will work.

That will leave us with the issues on the left of the diagram to fix. To solve those we'll need:

• Shares for the out edges from buildings_final_demand_for_cooling_electricity.
• Some way to figure out the demands of the "savings" nodes. This could be done either by specifying a demand for each one, or by setting a child_share on the edges from which Refinery should be able to figure out the correct demand.

[lodykuling]

I propose to fix the problem for buildings_final_demand_for_cooling_electricity by setting the share for buildings_cooling_collective_cooling_network_electricity to zero, as this converter is only used in the model for amsterdam (according to @wmeyers ) which is not supported/shown by the ETM anymore. For now I will include this in the query list, in the longer run I think this converter can be deleted.

Concerning the "savings" nodes: @ChaelKruip and I are currently re-modeling the insulation part of the graph. Most likely only insulation will remain and recirculation and ventilation will be removed. So the savings nodes for space heating and space cooling should be set on hold.

However for the "savings" nodes in lighting a solution has to be found.

[AlexanderWirtz]

Great! However there is no data for that node in the CHP CSV file. Once there is, all the uncalculated nodes in the top-right of the diagram will work.

Doe anyone know why this data is not here? I do see it in the CHP analysis v 2.09 (No idea why the buildings rows have red font):

Has this bit been resolved @antw ?

[antw]

Has this bit been resolved @antw ?

Yeah; I didn't know the central producers CSV file existed yet. I'll need to rename the biogas row per @ChaelKruip's instructions, but the CHP demand issue should be resolved.

[antw]

The buildings analysis has a file, "pv_caps.csv", which contains demands for

• electricity_production_pv_caps
• roof_surface_available_pv_buildings

	production
electricity_production_pv_caps	122.4
roof_surface_available_pv_buildings	133

Previously I had merged this with the central producers CSV. Since adding the real central production file from Dropbox, this no longer seems like the correct solution.

Any ideas for where I should put this data?

[dennisquintel]

I am a bit confused by the name roof_surface_available_pv_buildings. What does this entail? Is this a maximum for buildings? Or a converter? What is the unit for this value? @lodykuling, @wmeyers or @AlexanderWirtz, please chip in.

[antw]

If it's any help, electricity_production_pv_caps is used to set demand on the "buildings_solar_pv_solar_radiation" node. roof_surface_available_pv_buildings appears not to be used.

[AlexanderWirtz]

I also have no idea what the roof surface available is for

[dennisquintel]

I also have no idea what the roof surface available is for.

Then who has? Who created this? Can somebody please explain? Then we can continue with this subsector.

[wmeyers]

It's for area data. Ignore it for now!

[AlexanderWirtz]

Weird that it has found its way there. Also the naming is really not acceptable. the word caps should be avoided, as it gets misinterpreted as a slider cap.

@ChaelKruip what is the status of your naming convention? Can we finish that and then implement it on all the queries and converter demands?

[AlexanderWirtz]

@dennisschoenmakers as far as I understand it was mistakenly added to this csv file and can be removed. The electricity_production_pv_caps is the actual production that @antw needs

[ChaelKruip]

what is the status of your naming convention? Can we finish that and then implement it on all the queries and converter demands?

I think we can proceed. See this issue for info.

[StijnDellaert]

I redid the csv's for this sector following the naming conventions. However, I may have missed small spelling mistakes that were present. The CHP and PV solar demands are now all in the latest CE production table, so the 'pv_caps.csv' has become redundant. Can the sector graph now be calculated completely @antw ?

[Richard-Deuchler]

I added 8 child_shares to the analysis and the dropbox directory, which take care of ...savings_converters. The converters are to the very left of the subgraph and previously undefined to my knowledge. New CSV files, also defined in the updated edges.csv:

buildings_useful_demand_for_space_heating_child_share buildings_useful_demand_for_space_heating_after_insulation_child_share buildings_useful_demand_for_space_heating_after_insulation_recirculation_child_share buildings_useful_demand_cooling_child_share buildings_useful_demand_after_insulation_cooling_child_share buildings_useful_demand_after_insulation_recirculation_cooling_child_share buildings_useful_demand_light_child_share buildings_useful_demand_after_motion_detection_light_child_share

[antw]

• Initial values
• Calculable
• Incalculable

Looking pretty good! Refinery is having some trouble with two useful demand nodes on the far left. Each node has two incoming edges, with a child share specified on one of them.

If a child share for both incoming edges is added, Refinery has no problem and calculates the nodes and edges correctly:

The share data is in the CSV file, there's just no query to set it. I realise this seems a bit ridiculous – if one edge is 0.0, then the other must be 1.0 – but Refinery's primary currency is demand, and in the absence of a known demand, it struggles. Like with slot conversions, I think it's reasonable to require that all the shares be set and not just some of them.

[antw]

I forgot to mention, there were only two minor issues with the research data:

• buildings_final_demand_for_cooling_electricity_parent_share.csv: The final row ("buildings_cooling_collective_cooling_network_electricity") contains no share value. It needs to be 0.0 otherwise the CSV parser chokes.
• The buildings_chp_engine_biogas node is misnamed in the central producers table as buildings_collective_chp_biogas. This was mentioned briefly in an earlier comment, but a permanent fix is needed; either the node name needs to be changed, or the central producers table needs to be updated with the correct name. @ChaelKruip do you know which of these two names is the one we want to keep?

[ChaelKruip]

@ChaelKruip do you know which of these two names is the one we want to keep?

buildings_chp_engine_biogas

[Richard-Deuchler]

I updated the edges file and added the missing 0.0 to the parent_share in question.

[wmeyers]

I have a completely filled in buildings sector in Atlas! Closing this issue