# Unable to visualize Exodus file from sculpt
**URL:** https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121
**Category:** ParaView Support
**Created:** [July 25, 2024, 3:23pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121 "2024-07-25T15:23:42Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@GregVernon](https://discourse.paraview.org/u/GregVernon)
#### Post date: [July 25, 2024, 3:23pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/1 "2024-07-25T15:23:42Z")
@wascott - this might be relevant to Sandia. We have a user who posted a question on our forum… if I run the below `sculpt_overlay.i` file in the `sculpt` distributed with Coreform Cubit 2024.3 it seems to not import into ParaView 5.12.0. To replicate, download the three files below:
[sculpt\_overlay.diatom](https://discourse.paraview.org/uploads/short-url/gyKFuMjOkPwwczGYHPbNzzsaFi2.diatom) (107 Bytes)
[cube.stl](https://discourse.paraview.org/uploads/short-url/vV09z8CpOrK6G702vVsi3gposap.stl) (684 Bytes)
[sculpt\_overlay.i](https://discourse.paraview.org/uploads/short-url/cbsWnPCAqnY7GVOB1ZQahUUXXqn.i) (391 Bytes)
And then, with all files in the same directory, run:
```auto
sculpt.exe -i sculpt_overlay.i
```
That should export two `*.e.1.0` files, which I’ve attached below
- [sculpt\_overlay.e.1.0](https://discourse.paraview.org/uploads/short-url/81xqfYj7gSMnc6KxlMq3zAWhwdo.0) (181.4 KB)
- [vfrac\_adapt.e.1.0](https://discourse.paraview.org/uploads/short-url/j8zQaw8FbsMZ5IaMU38jwzOjFpB.0) (224.1 KB)
If I load either file into ParaView, they appear to be empty (containing no cells, etc.)
and present errors:
```auto
ERROR: In vtkIOSSReader.cxx, line 946
vtkIOSSReader (0000023B0C987400): Error in UpdateTimeInformation:
Failed to open database C:/Users/Owner/Documents/CubitTemp/SculptScratch/forum_tux/sculpt_overlay.e
ERROR: In vtkExecutive.cxx, line 730
vtkPVCompositeDataPipeline (0000023B0C6A9380): Algorithm vtkIOSSReader (0000023B0C987400) returned failure for request: vtkInformation (0000023B0F5F08B0)
Debug: Off
Modified Time: 423810
Reference Count: 1
Registered Events: (none)
Request: REQUEST_INFORMATION
FORWARD_DIRECTION: 0
ALGORITHM_AFTER_FORWARD: 1
ERROR: In vtkExecutive.cxx, line 730
vtkPVCompositeDataPipeline (0000023B0C6A9380): Algorithm vtkIOSSReader (0000023B0C987400) returned failure for request: vtkInformation (0000023B2976D610)
Debug: Off
Modified Time: 507690
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA
FORWARD_DIRECTION: 0
ALGORITHM_AFTER_FORWARD: 1
FROM_OUTPUT_PORT: 0
```
However, they can be imported back into Coreform Cubit, so they appear valid:
Is this something that we need to address on the `sculpt` side of things, a bug in the ParaView/VTK side of things, or is this [PEBKAC](https://en.wiktionary.org/wiki/PEBKAC#English)?
---
### Author:  [@GregVernon](https://discourse.paraview.org/u/GregVernon)
#### Post date: [July 25, 2024, 9:37pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/2 "2024-07-25T21:37:27Z")
It looks like it’s both `sculpt` and PEBKAC. To document the workaround:
1. `Tools` → `Manage Plugins`
2. Load the `LegacyExodusReader` plugin:
3. When importing the file, choose the `ExodusII` file type:
4. _et voila_
@cory.quammen – If one wanted to look to find information about how to update our tool to export Exodus files that are compatible with the (new?) IOSS readers, where’s the best place to look?
---
### Author:  [@dcthomp](https://discourse.paraview.org/u/dcthomp)
#### Post date: [July 25, 2024, 10:25pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/3 "2024-07-25T22:25:28Z")
I am able to load your examples simply by renaming them. Remove the `.1.0` from each file and try again. The final number (`0` in this case) should be ≥ the prior numbers.
There should probably be a bug report as we should still be able to load improperly named files. It may be a bug in VTK’s file-series reader rather than the ioss reader itself.
---
### Author:  [@GregVernon](https://discourse.paraview.org/u/GregVernon)
#### Post date: [July 26, 2024, 3:17pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/4 "2024-07-26T15:17:10Z")
Hmm… well that is interesting. However, regarding the `.X.Y` – I do believe it is Exodus convention for `X = num_partitions` and `Y = partition_id`, for example:
- `my_exodus.3.0`
- `my_exodus.3.1`
- `my_exodus.3.2`
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [July 29, 2024, 9:39pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/5 "2024-07-29T21:39:20Z")
> [@GregVernon](#):
>
> If one wanted to look to find information about how to update our tool to export Exodus files that are compatible with the (new?) IOSS readers, where’s the best place to look?
Looks like @dcthomp provided the useful info here. There really shouldn’t be any changes needed (and hence no documentation for what you need to change) as the IOSS-based Exodus reader is intended to read Exodus files produced long before it existed.
---
### Author:  [@dcthomp](https://discourse.paraview.org/u/dcthomp)
#### Post date: [July 29, 2024, 9:49pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/6 "2024-07-29T21:49:25Z")
It does look like a bug in VTK, though.
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [July 29, 2024, 9:54pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/7 "2024-07-29T21:54:20Z")
In the file series identification? Could be. I’ll take a look.
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [July 30, 2024, 1:31am UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/8 "2024-07-30T01:31:42Z")
The file series identification works properly with these single files, identifying that there is 1 partition and that the file corresponds to partition 0. Tracing this through to the IOSS library, I came across a conditional that fails in this scenario:
>
Since `num_processors` is equal to 1 instead of greater than 1, the block of code that appends the number or processes and the process number to the base file is skipped, leaving the decoded name as the base file name. This file of course does not exist, hence the error messages you are seeing.
If I modify that conditional on `Ioss_Utils.C` to read `if (num_processors >= 1) {` and recompile ParaView, the files load no problem.
I’d like to get @Gregory_Sjaardema 's input on this - should IOSS handle these single data files following the parallel naming conventions? Or should ParaView do something special in this case?
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [July 31, 2024, 2:53pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/9 "2024-07-31T14:53:12Z")
Issue to track this is here: [https://gitlab.kitware.com/paraview/paraview/-/issues/22712](https://gitlab.kitware.com/paraview/paraview/-/issues/22712)
---
### Author:  [@Gregory\_Sjaardema](https://discourse.paraview.org/u/Gregory_Sjaardema)
#### Post date: [August 5, 2024, 7:56pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/10 "2024-08-05T19:56:05Z")
That is the (unwritten) convention for “decomposed file-per-rank” files. I haven’t seen anyone use it for undecomposed files before. We can probably make it work, but I would also contact the generator of the file to see why they are using this since it is confusing and adds no information.
In the file-per-rank decomposed files (#ranks \> 1), the file.\<#rank\>.\ case, I know that these files are the result of a parallel decomposition for \<#rank\> ranks and that the files contain the extra communication data that is needed to set up communication maps.
I also know that the user wants to run that file on \<#ranks\> ranks and is not valid for any other rank count for the analysis code.
I can support this case since it logically follows the #rank\>1 cases, but then do I logically also follow that this file can be used on one and only 1 rank analyses?
Also what convention should be followed when/if a user takes this file and decomposes if for, for example, 4 ranks… Are the decomposed files named file.e.1.0.4.0 … file.e.1.0.4.3?
---
### Author:  [@GregVernon](https://discourse.paraview.org/u/GregVernon)
#### Post date: [August 5, 2024, 8:55pm UTC](https://discourse.paraview.org/t/unable-to-visualize-exodus-file-from-sculpt/15121/11 "2024-08-05T20:55:48Z")
@Gregory_Sjaardema – it appears that `sculpt` produces files in this unwritten convention if run on one core. I’ll start a discussion with Sandia development team to see if they’d be on-board with revising this behavior.