Feature: Screen Charge Deposition

[cr-xu]

Description

• Add general Cloud-in-Cell (CIC) method for 1,2, and 3D charge deposition.
• Add cloud-in-cell method for Screen, that is differentiable and faster than the kde method.

Fixes #433

Also partially addresses #543

This PR merges @roussel-ryan 's fork https://github.com/roussel-ryan/cheetah/tree/diag0 into the master.

Motivation and Context

• I have raised an issue to propose this change (required for new features and bug fixes)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (update in the documentation)

Checklist

• I have updated the changelog accordingly (required).
• My change requires a change to the documentation.
• I have updated the tests accordingly (required for a bug fix or a new feature).
• I have updated the documentation accordingly.
• I have reformatted the code and checked that formatting passes (required).
• I have have fixed all issues found by flake8 (required).
• I have ensured that all pytest tests pass (required).
• I have run pytest on a machine with a CUDA GPU and made sure all tests pass (required).
• I have checked that the documentation builds (required).

Note: We are using a maximum length of 88 characters per line.

[jank324]

I just discovered a fairly significant issue with the implementation as is: Cheetah assumes that there can be any number of vector dimensions, and how many there are is unknown. However, as it stands, the Cloud-in-Cell implementation assumes exactly one vector dimensions, and, I believe, relies on Tensor's number of dimensions to determine how many histogram dimensions are needed. This is fundamentally incompatible with how Cheetah does it. Instead, the Cloud-in-Cell implementation should follow the interface of numpy.histogramdd.

[roussel-ryan]

Are you sure about this? We've been doing arbitrary batch dimensions for gpsr using similar code.

[jank324]

Well ... I just started checking how we might fix this. And I think it might actually be vector-dimension-agnostic, but the docstring and argument verification just say otherwise.

[jank324]

I think this doesn't actually match what the function really does.

[roussel-ryan]

I agree

[roussel-ryan]

Wait, let me look at it a little more in detail

[roussel-ryan]

Wait, let me look at it a little more in detail

[jank324]

I changed it now to something that I believe reflects much better how it works (or should work). Interestingly, this is exactly backwards from what np.histogramdd does. I don't know if that's bad or irrelevant. I find the way we do it now intuitive as well.