Skip to content

Add files via upload - #876

Open
swainkipr wants to merge 2 commits into
SmileiPIC:developfrom
swainkipr:master
Open

Add files via upload#876
swainkipr wants to merge 2 commits into
SmileiPIC:developfrom
swainkipr:master

Conversation

@swainkipr

@swainkipr swainkipr commented Apr 22, 2026

Copy link
Copy Markdown

This PR introduces a new laser snippet to src/Python/pyprofiles.py designed to interface Lasy with Smilei's Azimuthal Mode (AM) solver. The goal is to allow users to import realistic experimental laser profiles directly into cylindrical geometry simulations.
Key Implementation Details:

  • Converts Lasy's $E_x$ envelope to the $B_z$ field required by Smilei.
  • Uses the reconstruct_rt_field_lasy function to build the $B_z(\theta, t, r)$ field from the mode components stored in Lasy’s openPMD/hdf5 format.
  • Computes the real and imaginary parts of $B_r^m$ and $B_{\theta}^m$ for the Azimuthal Mode decomposition.
  • Ensures the simulation time window remains valid with the condition $MovingWindow(time_{start}) < N_{time} \times dt$.

I have tested in vacuum to ensure this workflow works well. Here I am attaching the namelist and the input laserfilefromlasy.
laserfileFromlasy.tar.gz
namelist.py
pyprofiles.py
Lasy_smilei_workflow.pdf

@beck-llr

beck-llr commented Apr 27, 2026

Copy link
Copy Markdown
Contributor

Thank you @swainkipr . This is a very interesting PR but I won't have time to review it seriously before at least 2 weeks.
@Z10Frank and @mccoys don't hesitate to have a look, this might interest you as well.

@Z10Frank

Copy link
Copy Markdown
Contributor

Hello @swainkipr,
thanks a lot! I like the idea of having a profile in pyprofiles.py to import a laser using LASY.
I have a few initial comments:

  1. For integration, the function should be made more general, for example at the moment the carrier wavelength of the laser is hard-coded to lambda0 = 0.8e-6, and the reference frequency in a namelist may not always be equal to 2pi/lambda0, so the carrier would not correspond to a cos(t) in every case, it should be cos(omega*t), where omega is the ratio between the laser carrier frequency and the normalising reference frequency. When the two are the same, omega reduces to 1.
  2. Does LASY store the azimuthal modes of the Cartesian components? In this case, creating a theta_grid and taking the FFT is not necessary, an analytical conversion can be done (Eqs. 33-42 of https://hal.science/hal-05404087v2/document).
  3. Would it be possible to add an import also for laser stored in Cartesian geometries without azimuthal mode decomposition? This can be done later, it's not needed for this pull request.

@swainkipr

Copy link
Copy Markdown
Author

Hello @Z10Frank Thanks for your comments!
You are correct to point out to write a more generalized function. I have made the changes and now its more generalized with respect to the reference_frequency in smilei.

pyprofiles.py
namelist.py

Regarding the second comment, Yes Lasy stores the azimuthal modes. Additionally, Lasy give both options, one can store the modes or just store the input values without decomposing into modes. Here, its the second case.
At the beginning since it was focused on rt-geometry, I was not yet familiar with the Laguerre–Gaussian–based analytical decomposition described in the document; though the approach in the document is definitely interesting to try. Further, the idea of choosing the second case (that is creating a theta grid and taking FFT ) is for the convenience to have more control on smilei parameters and to have an unified algorithm while extending it to Cartesian geometry (in future) with minimal changes.

It is definitely possible to add support for importing a laser defined directly in Cartesian geometry without azimuthal mode decomposition. But then, is it intended to use in Smilei-cartesian or cylindrical? If we use in 3D-cartesian geometry, will it not be computationally expensive with the realistic-laser? Could you help clarify this point?

@beck-llr

Copy link
Copy Markdown
Contributor

Hi
You are doing the PR into the master branch. Please modify it so that it goes to the develop branch.

@beck-llr

Copy link
Copy Markdown
Contributor

@swainkipr The cost of a 3D simulation will be expensive whether the laser used is realistic or not. Introducing a measured laser or a theoretical one doesn't make a difference in the cost of the simulation.
I agree that it would be convenient to extend the possibility to do so also for a Cartesian grid. As pointed out by @Z10Frank , this is not a requirement for this PR.

@beck-llr

Copy link
Copy Markdown
Contributor

From my understanding the reconstruction and computation of modes is needed when going from a Cartesian description to a cylindrical one. From @swainkipr comment I understand that this is the case here. So it is only a particular case of application of Lasy that is supported by this PR. Could it be extended to also support reading the AM modes directly ? (Lasy doc is here https://github.com/LASY-org/lasy)

Also it looks like only Ex(Lasy) / Ey(Smilei) component is imported. This limits the application to linear polarization along this direction only. Could a support for the second transverse component be added ?

@swainkipr
swainkipr changed the base branch from master to develop May 28, 2026 04:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants