split blocks

[leorosa]

Hi Nicolas,

Regarding the splitting of blocks, I've thinking in using the following algorithm:

1. select an edge;
2. find all parallel edges (which is already done when setting edge properties);
3. find all related points (p0 and p1 of each edge);
4. calculate the middle position;
5. find all parallel blocks;
6. for each block,
   6.1 create two new blocks, and
   6.2 remove the original;

What do you think about these steps? I'm wondering, if a toolbox is needed, to inform a distance/ratio, or some other parameter. I intend to read more of the code, to reuse something already done. Probably step 5 will be tricky.

Best regards,
Leonardo Rosa

[nicolasedh]

Hi,

Please let me think about it during the day. One thing that comes to mind
is how we should handle information on patches and edges that get split.
And bc's.

Maybe a seventh step, auto merge patches.

Instead of a window we could have an interactive plane. Like paraview
slice.

I'll get to you to night.

Best regards
Nicolas
Den 15 feb. 2016 01:16 skrev "leorosa" notifications@github.com:

Hi Nicolas,

Regarding the splitting of blocks, I've thinking in using the following
algorithm:

1. select an edge;
2. find all parallel edges (which is already done when setting edge
   properties);
3. find all related points (p0 and p1 of each edge);
4. calculate the middle position;
5. find all parallel blocks;
6. for each block, 6.1 create two new blocks, and 6.2 remove the
   original;

What do you think about these steps? I'm wondering, if a toolbox is
needed, to inform a distance/ratio, or some other parameter. I intend to
read more of the code, to reuse something already done. Probably step 5
will be tricky.

Best regards,
Leonardo Rosa

—
Reply to this email directly or view it on GitHub
#8.

[leorosa]

Hi,

Sure, take your time. This is a somewhat 'big' change, and the more it is planned, the better.

Creating new blocks, we were (explicitly) avoiding have to check where a block was split, how many elements maintain in each side, 'simpleGrading' values, if it some edge is an arc...

I have not thought about the patches, but... it would be convenient to keep the same type of the original blocks. What have you suggested with 'auto merge patches'? I didn't understand.

An interactive plane would be ideal. Not sure how much extra work will be needed, but maybe (for me) coding this would be helpful to improve other things (move vertices, extrude patches).

Thanks!
Leonardo

[nicolasedh]

Yes about the plane I was hoping for good examples of a widget. I had
quick look at http://www.vtk.org/Wiki/VTK/Examples/Cxx#Widgets but didn't
find anything that was exactly what I wanted. Maybe the interact with a
plane or distance widget.

Yes we are still in alpha release so if we loose information of edges or
patches its not a big problem. But we can't have edges/patches that are the
same in respect of their verticeIds but separate objectes. I think it might
happen when create the blocks. Especially when more than one block is
split. But will know when we try. One way to fix such an issue would be
have a function that loops through all patches and merges those that are
the same. That was the auto merge I was talking about.

I'll see if I can't dig in a bit my self but first I'd like to finish my
current project.

Let me know if you give it a shot and if I can help.

Nicolas
Den 15 feb. 2016 11:03 fm skrev "leorosa" notifications@github.com:

Hi,

Sure, take your time. This is a somewhat 'big' change, and the more it is
planned, the better.

Creating new blocks, we were (explicitly) avoiding have to check where a
block was split, how many elements maintain in each side, 'simpleGrading'
values, if it is an arc...

I have not thought about the patches, but... it would be convenient to
keep the same type of the original blocks. What have you suggested with
'auto merge patches'? I didn't understand.

An interactive plane would be ideal. Not sure how much extra work will be
needed, but maybe (for me) coding this would be helpful to improve other
things (move vertices, extrude patches).

Thanks!
Leonardo

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[leorosa]

Hi,

Just to be clear: if we have one block, defined with hex(0 1 2 3 4 5 6 7), create four new vertices (8, 9, 10, 11), and

• create hex(0 1 2 3 8 9 10 11)
• create hex(8 9 10 11 4 5 6 7)
• remove hex(0 1 2 3 4 5 6 7)

there would remain edges and patches at the same positions? I thought that the removeHexBlock() method would take care of the orphan edges and patches...

Leonardo

[nicolasedh]

Hi,

Well it should. If edges get orphaned. I haven't worked with it in a
while. So I'm not sure.

I guess we'll have to solve them problems as they pop up. It sounds like
your plan might work!
Den 15 feb. 2016 9:07 em skrev "leorosa" notifications@github.com:

Hi,

Just to be clear: if we have one block, defined with hex(0 1 2 3 4 5 6 7),
create four new vertices (8, 9, 10, 11), and

• create hex(0 1 2 3 8 9 10 11)
• create hex(8 9 10 11 4 5 6 7)
• remove hex(0 1 2 3 4 5 6 7)

there would remain edges and patches at the same positions? I thought that
the removeHexBlock() method would take care of the orphan edges and
patches...

Leonardo

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[leorosa]

I'll try this approach, then. Maybe first delete and then create -- but test and see what we get. I'll need first to read more code -- and probably ask for some help in the following days/week.

[nicolasedh]

Very good I'll be happy to help!

2016-02-16 1:53 GMT+01:00 leorosa notifications@github.com:

I'll try this approach, then. Maybe first delete and then create -- but
test and see what we get. I'll need first to read more code -- and probably
ask for some help in the following days/week.

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[leorosa]

Hi Nicolas,

It's been fun to read/change the code. I'm writing to let you know that a 'preliminar' implementation of a split block function is already present in commit leorosa@5c19746 .

As the way used to pick the vertices is kind of random, it was needed to (try to) reorder them. If you try to run the program, please test it also commenting the calls to "orderVertices" (SplitBlocks.cpp, lines 116 and 126) to see why it was needed.

Now this function splits all parallel blocks in two halves: it appears that the edges in a block may have different orientations, and then if a different ratio was specified, it would produce distorted blocks... Moreover, patches are not checked 'now', but I'll see that later.

Well, any comments are welcome.

Leonardo

[nicolasedh]

Hi!

Really nice work. I've just tried how it works. I haven't yet read any code but will start now. I did noticed that the vertices are not updated in the table. I'll have a look.

Yes in order to be able to use a parametric split we would have to check the direction of each edge and possibly reverse the direction. Mathematically I think it would easy just to check. Just check dot-product of each edge with respect to the first edge. If it's <0 then the parameter should be 1-p. Programatically though, I don't know =).

I've also had a thought on "previewing" the split. First I thought it would look nice if we showed a paraview style slice. However if we support parametric splits it would have to be one quad per block.

By the way. I've noticed a bug in the install.sh script. I've pushed a fix. If you like to pull it I'd reccomend you to have a look at git rebase

/Nicolas

[nicolasedh]

Hi,

I've added a note to the code. I really like gitub =)

leorosa@5c19746#commitcomment-16185845

[nicolasedh]

As for how we keep the vertices orderd.

What I did for the extrude block was to actually have 6 different ways to do it.
Now for edges there would be 12 different ways to split one block. However there are only three principal axis where we can split. So we should be able to boil it down to three different ways.
Basically for each block, we always have either edges 0,1,2,3 or 4,5,6,7, org 8,9,10,11. See the figure from OF user guide: http://cfd.direct/wp-content/html/UserGuide/img/user461x.png Based on that information we should know the order of the two new blocks vertices.

When thinking about it. We could hava a situation when the user selects one edge. At least one block gets split twice or more. Like a wierd O-grid. Which starts from say face 5 och one block and goes through some loop and reconnects at say face 6 (which isn't opposite of face5.

So maybe it's better to re-order as you are doing. But I really think we should be able to use the information we have of the deleted block. I just can't figure it out right now.

[leorosa]

Hi!

Thinking a little more: we should be able to retrieve the (ordered) vertices from the blocks themselves. Them, with the parallel edge that actually has the "0" vertice, the oposing vertice can tell us which of the three (block) directions is to be divided: 0-1, 0-3 or 0-4. Them select the right vertices before creating the new half-blocks.

I'm not satisfied with the implemented "orderVertices", as (I think) it is not guaranteed that it will always work -- e.g. a really distorted block. But then the mesh will have a poor quality anyway.

This function also appears to be slow. Maybe we can use it (only) in a "Tool/Reorder block" function, destined to correct skewed blocks found by the user? Hopefully it would be useful for those weird split cases that you cited.

p.s.: this notes thing from github is Really nice :)

[nicolasedh]

Hi

Thinking a little more: we should be able to retrieve the (ordered)
vertices from the blocks themselves. Them, with the parallel edge that
actually has the "0" vertice, the oposing vertice can tell us which of the
three (block) directions is to be divided: 0-1, 0-3 or 0-4. Them select the
right vertices before creating the new half-blocks.

Good thought! I think it sounds really good. Smart!

I'm not satisfied with the implemented "orderVertices", as (I think) it
is not guaranteed that it will always work -- e.g. a really distorted
block. But, then, the mesh will have a poor quality anyway.

Yes and how about rotated 45 degrees up and to the side. Will min z be good?

This function also appears to be slow. Maybe we can use it in a
"Tool/Reorder block" function, destined to correct skewed blocks found by
the user? Hopefully it would be useful for those weird split cases.

Well speed isn't much of an issue. Unless it's really slow. I once got a
hint from they guy from swift block. He had an algorithm from a published
paper that constructed the blocks from vertices. I was looking for it in my
notes but haven't found it. I could check with him if you are interested.

p.s.: this notes thing from github is Really nice :)

Yes I really like it! I didn't know github was this good ;-)

[leorosa]

Hi!

Sorry for the (really) late reply: my time was short these days to do anything. This week I intend to work again on this approach for the blocks splitting.

[nicolasedh]

Hi,

Don't worry about it. Take your time. It's a spare time project so don't
feel any pressure to do anything.

What's the point if it's no longer fun? Or at least interesting?

/N

2016-03-01 11:01 GMT+01:00 leorosa notifications@github.com:

Hi!

Sorry for the (really) late reply: my time was short these days to do
anything. This week I intend to work again on this approach for the blocks
splitting.

—
Reply to this email directly or view it on GitHub
#8 (comment)
.