Laser back scattering

[cbontoiu]

Hello,

I am struggling to find the "perfect" absorber power and thickness at the positive y end. I use 32 cells so for the laser initPlaneY = 33u and 1e-03 for the absorber power but I get a massive laser wave bouncing back. Is this because of my plasma density settings? Is it because of the short laser wavelength? am I missing anything here?

I attach the model using the typical absorber as defined in grid.param but I get a similar effect when using PML. What are my choices?

single-thick-tube-3d.zip

Many thanks.
Cristian

[PrometheusPi]

@cbontoiu Thanks for posting this question. It might be (unintuitively) caused by the details of your laser setup.

Could you please state the following details of your setup:

• number of iterations when the laser reaches the TOP (positive-y boundary)
• time step duration
• your laser's initialization time: fields::laserProfiles::Selected::INIT_TIME

According to our absorber rules, the positive y-axis absorber without moving window is only active if t = DELTA_T_SI * number_of_iterations > fields::laserProfiles::Selected::INIT_TIME.

@psychocoderHPC I remember you explained to me, why we had this rule years ago. But I do not remember. Could you state the reason why we have this rule?

[sbastrakov]

@PrometheusPi I believe what you wrote applies for the min y boundary, while the reflection observed is at max y boundary? There is a set of .param files attached. However I can't figure which .cfg file you used @cbontoiu ?

[sbastrakov]

I think i understand The logic of that condition you mentioned, it is to properly generate the laser with initial plane y at 0. However again I don't think it's what causes the problem here

[cbontoiu]

@sbastrakov to run my simulation I use

tbg -s bash -c etc/picongpu/runConfiguration.cfg -t etc/picongpu/bash/mpiexec.tpl

with TBG_periodic="--periodic 1 0 1" so there should be an absorber at the positive y side.

[cbontoiu]

Hello @PrometheusPi and @sbastrakov and many thanks for looking into this problem.

It seems that the laser pulse reaches the positive y absorber around t = 40 fs, and that corresponds to 9620 iterations. I don't know how to obtain fields::laserProfiles::Selected::INIT_TIME. Is it the time it will take to fly from y = 0 to y = initPlaneY = 33u? That would be 0.192 fs. I attach my laser.param file.

laser.param.txt

[PrometheusPi]

@sbastrakov Sorry - you are right. I got confused with the old naming. "TOP" is negative-y. Thus this does not explain the issue.

[cbontoiu]

I attach a similar gif with slightly different laser parameters. It is interesting that the second half of the pulse is greatly affected by the interaction with the tubular plasma around t = 30 fs which is the full pulse duration.

[sbastrakov]

So that INIT_TIME seems to be unrelated. If you were wondering, for the PlaneWave laser it is computed from your laser parameters as here. But as a user you normally don't need to worry about it.

[cbontoiu]

More parameters:

This simulation is without the moving window. Two GPUs deal with the y-direction. However, backward reflection was noticed even with a moving window. Any suggestion is greatly valued.

[sbastrakov]

@cbontoiu sorry, it is all somewhat confusing. It is hopefully simplified later this year.

So with moving window enabled. Our assumption is that the whole laser (or the "only important" part) fits the global domain in y (not counting the extra 1 GPU layer in y). So we operate as follows: the laser is first generated at near min y boundary according to initPlaneY and other user-set parameters. Then it propagates towards positive y. At some point, specified by a user but before the laser hits the positive y boundary, the window starts moving. Because of this assumed mode, we disable positive y absorber as nothing could hit it anyhow. There are also technical details and reasons there, but from a user side should look like this. It can explain reflections like you saw, if your laser does not fit the domain.

With the moving window disabled, we do not do that manipulation. Since your attached runConfiguration.cfg had it disabled, I do not understand why reflection happened.

[sbastrakov]

With respect to my last point, just to be sure could you attach file tbg/submit.cfg from the resulting directory on the run that generated the gif your first message in this issue.

[cbontoiu]

With respect to my last point, just to be sure could you attach file tbg/submit.cfg from the resulting directory on the run that generated the gif your first message in this issue.

Hello @sbastrakov he re is the file

submit.cfg.txt

Thank you

[sbastrakov]

Thanks. So moving window is indeed off. So far I am out of ideas, will run a small simulation tomorrow with such a 1x2x1 devices and laser to investigate further

[cbontoiu]

Hello,

I observed this problem again on an array of tubes as shown in the gif attached. The unusual settings from the gas-plasma PIC simulations are:

• the moving point is set to 1.25;
• the plasma density is 1e22 cm^-3
• the laser wavelength is 50 nm, so very small
• the FWHM pulse duration is 1 fs, so very small

The cfg file is called runConfiguration.cfg. Any hint on how to overcome this problem is appreciated. Kind regards,

submit.cfg.txt

Cristian

hex-array-thick-tubes.zip

[cbontoiu]

I just read that this backscattering might be a natural phenomenon. Basically the plasma is compressed by the laser pulse and at some point when the laser pulse is depleted enough, explodes backwards sending EM waves so not the laser pulse, but is just a guess. I am not sure that this is the case

[PrometheusPi]

@cbontoiu Yes, light is always scattered. IN the underdense case, only a small fraction is scattered in backward direction. In he overdense case, only backward scattering occurs.

I am not sure if setting the move point to a value >1 is valid. @psychocoderHPC could you comment on that.
That could mean that your sliding starts after (parts of) the laser hits the back of the simulation box.

What densities do you reach during the simulation (due to self compression of the tubes) and what longitudinal momentum do the electrons reach?

[psychocoderHPC]

Setting slide point to >1 will destroy the physics because the longitudinal field will hit the simulation bonderie. The default 0.9 is choosen to avoid that numerical artifacts will touch the simulation box. Am 8. März 2021 15:35:35 MEZ schrieb Richard Pausch <notifications@github.com>:

…

@cbontoiu Yes, light is always scattered. IN the underdense case, only a small fraction is scattered in backward direction. In he overdense case, only backward scattering occurs. I am not sure if setting the move point to a value >1 is valid. @psychocoderHPC could you comment on that. That could mean that your sliding starts after (parts of) the laser hits the back of the simulation box. What densities do you reach during the simulation (due to self compression of the tubes) and what longitudinal momentum do the electrons reach? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #3511 (comment)

[cbontoiu]

@cbontoiu Yes, light is always scattered. IN the underdense case, only a small fraction is scattered in backward direction. In he overdense case, only backward scattering occurs.

I am not sure if setting the move point to a value >1 is valid. @psychocoderHPC could you comment on that.
That could mean that your sliding starts after (parts of) the laser hits the back of the simulation box.

What densities do you reach during the simulation (due to self compression of the tubes) and what longitudinal momentum do the electrons reach?

Actually, I don't know how to extract the longitudinal/transverse momentum. All I can do so far is to extract the energy and I assume it is kinetic energy expressed in J.

[cbontoiu]

Setting slide point to >1 will destroy the physics because the longitudinal field will hit the simulation bonderie. The default 0.9 is choosen to avoid that numerical artifacts will touch the simulation box. Am 8. März 2021 15:35:35 MEZ schrieb Richard Pausch notifications@github.com:
…
@cbontoiu Yes, light is always scattered. IN the underdense case, only a small fraction is scattered in backward direction. In he overdense case, only backward scattering occurs. I am not sure if setting the move point to a value >1 is valid. @psychocoderHPC could you comment on that. That could mean that your sliding starts after (parts of) the laser hits the back of the simulation box. What densities do you reach during the simulation (due to self compression of the tubes) and what longitudinal momentum do the electrons reach? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #3511 (comment)

Thank you. This is really important to know. I pushed the moving point beyond one just be able to to see more of the pulse tail while still keeping the simulation domain small and get the 0.25 nm mesh resolution. It all stems from the fact that I have only two GPUs on my machine.

[PrometheusPi]

@cbontoiu To extract the momentum, you can use the phase space plugin or the openPMD based output. For density you can use the openPMD based output. It contains (by default) the density of each species. The openPMD-viewer allows to visualize momentum distribution, phase space and density plots.