Unstable results for heavily doped Ge nanodisk arrays

[gevero]

I am working on heavily doped Ge nanodisk array 500nm high and 1000nm of diameter. Except for the fact that I am working in the infrared [5000-20000]nm, everything is as for simple plasmonic nanostructures in the visible.

What happens is as seen in this jupyter notebook. In spite of a mesh that seems to be more than fair, with respect to the spatial variations of the field, the output is extremely sensitive to mesh parameters, and there seem to be no definite rule to get a stable output.

In this particular case I run the notebook with a modified EMUstack version (python3 compatible), but i checked with the as is python2 version and the outputs are identical.

The fact is that the results are nonphysical but not random, i.e. they are incorrect but identical run after run. Do you have any suggestion for me? I was planning to couple EMUstack with a genetic optimizer, but as long as the output is not stable for a reasonable set of parameters, this is going to be difficult for me.

Best

Giovanni

[gevero]

Hi Bjorn

Hope everything is going fine with your thesis. I have a small update on the subject. Correctness of the results is a function of the parameter max_order_PWs, and as a consequence of the number of bloch orders. For high (greater than 3) max_order_PWs the result becomes wrong and unphysical, yet stable from run to run. It seems to me that all the bloch modes are correctly computed if i take a look at the plots of the Bloch fields, and indeed I get no error or warning from the code. Defining a finer mesh (even a very fine one) does not seem to help. The problem could lie in the enforcing of the correct boundary conditions: may be that overdetermined linear system to obtain the correct boundary conditions is not correctly solved when it becomes too large.

Let me know what you think about it. Best

Giovanni

[bjornsturmberg]

Hi Giovanni,

I handed in my thesis on Friday, so I will have a bit of time to look into these issues! Today I started with this issue - regarding highly doped Ge. I cannot actually replicate the error you observed... The attached Figs and Script were generated using your script with 2 and 3 PW orders. I also pushed the latest update, and although I cannot see how this would change things, please merge this and try again so that we're on the same page.

I'm looking forward to clearing these issue up! Cheers

spec-3PWs.pdf spec-2PWs.pdf fileds.pdf

[gevero]

Hi Bjorn

Thanks for the answer. I will run my calculations from a clean repo and see what happens.

Best Giovanni

[gevero]

Hi Bjorn

I run it from a clean copy of the repo with python2. Still the same problem... I think I am narrowing it down to the fact that I am not working in ubuntu... I will keep you posted...

[bjornsturmberg]

Hi Giovanni,

can you specify what libraries and compilers you are using? I haven't really experimented that much with EMUstack on more than a few flavours of linux on my computer and supercomputer facilities, but you never know maybe something will stick out?

Cheers

Kind Regards, Björn

Björn Sturmberg CUDOS and IPOS at The School of Physics THE UNIVERSITY OF SYDNEY Rm 321, School of Physics | University of Sydney | NSW | 2006 T +61 2 9351 3963 | E [email protected] [email protected]

On Thu, Nov 26, 2015 at 2:55 AM, Giovanni Pellegrini < [email protected]> wrote:

Hi Bjorn

I run it from a clean copy of the repo with python2. Still the same problem... I think I am narrowing it down to the fact that I am not working in ubuntu... I will keep you posted...

— Reply to this email directly or view it on GitHub https://github.com/bjornsturmberg/EMUstack/issues/7#issuecomment-159650151 .

[gevero]

Hi Bjorn

I performed some test and below are reported all the relevant informations:

• You can checkout the issue_7_8 branch of my EMUstack repo. There you will find a couple of notebooks (issue_7 and issue_8) related to issue #7 (this issue) and also to issue #8
• I can reproduce issue #7 if I run the calculation on my cluster where I use the precompiled libraries. If i run the calculations on an Ubuntu 12.04 virtual machine instead, the issue vanishes whether I use the system or precompiled libraries. Therefore I think it is something regarding my environment, but i could not say what it is...
• Regarding issue #8 I can reproduce it both on my cluster and in the ubuntu 12.04 virtual machine. Maybe you can run the examples yourself and see what happens. The local-field is of course also wrong, but I suspect that also my plotting routine could be suffering from a bug (i.e. it's only working for square grids)

For the moment this is all

Best

Giovanni

[bjornsturmberg]

Hmm, okay I will then not look into this issue (#7) any further but will concentrate on #8.