Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2D LWFA Example w/ GaussianBunchDistribution #44
base: master
Are you sure you want to change the base?
2D LWFA Example w/ GaussianBunchDistribution #44
Changes from all commits
0e711f3
c0432c9
809740a
b792aca
2dcce91
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That convention looks good to me and is consistent with openPMD 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I didn't see that. Is this PR outdated and needs to merge
master
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why this diff is showing up here. Perhaps merge in master would help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, or rebasing the PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PICMI_GaussianBunchDistribution.get_n_physical_particles() -> int
or maybePICMI_GaussianBunchDistribution.compute_n_physical_particles() -> None
(which then ought to be documented & tested)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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.