Nancy, Thanks for your reply. What I don't understand is how do the metric terms get included in the calculation of the divergence or curl. For example suppose I'm in cylindrical coordinates and I have a vector with only a radial component, V_r. Then to calculate the divergence I want to know
div V = (1/r) (d/dr) (r V_r) = (V_r / r) + (d/dr) V_r Numerically there are a number of ways to approximate this derivative, but however it is done the code which does the differentiation needs to know the metric terms. For example one way I could see it being done is include the "source terms" (the V_r / r term) when we finally get around to describing the fact that the surfaces of constant (r) are not Euclidian. But since all of the modules are independent, this can't be the way it's done (as far as I can tell). Is there a simple way I can look at the code for calculating the divergence or curl of a vector field. Let me guess, "yes get the cvs and look at the source code!" :-) Any idea what the name of the routines are in charge of the div. and curl operations are? Thanks, Tom On Wed, 21 Jun 2000, nancy collins wrote: > >> 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 > > > >
