Define clearly what forces are

[sannant]

It often takes me a while, scrolling thru the code and looking at some simulation results, to figure out what the forces are actually meant to be. I think our convention is that substrate forces are $- \partial E_el / \partial u$, with u positive into the halfspace. These forces are negative in repulsive contacts.

We usually like to represent our forces as being positive inside the contact area, and these would be the forces applied on the substrate in the positive u direction. That is why I get confused so easily.

Also sometimes the force is returned, but it is called pressure.

Note that inside the "minimization code", using the gradient of the energy, rather then the force, is the most natural thing.

I think the current convention makes sense after all but it needs to be clarified here: https://computationalmechanics.github.io/ContactMechanics/usage.html and in the individual docstrings.

@sindhu2993 , @pastewka what are your opinions ?

[pastewka]

I thought that we essentially follow the convention that's in Johnson, i.e. positive displacements are into the half space and positive pressures lead to positive displacements. This is what was discussed with @tjunge at birth of this code.

I agree that forces and pressures are not clearly distinguished and we should make clear from variable names whether it is a force or a pressure.

[sannant]

Yes positive forces applied onto the halspace lead to positive displacements. But evaluate_force is exactly the oposite of that force.

def evaluate_elastic_energy(self, forces, disp):
        """
        computes and returns the elastic energy due to forces and displacements
        Arguments:
        forces -- array of forces
        disp   -- array of displacements
        """
        # pylint: disable=no-self-use
        return .5 * self.pnp.dot(np.ravel(disp), np.ravel(-forces))

[pastewka]

I agree that this looks wrong and should be inverted. Is this function ever used anywhere? I guess that you need it now for the optimizers.

[sannant]

It is used a lot. I mean evaluate_force, or evaluate_disp,that is used as input for forces. What we could think about is to switch progressively to evaluate_gradient, that is always unambigous.

[sannant]

inside evaluate gradient we can make a note saying that positive values correspond to forces pressing into the substrate and lead to positive displacements.

Ah no one problem is that there is a gradient according to u and one according to p.

[pastewka]

I like the idea of switching to evaluate_gradient. This sounds like a major refactor. We should probably do this together some time in the new year.

[sannant]

Yes.

[pastewka]

The forces that are produced by the half space of course need to carry the minus sign. Calling it gradient will make this all unabiguous.

[sindhu2993]

I will be happy to implement these changes in the code. It was a real struggle for me to figure out the minus signs. Having this information in the docstring of evaluate_gradient would helpful.

[pastewka]

Okay, whoever feels responsible is of course welcome to implement that refactor... Just let us know if someone is working on this so we don't start twice.

[sindhu2993]

Yes.

[pastewka]

Just read this thread because I'm preparing v1.0. Did anybody ever start working on this? Should this go into v1.0? I would prefer to avoid major changes because this may break TopoBank.

[sannant]

No. I won't find time for this during the next weeks