The displacement becomes unnatural due to a node specific to COQUE_3D.
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- cpp
- Domain
- data-visualization
Research direction
Start with the attached AttachedFile.zip, including the .rmed output and .comm script, and reproduce the COQUE_3D display in ParaView. Then trace MEDReader's handling of TRIA7 and QUAD9 displacement data, comparing DEPL with SIEQ and SIGM in SpreadSheetView. Done means the displayed DEPL distribution is correct for the additional element nodes.
Written by the indexing model from the issue text.
Description
I am a user from Japan. Please forgive me if my English is inappropriate.
I am very grateful for MEDReader.
I have found a bug in the MEDReader plugin.
I think, it is a bug specific to the shell element known as COQUE_3D.
Environment in use
- paraview ver 6.1.1
- SalomeMeca2024
- Ubuntu 24.04.4 LTS
The meshes for COQUE_3D consist of TRIA7 (triangular) and QUAD9 (quadrilateral) elements; unlike standard quadratic elements (TRIA6 and QUAD8), these include an additional 7th and 9th node, respectively.
When I load and display the output file (rmed) from SalomeMeca, the DEPL (displacement) shows a strange distribution.
I suspect this is because the DEPL values for nodes 7 and 9 are zero, yet those nodes are being displayed.
For quantities such as SIEQ and SIGM (i.e., those other than DEPL), the Code_Aster (comm) commands convert element-based solutions to nodal-based solutions; however, since DEPL is inherently a nodal solution, no conversion is required.
When examining the data using ParaView's SpreadSheetView, I found that for variables such as SIEQ and SIGM (i.e., those other than DEPL), appropriate values are output for the 7th and 9th nodes upon conversion from element-based solutions to node-based solutions.
my regards
I am attaching the output file (.rmed) and the Aster code (.comm).
AttachedFile.zip
- Dominant language
- C++
- Stars
- 1
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SalomePlatform/medreader
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
SalomePlatform/medreader#5 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
SalomePlatform/medreader#1 · 5 comments ·
All issues in SalomePlatform/medreader
Similar issues
-
`enzymexla.linalg.lu` lowering fails for a tall matrix: the permutation is built with the pivot typeOpen
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
EnzymeAD/Enzyme-JAX#3286 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
apache/iceberg-cpp#973 ·
Maintainers usually reply within 1 day
-
feature request
Difficulty 1/5 Under an hour Newbie friendliness 86/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day