[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