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