[Paraview] [EXT] Re: How to find the nearest quad element?

Wed Sep 9 09:17:59 EDT 2015

For sure it is useful to attach the script if this is not too problematic
for you.

Marco

On Wed, Sep 9, 2015 at 2:53 PM, Dennis Conklin <dennis_conklin at goodyear.com>
wrote:

> Marco,
>
>
>
> Hey, we are all busy, I understand that – and I don’t mind doing the work
> myself but I’m not having success here.
>
>
>
> I have looked at the vertex from the Cell Centers filter and they looked
> okay to me.  I am just now editing my script so that each hex will get the
> GlobalElementID of the quad that GetClosestPoint thinks is closest, so I
> can dig a little deeper.
>
>
>
> Would it be useful for me to attach my script so that any obvious mistakes
> can be detected?
>
>
>
> Dennis
>
>
>
> *From:* Marco Nawijn [mailto:nawijn at gmail.com]
> *Sent:* Wednesday, September 09, 2015 8:50 AM
>
> *To:* Dennis Conklin
> *Cc:* Paraview (paraview at paraview.org)
> *Subject:* Re: [EXT] Re: [Paraview] How to find the nearest quad element?
>
>
>
> "for the cell locator." -> OOPS: I mean for the point locator of course.
>
>
>
> Marco
>
>
>
>
>
> On Wed, Sep 9, 2015 at 2:49 PM, Marco Nawijn <nawijn at gmail.com> wrote:
>
> Hi Dennis,
>
>
>
> Sorry for not coming back with an example yet. I had a few other things
> that keep
>
> me really busy. I don't have a solution yet, but I was wondering if you
> visualized
>
> the center point locations you believe are used as a basis for the cell
> locator.
>
> I typically do this by creating a vertex (point cell) for every point that
> I am interested
>
> in. In this way you can plot the point, the hex and the quad and continue
> debugging
>
> from there.
>
>
>
> Marco
>
>
>
>
>
> On Wed, Sep 9, 2015 at 2:16 PM, Dennis Conklin <
> dennis_conklin at goodyear.com> wrote:
>
> All,
>
>
>
> I thought an example of my “not sensible” output would make this clearer,
> see the picture below.
>
> All of the highlighted hex elements are at the edge of the piece and the
> lower edge of the piece is covered in membrane elements (quads).   So, each
> of the highlighted hex elements actually shares 4 nodes with a quad.
> Therefore, the closest quad to each of those hex elements should be the
> attached quad, and each of the highlighted hexes should get a different
> index returned from FindClosestPoint.
>
> I have displayed the actual index returned from FindClosestPoint on each
> hex.    So there are 5 hexes that FindClosestPoint thinks quad18 is the
> closest quad, similarly 5 hexes for quad19, 5 hexes for quad20.
>
>
>
> I expect that each of the highlighted hexes should get a different index
> returned from FindClosestPoint and that index should correspond to the
> individual membrane that each hex shares 4 nodes with.
>
>
>
> I still am not sure that this will make sense, but any ideas why this is
> not behaving as I expected?
>
>
>
> Thanks for any help
>
>
>
> Dennis
>
>
>
>
>
> *From:* Dennis Conklin
> *Sent:* Tuesday, September 08, 2015 2:54 PM
> *To:* 'Marco Nawijn'
> *Cc:* Paraview (paraview at paraview.org)
> *Subject:* RE: [EXT] Re: [Paraview] How to find the nearest quad element?
>
>
>
> All,
>
>
>
> So I have taken a shot at this and have a few questions.
>
>
>
> I have multiple blocks of quads and I need to find the nearest quad for
> every hex in the model (also multiple blocks).  The purpose of this is to
> assign the Normal to the nearest quad to each hex
>
>
>
> My approach was:
>
> 1.       Create 2 inputs for the Programmable Filter
>
> a.      1st is regular Exodus file
>
> b.      2nd is regular file with Extract Surface/Generate Surface
> Normals/Cell Centers filters run – this has no cells, only points at the
> quad centers that contain what I want, which is Normals to the quad (also
> contains points at the hex centers, which I will use later)
>
> 2.      In PF, I loop thru all quad blocks in the 2nd input and build 2
> arrays.  First array has all the points in all the quad blocks in the 2nd
> input, and the second array has the corresponding normal associated with
> those points.
>
>
>
> Now, I make a vtk.vtkKdTree and use BuildLocatorFromPoints(my pt array)
>
> Now I loop over all hex in model, call FindClosestPoint using the point
> from the Cell Centers filter for the hex.  This returns an integer index
> and I assume Normals(index) is the normal associated with that quad
>
>
>
> I do not get a sensible output.
>
>
>
> My conclusion is that when I go thru this process, the index returned from
> FindClosestPoint is no longer synced to the original order of the points,
> which causes it to be a bad index into my Normals array.
>
>
>
> It’s also extremely possible that there is some setup of kdTree that I
> need to do first that I am omitting.
>
>
>
> So, is there a way to get kdTree to preserve the original order of the
> points, or is there another way to get an index back into my array of
> Normals, such that I can figure out which one is associated with the return
> from FindClosestPoint
>
>
>
> I’m not sure this is clear enough to be interpreted by anyone, but here’s
> hoping.
>
>
>
> Dennis
>
>
>
> *From:* Marco Nawijn [mailto:nawijn at gmail.com <nawijn at gmail.com>]
> *Sent:* Tuesday, August 25, 2015 11:26 AM
>
>
> *To:* Dennis Conklin
> *Cc:* Paraview (paraview at paraview.org)
> *Subject:* Re: [EXT] Re: [Paraview] How to find the nearest quad element?
>
>
>
> Hi Dennis,
>
>
>
> That timeframe is ok for me.
>
>
>
> Marco
>
>
>
>
>
> On Tue, Aug 25, 2015 at 5:24 PM, Dennis Conklin <
> dennis_conklin at goodyear.com> wrote:
>
> Marco,
>
>
>
> I am actually tied up for the next week or so, so if you can post a sample
> in that timeframe that would be perfect.
>
>
>
> Thanks very much
>
>
>
> Dennis
>
>
>
> *From:* Marco Nawijn [mailto:nawijn at gmail.com]
> *Sent:* Tuesday, August 25, 2015 11:21 AM
> *To:* Dennis Conklin
> *Cc:* Paraview (paraview at paraview.org)
> *Subject:* Re: [EXT] Re: [Paraview] How to find the nearest quad element?
>
>
>
> Hi Dennis,
>
>
>
> You might also be interested in the vtkCellCenters filter. As the name
> suggests, it
>
> will generate the centers of the cells for you. If you are not in a big
> rush, I can build
>
> you a small self contained sample in Python that demonstrates the filter
> and the
>
> use of the point locator. I am a little busy at the moment, but I can post
> the sample
>
> in a couple of days.
>
>
>
> Marco
>
>
>
>
>
> On Tue, Aug 25, 2015 at 1:40 PM, Dennis Conklin <
> dennis_conklin at goodyear.com> wrote:
>
> Marco,
>
>
>
> Thanks for that tip – I’m not very familiar with vtk and I’ve never heard
> of that class but it seems appropriate so I will try to dig into it.
>
>
>
> Thanks again
>
>
>
> Dennis
>
>
>
> *From:* Marco Nawijn [mailto:nawijn at gmail.com]
> *Sent:* Monday, August 24, 2015 10:28 AM
> *To:* Dennis Conklin
> *Cc:* Paraview (paraview at paraview.org)
> *Subject:* [EXT] Re: [Paraview] How to find the nearest quad element?
>
>
>
> What about the following:
>
>
>
> Generate two additional datasets, one containing (an approximate of) the
> center of the hex elements, the second the center of the quads. Then create
> a vtkKdTreePointLocator object based on the center points of the quad
> elements. Than loop over the centers of the hex elements and use one of the
> Find* methods to get the closest quad.
>
>
>
> Marco
>
>
>
>
>
>
>
>
>
> On Fri, Aug 21, 2015 at 2:21 PM, Dennis Conklin <
> dennis_conklin at goodyear.com> wrote:
>
> Sam,
>
> Thanks for responding.  You have helped me several times in the past and I
> am always grateful for your insights.  In this case there is considerable
> refinement in the model, so only a very small portion of the hex elements
> are in immediate contact with quads.   Also you could think of places like
> the tread in the tire where there is no reinforcement whatsoever.
>
> Another approach which I have considered is a wave propagation technique,
> where in the first wave every hex immediately adjacent to a quad gets
> direction cosines assigned (as you suggest).   Then you loop thru the
> remaining elements and assign cosines from any adjacent quad or hex that
> has cosines.   Eventually the direction cosines will propagate throughout
> the model.   A major complication is that wavefronts will collide and then
> you will have to choose which of several conflicting neighbor cosines to
> adopt.  Averaging is one approach but certain structures give adjoining
> cosines which are 180 degrees reversed, so averaging would give you an
> indeterminate direction.
>
> I am toying now with some pseudo-variables, such as combinations of radius
> and lateral location, combined with zoning, to try to find a quantity that
> is unique for a local section of the geometry, to reduce the  search size
> for each hex element.
>
> I am still hoping for a very clever scheme which someone may suggest
> before I proceed with these much more brute force methods.
>
> Dennis
>
>
>
> *Sam Key Wrote:*
>
> *Dennis, *
>
> *Assuming for the moment that each quad 4-tuple is a finite element that
> contains one or more tire reinforcement items, and that each quad 4-tuple
> is "sandwiched" in between two hex 8-node finite elements, then the quad's
> 4-tuple is also a surface facet of two different 8-node hexahedrons. Both
> hexhedrons are the 'closest' hexhedrons to the quad. Given the usual
> organization of 'element blocks' in the Exodus-II datum structures, the two
> closest hexahedrons will be located on the surface of their respective
> element blocks. *
>
> *Using material ID's which are also element block ID's, have the software
> generate surface side-sets for each of these two element blocks specified
> with these two material ID's. With luck, each member in the side-set will
> be specified as a 2-tuple, (Elem# in the block, Quad-Face# in the hexah) *
>
> *With his info, you can confine your search to finding the side-set item
> that has a 4-tuple that matches your quad's 4-tuple. The search is reduced
> to a relatively small collection of hexahedral surface 4-tuple faces.  *
>
> *Hope this helps. *
>
> *Samuel W Key FMA Development, LLC 1005 39th Ave NE Great Falls, Montana
> 59404 USA *
>
>
>
>
>
> *From:* Dennis Conklin
> *Sent:* Thursday, August 20, 2015 3:52 PM
> *To:* Paraview (paraview at paraview.org)
> *Subject:* How to find the nearest quad element?
>
>
>
> All,
>
>
>
> I have an Exodus, multi-block model.  Most of the blocks are hex elements,
> and some are layers of quads (tires are composite structures).  I would
> like to establish local strains which are oriented in the direction of the
> nearest quad layer.  To do this I need to identify, for each hex in the
> model, which quad element in the model is closest to the hex.    Then I can
> extract directions from the quad element and rotate the strain tensor in
> the hex to these local coordinates.
>
>
>
> My question is,  is there some clever and efficient way to quickly
> determine the nearest quad for each hex in the model.  Keep in mind that
> there are multiple blocks of quads, but if there is some way to address the
> quad blocks one at a time, I could make this work.
>
>
>
> The brute force way is:
>
> Loop over every hex in the model:
>
>       Loop over every quad in the model:
>
>              Calculate the distance between hex and quad
>
>              Smallest distance wins!
>
>
>
> That is a pretty brutally inefficient calc (several million hex elements)
> that I am trying to avoid – any ideas about how best to approach this.
> I’m hoping for some elegant way to use connectivity or something of that
> sort.
>
>
>
> Thanks for looking
>
>
>
> Dennis
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150909/1979681e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 116565 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150909/1979681e/attachment.png>