self consistent solution of poisson e... Log Out | Topics | Search
Moderators | Register | Edit Profile

FlexPDE User's Forum » User Postings » self consistent solution of poisson equation « Previous Next »

Author Message
Top of pagePrevious messageNext messageBottom of page Link to this message

ralph krupke (ralph_krupke)
New member
Username: ralph_krupke

Post Number: 1
Registered: 10-2007
Posted on Tuesday, October 23, 2007 - 05:31 pm:   

Task: Calculating the potential profile along a carbon nanotube field effect transistor under fixed source and gate potential and floating drain potential in a cylindrical configuration (nanotube and source-drain electrodes in the center of a cylindrical gate electrode).
Solution: Solving Poisson equation self-consistently by taking into account (1) the floating drain electrode and (2) the charge on the nanotube which depends on the potential (potential dependent material properties).
Problem: The following error message appears:
"Expression Evaluator has encountered an ILLEGAL OPERATOR (Sum())". The error disappears when self-consistency is sacrificed by setting q=0 on the nanotube (region 4).
Question: What are the general rules for setting up such a problem. E.g. is it correct to define the potential u as a variable and to define the potential dependent charge under definitions. The charge enters then the poisson equation via the nanotube, where the charge is assigned to the cylindrical nanotube surface (region4).
application/octet-streamCylindrical CNT-FET self-consistent Poisson equation
test.pde (2.5 k)
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 971
Registered: 06-2003
Posted on Tuesday, October 23, 2007 - 11:18 pm:   

Apparently this is the most complex application of the SUM operator anyone has tried.
There is a logic error in processing the SUM operator if it appears in a source term.

I will repair this error and re-post the recently released version 5.0.19 with the correction.

HOWEVER:
Q is a volume source, but region 4 is merely a line and has no volume. So the source Qz never appears in any mesh cell and can be deleted.

Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 972
Registered: 06-2003
Posted on Tuesday, October 23, 2007 - 11:29 pm:   

Correction:
The crucial factor is that the SUM term has a variable dependency, and therefore is differentiated to form the Jacobian matrix. This is where the logic error occurs.
Top of pagePrevious messageNext messageBottom of page Link to this message

ralph krupke (ralph_krupke)
New member
Username: ralph_krupke

Post Number: 2
Registered: 10-2007
Posted on Wednesday, October 24, 2007 - 03:05 pm:   

Dear Robert, thank you very much for your assistance.
In our problem Q is indeed supposed to be a volume source. By defining region 4 as a line with q=1/(2*pi)*Qz, I was assuming to map the line charge Qz onto a cylinder since the system is anyhow defined in a cylindrical geometry.
If this is not the case, what would be the appropriate approach ?
Concerning the "logic error in processing the SUM operator": Is this also after your second post sth. which you would have to fix ?
Regards, Ralph
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 976
Registered: 06-2003
Posted on Thursday, October 25, 2007 - 01:18 am:   

1.
Simply put, a volume source needs a volume to be a source in.

You have two choices.
a) You can define a volume where the volume source operates.
b) you can define a NATURAL() on the boundary. The NATURAL boundary condition applied internally is a line source (or surface source in 3D), since it is the difference in flux as seem from two sides of the boundary.

2.
A way around the SUM issue is to create an auxiliary FlexPDE script that builds a table of Qz vs U, and use this as a lookup.

The numbers you are using create values of Qz on the order of 1e48, which exceeds the value range acceptable to the FlexPDE table reader, so you need to scale them down. I have done this in the attached script. The script also provides a smoothing factor on the data, since the raw computation creates serious noise, which may destroy Newton's method if used directly. The attached graphics show smoothed and unsmoothed output.

You should check the coefficients in your Qz to determine whether this 1e48 value is correct. Applied to your Poisson equation, the source is 40 orders of magnitude larger than the diffusion term, so the computation crashes from roundoff error.


application/octet-stream
tabulate.pde (1.5 k)


Top of pagePrevious messageNext messageBottom of page Link to this message

ralph krupke (ralph_krupke)
Junior Member
Username: ralph_krupke

Post Number: 3
Registered: 10-2007
Posted on Monday, October 29, 2007 - 03:25 pm:   

Dear Robert, thanks again.
The LUT solution works fine.
I am still not sure how to map the line charge Qz onto a cylindrical surface:
Does your suggested solution 1b means, that if I set natural(u)=Qz along a line in z-direction at r=nanotuberadius, this actually maps this charge onto the cylindrical nanotube surface (within a XCYLINDER model) ? And if so do I have to divide Qz by the nanotube circumference first ?
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 979
Registered: 06-2003
Posted on Monday, October 29, 2007 - 06:58 pm:   

Your equation is
div(eps*grad(u))-q=0
so the Natural(u) BC provides values of normal(eps*grad(u)) on a boundary.
Internally, it is a source corresponding to a generation of normal(eps*grad(u)), and you should provide numbers dimensionally consistent with this. (I presume this is surface charge density).
Top of pagePrevious messageNext messageBottom of page Link to this message

ralph krupke (ralph_krupke)
Member
Username: ralph_krupke

Post Number: 4
Registered: 10-2007
Posted on Wednesday, November 07, 2007 - 03:47 pm:   

Robert, I have once more a question regarding boundary conditions in our XCYLINDER('z','r') Problem.
Can it be that the Natural(u) BC in cylindrical geometry is weighted by (2*PI*R)^-1, representing the fact that the equations are solved in a revolution around the axis ?
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 984
Registered: 06-2003
Posted on Thursday, November 08, 2007 - 01:05 am:   

In the usual case, the Natural() represents a flux, or quantity per unit area per unit time crossing normal to the outer surface.

In cylindrical geometry, the discretized equations are multiplied by differential volume or area metrics before integration.

Total current across a cylindrical boundary is therefore the Natural() value multiplied by 2*pi*r. (Or maybe the 2*pi is missing. once upon a time it was....)

If you report an SINTEGRAL() on a cylindrical surface you will see the effect of the R weighting.
Top of pagePrevious messageNext messageBottom of page Link to this message

ralph krupke (ralph_krupke)
Member
Username: ralph_krupke

Post Number: 5
Registered: 10-2007
Posted on Sunday, November 11, 2007 - 05:31 pm:   

Dear Robert, checking as you suggested with SINTEGRAL() it indeed seems that Natural() values in cylindrical geometry are internally multiplied by a factor 2*pi*r. Thanks.

Coming back to our original problem of setting up properly a self-consistent poisson code: Could you please take a look on the attached pde-file and confirm that the potential is calculated self-consistently. For the moment we have chosen to use the Laplace equation with one potential dependent boundary condition. The charge on this boundary (the nanotube) depends on the surface potential and the link between u and qz is given by the table function. The results we get give the right order of magnitude values, however we dont know how to test whether self-consistency is achieved.
application/octet-stream
CNT_SBFET_2.pde (2.1 k)
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 989
Registered: 06-2003
Posted on Sunday, November 11, 2007 - 06:26 pm:   

I don't know what you mean by achieving self-consistency. The solution will be self-consistent within the specified ERRLIM in each cell. All the equations are solved simultaneously, and if the Newton iteration converges, the equations will be self-consistent.

You could plot an elevation of normal(eps*grad(u)) on each side of the qz boundary and compare with qz to see if it adds up.

I have attached a script with my modifications. You didn't include your Qz table, so I can't run it.

Incidentaly,
1) I assume you want eps0=8.85e-12 not eps0=8.85e-112.
2) You don't need the UPULSE on your qz. The boundary condition (source) is applied on the boundary line at r=RT, so all evaluation points are within the pulse range.
3) You can write simply qz, not qz(u). Qz is defined in the table as being a function of u, so the dependency is implicit.
application/octet-stream
CNT_SBFET_2a.pde (2.4 k)
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 990
Registered: 06-2003
Posted on Monday, November 12, 2007 - 08:20 pm:   

Your posted shapes of Qz look rather strongly peaked. It is possible the Newton's method is not converging.

Newton's method requres that the initial solution estimate be close enough to the final solution that the minimizing functional does not contain spurious maxima or minima. If the slopes become nearly flat, the iteration step may jump too far and diverge.

FlexPDE has a SELECT control to limit the maximum size of any step during the iteration. If you set SELECT CHANGELIM=0.01 or some other small value, it wall cause the Newton iteration to creep until a quadratic valley is found.

If your computation is not converging, try this control.
Top of pagePrevious messageNext messageBottom of page Link to this message

Sabine Blatt (sblatt)
Member
Username: sblatt

Post Number: 10
Registered: 09-2005
Posted on Thursday, November 15, 2007 - 05:40 am:   

Dear Mr Nelson

I work with Ralph on this problem and at the moment try to generate a full 3d simulation of a more realistic setup. Unlike in our previous simulation, the gate and electrodes are now planar structures, while the nanotube - of course - is still a cylinder.
I am currenctly not concerned about the correct boundary conditions for the tube, but only trying to set up the geometry. Besides, I chose non-realistic dimensions to avoid a very time consuming mesh generation. I thought I had defined the surfaces such that they would allow to construct a cylindrical tube between planar electrodes, but something seems to be wrong as I receive a "Mesh entaglement" message when running the simulation. Could you possibly have a look at the script and tell me what went wrong?!
application/octet-stream
3d_CNT_SBFET_makro.pde (4.1 k)


Besides, we found a mistake in our script that you used to set up "tabulate.pde". This explains the weired shape of qz. This is the corrected version:
application/octet-stream
tabulate1.pde (1.5 k)

Top of pagePrevious messageNext messageBottom of page Link to this message

Sabine Blatt (sblatt)
Member
Username: sblatt

Post Number: 11
Registered: 09-2005
Posted on Thursday, November 15, 2007 - 08:27 am:   

I found and corrected one minor mistake, but the simulation still crashes due to mesh errors...
application/octet-stream
3d_CNT_SBFET_makro1.pde (4.4 k)

(Btw, I further increased the dimensions to better see what's going on during the mesh generation.)
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 994
Registered: 06-2003
Posted on Thursday, November 15, 2007 - 06:25 pm:   

----------------------------------
IT APPEARS TO ME THAT THIS WHOLE DEVICE WOULD BE EASIER TO MODEL IN AN UPRIGHT ORIENTATION. You will have a couple of circles and squares and some planar extrusion surfaces. I strongly suggest that you pursue this alternative. See "Samples | Misc | 3D_Domains | 3D_Spool.pde" for an example.
----------------------------------------

There are two problems with the script as you sent it (actually three, but I'll get to that later...):

1)
Two of the regions containing your cylinder extend beyond the radius of the cylinder. This means that the true extent of the cylinder is nowhere made explicit - there is no bounding line at the edge of the cylinder. FlexPDE therefore overlays triangles randomly over the break in surface slope and generates a ragged mating surface.

Put FEATURES along y=RT and y=-RT to delimit the break in surface slope at the waist of the cylinder.
LIMITED FEATURE
layer 3
start(-half_x,RT) line to (half_x,RT)
LIMITED FEATURE
layer 3
start(-half_x,-RT) line to (half_x,-RT)


2)
You have your cylinder lying in contact with the surface 2 plane. This grazing incidence causes trouble for the mesh generator - a knife edge with circular shape. This causes great difficulty. Triangles are randomly placed along the surfaces, some points of which are in contact and some not.

The first fix is to run a FEATURE along the contact point. But there is still the problem of cells with thickness dropping quadratically to zero.
LIMITED FEATURE
layer 2
start(-half_x,0) line to (half_x,0)


If you can logically do it, drop the position of surface 2 to create a small gap between it and the cylinder.
SURFACE "s2" z=-(z_sio2/100) {sample surface @ z=0}

If you cannot do this, you will have to create a narrow strip region at the contact, so that the cylinder has a narrow flat spot and no cell thickness goes to zero.

3)
Having fixed these things, there is still trouble merging the flat contact strips alongside the cylinder. I don't know what is causing this, because it appears that it should work. I am looking into this.

-----------------------------------
Incidentally, there are some points about your script that are of dubious character:

a)
The construct "layer 1 layer 2 thing=5"
does not set thing=5 in layer 1.
You must say
layer 1 thing=5
layer 2 thing=5

b)
You do not need to restate "layer" specifications in a Limited Region. In the fragment:
Layer 1 thing=5
Layer 1
start().....
The second "Layer 1" is redundant and ignored.
The "layer" (or "surface") qualifier does not attach to the bounding path. The occurrence of any "Layer" or "Surface" qualifier associated with parameter definitions in a Limited Region automatically determines what layers and surfaces will contain the path.
Layer-specific boundary conditions along the path must be explicitly qualified at their point of definition. See The documentation of Limited Regions.

c)
Your regions 1 and 2 are the same. Region 1 will therefore be totally overlaid and unseen. You may as well leave it out.

Top of pagePrevious messageNext messageBottom of page Link to this message

Sabine Blatt (sblatt)
Member
Username: sblatt

Post Number: 12
Registered: 09-2005
Posted on Friday, November 16, 2007 - 08:45 am:   

Dear Mr Nelson

thank you for the very helpful comment. Now that you point it out, I agree it would have been easier to model in an upright orientation ;)

I fixed problem 1 and 2 according to your suggestions and I also changed my boundary conditions and parameter definition - hopefully it makes more sense now!

application/octet-stream
3d_CNT_SBFET_makro2.pde (4.5 k)


Do you think problem 3 might be solved (or rather circumvented) by modelling the setup in an upright orientation?
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 996
Registered: 06-2003
Posted on Friday, November 16, 2007 - 01:56 pm:   

Problem (3) is because FlexPDE does not know how to merge out a portion of a region. It can only merge (pinch out) full regions. This would imply that you need to declare the side pieces of the source and drain as separate regions, residing in layers 2,3 and 4, and also declare a new region for the cylinder on the right end.

I think all this trouble would go away if you model it upright. All the cut surfaces would be planes, and there would be no merged (pinched out) layers.
Top of pagePrevious messageNext messageBottom of page Link to this message

Sabine Blatt (sblatt)
Member
Username: sblatt

Post Number: 13
Registered: 09-2005
Posted on Monday, November 19, 2007 - 10:52 am:   

I now modelled our device in an upright orientation. Still, there are a couple of problems which appear during the simulation. I would again be very glad

for your advice!

1) Regarding "3d_CNT_SBFET_makro_upright.pde":
- I tried to fix the potential of the source electrode to phi_S by specifying the potential on the two surfaces "s1" and "S2" and along the boundary of

limited region 3 in layer "l1", while modelling the interior of this region as "void". Somehow this doesn't work and I have to specify a very large epsr. Do

you know what is the problem here?
- I would like to check again what the normal(eps*grad(u)) looks like on the surface and therfore defined some elevation plots for different spots on the

nanotube surface. Can I use your formalism for this in 3d, too?
- Regarding boundary conditions between materials - according to the handbook, unless otherwise specified, the default boundary condition is

natural(u)=0. Does this also hold true for boundaries between materials with different parameters (here epsr)? This would imply that the charge on a

material boundary (with the default bc) is always zero, if I understand correctly...
- I then tried to include the non-zero surface charge of the tube in a similar fashion like in the cylindrical model, i.e. by setting natural(u)=eps*qz along

the boundary of limited region "tube". The simulation then crashes... Can you tell me what to do?

2) As stated earlier, I so far used dimensions which were very different from the realistic dimensions of the system. When I reduce the dimensions to

some "intermediate" values, this again produces meshing errors (see 3d_CNT_SBFET_mini_upright.pde). Why is this? I am currently running the

simulation with the realistic values, but this will take a while...

3) One general question: having calculated and exported via transfer(u) the potential for a certain geometry and set of boundary conditions, is it possible to "re-use" the u-data to plot additional graphs without running the full simulation again? I tried to import both the mesh and the potential, but then "u" is defined twice, and if I delete the "variables u" and the equation and boundary conditions from the script and define the imported "u" in the definitions section, this causes an error when calculating a function of u...

application/octet-stream
3d_CNT_SBFET_makro_upright.pde (5.9 k)

application/octet-stream
3d_CNT_SBFET_mini_upright.pde (5.6 k)
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 999
Registered: 06-2003
Posted on Monday, November 19, 2007 - 02:49 pm:   

0)
Your horizontal layout had the cylinder extending through what becomes layers 3 and 4 in the vertical layout. This is not the case in the vertical. Which did you want?

1)
a)
You set the potential of the source electrode to -Phi_S on surface s2 of region 3. On surface 2, region 4 overlays most of region 3, and the potential is NOT set in region 4. As a result, the potential is forced to -Phi_S only along the ring of region 3 surrounding the cylinder. Put the surface s2 BC into region 4, and you can void layer 1.

b) you can plot normal(eps*grad(u)) on any bounding surface, 2D or 3D. At interior points or on elevations, however, "normal" is undefined (normal to what?) and you must use explicit derivatives or dot products.

c) FlexPDE applies the Divergence theorem to all divergence terms with derivative arguments (ie, second-order terms). In your case, div(eps*grad(u)) produces surface terms normal(eps*grad(u)). These terms are assumed to be zero on interior material interfaces, consistent with Maxwells equations in the absence of free surface charge. "Surface charge" does not include polarization charge.

d) Surface charge density is Qz, not eps*qz. Natural(u) means normal(eps*grad(u)), which is surface charge density. Eps*qz is ambiguous on the boundary if eps is discontinuous. Use Natural(u)=qz. (this converged successfully in the "mini" case with void electrode. See attached.)

2)
The mini configuration gets meshing errors trying to link up the long square pencil of the source electrode. This is probably because the pencil is only one cell wide and the mesh generator does not have sufficent options to find links. Try increasing the mesh density in the electrode. If you VOID the electrode, as I believe you want to do anyway, the problem disappears.


3)
You can read in a TRANSFER file and construct more plots without re-running the simulation. This plotting script should not have any VARIABLES or EQUATIONS. Simply do a TRANSFERMESH('file',U,.....) and plot what you want to see. The domain definition in the importing script must match exactly the domain definition in the exporting script.


application/octet-stream
3d_CNT_SBFET_mini_upright1.pde (5.7 k)

Top of pagePrevious messageNext messageBottom of page Link to this message

Sabine Blatt (sblatt)
Member
Username: sblatt

Post Number: 14
Registered: 09-2005
Posted on Wednesday, November 21, 2007 - 10:24 am:   

Sorry to bother you again, Mr Nelson, but I am still confused with this natural boundary condition...

Starting with the Maxwell equation eps*div(E) = rho, where E is the electric field and rho is the charge density, application of the divergence theorem to a boundary material/vacuum gives eps*n*E = sigma, where n is the normal vector on the surface and sigma is the surface charge. In terms of potential we can write, with E=-grad(u), eps*d/dn(u) = sigma. In the case of a boundary between two materials with different eps, this yields n*(eps1*E-eps2*E) = d/dn(eps1*u-eps2*u) = sigma when we assume eps1 and eps2 to be constant within each material. If natural(u) specified d/dn(u), I would therefore expect the appropriate boundary to take the form natural(u) = sigma/eps = qz/eps in our case.

On the other hand, the FlexPDE Help states "In divergence equations, such as DIV(k F) = 0 [...] The NATURAL boundary condition specifies the value
of (k F . n) on the boundary". This would imply natural(u) = qz in our case, as you suggested. (But apparently then natural (u) is not equal to
d/dn(u)...)

In contrast to that, the results of the cylindrical simulation CNT-SBFET_2a.pde agree with independent calculations only if we set natural(u) = qz*eps (we first did this because the Help also says "If the PDE is multiplied by some factor, then the associated NATURAL boundary condition must be multiplied by the same factor"). In this case, the calculated values of qz also match the numbers of (eval(dr(u),z,r-0.0001*nm)-eval(dr(u),z,r+0.0001*nm)).

I tried all three alternatives in the cylindrical case. The only case in which u is not equal to zero on the tube (in agreement with the predictions from other calculations) is when I use natural(u) = qz*eps.
When running the 3d simulation with natural(u) = qz, the potential again is zero on the tube and the values of qz and the appropriate derivatives of the potential do not agree (btw, in the third elevation there is a mistake: the derivative at this point should be (-dx(u)+dy(u))/sqrt(2)).
Using natural(u) = qz*eps, the potential monitored in the first few iterations of the simulation is non-zero, but then some error occurs and the simulation crashes...

I would again be very glad for your advise!
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 1000
Registered: 06-2003
Posted on Wednesday, November 21, 2007 - 02:17 pm:   

Firstly, the Maxwell equation is div(eps*E)=rho, not eps*div(E)=rho. These are equivalent only in a single material with constant eps.

1) Natural(u) is NOT equivalent to dn(u)! Only in the equation div(grad(u))+S=0 are they the same thing. As we repeatedly state in the documentation, and as you have quoted, the NATURAL() BC defines the values of the surface integrands generated by applying the divergence theorem to second order terms. Application of the divergence theorem to the equation div(eps*grad(u))+S=0 produces surface terms normal(eps*grad(u)). This is the value you must supply in the NATURAL BC.

It is a common topic in EM texts to show that (D2-D1)<dot>n=sigma at a material interface, with D=eps*E (see for example Jackson, "Classical Electrodynamics" p19). FlexPDE defaults to no surface charge, so that the normal component of D is continuous across a material interface. The Natural() BC on an interior boundary provides a value of (D2-D1)<dot>n, or sigma, the free surface charge.

2) Do a dimensional analysis of your equations and verify that eps*grad(u) and qz have the same dimensions (nominally charge per unit area).
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 1001
Registered: 06-2003
Posted on Wednesday, November 21, 2007 - 02:23 pm:   

Clarification:
1)Application of the divergence theorem to the equation div(eps*grad(u))+S=0 produces surface terms normal(eps*grad(u)) on an outer boundary. On an interior boundary, the values of normal(eps*grad(u)) as seen from the two sides of the interface have oppositely directed normals. In the usual case, adding the two oppositely directed terms cancels, producing (D2-D1)<dot>n=0. It is this DIFFERENCE that you must supply in the NATURAL BC at an interior boundary.
Top of pagePrevious messageNext messageBottom of page Link to this message

Sabine Blatt (sblatt)
Member
Username: sblatt

Post Number: 15
Registered: 09-2005
Posted on Tuesday, November 27, 2007 - 11:56 am:   

Dear Mr Nelson

we solved our boundary problem and the "3d_CNT_SBFET_mini" simulation now runs smoothly. Now I would like to simulate the realistic dimensions. Unfortunatelly this involves a wide range of dimensions, from 1e-10 m to 1e-6 m and the simulation crashes during mesh generation.

I tried to insert a variety of mesh control commands to generate a dense mesh in the region around the nanotube, but none of them has the desired effect and I always end up with errors during the mesh generation. I attached my current script (at the moment I only care about the mesh generation, therefore I took out any information concerning the potential) and I would be very glad if you could give me some advise on this issue. I think the best solution would be a mesh which becomes more dense when approaching the nanotube and tried to model this in limited region 2, but without success...
application/octet-stream
3d_CNT_SBFET_nano_mesh.pde (4.5 k)


Thanks again!
Top of pagePrevious messageNext messageBottom of page Link to this message

Robert G. Nelson (rgnelson)
Moderator
Username: rgnelson

Post Number: 1006
Registered: 06-2003
Posted on Tuesday, November 27, 2007 - 05:58 pm:   

Your attempts to control the mesh have caused more trouble than they cure....

The fundamental problem is that the vertical plane in close proximity to the tube is not sensing the cell size in the tube, and is gridding with cells too large to be linked to the nearby tube (We need to explore the reason why this happens).

The easy way to fix this is to put a LIMITED FEATURE joining the wall to the tube. This makes everyone aware of the proximity and the grid is constructed correctly.

In the attached files, we have removed your "Mesh Control Region" (2) and your Mesh_Spacing control on the tube wall. This latter control increases the mesh generation time enormously.

The default cell size on an arc is 30 degrees. The resulting cell wall is bent (parabolic) to conform to the arc shape, so don't be misled by the plots that show straight sides into thinking you need a dense mesh on the arc.

1.
In the attached script nano1.pde, we have removed the items listed above, and added the LIMITED FEATURE. It grids in about 10 minutes.

With your original density on the tube, it runs for many hours. This is because the tube is very long, and cutting the cell dimension by a factor of 3 increases the cell count on the bounding surface by 9 and the number of volume cells by 27. There are also some n-squared search loops in the gridding process. If you want to increase the density on the tube, you can re-activate your mesh_spacing control, but be aware that it is very expensive.

2.
In the attached script nano2.pde, we have used nano1.pde as a starting point and scaled the z-dimension by a factor of 5. This has the effect of elongating the cells in the z direction, and cutting the total cell count by the scaling factor. This problem completes in less than two minutes. See the Tech Note "Coordinate Scaling" for the details of how this is done. You can pick a different number if you want, just change the definition of "S".



application/octet-stream
nano1.pde (4.5 k)

application/octet-stream
nano2.pde (4.6 k)

Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Password:
Options: Enable HTML code in message
Automatically activate URLs in message
Action:

Topics | Last Day | Last Week | Tree View | Search | Help/Instructions | Program Credits Administration