# dipolepower(f) crashing the program

In the attached .fsp file (that needs to be run):
dipolepower.fsp (337.5 KB)

after getting the frequency vector f, running the dipolepower(f) command crashes the program. Using the gui to click and calculate and even plot works fine.

Part of what I don’t understand is that I’m running a sweep of the dipole position (that’s the only parameter that changes, everything else is the same) and only 4/300 of the .fsp files have this error. All of the others are fine.

I tried using the following as a workaround (which did not crash the program) but I wasn’t sure how to incorporate the frequency vector as these commands return 1000 element vector, whereas I only used 300 frequency points in the simulation.
dipole_power=getresult(‘E_dipole’,‘dipolepower’);
dipole_power=dipole_power.dipolepower;

Dear @bpi,

Sorry for any inconvenience that this might have caused you and thank you very much for sharing the problem with us. Generally when the mesh size becomes small in the order of \lambda/1000, you should expect that the results are not very reliable. This is explained here. As you explained, it works with gui but running the dipolepower(f) causes the software to crash.

I could replicate the problem as you explained. The software behaves normal until the mesh size is 2 nm but crashing happen when the mesh size becomes 1 nm which is close to 900/1000 where 900 is your maximum \lambda. Can you please upload your sweep code so that we have more data points to figure out what else causes the issue?

By default, software returns 1000 frequency points for your dipolepower. To extract data on your frequency range of interest you can interpolate your data using interp command as explained in this page. For example:

dipole_power=getresult('E_dipole','dipolepower');
power=dipole_power.dipolepower;
f_old=dipole_power.f;
sampled_power=interp(power,f_old,linspace(3.33e14,10e14,300));


Where 3.33e14 and 10e14 correspond to \lambda=300 nm and \lambda=900 nm, respectively.

The sweep code is: Dipole_Sweep.lsf (1.4 KB)

Things got a little bit more complicated. I originally ran all of the simulations on a cluster. After finding this bug which crashed the program, I reran those simulations again on the cluster, and the problem persisted. I then reran (after I submitted the original post) the simulations on a desktop computer and did the analysis immediately after running the simulation and it didn’t crash and worked correctly. So I’m a little mystified, but I’ve got the results I need. I’m happy to try and help you guys figure out the bug however you need me to.

Dear @bpi

Thank you very much for providing the sweep file and extra information on this regard. I run your file on my desktop and it crashed mine twice as well. It definitely needs further investigation but my guess is that it is somehow random, for example you didn’t see the problem when you run on your desktop! I am glad that workaround trick worked for you and you could extract your results.
Did you try running the simulations on a slightly coarse mesh, like 2 nm instead of 1 nm?

I didn’t. Do you think that some of results may be wrong due to this very high mesh?

Hi @bpi

I should discuss it with our team to learn more about what is exactly limiting us, but since there is a warning in our KB, I would rather try a slightly coarse mesh size with dipole sources to avoid any potential numerical errors.