From: Ed Z. <za...@ce...> - 2010-04-19 21:06:26
Attachments:
plcont.patch
m2.png
|
Hi All, I've been using plplot for a project where we have to plot so-called "co-tidal charts" which display the amplitude and phase of the tide in the ocean. The amplitude is normally shown with a color image (made with plimage), and the phase is shown with contours (using the fortran interface, plcon1). As you may know, contours of phase data have jumps where the phase wraps around, say, the 0/360 degree reference phase. This leads to situations in contour plots where the phase is contoured nicely, except where these jumps occur. Within the jump, all the contour lines are packed into the jump. This is an unavoidable consequence of trying to contour phase in 2-d, whenever the field has zero amplitude points (so-called, amphidromes, in the tidal context) where the phase is undefined. I've attached a little patch to plplot/src/plcont.c from a freshly checked out source distribution (r10926). I wonder if you might consider adding a new subroutine to the plplot library, say, plcont_phase, which would correctly represent phase contours without the jumps? Unfortunately, the only way to make these plots nicely is to tamper with the core of the contouring routine, since it involves wrapping the phases locally for the corners of each grid cell. Other approaches, such as making the phase plot an image and wrapping the color map, can't be used when you want to overlay the phase contours on another image. Other approaches which are contour-based don't permit one to visually dis-ambiguate, say, the 0deg phase line from the 180deg phase line. I've included a sample image which shows (with thicker contour lines), how the 0deg phase lines simply end at amphidromic points. I'm using the fortran interface to plplot, and I'm not that familiar with cmake or how to generate all the language bindings, so I simply modified the plcont.c code (this is the only kind of contour plot I presently require). Possibly someone here could add the proposed plcont_phase routine, or point me to instructions for updating the cmake and language bindings. These would all follow plcont exactly, although it might be more professional to add a new parameter to the plcont_phase interface which specifies the units of phase (say, degrees or radians). If you want to include this in plplot, I can supply some example code for the "examples" to show contouring with and without this feature. Regards, Ed |
From: Alan W. I. <ir...@be...> - 2010-04-19 22:22:24
|
On 2010-04-19 13:47-0700 Ed Zaron wrote: > Hi All, > I've been using plplot for a project where we have to plot so-called "co-tidal charts" which display the amplitude and phase of the tide in the ocean. The amplitude is normally shown with a color image (made with plimage), and the phase is shown with contours (using the fortran interface, plcon1). > As you may know, contours of phase data have jumps where the phase wraps around, say, the 0/360 degree reference phase. This leads to situations in contour plots where the phase is contoured nicely, except where these jumps occur. Within the jump, all the contour lines are packed into the jump. This is an unavoidable consequence of trying to contour phase in 2-d, whenever the field has zero amplitude points (so-called, amphidromes, in the tidal context) where the phase is undefined. > I've attached a little patch to plplot/src/plcont.c from a freshly checked out source distribution (r10926). I wonder if you might consider adding a new subroutine to the plplot library, say, plcont_phase, which would correctly represent phase contours without the jumps? Hi Ed: I haven't looked at your patch, but I assume it processes phase data to impose phase continuity so that after processing you end up (in general) with a continous phase range from -M*360 deg to N*360 deg which is easy to contour. Assuming your patch does something like that, the question which I would like you to discuss further is whether this is of sufficient usefulness to PLplot users to add this functionality to our API for all the languages we support or whether this straightforward processing to impose phase continuity should be done by individual users before they call PLplot with their (now) continuous phase data. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Maurice L. <mj...@br...> - 2010-04-20 03:21:24
|
On Monday, April 19, 2010 at 15:22:14 (-0700) Alan W. Irwin writes: > On 2010-04-19 13:47-0700 Ed Zaron wrote: > > > Hi All, > > > I've been using plplot for a project where we have to plot so-called > "co-tidal charts" which display the amplitude and phase of the tide in the > ocean. The amplitude is normally shown with a color image (made with > plimage), and the phase is shown with contours (using the fortran interface, > plcon1). > > > As you may know, contours of phase data have jumps where the phase wraps > around, say, the 0/360 degree reference phase. This leads to situations in > contour plots where the phase is contoured nicely, except where these jumps > occur. Within the jump, all the contour lines are packed into the jump. This > is an unavoidable consequence of trying to contour phase in 2-d, whenever > the field has zero amplitude points (so-called, amphidromes, in the tidal > context) where the phase is undefined. > > > I've attached a little patch to plplot/src/plcont.c from a freshly checked > out source distribution (r10926). I wonder if you might consider adding a > new subroutine to the plplot library, say, plcont_phase, which would > correctly represent phase contours without the jumps? > > Hi Ed: > > I haven't looked at your patch, but I assume it processes phase data to > impose phase continuity so that after processing you end up (in general) > with a continous phase range from -M*360 deg to N*360 deg which is easy to > contour. > > Assuming your patch does something like that, the question which I would > like you to discuss further is whether this is of sufficient usefulness to > PLplot users to add this functionality to our API for all the languages we > support or whether this straightforward processing to impose phase > continuity should be done by individual users before they call PLplot with > their (now) continuous phase data. I agree with Alan, AFAICT the phase transformation can & therefore should be done in user space. I suggest a suitable wrapper function on your end, to copy and transform the data as necessary. Note, people doing polar plots (shades or contours) have to similarly massage their data before passing it to plplot in order to pick up the continuity condition at angle 0 = 2pi. One could claim this is an important effect for the library to handle natively, but frankly I've never seen the need, preferring a leaner and more easily maintained API. This is illustrated (rather quietly) in the final (polar) plot of example 16, where the angle coordinate value runs from 0 to 2pi inclusive -- providing a duplicated data point to enforce continuity. -- Maurice LeBrun |
From: David M. <da...@as...> - 2010-04-20 04:55:08
|
Hi, Ed, On Apr 19, 2010, at 13:47 , Ed Zaron wrote: > it involves wrapping the phases locally for the corners of each > grid cell. In addition to the already mentioned possibility of creating a "wrapped phase" copy of your data array, another alternative you might want to consider is using the "plfcont" routine rather than c_plcont (aka plcont). The "plf" variants of 2d data functions are passed data via a pointer to the data and a pointer to either an evaluator function or (for "new style" plf functions) a structure of pointers to a set of operator functions. For each point, the 2d data function will access the user data via the evaluator function (which is passed the user data pointer). If you could create an "evaluator" function that performed the local phase wrap for each point "on-the-fly", I think you'd be able to do what you want with the existing plplot API without having to create a "wrapped phase" (or even "unwrapped phase") copy of your data. My guess is that whatever you added to plcont's internals could be refactored into a suitable evaluator function. If you look at the implementation of c_plcont, you'll see that it simply calls plfcont "with a particular choice for f2eval and f2eval_data". In your case, f2eval_data would be a pointer to your data and f2eval would be replaced with your "local phase wrap evaluator function". Hope this helps, Dave |
From: Alan W. I. <ir...@be...> - 2010-04-20 05:35:44
|
On 2010-04-19 22:21-0500 Maurice LeBrun wrote: > On Monday, April 19, 2010 at 15:22:14 (-0700) Alan W. Irwin writes: > > On 2010-04-19 13:47-0700 Ed Zaron wrote: > > > > > Hi All, > > > > > I've been using plplot for a project where we have to plot so-called > > "co-tidal charts" which display the amplitude and phase of the tide in the > > ocean. The amplitude is normally shown with a color image (made with > > plimage), and the phase is shown with contours (using the fortran interface, > > plcon1). > > > > > As you may know, contours of phase data have jumps where the phase wraps > > around, say, the 0/360 degree reference phase. This leads to situations in > > contour plots where the phase is contoured nicely, except where these jumps > > occur. Within the jump, all the contour lines are packed into the jump. This > > is an unavoidable consequence of trying to contour phase in 2-d, whenever > > the field has zero amplitude points (so-called, amphidromes, in the tidal > > context) where the phase is undefined. > > > > > I've attached a little patch to plplot/src/plcont.c from a freshly checked > > out source distribution (r10926). I wonder if you might consider adding a > > new subroutine to the plplot library, say, plcont_phase, which would > > correctly represent phase contours without the jumps? > > > > Hi Ed: > > > > I haven't looked at your patch, but I assume it processes phase data to > > impose phase continuity so that after processing you end up (in general) > > with a continous phase range from -M*360 deg to N*360 deg which is easy to > > contour. > > > > Assuming your patch does something like that, the question which I would > > like you to discuss further is whether this is of sufficient usefulness to > > PLplot users to add this functionality to our API for all the languages we > > support or whether this straightforward processing to impose phase > > continuity should be done by individual users before they call PLplot with > > their (now) continuous phase data. > > I agree with Alan, AFAICT the phase transformation can & therefore should be > done in user space. I suggest a suitable wrapper function on your end, to > copy and transform the data as necessary. > > Note, people doing polar plots (shades or contours) have to similarly massage > their data before passing it to plplot in order to pick up the continuity > condition at angle 0 = 2pi. One could claim this is an important effect for > the library to handle natively, but frankly I've never seen the need, > preferring a leaner and more easily maintained API. This is illustrated > (rather quietly) in the final (polar) plot of example 16, where the angle > coordinate value runs from 0 to 2pi inclusive -- providing a duplicated data > point to enforce continuity. Hi Ed: Let me add a bit more to what Maurice said by talking about a specific example. Suppose the function you are plotting is theta(x,y), where theta = arctan2(y, x) In this (simple) case, there is obviously a 2 pi discontinuity in theta at +/- pi. For lack of a better term, let's call that an angle range discontinuity. I don't have a lot of experience with the plcont API, but I know it is quite general and the "Contour and Shade PLot" section of our documentation at http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.5/contour-plots.html says the following: "Examples of the use of these transformation routines are given in examples/c/x09c.c, examples/c/x14c.c, and examples/c/x16c.c. These same three examples also demonstrate a user-defined transformation function mypltr which is capable of arbitrary translation, rotation, and/or shear. By defining other transformation subroutines, it is possible to draw contours wrapped around polar grids etc." It appears to me that last sentence is stating the user-defined transformation function is the proper way to deal with contouring of angular data with range discontinuities like the simple example above. The same approach may allow you to deal properly with your more general case of a phase range discontinuity occuring at arbitrary curves in the x, y, plane. Maurice, do you agree or was there something else you had in mind? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Maurice L. <mj...@br...> - 2010-04-20 07:40:16
|
On Monday, April 19, 2010 at 22:35:33 (-0700) Alan W. Irwin writes: > On 2010-04-19 22:21-0500 Maurice LeBrun wrote: > > [...] > > Note, people doing polar plots (shades or contours) have to similarly massage > > their data before passing it to plplot in order to pick up the continuity > > condition at angle 0 = 2pi. One could claim this is an important effect for > > the library to handle natively, but frankly I've never seen the need, > > preferring a leaner and more easily maintained API. This is illustrated > > (rather quietly) in the final (polar) plot of example 16, where the angle > > coordinate value runs from 0 to 2pi inclusive -- providing a duplicated data > > point to enforce continuity. > > Hi Ed: > > Let me add a bit more to what Maurice said by talking about a specific > example. Suppose the function you are plotting is theta(x,y), where theta = > arctan2(y, x) In this (simple) case, there is obviously a 2 pi discontinuity > in theta at +/- pi. For lack of a better term, let's call that an > angle range discontinuity. > > I don't have a lot of experience with the plcont API, but I know it is quite > general and the "Contour and Shade PLot" section of our documentation at > http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.5/contour-plots.html > says the following: > > "Examples of the use of these transformation routines are given in > examples/c/x09c.c, examples/c/x14c.c, and examples/c/x16c.c. These same > three examples also demonstrate a user-defined transformation function > mypltr which is capable of arbitrary translation, rotation, and/or shear. By > defining other transformation subroutines, it is possible to draw contours > wrapped around polar grids etc." > > It appears to me that last sentence is stating the user-defined > transformation function is the proper way to deal with contouring of angular > data with range discontinuities like the simple example above. The same > approach may allow you to deal properly with your more general case of a > phase range discontinuity occuring at arbitrary curves in the x, y, plane. > Maurice, do you agree or was there something else you had in mind? The general remapping of coordinates is a crucial part of it. I was also pointing out how one can achieve a specific functional boundary condition i.e. f(r, 0) == f(r, 2pi) on a polar grid without having to support that in plplot per se. Typically when one discretizes space it's a one-to-one mapping between grid indices and spatial coordinates barring degenerate points like r=0 (which I have never liked and tend to avoid if possible). If you do a contour or shade plot for such a "regular" discretization in polar coordinates, IIRC you end up with a plot that looks like a pie with a slice cut out of it -- because the contourer and shader know nothing about your boundary condition. You've just taken a rectangular grid and stretched it around until it approximates a circle. To "fill in the pie slice" you need to add in an "extra" gridpoint at 2pi. It's redundant, so anathema to the central loops in a simulation code, but makes the diagnostic give the result you want. So in this case the wrapper function is called for. In example 16 you can see the wrap-around in theta clearly: for ( i = 0; i < nx; i++ ) { r = ( (PLFLT) i ) / ( nx - 1 ); for ( j = 0; j < ny; j++ ) { t = ( 2. * M_PI / ( ny - 1. ) ) * j; cgrid2.xg[i][j] = r * cos( t ); cgrid2.yg[i][j] = r * sin( t ); z[i][j] = exp( -r * r ) * cos( 5. * M_PI * r ) * cos( 5. * t ); } } although like I mentioned it's not well-advertised. Sorry.. -- Maurice LeBrun |
From: David M. <da...@as...> - 2010-04-20 15:23:55
|
Hi, Maurice and Alan, On Apr 20, 2010, at 0:39 , Maurice LeBrun wrote: > The general remapping of coordinates is a crucial part of it. I think you are referring to the 0/2pi coordinate "seam" when transforming a rectilinear grid to a polar grid. I think Ed (correct me if I'm wrong, Ed) is referring to a different problem of contouring the phase (i.e. angle or arg) of complex data values regardless of the grid type (i.e. rectilinear or polar). One approach I've taken in the past when visualizing 2d complex data fields (and would like to add to plsurf3d et al) is to make a surface plot with z values based on the amplitudes and color values based on the phase. Using the phase as the hue component of HSL (or HSV) makes for a nice colorization that handles phase wrapping intrinsically since the HSL "color wheel" wraps smoothly itself. Unfortunately, this "trick" doesn't help for contouring data. Dave |
From: Alan W. I. <ir...@be...> - 2010-04-20 16:14:16
|
On 2010-04-20 08:23-0700 David MacMahon wrote: > Hi, Maurice and Alan, > > On Apr 20, 2010, at 0:39 , Maurice LeBrun wrote: > >> The general remapping of coordinates is a crucial part of it. > > I think you are referring to the 0/2pi coordinate "seam" when transforming a > rectilinear grid to a polar grid. I should emphasize for my simple test case that theta(x,y) = arctan2(y, x) is the function you are contouring on a rectilinear x, y grid, and that no remapping of coordinates away from an x, y coordinate system is desired. So the question is whether there is a practical way with our current API to contour that simple test case without the contours going crazy at the discontinuity? I believe the answer is (although I am not completely positive since I have never tried it) the user-defined transformation function could simply interpolate the grid of theta values in x and y without doing any coordinate transformation but demand local continuity of theta by adding or subtracting 2 pi when necessary. And similarly for the more general case described by Ed. BTW, if somebody believes my idea for proper contouring of the simple test case would work and is willing to implement it, then that would make a nice additional page for example 9 to refer to if this topic ever comes up again. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |