Saving data file at desired position
Closed this issue · 7 comments
Hi,
I have a question about saving the lasy data. I construct a laser pulse by separately constructing longitudinal and transverse profile. The data of the constructed laser pulse is saved (as shown below) to be used in an another code
laser.propagate(-1000.0e-6) # propagate laser in backward direction by 1 mm
laser.write_to_file('lasy_laser','h5')
I propagated the laser backward by 1 mm and then save the field values.
Does the field values saved are at 1 mm before the focus position or at the focus point ?
I want to load this saved data file in FBPIC, where the focus position is expected to be 1 mm down stream ( 1 mm deep after starting the simulation ).
Hi,
Here is some more information about what happened when I load this lasy generated laser pulse in FBPIC.
Please, see the attached file.
I did the following:
(1) construct a spatially gaussian and temporally asymmetric laser pulse with LASY.
(2) saved the LASY generated laser pulse data in ".h5" format.
(3) and finally, loaded this data in FBPIC code.
Unfortunately, I found that the initial condition of the laser pulse is not correct when loaded in FBPIC.
Please, could you help me to fix this out. I have attached the LASY and FBPIC files.
Thanks a lot.
Thanks a lot for posting these details!
This seems to be an FBPIC issue rather than a LASY issue. I will take a closer look.
Have you been able to see the same issue on smaller cases? (e.g. with smaller simulation grid)
Also: does this test work properly on your system?
Hi @RemiLehe,
thanks a lot for checking the issue. So far, this was my first test with LASY and porting its data file in FBPIC.
I haven't made any other test but I can also check with smaller simulation grid.
Also: does this test work properly on your system?
While using LASY and porting file in FBPIC, I didn't encounter any issue or didn't received any error message. Looks like everything went smoothly.
I am very curiously looking forward to use the powerful features of LASY and then its porting in FBPIC. FBPIC is my main PIC tool, I would really appreciate if this issue of porting LASY files in FBPIC will be fixed.
Thanks a lot.
@koesterf Thanks again for raising this issue.
I had a closer look, and I think that the problem here is that the antenna does not have enough time to get to the peak of the laser pulse before exiting the moving window. The issue is illustrated below.
As a result, during the FBPIC simulation, the antenna is essentially emitting the part of the pulse that has an amplitude very close to 0. (We can indeed see in Lasy2FBPIC.pdf that the amplitude of the emitted field is much lower than the expected one.)
One solution is to slightly modify the bounds of the box in the lasy script, e.g. using
lo = (0.0 , -0.25 * 1.0e-12) # lower bound of the simulation box
hi = (10.0 * w0 , 1.75 * 1.0e-12) # upper bound of the simulation box
instead of
lo = (0.0 , -1.0 * 1.0e-12) # lower bound of the simulation box
hi = (10.0 * w0 , 1.0 * 1.0e-12) # upper bound of the simulation box
(See lasy_script.txt)
This result in the following case:
Using the above lasy
script, as well as Lasy2FBPIC.txt (where I reduced the transverse resolution of the simulation to make it more manageable to run), I get the following at iteration 4300:
which I think does match the expected laser profile and amplitude.
In conclusion, I don't think that there is a bug in FBPIC or lasy.
However, I understand how the above can confuse users. If you have any suggestions on how to improve the FBPIC documentation (e.g. on this page) to avoid this type of confusion, please let us know.
Hi @RemiLehe, thanks a lot. I appreciate a lot your help and the explanation you provided for using the LASY file properly in FBPIC. I will follow the grid resolution you used (and also experiment different cases).
Yes, as a user I would like to see a more improved documentation, however, I also believe that this could happen with the help of users input. Once I will done with the problem I am trying to do with LASY and FBPIC, I will come up with small (but many) suggestions on how the documentation could be made more practical for the end users.
Thanks you for the wonderful discussion and help.
Best,
Frank