Jonathan, Daniel,
thanks for the quick feedback. So, if I am not too mistaken, I might as
well view this like modelling a slice of pie in cartesian (rectangular)
3D space, and applying zero flux, etc., boundary conditions to the two
flanks (planes of constant theta) of the slice? We really are talking
about a 3D model then. No need to talk about cylindrical coordinates
then, simply model an arbitrary shape (such as a cylinder) in
rectangular 3D space? The question then is, how well will a mesh
approximate curved surfaces? Plus, no matter how thin the slice in 3D, a
computational sacrifice has to be made, because we are dealing with more
grid points in 3D than we would in 2D? Am I getting close, or have I
missed the point?
Regards,
Matt
Jonathan Guyer wrote:
On Jan 18, 2007, at 11:13 AM, Daniel Wheeler wrote:
On Jan 17, 2007, at 4:12 PM, Matt Koch wrote:
I just have no concept of why I would need a 3D mesh to generate a
2D cylindrical mesh.
This is so that the cell volumes and face areas are approximated
correctly. You could of course
subclass from Grid2D to make a CylindricalGrid2D object and
overwrite the methods required to
create cell volumes and face areas. I am not sure if this is all you
have to do, but I suspect it is.
Just in case we're not all thinking the same thing when we say "2D"
and "3D" in this case, I'm going to attempt to clarify (but will
probably fail miserably).
Let's take our cylindrical coordinates to be
r: radial distance from axis of cylinder
theta: azimuthal angle around axis of cylinder
z: distance along length of cylinder
It is a simple matter to map these three coordinates to the Cartesian
coordinates X, Y, Z.
Matt originally said he wanted (r, z), making the common assumption
of axial symmetry. Although (r,z) can be trivially mapped to (x,z),
FiPy's divergence operator will not give the correct result, because
it operates in Cartesian coordinates and will give (\partial \phi_x /
\partial x) instead of (1/r)(\partial (r \phi_r) / \partial r). In
theory, we could come up with a new discretization for the
cylindrical operator, but this wouldn't be fun at all. Instead, by
making a wedge (slice of pie) in X, Y, Z, we should automatically get
a pretty good approximation of the cylindrical operator, because the
areas of the faces and the volumes of the cells would be changing
with the radius, and this gets reflected in the Cartesian
discretization. We think that we could do an even better job by
adjusting the face areas and cell volumes to account for the fact
that the inner and outer faces are curved.
We will probably do this at some stage and it may not be such a big
job, but I can't do it right now.
The stages for doing this are as follows.
1) Create class CylindricalGird2D subclassed from UniformGrid2D.
2) Overwrite getCellVolumes(), getFaceAreas() to have the
correct values.
The idea here is that as long as we're fudging the face areas and
cell volumes in a 3D wedge mesh, we might as well fudge the face
"areas" and cell "volumes" of a 2D mesh. This will require much
testing, but should work.
This is something that has now come up a couple of times on the list
and which is going to be useful for some of our own research, so we
will be working on a canned solution, but I can't say how long it
will take. Actually creating a wedge mesh wouldn't be too hard at
all, but validation will take some time. There are questions like is
it better to have fixed radial spacing or is it better to have the
cell spacing drop off as 1/r or ???.
In addition, if you wanted to look at a problem with axial symmetry
and no z variation (just r in a plane), then it should be possible
adapt a UniformGrid1D in the same basic way, but again, this would
all have to be validated.
3) Tee Geometry
Thanks for the tip. I recall now having stumbled across this
somewhere in the documentation. I assume the "shift and merge"
trick somehow applies to the above cylindrical mesh as well?
Yes, that works in 3D and would work if you created a
CylindricalGrid2D object as well.
Just be aware that the algorithm isn't particularly fancy. The
exterior faces of the different mesh pieces that merge together have
to coincide with each other. FiPy won't try to fix things up if they
don't.
