2D LWFA Example w/ GaussianBunchDistribution #44
Conversation
Added new method for particles
added more methods, and also add a code-specific option "other:<algorithm>"
made changes according to reviews.
Made a 2D LWFA example to speed up testing. In the process it became necessary to add an attribute to the Gaussian Beam. In 2D Cartesian (or r-z) Here I assume the distribution is Gaussian and the density is related to the physical particles via the relation N = density * product(sigma) * (2*pi)^(3/2) In the 3D example, the total beam particles is 10^8 and the RMS width is 1 micron in all directions, this corresponds to a density of 6.35*10^24 m^(-3).
| initial_distribution=None, particle_shape=None, density_scale=None, method=None, **kw): | ||
|
|
||
|
|
||
| assert method is None or method in PICMI_Species.methods_list or method.startswith('other:'), \ |
There was a problem hiding this comment.
That convention looks good to me and is consistent with openPMD 👍
There was a problem hiding this comment.
I don't think that these changes should be here. This is unrelated to the input file and these changes are already in the repo.
There was a problem hiding this comment.
Oh, I didn't see that. Is this PR outdated and needs to merge master?
There was a problem hiding this comment.
I'm not sure why this diff is showing up here. Perhaps merge in master would help.
| plasma_min = [-20.e-6, 0.0e-6] | ||
| plasma_max = [ 20.e-6, 1.e-3] | ||
|
|
||
| # --- electron bunch |
There was a problem hiding this comment.
The intent of the Gaussian beam distribution is that it is describing the physics of the beam and is not dependent on the dimensionality of the underlying simulation. So, the input parameters should all have lengths of 3, and the number of physical particles is well defined.
In lower dimensional simulations, the ignored directions would have a unit length.
| self.centroid_position = centroid_position | ||
| self.centroid_velocity = centroid_velocity | ||
| self.velocity_divergence = velocity_divergence | ||
| if(centroid_position is None): |
There was a problem hiding this comment.
Not for this PR, but for the discussed update in #63:
@s9105947 @BrianMarre the question came up today how we would express such logic with the DataClasses. Can you comment?
There was a problem hiding this comment.
I'll jump in. See my comment above that the input parameters should always have a length of 3 (since this class should be independent of the dimensionality of the simulation). In that case, this logic is not needed.
But if something like this is needed, the dataclass allows the method __post_init__ where this could be done. Type checking can still be done, ensuring that the input parameters are sequences.
There was a problem hiding this comment.
- data-classes are pure data interfaces. They do not perform any computation on data themselves. (Unless explicitly mentioned/requested.)
- derived computations are methods, e.g.
PICMI_GaussianBunchDistribution.get_n_physical_particles() -> intor maybePICMI_GaussianBunchDistribution.compute_n_physical_particles() -> None(which then ought to be documented & tested) - @dpgrote stresses an important point: this class corresponds to a physical density distribution. From there I would derive: a 2D distribution is different (i.e. must be handled differently) than a 3D distribution -> it should be its own class.
At which point we should ask: Do we need this 2D class, or can we model the 2D case as a special case of 3D?
Either way, this many if-statements are too many and warrant either a separate class or mapping 2D to 3D.
There was a problem hiding this comment.
With respect to geometry, we usually defer to declaring everything physics-related in 3D and expressing periodicity/symmetries separately for mapping. That's why Dave proposes to put everything in in 3D.
There are multiple ways to implement 1D, 2D and RZ, see for instance: https://doi.org/10.5281/zenodo.3266820 section 2.3.4. We put such information in the numerical parameters, e.g., the grid: https://picmi-standard.github.io/standard/grid.html. One could consider adding symmetry options specifically at some point to abstract further.
We follow the same line of thought (concept) for boosted frame simulations (express everything in the lab frame and convert in the background).
In other words: "explicit 2D classes" rather no if we talk about physics parameters. We can do such transformations as late as possible in the code backend.
| self.centroid_position = centroid_position | ||
| self.centroid_velocity = centroid_velocity | ||
| self.velocity_divergence = velocity_divergence | ||
| if(centroid_position is None): |
There was a problem hiding this comment.
- data-classes are pure data interfaces. They do not perform any computation on data themselves. (Unless explicitly mentioned/requested.)
- derived computations are methods, e.g.
PICMI_GaussianBunchDistribution.get_n_physical_particles() -> intor maybePICMI_GaussianBunchDistribution.compute_n_physical_particles() -> None(which then ought to be documented & tested) - @dpgrote stresses an important point: this class corresponds to a physical density distribution. From there I would derive: a 2D distribution is different (i.e. must be handled differently) than a 3D distribution -> it should be its own class.
At which point we should ask: Do we need this 2D class, or can we model the 2D case as a special case of 3D?
Either way, this many if-statements are too many and warrant either a separate class or mapping 2D to 3D.
Added a new 2D example for easier testing. To use the example a new parameter for Gaussian beam need to be introduced which is the beam density.