GID Interface Plugin Material Bug & Workaround

General discussion about Elmer
Post Reply
gos
Posts: 61
Joined: 13 Sep 2011, 21:22
Antispam: Yes

GID Interface Plugin Material Bug & Workaround

Post by gos »

Hello,

I suspect I have found a bug in the GID Interface Plugin (or in the VTK Export ?)

I created a GID file as shown in my previous post. I then exported the results of a simulation to VTK format.
Next, I open the VTK file in Visit 2.3.2 (https://wci.llnl.gov/codes/visit/).

In Visit, it should then be possible to choose which Materials to display: Material 1, 2 or both.

However, before I apply my patch to the VTK file, there is no "materials" in the Subset Dialog to choose materials to hide, only the "domains" entry is present, and it may not be expanded to show any more detail.

However, if you search and replace the following terms in the VTK file,
Search : SCALARS group int32
Replace with: SCALARS materialint32

(see the attached VTK file where the replacement above has been peformed)

the materials will display in the Subset Dialog in Visit, and Material 2 (holes with Air in the recatngle) may be turned off as shown below:
Visit_Materials_Dialog_Material_2_Hidden.JPG
Visit_Materials_Dialog_Material_2_Hidden.JPG (66.2 KiB) Viewed 8556 times
gos
Attachments
vtk_data0001.rar
(10.43 KiB) Downloaded 429 times
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: GID Interface Plugin Material Bug & Workaround

Post by raback »

Hi gos

This was just fixed.

-Peter
gos
Posts: 61
Joined: 13 Sep 2011, 21:22
Antispam: Yes

Re: GID Interface Plugin Material Bug & Workaround

Post by gos »

raback wrote:Hi gos

This was just fixed.

-Peter
Hello,
Thanks Peter, the VTK files now work with Visit.

However, VTU files still have the same problem.

There is also a discrepancy between the names exported in the .SIF file, and the variable names in the VTK / VTU file:

The following variable names are exported to VTK or VTU file:

Solver 3
Equation = Result Output
Single Precision = True
Procedure = "ResultOutputSolve" "ResultOutputSolver"
Output File Name = VTK_Data
Output Format = Vtk
Binary Output = True
Scalar Field 1 = Temperature
Scalar Field 2 = Heat Source
End

The VTK file then lists:

SCALARS Temperature double /* This matches the variable name in the SIF file */
SCALARS Heat.source double /* This DOE NOT match the variable name in the SIF file */

The VTU file then lists:

<DataArray type="Float32" Name="temperature" NumberOfComponents="1" format="appended" offset="0"/> /* Same name as in SIF file, but Case DOES NOT match */
<DataArray type="Float32" Name="heat source" NumberOfComponents="1" format="appended" offset="556"/> /* Same name as in SIF file, but Case DOES NOT match */

Visit is case sensitive, so this leads to problems when I use scripts to process the files...

Suggested Solution:

It would be very nice if the names in the SIF file would be reproduced exactly in the VTK & VTU files.


gos
Franz Pichler
Posts: 196
Joined: 29 Sep 2011, 12:25
Antispam: Yes

Re: GID Interface Plugin Material Bug & Workaround

Post by Franz Pichler »

Hello.

I would be interested in the material 101 in the screenshot.
i use paraview to view my results and have the materials and also have two materials 101 and 102 which somehow belong to the boundary conditions i think. not sure tho.

any ideas?

thx
Franz
gos
Posts: 61
Joined: 13 Sep 2011, 21:22
Antispam: Yes

Re: GID Interface Plugin Material Bug & Workaround

Post by gos »

Franz Pichler wrote:Hello.

I would be interested in the material 101 in the screenshot.
i use paraview to view my results and have the materials and also have two materials 101 and 102 which somehow belong to the boundary conditions i think. not sure tho.
any ideas?
Hello Franz,

In GID, when assigning boundary conditions to the Rectangle that constitute the material of the Slab, I assigned the Index number 1 to the the Boundary: Somehow, they end up as index 101 in Visit, and obviously in Paraview. Further, when I also assigning Boundary Index 2 to the holes, they end up as index 102 in Visit.

I also tried to assign index 1-4 to the separate sides of a non-rectangular shape, but the boundary shows up as index 101 in Visit.

gos
cemg
Posts: 26
Joined: 02 Feb 2012, 17:41
Antispam: Yes
Location: Vigo, Spain

Re: GID Interface Plugin Material Bug & Workaround

Post by cemg »

Hello,

as you can see, the vtk output format "writer" (module VtkLegacyFile, inside ResultOutputSolver.src) sets the bc ids starting in 101 (line 2128 of the previous file). This is (probably) because the vtk file format treats the ids of domains and boundaries the same way (and they must be identified with different labels if you want to use its ids as a filter).

Anyway, let me say that setting the first boundary id to 101 its not a good solution, because this limits the domains to 100 (I've found all this trying to debug a postprocessing methodology for a problem with more than 100 domains), but I can't suggest a better solution, so...

Regards,

Cesar
Last edited by cemg on 23 Apr 2012, 09:48, edited 1 time in total.
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: GID Interface Plugin Material Bug & Workaround

Post by raback »

Hi

Any suggestion what would be a better idea? Add 1000? Start numbering from max body Id? We are limited to positive integers so there isn't really any other choice than to add some offset.

-Peter
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: GID Interface Plugin Material Bug & Workaround

Post by raback »

Ok, as a quick remedy for cases with huge number of bodies I added the following lines

Code: Select all

        BCOffset = 100
        DO WHILE( BCOffset <= Model % NumberOfBodies ) 
          BCOffset = 10 * BCOffset
        END DO
It is backward compatible for cases with less than 100 bodies.

-Peter
cemg
Posts: 26
Joined: 02 Feb 2012, 17:41
Antispam: Yes
Location: Vigo, Spain

Re: GID Interface Plugin Material Bug & Workaround

Post by cemg »

Thank you, Peter.

Regards,

Cesar
Post Reply