architecture-building-systems / cityenergyanalyst Goto Github PK

This function relates the thermal mass of the building. It can be calculated in a detailed way according to ISO standards. it will need also archetypes to facilitate this. It would be good to use if understanding the sensitivity of thermal mass is needed.

The existing radiation engine is dependent on arcgis. It would be great to have a more powerful and stand alone engine.

What norm is this based on? What are the exact criteria used to calculate this field?

Generic controls of the current tool might lead to overestimations and inaccuracy in the dynamic profiles of energy consumption. a lighting control strategy would be especially interesting in order to analyse the efficiency of the last at the urban scale.

The use of Equipment has become obsolete for other cases without industrial use. It will be taken away shortly to simplify the problem.

Check Variable in Demand.py and create archetypes out of it.

For example, it could be limited by resource availability and accessibility.

The "urben" repository has a glossary that applies to this repository as well. Use it as a starting point for the VARIABLES.md file.

Should be stated clear at the output

• Water0: Mw peak
• Occupants: Peak occupancy, hour with 100% occupancy.

the function calc_Y returns a list of transmittance values for pipes depending on the year of retrofit...

• why is the result called Y? this only makes sense if the standards equations use this naming.
• we should rename the function to calculate_pipe_transmittance_values
• we should consider moving this to the archetypes instead
• the result should probably be a named tuple (unless the standards use indexes, but even then...)

Come up with a solution to the size of the radiation input file - it is currently quite big. Could we zip it?

The order of columns in the properties script should be changed. It is currently messy.

Also, check output columns of the other scripts for similar problems.

• self.hoursop = 5 Pump running hours assuming around 2000 hour of operation per year. Charged to the electrical system from 11 am to 4 pm. Get a better value-not priority!
• Self.equivalentlength = 0.6 Used to calculate the friction losses in the pipes. So you assume the network is longer so that you don’t need to calculate the temp losses at the fixtures. Should be 1.3!

We should probably update the archetypes to include these variables. Today they are part of the user's input, and window-to-wall-ratio is considered fixed

Usually, the weather data is about the airport or the nearest the weather station. But, for a specific site, because of the urban heat island effect, etc., the weather date should be different from the airport or weather stations.

There should be a procedure to generate such weather data for the specific site. Umi by MIT has such weather generator.

"analytical" only makes sense when comparing this to some other demand calculation method - we could call the function demand_calculation, calculate_demand or whatever. analytical doesn't even mean anything to do with demand calculation outside of context...

It concerns the standardization part of the tool.

Dependent variables in the simulation that should be parametric for scenarios evolving over time/trajectories: (1) weather, (2) electricity supply mix, (3) prices of energy, (4) occupancy of buildings & schedules of occupants, (5) electricity demand

Adding missing parameters and units to the documentation (QCf, QHf, Qcsf0, Qhsf0, Qwwf0)

The function CalcIncidentRadiation is slow. Run it through a profiler and propose ways to speed up the calculation.

Each building has one supply system for both DHW and SH currently.

• Change name of dataframe q
• q1.E4 will probably have to be changed - it is an equipment type in industrial processes!

The /cea/db/Archtetypes folder contains statistical data broken up by building usage. The current version is specific to Switzerland (maybe even ZH/Switzerland). We should move them to a subfolder (/cea/db/Archetypes/zh-ch/) to reflect this.

Also, check if the same applies to Schedules. In that case, move the Archetypes to: (/cea/db/zh-ch/Archetypes) and the Schedules to (/cea/db/zh-ch/Schedules)

This will let us also ship the Singapore version of the archetypes / schedules.

This concerns an outdoor dependent model for simualting air infiltration in buildings due to occupancy and building tightness. Until now this is generalized independently of the type of occupancy or building with the next variables in GlovalVariables.py

• self.NACH_inf_non_occ = 0.2 num air exchanges due to infiltration when no occupied. SIA
• self.NACH_inf_occ = 0.5 num air exchanges due to infiltration when occupied. SIA

also, the infiltration rate should be adjust accordingly

The output column Ef of the demand script is currently defined as Ealf + Eauxf, but according to JF it should also include electricity demand from processes...

During the developer walk-through, we came upon these variables and we don't quite know if they are still being used. Check. And then update documentation in demand.md.

this will influence documentation of calc_form and calc_Y

I know this is supposed to mean "energy generation", just... it always reminds me of generation as in grandfather - father - son. Especially when we have evolutionary algorithms in the project: They have generations too... Can we call it systems.shp? Other ideas?

Return ta_hs_set,ta_cs_set,people,ve,q_int,Eal_nove,Eal_ve/2,mww,mw, w_int, hour
Eal_ve should not be half here but should be changed in the occupancy schedule

Eauxf is the final auxillary electricity in [kWh] for fans and pumps. Split it into a fans portion and a pumps portion.

Create a reader of .epw data files which are easier to find in literature for building simulation than those from meteonorm

Use the ISO standards (FIXME: which ones?) as the basis for naming the schedules. Check each column name to see if it is the correct name.

These column names must be updated in the documentation (demand.md and possibly the appendix)

Possible agent based modeling of energy demand

there is only one year of retrofit as Input variable, but this not resembles reality. there could be one retrofit year for windows, another one for floors etc.. This will also cancel out the flags of Embodied.py

Assign different level/year of retrofit when calculating embodied energy: Create individual columns for "year retrofit windows", "year retrofit walls", "year retrofit partitions", etc. in the building "properties.xls" file

Changes involve creating new columns in the buildings.shp resembling every year of retrofit, and in the The calc_category function in functions.py

Fixing the start of the heating schedule in order to avoid high peak loads, so start an hour before the people arrive. It consist in a control strategy

I think that would be so much cleaner: You tell the script what it should call the file (properties.xls) that it writes instead of where to write it. This reduces implicit knowledge in the interface.

Quoting the Zen of Python:

Explicit is better than implicit.

Extract the PropertiesTool class from the properties.py script (and the same for the other scripts) to a separate file (properties_tool.py?)

A quite diverse notation of variable names was found in 30% of the data. It still works like this, but it would be great to have a standad notation

It is the same variable defined in Global Variables. it has to be checked

Go through the codebase and change any DataFrame.to_excel(... cols={...}) to DataFrame.to_excel(... cols=[...])

The generate_*_flag parameters should turn overwriting of the various worksheets in the output (properties.xls) on and off.

• How is this behavior defined?
• What is generated if no such file exists and no flags are set? An empty excel sheet?
• Are the sheets overwritten?