Avoid copying vectors from one data type to other and fix warmstarting algorithm

[RShaw026]

Description and Context

This Merge Request avoids copying vectors from one data type to another unnecessarily. This issue has earlier caused some "segmentation fault" issues, which were solved by avoiding copying of some vectors, especially in problems with high resolution or near full contact (high indentation). Therefore, this merge request helps reduce these issues.

Earlier warmstart worked for cases when the size of xv0 is larger than xvf. This change makes sure that it works even if the size of xvf is larger. This change enables us to store and use the active set in BACI for the next MIRCO call as the stored xvf would be larger, especially in the first iteration of a new MIRCO call.

Related Issues and Pull Requests

• Closes
• Blocks
• Is blocked by
• Follows
• Precedes
• Related to
• Part of
• Composed of

How Has This Been Tested?

I ran ctest and the examples. I have added a new test case for warmstart.

Checklist

• [ ] My commit messages mention the appropriate GitHub issue numbers and are longer than one line where appropriate.
• [ ] I have added/updated documentation where necessary.

Additional Information

Interested Parties / Possible Reviewers

@mayrmt @isteinbrecher

[RShaw026]

@mayrmt xvf are the coordinates of points in contact in the previous iteration, and xv0 are the coordinates of points expected to be in contact in the current iteration. In a normal MIRCO call, usually, the number of points expected to be in contact (done in the ContactSetPredictor) is greater than the number of points in contact in the previous iteration. Therefore, the previous warmstarting algorithm worked fine as we were not using a pre-known active set in the first iteration.

In BACI, we call MIRCO multiple times for the same node. The idea is to store the active set from the previous MIRCO call and use it again as input in the next MIRCO call for the same node. Then it might happen that the number of points in contact in the previous MIRCO call is higher than the current number of points predicted to be in contact in the new MIRCO call, at least in the first iteration.

Therefore, this change makes the code more robust by not depending on the sizes of xvf or xv0, and giving the expected output. There are two unit tests that check the two cases of either of the vectors being of larger size.

[mayrmt]

@RShaw026 Do we really not rely on the sizes of both vectors or do we implicitly hope, that one of the vectors is large enough to deal with an increased active set (although we can't predict the amount of the increase)?

I am fine with merging this. I just want to make sure, that we don't rely on some vague assumption, that might bite us down the road.