[vtk-developers] how to handle FEM data in VTK?

Pierre JUILLARD pierre.juillard at gmail.com
Tue Jul 8 09:09:24 EDT 2008


Dear M. Gebbert,

Thank you very much for your so detailed answers.
However, as I said, I am not a VTK expert, nor english my mother tong is.
What do "IMHO" and AFAICT" mean?

I see that I am actually following you in this work as we target the same
software:
PAMSTAMP/ PAMCRASH (M01 mapping file manipulation),
AUTOFORM,
ABAQUS (INP and ODB file manipulation),
LSDYNA, and also NASTRAN.

I guess they are not, but I ask nontheless as it could save much time for
us: are you works available somwhere? It would really ease our work to start
from something already existing.

In any case, I thank you again for your help!
It really is a pleasure to exchange about this subject with you.

Best regards,

Pierre



2008/7/8, Soeren Gebbert <soerengebbert at googlemail.com>:
>
> Hello Pierre,
>
> 2008/7/6 Pierre JUILLARD <pierre.juillard at gmail.com>:
> > Dear M. Gebbert,
> >
> > I thank you very much for all these details.
> > I tried to organize all the information you gave me in the enclosed ppt
> > (also, I printed it in the enclosed pdf for an easier reading).
>
> Thanks, i had a look on it.This is quite near the concept i have
> implemented.
> But i handle shell and volume elements equally. The position of the
> integration points for shell elements is based
> on the element or nodal (integration point) thickness.
>
> >
> > Could you please confirm me that this is "more or less" a good
> > representation of your own VTK structure? It raised some uncertainties
> from
> > my side, and if it doesn't bother you, I would like to ask further
> questions
> > on the following sujects.
> >
> > =============================================
> > POINT DATA at integration point for shell and volume elements
> > =============================================
> >
> > How should the difference concerning integration points between shell and
> > volume elements be dealt with?
>
> If you want to visualize the integration points, which i do, you must
> know there exact position
> in 3d space. Therefore the integration points are stored with valid x,
> y and z coordinates for volume and shell elements.
> If you want to transform them based on a transformation of the FEM
> mesh, you have to calculate the correct
> position again. With volume elements there is no problem, because the
> integration points can be positioned with the available shape
> functions,
> but shell elements only provide shape functions in two dimensions.
> Therefore i store the thickness of a shell element as a scalar value
> per element or integration point and use this value to
> compute the correct position in 3d of the shell integration point.
>
> >
> > In your e-mail, I don't see any distinction between shell and volume
> > elements: you seem to deal with them equally using the same data
> > structure.However, I made a difference in the pdf because some of the
> shell
> > integration point (the in-plane integration points) have at least one
> more
> > point data than the others (over-thickness integration points): the
> > thickness.
> > I guess there thus should be a distinction, shouldn't it?
>
> I make no difference in the way that i use the same filters for shell
> and volume elements which know how to handle them.
> The filter i have implemented are flexible in this way, because the
> computation between shell and volume elements and
> integration point, are not that different. I store the thickness for
> shell integration points. The filter recognize if
> a thickness array is available or not.
>
> >
> > As for volume elements, all integration points are considered equally.
> >
> > =============================================
> > LOCAL COORDINATE SYSTEM for tensor results
> > =============================================
> >
> > I really am a VTK beginner as I think you have guessed.
> > The thing is I don't know in which coordinate system are expressed
> vectors
> > and tensors, and if this coordinate system may be modified.
> > Is it indeed possible to use local coordinate system?
>
> AFAICT VTK uses a global coordinate system.
> The transformation classes which are available automatically transform
> vector data based on the global coordinate system.
>
> > Several local coordinate definitions (attached to a single finite
> element)
> > are possible, based on the element connectivity.
> > The following one is most notably widely spread in explicit simulation
> for
> > quadrangles:
> >
> > Considering a quadrangle made up with the nodes 1, 2, 3 and 4.
> > calling A the middle of segment [1,4]
> > calling B the middle of segment [1,2]
> > calling C the middle of segment [2,3]
> > calling D the middle of segment [3,4]
> > => the X local axis may be given by: [A,C]
> > => the Z local axis may be given by: AC x BD (vector product)
> > => and finally the Y local axis may be given by: Z x X (vector product)
> >
> > It is interesting as it allows to move a mesh (translation / rotation)
> > without having to update the vector and tensor data attached to the
> elements
> > (cells).
>
> I use a global coordinate system and have to compute the
> transformation and the position
> of tensors and integration again if the FEM mesh is transformed
> (affine, etc..).
> IMHO to use a global coordinate system is much more consistent
> for computation and for visualization. We use the results of many
> different fem programs (PAM-STAMP, Autoform, Abaqus, LS-DYNA, ...)
> and we want to visualize them in the same way, so a global coordinate
> system is IMHO a good choice.
>
> >
> > So, if the definition of the local coordinate system (in which are
> expressed
> > vector and tensor result for one cell) can be modified, my question is:
> > How should this definition be stored? How to make it dependent from the
> > element connectivity? Woudl you have some advices?
>
> Because i use a global coordinate system, i cant tell how to handle
> such information.
> But one way is to use the element geometry like you have described.
> AFAICT Abaqus uses the global X-Axes
> as one component of the local coordinate system,if the angle of the
> element edge is sufficient.
>
> >
> > =============================================
> > CELL and POINT DATA in the first ugrid
> > =============================================
> >
> > You were indicating me that you store some cell and point data in the
> first
> > ugrid.I think it is intersting to store nodal thickness (optionnal),
> element
> > ID, and material ID at this level. Had you other data in mind?
>
> I store the element thickness in elements or integration points, the
> material in the elements and
> original ids in points and elements. But VTK is flexible enough to
> store as many scalars (temperature?),
> vectors (displacement?) and tensors as you like. While the process of
> the fem data, i store several new
> arrays in elements, points and integration points.
>
> >
> > =============================================
> > correspondences between ugrids
> > =============================================
> >
> > You were pointing me to use integration method IDs to have a link between
> > the 2nd and 3rd ugrid.
> > I also added the element IDs to have a link between the 1st and 2nd
> ugrid:
> > does this seem relevant to you?
>
> Because the elements in the first and second grid have an equal
> numbering, i don't need to store
> the element ids. If you use the threshold filter with the first and
> second ugrid which will have equal
> threshold arrays, the data consistency is granted.
>
> >
> > =============================================
> > related works
> > =============================================
> >
> > Finally, do you know if the LSDynaReader class produces the same kind of
> VTK
> > structure when reading LSDyna results? I tried to read the description
> page
> > of the vtkLSDynaReader class, and I am not really sure to understand what
> is
> > really done...
>
> Sorry, i have no clue how the LSDynaReader reader works. The
> documentation confuses me.
> We convert LSDyna format in the form i have described, without the
> usage of the LSDynaReader.
>
> >
> > =============================================
> >
> > Thank you again for all the advices you already gave me.
> >
> > I know that you are only describing your method, and that several others
> > could most probably be found to handle FEM data in VTK. So You may be
> > surprised that I have so many questions.
> > The thing is, it really appears to me as a complex subject, and I would
> like
> > to have a very good understanding of the already "validated" methods such
> as
> > yours.
>
> That's a good  approach. The approach i have chosen is not the best,
> because i did not had the time to think
> long enough about the problematic. I would love to hear about your
> final approach.
> Will pointed out that you should use the
> adaptor framework. I had a look on it and was impressed how flexible
> it is. But for the needs that i had it was not sufficient
> (i think because i did not understand it completely).
> I wanted that all the unstructured grid filter work on my elements and
> integration points and not on a tessellated version of my grid.
> It was also difficult for me to understand how to implement the
> flexibility to use all kind of integration point orders
> (3, 5, 7 ... 20 layers and 1,3,4,6,7 .. 27 integration points per
> layer) connected with different elements with the adaptor framework.
> I did not understand it completely. So i cant tell if the adaptor
> framework is sufficient for those need.
>
> >
> > I thank you again for your help.
> > Best regards,
> >
> > Pierre
> >
> > PS: I opened the file you sent in your previous e-mail in ParaView: if
> I'm
> > correct, there is no mesh, but only integration points? Am I right?
>
> Yes, no mesh is needed. The element type is a POLY_VERTEX.
>
> Best regards
> Soren
>
> ps.:
> Can you please forward this conversation to the VTK dev list, maybe
> others are interested too and have more ideas.
>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20080708/c63750e8/attachment.html>


More information about the vtk-developers mailing list