Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lazy compilation fails with overintegration and TPE #1073

Open
anderson2981 opened this issue Oct 18, 2024 · 2 comments
Open

Lazy compilation fails with overintegration and TPE #1073

anderson2981 opened this issue Oct 18, 2024 · 2 comments
Assignees

Comments

@anderson2981
Copy link
Contributor

Specifying a quadrature order seems to confuse the transformation chain. The attached example demonstrates this behavior.

Specifically, setting order=1 and quadrature_order=1 yields the following error:

error message

here is an input file

run_params.yaml

occurs in y3prediction driver

mpirun -n 1 python -u -O -m mpi4py driver.py -i run_params.yaml --lazy --overintegration

using the mesh at

data/cav5_comb4/2D/coarse_quads/

@MTCam
Copy link
Member

MTCam commented Oct 19, 2024

For a simpler example, the error can be reproduced with any inviscid driver in mirgecom. The pulse.py example has been prepared to easily reproduce on mirgecom@update-overintegration-tests:

python -m mpi4py pulse.py --tpe --overintegration --lazy

The default when using tensor product elements is to create a QuadratureGroupFactory(order=p) where p is the degree of the polynomial basis for the elements. By default this gets us a JacobiGauss quadrature rule with (p+1)^d quadrature nodes that is exact up to 2p + 1. But currently, sending anything less than 2p to QuadratureGroupFactory reproduces the error.

We can work around the error by just refusing to fuse those kernels identified as nestable. An example of that work-around is here.

@matthiasdiener
Copy link
Member

matthiasdiener commented Oct 21, 2024

The real error message (for pulse) is:

  File "/Users/mdiener/Work/e5/meshmode/meshmode/array_context.py", line 1706, in transform_loopy_program
    knl = fuse_same_discretization_entity_loops(knl)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/mdiener/Work/e5/loopy/loopy/tools.py", line 968, in wrapper
    result = func(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/mdiener/Work/e5/meshmode/meshmode/array_context.py", line 927, in fuse_same_discretization_entity_loops
    knl = _fuse_loops_over_a_discr_entity(knl, DiscretizationDOFAxisTag,
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/mdiener/Work/e5/meshmode/meshmode/array_context.py", line 886, in _fuse_loops_over_a_discr_entity
    lp.get_kennedy_unweighted_fusion_candidates(
  File "/Users/mdiener/Work/e5/loopy/loopy/transform/loop_fusion.py", line 766, in get_kennedy_unweighted_fusion_candidates
    raise LoopyError(f"'{iname}' and '{conflict_iname}' "
loopy.diagnostic.LoopyError: '_pt_sum_r0_15' and '_pt_sum_r1_1' cannot fused be fused as they can be nested within one another.

caused by this part of the code in meshmode/array_context.py: fuse_same_discretization_entity_loops():

knl = _fuse_loops_over_a_discr_entity(knl, DiscretizationDOFAxisTag,
                                          "idof",
                                          True,
                                          orig_knl)

Removing that line of code also works around the issue.

Is there perhaps a stray DiscretizationDOFAxisTag in the code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants