| Author |
 Topic  |
|
|
Emile0205
South Africa
8 Posts |
 Posted - Oct 18 2017 : 15:32:10
|
Hello
So I am trying to test a VIA in FastCap, specifically a block VIA connecting one metal layer to another with ground plates above, below and in the middle of the model (with a gap for the VIA to go through in the middle).
Due to the nature of the test the VIA needs to be kept as a seperate node even though it is connected to the two metal layers as we need to determine if the VIA causes any extra capacitance within the model.
Interestingly enough it is found that when each block in the model is given a single mesh a result is found, but as soon as the VIA and the two metal layers receive more than one mesh NAN results are received. This happens even if the two metal layers are made the same node, and even if the two metal layers AND the via are made the same node. By the way FastCap does not produce any errors, only produces NAN after a single iteration of each node.
So I am curious over why this would happen. Is it because the two connecting faces of the VIA (i.e. the top and bottom face in contact with the two metal layers) is given a outer permitivity? If this is the case what would the outer permittivity have to be for faces in contact with other metal layers, and then also would the overlapping faces of the metal layers (i.e. those parts in contact with the via) also have to be given a different outer permittivity than the rest of rest of the metal layer? Or is there some other reason that FastCap produces NAN results?
Thanks in advance
Emile Engelbrecht |
|
|
Emile0205
South Africa
8 Posts |
Posted - Oct 19 2017 : 10:26:03
|
So I think the question is how would one handle metal layers that are in contact with one another and are NOT a part of the same node (purely for testing reasons and ease of simulation)
Emile Engelbrecht |
 |
|
|
Emile0205
South Africa
8 Posts |
Posted - Oct 19 2017 : 10:27:35
|
Note this also causes panels to overlap. Should these panels still be created but ensured to be different sizes making FastCap not delete the overlapping panels, or should they be deleted to make a joint object?
Emile Engelbrecht |
|
|
|
Enrico
530 Posts |
Posted - Oct 19 2017 : 11:16:10
|
Hi Emile,
you possibly have misunderstood the 'not overlapping' requirement. It does not matter if the panels have different dimensions, they can NOT overlap, nor intersect. They can share only edges. This is due to the mutual potential calculations, that are performed via a surface integral, and that can become singular if the testing points on the second panel falls on the source panel (so the distance tends to zero).
I also see that you are trying to manage the refinement, as well as you need to properly handle the outperm / inperm definitions.
In this respect I would suggest you to use FasterCap, not FastCap; as you can define outperm / inperm on a per-panel basis, and the geometry can be automatically refined. You can also use FreeCAD for a simple geometry definition, including cutting the planes with the proper shapes, so you don't have overlaps - see the E.M. Workbench, this is today just a simple script, but can be hugely useful for this kind of application
Best Regards,
Enrico
|
|
|
|
Emile0205
South Africa
8 Posts |
Posted - Oct 19 2017 : 12:00:18
|
Thanks Enrico!
I understand now about the overlapping requirement. Just wondering if its okay to create an overlap and just let FastCap delete it? This should surely not change the results too much?
Emile Engelbrecht |
|
|
|
Enrico
530 Posts |
Posted - Oct 19 2017 : 12:58:51
|
Do not trust that. FastCap (as well as FasterCap) does some basic checks about overlaps, but checking for intersections is a 3D classic problem with complexity N^2. While there are techniques to lower this complexity, this is not the goal of FastCap; so you simply cannot rely on the internal input sanity checks to cover all cases. You are ultimately responsible to provide a clean input.
As said, a 3D cad program used as pre-processor can help in this respect: it can remove all overlaps.
Best Regards,
Enrico |
|
|
|
Enrico
530 Posts |
Posted - Oct 19 2017 : 13:11:14
|
Let me also add that if you need support for this kind of activity (creating the model, or better, customizing the infrastructure for creating the model), we are fully available to help you.
Best Regards
Enrico |
|
|
|
Emile0205
South Africa
8 Posts |
Posted - Oct 23 2017 : 13:41:40
|
Hey Enrico
I am struggling with this model I am trying to make of a VIA. I have ensured zero overlap within the model (specifically where the VIA touches the two capacitor plates that it's connecting). And I still get a result for Big Meshes but as soon as I use smaller meshes I get NaN results. Do you know what the reasons would be for why NaN would given at the output?
Emile Engelbrecht |
|
|
|
Enrico
530 Posts |
Posted - Oct 24 2017 : 10:11:31
|
Please post your smallest offending input file. If you don't want it to be public, you can use any input file that causes the error, or you can sent it privately to me at the address specified in the 'contact' page.
I still think that the error is in the input file. NaN is usually caused by overlaps, also too small panels (near machine precision) may cause similar issues, but I can hardly think this is your issue. If you are sure there are no overlaps, nor panels crossing each other, I need to see the input file.
(you may want to debug it yourself, as the source code of FastCap is fully published, but I may be able to spot your issue quickly)
Best Regards,
Enrico
|
|
|
|
Emile0205
South Africa
8 Posts |
Posted - Oct 27 2017 : 12:39:18
|
Thanks for the help
It was found that there were overlapping pannels within the model. Im just curious Enrico, do you know why FastCap calculated capacitance values for some models where there are overlapping panels and then cant calculate it for others?
Regards
Emile
Emile Engelbrecht |
|
|
|
Enrico
530 Posts |
Posted - Oct 30 2017 : 12:08:14
|
Of course I do. This stems from how the mutual interactions are calculated. FastCap relies on a multipole representation of the panels. The multipole depends from the input geometry and how it is grouped. So changes in the input structure can make the calculations hit a singularity, or not, depending on how they are positioned relative to one other. However, please note that even if you do NOT hit a singularity, the result cannot be trusted anyway; first because you may be close to a singularity, and therefore introduce errors in the solution; and second because simply in the E.M. representation of the problem, you are calculating the charge density twice in the same location of space, and this is not physical.
Best Regards,
Enrico
|
|
|
| |
Topic |
|
VIA in FastCap
