diff --git a/Docs/source/dataanalysis/picviewer.rst b/Docs/source/dataanalysis/picviewer.rst index 2772d9aa5e2..60aacbb2cca 100644 --- a/Docs/source/dataanalysis/picviewer.rst +++ b/Docs/source/dataanalysis/picviewer.rst @@ -2,7 +2,7 @@ PICViewer ========= .. figure:: sample_image.png - :alt: picture + :alt: figure not found PICViewer is a visualization GUI implemented on PyQt. The toolkit provides various easy-to-use functions for data analysis of diff --git a/Docs/source/dataanalysis/visit.rst b/Docs/source/dataanalysis/visit.rst index a19d7c7c3e7..e11be8638c7 100644 --- a/Docs/source/dataanalysis/visit.rst +++ b/Docs/source/dataanalysis/visit.rst @@ -26,7 +26,7 @@ Assuming that you ran a 2D simulation, here are instructions for making a simple Your image should look similar to the one below .. figure:: Ez.png - :alt: picture + :alt: figure not found In 3D, you must apply the “Operators” -> “Slicing” diff --git a/Docs/source/dataanalysis/visualpic.rst b/Docs/source/dataanalysis/visualpic.rst index a43e234c04a..57fe410b812 100644 --- a/Docs/source/dataanalysis/visualpic.rst +++ b/Docs/source/dataanalysis/visualpic.rst @@ -32,9 +32,11 @@ Example: ``vpic3d -s beam -rho -Ez diags/diag1/`` could be used to visualize the Example: ``vpic3d -Ex diags/diag1/`` could be used to visualize the transverse focusing field :math:`E_x` in a plasma wake behind a laser pulse (linearly polarized in :math:`E_y`), see below: .. figure:: https://user-images.githubusercontent.com/1353258/233236692-4d75b12f-de44-43dc-97bd-c96b04ee68ac.png - :alt: Example view of a 3D rendering with VisualPIC. + :alt: figure not found :width: 100% + Example view of a 3D rendering with VisualPIC. + The **Python script** controlled rendering allows more flexible options, such as selecting and cutting views, rendering directly into an image file, looping for animations, etc. As with matplotlib scripts, Python script scenes can also be used to open a GUI and then browse time series interactively. The `VisualPIC examples `__ provide showcases for scripting. diff --git a/Docs/source/dataanalysis/workflows/tunneling.rst b/Docs/source/dataanalysis/workflows/tunneling.rst index 650500a1b92..b900d441ace 100644 --- a/Docs/source/dataanalysis/workflows/tunneling.rst +++ b/Docs/source/dataanalysis/workflows/tunneling.rst @@ -52,5 +52,7 @@ To close the connection down, do this: * ``Ctrl+C`` the SSH tunnel in terminal B .. figure:: https://user-images.githubusercontent.com/1353258/232120440-3965fa38-9ca6-4621-a100-2da74eb899cf.png - :alt: Example view of remote started Jupyter service, active SSH tunnel, and local browser connecting to the service. + :alt: figure not found :width: 100% + + Example view of remote started Jupyter service, active SSH tunnel, and local browser connecting to the service. diff --git a/Docs/source/developers/checksum.rst b/Docs/source/developers/checksum.rst index ccbea3408ef..ce486ed6e57 100644 --- a/Docs/source/developers/checksum.rst +++ b/Docs/source/developers/checksum.rst @@ -89,17 +89,23 @@ Alternatively, the benchmarks can be reset using the output of the Azure continu * On the Github page of the Pull Request, find (one of) the pipeline(s) failing due to benchmarks that need to be updated and click on "Details". .. figure:: https://user-images.githubusercontent.com/49716072/135133589-1fd8a626-ff93-4b9e-983f-acee028e0e4e.png - :alt: Screen capture showing how to access Azure pipeline output on Github. + :alt: figure not found + + Screen capture showing how to access Azure pipeline output on Github. * Click on "View more details on Azure pipelines". .. figure:: https://user-images.githubusercontent.com/49716072/135133596-8f73afa2-969e-49a4-b4a6-184a4f478a44.png - :alt: Screen capture showing how to access Azure pipeline output on Github. + :alt: figure not found + + Screen capture showing how to access Azure pipeline output on Github. * Click on "Build & test". .. figure:: https://user-images.githubusercontent.com/49716072/135133607-87324124-6145-4589-9a92-dcc8ea9432e4.png - :alt: Screen capture showing how to access Azure pipeline output on Github. + :alt: figure not found + + Screen capture showing how to access Azure pipeline output on Github. From this output, there are two options to reset the benchmarks: @@ -108,7 +114,9 @@ From this output, there are two options to reset the benchmarks: For instance, if the failing test is ``LaserAcceleration_BTD``, this content can be pasted into the file ``Regression/Checksum/benchmarks_json/LaserAcceleration_BTD.json``. .. figure:: https://user-images.githubusercontent.com/49716072/244415944-3199a933-990b-4bde-94b1-162b7e8e22be.png - :alt: Screen capture showing how to read new benchmark file from Azure pipeline output. + :alt: figure not found + + Screen capture showing how to read new benchmark file from Azure pipeline output. #. If there are many tests failing in a single Azure pipeline, it might become more convenient to update the benchmarks automatically. WarpX provides a script for this, located in ``Tools/DevUtils/update_benchmarks_from_azure_output.py``. @@ -117,12 +125,16 @@ From this output, there are two options to reset the benchmarks: * From the Azure output, click on "View raw log". .. figure:: https://user-images.githubusercontent.com/49716072/135133617-764b6daf-a8e4-4a50-afae-d4b3a7568b2f.png - :alt: Screen capture showing how to download raw Azure pipeline output. + :alt: figure not found + + Screen capture showing how to download raw Azure pipeline output. * This should lead to a page that looks like the image below. Save it as a text file on your local computer. .. figure:: https://user-images.githubusercontent.com/49716072/135133624-310df207-5f87-4260-9917-26d5af665d60.png - :alt: Screen capture showing how to download raw Azure pipeline output. + :alt: figure not found + + Screen capture showing how to download raw Azure pipeline output. * On your local computer, go to the WarpX folder and cd to the ``Tools/DevUtils`` folder. diff --git a/Docs/source/theory/amr.rst b/Docs/source/theory/amr.rst index d83b1d7db9d..b255eb08fc4 100644 --- a/Docs/source/theory/amr.rst +++ b/Docs/source/theory/amr.rst @@ -6,7 +6,7 @@ Mesh refinement .. _fig_ESAMR: .. figure:: ICNSP_2011_Vay_fig1.png - :alt: Sketches of the implementation of mesh refinement in WarpX with the electrostatic (left) and electromagnetic (right) solvers. In both cases, the charge/current from particles are deposited at the finest levels first, then interpolated recursively to coarser levels. In the electrostatic case, the potential is calculated first at the coarsest level :math:`L_0`, the solution interpolated to the boundaries of the refined patch :math:`r` at the next level :math:`L_{1}` and the potential calculated at :math:`L_1`. The procedure is repeated iteratively up to the highest level. In the electromagnetic case, the fields are computed independently on each grid and patch without interpolation at boundaries. Patches are terminated by absorbing layers (PML) to prevent the reflection of electromagnetic waves. Additional coarse patch :math:`c` and fine grid :math:`a` are needed so that the full solution is obtained by substitution on :math:`a` as :math:`F_{n+1}(a)=F_{n+1}(r)+I[F_n( s )-F_{n+1}( c )]` where :math:`F` is the field, and :math:`I` is a coarse-to-fine interpolation operator. In both cases, the field solution at a given level :math:`L_n` is unaffected by the solution at higher levels :math:`L_{n+1}` and up, allowing for mitigation of some spurious effects (see text) by providing a transition zone via extension of the patches by a few cells beyond the desired refined area (red & orange rectangles) in which the field is interpolated onto particles from the coarser parent level only. + :alt: figure not found :width: 95% Sketches of the implementation of mesh refinement in WarpX with the electrostatic (left) and electromagnetic (right) solvers. In both cases, the charge/current from particles are deposited at the finest levels first, then interpolated recursively to coarser levels. In the electrostatic case, the potential is calculated first at the coarsest level :math:`L_0`, the solution interpolated to the boundaries of the refined patch :math:`r` at the next level :math:`L_{1}` and the potential calculated at :math:`L_1`. The procedure is repeated iteratively up to the highest level. In the electromagnetic case, the fields are computed independently on each grid and patch without interpolation at boundaries. Patches are terminated by absorbing layers (PML) to prevent the reflection of electromagnetic waves. Additional coarse patch :math:`c` and fine grid :math:`a` are needed so that the full solution is obtained by substitution on :math:`a` as :math:`F_{n+1}(a)=F_{n+1}(r)+I[F_n( s )-F_{n+1}( c )]` where :math:`F` is the field, and :math:`I` is a coarse-to-fine interpolation operator. In both cases, the field solution at a given level :math:`L_n` is unaffected by the solution at higher levels :math:`L_{n+1}` and up, allowing for mitigation of some spurious effects (see text) by providing a transition zone via extension of the patches by a few cells beyond the desired refined area (red & orange rectangles) in which the field is interpolated onto particles from the coarser parent level only. @@ -25,7 +25,7 @@ A sketch of the implementation of mesh refinement in WarpX is given in :numref:` .. _fig_ESselfforce: .. figure:: ICNSP_2011_Vay_fig2.png - :alt: Position history of one charged particle attracted by its image induced by a nearby metallic (dirichlet) boundary. The particle is initialized at rest. Without refinement patch (reference case), the particle is accelerated by its image, is reflected specularly at the wall, then decelerates until it reaches its initial position at rest. If the particle is initialized inside a refinement patch, the particle is initially accelerated toward the wall but is spuriously reflected before it reaches the boundary of the patch whether using the method implemented in WarpX or the MC method. Providing a surrounding transition region 2 or 4 cells wide in which the potential is interpolated from the parent coarse solution reduces significantly the effect of the spurious self-force. + :alt: figure not found :width: 95% Position history of one charged particle attracted by its image induced by a nearby metallic (dirichlet) boundary. The particle is initialized at rest. Without refinement patch (reference case), the particle is accelerated by its image, is reflected specularly at the wall, then decelerates until it reaches its initial position at rest. If the particle is initialized inside a refinement patch, the particle is initially accelerated toward the wall but is spuriously reflected before it reaches the boundary of the patch whether using the method implemented in WarpX or the MC method. Providing a surrounding transition region 2 or 4 cells wide in which the potential is interpolated from the parent coarse solution reduces significantly the effect of the spurious self-force. @@ -35,7 +35,7 @@ The presence of the self-force is illustrated on a simple test case that was int .. _fig_ESselfforcemap: .. figure:: ICNSP_2011_Vay_fig3.png - :alt: (left) Maps of the magnitude of the spurious self-force :math:`\epsilon` in arbitrary units within one quarter of the refined patch, defined as :math:`\epsilon=\sqrt{(E_x-E_x^{ref})^2+(E_y-E_y^{ref})^2}`, where :math:`E_x` and :math:`E_y` are the electric field components within the patch experienced by one particle at a given location and :math:`E_x^{ref}` and :math:`E_y^{ref}` are the electric field from a reference solution. The map is given for the WarpX and the MC mesh refinement algorithms and for linear and quadratic interpolation at the patch refinement boundary. (right) Lineouts of the maximum (taken over neighboring cells) of the spurious self-force. Close to the interface boundary (x=0), the spurious self-force decreases at a rate close to one order of magnitude per cell (red line), then at about one order of magnitude per six cells (green line). + :alt: figure not found :width: 95% (left) Maps of the magnitude of the spurious self-force :math:`\epsilon` in arbitrary units within one quarter of the refined patch, defined as :math:`\epsilon=\sqrt{(E_x-E_x^{ref})^2+(E_y-E_y^{ref})^2}`, where :math:`E_x` and :math:`E_y` are the electric field components within the patch experienced by one particle at a given location and :math:`E_x^{ref}` and :math:`E_y^{ref}` are the electric field from a reference solution. The map is given for the WarpX and the MC mesh refinement algorithms and for linear and quadratic interpolation at the patch refinement boundary. (right) Lineouts of the maximum (taken over neighboring cells) of the spurious self-force. Close to the interface boundary (x=0), the spurious self-force decreases at a rate close to one order of magnitude per cell (red line), then at about one order of magnitude per six cells (green line). diff --git a/Docs/source/theory/boosted_frame.rst b/Docs/source/theory/boosted_frame.rst index 04c30bedc98..9bd0c041f2a 100644 --- a/Docs/source/theory/boosted_frame.rst +++ b/Docs/source/theory/boosted_frame.rst @@ -8,7 +8,7 @@ The simulations of plasma accelerators from first principles are extremely compu .. _fig_Boosted_frame: .. figure:: Boosted_frame.png - :alt: [fig:Boosted-frame] A first principle simulation of a short driver beam (laser or charged particles) propagating through a plasma that is orders of magnitude longer necessitates a very large number of time steps. Recasting the simulation in a frame of reference that is moving close to the speed of light in the direction of the driver beam leads to simulating a driver beam that appears longer propagating through a plasma that appears shorter than in the laboratory. Thus, this relativistic transformation of space and time reduces the disparity of scales, and thereby the number of time steps to complete the simulation, by orders of magnitude. + :alt: figure not found A first principle simulation of a short driver beam (laser or charged particles) propagating through a plasma that is orders of magnitude longer necessitates a very large number of time steps. Recasting the simulation in a frame of reference that is moving close to the speed of light in the direction of the driver beam leads to simulating a driver beam that appears longer propagating through a plasma that appears shorter than in the laboratory. Thus, this relativistic transformation of space and time reduces the disparity of scales, and thereby the number of time steps to complete the simulation, by orders of magnitude. diff --git a/Docs/source/theory/boosted_frame/input_output.rst b/Docs/source/theory/boosted_frame/input_output.rst index f47915116df..712642e312e 100644 --- a/Docs/source/theory/boosted_frame/input_output.rst +++ b/Docs/source/theory/boosted_frame/input_output.rst @@ -15,7 +15,7 @@ Inputs and outputs in a boosted frame simulation .. _fig_inputoutput: .. figure:: Input_output.png - :alt: (top) Snapshot of a particle beam showing “frozen" (grey spheres) and “active" (colored spheres) macroparticles traversing the injection plane (red rectangle). (bottom) Snapshot of the beam macroparticles (colored spheres) passing through the background of electrons (dark brown streamlines) and the diagnostic stations (red rectangles). The electrons, the injection plane and the diagnostic stations are fixed in the laboratory plane, and are thus counter-propagating to the beam in a boosted frame. + :alt: figure not found :width: 100% (top) Snapshot of a particle beam showing “frozen" (grey spheres) and “active" (colored spheres) macroparticles traversing the injection plane (red rectangle). (bottom) Snapshot of the beam macroparticles (colored spheres) passing through the background of electrons (dark brown streamlines) and the diagnostic stations (red rectangles). The electrons, the injection plane and the diagnostic stations are fixed in the laboratory plane, and are thus counter-propagating to the beam in a boosted frame. diff --git a/Docs/source/theory/boundary_conditions.rst b/Docs/source/theory/boundary_conditions.rst index 395b072ccbe..74bf4bd3cfe 100644 --- a/Docs/source/theory/boundary_conditions.rst +++ b/Docs/source/theory/boundary_conditions.rst @@ -294,7 +294,7 @@ the right boundary is reflecting. .. _fig_PEC_boundary_deposition: .. figure:: https://user-images.githubusercontent.com/40245517/221491318-b0a2bcbc-b04f-4b8c-8ec5-e9c92e55ee53.png - :alt: Plot of PEC boundary current deposition showing current vs position along the ``x``-axis. + :alt: figure not found :width: 100% PEC boundary current deposition along the ``x``-axis. The left boundary is absorbing while the right boundary is reflecting. diff --git a/Docs/source/theory/cold_fluid_model.rst b/Docs/source/theory/cold_fluid_model.rst index 813a568c540..4cabc5653f6 100644 --- a/Docs/source/theory/cold_fluid_model.rst +++ b/Docs/source/theory/cold_fluid_model.rst @@ -45,9 +45,9 @@ Implementation details .. _fig_fluid_loop: .. figure:: https://github.com/ECP-WarpX/WarpX/assets/69021085/dcbcc0e4-7899-43e4-b580-f57eb359b457 - :alt: Figure showing fluid Loop embedded within the overall PIC loop. + :alt: figure not found - Fluid Loop embedded within the overall PIC loop. + Fluid loop embedded within the overall PIC loop. The fluid timeloop is embedded inside the standard PIC timeloop and consists of the following steps: 1. Higuera and Cary push of the momentum 2. Non-inertial (momentum source) diff --git a/Docs/source/theory/intro.rst b/Docs/source/theory/intro.rst index 2101d9d81cb..c6d56511e3f 100644 --- a/Docs/source/theory/intro.rst +++ b/Docs/source/theory/intro.rst @@ -4,7 +4,7 @@ Introduction ============ .. figure:: Plasma_acceleration_sim.png - :alt: Plasma laser-driven (top) and charged-particles-driven (bottom) acceleration (rendering from 3-D Particle-In-Cell simulations). A laser beam (red and blue disks in top picture) or a charged particle beam (red dots in bottom picture) propagating (from left to right) through an under-dense plasma (not represented) displaces electrons, creating a plasma wakefield that supports very high electric fields (pale blue and yellow). These electric fields, which can be orders of magnitude larger than with conventional techniques, can be used to accelerate a short charged particle beam (white) to high-energy over a very short distance. + :alt: figure not found Plasma laser-driven (top) and charged-particles-driven (bottom) acceleration (rendering from 3-D Particle-In-Cell simulations). A laser beam (red and blue disks in top picture) or a charged particle beam (red dots in bottom picture) propagating (from left to right) through an under-dense plasma (not represented) displaces electrons, creating a plasma wakefield that supports very high electric fields (pale blue and yellow). These electric fields, which can be orders of magnitude larger than with conventional techniques, can be used to accelerate a short charged particle beam (white) to high-energy over a very short distance. diff --git a/Docs/source/theory/multiphysics/collisions.rst b/Docs/source/theory/multiphysics/collisions.rst index 08485345a13..0c23541b156 100644 --- a/Docs/source/theory/multiphysics/collisions.rst +++ b/Docs/source/theory/multiphysics/collisions.rst @@ -150,8 +150,10 @@ See for example :cite:t:`b-Lim2007` for a derivation. The result is that given a The impact of incorporating relativistic effects in the MCC routine can be seen in the plots below where high energy collisions are considered with both a classical and relativistic implementation of MCC. It is observed that the classical version of MCC reproduces the classical limit of the above equation but especially for ions, this result differs substantially from the fully relativistic result. .. figure:: https://user-images.githubusercontent.com/40245517/170900079-74e505a5-2790-44f5-ac84-5847eda954e6.png - :alt: Classical v relativistic MCC + :alt: figure not found :width: 96% + Classical vs relativistic MCC. + .. bibliography:: :keyprefix: b- diff --git a/Docs/source/theory/pic.rst b/Docs/source/theory/pic.rst index 8356ba9f0f8..b4d7214329e 100644 --- a/Docs/source/theory/pic.rst +++ b/Docs/source/theory/pic.rst @@ -6,7 +6,7 @@ Particle-in-Cell Method .. _fig-pic: .. figure:: PIC.png - :alt: [fig:PIC] The Particle-In-Cell (PIC) method follows the evolution of a collection of charged macro-particles (positively charged in blue on the left plot, negatively charged in red) that evolve self-consistently with their electromagnetic (or electrostatic) fields. The core PIC algorithm involves four operations at each time step: 1) evolve the velocity and position of the particles using the Newton-Lorentz equations, 2) deposit the charge and/or current densities through interpolation from the particles distributions onto the grid, 3) evolve Maxwell’s wave equations (for electromagnetic) or solve Poisson’s equation (for electrostatic) on the grid, 4) interpolate the fields from the grid onto the particles for the next particle push. Additional “add-ons” operations are inserted between these core operations to account for additional physics (e.g. absorption/emission of particles, addition of external forces to account for accelerator focusing or accelerating component) or numerical effects (e.g. smoothing/filtering of the charge/current densities and/or fields on the grid). + :alt: figure not found The Particle-In-Cell (PIC) method follows the evolution of a collection of charged macro-particles (positively charged in blue on the left plot, negatively charged in red) that evolve self-consistently with their electromagnetic (or electrostatic) fields. The core PIC algorithm involves four operations at each time step: 1) evolve the velocity and position of the particles using the Newton-Lorentz equations, 2) deposit the charge and/or current densities through interpolation from the particles distributions onto the grid, 3) evolve Maxwell’s wave equations (for electromagnetic) or solve Poisson’s equation (for electrostatic) on the grid, 4) interpolate the fields from the grid onto the particles for the next particle push. Additional “add-ons” operations are inserted between these core operations to account for additional physics (e.g. absorption/emission of particles, addition of external forces to account for accelerator focusing or accelerating component) or numerical effects (e.g. smoothing/filtering of the charge/current densities and/or fields on the grid). @@ -173,7 +173,7 @@ is described in, e.g., :cite:t:`pt-VayCSD12,pt-Vaycpc04`. .. _fig_yee_grid: .. figure:: Yee_grid.png - :alt: [fig:yee_grid](left) Layout of field components on the staggered “Yee” grid. Current densities and electric fields are defined on the edges of the cells and magnetic fields on the faces. (right) Time integration using a second-order finite-difference "leapfrog" integrator. + :alt: figure not found (left) Layout of field components on the staggered “Yee” grid. Current densities and electric fields are defined on the edges of the cells and magnetic fields on the faces. (right) Time integration using a second-order finite-difference "leapfrog" integrator. @@ -456,7 +456,7 @@ During these subintervals, :math:`\boldsymbol{\widetilde{J}}` and :math:`\wideti .. _fig-psatd_jrhom: .. figure:: https://gist.githubusercontent.com/oshapoval/88a73cada764364ad4ffce13563cedf1/raw/697ce1897cde0416bebdde8f1c1e8fcf859cb419/psatd_jrhom.png - :alt: figure not found, caption only + :alt: figure not found Diagrams illustrating various time dependencies of the current density :math:`\boldsymbol{\widetilde{J}}` and charge density :math:`\widetilde{\rho}` for constant/linear (CL), both constant (CC), linear (LL) and quadratic (QQ) dependencies with :math:`m` subintervals: (first column) :math:`m=1`, (second) :math:`m=2` and (third) :math:`m=4`. CL1 corresponds to the standard PSATD PIC method. The triangle and circle glyphs represent the times at which the macroparticles deposit :math:`\boldsymbol{\widetilde{J}}` and :math:`\widetilde{\rho}` on the grid, respectively. The dashed and solid lines represent the assumed time dependency of :math:`\boldsymbol{\widetilde{J}}` and :math:`\widetilde{\rho}` within one time step, when integrating the Maxwell equations analytically. @@ -503,9 +503,8 @@ Here, :math:`\boldsymbol{a_J}, \boldsymbol{b_J}, \boldsymbol{c_J}, a_{\rho}, b_{ .. _fig-j_rho_table: -.. figure:: - https://gist.githubusercontent.com/oshapoval/88a73cada764364ad4ffce13563cedf1/raw/ebc249f8e875a952c65a5319fd523821baccfd5a/j_rho_table.png - :alt: figure not found, caption only +.. figure:: https://gist.githubusercontent.com/oshapoval/88a73cada764364ad4ffce13563cedf1/raw/ebc249f8e875a952c65a5319fd523821baccfd5a/j_rho_table.png + :alt: figure not found Polynomial coefficients based on the time dependency of the current and charge densities :math:`{\boldsymbol{\widetilde{J}}}(t)` and :math:`\widetilde{\rho}(t)` over one time subinterval, :math:`\delta t = \Delta t/m`. diff --git a/Docs/source/usage/faq.rst b/Docs/source/usage/faq.rst index 4ed0f8fa6af..88f3198d88c 100644 --- a/Docs/source/usage/faq.rst +++ b/Docs/source/usage/faq.rst @@ -65,9 +65,9 @@ What about Back-transformed diagnostics (BTD)? ---------------------------------------------- .. figure:: https://user-images.githubusercontent.com/10621396/198702232-9dd595ad-479e-4170-bd25-51e2b72cd50a.png - :alt: [fig:BTD_features] Minkowski diagram indicating several features of the back-transformed diagnostic (BTD). The diagram explains why the first BTD begins to fill at boosted time :math:`t'=0` but this doesn't necessarily correspond to lab time :math:`t=0`, how the BTD grid-spacing is determined by the boosted time step :math:`\Delta t'`, hence why the snapshot length don't correspond to the grid spacing and length in the input script, and how the BTD snapshots complete when the effective snapshot length is covered in the boosted frame. + :alt: figure not found - [fig:BTD_features] Minkowski diagram indicating several features of the back-transformed diagnostic (BTD). The diagram explains why the first BTD begins to fill at boosted time :math:`t'=0` but this doesn't necessarily correspond to lab time :math:`t=0`, how the BTD grid-spacing is determined by the boosted time step :math:`\Delta t'`, hence why the snapshot length don't correspond to the grid spacing and length in the input script, and how the BTD snapshots complete when the effective snapshot length is covered in the boosted frame. + Minkowski diagram indicating several features of the back-transformed diagnostic (BTD). The diagram explains why the first BTD begins to fill at boosted time :math:`t'=0` but this doesn't necessarily correspond to lab time :math:`t=0`, how the BTD grid-spacing is determined by the boosted time step :math:`\Delta t'`, hence why the snapshot length don't correspond to the grid spacing and length in the input script, and how the BTD snapshots complete when the effective snapshot length is covered in the boosted frame. Several BTD quantities differ slightly from the lab frame domain described in the input deck. diff --git a/Docs/source/usage/pwfa.rst b/Docs/source/usage/pwfa.rst index 1d3481b5589..56af63b74c0 100644 --- a/Docs/source/usage/pwfa.rst +++ b/Docs/source/usage/pwfa.rst @@ -26,7 +26,9 @@ The plasma, of total length L, has a density profile that consists of a lr long With this configuration the driver excites a nonlinear plasma wake and drives the bubble depleted of plasma electrons where the beam accelerates, as can be seen in Fig. `[fig:PWFA] <#fig:PWFA>`__. .. figure:: PWFA.png - :alt: [fig:PWFA] Plot of 2D PWFA example at dump 1000 + :alt: figure not found + + Plot of 2D PWFA example at dump 1000. [fig:PWFA] Plot of the driver (blue), beam (red) and plasma_e (green) electron macroparticle distribution at the time step 1000 of the example simulation. These are overlapping the 2D plot of the longitudinal electric field showing the accelerating/deccelerating (red/blue) regions of the plasma bubble. diff --git a/Docs/source/usage/workflows/ml_dataset_training.rst b/Docs/source/usage/workflows/ml_dataset_training.rst index 450e0fe2879..a351b7853d9 100644 --- a/Docs/source/usage/workflows/ml_dataset_training.rst +++ b/Docs/source/usage/workflows/ml_dataset_training.rst @@ -33,7 +33,7 @@ Looking closer at the z-pz space, we see that some particles were not trapped in .. _fig_unclean_phase_space: .. figure:: https://gist.githubusercontent.com/RTSandberg/649a81cc0e7926684f103729483eff90/raw/095ac2daccbcf197fa4e18a8f8505711b27e807a/unclean_stage_0.png - :alt: Plot showing the final phase space projections of a particle beam through a laser-plasma acceleration element where some beam particles were not accelerated. + :alt: figure not found The final phase space projections of a particle beam through a laser-plasma acceleration element where some beam particles were not accelerated. @@ -45,7 +45,7 @@ After filtering, we can see in :numref:`fig_clean_phase_space` that the beam pha .. _fig_clean_phase_space: .. figure:: https://gist.githubusercontent.com/RTSandberg/649a81cc0e7926684f103729483eff90/raw/095ac2daccbcf197fa4e18a8f8505711b27e807a/clean_stage_0.png - :alt: Plot showing the final phase space projections of a particle beam through a laser-plasma acceleration element after filtering out outlying particles. + :alt: figure not found The final phase space projections of a particle beam through a laser-plasma acceleration element after filtering out outlying particles. @@ -246,14 +246,14 @@ When the test-loss starts to trend flat or even upward, the neural network is no .. _fig_train_test_loss: .. figure:: https://gist.githubusercontent.com/RTSandberg/649a81cc0e7926684f103729483eff90/raw/095ac2daccbcf197fa4e18a8f8505711b27e807a/beam_stage_0_training_testing_error.png - :alt: Plot of training and testing loss curves versus number of training epochs. + :alt: figure not found Training (in blue) and testing (in green) loss curves versus number of training epochs. .. _fig_train_evaluation: .. figure:: https://gist.githubusercontent.com/RTSandberg/649a81cc0e7926684f103729483eff90/raw/095ac2daccbcf197fa4e18a8f8505711b27e807a/beam_stage_0_model_evaluation.png - :alt: Plot comparing model prediction with simulation output. + :alt: figure not found A comparison of model prediction (yellow-red dots, colored by mean-squared error) with simulation output (black dots). diff --git a/Docs/source/usage/workflows/plot_distribution_mapping.rst b/Docs/source/usage/workflows/plot_distribution_mapping.rst index 7e22ff6ba19..eddf1f5acf8 100644 --- a/Docs/source/usage/workflows/plot_distribution_mapping.rst +++ b/Docs/source/usage/workflows/plot_distribution_mapping.rst @@ -144,7 +144,7 @@ This generates plots like in `[fig:knapsack_sfc_distribution_mapping_2D] <#fig:k \centering .. figure:: knapsack_sfc_distribution_mapping_2D.png - :alt: Sample distribution mappings from simulations with knapsack (left) and space-filling curve (right) policies for update of the distribution mapping when load balancing. + :alt: figure not found :name: fig:knapsack_sfc_distribution_mapping_2D :width: 15cm @@ -177,7 +177,7 @@ This generates plots like in `[fig:knapsack_sfc_costs_2D] <#fig:knapsack_sfc_cos \centering .. figure:: knapsack_sfc_costs_2D.png - :alt: Sample computational cost per box from simulations with knapsack (left) and space-filling curve (right) policies for update of the distribution mapping when load balancing. + :alt: figure not found :name: fig:knapsack_sfc_costs_2D :width: 15cm @@ -268,7 +268,7 @@ This generates plots like in `[fig:distribution_mapping_3D] <#fig:distribution_m \centering .. figure:: distribution_mapping_3D.png - :alt: Sample distribution mappings from 3D simulations, visualized as slices in the :math:`ik` plane along :math:`j`. + :alt: figure not found :name: fig:distribution_mapping_3D :width: 15cm