Utilize FourCIPP in MeshPy

[davidrudlstorfer]

Utilize FourCIPP in MeshPy (the input file inherits from it and also the testing uses a ready-to-use function from FourCIPP)

[davidrudlstorfer]

(Only the second commit is crucial - the first commit is from #348)

[davidrudlstorfer]

Sorry for the chaos - got it working locally - I am missing something somewhere

[davidrudlstorfer]

This was one really dumb typo on the fourcipp side ... Now everything works as expected. No more type casting needed for any numpy type and our functions can also be automatically converted everywhere.

[davidrudlstorfer]

@isteinbrecher now this would also be ready from a FourCIPP converter perspective. Now nothing should change anymore - therefore, now it's completely ready for review:)

[isteinbrecher]

Thanks a lot for the changes @davidrudlstorfer ! This was actually very easy to review considering the complexity.

I really like how using the FourCIPP data structures simplifies a lot of the implementation in MeshPy BeamMe.

Some of my raised points can also be tackles in follow up PRs. We can shortly discuss this in the threads and open issues if we think this is the better way to go.

I am getting very used to the new interface!

[davidrudlstorfer]

@isteinbrecher this would be ready for your review again.

I left four comments open for discussion and fixed the one thing. The remaining points should probably be tackled in separate PR's as they are already documented in the corresponding issue (testing tolerances, ...)

[davidrudlstorfer]

With 4C-multiphysics/fourcipp#50 being merged I've switched back FourCIPP to the main repo again:)

Therefore, this would be finally ready:)

[davidrudlstorfer]

I've copied the ToDo's from #348 (comment)






• nurbs: fix dump_to_list functions to be compatible with fourcipp

• fourcipp: Once the nurbs stuff is fixed we must remove the function is_fourcipp_available

• fourcipp: a dumper for numpy types (arrays, floats, ints, booleans) will be added soon. Therefore, I would keep the int/float/list comparison for now in the dump_to_list functions and remove it soon from MeshPy. See Add converter to convert data to native Python data types 4C-multiphysics/fourcipp#50 and Utilize FourCIPP in MeshPy #354

• currently the overwrite option is gone, this is not as easily implementable because one does actually not know what should be overwritten? If there is a plausible solution to this we can add it to FourCIPP we discussed that this feature is not necessary

• can we finally delete the tutorial or should be wait longer?
 Create an issue for that Already documented in Rethink tutorials for MeshPy #171

After these things are fixed I would merge this and I noted the following clean-ups after this PR

• improve testing infrastructure (test abaqus input files also with compare_nested_list_or_dicts, remove entire string comparison from our side, also open a diff in VSCode for the yaml files)

• move all dump_to_list logic to the input file (similar to boundary_condition, function, etc…)

• move element_type_to_four_c_string to a more central place, i.e., out of core. This should be easily possible once the dump_to_list functions are in the input file (currently a circular import restricts me from moving this)

• then we can also fix the current hackery in the solidrigidsphere for free (here also a circular import hinders me from working further on this)

• discuss if the validation should be turned on during dump (note: this could lead to failing tests, i.e., some form of input changes in 4C - we pull the latest FourCIPP version nightly - then the validation would fail, note that this could also be a good thing)

• Replace self.element_description with self.data.

• Pass the connectivity array of elements into the input file and hand over the conversion for a MeshPy Node to the FourCIPP converter

• Finally we can improve and simplify (by a lot) the model importer

• And finally, finally we can improve and simplify the mesh to dict conversion (by a lot)

[isteinbrecher]

Thanks a lot again @davidrudlstorfer for the changes, and sorry for my overdue review. I aded one more point to your comment #354 (comment).

I think if we only have two minor points left, I am confident that we can merge this soon!

[isteinbrecher]

Oh, and when this is finished, should we simply copy the open points from #354 (comment) into a "cleanup issue"?

[davidrudlstorfer]

@isteinbrecher I've now reworked the testing stuff in a preliminary state. This state can be easily improved in a follow up. Currently only 4 tests (the abaqus tests) use the complicated string comparison. If we also switch that in the near future we can simplify everything a lot further.

This would be ready for review again.

[isteinbrecher]

Thanks for the changes, looks very good to me. There is only the one question regarding the inp in testing remaining, then we can merge this 🚀.

Regarding the compare_string_with tolerances, I had the exactly same thoughts, that we can remove it, but then ended up with the failing abaqus tests 😅.

[davidrudlstorfer]

Again ready for review - thanks for the review:)

[isteinbrecher]

LGTM! Thanks for going the extra mile @davidrudlstorfer .

Once this is merged, I will update the CubitPy PR.