good questions! I’ll try to answer them one-by-one:
The wording continuous formulation is a wording that comes from the underlying tool that we use for the advanced analysis types (Code_Aster) and rather a distinction to the other available formulation, the discrete formulation. The discrete formulation is called that way, since it uses already discretized fields such as displacement and nodal forces in the contact equations. It’s available with a node-to-segment and a node-to-segment pairing.
We decided to only include the continuous formulation since it is the more generic one and better usable with friction. The continuous formulation uses a node-to-segment pairing.
The wording in the documentation is indeed not explicit enough. In this case the correct naming is Stabilized Lagrangian Method, but it is equivalent to the Augmented Lagrangian Method, for details you can have a look at this phd thesis by Ayaovi Dzifa Kudawoo.
This is partly related to the general nature of the Penalty Method and also the current implementation of the Augmented Lagrangian Method.
Generally the source of (almost) all difficulties when dealing with physical contact is the high nonlinearity of the contact conditions, they are not only nonlinear, but non-differentiable and discontinuous. Since the Penalty Method itself smoothens the strong contact assumptions by allowing a certain amount of penetration, reduces the numerical difficulties. Of course, the method itself introduces another source for numerical problems as you stated, but with a reasonable starting value for the penalty factor most contact analyses will at least give an initial result. This can be then used as a starting point to further refine your setup and finally reach converged results.
The Augmented Lagrangien Method can have problems with over-constrained simulation setups, for example when symmetry and frictional contact constrain the same DOF. This might partially be related to the current implementation, but experience has shown that in those cases switching to a penalty contact often solves the problem.
I am not sure how far you want me to go with an answer to this one. The contact surfaces are generally never matching. The current implementation does not use a mortar method. You can find all details of its implementation in this document of the official Code_Aster documentation.
As a side note: Recently there was an improved contact method for non-matching meshes implemented into Code-Aster that is going to be integrated into SimScale as soon as it’s stable. Details can be found in this paper.
If you have any additional questions, I’m happy to help.