make compatible with non-coupling-enabled versions of grudge v3 - Githubissues

illinois-ceesd / mirgecom

MIRGE-Com is the workhorse simulation application for the Center for Exascale-Enabled Scramjet Design at the University of Illinois.

Other

11 stars 19 forks source link

make compatible with non-coupling-enabled versions of grudge v3 #1048

Closed matthiasdiener closed 1 month ago

matthiasdiener commented 1 month ago

Followup of #898.

TODO:

~~needs https://github.com/inducer/arraycontext/pull/269~~
[x] undo changing branches to main (undo https://github.com/illinois-ceesd/mirgecom/pull/1048/commits/596894d871c06c0b8671898b661e097d6b5a4d9b)

Questions for the review:

[ ] Is the scope and purpose of the PR clear?
- [ ] The PR should have a description.
- [ ] The PR should have a guide if needed (e.g., an ordering).
[ ] Is every top-level method and class documented? Are things that should be documented actually so?
[ ] Is the interface understandable? (I.e. can someone figure out what stuff does?) Is it well-defined?
[ ] Does the implementation do what the docstring claims?
[ ] Is everything that is implemented covered by tests?
[ ] Do you see any immediate risks or performance disadvantages with the design? Example: what do interface normals attach to?

matthiasdiener commented 1 month ago

This is ready for a first look @majosm @MTCam @inducer. The production tests probably have no chance of succeeding (but I think this isn't the goal).

MTCam commented 1 month ago

I don't have a problem with anything being done here, except the hamstringing of the prediction tests. If prediction tests can't be run, then nothing can stop us from checking things in that break prediction - which has caused us great trouble multiple times in the not-too-distant past.

matthiasdiener commented 1 month ago

I don't have a problem with anything being done here, except the hamstringing of the prediction tests. If prediction tests can't be run, then nothing can stop us from checking things in that break prediction - which has caused us great trouble multiple times in the not-too-distant past.

Just to clarify, this PR currently includes changing the production branches of depending packages to main (https://github.com/illinois-ceesd/mirgecom/pull/1048/commits/596894d871c06c0b8671898b661e097d6b5a4d9b). This is temporary, to demonstrate that the non-coupling-needing tests can pass. This will be reversed in case this PR is going to be merged.

MTCam commented 1 month ago

I don't have a problem with anything being done here, except the hamstringing of the prediction tests. If prediction tests can't be run, then nothing can stop us from checking things in that break prediction - which has caused us great trouble multiple times in the not-too-distant past.

Just to clarify, this PR currently includes changing the production branches to main (596894d). This is temporary, to demonstrate that the non-coupling-needing tests can pass. This will be reversed in case this PR is going to be merged.

Ah, I see now. So is the plan that external packages can do their "upstream mirgecom tests" in CI by using run-examples.sh, and only compatible tests will be run?

matthiasdiener commented 1 month ago

I don't have a problem with anything being done here, except the hamstringing of the prediction tests. If prediction tests can't be run, then nothing can stop us from checking things in that break prediction - which has caused us great trouble multiple times in the not-too-distant past.

Just to clarify, this PR currently includes changing the production branches to main (596894d). This is temporary, to demonstrate that the non-coupling-needing tests can pass. This will be reversed in case this PR is going to be merged.

Ah, I see now. So is the plan that external packages can do their "upstream mirgecom tests" in CI by using run-examples.sh, and only compatible tests will be run?

Yes, run-examples.sh, or pytest.

MTCam commented 1 month ago

I don't have a problem with anything being done here, except the hamstringing of the prediction tests. If prediction tests can't be run, then nothing can stop us from checking things in that break prediction - which has caused us great trouble multiple times in the not-too-distant past.

Just to clarify, this PR currently includes changing the production branches to main (596894d). This is temporary, to demonstrate that the non-coupling-needing tests can pass. This will be reversed in case this PR is going to be merged.

Ah, I see now. So is the plan that external packages can do their "upstream mirgecom tests" in CI by using run-examples.sh, and only compatible tests will be run?

Yes, run-examples.sh, or pytest.

I don't think it can be "or". Upstream pkg's dowstream mirgecom tests should include the examples, at least, if not exclusively.

matthiasdiener commented 1 month ago

This is ready for review. The Production CI error is due to a merge issue.