Fix inconsistent ufl usage in examples

[schnellerhase]

Some examples use multiple import schemes of ufl, this switches to a single import style per example.

For example currenltly demo_elasticity.py contains:

import ufl
from ufl import dx, grad, inner

Other examples that share this:

• demo_biharmonic.py
• demo_cahn-hilliard.py
• demo_hdg.py
• demo_helmholtz.py
• demo_lagrange_variants.py
• demo_poisson_matrix_free.py
• demo_poisson.py
• demo_pyamg.py
• demo_stokes.py

[francesco-ballarin]

Not sure if it is worth continuing to work on this.

Some of the developers are of the opinion that the choice of doing

from ufl import dx, grad, inner

is to ensure that the weak formulation of the problem is as close to the one on paper as possible, avoiding to have to add a prefix ufl. to every term in the formulation.
Personally that's not my opinion, but they do have a valid point.

[schnellerhase]

Good point, but could we then switch to consistent usage of from ufl import ... in all cases?

[francesco-ballarin]

I guess so, unless the list of imported names gets super long. If I were you I would put this on hold until a few other developers have had the opportunity to comment.

[jorgensd]

I guess so, unless the list of imported names gets super long. If I were you I would put this on hold until a few other developers have had the opportunity to comment.

I think having a mixture doesn’t hurt.

[schnellerhase]

I noticed this by chance when copying the elasticity weak form

2.0 * μ * ufl.sym(grad(v)) + λ * ufl.tr(ufl.sym(grad(v))) * ufl.Identity(len(v))

and it was not clear to me why it didn't just work with an ufl import that I spotted right away. I mean after taking a closer look at it was no problem, but it does seem odd to me to have different imports at play in one line for the same module.

[michalhabera]

I noticed this by chance when copying the elasticity weak form

2.0 * μ * ufl.sym(grad(v)) + λ * ufl.tr(ufl.sym(grad(v))) * ufl.Identity(len(v))

and it was not clear to me why it didn't just work with an ufl import that I spotted right away. I mean after taking a closer look at it was no problem, but it does seem odd to me to have different imports at play in one line for the same module.

Here I agree it is very confusing. It dangerously suggests grad comes from some place other than sym. I think this should be made consistent per "module import level", i.e. the above example. Once importing from ufl import foo there should not be ufl.TrialFunction in the same file.