Inconsistencies between element numbering in Cubit and Exodus files

Coreform Cubit Importing/Exporting
#1

Hello,

I’m currently trying to implement a mesh refinement procedure for a tetrahedral mesh based on the mesh refinement tools detailed here: Mesh Refinement. However, I’m running into some issues where the element numbers between Cubit files and Exodus files I’m exporting within the same session are inconsistent.

Here is my current procedure:

  1. Save the Cubit file and Exodus file for the initial mesh
  2. Load the mesh info from the exodus file into my codebase, solve the underlying problem in my codebase, perform an error estimate, and select a set of elements to refine based on that estimate.
  3. Load the Cubit file back into cubit, refine those elements, compress the element numbers, and export new Exodus and Cubit files.

The problem that I’m having is that I need both the Exodus and Cubit files so that I can load mesh information into my code and retain the geometry information, but I have found that the element numbers are inconsistent between the two.

microstrip_coarse.cub5 (433.1 KB)
microstrip_coarse.e (443.4 KB)
cubit03.jou (438 Bytes)

I’ve attached some files above to show an example of this. I start with the initial mesh microstrip_coarse.e with Cubit file microstrip_coarse.cub5, which appear to have matching numbers as far as I can tell. I then run my code, which is followed by the Cubit refinement process (with commands in cubit03.jou).

microstrip_coarse_1.e (144.7 KB)
microstrip_coarse_1.cub5 (417.0 KB)
cubit04.jou (444 Bytes)

This outputs microstrip_coarse_1.cub5 and microstrip_coarse_1.e, which I’ve included above. I then repeat the same process, for which the cubit steps are again provided in cubit04.jou.

In this case though, I find that I wind up refining the wrong elements. If I load microstrip_coarse_1.e into Cubit and select tets 419 294 600 542 295 206 (all the ones I want to refine), I see the following:

image
image358×666 20.4 KB

However, if I load microstrip_coarse_1.cub5 file in and select the same tets, I get a completely different set:

image
image299×588 17.4 KB

This is clearly not the same set of tets, but I don’t understand why it would be different. Is there some command I need to be using to prevent this behavior? Or is there a way I could modify my process to avoid it altogether? I tried using exodus files exclusively, but it produced issues on more complicated geometries since the meshed-based geometry doesn’t accurately represent the curved features of the actual geometry.

Thanks in advance for your help, and please let me know if any additional information is needed.

#2

Hi @selkin,
i have seen that you used blocks to export faces while you already exported the tets in different blocks.
Please use sidesets if you want to group faces for the use of boundary conditions, ect.

When i delete all blocks containing only faces and create a sideset for them, i got no issue with the ids.

delete block 3 to 7
sideset 1 add surface 5 6 7 8 9 10
sideset 1 name "PEC0"

Can you try if using sidesets for faces instead of blocks fixes your issue?

#3

Hi @Norbert_Hofbauer,

Thanks for the response! We’re currently adapting our code to work with sidesets instead of blocks. I’ll let you know if we have any issues once we get that functionality operational.

Thanks again,

Sam Elkin

#4

Hi @Norbert_Hofbauer,

Sorry for the long delay in getting back to you on this, something else took priority for a bit and we had to take a step back from this project.

Unfortunately, using sidesets doesn’t seem to fix this problem. Similarly to the prior case, we generate an initial mesh and cubit file, and the numbering on these seems to agree. These files are attached below:
microstrip_coarse_sidesets.cub5 (421.2 KB)
microstrip_coarse_sidesets.e (142.9 KB)

We select a set of tets with IDs 1200, 2000, 3000, 3200, 3400, and these visually appear to be the same between the two files:

.cub5 file:
image

.e file:
image

We then generate the mesh and cubit file for the following adaptive pass using the commands in this bash script:
cubit01.jou (448 Bytes)
microstrip_coarse_sidesets_1.e (181.1 KB)
microstrip_coarse_sidesets_1.cub5 (464.4 KB)

As before, we find that the resulting files (see above) have inconsistent numbering. Selecting the same set of tets (IDs 1200, 2000, 3000, 3200, 3400), the results are clearly different:

.cub5 file:
image

.e file:
image

Since this was all done with sidesets, it seems like this isn’t the source of the issue. Do you have any other ideas as to what’s going wrong. We’re a bit confused given that things are working fine for the initial mesh and we only see these problems after refining that mesh, so it seems like we’re probably just doing something silly. Hopefully you can help us determine what that might be. Thanks in advance for your help!

#5

Hi @Norbert_Hofbauer,

Sorry for the double ping, I just wanted to check in to see if you’ve had a chance to take a look at this. Thanks in advance for your help!

-Sam Elkin