Remove beamcontact framework

[davidrudlstorfer]

After a discussion with @isteinbrecher it turned out that the beamcontact framework can actually be deleted because its capabilities have been superseded by the new beaminteraction framework.

Currently we have no issue on Github for that - on our old Gitlab site I found the following issue https://gitlab.lrz.de/baci/baci/-/issues/1013

Currently I am experiencing problems while improving the input for the beam potential interactions. To not hinder my progress I will remove the beam potential interaction capabilities from the old framework for now.

Nevertheless, we should definitely aim to remove the old framework soon because it would ease a lot of modularization work in the beam framework.

@isteinbrecher @maxfirmbach @knarfnitram

Feel free to tag any other beam people

[mayrmt]

@davidrudlstorfer Thanks for raising this topic! I agree: if we don't need the old implementation, let's get rid of it.

The old GitLab issue raises questions about the BEAMS_NEWGAP. Can we clarify, what this is and if we need it? As far as I remember (though only vaguely), the new gap has been introduced by Christoph Meier to avoid very slender beams crossing each other without establishing contact (in particular for cases, where a beam would move more than the diameter of its potential contact partner, so that it ends up on the "other side" of another beam without ever penetrating it.

[isteinbrecher]

I think there is one test case in the old framework that has beam-to-beam, beam-to-solid and solid-to-solid contact. This one still has to be moved to the new framework, then we could remove the whole old framework.

[isteinbrecher]

And of course check what the state of BEAMS_NEWGAP is.

[maxfirmbach]

@davidrudlstorfer Thanks for bringing this up again. I agree with all comments: We should remove it as soon as possible, which I think is now 😃. There might only be ~4 tests left using the old beam contact, so there‘s not a lot of things to do to get rid of it.

[maxfirmbach]

I tagged @knarfnitram, which is one of the prime users of beam contact for his simulations.

[maxfirmbach]

@davidrudlstorfer How is the state on this? We always need to adapt code there that is already dead, would really like to see this gone as soon as possible.

[maxfirmbach]

@davidrudlstorfer Okay, I talk to @isteinbrecher and @knarfnitram. We try to move the remaining tests to the new framework. If that is done I would come back to you regarding the removal 😉.

[isteinbrecher]

Can we identify which tests still use the old framework?

[davidrudlstorfer]

I will quickly test this by removing the framework and opening a dummy PR

[knarfnitram]

At least the 4 testcases, where BEAMS_NEWGAP is used and MODELEVALUATOR: "Standard" is not defined needs definitely to be ported:

• beam3eb_static_contact_penalty_newgap_twocrossedbeams.4C.yaml
• beam3eb_static_contact_beamtosolidcontact_solidcontact.4C.yaml
• beam3r_line2_genalpha_liegroup_contact_penalty_linpen_newgap_smoothed_twocrossedbeams.4C.yaml
• beam3r_line2_genalpha_liegroup_contact_penalty_linpen_newgap_twocrossedbeams.4C.yaml

[davidrudlstorfer]

See #1175

[knarfnitram]

During the removal of the BEAMS_NEWGAP we realized that the functionality BEAMS_SMOOTHING is also missing and it's only tested in combination with BEAMS_NEWGAP in test case beam3r_line2_genalpha_liegroup_contact_penalty_linpen_newgap_smoothed_twocrossedbeams

[knarfnitram]

As discussed offline: the BEAMS_SMOOTHING will not be ported and the test case beam3r_line2_genalpha_liegroup_contact_penalty_linpen_newgap_smoothed_twocrossedbeams can be deleted.

[maxfirmbach]

@davidrudlstorfer @isteinbrecher @davidrudlstorfer This means the old beam contact module beamcontact can be safely deleted now, right?

[knarfnitram]

yes, all functionality we'd like to keep should now be ported and we can proceed with #1175 .

[davidrudlstorfer]

Closed with #1175

[maxfirmbach]

Cool!