SEL-Columbia / networkplanner

Electricity infrastructure prototyping framework
networkplanner.modilabs.org
15 stars 3 forks source link

Scenario fails at network build stage #107

Closed Naigege closed 10 years ago

Naigege commented 10 years ago

The network looks a bit odd, with crosses and clusters of lines.

http://optimus.modilabs.org/scenarios/668.html

Traceback (most recent call last): File "utilities/harvest.py", line 53, in scenario.run() File "/var/www/np/np/model/init.py", line 262, in run networkValueByOptionBySection = datasetStore.buildNetwork(networkModel, networkConfiguration, jobLogger=Job) File "/var/www/np/np/lib/dataset_store.py", line 255, in buildNetwork net = jobVS.buildNetworkFromNodes(list(self.cycleNodes()), self.getProj4(), jobLogger=jobLogger) File "/var/www/np/np/lib/network/modKruskal/init.py", line 98, in buildNetworkFromNodes net = self.buildNetworkFromSegments(*self.generateSegments(nodes, computeDistance, proj4), jobLogger=jobLogger) File "/var/www/np/np/lib/network/modKruskal/init.py", line 194, in buildNetworkFromSegments subnet = net.addSegment(segment) File "/var/www/np/np/lib/network/init.py", line 409, in addSegment return self._addSegmentIndexed(newSegment) File "/var/www/np/np/lib/network/init.py", line 343, in _addSegmentIndexed subnetCounts = self._getIntersectingSubnets(newSegment) File "/var/www/np/np/lib/network/init.py", line 273, in _getIntersectingSubnets assert len(intersection) > 1 TypeError: object of type 'LineString' has no len()

carbz commented 10 years ago

Back in December when modeling very complex existing-networks in Timor, IDN, we experienced a similar failure at the 'Building network' step. We worked around the Timor failure point by simply subsetting out the most complex section of the Timor network. So there is precedent for the NP model to fail at the 'Building network' step of the process as recounted below. However Naichen's above error suggests some relation to the Subnet constraint.

Traceback (most recent call last): File "utilities/harvest.py", line 53, in scenario.run() File "/var/www/np/np/model/init.py", line 255, in run metricValueByOptionBySection = datasetStore.applyMetric(metricModel, metricConfiguration) File "/var/www/np/np/lib/dataset_store.py", line 179, in applyMetric nodeVS = metricModel.VariableStore(node.getValueByOptionBySection(), jobVS) File "/var/www/np/np/lib/variable_store.py", line 56, in init self.set(variableClass, value) File "/var/www/np/np/lib/variable_store.py", line 61, in set self.variableByClass[variableClass] = variableClass(self, value) File "/var/www/np/np/lib/variable_store.py", line 198, in init self.value = self.c'parse' ValueError: could not convert string to float: NA

chrisnatali commented 10 years ago

Looks like a bug. At Line 273 we're testing the result of intersecting a segment with the rest of the network. It's expecting a list of geometries in the case where the intersection doesn't happen at a single point, but the intersection could be a line in the case where both points of the segment exist on the network. Will patch it. Thanks for pointing this out.

carbz: the error you point out looks pretty different...that's in the variable processing code for the metric calculation (looks like it's expecting a number and it got nothing)

chrisnatali commented 10 years ago

This has been addressed with the merging of (this)[https://github.com/SEL-Columbia/networkplanner/pull/110] pull request.

The problem was resolved by rejecting candidate segments that match exactly with a segment on the existing/proposed network (code here)[https://github.com/SEL-Columbia/networkplanner/blob/master/np/lib/network/__init__.py#L269]

(I needed to remove code for this one)