All Forums  FastFieldSolvers  FasterCap and FastCap2  Last defined conductor (2D analysis) being ignored

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize: 640 x 480 800 x 600 1024 x 768 1280 x 1024 UserName: Password: Antispam question: What do MOONwalk and MOONdance have in common? Answer: Format Mode: Basic  Help  Prompt  Format: Font Andale Mono Arial Arial Black Book Antiqua Century Gothic Comic Sans MS Courier New Georgia Impact Lucida Console Script MT Bold Stencil Tahoma Times New Roman Trebuchet MS Verdana   Size 1 2 3 4 5 6   Color Black Red Yellow Pink Green Orange Purple Blue Beige Brown Teal Navy Maroon LimeGreen Message: * HTML is OFF * Forum Code is ON [quote][i]Originally posted by Ashutosh98[/i] [br]I am doing a 2D analysis of a system of conductors arranged/embedded in a dielectric medium. The number of conductors in my system is N (variable controlled by me). I was initially modelling this system as 3D, but 2D seems to be getting a convereged solution much faster. The problem I am facing with the 2D analysis is that I should be getting a Capacitance Matrix of the dimension (N-1)x(N-1) since the last defined conductor in the .lst file will be considered ground, but instead I am getting a (N-2)x(N-2) capacitance matrix. I tried to investigate this problem by loading the refined 2D geometry in Fastmodel, and found that apparently Fastercap is completely ignoring the conductor which has been defined last in the .lst file. I figured that I might be doing something wrong in preparing the .lst file, so I went through the 2D examples given in the Fastercap documentation (like coax_cable_coated_2d_fine), and found they had done nothing special, and were defining the last conductor in a similar manner as me. So I tried to solve this problem crudely by introducing a dummy conductor which will get ignored by Fastercap. This seems to solve this problem, and now I am getting (N-1)x(N-1) matrices, but it does make me wonder what is happening which is causing Fastercap to ignore the last conductor. Also is it wise to assume that now the second last defined conductor acts as the ground? Just to keep note: I am defining the last conductor in the same way as the conductors above it, i.e. I am using the same geometry .txt file, just its position (x and y offset) is different. Another very confusing thing which happens is that when I comment out the last defined conductor, the system remains the same according to Fastercap, and exactly the same solution is obtained. It's almost as if Fastercap needs a concluding statement or something. It will be really helpful if someone can clear up this confusion. Ashutosh Mukherjee [/quote]   Check here to include your profile signature.