Improve usage of type converter when dumping to input file

[isteinbrecher]

As discussed here, the way we use custom type converting when dumping to an input file should be reworked
#446 (comment)

• Introduce own BeamMe type converter
• Apply the custom type converter selectively only at places where we know that there might be the need for type conversion
• Check if this can also be applied to CubitPy Adapt performance test time of cubit #570 (comment)

[davidrudlstorfer]

If I remember correctly we currently convert the stuff during the addition to the input file, we could also think about only converting once we dump the file.

This would probably need a small change in FourCIPP because currently each item is automatically converted during the addition.

If we could cope with the performance degradation we could also just enable the conversion to happen twice, i.e., during the addition and during dumping (this is currently hardcoded to false). Then we would need no additional changes in FourCIPP

[isteinbrecher]

If I remember correctly we currently convert the stuff during the addition to the input file, we could also think about only converting once we dump the file.

Yes, that is the current behaviour. I would not want to change this, because at the moment we require a Mesh object to be in an operational state when adding to the input file. Could be that the mesh is then used in a different way, modifying the underlying objects and leading to unwanted results if the conversion is only done later on.

If we could cope with the performance degradation we could also just enable the conversion to happen twice, i.e., during the addition and during dumping (this is currently hardcoded to false). Then we would need no additional changes in FourCIPP

It depends on what data is converted multiple times conversion. If during InputFile.add, we apply the conversion to the added data and then finally during InputFile.dump to the full data, I think that this would be no issue performance wise. What I would like to avoid is that during InputFile.add we apply the conversion to the full data currently contained in the InputFile - because we know that this data is already converted - and I think that would have the performance of $\mathcal{O}(n^2)$.

[isteinbrecher]

I added some todos to the issue description.