Unable to visualize Exodus file from sculpt

GregVernon · July 25, 2024, 3:23pm

@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 (107 Bytes)

cube.stl (684 Bytes)

sculpt_overlay.i (391 Bytes)

And then, with all files in the same directory, run:

sculpt.exe -i sculpt_overlay.i

That should export two *.e.1.0 files, which I’ve attached below

sculpt_overlay.e.1.0 (181.4 KB)
vfrac_adapt.e.1.0 (224.1 KB)

If I load either file into ParaView, they appear to be empty (containing no cells, etc.)

and present errors:

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?

GregVernon · July 25, 2024, 9:37pm

It looks like it’s both sculpt and PEBKAC. To document the workaround:

Tools → Manage Plugins
Load the LegacyExodusReader plugin:

image802×632 21.2 KB
When importing the file, choose the ExodusII file type:
et voila

image960×1032 239 KB

@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?

dcthomp · July 25, 2024, 10:25pm

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.

GregVernon · July 26, 2024, 3:17pm

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

cory.quammen · July 29, 2024, 9:39pm

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.

dcthomp · July 29, 2024, 9:49pm

It does look like a bug in VTK, though.

cory.quammen · July 29, 2024, 9:54pm

In the file series identification? Could be. I’ll take a look.

cory.quammen · July 30, 2024, 1:31am

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:

github.com

sandialabs/seacas/blob/master/packages/seacas/libraries/ioss/src/Ioss_Utils.C#L197


      
          std::string Ioss::Utils::decode_filename(const std::string &filename, int processor,
                                                   int num_processors)
          {
            // Current format for per-processor file names is:
            // PREFIX/basename.num_proc.cur_proc
            // the 'cur_proc' field is padded to be the same width as
            // the 'num_proc' field
            // Examples: basename.8.1, basename.64.03, basename.128.001
          
            // Create a std::string containing the total number of processors
            if (num_processors > 1) {
              size_t proc_width = number_width(num_processors);
          
              std::string decoded_filename =
                  fmt::format("{}.{}.{:0{}}", filename, num_processors, processor, proc_width);
              return decoded_filename;
            }
            return filename;
          }
          
          std::string Ioss::Utils::get_trailing_digits(const std::string &name)

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?

cory.quammen · July 31, 2024, 2:53pm

Issue to track this is here: https://gitlab.kitware.com/paraview/paraview/-/issues/22712

Gregory_Sjaardema · August 5, 2024, 7:56pm

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>.<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?

GregVernon · August 5, 2024, 8:55pm

@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.