Remove dependence of step-39 on LocalIntegrators. #17016
Conversation
|
I am not opposed to the change to remove LocalIntegrator usage. I think it would be much cleaner to use FEInterfaceValues here (instead of the difficult to understand on/out/whatever matrices). I thought I implemented this exact problem already, but maybe I misremember. What do you think? (I can do that change) |
|
Yes, totally! If you already have such a patch, feel free to post. Otherwise, how about we merge the current one which removes one kind of dependence (on the pre-canned integrators) and you build your patch on that removing the other kind of dependence (on the various other data structures)? I would like to get this one merged before the release because that allows us to move forward with #15604. Using a better approach to integration can work on a separate time scale if necessary. |
|
Let's merge this first then. |
| double penalty1 = deg1sq / dinfo1.cell->extent_in_direction(normal1); | ||
| double penalty2 = deg2sq / dinfo2.cell->extent_in_direction(normal2); | ||
| if (dinfo1.cell->has_children() && !dinfo2.cell->has_children()) | ||
| penalty1 *= 2; |
There was a problem hiding this comment.
I don't understand why this is different from the old code that does an XOR between the two bools. Your version is a easier to understand, though.
There was a problem hiding this comment.
Yes, I find XORs to be exceptionally difficult to read.
The difference is that in the original code, we only always updated penalty1, even if the second cell was refined. In my code here, I update penalty1 above and penalty2 below. It doesn't matter if you're on a uniform mesh, but it matters in general.
Related to #15604, #16690. The first commit, in essence, inlines the contents of the
LocalIntegratorsfunctions into step-39 plus some minor clean-ups. The second commit is just a C++ issue. The third commit fixes the issue in the computation of the IP penalty factor mentioned in #15604.