However, this is quite intrusive for people, who are not familiar with deal.II and the code. deal.II has the GridIn class in order to read mesh files from the filesystem and we should try to make it compatible with our solver codes. This will only work for hexahedral meshes so far.
In a best case scenario, we could create a separate class, which can be used in both solver codes. As an alternative, one could directly replace the make_grid code by some GridIn function. Important will be the setting of the boundary IDs in order to apply proper boundary conditions. If setting the boundary IDs through the mesh file fails, we can add additional parameters in the parameter file in order to handle this parametrized.
As a first step, we could try to run one of our tutorial cases with an external mesh, e.g., the flap.
Right now, the grid generation is hard-coded in the solver codes, with some refinement parameters in the parameter file
https://github.com/precice/dealii-adapter/blob/dbb25bea51531b7e4e0c9b5e4def3a7fadf8367c/source/nonlinear_elasticity/nonlinear_elasticity.cc#L163
However, this is quite intrusive for people, who are not familiar with deal.II and the code. deal.II has the GridIn class in order to read mesh files from the filesystem and we should try to make it compatible with our solver codes. This will only work for hexahedral meshes so far.
In a best case scenario, we could create a separate class, which can be used in both solver codes. As an alternative, one could directly replace the
make_gridcode by someGridInfunction. Important will be the setting of the boundary IDs in order to apply proper boundary conditions. If setting the boundary IDs through the mesh file fails, we can add additional parameters in the parameter file in order to handle this parametrized.As a first step, we could try to run one of our tutorial cases with an external mesh, e.g., the flap.