RadiantTempMap resolution problem

old forum
1

Hi,

I’m trying to use the HB_RadiantTempMap component, but i get the following error:

  1. The number of test points in the _testPtsViewFactor and mesh faces in the _viewFactorMesh do not match.

This happens when i change the gridSize_ in the HB_IndoorViewFactor (to 1 as in video 8) (attached picture).

I assume there is something i did wrong, but where …?

Thanks,

-A.


2

Hi Abraham,

I can’t seem to replicate your error. Attached is a screenshot of what I get with the video 8 example file. Is there anything different about your GH file from the example and, if so, could you upload it?

I know I put in a check to make sure that the faces of the generated mesh and the number of branches in the view factor tree match, which is why you are getting that warning. Perhaps you have a geometry case where there is a mesh face generated outside the boundary of the zone?

-Chris


3

Hi Chris,

Attached the file i’m using. I don’t believe i’m doing something different from the video. Framed in white the relevant components.

Thanks,

-A.

8 - Importing Surface Level Results and Visualizing Them_V8.gh (260 KB)

4

Chris, I just wanted to confirm that I can also reproduce the warning

5

Hi,

Changing the AbsoluteTolerance to 0.001 (it was 0.01) seems to be the solution to this problem (and others :-)).

Mostapha, can you confirm this at your end?

Thanks,

-A.

6

Well. That is strange (for this problem). Chris, should we add an extra check for this one?

7

I guess that we should but I have a rough idea of why this is happening. I used the model tolerance in a lot of checks in the components that I made and I can see that having a large tolerance could cause the checks to behave weirdly. I am going to look deeper into why the tolerance is an issue on this component and see if I can come up with solutions that could be implemented on the other components like the glazing generator.

In the meantime, it might be wise to put in a check on HB_HB next to the units system check to make sure that users have a good Rhino model tolerance that won’t cause any of the components to behave weirdly.

8

Hey Guys,

I have new information to report. I have found the specific surface that causes the problem. From what I can tell, the issue only happens when you have geometry that has been created with one Rhino model tolerance and then internalized into GH but then our components act on it using a different Rhino model tolerance. So, as long as the user is creating geometry and using out components all within the same tolerance, there should never be any issues. It just happens in our case here because I created the house geometry with a tolerance of 0.001 but, then, when Abraham opened it on his system, the component generated a mesh off of that geometry with a tolerance of 0.01. Accordingly, this caused that little sliver of a triangle in the image below to not be a mesh face and this later caused my component to fail. I am going to put in a warning about the tolerance so that users know what to do the next time that this happens.

9

Thank you Sherlock!