> The bummer is that this means that the code for the divergence and curl assume a cartesian coordinate system.
no, not correct. they only assume the coordinate system axes are orthogonal to each other in that coordinate system. so they can be [r,phi,z] and it all just works. you compute curl in that coordinate system, and do some visualization of it - ribbons or glyphs. then right before you display it, you convert just the positions into [x,y,z] to plot them. the connections remain as is. > ... The first > and I'm afraid most difficult problem is that my data are connection > dependent rather than position dependent. Moreover, I'm not sure I > understand how this will work. I have essentially a 2-D data set in (r,z) > which I want to map to a cylindrically symmetric 3-D data set in > (r,phi,z). i don't think that connection dependent data is any sort of problem for dx. in your input file, say the 'data' component is 'dep' on 'connections' instead of 'positions' and you're done. all the modules understand connection dependent data and do the right thing with it. or have you looked at what we do with connection dep data and have a specific reason you think it will cause problems? there's no problem with having 2d surfaces in 3d. you can have quads in 3 space, and/or you can stack sheets of quads into volumes consisting of cubes/hexahedra. they can be in [r,phi,z] space, and you can slice, stack, cut, whatever in your cylindrical coordinates, and then right before you display the results, you convert just the positions to [x,y,z] because we live in a euclidean world. chris p. will probably have something more helpful to say, but don't assume the data model won't let you do what you want. there are limits to it, but from what you've said so far i don't see a problem. you don't need to approximate a curve with small line segments, you can really compute in the curved coordinate system. nancy
