GID Interface Plugin Material Bug & Workaround

[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 (66.2 KiB) Viewed 488 times

gos

[raback]

Hi gos

This was just fixed.

-Peter

[gos]

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]

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]

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]

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

[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]

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]

Thank you, Peter.

Regards,

Cesar