RF Module Problems

[akzy]

Hi Homer,

Just a quick introduction to what im solving for and the issue. I plan to use the RF module to calculate the electric field above the surface of a surface Paul trap for use in ion trap quantum computing. The issue im currently having is the the S and Z parameters seem to be rather unrealistic - mainly with the Z at ~ -10^10-10^17i . For this type of geometry i should be expecting something on the order of 10^4 to 10^5. I've made a github directory here https://github.com/akzy/scuff/tree/akzy-take-3 but first ill give you a brief talk through whats going on.

To simplify for the time being, I'm just simulating the top electrode layer which im creating with two seperate meshes. For simplicity, imagining like a box, one is the top of the box (electrodegold2umtop.msh), and the other is an open top box (electrodegold2um.msh) - stick them together you get a box :). This seems to be the only way i can get the analyse function to see an external boundary so i can assign numerical ports (trap.ports) by using the edges i get off the individual mesh files and define using PSURFACE and MSURFACE for each respective surface. The geometry itself can be split into two separate sections, the RF rail (centre) and the separated ground planes either side.

I believe the issue is to do with the normals of each surface but i cant be sure. The individual meshes have the normals pointing outwards (i.e. to vacuum) and when stitched together in the scuff-geo, this stays consistent (you really have to zoom on gmsh 'trap.pp' to see it but it does). Then labelling the regions in the scuffgeo, it has 'Exterior' first followed by 'electrode' which i have defined as PEC (I have tried flipping these all over in many different combinations to no avail). An insight into this would be greatly appreciated.

For the time being, i have edited out the the other layers i plan to use which will be (from top to bottom) electrode layer, dielectric, ground electrode (so there would be a ground on the top layer AND this layer), dielectric, silicon - can you foresee a problem with this?

Any insight at all into this would be greatly appreciated!

Thanks,

Zak

[HomerReid]

Looking through your files, I see a couple of things:

• In trap.scuffgeo, you are declaring an entire REGION to be PEC. This is probably not what you want---you don't have an entire 3D region of space that is filled solid with perfect conductor, right? If you are trying just to simulate one or two open metallic surfaces in vacuum, just use OBJECT...ENDOBJECT statements for each surface. I think I see at least in part what you are eventually trying to do with your REGION and SURFACE definitions, but keep in mind that each REGION is a 3D volume of space fully enclosed by a closed surface comprised of one or more surface meshes. For open surfaces in vacuum, like you have here, there is only one REGION in the problem (the default exterior vacuum region) which you don't need to specify explicitly.
• Your mesh files are going to be problematic numerically because in several places you have triangles whose edges are huge compared to the separation distances to other surfaces. In general the triangle edges need to be on the order of, or smaller than, the distance to any other surface.
• The reason you are getting a huge value for the Z parameter is that the S11 parameter is evaluating to unity, i.e. the input current is perfectly reflected (infinite input impedance). This is due to the incorrect geometry description.
• Regarding port specification, there is actually an easier way to specify ports than identifying individual edges by number. If you can describe a port as lying one one or more line segments in space, then you can just specify the coordinates of the endpoints of the line segments, and SCUFF-RF will automatically figure out which edges live on those line segments. For example, if your device is organized such that there is a positive port running from Z=-1 to Z=+1 on the Z axis and a negative port running from Z=-1 to Z=+1 at a distance of 1 mm away in the X direction, your .ports file can look like

PORT
    PPOLYGON 0 0 -1 0 0 1
    MPOLYGON 1 0 -1 1 0 1
ENDPORT

This way of defining ports is independent of mesh resolution, so you can just write a single .ports file for use with multiple .msh files obtained from the same GMSH geometry file at different resolutions.

I would encourage you to start with a simpler toy version of your geometry (maybe just a single PEC rectangle with positive/negative port edges on opposite sides) and verify that you get reasonable results for that, then gradually add features to work up to the full complexity of your actual geometry.

Good luck!

[akzy]

Hi Homer,

Thanks for taking the time to look through my work - I really do appreciate it!

We actually do have 3d volumes that are full and not hollow - the top three layers are effectively making a coplanar waveguide. So first question, is this method of definition correct then? However when i activate the other layers i receive nan values for S and Z parameters. From some earlier tests i noticed that increasing the mesh size often deals with this problem.

This nicely brings us to the mesh problem - When i start using finer meshes, i can easily get into large (10s of GB) which is starting to push on my 64GB limit :/ Can you suggest any neat tips for this edge meshing whilst leaving it coarse in the center. Usually i do it by editing the 'cl__1' in the .geo - would you suggest this is a good method?

Finally, i have created a toy version, which is more or less a coplanar waveguide with similar dimensions to our ion traps and implementing the geometry port system (that makes things a lot easier :)). https://github.com/akzy/scuff/tree/akzy-patch-1 Again, i have to use large BEM matrices to get it to work - im concerned this will become a problem when i move to more complex geometries.

Thanks for your time,

Zak