If you are wondering where the data of this site comes from, please visit https://api.github.com/users/PrometheusPi/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Richard Pausch PrometheusPi HZDR @ComputationalRadiationPhysics Dresden, Germany Post-Doc in theoretical plasma physics

In Situ Animation of Accelerated Computations :microscope:

A GPU-accelerated stencil for filtering and smoothing using numba

A simple web page for information on PIConGPU workshops

An ipython notebook based introduction to the particle-in-cell algorithm

several UNIX shell tools for use on hpc systems

A presenter software for talks and lectures that allows combing various inputs.

Particle-in-cell simulations for the exascale era :sparkles:

Clara2 - a parallel classical radiation calculator based on Liénard-Wiechert potentials

PullRequestReviewEvent

 The openPMD API will parse the file name to decide the chosen backend and iterat In order to set defaults for these value, two further options control the filename:  * --openPMD.ext sets the filename extension.-  Possible extensions include bp for the ADIOS2 backends (default), h5 for HDF5 and sst for Streaming via ADIOS2/SST.-  If the openPMD API has been built with support for the ADIOS1 and ADIOS2 backends, ADIOS2 will take precedence over ADIOS1.-  This behavior can be overridden by setting the environment variable OPENPMD_BP_BACKEND=ADIOS1.+  Possible extensions include bp for the ADIOS2 backend (default), h5 for HDF5 and sst for Streaming via ADIOS2/SST.+  If the openPMD API has been compiled with support for ADIOS2, the openPMD API will automatically prefer using ADIOS2 over ADIOS1.

If I understand @franzpoeschel last comment corretly, using ADIOS(1) no option anymore. Shouldn't than this sentence state:

  If the openPMD API has been compiled with support for ADIOS2, the openPMD API will automatically prefer using ADIOS2 over HDF5.

sbastrakov

comment created time in 5 days

PullRequestReviewEvent
PullRequestReviewEvent

 namespace picongpu             std::string getDefault() const override;         }; -        std::vector<std::string> const JsonMatcher::m_recognizedBackends = {"adios1", "adios2", "hdf5", "json"};+        std::vector<std::string> const JsonMatcher::m_recognizedBackends = {"adios2", "hdf5", "json"};

Thanks for the last explanation @franzpoeschel - that leads me to the following question ...

sbastrakov

comment created time in 5 days

PullRequestReviewEvent

@ComputationalRadiationPhysics/picongpu-maintainers Please feel free to review. Since there seems to be solution to have a central bibliography but keep local references on each page as a kind of short literature review of the topic (as it is currently), I just added all relevant references in docs/source/usage/reference.rst

PrometheusPi

comment created time in 5 days

push eventPrometheusPi/picongpu

commit sha 33c58513b18e0caea33ceea1fc9170b48cbf2263

push time in 5 days

push eventPrometheusPi/picongpu

commit sha 5154cce9df01ee3ecbb34018151402592004cef4

CI: allow to interrupt job To reduce the CI load allow to interrupt the previous CI jobs if a branch is updated. see: https://docs.gitlab.com/ee/ci/yaml/#interruptible

commit sha 44b81835f8772b0732ac069841037cbc46dbe353

Add a new enum for particles boundary kind

commit sha 5766395d34af07ec6e976bf281f2fd367f468d99

Add static storage for boundary kinds in Particles, use it in getStringProperties

commit sha 7ea772498656f86857051f386121b388d8b2a41a

Add command-line options to set particle boundary kinds By default, the kinds matching --periodic are used. Using the new options would override it. However, currently it is only allowed to set the matching values. (This will be changed once there are more boundary implementations)

commit sha 28267ba3f360ea6a3d8724ec3ca7c4dd0f00bb44

Add a functor to apply particle BCs and call to it For both Absorbing and Periodic boundaries it does not need to do anything. Can be customized for other boundary types

commit sha ddcde06e0c4b3358ecce841edd72695e59002d88

Clarify docs for boundaryCondition<> particle flag

commit sha e33d42c41c58283de6727f7554a824f62b862d90

Merge pull request #3761 from psychocoderHPC/topic-interruptibleCIJobs CI: allow to interrupt job

commit sha 33d8ffe595118d7499e1c8d01b85df369fa1b083

Merge pull request #3763 from sbastrakov/topic-customizeParticleBoundaryConditions Enable support for custom particle boundaries

commit sha 53cb1ed637eaa18d6bfb81993900d40a2df3b045

CI: compile on x86 runners Seperate PMacc and PIConGPU jobs. PIConGPU is currently not executed on GPU therefore we can run the compile tests on CPU CI runner and only perform PMacc tests on the accelerator specific runners. To reduce the load PMacc is only testeing each second boost version. The newest boost version is always included. Update the CI base job descriptions to simplify switching to a new container tag or cuda/hip version.

commit sha 96f6980fd2961f03137dfb53ddfd2e9f0fc546a4

Clarify naming and comments for pmacc kernel mapping types Fix mixing up of block and supercell indexing in the naming. Link all mapping templates to the MapperConcept.

Fix drift manipulator in SingleParticle Example Name suggested y-drift, but it is x-drift

commit sha 117a56d23bea353baec95774eab1489db0d50796

Do not use openPMD compression parameter in Dataset class This parameter was for legacy-style selection of compression in openPMD which is implemented only in ADIOS1. The openPMD plugin does not support ADIOS1, so this is inaccessible functionality. The legacy-style compression support will likely be removed in openPMD, compression should be configured in a backend-specific style via JSON.

commit sha 4f4d0afca09192e225981e5453ee37076bf7628d

Remove unused parameter from writeField in openPMD plugin

commit sha 8fba50e01b7c0c647ca1e4878d4ee185023b1a0f

fix compile In case OpenPMD is not available and PIConGPU is compiled for the CUDA backend the code is not compiling because of a syntax error.

commit sha aab865605053f66731a735012e2786e4ee7c3892

Merge pull request #3767 from franzpoeschel/fix_writeField-remove-unnecessary-parameter Remove unnecessary parameter in writeField function template of openPMD plugin

commit sha d8faf805bd6b18d612618b4a775d2057bbefa630

Merge pull request #3766 from lennertsprenger/fix-2021-09_singleParticle Fix drift manipulator in SingleParticle Example

commit sha cb1ef4083ed2039f436dd4051e690c69866bca7c

compile on CPU runner only Add tag cpuonly to avoid blocking special GPU runner.

commit sha a776e9253980ba159db1d09e87c8e114823bf9da

Merge pull request #3768 from psychocoderHPC/fix-compile fix compile

commit sha d64bd81eb12c43498b957130272518e0f1b6c0b4

Merge pull request #3764 from franzpoeschel/remove-compression Remove --openPMD.compression parameter

commit sha 2f43dd234cb01fbbe46682dc1abe937de986d478

Merge pull request #3762 from psychocoderHPC/topic-optimzeCI CI: compile on x86 runners

push time in 5 days

Hi @cbontoiu , as far as I understand your laser.param, you laser front is at a phase \in [0,1):

RAMP_INIT / 2. * PULSE_LENGTH_SI * c / WAVE_LENGTH_SI =
3. * 2.354820045 / 2. * 7.082581446e-17 * 2.9979e8 / 5e-8 =
1.4999


which is numerically close enought to halfe a wavelength to not show the above field.

However, your RAMP_INIT is very small and thus the electric field witch is initially introduces is:

exp(-0.5 (3. * 2.354820045 / 2.)^2) =
0.002


still quite large.

I would propose the following checks:

• set RAMP_INIT to at least 10 and see whether the artifacts vanish
• If not, try again without particles and see if the effect is perhaps coming from a reflection/feedback from the particles

I hope this helped. If you have any further questions, please feel free to ask.

cbontoiu

comment created time in 5 days

@cbontoiu What did you change between your second-to-last and last plot? (the color scale changed by 7-8 orders of magnitude).

cbontoiu

comment created time in 5 days

An easier way to determine the "the number of electrons (captured)" would be to use the e_chargeDensity, do the same stabs as above (1)-(3) (but now dividing by charge converts charge density to number density) and than you now exactly how many electrons are in each PIC cell.

cbontoiu

comment created time in 5 days

Thus the increase in energy density you are seeing between y=550nm and 650nm comes from the energy gain in the laser field. The energy density between y=420nm and 500nm might have two reasons: either there are just more particles as the back of the wake and thus the sum over particles produces a higher total energy, or you have energetic particles (injection) or both.

cbontoiu

comment created time in 5 days

Okay, I thought you were interested in the average energy per real electron.

cbontoiu

comment created time in 5 days

Perfect :+1: - than the only issue I see is how you define "average" - but perhaps I misunderstand your goal here?

cbontoiu

comment created time in 5 days

@sbastrakov You are right :+1: - I thought @cbontoiu is using the openPMD-api and not the openPMD-viewer. (Is this correct @cbontoiu?)

If you are using the openPMD-viewer interface, my comment on "To (1):" can be ignored and your only error occurs at computing the average (see "To (3):").

cbontoiu

comment created time in 5 days

 namespace picongpu             std::string getDefault() const override;         }; -        std::vector<std::string> const JsonMatcher::m_recognizedBackends = {"adios1", "adios2", "hdf5", "json"};+        std::vector<std::string> const JsonMatcher::m_recognizedBackends = {"adios2", "hdf5", "json"};

If we do not provide adios2, openPMD-api could still use adios(1), correctly? Why would you thus remove this "adios1" json tag?

sbastrakov

comment created time in 5 days

PullRequestReviewEvent
PullRequestReviewEvent

@cbontoiu Please excuse the late replay. Regarding:

I am trying to make use of the field 'e_all_energyDensity'. If I understand correctly, the manual says that within each mesh cell, this is the sum of the kinetic energies divided by the cell volume. That is all particles that happen to be in a cell will have their kinetic energy added up and the result will be divided by the cell volume.

This it totally correct. I would just add, that since we are using macro-particles with a spatial shape, neighboring particles will also influence this sum over all particles. (see https://picongpu.readthedocs.io/en/latest/models/shapes.html for more details)

Regarding:

(1) In the figure below, plotting 'e_all_energyDensity' shows a tiny region where this field has a maximum of about 0.7e+17 (I assume in Joule/m^3) (2) and because my cell volume is CELL_VOLUME = 1.33504e-30 m^3 I can multiply 'e_all_energyDensity' by CELL_VOLUME to get the energy to about 1.0e-13 (I assume in Joule) (3) This can then be divided by the electron charge e to get the energy in eV so I can finally say that the tiny electron bunch has an average kinetic energy of ~0.60 MeV. (4) Is my reasoning right?

To (1): as far as I understand your code in your later comment you did not convert to SI units - thus your energy density is still in PIConGPU units. (Assuming you are using the openPMD-api) Perhaps this is defined in CA[4]- I do not know what this variable means.

To (2): If your previous result would have been in SI units, that step would be correct.

To (3): (Assuming you where is SI units before.) No, the value is not an average value. The number you calculated is the total kinetic energy within the volume of a cell. To convert this to an average energy of the electrons you need to dived that total energy per cell by the number of electrons per cell. This is however a dynamic quantity. I would recommend to use the charge density here. This would also allow you to avoid the multiplication with the cell volume and the division by the elementary charge (to convert from J to eV) .

To (4): your general reasoning is correct, but there were some minor errors.

Regarding:

Does the choice of particle per cell (6 PPC here) influence the result somehow, I mean do I have to use 6 in my conversions ? Does it make a difference if I dump all particles or only probes, as it is the case here with using ProbeEveryTwentiethCell = EveryNthCellImp l< mCT::UInt32 < 20, 20, 20 > >; ?

The numbers per cell that you initialize should not matter if the analysis is set up correctly. However, the number of electrons per cell (dynamic quantity) is essential for computing the average (please see "To (3)".)

cbontoiu

comment created time in 5 days

commit sha cfbff6ed6362c5509993bc776c9de8a8ea9001f4

Separate notification of plugins into a separate function in SimulationHelper It was previously done inside the checkpointing function which was confusing

commit sha 85d39663822559f8280c12d8b1e17d6ded5c3375

Merge pull request #3788 from sbastrakov/topic-simulationHelperRefactorNotifyPlugins Separate notification of plugins into a separate function in SimulationHelper

push time in 5 days

Separate notification of plugins into a separate function in SimulationHelper component: PMacc refactoring

It was previously done inside the checkpointing function which was confusing.

I am now working on documenting in general how the PIConGPU computational loop works and can be extended, and so found out this confusing piece.

+22 -10

1 comment

1 changed file

sbastrakov

pr closed time in 5 days

commit sha 9c668983dd706cea9625fb70193c801a72a27151

Remove compile-time movePoint from grid.param We already had a runtime parameter for it, now it is the only way to set it. Update all grid.param files.

Merge pull request #3793 from sbastrakov/topic-removeCompileTimeWindowMovePoint Remove compile-time movePoint from grid.param

push time in 5 days

Remove compile-time movePoint from grid.param refactoring component: user input

We already had a runtime parameter for it, now it is the only way to set it. Update all grid.param files.

+3 -335

0 comment

21 changed files

sbastrakov

pr closed time in 5 days

PullRequestReviewEvent

push eventPrometheusPi/picongpu

commit sha c7ee2f3f6a14ca32e2dc3f177a65594ae150ee33

fix tries to build global bibliography

push time in 5 days

@psychocoderHPC You added that file. Is this intended?

PrometheusPi

comment created time in 5 days

When building the documentation, I get the following warning:

checking consistency... /.../picongpu/docs/source/usage/param/particles/current.rst: WARNING: document isn't included in any toctree


Indicating that current.rst is currently not included.

created time in 5 days

issue closedmcmtroffaes/sphinxcontrib-bibtex

I use sphinxcontrib-bibtex to cite references throughout our documentation but define them only once in a *.bib file. However, if I reference the same paper in two different pages, I get the following warning:

/...picongpu/docs/source/usage/plugins/radiation.rst:536: WARNING: duplicate citation for key "Pausch2019"
/.../picongpu/docs/source/install/path.rst:64: WARNING: duplicate citation for key "Pausch2019"


Is this intended and is there a way to avoid this warning?

closed time in 6 days

PrometheusPi

issue commentmcmtroffaes/sphinxcontrib-bibtex

Thanks @mcmtroffaes for you help - I will close the issue now.

PrometheusPi

comment created time in 6 days