Modernize Mirgecom#360
Conversation
7d82d08 to
57f3edd
Compare
|
So my plan is to wait until inducer/grudge#74 is merged before this PR is "ready." However, I think we should keep commenting about the user interface until we're all happy with it. |
|
Thanks @thomasgibson for taking this on! (Just did a quick scroll here, no huge red flags spotted.) |
|
Unsubscribing... @-mention or request review once it's ready for a look or needs attention. |
f511693 to
2c9c57a
Compare
f48f181 to
72a6a03
Compare
|
Haven't forgotten about this PR; I would prefer to have inducer/grudge#122 in first |
Hey @thomasgibson , I think this addresses some portion of #509 ? |
Yes it indeed does! It will take care of removing references to |
This PR does the following:
grudge.discretization.EagerDiscretization. Why? Becausegrudgeis, for the most part, agnostic to whether arrays are eager, gpu, or lazy. It is the job ofarraycontextto sort out the behavior of arrays, notgrudge. Moreover, this uses the more stable (non-deprecated) interface of grudge.meshmodeto the newarraycontextpackage. This also includes the swapping of arguments for functions likethaw.RenamesApparently CI didn't like this.wave-eager-x.py->wave-x.py. This is because of item 1. When lazy evaluation comes in, the only thing that should really change (from mirgecom's perspective) is the use of a new lazy array context.