Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inacurate tight focusing with LaserOffset() #201

Closed
Horymir001 opened this issue Jan 21, 2020 · 13 comments
Closed

Inacurate tight focusing with LaserOffset() #201

Horymir001 opened this issue Jan 21, 2020 · 13 comments
Labels

Comments

@Horymir001
Copy link

Dear developers,
I do observe an inaccuracy with tight focusing implementation based on Thiele's method.

  1. The laser is focused out of axis (about 0.12 microns with offset = 3 microns and FWHM of Intensity is 1.2 um). It is a lot, it corresponds to 10% of the spot size.
  2. The phase is also misaligned. Please, see the input file, post-processing scripts and output plot.
    Thank you for any advice on how to overcome that.
    Best regards,
    Vojtěch Horný

Files.zip

@mccoys
Copy link
Contributor

mccoys commented Jan 27, 2020

Hi

I will look into this issue whenever I have time. Thanks for reporting.

Could you say whether it is a cosmetic problem or a real issue for you (and why)?

Cheers

@mccoys mccoys added the bug label Jan 27, 2020
@Horymir001
Copy link
Author

Hi,
misfocusing is quite a serious issue for me. I would like to simulate interaction with submicron targets. Obviously, when the factor of misalignment is comparable with the size of the target, it leads to inaccurate conclusions.

@MickaelGrech
Copy link
Contributor

Hi @Horymir001
Thanks for reporting this issue.
I think that what @mccoys meant is that there is a quick by-pass for your problem that is to correct, in your input file, the focus of your beam by the error you measure.
It is obviously not the optimal option, but it could be a quick way to fix your problem while we are investigating the pb.

@Horymir001
Copy link
Author

Hi @MickaelGrech
yes, I actually do use such a by-pass. However, I am hesitant about e.g. publishing such results.
Good luck with the investigation ;)

@mccoys
Copy link
Contributor

mccoys commented Jan 30, 2020

Please pull and try the latest version from github.I think most of the problem is fixed, although there might be something I have missed.

@Horymir001
Copy link
Author

Hello @mccoys and @MickaelGrech,
thanks, indeed, most of the problem is solved.
Please find attached some results. I slightly modified the input file - just to avoid such large output files.
A slight discrepancy remains: maximum value of intensity is 9.58e19 W/cm2, instead of 1.0e20 W/cm2 as I intended. I assume it is caused by Maxwell solver. I experienced a similar issue with the EPOCH code as well. If you are intersted, you might compare here: https://cfsa-pmw.warwick.ac.uk/EPOCH/epoch/issues/1891
Best wishes,
Vojtěch Horný

Files2.zip

@mccoys
Copy link
Contributor

mccoys commented Jan 31, 2020

The discrepancy is probably due to some small part of the expanded beam being lost at the boundary, or as you said, by the solver itself.

Note that I cannot access the issue you refer to

@MickaelGrech
Copy link
Contributor

MickaelGrech commented Jan 31, 2020

@Horymir001, I do not believe that the discrepancy comes from the Maxwell solver, but, as suggested by @mccoys by the fact that the transverse size of your simulation is most likely too small. Did you try increasing by a factor 2 the transverse sizes? I think this should decrease the observed discrepancy.

@Horymir001
Copy link
Author

Hi, yes, I also find this explanation much more sound. I might check it one day.

@mccoys
Copy link
Contributor

mccoys commented Feb 3, 2020

Do not forget to close the issue if resolved for you

@Horymir001 Horymir001 reopened this Apr 7, 2020
@Horymir001
Copy link
Author

Horymir001 commented Apr 7, 2020

I observe that the current version with LaserOffset() crashes in the 2D simulation when it is run at more cores than a single one.
The input file I attach run well with the previous implementation of LaserOffset.

tight_focusing.zip

Output from a terminal:

[vojho@hebbe2 test]$ module list

Currently Loaded Modules:
  1) GCCcore/8.2.0     4) icc/2019.1.144-GCC-8.2.0-2.31.1     7) imkl/2019.1.144  10) ncurses/6.1      13) SQLite/3.27.2  16) libffi/3.2.1  19) HDF5/1.10.5
  2) zlib/1.2.11       5) ifort/2019.1.144-GCC-8.2.0-2.31.1   8) intel/2019a      11) libreadline/8.0  14) XZ/5.2.4       17) Python/3.7.2  20) SciPy-bundle/2019.03
  3) binutils/2.31.1   6) impi/2018.4.274                     9) bzip2/1.0.6      12) Tcl/8.6.9        15) GMP/6.1.2      18) Szip/2.1.1

 

[vojho@hebbe2 test]$ mpirun -n 8 ~/Smilei/smilei tight_focusing.py 
                    _            _
  ___           _  | |        _  \ \   Version : bv4.3-92-g6b25773-bmaster
 / __|  _ __   (_) | |  ___  (_)  | |   
 \__ \ | '  \   _  | | / -_)  _   | |
 |___/ |_|_|_| |_| |_| \___| |_|  | |  
                                 /_/    
 
 

 Reading the simulation parameters
 --------------------------------------------------------------------------------
 HDF5 version 1.10.5
	 Python version 3.7.2
	 Parsing pyinit.py
	 Parsing bv4.3-92-g6b25773-bmaster
	 Parsing pyprofiles.py
	 Parsing tight_focusing.py
	 Parsing pycontrol.py
	 Check for function preprocess()
	 python preprocess function does not exist
	 Calling python _smilei_check
	 Calling python _prepare_checkpoint_dir
	[WARNING] Change patches distribution to hilbertian
	[WARNING] simulation_time has been redefined from 163.362818 to 163.258176 to match timestep.
	[WARNING] Particles cluster width set to : 20
 

 Geometry: 2Dcartesian
 --------------------------------------------------------------------------------
	 Interpolation order : 4
	 Maxwell solver : Yee
	 (Time resolution, Total simulation time) : (5.923134, 163.258176)
	 (Total number of iterations,   timestep) : (967, 0.168830)
	            timestep  = 0.950000 * CFL
	 dimension 0 - (Spatial resolution, Grid length) : (3.978874, 201.061930)
	             - (Number of cells,    Cell length)  : (800, 0.251327)
	             - Electromagnetic boundary conditions: (silver-muller, silver-muller)
                     - Electromagnetic boundary conditions k    : ( [1.00, 0.00] , [-1.00, -0.00] )
	 dimension 1 - (Spatial resolution, Grid length) : (3.98, 201.06)
	             - (Number of cells,    Cell length)  : (800, 0.25)
	             - Electromagnetic boundary conditions: (silver-muller, silver-muller)
                     - Electromagnetic boundary conditions k    : ( [0.00, 1.00] , [-0.00, -1.00] )
 

 Vectorization: 
 --------------------------------------------------------------------------------
	 Mode: off
 

 Pre-processing LaserOffset
 --------------------------------------------------------------------------------
	 LaserOffset #0
Stack trace (most recent call last):
#6    Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in 
#5    Object "/cephyr/users/vojho/Hebbe/Smilei/smilei", at 0x46762e, in 
#4    Object "/lib64/libc.so.6", at 0x7f9dab8ac504, in __libc_start_main
#3    Object "/cephyr/users/vojho/Hebbe/Smilei/smilei", at 0x465d75, in main
#2    Object "/cephyr/users/vojho/Hebbe/Smilei/smilei", at 0x5bd2c1, in Params::Params(SmileiMPI*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >)
#1    Object "/cephyr/users/vojho/Hebbe/Smilei/smilei", at 0x4ec620, in LaserPropagator::operator()(std::vector<_object*, std::allocator<_object*> >, std::vector<int, std::allocator<int> >, double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, double)
#0    Object "/apps/Hebbe7/software/MPI/intel/2019.1.144-GCC-8.2.0-2.31.1/impi/2018.4.274/SciPy-bundle/2019.03/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so", at 0x7f9d9a9bdf33, in 
Segmentation fault (Address not mapped to object [0x18])

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   PID 29877 RUNNING AT hebbe2
=   EXIT CODE: 11
=   CLEANING UP REMAINING PROCESSES
=   YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================
   Intel(R) MPI Library troubleshooting guide:
      https://software.intel.com/node/561764
===================================================================================
[vojho@hebbe2 test]$ 

@mccoys
Copy link
Contributor

mccoys commented Apr 8, 2020

I found the bug that was recently introduced, and will fix ASAP.

In the future, please open a new issue, as this one was on a different bug.

@mccoys
Copy link
Contributor

mccoys commented Apr 9, 2020

Done in last push.

@mccoys mccoys closed this as completed Apr 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants