The range of temporal evolution of the amplified pulse

[sulfonic-acid]

Hi, Yihao.
Thanks for your generous sharing, these codes are quiet useful to simulate amplifiers.
There is a strange question. I find that all the GMNA files could run successfully, but the coordinate range for time is always almost symmetrical (from -5 to 5 ps).It seems that the simulation for spectral evolution in the gain fiber is successful in GMN process. However, the evolution of pulses does not seem obvious and differs from previous literature in some ways.
I think this range may be influenced by function fft, or for other reasons.
I'm not sure if this is a problem, or rather, I'm not familiar with this aspect (that means the picture is right).
Thank you very much!

file path: GMMNLSE/Examples/Gain-rate-equation model/GMNA

[AaHaHaa]

Hi,

First thanks for using my code. I'm always happy to see that people can find it useful.

The functionality of pulse temporal centering is default to turn on. This means that the pulse is always centered to the time window based on its weighted temporal center: int(t,\abs{A}^2) is shifted to be zero.

This time-shifted information is stored in the output as prop_output.t_delay. The unit is ps, the same as time window.
You can restore the time delay of the pulse by restored_field(:,i) = circshift(prop_output.fields(:,1,i),floor(prop_output.t_delay/dt)).

You can turn this temporal centering off by having sim.pulse_centering = false; before running GMMNLSE_propagate().

Because of periodic nature of Fourier Transform, the pulse can go beyond the time window and come out on the other side. This just looks annoying to me, so I added this temporal pulse centering function to the code. With this, it is also easier to visualize the correct pulse relative positions if you have multiple pulses. For example, if you simulate a soliton fission process, many solitons propagate at different speeds. It's so easy to have one soliton propagate really slowly (if there is Raman SSFS effect) and later go beyond the time window and then appear at the leading edge of the time window. This artificial numerical effect will potentially mislead people to think that there is a pulse that propagates faster than all the others if we don't check the propagation carefully.

Besides, in general, the actual delay of the pulse is usually not important. The time window is moving as well. It's called "moving frame". The time window is moving with the pulse due to beta_(1) in the equation. See Chapter 1 of readme.pdf. If you care about the actual delay, you need to take into account moving frame I think. By the way, if beta_(1) is zero, the simulation will run super slowly. It makes the final beta(omega) huge, and thus the z-stepping cannot be huge. You need to resolve the phase beta*z correctly in simulations to capture many phase-related physics. Therefore, it's important to have beta_(0) and beta_(1) to be values that minimize beta(omega) to speed up simulations. And from physics, we know that applying this mathematical trick doesn't affect the physics regarding phases.

Is this what you're asking?

[sulfonic-acid]

Hi, Yihao.
Yes, this solves my question. I appreciate your detailed answer.

This line of code has an extra letter: sim.pulse_centering = false;

[AaHaHaa]

Oh, thanks. I edited it. A small typo here.

[sulfonic-acid]

I try to use these code, and share results in here.
I get trouble in this code (maybe the definition of cirshift has changed in MATLAB). restored_field = circshift(prop_output.fields,floor(prop_output.t_delay/dt))
My attempt is as follows（I am trying to plot the pulse）:

restored_field=squeeze(prop_output.fields);delay=floor(prop_output.t_delay/dt);
for i=1:36
    restored_field(:,i) = circshift(restored_field(:,i),delay(i));
end
figure
mesh(prop_output.z,t,abs(squeeze(restored_field)).^2)
view([90 -90]);view([90 -90]);ylim([-8,8]);

It could get the similar results by using sim.pulse_centering = false;. But it shows the pulse moves to the positive direction.

I am interested in the delay of pulse because I watched the videos of GMNA [1,2] which the pulse moves to the negative direction of time.
PM_GMNA_10um.m as an example: I am confused about the positive T_delay and large beta_1(fiber_Gain.beta_1=4.8821e3 >> time_window). In this situation, it is difficult to make the pulse moves to the negative direction of time.
I think I may have misunderstood some of the conditions in GMNA. Does T_delay indicate a relative delay considering the effect of moving frame?
If I use delay=-floor(prop_output.t_delay/dt), the results will be similar with these videos and literatures. But I don't have any evidence, this may just be a coincidence. I gauss: When considering the movement of pulses, must we consider the moving frame?

[1] https://wise.research.engineering.cornell.edu/guide-main/pulse-evolutions/gain-managed-nonlinear-amplifier/
[2] P. Sidorenko and F. Wise, “Generation of 1  µJ and 40  fs pulses from a large mode area gain-managed nonlinear amplifier,” Opt. Lett. 45, 4084-4087 (2020)

[AaHaHaa]

I edited it again. It should be restored_field(:,i) = circshift(prop_output.fields(:,1,i),floor(prop_output.t_delay/dt)) over i, different saved fields of different propagation distances.

I see that you're trying to duplicate that. I'm not the one who generated that figure. It's from our postdoc who left. I remembered he once complained about me adding this temporal centering as well, so I'm guessing that his code didn't have temporal centering. Therefore, he artificially put the pulse at the trailing edge of the time window to keep the moving pulse in it without hitting the window edge.

As I said, beta_(1) can be any value. Perhaps in his simulations, he used a smaller beta_(1) such that the time window can't catch up with the redshifted pulse. You can duplicate that figure by turning off pulse_centering and slightly reducing fiber.betas(2).

In my GMNA example, I set beta_(1) to be the value at 1080 nm, so before perfectly redshifting to the final GMNA, the pulse is relatively slow (bluer color under normal dispersion) to the time window and thus it has a positive T_delay. In that figure from our postdoc, apparently he set beta_(1) at 1030 nm, the center wavelength of his seed pulse, so the pulse is always faster than (redder color under normal dispersion) the time window. This is the reason of the discrepancy between our simulations. You can duplicate his result by turning off pulse_centering and changing sim.lambda0=1030e-9;.

beta_(1) is the inverse group velocity, the inverse speed of the moving frame (time window), and its unit is ps/m. Comparing it with the width of the time window is comparing apple and orange; they're just different things.

By the way, don't use restored_field(:,i) = circshift(prop_output.fields(:,1,i),-floor(prop_output.t_delay/dt)) with a minus sign, which is just wrong.

Hope this helps.

[sulfonic-acid]

I appreciate your support very much. Thanks for sharing the detailed information with me.

[AaHaHaa]

No problem.

I just tried to run one GMNA example. Setting sim.lambda0=1030e-9; and sim.pulse_centering=false' can make prop_output.t_delay(end) negative which means that the pulse is moving faster than the time window. My rational above is correct.

Feel free to ask more.