[Paraview] Exodus ii vs Xmdf for Paraview for finite elements post-processing

Samuel Key samuelkey at bresnan.net
Sat May 5 11:32:22 EDT 2018


Paul,

My own simulation software allows non-sequential, but unique assignment 
of user-specified ID's for Points and Cells. (It is user friendly, and 
requires and provides a wealth of datum checking to see if the input 
datum set is logically connected.)

For what it is worth, the EnSight format supports user-assigned Point 
and Cell ID's.

HOWEVER, the ParaView EnSight Reader which in all other respects appears 
to be bullet proof and supports arbitrary n-vertex polyhedral finite 
elements that my software uses, simply skips the reading and storing of 
the user-assigned Point and Cell ID's.

(I rely heavily on ParaView for post processing and will continue to  
write out the Point and Cell ID's to the EnSight-formatted simulation 
datum set in the hope that some day ParaView will accept and make use of 
the Point and Cell ID's. )

A possible solution may be the following for identifying Cells -- my 
software writes out Material Model user-assigned ID's "MatID" as Cell 
data. The software's EnSight Writer uses the EnSight Part-construct to 
create a "graphically displayable object" for each domain based on a 
common value for MatID. The user, planning ahead, can artificially give 
one or more Cells a unique MatID. Then ParaView's Extract Block filter 
allows any combination of material domains to be selected for further 
processing/examination.

The attached image is a two-cell example. (Two independent finite 
elements with different Mat ID's and the same material properties but 
with different large-strain formulations each subjected to the same 
strain loop).

Sam Key


On 5/5/2018 3:10 AM, paul.carrico at free.fr wrote:
>
> Dear All,
>
> This email is an echo of a previous one where I noticed that for XDMF 
> format, Node Id and Element one are not explicitely provided (for 
> performance issue I guess); writing an interface for renumbering 
> topology (connectivity), datasets and so on is not a problem by itself 
> (jus more work), but rather the fact that information's are lost 
> (information's from the solver based on the original mesh for example).
>
> Thus I'm having a look to Exodus ii format and how I can use y h5 file 
> (through netCDF I guess and not directly) ... if I'm right it allows 
> nodes/elements Id's.
>
> Compared to Xdmf, does somebody want to share his 
> feedback? (limitations, implementation, performance, parallelisation, 
> and so on)
>
> Thanks for any help
>
> Regards
>
> Paul
>
>
>
>
> _______________________________________________
> 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:
> https://public.kitware.com/mailman/listinfo/paraview

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/paraview/attachments/20180505/af196449/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vp121-C0-2Cycle-Closed-Strain-Loop-Hypo-vs-Hyper-mat-models.png
Type: image/png
Size: 154407 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/paraview/attachments/20180505/af196449/attachment.png>


More information about the ParaView mailing list