Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. From: Alan W. Irwin - 2004-05-09 19:31 ```On 2004-05-09 18:40+0200 Rafael Laboissiere wrote: > * Alan W. Irwin [2004-05-09 08:38]: > > > No. :-) I agree both have a sharp boundary, but the edge limits required in > > the EOS field (and others) are expressed as integer indexes which > > necessarily are quantized and therefore the edges look rough. While the > > defined function in plshade(s) is a PLINT (*defined) (PLFLT, PLFLT) with > > floating point arguments whose limits therefore look smooth. > > I can hardly believe that your quantized indices cannot be expressed as a > smooth, floating point boundary function. For instance, if you have the > following domain in your EOS problem: > > y=3 + + + + > y=2 - + + + > y=1 - - + + > y=0 - - - + > x=0 x=1 x=2 x=3 > > where "-" means excluded and "+" means included, then the following > "defined" function would do the job: > > PLINT > defined (PLFLT x, PLFLT y) > { > return (y >= x + 3); > } > > Using this function with the hypothetical plsurf3dx function that I proposed > in my last post, would produce a nice 3d surface plot with a boundary around > the origin that would be an elegant straight line connecting the points > (x,y) = (0,3) anf (x,y) = (3,0). Instead of rectangular patches, we would > have triangular ones, like those produced by plshades. That tabale above clearly shows the problem. There are at least two options here for the limit. In one, the limit is a discontinuous step function even for your simple example above. So between x = 0. and 1. you want the y limit to be 3., between x = 1. and 2. you want the limit to be 2. etc. Another option is you would want a smooth limit like you have suggested above (perhaps adjusted upward by a half unit so it never wanders into the undefined region.) Eventually, if we do go with a defined function approach we would want it general enough so either type of limit could be used. > > I am quite positive that my proposal is suitable for your EOS problem, or > are we still talking different languages? :-) I think if somebody in the future wanted to make the effort it is possible they could change over to the "defined" type of approach that you are recommending, but it is not trivial. One problem to be overcome is research examples are not as simple as your hypothetical case. The boundaries are complicated in general so they would have to be described by a whole series of y limits depending on the x value (both for the "discontinuous" and "smooth" limits described above). So in the general case you would have to look up the appropriate x range for your x value in a table, then find the y range for that x range, then fill to the limit. (You would also have to programme the case where the x limits were a function of y since the meaning of the fast and slow indices in plsurf3dl is swapped between x and y depending on azimuth). Anyhow, I agree with you the "defined" approach should be possible. However,it is a lot of additional programming effort that I would not want to do myself. If somebody wanted to take this project on in the future, I should mention there is an additional complication that has to be dealt with. The table of x ranges and corresponding y ranges are "user" data that varies from one calculation to the next. Probably the most general way to communicate that data to defined is to add a PLPointer to the argument list of defined, and also add a corresponding PLPointer defined_data argument to your proposed argument list for the plsurf variation that will come after mine. (It's a separate issue, but I should mention that Maurice has recommended this generalization of the defined API for the plshade and plshades case, and some day we should deal with that issue as well.) In sum, my judgment is using the "defined" approach for the plsurf... case is possible but it is non-trivial and therefore something we will want to deal with in the future. Meanwhile, the current plsurf3dl should satisfy a clear research need that we didn't satisfy before. Alan __________________________ Alan W. Irwin email: irwin@... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ```

[Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. Alan W. Irwin <irwin@be...>
 Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. From: Rafael Laboissiere - 2004-05-09 01:44 ```* Alan W. Irwin [2004-05-08 15:54]: > Well, I finally have implemented non-rectangular x and y index limits for a > plsurf3d variant (plsurf3dl). gnuplot has had this functionality since > before the mid-90's, and I needed it for my research so here it is for > PLplot. > > For those interested in the prospective changes, please look at the attached > patch file. It is all added API with no backwards incompatibilities. > > [...] > > Rafael, in particular, you should have a look to make sure there is nothing > in the attached patch file that concerns you as our release manager. As regards the release process, I do not think it would be a problem. I have to check your claim about backwards compatibility, though. > If there are no major objections to the changes, I will commit on Monday. I do not have strong objections to your code, but a remark: I would much prefer for plsurf3dl (or whichever name it had) the same mechanism for exclusions as for plshades, namely a "defined" function as argument. The benefits of this are arbitrary exclusion regions (not only xy max/min regions) and the improved coherence of the PLplot API. Furthermore, the results in demo x08c using your new code do not look very nice, the boundary lines being too ragged. This problem existed before in plshades and I fixed it to produce smooth boundaries. I believe that the same algorithm could be applied to your new plsurf3dl function, once it uses a "defined" argument. -- Rafael ```

 Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. From: Alan W. Irwin - 2004-05-09 05:07 ```On 2004-05-09 03:43+0200 Rafael Laboissiere wrote: > * Alan W. Irwin [2004-05-08 15:54]: > > > Well, I finally have implemented non-rectangular x and y index limits for a > > plsurf3d variant (plsurf3dl). gnuplot has had this functionality since > > before the mid-90's, and I needed it for my research so here it is for > > PLplot. > > > > For those interested in the prospective changes, please look at the attached > > patch file. It is all added API with no backwards incompatibilities. > > > > [...] > > > > Rafael, in particular, you should have a look to make sure there is nothing > > in the attached patch file that concerns you as our release manager. > > As regards the release process, I do not think it would be a problem. I > have to check your claim about backwards compatibility, though. Yes, please. I am virtually positive there are no backwards incompatibilies introduced, but a second look is always worthwhile. If I don't hear from you on this by Monday, I will assume it is okay. > > > If there are no major objections to the changes, I will commit on Monday. > > I do not have strong objections to your code, but a remark: I would much > prefer for plsurf3dl (or whichever name it had) the same mechanism for > exclusions as for plshades, namely a "defined" function as argument. The > benefits of this are arbitrary exclusion regions (not only xy max/min > regions) and the improved coherence of the PLplot API. Eventually, that would be a good idea, but that is a much bigger project then the useful added functionality I have in hand now. > > Furthermore, the results in demo x08c using your new code do not look very > nice, the boundary lines being too ragged. This problem existed before in > plshades and I fixed it to produce smooth boundaries. I believe that the > same algorithm could be applied to your new plsurf3dl function, once it uses > a "defined" argument. The problem I am dealing with has completely sharp non-rectangular boundaries. An Equation of State is calculated on some supercomputer for a certain non-rectangular grid of indices, but the results are completely undefined beyond them. The EOS programme typically fails to converge beyond those boundaries because the fundamental assumptions and approximations in the code begin to break down (especially at relatively cool temperatures and high densities). The consensus in this research field (and also this is how it is handled in the gnuplot algorithm to do the same thing) is to leave those boundaries sharp rather than smoothing them. The idea is to present the results "warts and all" without smoothing so it is clear where the calculation failed at the boundaries. So the present result is perfect for EOS research needs and presumably many other research fields where the consensus opinion is to present unsmoothed research results. Of course, an option for smoothing the edges could be added later on if somebody had a need for it and wanted to do the substantial work involved, but we would also would want to retain the current unsmoothed behaviour as well. I do agree with you that the present two revised x08c pages have rough edges (by design) so we probably do not want to display those pages by default. Thus, I propose to introduce an option to display additional pages demonstrating the new functionality for non-rectangular x/y regions, but by default we will only display the old results. Do you agree with this approach for the example? Alan __________________________ Alan W. Irwin email: irwin@... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ```

 Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. From: Rafael Laboissiere - 2004-05-09 10:02 ```* Alan W. Irwin [2004-05-08 21:59]: > Yes, please. I am virtually positive there are no backwards incompatibilies > introduced, but a second look is always worthwhile. If I don't hear from you > on this by Monday, I will assume it is okay. I will not have time to check this until Monday. Just commit it and we can revert or fix the situation later. > The problem I am dealing with has completely sharp non-rectangular > boundaries. An Equation of State is calculated on some supercomputer for a > certain non-rectangular grid of indices, but the results are completely > undefined beyond them. The EOS programme typically fails to converge beyond > those boundaries because the fundamental assumptions and approximations in > the code begin to break down (especially at relatively cool temperatures and > high densities). The consensus in this research field (and also this is how > it is handled in the gnuplot algorithm to do the same thing) is to leave > those boundaries sharp rather than smoothing them. The idea is to present > the results "warts and all" without smoothing so it is clear where the > calculation failed at the boundaries. So the present result is perfect for > EOS research needs and presumably many other research fields where the > consensus opinion is to present unsmoothed research results. > > Of course, an option for smoothing the edges could be added later on if > somebody had a need for it and wanted to do the substantial work involved, > but we would also would want to retain the current unsmoothed behaviour as > well. I think there is a confusion here. The algorithm involving the exclusion region in the plshades function *_does_* use a sharp boundary. This boundary is defined by the function "defined" which is passed as an argument of plshades. There is no smoothing at all for producing the plot, it's "warts and all". Are we talking the same language? :-) In sum, I think that the exclusion approach via a "defined" function is perfectly adapted for your EOS problem. > I do agree with you that the present two revised x08c pages have rough edges > (by design) so we probably do not want to display those pages by default. > Thus, I propose to introduce an option to display additional pages > demonstrating the new functionality for non-rectangular x/y regions, but by > default we will only display the old results. Do you agree with this > approach for the example? This is a good approach for the x08c example, please implement it. All that said, if your changes do not introduce any backwards incompatibility, I would say let us introduce it. Later, someone could come with an improved plsurf3dx ("x" for "exclusion") which would have a signature like this: plsurf3dx (PLFLT *x, PLFLT *y, PLFLT **z, PLINT nx, PLINT ny, PLINT opt, PLFLT *clevel, PLINT nlevel, PLINT (*defined) (PLFLT, PLFLT)) much cleaner, much better. The problem is that we introduce a plsurf3dl function now that would be obsolete in the future, increasing the amount of bloat in the library. -- Rafael ```

 Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. From: Alan W. Irwin - 2004-05-09 15:44 ```On 2004-05-09 12:01+0200 Rafael Laboissiere wrote: > * Alan W. Irwin [2004-05-08 21:59]: > > The problem I am dealing with has completely sharp non-rectangular > > boundaries. An Equation of State is calculated on some supercomputer for a > > certain non-rectangular grid of indices, but the results are completely > > undefined beyond them. The EOS programme typically fails to converge beyond > > those boundaries because the fundamental assumptions and approximations in > > the code begin to break down (especially at relatively cool temperatures and > > high densities). The consensus in this research field (and also this is how > > it is handled in the gnuplot algorithm to do the same thing) is to leave > > those boundaries sharp rather than smoothing them. The idea is to present > > the results "warts and all" without smoothing so it is clear where the > > calculation failed at the boundaries. So the present result is perfect for > > EOS research needs and presumably many other research fields where the > > consensus opinion is to present unsmoothed research results. > > > > Of course, an option for smoothing the edges could be added later on if > > somebody had a need for it and wanted to do the substantial work involved, > > but we would also would want to retain the current unsmoothed behaviour as > > well. > > I think there is a confusion here. The algorithm involving the exclusion > region in the plshades function *_does_* use a sharp boundary. This > boundary is defined by the function "defined" which is passed as an argument > of plshades. There is no smoothing at all for producing the plot, it's > "warts and all". > > Are we talking the same language? :-) No. :-) I agree both have a sharp boundary, but the edge limits required in the EOS field (and others) are expressed as integer indexes which necessarily are quantized and therefore the edges look rough. While the defined function in plshade(s) is a PLINT (*defined) (PLFLT, PLFLT) with floating point arguments whose limits therefore look smooth. > All that said, if your changes do not introduce any backwards > incompatibility, I would say let us introduce it. I will do it tomorrow (Monday) (with the non-default option in the example we discussed) unless I hear further objections. Alan __________________________ Alan W. Irwin email: irwin@... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ```

 Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. From: Rafael Laboissiere - 2004-05-09 16:41 ```* Alan W. Irwin [2004-05-09 08:38]: > No. :-) I agree both have a sharp boundary, but the edge limits required in > the EOS field (and others) are expressed as integer indexes which > necessarily are quantized and therefore the edges look rough. While the > defined function in plshade(s) is a PLINT (*defined) (PLFLT, PLFLT) with > floating point arguments whose limits therefore look smooth. I can hardly believe that your quantized indices cannot be expressed as a smooth, floating point boundary function. For instance, if you have the following domain in your EOS problem: y=3 + + + + y=2 - + + + y=1 - - + + y=0 - - - + x=0 x=1 x=2 x=3 where "-" means excluded and "+" means included, then the following "defined" function would do the job: PLINT defined (PLFLT x, PLFLT y) { return (y >= x + 3); } Using this function with the hypothetical plsurf3dx function that I proposed in my last post, would produce a nice 3d surface plot with a boundary around the origin that would be an elegant straight line connecting the points (x,y) = (0,3) anf (x,y) = (3,0). Instead of rectangular patches, we would have triangular ones, like those produced by plshades. I am quite positive that my proposal is suitable for your EOS problem, or are we still talking different languages? :-) -- Rafael ```

 Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. From: Alan W. Irwin - 2004-05-09 19:31 ```On 2004-05-09 18:40+0200 Rafael Laboissiere wrote: > * Alan W. Irwin [2004-05-09 08:38]: > > > No. :-) I agree both have a sharp boundary, but the edge limits required in > > the EOS field (and others) are expressed as integer indexes which > > necessarily are quantized and therefore the edges look rough. While the > > defined function in plshade(s) is a PLINT (*defined) (PLFLT, PLFLT) with > > floating point arguments whose limits therefore look smooth. > > I can hardly believe that your quantized indices cannot be expressed as a > smooth, floating point boundary function. For instance, if you have the > following domain in your EOS problem: > > y=3 + + + + > y=2 - + + + > y=1 - - + + > y=0 - - - + > x=0 x=1 x=2 x=3 > > where "-" means excluded and "+" means included, then the following > "defined" function would do the job: > > PLINT > defined (PLFLT x, PLFLT y) > { > return (y >= x + 3); > } > > Using this function with the hypothetical plsurf3dx function that I proposed > in my last post, would produce a nice 3d surface plot with a boundary around > the origin that would be an elegant straight line connecting the points > (x,y) = (0,3) anf (x,y) = (3,0). Instead of rectangular patches, we would > have triangular ones, like those produced by plshades. That tabale above clearly shows the problem. There are at least two options here for the limit. In one, the limit is a discontinuous step function even for your simple example above. So between x = 0. and 1. you want the y limit to be 3., between x = 1. and 2. you want the limit to be 2. etc. Another option is you would want a smooth limit like you have suggested above (perhaps adjusted upward by a half unit so it never wanders into the undefined region.) Eventually, if we do go with a defined function approach we would want it general enough so either type of limit could be used. > > I am quite positive that my proposal is suitable for your EOS problem, or > are we still talking different languages? :-) I think if somebody in the future wanted to make the effort it is possible they could change over to the "defined" type of approach that you are recommending, but it is not trivial. One problem to be overcome is research examples are not as simple as your hypothetical case. The boundaries are complicated in general so they would have to be described by a whole series of y limits depending on the x value (both for the "discontinuous" and "smooth" limits described above). So in the general case you would have to look up the appropriate x range for your x value in a table, then find the y range for that x range, then fill to the limit. (You would also have to programme the case where the x limits were a function of y since the meaning of the fast and slow indices in plsurf3dl is swapped between x and y depending on azimuth). Anyhow, I agree with you the "defined" approach should be possible. However,it is a lot of additional programming effort that I would not want to do myself. If somebody wanted to take this project on in the future, I should mention there is an additional complication that has to be dealt with. The table of x ranges and corresponding y ranges are "user" data that varies from one calculation to the next. Probably the most general way to communicate that data to defined is to add a PLPointer to the argument list of defined, and also add a corresponding PLPointer defined_data argument to your proposed argument list for the plsurf variation that will come after mine. (It's a separate issue, but I should mention that Maurice has recommended this generalization of the defined API for the plshade and plshades case, and some day we should deal with that issue as well.) In sum, my judgment is using the "defined" approach for the plsurf... case is possible but it is non-trivial and therefore something we will want to deal with in the future. Meanwhile, the current plsurf3dl should satisfy a clear research need that we didn't satisfy before. Alan __________________________ Alan W. Irwin email: irwin@... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ```

 Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. From: Rafael Laboissiere - 2004-05-09 21:08 ```* Alan W. Irwin [2004-05-09 12:23]: > That tabale above clearly shows the problem. There are at least two options > here for the limit. In one, the limit is a discontinuous step function even > for your simple example above. So between x = 0. and 1. you want the y limit > to be 3., between x = 1. and 2. you want the limit to be 2. etc. Another > option is you would want a smooth limit like you have suggested above > (perhaps adjusted upward by a half unit so it never wanders into the > undefined region.) Eventually, if we do go with a defined function approach > we would want it general enough so either type of limit could be used. Well, remember that the "defined" function is, by its very nature, completely arbitrary and the user can implement it in the way she wants. In particular, the "real ragged" boundary that you are proposing above (which I find quite strange, by the way) can be trivially implemented in a specific "defined" function. > I think if somebody in the future wanted to make the effort it is possible > they could change over to the "defined" type of approach that you are > recommending, but it is not trivial. One problem to be overcome is research > examples are not as simple as your hypothetical case. The boundaries are > complicated in general so they would have to be described by a whole series > of y limits depending on the x value (both for the "discontinuous" and > "smooth" limits described above). So in the general case you would have to > look up the appropriate x range for your x value in a table, then find the y > range for that x range, then fill to the limit. In this case, just implement the defined function as a table lookup. So what? > (You would also have to programme the case where the x limits were a > function of y since the meaning of the fast and slow indices in plsurf3dl > is swapped between x and y depending on azimuth). I did not quite understand your statement. With the use of the defined function, there is no need to defined which coordinate x or y is a function of which other. Remember that both x and y are arguments of defined, and the user can do whatever she wants with the values. > the "defined" approach should be possible. However,it is a lot of > additional programming effort that I would not want to do myself. The bits of code for doing it are already in plshade.c (I wrote them). I did not look at the code of plsurf3d, but it should be feasible. Of course, I am not asking you to do it... At any rate, the resulting plot would look much nicer and I think it would be a great improvement to PLplot. Take a look at: http://people.debian.org/~rafael/plplot/x08-exclusion.ps This is how the plot in x08 would look like with a defined function. Would that suit your EOS research paper? > If somebody wanted to take this project on in the future, I should mention > there is an additional complication that has to be dealt with. The table of > x ranges and corresponding y ranges are "user" data that varies from one > calculation to the next. Probably the most general way to communicate that > data to defined is to add a PLPointer to the argument list of defined, and > also add a corresponding PLPointer defined_data argument to your proposed > argument list for the plsurf variation that will come after mine. > > (It's a separate issue, but I should mention that Maurice has recommended > this generalization of the defined API for the plshade and plshades case, > and some day we should deal with that issue as well.) Yes, I thought about this as well. This idea is already implemented for the transformation function argument (pltr) of the plshade* API routines and an extension to the defined function is totally feasible. -- Rafael ```

 Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. From: Alan W. Irwin - 2004-05-10 18:16 ```On 2004-05-09 23:07+0200 Rafael Laboissiere wrote: > At any rate, the resulting plot would look > much nicer and I think it would be a great improvement to PLplot. Take a > look at: > > http://people.debian.org/~rafael/plplot/x08-exclusion.ps > I had to agree that was a good looking plot, but Rafael told me privately that it was just a mock-up made with xfig, and some additional programming work will be required to implement his ideas. So here is my plan which I have created based on my recent private discussion with Rafael. * Commit my current working solution (just done, but with no changes to x08c.c, and I have removed plxyindexlimits from the public API since it looks like that will not be used once Rafael's "defined" approach is finalized). Note this solution is done for plsurf3dl, and the new plot3dcl API is sufficient to allow non-rectangular limits in that case. However, that functionality in plot3dcl is currently a no-op and needs more work to be finished. * As time permits (probably post-release), I will continue refining my solution including making non-rectangular boundaries for plot3dcl using the current plot3dcl API. I will abandon this refinement as soon as Rafael gets his "defined" approach to work. * As time permits (probably post-release), Rafael will modify his already existing solution for a "defined" callback function in plshade and plshades to add user data to help define the boundaries of defined regions. This change will require new variants of plshade and plshades, but IMO allowing user data will lift the defined callback function from something of a curiosity to something that will find a lot of use since in general boundaries are quite complicated and being able to define them with the help of user-supplied data will be extremely useful. I am already looking forward to an example plshades plot with so many random holes with random sizes that it will look something like a complicated slice of swiss cheese. * Rafael will also propagate his modified "defined" solution to new variants of plsurf and plot3d to replace my current solution. (Propagating the defined solution to a new variant of plcont will also be required since plsurf, plot3d and friends all call a variant of plcont to get the contours at the bottom of the plots.) Rafael and I are in complete agreement that there is going to be substantial API bloat from all these new variants of plshade, plshades, plcont, plsurf, and plot3d, but it is worth it to get all this new "swiss-cheese" functionality, and bloating the API means there will be no backwards incompatibilities introduced to the API at this time. We believe the advent of plplot6 will give us an excellent chance to do a massive cleanup of this API bloat in any case. Alan __________________________ Alan W. Irwin email: irwin@... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ```

 Re: [Plplot-devel] Added API for a plsurf3d variant (plsurf3dl) which implements non-rectangular index limits. From: Rafael Laboissiere - 2004-05-10 21:20 ```* Alan W. Irwin [2004-05-10 11:16]: > So here is my plan which I have created based on my recent private > discussion with Rafael. Thanks for summarizing the situation, Alan. Just a comment: > * As time permits (probably post-release), Rafael will modify his already > existing solution for a "defined" callback function in plshade and > plshades to add user data to help define the boundaries of defined > regions. [...] > > * Rafael will also propagate his modified "defined" solution to new variants > of plsurf and plot3d to replace my current solution. [...] I do not have the slight idea of when I will start to even just think about a possible implementation of the "defined" solution. In order words, this may be a long-term project. Do not wait anything from me any soon. -- Rafael ```