Lines in Breps after using Polysurface

[Mr. Bram1 Kerkhofs1 0]

Dear

I'm currently wrestling a bit with the following:

A bit of a side story:
Whenever you use the Feature Extract functionality in order to get an explicit meshing in SnappyHexMesh (openFOAM), you need to know exactly where you have some edges and where not. Feature Extract opens your STL, tracks down all defined lines, and considers them as edges, and puts it in an eMesh file. If you don't control where the lines are, you need to open the processed .eMesh file in a program and manually remove lines you don't consider relevant for the mesh generation, which is tedious and doesn't go with the nice automatic optimization which is possible in CAESES.

 

 So I'm busy designing this quite complex wing with the philosophy as Fourier series: look at it as a sum of series of reoccurring things.

My computer isn't from the latest generation and I found out that I could make the wing with a metaSurface, and just let it calculate the same thing over and over, just translated and rotated a bit. Or I could find out what the longest period is of my reoccurring things and just make images of it, which are translated and rotated. And Eureka, the second strategy devided my calculating time with a factor of 4.

Bear with me...

The only disadvantage was that, while using PolySurface, it sometimes generated a line inbetween two subesquent surfaces, and sometimes it didn't.
I was looking for ways to control it and I found the following: Some geometries just get it, some don't, don't know why.
The lines between the surfaces are not visible when using the view of the polysurface, they only emerge when using the Breps representation.

 

So my question is: How I know when polySurface will add a division line, and when not? or: How do I get rid of the lines in Caeses?

So I put this case in the attachment.
You can see here 2 rows of planes, the first one is twisted, the other one is just straight.

They are equally long, but the twisted one has clear divisions, while the straight one doesn't have a division in the three last surfaces (see picture).

I also put the case in attachment

Cheers, and have a nice weekend
 

Polysurface_line.fdbc

[Jörg 29]

Hi Bram,

 

I am not 100% sure what you try to model - maybe your meta surface modeling is not ideal or can be further improved. Do you have an example that you can post?

 

The brep splits the surfaces according to their continuity information that you can control:

 

For instance, a linear brep will not be split, while some concatenated ruled surfaces lead to splits. You can change this setting to remove all splits, for instance. However, we should check your meta surface model, or better understand what you finally need.

 

Best regards

Joerg

[Mr. Bram1 Kerkhofs1 0]

Hi Joerg

Thanks for the fast reply, you never disappoint :).
The controls do solve the problem. When I put it to "Tangent discontinuity (G1)" it doesn't show any break lines. So it's the " Tangent Magnitude Discontinuity (C1)" which is causing the break lines.
But it's a bit strange since the thing I'm modelling in the example is actually a kind of helical-surface which could be continuously generated through a metaSurface. But since a helix is just a continuous "reoccurring" function you don't need to calculate every point over and over again. It's a bit like trying to make a sinus function which is 8 periods long, and instead of calculating every point, you take one period and copy it multiple times and paste them behind eachother. So you just copy-paste the helix and translate and twist the copied part and put it on top of it, which is faster. This also shouldn't bring any discontinuity with it, since it's a copy.

Side story:

The speed is not of concern for the case in attachment, but for my full model it takes 140seconds (the fast way) to process since there are a lot of "looking up" going on for the design parameters, when I let it run completely through the metaSurface it takes >500 seconds. Timing was done with the RunProfiler, and to be sure that there is no cheating because of the "smart and lazy" CAESES algorithm I requested it to give me the approximate surface area, so I was sure the surface was generated.
So speed optimization is the main reason why I am doing this :).
 
End of side story

I made an additional case, where I have the same problem. This time it is a Helix which turns around a line and generates a surface. As you can see, there is only a division line on the last part. An here is the catch: this only happens when the last part isn't complete a full copy. So in order to generate the last part I put in the ImageSurface the option .setUDomain([0,j]). Whenever j<1 you get the division line, whenever j=1 no division line. The length of a block is 0.3, and it should fill up until 1, so 3,333 blocks are necessary, when I put the Length to 0.25, so it generates 4 blocks, there is no division line.

Enjoy the weekend!

UPDATE:
Another observation: When I create a brep of the PolySurface of straight rectangles, it doesn't create the split line. When I import the PolySurface as a source for a boolean operation in a Brep, it creates the split lines again. But when I make first a Brep of the polysurface, and take that brep as a source for the boolean operation, again no split lines.
Hope this helps :)

Polysurface_line.fdbc

[Stefan Wunderlich 6]

Hi Bram,

 

just a short note from my side:

There is a difference between BrepSources and BooleanOperation / SolidFromIntersection.

 

In the boolean operation, we add the source surfaces of the polysurface to increase robustness. This is maybe not in all cases the best solution and we will think this over.

But then we would need to introduce "split continuity" in all these tools (like in BrepSources) - simplicity vs. options ;)

 

Cheers,

Stefan