VtkData has_cell_data function uses wrong function to get the number of arrays

[javijv4]

Description

The function VtkVtpData::has_cell_data and VtkVtuData::has_cell_data (lines 801 and 1060 in VtkData.cpp) define the number of arrays as:

int num_arrays = impl->vtk_ugrid->GetPointData()->GetNumberOfArrays();

when it should be

int num_arrays = impl->vtk_polydata->GetCellData()->GetNumberOfArrays();

Reproduction

There is currently no test that checks the implementation. These functions are called when a domain is specified using a .vtu or .vtp file.

Expected behavior

Change the code in VtkData.cpp to use GetCellData().
Should we add a test? Maybe the one @msbazzi sent in #363. I can modify the one I added in #504 to use .vtu. That way, we would have a solid and EP test of this.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

[ktbolt]

@javijv4 The more tests the better !

[javijv4]

I am working in this branch.

Fixed the bug and added the FSI example. The EP example fails if the domains are read using a .vtu file. I will try to identify the issue next.

[ktbolt]

@javijv4 What is the EP example ?

[javijv4]

@ktbolt, this mwe.zip. It's the same as in tests/cases/cep/slab_domains. It works with a .dat file but not with a .vtu file. When I try using the .vtu file, the residuals and solutions are all zeros, which probably means the domains are not being read and the solver is not doing anything.

[ktbolt]

@javijv4 I just ran tests/cases/cep/slab_domains with a .vtu file

with and it seemed to work ok; matched the results from the domain text file.

[javijv4]

@ktbolt, ah! I had created the domainIDs.vtu using int64, which is why it wasn't working. I was able to get it working using int32. I will update this test and create a pull request.

[ktbolt]

@javijv4 Yes, I was wondering if it was the Int64 most-annoying-thing-ever problem.

[ktbolt]

@javijv4 I am going to try to fix this I think; see #490.

[javijv4]

@ktbolt, fixing it would be great! I think we'll avoid a lot of debugging time for no reason.