Skip to content
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

variable ParticlePerCell in init #4910

Open
BrianMarre opened this issue May 28, 2024 · 3 comments
Open

variable ParticlePerCell in init #4910

BrianMarre opened this issue May 28, 2024 · 3 comments
Assignees
Labels
component: user input signals changes in user API such as .param files, .cfg syntax, etc. - changelog! feature request a request or suggestion to implement new functionality refactoring code change to improve performance or to unify a concept but does not change public API

Comments

@BrianMarre
Copy link
Member

It would be nice to be able to vary the number of particles we try to spawn in each cell over the simulation.

This would allow an increased number of samples in regions of interest while keeping the total number of macro particles down, and avoiding the need to use separate species.

This is feasible as discussed with psychocoderHPC offline but will require an interface change in the start position functors.

@ikbuibui
Copy link
Contributor

In your opinion what would a good/convenient way to describe this initial particle density distribution be, just so I can get more of an idea of what the interface should maybe look like. Maybe a normalized SIM_DIM dimensional function, scaled by the max particles per cell you want?

@pordyna
Copy link
Member

pordyna commented May 29, 2024

Exactly, with x, y, (z) in SI units like in density function and with the total domain size (in SI units) available in the functor since there is no way in PIConGPU to shift your coordinate system, and simulation box size is a runtime option. (Btw. this should be also a thing for the density functor ;) )

@pordyna
Copy link
Member

pordyna commented May 29, 2024

I would also suggest that there should be a test if the result is an unsigned integer, but no automatic conversion so that the user fully controls the rounding. But, others may have a different opinion on that.

@steindev steindev added refactoring code change to improve performance or to unify a concept but does not change public API component: user input signals changes in user API such as .param files, .cfg syntax, etc. - changelog! feature request a request or suggestion to implement new functionality labels Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: user input signals changes in user API such as .param files, .cfg syntax, etc. - changelog! feature request a request or suggestion to implement new functionality refactoring code change to improve performance or to unify a concept but does not change public API
Projects
None yet
Development

No branches or pull requests

4 participants