Pyccelize evaluate_dofs to speed up tests

[kvrigor]

test_derham_projector_3d and test_3d_commuting_pro_3 collectively take ~10mins to run. This PR tries to drastically reduce this long test time.

#
# Run tests on 4 CPUs just like GitHub runners
#
$ pytest -n 4 psydac/feec/tests/test_global_projectors.py -k "test_derham_projector_3d"
========================== test session starts ==============================
platform linux -- Python 3.12.8, pytest-8.3.3, pluggy-1.5.0
rootdir: /home/user/psydac
configfile: pytest.ini
plugins: profiling-1.8.1, anyio-4.6.2.post1, xdist-3.6.1
4 workers [18 items]
..................                                                                                            [100%]
=================== 18 passed in 361.08s (0:06:01) ===========================

$ pytest -n 4 psydac/feec/tests/test_commuting_projections.py -k "test_3d_commuting_pro_3"
========================== test session starts ==============================
platform linux -- Python 3.12.8, pytest-8.3.3, pluggy-1.5.0
rootdir: /home/user/psydac
configfile: pytest.ini
plugins: profiling-1.8.1, anyio-4.6.2.post1, xdist-3.6.1
4 workers [16 items]
................                                                                                              [100%]
========================= 16 passed in 219.16s (0:03:39) =====================

These slow tests call evaluate_dofs_*() multiple times. A single call to evaluate_dofs_*() is already costly due to usage of deeply nested for loops:

psydac/psydac/feec/global_projectors.py

Lines 772 to 778 in 66205a5

	def evaluate_dofs_3d_0form(intp_x1, intp_x2, intp_x3, F, f):
	n1, n2, n3 = F.shape
	for i1 in range(n1):
	for i2 in range(n2):
	for i3 in range(n3):
	F[i1, i2, i3] = f(intp_x1[i1], intp_x2[i2], intp_x3[i3])

psydac/psydac/feec/global_projectors.py

Lines 781 to 818 in 66205a5

	def evaluate_dofs_3d_1form(
	intp_x1, intp_x2, intp_x3, # interpolation points
	quad_x1, quad_x2, quad_x3, # quadrature points
	quad_w1, quad_w2, quad_w3, # quadrature weights
	F1, F2, F3, # arrays of degrees of freedom (intent out)
	f1, f2, f3 # input scalar functions (callable)
	):
	k1 = quad_x1.shape[1]
	k2 = quad_x2.shape[1]
	k3 = quad_x3.shape[1]
	n1, n2, n3 = F1.shape
	for i1 in range(n1):
	for i2 in range(n2):
	for i3 in range(n3):
	F1[i1, i2, i3] = 0.0
	for g1 in range(k1):
	F1[i1, i2, i3] += quad_w1[i1, g1] * \
	f1(quad_x1[i1, g1], intp_x2[i2], intp_x3[i3])
	n1, n2, n3 = F2.shape
	for i1 in range(n1):
	for i2 in range(n2):
	for i3 in range(n3):
	F2[i1, i2, i3] = 0.0
	for g2 in range(k2):
	F2[i1, i2, i3] += quad_w2[i2, g2] * \
	f2(intp_x1[i1], quad_x2[i2, g2], intp_x3[i3])
	n1, n2, n3 = F3.shape
	for i1 in range(n1):
	for i2 in range(n2):
	for i3 in range(n3):
	F3[i1, i2, i3] = 0.0
	for g3 in range(k3):
	F3[i1, i2, i3] += quad_w3[i3, g3] * \
	f3(intp_x1[i1], intp_x2[i2], quad_x3[i3, g3])

The evaluate_dofs_*() functions seem to be good candidates for pyccel-ization. Problem is, evaluate_dofs_*() can take a Python function as an input, and this is not yet supported in pyccel. I'll have to find another way to speed this up.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.02%	✅ 100.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (66205a5)	30663	18399	60.00%
Head commit (3aae8b2)	61356 (+30693)	36828 (+18429)	60.02% (+0.02%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#458)	170	170	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[yguclu]

Pyccelized modules can call Python functions, if these are also Pyccelized...

[kvrigor]

Pyccelized modules can call Python functions, if these are also Pyccelized...

That's the catch -- those Python functions (i.e. f-evals in our case) should remain black box from C/ForTran perspective, and thus should not be pyccel-ized. Not optimal, but I think preserving the original f-eval (i.e. not pyccel-izing) is more important. There should be a way to bind Python methods as a function pointers in C . I asked this question in the Pyccel repo: pyccel/pyccel#2213 (comment)