We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

A Scalable Approach for Spatio-Temporal Assessment of Photovoltaic Electricity Potentials for Building Façades of Entire Cities

00:00

Formal Metadata

Title
A Scalable Approach for Spatio-Temporal Assessment of Photovoltaic Electricity Potentials for Building Façades of Entire Cities
Title of Series
Number of Parts
295
Author
Contributors
License
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The assessment of renewable energy potentials in urban environments gained a lot of interest in the recent decades due to CO2 reduction goals by cities, national policies as well as directives by the EU. In combination with advances in data creation and processing as well as the definition of standards like CityGML, new ways of modeling urban potentials have been developed. This lead to numerous approaches estimating roof-top solar photovoltaic (PV) production. However, in recent years due to research in building materials, the façades became more attractive and feasible for PV electricity production. This paper describes results on the development of an completely FOSS-based approach to assess the electricity production potential by building façade PV. To estimate solar irradiation we followed the hemispherical viewshed approach described by Fu, 1999. Combining it with an approach to dissect walls into regular 3D point grids (1 meter spacing) we calculate the sun visibility (each hour) and the sky viewshed throughout the year. This results in direct and diffuse irradiation for every wall point. To generate the electricity potential, the irradiation values are summed up for the wall points and are fed into an economic model. This is driven by technical parameters of the installation, such as module efficiency, installation and maintenance costs, figures about payback tariffs and envisaged module lifetime. The overall result is a city-wide PV suitability and electricity production potential map of every building façade. The processing is based on a city model in the CityGML format using the 3DCityDB database and the spatial processing functionalities of PostGIS. A set of Python scripts has been developed as a central control instance. The scripts control the processing of direct and diffuse irradiation as well as clear sky irradiation relying on the external “pvlib” Python library. Furthermore, we use the scripts to manage parallel processing of queries against the database to achieve scalability and improved performance. The parallelisation is done by processing single building walls. We run a case study with approximately 7000 single wall elements to process. We identified so far one of the major bottlenecks of the approach. This are the calculations of sun visibility for every wall point per timestamp (intersection with surrounding buildings) which takes per wall several minutes to process depending on the number of points per wall. Since we implemented a parallel processing of the walls running on a 80-core dedicated server machine, the completion for an entire city of 3 million wall points uses a decent amount of time for the given size of data set. Here we describe a scalable and highly parallelised approach which can be easily implemented through standard tools and libraries. This open up now for distributed approaches using multiple database servers for even better scalability.
Keywords
129
131
137
139
Thumbnail
28:17
Real numberBraidScalabilityApproximationEntire functionBuildingPlastikkarteFood energyBuildingFocus (optics)Twin primeVector potentialImplementationComputing platformState of matterFood energyInformation securityMathematical modelInternet service providerMultiplication signScaling (geometry)Lecture/Conference
Electronic mailing listScale (map)Food energyPlastikkarteComputing platformImplementationEstimationBuildingVector potentialMathematical modelVisualization (computer graphics)Interactive televisionTexture mappingMeasurementTerm (mathematics)Point (geometry)HypercubeWeb applicationMathematical modelSoftware developerBuildingMereologyGame controllerInstance (computer science)ResultantSet (mathematics)Workstation <Musikinstrument>Vector potentialMeasurementCollaborationismEstimatorFood energyLine (geometry)Representation (politics)View (database)Slide ruleSupercomputerDot productEnergy conversion efficiencyMetreSpacetimeTotal S.A.Office suitePoint (geometry)WeightCoefficient of determinationTerm (mathematics)Cellular automatonRule of inferenceState of matterSoftware testingDifferent (Kate Ryan album)InformationRadio-frequency identificationUniverse (mathematics)WordPRINCE2XML
Source codeDuality (mathematics)Cartesian coordinate systemFluid staticsPrice indexComponent-based software engineeringDiffusionState observerThermal radiationLine (geometry)Direction (geometry)Point (geometry)Diffuser (automotive)Point cloudFood energyOpen setDiagram
Electronic mailing listDiffusionSurfaceView (database)DivisorView (database)Multiplication signThermal radiationAreaDiffuser (automotive)Position operatorDivisorGreatest elementDirected setCASE <Informatik>Computer animation
View (database)DivisorElectronic mailing listDirected setSurfaceCondition numberPoint cloudAcoustic shadowObject (grammar)BuildingMathematical modelPoint (geometry)Line (geometry)MeasurementMereologyDiffuser (automotive)SurfaceCASE <Informatik>Row (database)Uniform resource locatorElectronic mailing listCondition numberSpacetimeSphereDemo (music)CybersexComputer animation
Directed setCalculationAcoustic shadowDifferent (Kate Ryan album)Data transmissionPosition operatorNumberPoint cloudBuildingPoint (geometry)Condition numberDiffuser (automotive)Line (geometry)Quantum stateSphereMultiplication signMereologyImage resolutionLecture/Conference
HypercubeASCIIElectronic mailing listBuildingBlock (periodic table)Data conversionGamma functionLinear subspacePoint (geometry)Table (information)Parallel computingBefehlsprozessorStandard deviationData storage deviceSemantics (computer science)Mathematical modelScripting languageControl flowParameter (computer programming)Physical systemMilitary operationNichtlineares GleichungssystemStandard deviationDirection (geometry)Line (geometry)Point (geometry)ResultantCybersexBuildingSemantics (computer science)Parameter (computer programming)Scripting languageDiffuser (automotive)Server (computing)Proper mapMathematical modelView (database)Vector potentialData storage deviceDivisorTable (information)Representation (politics)Multiplication signBitMathematicsLevel (video gaming)Query languageCubeTimestampFood energySummierbarkeitPosition operatorDirected setGreen's functionOperator (mathematics)MereologyCalculationFeedbackMetrePhysical systemForm (programming)Parallel portImage resolutionInsertion lossInformationBefehlsprozessorArithmetic meanVirtual machineNeuroinformatikCentralizer and normalizerSquare numberMassGradientMappingRight angleMeasurementSphereSoftware2 (number)Maxima and minimaChemical equationDataflowGraph coloringGoogolThermal radiationState of matterUniverse (mathematics)Instance (computer science)DatabaseDiscrete element methodArrow of timeSet (mathematics)Scaling (geometry)Range (statistics)Artificial neural networkPresentation of a groupProof theoryCASE <Informatik>Expert systemParity (mathematics)Computer hardwareComputer animation
Vector potentialBuildingInternet service providerPoint (geometry)Neighbourhood (graph theory)Mathematical modelArrow of timeChemical equationState of matterCellular automatonCalculationMultiplication signFood energyDiagram
Mathematical modelCalculationRule of inferenceBitSpacetimeCubeChemical equationNichtlineares GleichungssystemUniform resource locatorAreaPoint (geometry)Open setSoftware developerModule (mathematics)NeuroinformatikWindowBasis <Mathematik>Envelope (mathematics)Integrated development environmentCore dumpQuicksortGoodness of fitRaster graphicsObservational studyEuclidean vectorXMLLecture/Conference
Transcript: English(auto-generated)
OK, then. Let's start for the second talk in this session. So I won't read out this title, because there's a kind of unofficial short one, which would be called photovoltaic electricity
potential for states on buildings using post-JS and Python. So what was the motivation to do this kind of modeling approach? So there is an implementation of a secure platform for Luxembourg, which is also financed by a foundation in Luxembourg, set up by an energy provider.
So the goal was, on an urban scale, to estimate the renewable energy potentials, like on building roofs and in facades. And on the other hand, to estimate energy savings of residential buildings.
And with the goal to rely on distributed and high performance computing approaches. So then it was, or then the overall goal was to provide tools to the stakeholders that they can assess this potential. So mainly, like I said, the PV potential on rooftops,
and energy consumptions, and the saving tools for the residential buildings. And overall, also a kind of web-based tool to make this, to visualize the data and the results. Furthermore, it's about to kind of accelerate
the penetration of solar PV, and to increase the energy efficiency. So coming to the modeling part, so which data and tools were available. So there are some very old, actually lighter data set of Luxembourg. It's not an entire country, just parts of it.
So it's like 10 years old. Of course, we have some building footprints. We have some long-term irrigation measurements from a station nearby our institute. The tools that we identified were mainly 3D fire. That's the development of the University of Delft. We've been using the 3D CDDB. That's in development of the Technical University of Munich
and in collaboration with Berlin. And this involves then also PostGIS and Python. And Python is here, the main control instance to steer all the parts and the bits and parts. So in total, we are dealing with something
like 8,000 walls or building facades in our city, which is the second largest city in Luxembourg. It's called Esch-sur-Alzette. It's about 40,000 inhabitants. And to assess the global irradiation, which then leads to photovoltaic potential,
we generated hyperpoints. And these hyperpoints is a created representation of the walls or the facades, which have a one meter spacing. So you will see this in the next slide. So basically, this is a 3D model of Esch-sur-Alzette
and the terrain included in the background. And here, it's just a zoomed in view. You have these little black dots. And each little dot will be enhanced with the global irradiation later on and to assess the PV potential.
So like I said, it's about 8,000 building facades, different facades, and about 3 million of these little dots, which we have to calculate the solar irradiation. And just for your information, so global irradiation is consisting of beam or direct irradiation plus diffuse and usually also reflected. But this is neglected here because it's very, very low
compared to the others. So the beam is more or less a direct line between the solar panel or point of observation on Earth to the sun and the diffuse then is radiation that is scattered through the clouds and then reaching the kind of panel and getting transformed into energy with the solar panel.
So let's start with the diffuse. So what is this really? I mean, if you are in this kind of, you have to imagine this kind of urban canyon where you just have access to direct sunlight or to the sky where this little narrow opening here.
So this is called a kind of sky view factor. So how many or which kind of sectors of the sky you can see and I mean, light is still coming to the bottom, but it's not dark there, obviously. But it's also not lighted by the direct radiation
of the sun. So this is then the kind of sky view factor, which is based on topography in this case and in an urban area like this urban canyon, but it's not dependent on the time. So you can have, it's not dependent on the time like some position.
So this is how we calculated this. So you have to see that, you have to imagine that this is our city model. We have taken one out of the cyber points here and from each of the cyber point, specifically this one, we calculate a kind of line of sight to an imaginary hemisphere. So this is a regularly spaced hemisphere
put over our demo location and from each hyper point, we take a line to each point on this hemisphere and then calculate the intersection with the surrounding buildings and see and check if this intersection is true or not.
And then we know, okay, this part of the sky is visible from this point and then we have irradiation measurements and we can sum them up to get a kind of diffuse irradiation then. So then the other part is the direct irradiation. This is then of course,
also dependent on the exposition and the slope of the surface. So how is this solar panel oriented to the sun for in that case, it's obviously depending on atmospheric conditions like clouds and the transmissivity of the atmosphere to have a lot of dust in the atmosphere
and cast shadows from other buildings or chimneys, antennas, whatever. So and another point here is that the sun position is varying over the course of the day and obviously over the year. So if one panel is facing to the east, you will get more sun in the morning because sun is rising there
less than in the evening and vice versa. Obviously it's the optimum if the panel is oriented to the south or the facade. So then this looks a bit different. So whereas the diffuse is the kind of easy part, we have to deal here with all the sun positions throughout the year, throughout the day,
which makes like we use an hourly resolution, which makes up 8,600 kind of calculation steps throughout the year. And we do this for every hyperpoint. So this adds up to an enormous number. And what you can see here, like also in the first picture is the kind of yellow rays or lines to the sun.
They are free, so the sun can be seen for this step in time. And the dark ones, they are obviously obstructed because they go here through the buildings and then they are intersected by a building. And this would be one sun step, which is not visible from this point.
So this gets then deleted. Okay, so don't be afraid. This is our kind of workflow. So on the end, we have one central table in Postures which stores all the information about every hyperpoint. And basically, the goal is to calculate
the portion of direct irradiation and to calculate the portion of diffuse irradiation, which each point is receiving. And if we start here on the right side, we have some irradiation measurements. Like I said in the beginning, we have a kind of sky view factor calculated with all the lines which go from a facade
to the hemisphere. And we determine for each point the sky view factor and then with the irradiation, we can calculate the diffuse irradiation. And on the other side, we calculate direct irradiation for each time stamp throughout the year. And we intersect this also with the surrounding buildings and for each line going from the facade to the sun.
And so there's in between is a city gem, city gem L generated by this tool called 3D Fire of University of Delft. And it's, since we just have this lighter data available and no proper city gem L with a higher level of detail,
we have just have this cube representation of the city model. So we don't have roofs included, for instance, or detailed roofs included, which makes it a bit kind of artificial, but it still works. So it's quite a good and easy approach. So how does this look like?
So basically this is then just a part of the city of Ash. And if you zoom in a bit, then you can see it better. So you get this nice gradients over the walls in global irradiation where the sun is then taking its part over the course of the year. So that's the sum of irradiation for the whole year.
So this also is in a good possible range, like 900 kilowatt hours per year. And this makes up this nice pictures there. And this is available like 3 million hyperpoints for the whole city of Ash.
And yes, like I said, it's about 8,000 facades, 3 million hyperpoints. All this leads to roughly 1.2 terabytes in temporary tables in the database, which can be deleted. But at some point it's there. So we run this in a parallelized fashion on 70 CPU.
So it's a dedicated server hardware, which is also quite old, it's about 10 years old. So it's quite slow actually, but it works. It's very stable. So it's just a matter of installing this whole setup on a different or a newer machine with more cores. So we also have recently an HPC available in our institute, and we will use this probably
in the near future to really scale this up. So since the underlying software is also Postgres with PostGIS, this runs really pretty stable. So and it's very scalable. The terrain is also included in the intersections like you've seen before on the city-wide view.
And all this right now takes like roughly 15 days of computation, so that's really the heavy lifting to calculate the aeration, which then leads to the PV potential maps. So some advantages, we rely on kind of
standardized storage in CDGML or 3D CDGB, so you can export from 3D CDGB to CDGML again, which makes it then a kind of standardized export form to export your results. We also keep the semantics of CDGML inside 3D CDGB,
also quite useful. And like I said before, so it's one main Python script which controls the parallelization of the whole approach, which generates and sends query to Postgres. Results are still stored in Postgres, so that's easy to do. It's parallelized, and this leads to a decent,
I mean 15 days, it sounds a lot, but it's also a massive amount of data and calculation steps you have to take. So like I said, that's the heavy lifting of the computation. Then how do we get to kind of economic PV potential? So we have all the cyber points available,
and for each of the cyber points, you can kind of set up an economic equation. Okay, so we have a kind of square meter resolution on our building facades, and we want to put panels there, and our stakeholder gives us some values, which are right now quite conservative, like the economic lifetime of this installation
on this facade would be 20 years. After that, it should be paid back and generate some income, positive income. The payback price would be 24 cents, Euro cents. We have a system loss of 15%, so this is then all, the other values are all up to the kind of panels you would choose
to place on your facade. Like a system loss of 15%, annual operation cost, panel efficiency, it's also up to the panels, of course. So this is then up to the stakeholder, what they would like to choose. And if you do this equation, you could come up with a kind of minimum global irradiation per year,
which you should have to make this hyperpoint economically possible feasible, so that your equation gets positive after 20 years. So if you put this in into the database and do the math there, which just takes a few seconds, so that's really the point there.
So the global irradiation which you do once takes 15 days, and this takes a few seconds, and there, then it's also nice that the user, the stakeholder can play with different scenarios. So this goes very fast and will also be implemented in the WPS in the future, so that really the stakeholders can use this,
this pre-potential calculations on the fly, kind of. So this leads then to a kind of representation which tells you, okay, that's the, the price of 24, in the best case, 24 cents,
the price of energy that is generated throughout the year. So this means if you have a feedback tariff of 25, 24 cents and if your generated energy is lower priced because of the economic parameters you gain
with every kilowatt hour, you feed back to the grid, you gain some money and make your balance positive. So you also see it in here, that usually all those walls are all green, turn the upper right, there's a kind of direction arrow, green means north, so you're looking from south to north
and all these facades are exposed to the south, more or less, so they receive a lot of energy and they are doing well compared to the other side. If you turn this picture around, you see the green arrow is pointing to the north again, so you look from the southeast to the northwest and then this picture is different,
so you have a lot of red walls which are actually then quite expensive to do and the stakeholder would not place any panels there. So these facades would not be taken into account for the overall balance. So the approach or the whole modeling approach is also a good point to check for the stakeholders
to look for a whole quarter which they would like to kind of refurbish or place PV panels on the facades. It's not like the single assessment of a building
because this is then up to the energy provider. So it's more like in the urban planning phase, what could be done for the whole neighborhood quarter. Also you could also calculate the theoretical potential of the whole city. It's also, I mean, data is there,
so just need to sum it up, that's fine. So that's it from my side. If you have any questions, I'm happy to answer. Yeah.
Thank you. My question is a bit of a maybe funny question. You were running for 15 days on 70 cores. How many kilowatts did you use for the computation
and will it save, how many years extra do I have to run the PV things to? I didn't calculate that, but probably it will make the balance, yes. I mean, for sure, if you do the installation of the PV modules, it will save this energy, for sure.
No, it's just in general, it's when we do all these studies for environmental improvements, impacts, mitigation, and they involve super heavy computations, I sometimes wonder if we just sort of made a bet
back on the envelope calculation using a good guess, would it overall be cheaper? I was just curious if you would know how much kilowatt were used, because I have no idea. Me neither, sorry. I was just wondering, the roofs,
how much do you think more detailed model would impact the final answer? You mean if we include the roofs as well? For the roofs, we have a different approach, because this is facades in kind of 3D vector space.
For the roofs, we developed 2D raster space, kind of. I guess what I got from the literature is that facades are making 30 to 40% of the overall equation between roof facades, so you can get a lot out of the facades as well, that's the point. I mean, what's not included there are wall openings,
like windows, doors, and all this kind of stuff, places, areas on the facade which you cannot place a panel. It's due to lack of data. I mean, if you would have precise locations of window openings, we could include them, and then kind of exclude these areas of the calculation, but it's not there, so we had to use lighter data,
just extrude them to a cube. That's the most simple approach you can do with, I mean, if you have lighter data available, it's already quite good, but in some areas, in a lot of areas, they are not available, and we had them city-wide, also quite a good situation, usually.
And yes, so, okay, thanks. Thank you.