it is true that dx won't draw curved lines between 2 vertices;
the spacing of the vertices will indeed control how smooth your
curve plots, but my point is that if you do your computation before
you convert from [r,z] to cartesian, it won't matter.  it will be
doing a real linear interpolation in r and in z, without any loss
of accuracy because of sampling density.

before i go any further, maybe a simple experiment will help?

start with an empty dx session.

add a Construct, set origin=[0,0] deltas=[0.68,0.68] counts=[10,10]
(these deltas are to make it easier to convert into approximately
2 pi+ radians later on.)

connect the output to ShowConnections, that output to Image.
look at it.   a 2d grid.  mentally, think of the bottom axis as r,
the vertical axis as z.

now put 3 modules inline between the Construct & ShowConnections:
Mark, Compute, Unmark.   Set the component of Mark to "positions".
set the expression for Compute to "[a.y * cos(a.x), a.y * sin(a.x)]"

now rexecute and you'll hopefully see a circular grid now.  it's not quite
closed - that last stitching between column 0 and column 10 is what
chris was talking about with his previous append.

yes, there are straight lines between the verticies, but stay with me.

last step - take a Refine module, set the level to 1, and place it inline
between the Unmark & ShowConnections.  you get the same outline,
with each quad subdivided into 4 now.   now reconnect Unmark &
ShowConnections and put the Refine between the Construct & Mark.
now you should see a rounder circle.  the latter is doing linear
interpolation in r and z; the former is doing linear interpolation in x, y.
you get smoother & smoother approximations to a circle by making
more & more samples in r,z before converting to x,y.

so until you do the conversion of the positions, any computations you
do are automatically in r,z space, using linear interpolation in r & z, so
you don't have to worry about sampling density until you are ready to
convert.

i'm not sure i understand your question about the div & curl, but i'm
more than happy to point you to the source - look in
  src/exec/dxmods/_divcurl.c
you'll have to skip a lot of dx structuring code at the top.  there are
separate sections for computing div & curl in cubes/hexahedra, in
tets, etc - one per primitive type.   it's pretty highly macro-fied i'm
afraid.

sorry, i'm not sure i understand your geometry, but i think you are
saying that you have data at [r,z] and it should be rotated through all
phi's?   so i think you'd do that by importing a 2d [r,z] plane of quads,
using something like CollectSeries to make a group consisting of
the same plane repeated N times, and then using the Stack module
to make a real 3d volume of cubes in which each 2d sheet is the same.
is that anywhere close?   if so, then you may be able to just stack
2 sheets to make a volume 1 cube thick, do all your computations
in that, and then refine it at whatever density you want for display
purposes.

nancy

Reply via email to