Early interp

[inducer]

@alexfikl: @ShawnL00 noticed this. A good place to start is the docstring of the test, to understand the issue being addressed.

Draft because I think EarlyInterpolationAdder may need tweaking to handle all the densities that get thrown at it.

To do:

• Why are we calling weights_area_elements in the iteration loop?
  • get_flat_strengths_from_densities: better cache waa
• How does main avoid upsampling quad weights?
  • Possible: it doesn't. It just does so consistently.
• Add a never-upsample-weights check
• Longer-term: make interpolation need-driven rather than unconditional

Notes:

• This breaks the scalar_int_eq tests because the "input side" of the "Bremer" weights gets processed differently from the output side.
• EarlyInterpolationAdder will happily upsample QWeight, which it very much should not.

[inducer]

Recap of discussion with @ShawnL00 recently:

• In a "Bremer weighting" context, upsampling the quadrature weights is very much the right thing to do. (Because we're right-preconditioning the operator.)
• In other settings, upsampling quadrature weights is as dumb as it sounds.
• Distinguishing the two from the perspective of a term rewriter isn't easy.
  • Given that pytential's "language" operates in terms of mostly-continuous terms, having QWeights available as a primitive is... weird. So I'm open to getting rid of it.
• One option would be to have a "Bremer weighting operator", in which case the term rewriting is obvious.
• Another option (see Early interp (density) #322) is a generic "interpolation preventer" node, which seems quite clunky (but it does tell the upsampler what to do).

I'm still quite torn for what to do here.

[inducer]

@alexfikl: @ShawnL00 noticed this. A good place to start is the docstring of the test, to understand the issue being addressed.

Draft because I think EarlyInterpolationAdder may need tweaking to handle all the densities that get thrown at it.

To do:

• Why are we calling weights_area_elements in the iteration loop?
  • get_flat_strengths_from_densities: better cache waa
• How does main avoid upsampling quad weights?
  • Possible: it doesn't. It just does so consistently.
• Add a never-upsample-weights check
• Longer-term: make interpolation need-driven rather than unconditional

Notes:

• This breaks the scalar_int_eq tests because the "input side" of the "Bremer" weights gets processed differently from the output side.
• EarlyInterpolationAdder will happily upsample QWeight, which it very much should not.

[inducer]

Recap of discussion with @ShawnL00 recently:

• In a "Bremer weighting" context, upsampling the quadrature weights is very much the right thing to do. (Because we're right-preconditioning the operator.)
• In other settings, upsampling quadrature weights is as dumb as it sounds.
• Distinguishing the two from the perspective of a term rewriter isn't easy.
  • Given that pytential's "language" operates in terms of mostly-continuous terms, having QWeights available as a primitive is... weird. So I'm open to getting rid of it.
• One option would be to have a "Bremer weighting operator", in which case the term rewriting is obvious.
• Another option (see Early interp (density) #322) is a generic "interpolation preventer" node, which seems quite clunky (but it does tell the upsampler what to do).

I'm still quite torn for what to do here.

[inducer]

@alexfikl: @ShawnL00 noticed this. A good place to start is the docstring of the test, to understand the issue being addressed.

Draft because I think EarlyInterpolationAdder may need tweaking to handle all the densities that get thrown at it.

To do:

• Why are we calling weights_area_elements in the iteration loop?
  • get_flat_strengths_from_densities: better cache waa
• How does main avoid upsampling quad weights?
  • Possible: it doesn't. It just does so consistently.
• Add a never-upsample-weights check
• Longer-term: make interpolation need-driven rather than unconditional

Notes:

• This breaks the scalar_int_eq tests because the "input side" of the "Bremer" weights gets processed differently from the output side.
• EarlyInterpolationAdder will happily upsample QWeight, which it very much should not.

[inducer]

Recap of discussion with @ShawnL00 recently:

• In a "Bremer weighting" context, upsampling the quadrature weights is very much the right thing to do. (Because we're right-preconditioning the operator.)
• In other settings, upsampling quadrature weights is as dumb as it sounds.
• Distinguishing the two from the perspective of a term rewriter isn't easy.
  • Given that pytential's "language" operates in terms of mostly-continuous terms, having QWeights available as a primitive is... weird. So I'm open to getting rid of it.
• One option would be to have a "Bremer weighting operator", in which case the term rewriting is obvious.
• Another option (see Early interp (density) #322) is a generic "interpolation preventer" node, which seems quite clunky (but it does tell the upsampler what to do).

I'm still quite torn for what to do here.

[inducer]

@alexfikl: @ShawnL00 noticed this. A good place to start is the docstring of the test, to understand the issue being addressed.

Draft because I think EarlyInterpolationAdder may need tweaking to handle all the densities that get thrown at it.

To do:

• Why are we calling weights_area_elements in the iteration loop?
  • get_flat_strengths_from_densities: better cache waa
• How does main avoid upsampling quad weights?
  • Possible: it doesn't. It just does so consistently.
• Add a never-upsample-weights check
• Longer-term: make interpolation need-driven rather than unconditional

Notes:

• This breaks the scalar_int_eq tests because the "input side" of the "Bremer" weights gets processed differently from the output side.
• EarlyInterpolationAdder will happily upsample QWeight, which it very much should not.

[inducer]

Recap of discussion with @ShawnL00 recently:

• In a "Bremer weighting" context, upsampling the quadrature weights is very much the right thing to do. (Because we're right-preconditioning the operator.)
• In other settings, upsampling quadrature weights is as dumb as it sounds.
• Distinguishing the two from the perspective of a term rewriter isn't easy.
  • Given that pytential's "language" operates in terms of mostly-continuous terms, having QWeights available as a primitive is... weird. So I'm open to getting rid of it.
• One option would be to have a "Bremer weighting operator", in which case the term rewriting is obvious.
• Another option (see Early interp (density) #322) is a generic "interpolation preventer" node, which seems quite clunky (but it does tell the upsampler what to do).

I'm still quite torn for what to do here.

[inducer]

@alexfikl: @ShawnL00 noticed this. A good place to start is the docstring of the test, to understand the issue being addressed.

Draft because I think EarlyInterpolationAdder may need tweaking to handle all the densities that get thrown at it.

To do:

• Why are we calling weights_area_elements in the iteration loop?
  • get_flat_strengths_from_densities: better cache waa
• How does main avoid upsampling quad weights?
  • Possible: it doesn't. It just does so consistently.
• Add a never-upsample-weights check
• Longer-term: make interpolation need-driven rather than unconditional

Notes:

• This breaks the scalar_int_eq tests because the "input side" of the "Bremer" weights gets processed differently from the output side.
• EarlyInterpolationAdder will happily upsample QWeight, which it very much should not.

[inducer]

Recap of discussion with @ShawnL00 recently:

• In a "Bremer weighting" context, upsampling the quadrature weights is very much the right thing to do. (Because we're right-preconditioning the operator.)
• In other settings, upsampling quadrature weights is as dumb as it sounds.
• Distinguishing the two from the perspective of a term rewriter isn't easy.
  • Given that pytential's "language" operates in terms of mostly-continuous terms, having QWeights available as a primitive is... weird. So I'm open to getting rid of it.
• One option would be to have a "Bremer weighting operator", in which case the term rewriting is obvious.
• Another option (see Early interp (density) #322) is a generic "interpolation preventer" node, which seems quite clunky (but it does tell the upsampler what to do).

I'm still quite torn for what to do here.

[inducer]

@alexfikl: @ShawnL00 noticed this. A good place to start is the docstring of the test, to understand the issue being addressed.

Draft because I think EarlyInterpolationAdder may need tweaking to handle all the densities that get thrown at it.

To do:

• Why are we calling weights_area_elements in the iteration loop?
  • get_flat_strengths_from_densities: better cache waa
• How does main avoid upsampling quad weights?
  • Possible: it doesn't. It just does so consistently.
• Add a never-upsample-weights check
• Longer-term: make interpolation need-driven rather than unconditional

Notes:

• This breaks the scalar_int_eq tests because the "input side" of the "Bremer" weights gets processed differently from the output side.
• EarlyInterpolationAdder will happily upsample QWeight, which it very much should not.

[inducer]

Recap of discussion with @ShawnL00 recently:

• In a "Bremer weighting" context, upsampling the quadrature weights is very much the right thing to do. (Because we're right-preconditioning the operator.)
• In other settings, upsampling quadrature weights is as dumb as it sounds.
• Distinguishing the two from the perspective of a term rewriter isn't easy.
  • Given that pytential's "language" operates in terms of mostly-continuous terms, having QWeights available as a primitive is... weird. So I'm open to getting rid of it.
• One option would be to have a "Bremer weighting operator", in which case the term rewriting is obvious.
• Another option (see Early interp (density) #322) is a generic "interpolation preventer" node, which seems quite clunky (but it does tell the upsampler what to do).

I'm still quite torn for what to do here.

[inducer]

@alexfikl: @ShawnL00 noticed this. A good place to start is the docstring of the test, to understand the issue being addressed.

Draft because I think EarlyInterpolationAdder may need tweaking to handle all the densities that get thrown at it.

To do:

• Why are we calling weights_area_elements in the iteration loop?
  • get_flat_strengths_from_densities: better cache waa
• How does main avoid upsampling quad weights?
  • Possible: it doesn't. It just does so consistently.
• Add a never-upsample-weights check
• Longer-term: make interpolation need-driven rather than unconditional

Notes:

• This breaks the scalar_int_eq tests because the "input side" of the "Bremer" weights gets processed differently from the output side.
• EarlyInterpolationAdder will happily upsample QWeight, which it very much should not.

[inducer]

Recap of discussion with @ShawnL00 recently:

• In a "Bremer weighting" context, upsampling the quadrature weights is very much the right thing to do. (Because we're right-preconditioning the operator.)
• In other settings, upsampling quadrature weights is as dumb as it sounds.
• Distinguishing the two from the perspective of a term rewriter isn't easy.
  • Given that pytential's "language" operates in terms of mostly-continuous terms, having QWeights available as a primitive is... weird. So I'm open to getting rid of it.
• One option would be to have a "Bremer weighting operator", in which case the term rewriting is obvious.
• Another option (see Early interp (density) #322) is a generic "interpolation preventer" node, which seems quite clunky (but it does tell the upsampler what to do).

I'm still quite torn for what to do here.

[inducer]

@alexfikl: @ShawnL00 noticed this. A good place to start is the docstring of the test, to understand the issue being addressed.

Draft because I think EarlyInterpolationAdder may need tweaking to handle all the densities that get thrown at it.

To do:

• Why are we calling weights_area_elements in the iteration loop?
  • get_flat_strengths_from_densities: better cache waa
• How does main avoid upsampling quad weights?
  • Possible: it doesn't. It just does so consistently.
• Add a never-upsample-weights check
• Longer-term: make interpolation need-driven rather than unconditional

Notes:

• This breaks the scalar_int_eq tests because the "input side" of the "Bremer" weights gets processed differently from the output side.
• EarlyInterpolationAdder will happily upsample QWeight, which it very much should not.

[inducer]

Recap of discussion with @ShawnL00 recently:

• In a "Bremer weighting" context, upsampling the quadrature weights is very much the right thing to do. (Because we're right-preconditioning the operator.)
• In other settings, upsampling quadrature weights is as dumb as it sounds.
• Distinguishing the two from the perspective of a term rewriter isn't easy.
  • Given that pytential's "language" operates in terms of mostly-continuous terms, having QWeights available as a primitive is... weird. So I'm open to getting rid of it.
• One option would be to have a "Bremer weighting operator", in which case the term rewriting is obvious.
• Another option (see Early interp (density) #322) is a generic "interpolation preventer" node, which seems quite clunky (but it does tell the upsampler what to do).

I'm still quite torn for what to do here.