2D simulation error

[amrit-poudel]

I get the following error when I try to run a 2 D simulation using scuffem C++.

error: file Cylinder.msh: no panels found (aborting)

I generate a .msh file in gmsh by discretizing the boundary of a circle.

Is it possible to run 2D simulations in scuffem?

[HomerReid]

You can simulate geometries with translation invariance in 1 direction (such as infinite cylinders) by constructing a mesh for the unit cell and defining a 1D lattice in the .scuffgeo file. Here's an example:

http://homerreid.dyndns.org/scuff-em/doc/examples/SiliconBeams/SiliconBeams/

If you'd like to explain the particular simulation you are trying to run, I could help you get that set up along the lines of this example.

[amrit-poudel]

Thank you for pointing this example out. I want to compute the dyadic greens function (imag part of say Gzz. I can use a point dipole source (in fact it is a line source due to translational invariance) pointing in the z direction and then compute the z-component of the E-field) for a 2 D cylindrical geometry. Please note that for 2D simulation, I have a line source. I am confused how to handle the line source in C++ scuff-em. If I construct a 3 D cylinder with finite height h, and a then define a 1D lattice in scuffgeo file with lattice vector h, I can generate a cylinder with translational invariance in that direction, but how about the source? In a truly 2D simulation, we have a line source, but not a point source.

Aside # I am using similar ideas to compute the dyadic greens function for the half space geometry in 3D with a point source. Here, the geometry has translational invariance in two directions, x and y. As for the z-direction, I consider thickness of a slab > skin depth of the metal (Au). Geometrically, this is not a half-space, but the numerical solution must agree with the analytical result of the half-space if I consider evaluation or observation point z above the slab < thickness of the slab.

For half space geometry, we have a point source, unlike the line source in a truly 2D simulation, so I can define 2 D lattice in scuffgeo and compute the electric field for each kx and ky in the BZ and later add them up to get the electric field in real space.

I want to compare this numerical solution with the exact analytical solution of the dyadic greens function for the half space geometry.

Thanks for any help.

[amrit-poudel]

I am interested in a truly 2D geometry, with a line source. I do not quite understand how one can construct such a line source. I will appreciate any help.

[HomerReid]

For discussion of LDOS computations in SCUFF-EM, see #27. The long story short is that there is a specialized code called scuff-ldos that handles this calculation, and it is very close to being ready to commit to the repository, probably tonight or tomorrow.

As for the 2D line source, this is not one of the existing pre-implemented incident fields available in SCUFF-EM, but you can implement it yourself for use in API programs by copying and modifying one of the codes in src/libs/libIncField.

The basic idea for how to implement a line source (which has a continuous translational symmetry) in a Bloch-periodic code like SCUFF-EM (in which we have discrete translational symmetry) goes like this: First, write the fields of your source as 1D Fourier integrals over a 1D wavevector (a wavenumber) kz. In these integrals, kz will vary from -Infinity to +Infinity. Now, rewrite the integral in such a way that kz varies only from 0 to 2\pi/L, where L is the length of the unit cell of a 1D lattice. If the integrand of the original integral was I(kz), then the integrand of the new integral will be I^\prime(kz) = \sum I(kz + \Gamma), where \Gamma runs over all vectors in the 1D reciprocal lattice (so \Gamma = 2n\pi/L for all integers n.)

The function I^\prime(kz) is then the incident field you will supply to a SCUFF-EM calculation at Bloch vector kz.

This calculation is discussed in more detail in the 2D case in the memo scuff-ldos.pdf referenced in the discussion of #27.

[amrit-poudel]

Thanks for this explanation. Your approach makes sense.

My confusion is that if the source itself is translationally invariance, why is it necessary to perform summation over different Bloch wave vector?

[HomerReid]

You're right--for a line source of constant source density, there is no need to perform a Bloch-vector sum. You can do just a single calculation with Bloch vector k=0.