Re: subgridding

[Kevin Thomas <kjt@sgi.com>]

Andy,

The subgridding now available in LC is not a totally general
hexahedral meshing scheme.  Here are the current mesh
generation variants supported:

1. Cubic cells.  This is the original mesh used by LC where
each cell in the mesh is of size (dx,dy,dz), where dx equals
dy equals dz and dx, dy, and dz are constants.  This scheme
works with all the absorbing boundary conditions, and runs the
fastest.  This is the default mesh if the "Mesh Generation"
parameters in the "Define Model Parameters" dialog are not changed.

2. Non-cubic cells.  This originally appeared in version 2.5 in
July.  Each cell is of size (dx,dy,dz) where dx, dy, and dz are
constants.  More computation is required for each field update,
so the simulation may run slower.  Often the reduction in the number
of cells required saves memory and also makes the overall runtime
less.  Currently only the first order Mur (default) ABC works with
non-cubic cells.  This feature can be enabled by turning off the
"Cubic Cells" toggle in the Define Model Parameters dialog and
entering the values for dx, dy, and dz.

3. Non-uniform cells.  This is the new feature released in January
in version 2.7.  "Submesh" blocks are defined within the model to
modify the dx, dy, and dz values within a region, in effect making
dx, dy, and dz variables rather than constants.  The restriction
is that dx can only vary as a function of X (along the X-axis),
dy as a function of Y, and dz as a function of Z.  As many submesh
blocks can be added as required to define any combination of coarsened
or refined regions.  Again only the first order Mur ABC is valid.
There is no additional run-time penalty over the non-cubic
cell mesh.

To answer your questions:

1. Three orthogonal submesh blocks can be defined.  At their
intersection, the mesh will take on the dx, dy, and dz values of
the three blocks.  Elsewhere, one or more of the default mesh dx,
dy, and dz values will be in effect.  An example of this would be
if a single small feature (like a PCB via) must be resolved within
a model (a PCB might have long traces leading up to the via).
Three submesh blocks might be defined to intersect at this small
feature, locally refining the mesh.  Another way to approach this
same problem would be to define some submesh blocks to coarsen the
mesh away from the small feature.

2. Although you can attempt to define a submesh block which does not
touch the edge of the grid, you will notice that it is automatically
extended.  This is just a visual reminder of the restriction on
the mesh generality.  For example, if a submesh block redefines the
X-axis cell size within a region (i.e., redefines dx), then the
block is expanded in the Y and Z dimensions to the edge of the grid.
Thus, it always interacts with the ABC.

Another caveat concerning the submesh blocks is that the current
implementation does not properly take into account "remainders",
where the number of cells within a submesh region is not an
integer.  For example, if the default cell width is 1 mm and a
submesh block redefines dx to 0.3 mm within a 4 mm region, then
a contraction (or possibily, an expansion) of the model occurs
without warning.  If the submesh cell size times the thickness
of the block is an integral multiple of the default cell size,
then you're ok.  In the above example, if the submesh cell size
was 0.25, or the block thickness was 10, then there would be no
distortion.

If I get a chance, I will add some code to properly mend gaps,
perhaps by introducing implicit submesh regions that adjust the
cell size for just one layer of cells.  Also the restriction on
the PML ABC should go away some time.

-- 
Kevin Thomas    kjt@sgi.com    tel 1-651-683-3624
http://reality.sgi.com/kjt/     or 1-800-284-2729 x33624

BYERS ANDREW CLARK wrote:
> 
> Kevin and users,
>         It is great news that the subgridding capability is now
> implemented in lc, and there are several applications that I am looking
> forward to using it with. Here are two questions that I have:
>         1) in order to subgrid 3 dimensions, should I simply overlay three
> separate subgrid regions?
>         2) shouldn't the PML still work for a subgrid cell that does not
> border the boundary?
> 
>         We will check out both of these ideas on our own here, just wanted
> to see if you, or anyone else, had any thoughts on this.
> 
>         Thanks, Andy
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Andy Byers
> University of Colorado at Boulder
> work phone: 303-492-7891
> email: byersa@maori.colorado.edu
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~