With 4C-multiphysics/4C#1763 4C will be able to read beam elements from external mesh formats. Once that is done BeamMe should be adapted such that it can create input files and mesh files separately, allowing for a possible much more efficient data storage.
The question now is which format(s) do we want to support for internal representation in BeamMe and export formats (don't have to be the same). Internally I think that vtu makes the most sense, as we need it anyways for the PyVista view functionality and export to ParaView. Export format is not as clear to me, vtu should work (almost) straight away. However, the most common use case for very large mesh data in BeamMe is when there are a lot of solid elements coming from Cubit in the exodus format. It is worth checking out if we can simply append the beams (or solids) created in BeamMe to the exodus file from Cubit, so we don't have to read in and convert the whole Cubit mesh.
Edit: Also, if we can define a suitable internal representation in vtu, we could use that for comparison in most tests, without having to resort to 4C input files.
With 4C-multiphysics/4C#1763 4C will be able to read beam elements from external mesh formats. Once that is done BeamMe should be adapted such that it can create input files and mesh files separately, allowing for a possible much more efficient data storage.
The question now is which format(s) do we want to support for internal representation in BeamMe and export formats (don't have to be the same). Internally I think that vtu makes the most sense, as we need it anyways for the PyVista view functionality and export to ParaView. Export format is not as clear to me, vtu should work (almost) straight away. However, the most common use case for very large mesh data in BeamMe is when there are a lot of solid elements coming from Cubit in the exodus format. It is worth checking out if we can simply append the beams (or solids) created in BeamMe to the exodus file from Cubit, so we don't have to read in and convert the whole Cubit mesh.
Edit: Also, if we can define a suitable internal representation in vtu, we could use that for comparison in most tests, without having to resort to 4C input files.