Closed wgyang closed 17 hours ago
@wgyang Please upload all of the files needed to run a simulation so I can test.
@wgyang Please upload all of the files needed to run a simulation so I can test.
I modified my original post to include the mesh and input files.
The problem was that the read_vtp()
function was expecting to read a VTP file for some reason.
I've added a check for a VTU file inread_vtp()
and added a load_vtu()
function that works with faces. I also needed to add vtk_xml_parser
functions to store vtkUnstructuredGrid
data into a face.
The simulation now runs but svFSIplus results don't match the Fortran results.
I've fixed several bugs
A bug fest for sure!
So after fixing the .inp and .xml solver files to have the same parameters the C++ and Fortran code produce the same results.
@ktbolt Thank you Dave!! I can add this example to the test cases once you merge your fix into the main branch.
Thank Q @wgyang, allowed me to find several important bugs.
Description
When a high order mesh is used, the face mesh cannot be represented by vtp file. It should be written in an unstructured grid (vtu) file. svFSIplus uses load_vtp to read face files leading to an error when a high-order element mesh is used, for example, a curved quadratic triangle mesh. The P2 surface meshes used in the block compression test in svFSI-Tests are incorrect as they are written in vtp files. The figure below shows the face vtp file.
To support true high-order element meshes, function read_vtp needs to accept mshtype as input in addition to face type when it reads face files.
Reproduction
A tet10 mesh, svFSI.inp, and svFSI.xml are attached below for testing. tet10_test.zip
Expected behavior
svFSIplus can read and output the high-order meshes it supports.
Additional context
No response
Code of Conduct