search

architecture-building-systems / CityEnergyAnalyst

The City Energy Analyst (CEA)
https://www.cityenergyanalyst.com/
MIT License
194 stars 61 forks source link

reference-case-open is not updated #2594

Closed daren-thomas closed 4 years ago

daren-thomas commented 4 years ago

I'm trying to run the workflow (to be able to test all the new plots!) and ran into this problem:

C:\Users\darthoma\Documents\GitHub\CityEnergyAnalyst (2541-documentation-refactoring -> origin)
λ cea radiation
City Energy Analyst version 2.31.0
Running `cea radiation` with the following parameters:
- general:scenario = C:\Users\darthoma\Documents\CityEnergyAnalyst\projects\reference-case-open\baseline
  (default: {general:project}\{general:scenario-name})
- general:multiprocessing = False
  (default: True)
- general:number-of-cpus-to-keep-free = 1
  (default: 1)
- general:debug = False
  (default: False)
[...]
verifying geometry files
C:\Users\darthoma\Documents\CityEnergyAnalyst\projects\reference-case-open\baseline\inputs\building-geometry\zone.shp INFO:numexpr.utils:NumExpr defaulting to 8 threads.
getting geometry materials
creating 3D geometry and surfaces
Reading terrain geometry
Creating 3D building surfaces
Traceback (most recent call last):
  File "C:\Users\darthoma\Documents\CityEnergyAnalyst\Dependencies\Python\Scripts\cea-script.py", line 11, in <module>

    load_entry_point('cityenergyanalyst', 'console_scripts', 'cea')()
  File "c:\users\darthoma\documents\github\cityenergyanalyst\cea\interfaces\cli\cli.py", line 66, in main
    script_module.main(config)
  File "c:\users\darthoma\documents\github\cityenergyanalyst\cea\resources\radiation_daysim\radiation_main.py", line 464, in main
    config)
  File "c:\users\darthoma\documents\github\cityenergyanalyst\cea\resources\radiation_daysim\geometry_generator.py", line 510, in geometry_main
    height_col='height_ag', nfloor_col="floors_ag")
  File "c:\users\darthoma\documents\github\cityenergyanalyst\cea\resources\radiation_daysim\geometry_generator.py", line 240, in building_2d_to_3d
    data_preprocessed = BuildingData(locator, settings, geometry_terrain, height_col, nfloor_col)
  File "c:\users\darthoma\documents\github\cityenergyanalyst\cea\resources\radiation_daysim\geometry_generator.py", line 145, in __init__
    self.zone_building_solid_list = np.vectorize(self.calc_zone_building_solids)(self.zone_building_names)
  File "C:\Users\darthoma\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\numpy\lib\function_base.py", line 1972, in __call__
    return self._vectorize_call(func=func, args=vargs)
  File "C:\Users\darthoma\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\numpy\lib\function_base.py", line 2042, in _vectorize_call
    ufunc, otypes = self._get_ufunc_and_otypes(func=func, args=args)
  File "C:\Users\darthoma\Documents\CityEnergyAnalyst\Dependencies\Python\lib\site-packages\numpy\lib\function_base.py", line 2002, in _get_ufunc_and_otypes
    outputs = func(*inputs)
  File "c:\users\darthoma\documents\github\cityenergyanalyst\cea\resources\radiation_daysim\geometry_generator.py", line 183, in calc_zone_building_solids
    face_footprint = burn_buildings(geometry, self.terrain_intersection_curves)
  File "c:\users\darthoma\documents\github\cityenergyanalyst\cea\resources\radiation_daysim\geometry_generator.py", line 380, in burn_buildings
    raise ValueError('ERROR: this usually happens when buildings do not overlap with the terrain, try to check if this is the case')
ValueError: ERROR: this usually happens when buildings do not overlap with the terrain, try to check if this is the case
jimenofonseca commented 4 years ago

can you map zone.shp and terrain.tif in QGIS?

reyery commented 4 years ago

Are there supposed to be any differences between the building geometries of 2.90.0 and 2.31.0? I get the same error with the latest reference-case-open on my computer. By replacing input geometries with geometries from 2.29.0 reference-case-open the script runs. Terrain file does not seem to be the cause as both version of files have the same hashes.

reyery commented 4 years ago

Ok... I just tested and confirmed my fear and suspicion.

There might be something wrong with how input-editor is saving geometry files. (assuming there were no changes with geometry properties between versions, since I did not see any after briefly scanning through them)

My guess was that the properties of the geometries might not have changed but 2.31.0 reference-case-open geometry files might have been somehow "saved" by input-editor.

How to reproduce: 1) Replace 2.31.0 reference-case-open geometry files (i.e. zone and surroundings) with those in 2.29.0 2) Try running solar-radiation it should pass the Creating 3D building surfaces portion. 3) Go to input-editor and change one value of zone e.g. floors_bg, save, then change back to original value and save again 4) Try running solar-radiation and now it should fail showing the error as above.

I have not investigate it yet so I am not sure what is being changed/different from the original files. It might just happen only on my machine but I doubt so. Furthermore, I am also not sure how it will affect results of radiation. (i.e. if the user changes properties of zone using input-editor and runs radiation but somehow is not affected by this error)

reyery commented 4 years ago

ok. There seems to be differences in the .prj files in both zone and surrounding where the project system is "WGS_1984_UTM_Zone_32S" instead of "WGS_1984_UTM_Zone_32N" and ["false_northing",10000000] instead of ["false_northing",0]

2.31.0
PROJCS["WGS_1984_UTM_Zone_32S",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",10000000],UNIT["Meter",1]]

2.29.0
PROJCS["WGS_1984_UTM_Zone_32N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

similarly, There are differences between the coordinates of the bounding boxes of each geometry, their y coordinates are different. But the difference in "false_northing" i.e. 10000000 seems to be equal to the difference between both y coordinates. So I guess they are actually referring to the same location.

2.31.0
[463110.6988839674, 15225351.444618214, 463136.1851344639, 15225376.930633564]
[463235.6402998573, 15225348.954802573, 463261.1265454693, 15225374.440813035]
[463360.5817018389, 15225346.464997474, 463386.06794257654, 15225371.951003049]
[463108.20905922476, 15225226.50435994, 463133.6953090251, 15225251.990374586]
[463233.1504855808, 15225224.014558226, 463258.63673050597, 15225249.500567988]
[463358.09189802676, 15225221.524767004, 463383.5781380866, 15225247.01077189]
[463105.7192484406, 15225101.564091276, 463131.20549753483, 15225127.05010521]
[463230.6606852149, 15225099.074303491, 463256.1469294432, 15225124.560312547]
[463355.6021080773, 15225096.58452614, 463381.08834744943, 15225122.070530333]

2.29.0
[463110.6988839674, 5225351.444618215, 463136.1851344639, 5225376.930633564]
[463235.6402998573, 5225348.954802573, 463261.1265454693, 5225374.440813034]
[463360.5817018389, 5225346.464997475, 463386.06794257654, 5225371.951003049]
[463108.20905922476, 5225226.504359941, 463133.6953090251, 5225251.990374586]
[463233.1504855808, 5225224.014558228, 463258.63673050597, 5225249.5005679885]
[463358.09189802676, 5225221.524767004, 463383.5781380866, 5225247.010771889]
[463105.7192484405, 5225101.564091276, 463131.20549753483, 5225127.05010521]
[463230.6606852149, 5225099.074303491, 463256.1469294432, 5225124.560312545]
[463355.6021080773, 5225096.584526142, 463381.08834744943, 5225122.070530332]

Opening both geometries in QGIS does confirm this and shows them in the same area. So we can confirm that the input-editor does indeed change the projection system of the geometries, but technically they are still in the same location. (though it would be better if input-editor could still save files in their original projection system)

Therefore, my suspicion now is that the algorithms to calculate the intersections of terrain and geometry in radiation might not be able to handle different projection systems as it could be reading the y coordinate as it is, so it would most likely be out of range of the bounding box of the terrain. This could be related to #2558

We should definitely investigate this and make sure that the algorithm converts both terrain and geometry coordinates to the same projection system before doing the calculation. This could also help with users being able to import their own terrain files as there is a chance that it could have a different coordinate system from the geometries.

jimenofonseca commented 4 years ago

Great invrstigation. I think i know what the problem is. I saved the reference case with the input editor qhen i created the typology file. This updated the Zone file to the latest cea prj ‘which we fixed a few prs ago.

What we need to do is to reimport the terrain file,the street file, and the surroundigns file so CEA change the coordinate systme to the newest one.

After that the solar radiation should work...

Jimeno A. Fonseca Dr. Sc. ETH Zurich

Senior Researcher Singapore ETH-Centre (SEC)https://sec.ethz.ch/

Project Coordinator Multi-Scale Energy Systems (MuSES)https://fcl.ethz.ch/research/high-density-cities/multi-scale-energy-systems.html

Product Owner & Developer City Energy Analyst (CEA)https://cityenergyanalyst.com/

Principal Investigator Cooling Singapore (CS1.5)https://www.coolingsingapore.sg/ Future Resilience Systems (FRS)https://frs.ethz.ch/research/cyber-physical-systems/digital-twin-enabled-system-resilience.html

On 23 Feb 2020, 19:41 +0800, Reynold Mok notifications@github.com, wrote:

ok. There seems to be differences in the .prj files in both zone and surrounding where the project system is "WGS_1984_UTM_Zone_32S" instead of "WGS_1984_UTM_Zone_32N" and ["false_northing",10000000] instead of ["false_northing",0]

2.31.0 PROJCS["WGS_1984_UTM_Zone_32S",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",10000000],UNIT["Meter",1]]

2.29.0 PROJCS["WGS_1984_UTM_Zone_32N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

similarly, There are differences between the coordinates of the bounding boxes of each geometry, their y coordinates are different. But the difference in "false_northing" i.e. 10000000 seems to be equal to the difference between both y coordinates. So I guess they are actually referring to the same location.

2.31.0 [463110.6988839674, 15225351.444618214, 463136.1851344639, 15225376.930633564] [463235.6402998573, 15225348.954802573, 463261.1265454693, 15225374.440813035] [463360.5817018389, 15225346.464997474, 463386.06794257654, 15225371.951003049] [463108.20905922476, 15225226.50435994, 463133.6953090251, 15225251.990374586] [463233.1504855808, 15225224.014558226, 463258.63673050597, 15225249.500567988] [463358.09189802676, 15225221.524767004, 463383.5781380866, 15225247.01077189] [463105.7192484406, 15225101.564091276, 463131.20549753483, 15225127.05010521] [463230.6606852149, 15225099.074303491, 463256.1469294432, 15225124.560312547] [463355.6021080773, 15225096.58452614, 463381.08834744943, 15225122.070530333]

2.29.0 [463110.6988839674, 5225351.444618215, 463136.1851344639, 5225376.930633564] [463235.6402998573, 5225348.954802573, 463261.1265454693, 5225374.440813034] [463360.5817018389, 5225346.464997475, 463386.06794257654, 5225371.951003049] [463108.20905922476, 5225226.504359941, 463133.6953090251, 5225251.990374586] [463233.1504855808, 5225224.014558228, 463258.63673050597, 5225249.5005679885] [463358.09189802676, 5225221.524767004, 463383.5781380866, 5225247.010771889] [463105.7192484405, 5225101.564091276, 463131.20549753483, 5225127.05010521] [463230.6606852149, 5225099.074303491, 463256.1469294432, 5225124.560312545] [463355.6021080773, 5225096.584526142, 463381.08834744943, 5225122.070530332]

Opening both geometries in QGIS does confirm this and shows them in the same area. So we can confirm that the input-editor does indeed change the projection system of the geometries, but technically they are still in the same location. (though it would be better if input-editor could still save files in their original projection system)

Therefore, my suspicion now is that the algorithms to calculate the intersections of terrain and geometry in radiation might not be able to handle different projection systems as it could be reading the y coordinate as it is, so it would most likely be out of range of the bounding box of the terrain. This could be related to #2558https://github.com/architecture-building-systems/CityEnergyAnalyst/issues/2558

We should definitely investigate this and make sure that the algorithm converts both terrain and geometry coordinates to the same projection system before doing the calculation. This could also help with users being able to import their own terrain files as there is a chance that it could have a different coordinate system from the geometries.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/architecture-building-systems/CityEnergyAnalyst/issues/2594?email_source=notifications&email_token=ACEOXAUXWPASVP757QVW3UTREJOGHA5CNFSM4KZDJLS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMVZS3Y#issuecomment-590059887, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACEOXARFSQBKLVE3PIHQDK3REJOGHANCNFSM4KZDJLSQ.

reyery commented 4 years ago

I think it would be easier to just replace the shapefiles of zone and surroundings in the reference case if their properties have not changed. Then create another issue regarding the calculation of terrain intersection.