Unable to Reload Saved .cub, .cub5, or .msh Files in Cubit 2025.8 - ERROR: Referenced vertex not found

[huryk706]

Hello Coreform Team and Community,

I recently purchased and started using Coreform Cubit 2025.8. I am encountering a critical issue when attempting to reload files that I have just saved.

Problem Description

After creating a new model and saving it as a .cub file (or a .cub5 file), when I try to open the saved file immediately afterward, the load operation fails, and the following error code is displayed:

Geometry engine set to: ACIS Version 33.0.0.0 ERROR: Referenced vertex not found. Mesh could not be restored. ***Please validate the geometry model.*** ERROR: Command Failed.

I also saved the mesh as an .msh file and tried to reload the original Cubit file, but the same error occurs with both .cub and .cub5 formats.

Key Observation

Interestingly, the **exported .msh file opens perfectly fine in ANSYS Fluent (or other external solvers), which indicates that the mesh data itself is complete and not corrupted. The issue seems to be with how Coreform Cubit is saving or recalling the **link between the geometry and the mesh (or the mesh connectivity) when reading its native file formats (.cub/.cub5).

Questions

1. What could be the underlying reason for Coreform Cubit failing to restore the mesh (specifically the Referenced vertex not found error) immediately after a successful save in the same session?
2. Is this a known bug in version 2025.8, or is there a specific command or setting I might be missing during the saving process?
3. What are the suggested troubleshooting steps or workarounds to resolve this issue?

Thank you for your time and assistance in helping me resolve this problem. I appreciate your support.

[kgmerkley]

Can you give the set of commands that you used to arrive that this error? I’m running 2025.8 and I run the following set of commands, trying a set of different things to replicate the issue.

1. Create hex, tet, and pyramid elements in the same model
2. Export to fluent
3. Write to a .cub find and a .cub5 file
   None of these steps replicate your problem. My test journal file is included below.

Your help identifying this problem is appreciated!

Karl

reset
brick x 10
volume 1 copy move x 10
imprint all
merge all 
mesh vol 1
volume 2 scheme tetmesh
mesh vol 2
export fluent 'junk.msh' overwrite
save as 'junk.cub' overwrite
save cub5 'junk.cub5' overwrite
reset
open 'junk.cub'
reset
open 'junk.cub5'

[huryk706]

Hi Karl,

Thanks a lot for taking the time to reproduce my steps and share the journal file.

I just wanted to report back that the issue is now resolved, and it turned out not to be a problem with the journal or the CUB5 export itself, but with my Windows TEMP path.

My Windows user name is in Korean, so the default TEMP directory was:

C:\Users\윤규\AppData\Local\Temp

When opening the .cub5 file, Cubit wrote a temporary file like CBTxxxx.tmp into that folder, but ACIS consistently failed to read it and printed:

did not read anything from the input file ‘C:\Users\윤규\AppData\Local\Temp\CBTxxxx.tmp’
You may be trying to read a file that is from an Acis version newer than you are using.
Referenced vertex not found. Mesh could not be restored.

As a test, I launched Cubit from a batch file that first sets:

set TEMP=C:\CubitTemp
set TMP=C:\CubitTemp

With TEMP/TMP pointing to C:\CubitTemp (ASCII-only path), the same .cub5 file opens without any errors.
After that, I changed my user TEMP/TMP environment variables in Windows to C:\CubitTemp, and now Cubit works fine even when I start it normally from the shortcut.

So it looks like ACIS (or the CUB5 read path) has trouble when the TEMP directory contains non-ASCII characters in the user name. Changing TEMP/TMP to an English-only path is a reliable workaround.

Posting this here in case it helps others who might run into the same issue.
Thanks again for your help and for checking the workflow on your side!

[kgmerkley]

Thank you for your report. We should be using the UTF-8 character set everywhere. That would support the Korean character set as well. I will do an audit of the code to make sure we aren’t assuming Latin characters anywhere especially in the Open/Save dialogs.

Karl

[kgmerkley]

Hi @huryk706,

I created a directory on my machine named C:/Users/kgmer/AppData/테스트_임시폴더. I am able to save and open .cub5 files, .cub files and .sat files. I can also set this directory as my current working directory.

Do you have any suggestions for what else I should be testing to determine the root cause of the problem?

Thanks,
Karl

[huryk706]

Hi Karl,

Thanks again for digging into this and for testing with the Korean folder name.

I think the key difference in my case is that the problem is not related to the directory where I save/open the .cub5 file, but specifically to the TEMP directory that Cubit/ACIS uses for the CBTxxxx.tmp file.

In your test, your Windows user name and default TEMP path are probably ASCII-only (something like C:\Users\kgmer\AppData\Local\Temp), and only the working directory C:\Users\kgmer\AppData\테스트_임시폴더 contains non-ASCII characters. In my environment, the non-ASCII characters are in the user profile part of the TEMP path itself.

My setup is:

• Coreform Cubit: 2025.8
• ACIS: 33.0.0.0 (from the log)
• Windows with Korean user name
• User profile folder:
  C:\Users\윤규
• Default TEMP/TMP:
  C:\Users\윤규\AppData\Local\Temp

Symptoms:

• Saving .cub, .cub5, and exporting Fluent all work.
• Opening .cub works.
• Opening the same .cub5 fails with:

ERROR: did not read anything from the input file
C:\Users\윤규\AppData\Local\Temp\CBTxxxx.tmp
You may be trying to read a file that is from an Acis version newer than you are using.
ERROR: Referenced vertex not found. Mesh could not be restored.

Workarounds I confirmed:

• If I start Cubit from a command prompt with:

set TEMP=D:\CubitTemp
set TMP=D:\CubitTemp
"D:\Program Files\Coreform Cubit 2025.8\bin\coreform_cubit.exe"

then the exact same .cub5 file opens without any errors.

• If I set my user TEMP/TMP environment variables in Windows to D:\CubitTemp (ASCII-only path), Cubit also works fine when I launch it normally from the shortcut.

So the failure seems to depend only on whether the TEMP directory path contains non-ASCII characters, not on the working directory or the path where the .cub5 itself is stored. Once TEMP/TMP are moved to an ASCII-only path, .cub5 open/restore works reliably.

If you want to try to reproduce it more closely, maybe you could:

1. Temporarily set your user TEMP and TMP to a path that includes non-ASCII characters, for example:
   C:\Users\kgmer\AppData\테스트_임시폴더\임시
   log out and log back in, then run Cubit 2025.8 and open a .cub5 file.
2. Or start Cubit from a command prompt where you manually set:

set TEMP=C:\Users\kgmer\AppData\테스트_임시폴더\임시
set TMP=C:\Users\kgmer\AppData\테스트_임시폴더\임시
"C:\Program Files\Coreform Cubit 2025.8\bin\coreform_cubit.exe"

and then open a .cub5.

My guess (from the outside) is that the code path which writes and then passes the CBTxxxx.tmp file name to ACIS may still be assuming a Latin/ANSI encoding somewhere, whereas the open/save dialogs and working directory handling are already fully Unicode/UTF-8 aware. That might explain why your test with a Korean working directory succeeds, but my case with a Korean TEMP path fails.

I hope this helps narrow down the root cause.

Thanks again for your help