intersectMass component is unable to process normal breps and the warning is inconsistent

The attached workflow generate 10 random zones in a fix 3D grid.

Sometimes, the zones generated sometimes can be processed by the intersectMass correctly:

However, After changing the seed of the random function, some of the breps generated cannot be processed by intersectMass and a warning is shown:

Another strange thing is that the warning on intersectMass is not consistent, i.e. the same group of breps sometimes can be processed, and sometimes not ... And I'm sure it's not the problem of the breps.

Appreciate your kind advice on this issue which is quite blizzard ...

Thanks.

Attachments:

intersectMass issue _v01.gh, 473 KB

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Abraham Yezioro on April 26, 2017 at 10:56am

Hi Ji,

Why don't you connect directly the brep component to the HB_Mass2Zone? This works fine.

The boxes you create don't intersect between them. They have only a common face. I assume that this is what confuses the HB_IntersectMass.

Of course, i assume each box will be an independent zone and you don't want to make combinations of boxes into 1 zone.

-A.

Permalink Reply by Abraham Yezioro on April 26, 2017 at 12:23pm

See file ...

-A.

Attachments:

intersectMassissue_v01_AY.gh, 484 KB

Permalink Reply by Grasshope on April 26, 2017 at 8:41pm

Thank you, Abraham.

My main concerns are:

1. the intersectMass component shouldn't give a warning for breps with no partially overlapping surfaces

2. the warning is not given in a consistent manner.

We can bypass the intersectMass component in this particular case, but we still need to use it in other workflow in which large amount of input breps may or may not have partially overlapping surfaces. It will not be efficient if we have to manually bypass intersecMass for particular cases it cannot handle.

Permalink Reply by Abraham Yezioro on April 26, 2017 at 9:47pm

Still don't get why you need the intersect mass. Your case doesn't allow intersection. At most, face overlapping. That's why what i sent works fine.

Anyway, i was curious of your comment, and started testing if it has to do with tolerance units ... it is not. The thing is that when i open your file the intersectMass is ok. But when i move the seed slider it always turn orange. Even for the original seed. But the most interesting thing is that if i recompute the file it works fine for all cases. From this i have the suspicion that something remains in memory, from previous checkings, that needs to be cleaned. The error/warning is the one in line 257 (if Hzones == True).

Here probably Chris will have a more educated answer.

-A.

Permalink Reply by Grasshope on April 27, 2017 at 3:32am

Yes, Abraham, this is exactly the problem I encountered. Apologize that I didn't explain it clearly in my original post.

Following your advice, I did some more tests:

1. If the mass2Zone component is not imported in the workflow, there is no problem for the intersectMass component, no matter how we change the random seed to generate different groups of breps with overlapping surfaces:

2. However, once we add the mass2Zone component into the workflow, we have this problem as posted here.

3. As you pointed out, the warning is given when "Hzones == True" which only happens when one of the objects in _bldgMassesBefore is recognized as a zone already stored in HB Hive. So, I added one line after line257 to print out the zone name:

4. It seems for the cases that the intersecMass component shows warning, there is a zone name printed:

5. Whereas for those cases that the intersecMass component shows no warning, there is no zone name printed:

6. Even if the zone creation is turned off, there is still zone name printed for cases that intersectMass is unable to process:

So, I agree with you that this might be related to the HoneyBeeHive which stores honeybee zones.

Maybe whenever upstream geometries change that are connected to either intersectMass or Masses2Zones, the HoneyBeeHive has to be cleaned up and zone objects inside need to be recreated.

Hope Chris and Mostapha can kindly take a look and advise if this is the source of the issue.

Thanks.

- Ji

Attachments:

intersectMassissue_v02.gh, 474 KB

Permalink Reply by Abraham Yezioro on April 27, 2017 at 3:52am

I can add that the index of the names printed is increasing each time, so i'm betting on a memory storage issue.

Also if you set the Mass2Zone to False, or disable it, and recompute the IntersectMass works fine (no warnings).

-A.

Permalink Reply by Grasshope on April 28, 2017 at 2:45am

Yes, Abraham, disable Mass2Zone and recompute the workflow can solve this issue.

Permalink Reply by Grasshope on June 18, 2017 at 8:14pm

May I ask if this error related to the intersectMass component and zone memory storage management as pointed out by Abraham has been checked and verified?

Thanks.

- J.

RSS