From: Hiroyasu Y. <h-y...@ce...> - 2007-12-10 08:31:07
Attachments:
ggrid.png
|
Dear all: I would like to plot vectors in general curve coordinate as attached picture. Of course I have already try to be plotting with plvec2. When I gave the vector data which is u =1.0 and v=0.0, the plotted vectors look like along co-orthogonal coordinate. I think that plplot has the vector plotting function in general curve coordinate because I read the reference of plplot and sample code of x22f. Can we plot that things? Regards, Hiro |
From: Arjen M. <arj...@wl...> - 2007-12-10 08:53:46
|
> Dear all: > > I would like to plot vectors in general curve coordinate as attached > picture. Of course I have already try to be plotting with plvec2. > When I gave the vector data which is u =1.0 and v=0.0, the plotted > vectors look like along co-orthogonal coordinate. > > I think that plplot has the vector plotting function in general curve > coordinate because I read the reference of plplot and sample code of > x22f. Can we plot that things? > Hello Hiro, that means that the components of the vector are not cartesian but based on the (local) coordinate system (or grid orientation)? That means that PLplot will have to keep track of this more general coordinate system. Isn't it simpler to convert the components from the curve coordinate system to the cartesian plotting coordinates? For instance, in the case of polar coordinates: u = R cos phi v = R sin phi where R and phi are the polar components of the vector. Regards, Arjen |
From: Hiroyasu Y. <h-y...@ce...> - 2007-12-10 14:12:15
|
On 2007/12/10, at 17:53, Arjen Markus wrote: >> Dear all: >> >> I would like to plot vectors in general curve coordinate as attached >> picture. Of course I have already try to be plotting with plvec2. >> When I gave the vector data which is u =1.0 and v=0.0, the plotted >> vectors look like along co-orthogonal coordinate. >> >> I think that plplot has the vector plotting function in general curve >> coordinate because I read the reference of plplot and sample code of >> x22f. Can we plot that things? >> Hello Arjen: > that means that the components of the vector are not cartesian > but based on the (local) coordinate system (or grid orientation)? Yes, that is, I have been computing with local coordinate system. > That means that PLplot will have to keep track of this more general > coordinate system. Isn't it simpler to convert the components from > the curve coordinate system to the cartesian plotting coordinates? When I'm computing and then plot the vectors with local coordinate system, do we have to convert the vector component to plot the vectors along local coordinate under plplot? Regards, Hiro |
From: Andrew R. <and...@us...> - 2007-12-10 14:41:48
|
On Mon, Dec 10, 2007 at 11:11:42PM +0900, Hiroyasu Yasuda wrote: > > On 2007/12/10, at 17:53, Arjen Markus wrote: > > >> Dear all: > >> > >> I would like to plot vectors in general curve coordinate as attached > >> picture. Of course I have already try to be plotting with plvec2. > >> When I gave the vector data which is u =1.0 and v=0.0, the plotted > >> vectors look like along co-orthogonal coordinate. > >> > >> I think that plplot has the vector plotting function in general curve > >> coordinate because I read the reference of plplot and sample code of > >> x22f. Can we plot that things? > >> > > Hello Arjen: > > > that means that the components of the vector are not cartesian > > but based on the (local) coordinate system (or grid orientation)? > > Yes, that is, I have been computing with local coordinate system. > > > That means that PLplot will have to keep track of this more general > > coordinate system. Isn't it simpler to convert the components from > > the curve coordinate system to the cartesian plotting coordinates? > > When I'm computing and then plot the vectors with local coordinate > system, do we have to convert the vector component to plot the > vectors along local coordinate under plplot? Hiro, Although you can specify non-cartesian coordinates to plot vectors at, for example using pltr2 as in the last plot of example 22, this only specifies the location of the vectors. The vector components are always assumed to be cartesian. As Arjen said, if you want to use local coordinates for the vector components, you need to convert them to cartesian cordinates before plotting. Andrew |
From: Hiroyasu Y. <h-y...@ce...> - 2007-12-10 23:11:42
|
On 2007/12/10, at 23:41, Andrew Ross wrote: > On Mon, Dec 10, 2007 at 11:11:42PM +0900, Hiroyasu Yasuda wrote: >> >> On 2007/12/10, at 17:53, Arjen Markus wrote: >> >>>> Dear all: >>>> >>>> I would like to plot vectors in general curve coordinate as >>>> attached >>>> picture. Of course I have already try to be plotting with plvec2. >>>> When I gave the vector data which is u =1.0 and v=0.0, the plotted >>>> vectors look like along co-orthogonal coordinate. >>>> >>>> I think that plplot has the vector plotting function in general >>>> curve >>>> coordinate because I read the reference of plplot and sample >>>> code of >>>> x22f. Can we plot that things? >>>> >> >> Hello Arjen: >> >>> that means that the components of the vector are not cartesian >>> but based on the (local) coordinate system (or grid orientation)? >> >> Yes, that is, I have been computing with local coordinate system. >> >>> That means that PLplot will have to keep track of this more general >>> coordinate system. Isn't it simpler to convert the components from >>> the curve coordinate system to the cartesian plotting coordinates? >> >> When I'm computing and then plot the vectors with local coordinate >> system, do we have to convert the vector component to plot the >> vectors along local coordinate under plplot? > Hello, Andrew: > The vector components are always assumed to be cartesian. As Arjen > said, if you want to use local coordinates for the vector components, > you need to convert them to cartesian cordinates before plotting. I understand that you mention. However, the plplot reference of plvec2 in Chapter 20 said that: NOTE: this function is intended for use from a Fortran 77 caller only. The C user should instead call plvect using the built-in transformation function pltr2 for the same capability. Can we plot directly the vectors along curve coordinate with plvec2 ? Regards, Hiro |
From: Andrew R. <and...@us...> - 2007-12-11 16:46:55
|
On Tue, Dec 11, 2007 at 08:11:03AM +0900, Hiroyasu Yasuda wrote: > On 2007/12/10, at 23:41, Andrew Ross wrote: > > > On Mon, Dec 10, 2007 at 11:11:42PM +0900, Hiroyasu Yasuda wrote: > >> > >> On 2007/12/10, at 17:53, Arjen Markus wrote: > >> > >>>> Dear all: > >>>> > >>>> I would like to plot vectors in general curve coordinate as > >>>> attached > >>>> picture. Of course I have already try to be plotting with plvec2. > >>>> When I gave the vector data which is u =1.0 and v=0.0, the plotted > >>>> vectors look like along co-orthogonal coordinate. > >>>> > >>>> I think that plplot has the vector plotting function in general > >>>> curve > >>>> coordinate because I read the reference of plplot and sample > >>>> code of > >>>> x22f. Can we plot that things? > >>>> > >> > >> Hello Arjen: > >> > >>> that means that the components of the vector are not cartesian > >>> but based on the (local) coordinate system (or grid orientation)? > >> > >> Yes, that is, I have been computing with local coordinate system. > >> > >>> That means that PLplot will have to keep track of this more general > >>> coordinate system. Isn't it simpler to convert the components from > >>> the curve coordinate system to the cartesian plotting coordinates? > >> > >> When I'm computing and then plot the vectors with local coordinate > >> system, do we have to convert the vector component to plot the > >> vectors along local coordinate under plplot? > > > > Hello, Andrew: > > > The vector components are always assumed to be cartesian. As Arjen > > said, if you want to use local coordinates for the vector components, > > you need to convert them to cartesian cordinates before plotting. > > I understand that you mention. However, the plplot reference of > plvec2 in Chapter 20 said that: > > NOTE: this function is intended for use from a Fortran 77 caller > only. The C user should instead call plvect using the built-in > transformation function pltr2 for the same capability. > > Can we plot directly the vectors along curve coordinate with plvec2 ? plvec2 is equivalent to calling plvect with the pltr2 function as the pltr. This only affects the location of the vectors, not the direction / magnitude. The only reason for plvec2 etc is that fortran (and several other bindings) don't allow you to pass a function name as an argument. They provided a limited subset of the possible functionality of plvect. Andrew |
From: Arjen M. <arj...@wl...> - 2007-12-12 08:20:56
|
Andrew Ross wrote: >plvec2 is equivalent to calling plvect with the pltr2 function as the >pltr. This only affects the location of the vectors, not the direction / >magnitude. > >The only reason for plvec2 etc is that fortran (and several other bindings) >don't allow you to pass a function name as an argument. They provided a >limited subset of the possible functionality of plvect. > > Hello Andrew, is that the reason for plvec2? Because Fortran, ever since it supported user-defined functions, so at least from FORTRAN IV onwards, has supported passing function names as arguments. There is an important limitation vis-a-vis the _data_ that you can pass - that is: no equivalent to (void *) types, but function names are no problem at all! Regards, Arjen |
From: Andrew R. <and...@us...> - 2007-12-12 08:34:59
|
On Wed, Dec 12, 2007 at 09:20:46AM +0100, Arjen Markus wrote: > Andrew Ross wrote: > > >plvec2 is equivalent to calling plvect with the pltr2 function as the > >pltr. This only affects the location of the vectors, not the direction / > >magnitude. > > > >The only reason for plvec2 etc is that fortran (and several other bindings) > >don't allow you to pass a function name as an argument. They provided a > >limited subset of the possible functionality of plvect. > > > > > Hello Andrew, > > is that the reason for plvec2? Because Fortran, ever since it supported > user-defined > functions, so at least from FORTRAN IV onwards, has supported passing > function names as arguments. There is an important limitation vis-a-vis > the _data_ > that you can pass - that is: no equivalent to (void *) types, but > function names are > no problem at all! As far as I understand it, this was the issue. Remeber that the function has to be converted to a C function argument that can be passed to the C API of the plplot library, and not just called by other fortran code. Can this be done? Andrew |
From: Arjen M. <arj...@wl...> - 2007-12-12 08:51:59
|
Andrew Ross wrote: >On Wed, Dec 12, 2007 at 09:20:46AM +0100, Arjen Markus wrote: > > >>Andrew Ross wrote: >> >> >> >>>plvec2 is equivalent to calling plvect with the pltr2 function as the >>>pltr. This only affects the location of the vectors, not the direction / >>>magnitude. >>> >>>The only reason for plvec2 etc is that fortran (and several other bindings) >>>don't allow you to pass a function name as an argument. They provided a >>>limited subset of the possible functionality of plvect. >>> >>> >>> >>> >>Hello Andrew, >> >>is that the reason for plvec2? Because Fortran, ever since it supported >>user-defined >>functions, so at least from FORTRAN IV onwards, has supported passing >>function names as arguments. There is an important limitation vis-a-vis >>the _data_ >>that you can pass - that is: no equivalent to (void *) types, but >>function names are >>no problem at all! >> >> > >As far as I understand it, this was the issue. Remeber that the function >has to be converted to a C function argument that can be passed to the C >API of the plplot library, and not just called by other fortran code. >Can this be done? > > Yes, it can. I do not have the source code at hand right now, but I remember doing just that for the Fortran 90 interface - for plmap(), IIRC. I wrote a small C wrapper that gets the function name/address and then calls the Fortran routine. It was a bit tricky because of different calling conventions on Windows, but with such a wrapper it is quite possible. Regards, Arjen |
From: Andrew R. <and...@us...> - 2007-12-12 09:13:35
|
On Wed, Dec 12, 2007 at 09:51:59AM +0100, Arjen Markus wrote: > Andrew Ross wrote: > > >>Hello Andrew, > >> > >>is that the reason for plvec2? Because Fortran, ever since it supported > >>user-defined > >>functions, so at least from FORTRAN IV onwards, has supported passing > >>function names as arguments. There is an important limitation vis-a-vis > >>the _data_ > >>that you can pass - that is: no equivalent to (void *) types, but > >>function names are > >>no problem at all! > >> > >> > > > >As far as I understand it, this was the issue. Remeber that the function > >has to be converted to a C function argument that can be passed to the C > >API of the plplot library, and not just called by other fortran code. > >Can this be done? > > > > > Yes, it can. I do not have the source code at hand right now, but I > remember > doing just that for the Fortran 90 interface - for plmap(), IIRC. I > wrote a small C wrapper that gets > the function name/address and then calls the Fortran routine. It was a > bit tricky because > of different calling conventions on Windows, but with such a wrapper it > is quite possible. Ah yes. I should have looked more closely at this. Was there a reason you didn't do this for the plvect / plcont functions in the F95 bindings? I'm not sure I would advocate changing this now as we already have plvect / plcont implemented, although with different arguments to their C counterparts. Perhaps you could think about this? Andrew |
From: Arjen M. <arj...@wl...> - 2007-12-12 09:28:53
|
Andrew Ross wrote: >Ah yes. I should have looked more closely at this. Was there a reason >you didn't do this for the plvect / plcont functions in the F95 >bindings? I'm not sure I would advocate changing this now as we already >have plvect / plcont implemented, although with different arguments to >their C counterparts. Perhaps you could think about this? > >Andrew > > Only laziness ;). The method can certainly be extended to the FORTRAN 77 binding, but I have not done that yet. It would make the API more complete. I will look at it in the coming days. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2007-12-28 11:13:33
|
Andrew Ross wrote: > > >>Ah yes. I should have looked more closely at this. Was there a reason >>you didn't do this for the plvect / plcont functions in the F95 >>bindings? I'm not sure I would advocate changing this now as we already >>have plvect / plcont implemented, although with different arguments to >>their C counterparts. Perhaps you could think about this? >> >>Andrew >> >> >> With respect to the matter of providing a transformation function to plcont() and plvect(): I have looked at the current API and have considered possible solutions to make the F77 and F95 versions more like the C counterparts. The problem is not passing a function name - that is easy and has been around in Fortran for many decades. The real problem is passing arbitrary data to the function, as Fortran (up to F2003, that is) has no equivalent for C's void pointers (void *data). I can see a number of solutions, none of them very appealing: - For F77 we would be stuck with a single argument, for instance an array holding all the required data. That is awkward, if you need to combine integers and reals. It can be done though. - For F95 the type system allows you to gather all information into a derived type (equivalent in C: a struct), but then the compiler will complain that the argument has to be of the right type. You could get around it via the transfer() function, but that requires quite some understanding on the user's side. Another way would be to keep the plcont() and plvect() routines (or specially named versions of them) out of the PLplot module. Some compilers might still complain though: you would be passing derived types to routines that essentially are expected to have a F77-compatible interface. Alternatives: - For F95 define a suitable derived type that can be expected to be useful for most applications. That way we would have an interface that makes the compiler happy. - For F77 and F95, let the function itself take care of the data that it needs. In F77 you could use a COMMON block, in F95 you could use module data. I hesitate to go ahead and implement either one of these solutions, though the two alternatives give the best and most robust solutions (though not the most general). Does anyone feel strongly about extending the Fortran API in this way or shall we leave it as it is as far as these functions are concerned? Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2007-12-28 18:31:15
|
On 2007-12-28 12:13+0100 Arjen Markus wrote: > Andrew Ross wrote: > >> >> >>> Ah yes. I should have looked more closely at this. Was there a reason >>> you didn't do this for the plvect / plcont functions in the F95 >>> bindings? I'm not sure I would advocate changing this now as we already >>> have plvect / plcont implemented, although with different arguments to >>> their C counterparts. Perhaps you could think about this? >>> >>> Andrew >>> >>> >>> > With respect to the matter of providing a transformation function to > plcont() and plvect(): > I have looked at the current API and have considered possible solutions > to make the > F77 and F95 versions more like the C counterparts. > > The problem is not passing a function name - that is easy and has been > around in Fortran > for many decades. The real problem is passing arbitrary data to the > function, as Fortran > (up to F2003, that is) has no equivalent for C's void pointers (void *data). > > I can see a number of solutions, none of them very appealing: > > - For F77 we would be stuck with a single argument, for instance an > array holding all the > required data. That is awkward, if you need to combine integers and > reals. It can be done > though. > - For F95 the type system allows you to gather all information into a > derived type (equivalent > in C: a struct), but then the compiler will complain that the argument > has to be of the right type. > You could get around it via the transfer() function, but that requires > quite some understanding > on the user's side. > Another way would be to keep the plcont() and plvect() routines (or > specially named versions > of them) out of the PLplot module. Some compilers might still complain > though: you would > be passing derived types to routines that essentially are expected to > have a F77-compatible > interface. > > Alternatives: > - For F95 define a suitable derived type that can be expected to be > useful for most applications. > That way we would have an interface that makes the compiler happy. > - For F77 and F95, let the function itself take care of the data that it > needs. In F77 you could > use a COMMON block, in F95 you could use module data. > > I hesitate to go ahead and implement either one of these solutions, > though the two alternatives > give the best and most robust solutions (though not the most general). > > Does anyone feel strongly about extending the Fortran API in this way or > shall we leave it > as it is as far as these functions are concerned? Hi Arjen: If you have not done so already, you might want to look at what our Fortran bindings do for plcont, plshade, and plshades. We have special fortran API in all those cases because of the problems (I assume) of passing arbitrary data for the call back function like is possible with C. Come to think of it, though, none of these solutions are very satisfying. I recently had a similar problem with FreeEOS where I was writing a generalized BFGS minimization routine to work properly for a huge variety of different functions to be minimized with a large variety of argument lists. The solution was to use reverse communication, a Fortran engineering technique invented to just solve this problem. With this technique the generalized routine completely avoids using a callback function. Instead it communicates with the outside world with a all-purpose integer or character-string switch which tells the calling routine please call me again with such-and-such requested data (function value, gradient value, or whatever depending on the switch) supplied for this independent variable (or variables). Then the calling routine calls any routine it likes with the supplied independent variables and feeds back the requested results to the generalized routine (say plcont) which then does something with those results (such as plotting them). Reverse communication is a common technique used for many Fortran numerical libraries (see results of a google search for the two terms fortran and "reverse communication"). It worked well for my BFGS minimization problem, and I think it may be the answer to our fortran troubles with plcont, plshade, plshades, and plvect. 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: Arjen M. <arj...@wl...> - 2007-12-29 09:21:21
|
> > Hi Arjen: > > If you have not done so already, you might want to look at what our > Fortran > bindings do for plcont, plshade, and plshades. We have special fortran > API > in all those cases because of the problems (I assume) of passing arbitrary > data for the call back function like is possible with C. > > Come to think of it, though, none of these solutions are very satisfying. > I > recently had a similar problem with FreeEOS where I was writing a > generalized BFGS minimization routine to work properly for a huge variety > of > different functions to be minimized with a large variety of argument > lists. > The solution was to use reverse communication, a Fortran engineering > technique invented to just solve this problem. With this technique the > generalized routine completely avoids using a callback function. Instead > it > communicates with the outside world with a all-purpose integer or > character-string switch which tells the calling routine please call me > again > with such-and-such requested data (function value, gradient value, or > whatever depending on the switch) supplied for this independent variable > (or > variables). Then the calling routine calls any routine it likes with the > supplied independent variables and feeds back the requested results to the > generalized routine (say plcont) which then does something with those > results (such as plotting them). > > Reverse communication is a common technique used for many Fortran > numerical > libraries (see results of a google search for the two terms > fortran and "reverse communication"). It worked well for my BFGS > minimization > problem, and I think it may be the answer to our fortran troubles with > plcont, plshade, plshades, and plvect. > Hi Alan, you are absolutely right! Why didn't I think of that? Sometimes you get stuck in a particular line of thinking, I suppose. I will think about such a solution. It seems the most flexible method, without having to resort to obscure language tricks (and therefore applicable to more languages) Regards, Arjen |