Color Surfaces by EP Result issue

[jacoposartore]

As mentioned in issue #164, this components behaves oddly: sometimes it perfectly works and returns colored surfaces with legend

sometimes it doesn't

and returns the error

"0. Not all of the connected surface data could be found in the connected zones. You may want to connect all of your zones in order to see all of your connected surface data.

1. Runtime error (IndexOutOfRangeException): index out of range: 0
2. Traceback: line 317, in getData, "" line 606, in script"

This error is weird because the same zone is connected to the Color Zones component and works fine. Moreover, the surface data from the Read EP Surface Result seems correct.

I have uploaded to Dropbox https://www.dropbox.com/sh/t0lr3ibhl04xuoc/AABMQAEt6Jk5ogPH-gkDDsoIa?dl=0 the GH definition and two zip files with all the files generated by EnergyPlus in both the situations.

@chriswmackey It's basically the issue #164 GH definition that you corrected with all the components updated.

[chriswmackey]

Hello @jacoposartore,

I have found out what the issue is. For some reason, the names of the surfaces in your csv result file do not match the names of the surfaces in the zones that you are connecting. See below where you can see that the names in the header of the imported results do not match the labeled names of the surfaces in the Rhino scene:

The name of the zone still matches and this is why it still works for the color zones component. Do you remember what you did that was different between the case where the surface colorer worked and when it did not? Somewhere in the workflow which did not surfaces, the surfaces are probably being re-named.

Mostapha, is there any point in the workflow where you are re-naming all of the surfaces of the zone or re-creating the geometry such that it would have a different guid or name (perhaps in the re-evaluate zone)? In any case, I put in an extra check to make sure that the component does not turn red when none of the names of the surfaces match between the imported data and it just gives a warning now.

This issue is not really about the surface colorer anymore but is about the naming convention of the surfaces. I am going to pass this issue off to Mostapha since this is in his code domain.

[chriswmackey]

@mostaphaRoudsari and @jacoposartore ,

Maybe the fact that the surface names don't match is a result of this issue: https://github.com/mostaphaRoudsari/Honeybee/issues/168

Mostapha, please share your thoughts.

[jacoposartore]

@chriswmackey I remember that I deleted the result's folder then I restarted my laptop, but I guess that this won't make a real difference. I didn't apply any change to the definition between the two situations.

[chriswmackey]

Thanks @jacoposartore. I don't think that should cause the names to change. Mostapha is out for the next few days but we will get his thoughts and get to the bottom of this afterwards.

[mostaphaRoudsari]

Hey @chriswmackey and @jacoposartore. Sorry for being so late.

I see why this is happening, and you are right #168 is related:

If the user doesn't assign the names for the surfaces a random name will be generated. It means if you run the analysis once and then for any reason update the process name of surfaces will be different, and it will break your workflow... oops!

I can address this issue by naming the surfaces in a better way and rename the surfaces in createHBZoneFromSurfaces: https://github.com/mostaphaRoudsari/Honeybee/issues/76 and #168

I will be all over the place until the last week of September. I hope I can address all these issues once together at that time.