trouble with convergence [solved]

[greyltc]

Hi all, I think I've got a system that's just on the edge of being able to converge numerically, but it's not quite there and I wonder if anyone can offer me some advise on how to fix my convergence problem.

What I'm trying to do: I'm using the static current conduction equation to model current in very thin two layer metal/oxide film stack where the metal film is in a special pattern. This is a 3d problem because current enters the film stack normal to the plane and gets carried out by thin metal "highways" laterally. I'd like to accurately account for the electrical loss (joule heating) in the film stack. I'm designing solar cells in academia.

What I've done so far:
I've made a step file model of my film stack and meshed it with gmsh. The thin film stack I'm trying to simulate here is two layers: a 60nm thick layer where the current enters up from below on almost the whole surface, then on top of that, there's a 100nm thick layer of patterned metal, the whole thing is centimeters in the X and Y directions. I drawn the step file model in mm units in x and y, but in the z direction, I thickened the films up by a factor of 10000 to make meshing possible.

mesh.png

(181.08 KiB) Not downloaded yet

I load my mesh up into Elmer and set up the boundary conditions (a current injection surface at z=0 & a ground surface on one side are the only ones I need) and the materials and equations. If I run the simulation without correcting for the 1000x too thick z scaling i have in my model, everything seems to work mostly fine with the default solver settings (elmergui 9.0). It converges in like 60 iterations or something, done in a few seconds. Some of the data is a tiny bit splotchy/non-uniform, but for the most part, the results show me that the physics is correct (the bad z-scaling ruins the analysis):

wrong_geometry_scaling_result.png (194.64 KiB) Viewed 1062 times

I got this result with

Code: Select all

Coordinate Scaling(3) = 1e-3 1e-3 1e-3

in my sif file. That puts x&y in meters and leaves Z 10000 times too thick.

The problem is when I set

Code: Select all

Coordinate Scaling(3) = 1e-3 1e-3 1e-7

to get all the geometry into meters (including the 160nm thick z-direction), the results go right to hell. Numerically, it never converges, just hits the default 20 iteration stop point. When I look at the output after the 20 steps, The physics is almost right, but the data is really, really splotchy/noisy to the point where it's pretty obviously quite wrong and I can't trust the joule heating numbers, which is what I'm really after.

I've tried playing with the solver settings for a pretty long time, but nothing I do seems to help (there's a lot there, so maybe I've missed the right combo). If anyone can offer any tips on how to get this system to behave, I'm all ears.

Thanks in advance for any help anyone can offer!

Cheers,
¬grey

[kevinarden]

I would be concerned with element quality when scaling that much in 1 direction. Linear tets are not the highest quality element to start with.
You can use elmergrid to convert the mesh with scaling. I converted to vtu to look at it in paraview.
elmergrid 2 5 mesh -scale 1.E-3 1.E-3 1.E-7

mesh.png (160.55 KiB) Viewed 1060 times

[raback]

Hi

I think there is something fishy with the mesh. The "surface with edges" on Paraview shows like there would be double set of edges on body 1.

I agree with Kevin that ~5 orders of magnitude is challenging aspect ratio but the convergence is lost a lot earlier. I would expect somewhat more robust behavior. For these aspect ratios you might want to combine 2D and 3D models in the end but I think this is not the first issue here.

-Peter

[kevinarden]

using salome I meshed in meters using hexa elements solid bricks. it converged very well. I believe this confirms it is a mesh issue.

hexmesh.PNG (58.7 KiB) Viewed 1056 times

ycase.sif

(2.06 KiB) Downloaded 66 times

hex.zip

(909.3 KiB) Downloaded 58 times

[greyltc]

Thanks so much for your help everyone! I will focus on improving the mesh.

I've attached here my input step file (geometry.step, x and y in mm, z too thick by a factor of 1e4) and my gmsh mesh definition file (mesh_with_gmsh.geo) that I'm using to generate the mesh. If there are any gmsh experts out there, I'd love advise on how I should be changing my .geo file to improve the mesh quality to get this to converge. There are so many gmsh options in the manual and while playing with them, like 50% either segfault or produce meshes that it tells me contain errors! I'm using version 4.11.1

I'm also trying NETGEN, to hopefully make me a better mesh.

As for where to do the geometry scaling (if anywhere), I'm a bit confused about what's the most likely to give the best results. Should I
1) Redraw the input step file so that it's properly scaled (drawing units in meters), then run that through my mesher and elmer with no scaling anywhere.
2) Keep my geometry step file with the weird scaling as I have it now (x&y in mm, z too thick by a factor of 1e4), mesh it like that, and use elmergrid with `-scale 1e-3 1e-3 1e-7` to convert it to meters before loading it into elmer
3) Keep my geometry step file with the weird scaling as I have it now (x&y in mm, z 1e4 too thick), mesh it like that, not use elmergrid to rescale the mesh, but instead use `Coordinate Scaling(3) = 1e-3 1e-3 1e-7` in elmer to tell the solver to rescale it to meters there.
4) Something else? kevinarden wrote they "meshed in meters," with salome, but I'm not exactly sure what that means.

Should there be any difference in #2 vs #3; scaling the mesh after it's made with elmergrid's `-scale` vs doing it in numerically in elmer with `Coordinate Scaling(3)`? The reason I've never tried (1) is that I'm not sure how to ensure I get enough elements in the z direction if I try to directly mesh geometry with such a crazy aspect ratio.

kevinarden, your results look promising! I've never tried salome before, but I've downloaded it and tried some stuff, but I think I need to learn a bit more before I'm able to make decent meshes like yours. I managed to get the NETGEN 1D-2D-3D meshing algorithm to give me something, but it looks nothing like yours. I'm sure I wasn't clear on the boundary conditions of my problem in my first post. Current leaves the structure through the 0V ground surface and is injected into it only via one special (1.0cm^2) surface on the bottom (see below), 200A/m^2. When I've been doing my simulations so far, I don't set any properties on any of the other surfaces, which I hope isn't causing any issues.

boundary_conditions.png (20.09 KiB) Viewed 1038 times

When I loaded the mesh you so kindly attached to your post, I saw the ground surface, but the only other surface i saw was one that covered the entire rest of the geometry. Using that for the current injection surface (everywhere) is not quite the same and I wonder that's inherently more numerically stable or something. I tried it with your mesh and boundaries and it did converge for me too, and the results I got looked like yours, they make sense, so there's hope for me!

I still can't manage to get it to converge with the correct BCs as shown in the above sketch though, but that's hopefully just because I can't figure out how to mesh this thing properly.

[kevinarden]

I mis-understood the boundary conditions, I made current in the entire bottom surface. Very difficult to tell with how thin the part is.
Scaling is OK, but I think it should be the same for every coordinate to avoid element distortion. If it is necessary to model Z at actual times 10000 , then model x and y, same way, and scale them all the same. There are ways to control mesh size in gmsh using define mesh. You can specify number of elements per curve, to control the number of elements through the thickness versus length.

In my salome mesh, I meshed the 2D plane at z=0.0006 and extruded the surfaces down into solids, and then only the outer ring surface up into solids.

tet meshing is a powerful meshing tool, but getting good fem solutions from tets is difficult.

[greyltc]

This seems hard to mesh. I guess I'd need at least 20 elements (maybe even more like 100 would be better) in the z direction to get the grid points I need to properly capture the physics there. But to achieve that, the mesh is ending up way more dense than it has to be in the x and y directions and it just gets unmanageable computationally to even generate the mesh, let alone run a simulation on it.

I think my goal here could be to mesh this with ~10nm divisions in Z and ~100,000nm divisions in x and y, but I haven't been able to achieve that sort of anisotropic mesh so far while playing around with netgen, gmsh or salome. I don't see a ton of anisotropic meshing functionality at all. Generally any knobs these tools give on mesh size seem to be scalar, whenever I try tuning the mesh size, it applies equally in x, y and z, and that's not workable.

I've undone the mismatched 10,000x scaling in z that I had in the step file I previously attached, so I'll attach the proper aspect ratio step file here twice if anyone wants to give meshing it a shot. One version of the model is 1 drawing unit = 1 meter, the other is 1 drawing unit = 1 nanometer. The extents are 23mm x 9.5mm x 160nm.

extents.png (20.53 KiB) Viewed 1016 times

[greyltc]

And just for completeness, or in case they're somehow easier to work with, I'll put two more step files here with 1 drawing unit = 1 millimeter and 1 micrometer

[kevinarden]

It is a tough case to mesh. The aspect ratio is one thing. Typically you would go with 2D elements, and maybe that is a possibility. Will have to think about.

Another problem is features

features.PNG

(160.27 KiB) Not downloaded yet

the bottom radii cause reentrant corners, very difficult to mesh locally in that area, if this is not important to the results they can be eliminated.
The top has a very small radius, again, hard to mesh, is it important to the results?
Often meshing in FEM leave out some fine details because it causes hardship to meshing and has no effect on the analysis.

[greyltc]

I think I've got it! Here's what I did:

I flattened the whole geomoetry so that it's just a collection of wires on a plane. Then I played with a few 2d meshing algorithms until I got a 2d mesh that I like the look of (gmsh calls the algo. I used "Packing of Parallelograms"). Starting with a single, unified 2d mesh like this keeps everything coherent in the mesh across the edges of my wires. This is my template mesh:

2d_mesh.png

(34.43 KiB) Not downloaded yet

I then "grow" my 3d meshes out of this template. Since they all start from the same 2d mesh, they're all always connected properly. I dunno, but maybe this is an inherent problem in gmsh, but I was often having trouble getting meshes to connect with each other across 3d boundaries, they would sometimes connect in some parts of the geometry, but be disconnected in other parts, which would often lead to funky simulation solutions, and recognizing that is not always easy.

I pick regions of the template mesh and specify a height and number of planes/slices to copy up to that height. Here's 10 copies of the "metal" face in the upward direction over 1mm and 6 copies in the downward direction in the other regions down to -0.6mm:

3d_extruded_from_2d.png (241.1 KiB) Viewed 982 times

in my final mesh, compared to that screenshot, I just made 10 copies upwards to 100nm instead of 1mm an 6 copies downwards to 60nm instead of 0.6mm. The mesh is identical in both cases except for the spacing between the extruded template copy layers. Doing the mesh extrusion like this gives me precise control over the Z resolution independently from the x-y resolution that I picked when making my 2d template mesh.

Doing it like this also gave me some insight on how well the solvers work. Basically, when the structure gets too thin (even though the mesh is identical across trials except for extruded layer spacing), the iterative solver craps out. It takes longer and longer to converge as I thin out the structure, until it never does (the error is not progressing down during 20 iterations). The direct solver, however nails it every time, no matter how thin/thick I make the structure, and it's fast. The iterative solver agreed with the direct one down to about a 15 micron thick structure, after which it no longer converged and thus its result disagreed with the direct solver I was using (mumps).

I ended up making the whole thing with 1 drawing unit = 1 nm. I didn't do any scaling with elmergrid, but I set a scalar scaling of 1e-9 in my sif file to bring the simulation back into meters. Results are right in line with what I expect, now I can finally get on with my study!

result.png

(533.44 KiB) Not downloaded yet

Thanks for your help everyone!