symbolic evaluation problem in an annulus mesh

[NengLu]

Describe the bug
Encountering a symbolic evaluation problem in an annulus mesh. Evaluating a variable or the mesh coordinate system unit individually works, but it fails when calculating the expression involving the product of the variable and mesh.coordinatesystem_unit_e_0.

Reproduce

import underworld3 as uw
import sympy

mesh = uw.meshing.Annulus(radiusOuter=2, radiusInner=1, cellSize=0.05, qdegree=2, degree=1) 
D = uw.discretisation.MeshVariable("D", mesh, vtype=uw.VarType.SCALAR, degree=1, continuous=True) 
D.data[:,0] = 1.

uw.function.evaluate(D.sym * mesh.CoordinateSystem.unit_e_0 , mesh.X.coords)

Error

File <lambdifygenerated-10>:4, in _lambdifygenerated(_Dummy_68, _Dummy_69)
      2 [Dummy_67, Dummy_66] = _Dummy_68
      3 [PKBSM] = _Dummy_69
----> 4 return array([[1.0e-18*Dummy_66*Dummy_67 + Dummy_67*PKBSM[/sqrt](http://localhost:8888/sqrt)(_uw_x**2 + _uw_y**2), 1.0e-18*Dummy_66*Dummy_67 + PKBSM*_uw_y[/sqrt](http://localhost:8888/sqrt)(_uw_x**2 + _uw_y**2)]])

NameError: name '_uw_x' is not defined

Environment
Python 3.12
PETSc via Pixi environment
Branch: latest development (2026-02-24)

[lmoresi]

Fixed in PR #61 (merged to development)

Root cause: lambdify in _lambdify_and_evaluate() uses object identity to match argument symbols. The expression contained both UWCoordinate and BaseScalar instances for the same coordinates — lambdify treated them as different variables, generating code with undefined _uw_x/_uw_y names.

Fix: canonicalize all coordinate symbols (both types) to neutral Dummy symbols before lambdify, avoiding the identity mismatch entirely.

Your example now works:

uw.function.evaluate(D.sym * mesh.CoordinateSystem.unit_e_0, mesh.X.coords)

[NengLu]

Thx Louis, but I need to reopen this issue because the current fix introduces additional errors.

Evaluating expressions like 1.0 * mesh.CoordinateSystem.unit_e_1 or sympy.simplify(1) * mesh.CoordinateSystem.unit_e_0 after evaluating D.sym * mesh.CoordinateSystem.unit_e_0 results in new issues.

import underworld3 as uw
import sympy

mesh = uw.meshing.Annulus(radiusOuter=2, radiusInner=1, cellSize=0.5, qdegree=2, degree=1) 
D = uw.discretisation.MeshVariable("D", mesh, vtype=uw.VarType.SCALAR, degree=1, continuous=True) 
D.data[:,0] = 1.

print(uw.function.evaluate(D.sym * mesh.CoordinateSystem.unit_e_0 , mesh.X.coords).shape)
print(uw.function.evaluate(sympy.simplify(1)* mesh.CoordinateSystem.unit_e_0 , mesh.X.coords).shape)
print(uw.function.evaluate(1.0* mesh.CoordinateSystem.unit_e_1 , mesh.X.coords).shape)

It should show results:

(78, 1, 2)
(78, 1, 2)
(78, 1, 2)

While uw.function.evaluate(1.0* mesh.CoordinateSystem.unit_e_1) will show errors:

PrintMethodNotImplementedError: Unsupported by <class 'sympy.printing.numpy.SciPyPrinter'>: <class 'sympy.vector.scalar.BaseScalar'>
Set the printer option 'strict' to False in order to generate partially printed code.

And uw.function.evaluate(sympy.simplify(1)* mesh.CoordinateSystem.unit_e_1) will show errors:

File <lambdifygenerated-3>:2, in _lambdifygenerated(Dummy_47, Dummy_46)
      1 def _lambdifygenerated(Dummy_47, Dummy_46):
----> 2     return Dummy_47[/sqrt](http://127.0.0.1:8888/sqrt)(Dummy_46**2 + _uw_y**2)

NameError: name '_uw_y' is not defined

[lmoresi]

@NengLu — Thanks for the detailed reproducer. We've identified the root cause and have a fix on development.

What was happening: pure_sympy_evaluator.py used .subs() to replace UWCoordinate objects with BaseScalars before lambdify. But SymPy's internal caching creates multiple UWCoordinate instances for the same coordinate, and .subs() misses some due to UWCoordinate's custom __eq__/__hash__. The surviving UWCoordinates generated _uw_x/_uw_y names that didn't match the lambdify argument names.

Fix: Replaced the .subs() approach with Dummy-based canonicalization using .xreplace() — a direct tree traversal that avoids the identity issue. All your test cases now pass, including the sequence-dependent failure (evaluating D.sym * unit_e_0 first, then simplify(1) * unit_e_0).

Could you pull development and validate? Important: after pulling, clear the build cache to avoid stale code:

rm -rf build/lib.* build/bdist.*
./uw build

(./uw build alone can reuse a cached wheel since the version is always 0.0.0 — the rm ensures a fresh build.)

Underworld development team with AI support from Claude Code

[lmoresi]

Reopening — @NengLu could you test the fix on development and close this issue if it resolves your problem? See the previous comment for details and rebuild instructions.

Underworld development team with AI support from Claude Code

[NengLu]

Thank you for the fix, it resolved the issue. I'm closing it.