Thanks for the reply.
nancy collins:
|so chris is absolutely right when he says that dimension numbers - at
|least in Slab - aren't tied to any particular position axis.
That's my understanding. The Slice docs mention that "dimension" refers to
the order of the connections. In the example in my last e-mail, Export
confirms...
object 1 class gridpositions counts 3 4
origin 100 200
delta 0 1
delta 2 0
attribute "dep" string "positions"
object 2 class gridconnections counts 3 4
...
...dimension 0 is Y (Y varies slowest -- i.e. row-major order).
|i just went through a bit of doodling on paper to reconvince myself that
|this is still true - that the problem has no right answer for all cases
|because as it stands the module is underspecified. (i'd be glad to
|accept counter-arguments here.)
I agree. In the general case, it's not clear how to set the new origin,
deltas, and series positions. But for axis-aligned regular grids it is.
I pursued this because Slice tries to set series position to the value of
the removed dimension for each slice (which is meaningful for axis-aligned
grids) and Stack picks up these series positions to create the origin and
delta for the new dimension. It appeared these modules were made for each
other.
I also pursued it because the numbers I was getting didn't make sense. In
the simple example, I was slicing out of connection dimension 0 (Y) to get
a full row of dimension 1 (X), and getting a new origin that wasn't in the
domain of X in the original field. It wasn't in the Y domain for the
sliced field either; it was in the Y domain for the original field, which
doesn't make sense.
Currently I "fix" the results of Slice->Reduce->Stack by Inquire'ing and
Compute'ing the correct reduced grid, Construct'ing it, and transferring
all the data fields over from Stack's output with Replace. But doing this
in the general case takes a boatload of modules! There's got to be a
better way.
|this might still be sidestepping the question of what the default
|behavior ought to be if you don't specify the position dimension to
|remove, but if it picks the "wrong" one then it's less of an issue if you
|can explicitly override it.
I agree. My problem (how to Reduce/Filter/etc. 2D slices in a 3D volume)
would be solved if:
1) Slice would take it's cues for removing X,Y,or Z from the non-zero
component in the "dimension"th delta (admittedly that only works for
axis-aligned regular grids),
2) Slice would (as you suggest) let you specify which component (X,Y,or
Z) to remove from origin and deltas, and to extract to series position
(any DX problems with 0-vector deltas or non-unique series positions?),
or
3) Stack would support stacking fields with (n-1) connection dimensions
and (n) position dimensions into n dimensional objects (both in
positions and connections).
#3 appeals to me the most as it seems the most general.
In any case, on the Slice front we're still left with: what assumptions can
be made about the origin and deltas output by Slice? (or should they be
treated as ill-defined).
Thanks,
Randy
----------------------------------------------------------------------------
EXAMPLE: y
/\
||
202 * ---- * ---- * ---- *
| | | |
| | | |
201 * ---- * ---- * ---- *
| | | |
| | | |
200 * ---- * ---- * ---- *
100 102 104 106 ==> x
field = Construct( origin = [ 100,200 ],
deltas = { [ 0,1 ], [ 2,0 ] },
counts = [ 3,4 ] );
slice = Slab( field, dimension=0, position=1, thickness=0 );
--> returns: origin=[100,201], deltas={ [0,1],[2,0] }, counts=[1,4]
slice = Slice( field, dimension=0, position=1 );
--> returns : origin=[200], deltas={ [1] }, counts=[4]
--> SHOULD RETURN: origin=[100], deltas={ [2] }, counts=[4]
----------------------------------------------------------------------------
--
Randall Hopper (mailto:[EMAIL PROTECTED])
Lockheed Martin Operation Support
EPA Scientific Visualization Center
US EPA MD/24 ERC-1A; RTP, NC 27711
