 | Smilei users | 297 Members |
| github.com/SmileiPIC/Smilei | 4 Servers |
| Smilei users | 297 Members |
| github.com/SmileiPIC/Smilei | 4 Servers |
| Sender | Message | Time |
|---|---|---|
| 5 Dec 2024 | ||
 mohammad rezaei | Dear Experts, I conducted a test to inject an electron beam in Smilei. I imported the electron beam into the simulation box. Everything is fine, and the beam propagated in the window. However, when I used time freezing, the beam expanded dramatically after the time freezing, which is significantly different from when I did not use time freezing. Our test was conducted in AM cylindrical geometry and vacuum. | 15:37:08 |
 fredpz | Maybe give a little more details on how you make a temperature diagnostic? | 15:57:50 |
 erciyes | Hi guys, I've a question on one of the build options. In installment documentation, by default the parallel-enabled HDF5 is used. Then, I wonder what would be the usage of 'no_mpi_tm' configuration for the make command. It states that for a MPI library which does not support MPI_THREAD_MULTIPLE, so is it suitable to be used for the configurations like process divided into only MPI tasks, no openMP, so each MPI task is single thread? | 16:32:47 |
 beck-llr | Hi. If you use a single openMP thread per MPI process you might as well compile with config=noopenmp. You don't have to bother with thread multiple. | 16:56:07 |
| beck-llr | no_mpi_tm is useful when you have several openMP threds per MPI process but you want all MPI calls to be handled only by the master thread. | 16:57:20 |
| beck-llr | * no_mpi_tm is useful when you have several openMP threads per MPI process but you want all MPI calls to be handled only by the master thread. | 16:57:27 |
| mohammad rezaei | Download IMG_8162.MP4 | 17:00:05 |
| mohammad rezaei | this is output | 17:00:07 |
| fredpz | In reply to @rezaei.m.p:matrix.orgWhat did you freeze? Particles? Fields? | 17:41:23 |
| mohammad rezaei | Particles | 17:42:10 |
| mohammad rezaei | * Particles, Also in the test, there is not laser, Just I have particles | 17:43:58 |
| fredpz | There are fields caused by particles | 17:44:15 |
| mohammad rezaei | my main goal is: I have a laser and electron beam, I would like adjust distance of laser to electron beam. | 17:46:27 |
| mohammad rezaei | * my main goal is: I have a laser and electron beam, I would like adjust distance of laser to electron beam. when I use electron beam without frozen time, it is propagate in x direction but with frozen time, the electron beam destroy. | 17:48:45 |
 z10f | it is normal that an electron beam in vacuum explodes | 18:07:25 |
| z10f | This benchmark tstAM_10_em_propagation_external_field.py initializes a gaussian laser pulse entirely inside the window at t=0 using the External Fields, maybe it can help your case, because you can place the electron bunch just behind it without the need to freeze it. Now, be aware that this way of initializing is not 100% accurate, because 1) the formula for the fields comes from the paraxial wave equation, which is an approximation of a field satisfying Maxwell's equations. 2) to be numerically exact, you should compute the El component from the Er and Et components from the finite difference equivalent of the divergence equation for E (same for B), at each point. So, if you see a residual small fraction of the laser goind towards left this is expected | 18:13:51 |
| 6 Dec 2024 | ||
| erciyes | So then, even with "config=no_mpi_tm" option, there should be no problem to use HDF% parallel, right? | 10:12:59 |
| erciyes | * So then, even with "config=no_mpi_tm" option, there should be no problem to use HDF5 parallel, right? | 10:13:05 |
 Marius Hartig (TUDa) | Does anybody have experience with getting smilei to run on an older GPU, which is not officially supported by ROCm like a radeon r9 390x? | 10:56:16 |
| fredpz | It is very likely that it won't work. Even recent compilers don't necessary support all the features | 11:01:27 |
| beck-llr | In reply to @erciyes:matrix.orgAbsolutely. | 12:30:42 |
| Marius Hartig (TUDa) | Hello Smilei Users, I'm trying to get an energy spectrum of accelerated ions using the screen diagnostic in AM geometry. This means I am using "weight" as deposited quantity and "ekin" as an axis. I want to get dN/dE, where dN means the amount of real particles (not number density) in an energy bin of size dE. My approach is to first multiply with grid_length[0]grid_length[1]**2 to get weight per energy. Then multiplying with N_rL_r3 gives me number of real particles per energy. Dividing by K_r should convert smilei energy units to SI. Is this correct, because doing this for a similar simulation in 2D cartesian (with grid_length[0]*grid_length[1]N_rL_r2/K_r) results in values, which are way different. | 15:58:09 |
| Marius Hartig (TUDa) | * Hello Smilei Users, I'm trying to get an energy spectrum of accelerated ions using the screen diagnostic in AM geometry. This means I am using "weight" as deposited quantity and "ekin" as an axis. I want to get dN/dE, where dN means the amount of real particles (not number density) in an energy bin of size dE. My approach is to first multiply with grid_length[0]*grid_length[1]**2 to get weight per energy. Then multiplying with N_r_L_r3 gives me number of real particles per energy. Dividing by K_r should convert smilei energy units to SI. Is this correct, because doing this for a similar simulation in 2D cartesian (with grid_length[0]*grid_length[1]_N_r_L_r2/K_r) results in values, which are way different. | 16:01:24 |
| Marius Hartig (TUDa) | * Hello Smilei Users, I'm trying to get an energy spectrum of accelerated ions using the screen diagnostic in AM geometry. This means I am using "weight" as deposited quantity and "ekin" as an axis. I want to get dN/dE, where dN means the amount of real particles (not number density) in an energy bin of size dE. My approach is to first multiply with grid_length[0]*grid_length[1]**2 to get weight per energy. Then multiplying with N_r*L_r3 gives me number of real particles per energy. Dividing by K_r should convert smilei energy units to SI. Is this correct, because doing this for a similar simulation in 2D cartesian (with grid_length[0]*grid_length[1]_N_r_L_r2/K_r) results in values, which are way different. | 16:01:44 |
| z10f | This postprocessing script was made for the TrackParticles in AM geometry: https://github.com/SmileiPIC/TP-M2-GI/blob/main/Postprocessing_Scripts/Compute_bunch_parameters.py This way (and using the conversions in the script) you should be able to find the energy and weights of the macro-particles. Afterwards, an energy spectrum is just a weighted histogram of the energy | 16:01:55 |
| Marius Hartig (TUDa) | * Hello Smilei Users, I'm trying to get an energy spectrum of accelerated ions using the screen diagnostic in AM geometry. This means I am using "weight" as deposited quantity and "ekin" as an axis. I want to get dN/dE, where dN means the amount of real particles (not number density) in an energy bin of size dE. My approach is to first multiply with grid_length[0]*grid_length[1]**2 to get weight per energy. Then multiplying with N_r*L_r**3 gives me number of real particles per energy. Dividing by K_r should convert smilei energy units to SI. Is this correct, because doing this for a similar simulation in 2D cartesian (with grid_length[0]*grid_length[1]_N_r_L_r**2/K_r) results in values, which are way different. | 16:02:20 |
| Marius Hartig (TUDa) | * Hello Smilei Users, I'm trying to get an energy spectrum of accelerated ions using the screen diagnostic in AM geometry. This means I am using "weight" as deposited quantity and "ekin" as an axis. I want to get dN/dE, where dN means the amount of real particles (not number density) in an energy bin of size dE. My approach is to first multiply with grid_length[0]*grid_length[1]**2 to get weight per energy. Then multiplying with N_r*L_r**3 gives me number of real particles per energy. Dividing by K_r should convert smilei energy units to SI. Is this correct, because doing this for a similar simulation in 2D cartesian (with grid_length[0]*grid_length[1]*N_r*L_r**2/K_r) results in values, which are way different. | 16:02:36 |
| fredpz | In 2d Cartesian there is a missing spatial dimension. You have to make an assumption about this missing size | 16:19:31 |
 Ben Heller (TUDa) | How can this approach be applied to ScreenDiag? | 17:08:48 |
| Ben Heller (TUDa) | And apart from that, do the considerations to multiply by the factors described in the first message make sense? | 17:09:07 |