Native %pl

I have down loaded the new release and have been trying out the new native %pl. Very impressed - good job Paul and Co, this eliminates the need to write code to draw plots to %gr regions. It works on some data sets where the old %pl failed - which caused me much grief in the past.

Question. The new %pl clearly draws to a graphics region. Is it possible to divert the output of %pl from the screen to a graphics region in memory?

I ask this, as now that we have a nice plot (possibly more than one via a number of sequential calls to %pl) on the screen, the next step is to add a call back to copy the image(s) to a jpeg (or similar) file. I know how to do this for a plot drawn directly in a %gr region but I'm struggling to see how to do this for a %pl plot.

Thanks

Ken

In theory you should be able to use CREATE_GRAPHICS_REGION@ and COPY_GRAPHICS_REGION@ but I have not tried this.

Paul,

That's what I thought, but how do we get the handle of the graphics region created by %pl? That's what has stumped me on this.

Thanks

Ken

Ken

You can use a grave accent with %pl as in %gr.

Yes!, you can export the graph, for instance, to a jpg file:

filejpg='plot.jpg' ipc= export_image@(filejpg)

If you are using only a single %pl for plotting all graphs (thanks to the new implementation of Paul), you don't need to use the grave accent: the graph region used by %pl is selected by default.

I have tested this....

Agustin

Excellent Paul, thank you. I can see the way forward now.

This works fine in terms of creating the jpeg files, but I did note that Checkmate x64 does not like this code.

    program test
      use clrwin 
      implicit none
      integer plot_to_file_cb ; external plot_to_file_cb
      integer n,i
      integer(kind=3) plot1, plot2
      common plot1, plot2
      parameter(n=10)
      real*8 x(n),y(n),z(n)
      plot1 = 1
      plot2 = 2
      do i=1,n
        x(i)=0.1d0*(i-1)
        y(i)= -x(i)*x(i)
        z(i)= -y(i)
      enddo
      i=winio@('%ca[plots]%pv&')
      i=winio@('%`bg[white]&')
      call winop@('%pl[title=graph]')
      call winop@('%pl[width=2]')
      call winop@('%pl[y_max=0.9]')
      call winop@('%pl[x_array]')
      call winop@('%pl[link=curves]')
      call winop@('%pl[symbol=9]')
      call winop@('%pl[colour=red]')
      call winop@('%pl[pen_style=2]')
      call winop@('%pl[framed]')
      i = winio@('%`pl&',400,250,n,x,y,plot1)
      i = winio@('%2nl&')
      i = winio@('%ff%cn%ws&','A space between the graphics regions')
      i = winio@('%ff&')
      call winop@('%pl[title=graph]')
      call winop@('%pl[width=2]')
      call winop@('%pl[y_max=0.9]')
      call winop@('%pl[x_array]')
      call winop@('%pl[link=curves]')
      call winop@('%pl[symbol=9]')
      call winop@('%pl[colour=red]')
      call winop@('%pl[pen_style=2]')
      call winop@('%pl[framed]')
      i=winio@('%`pl&',400,250,n,x,z,plot2)
      
      i=winio@('%sf%ff%nl%cn%^tt[plot]&',plot_to_file_cb)
      i= winio@('%tt[ok]')
      end

      integer function plot_to_file_cb()
      use clrwin
      implicit none
      integer i
      integer(kind=3) plot1, plot2
      common plot1, plot2
        i = select_graphics_object@(plot1)
        write(6,*) i
        i = export_image@('plot1.jpg')
        write(6,*) i
        i = select_graphics_object@(plot2)
        write(6,*) i
        i = export_image@('plot2.jpg')
        write(6,*) i
        plot_to_file_cb = 1
      end function plot_to_file_cb

I have noted the failure when using %pl with '/64 /check'. For the time being it will be necessary to add '/inhibit_check 16' in this context.

Paul,

Please continue working with %pl LOG_LINEAR and LINEAR_LOG are urgent next!

Dan

It is a priority but right now we are working on the speed of PRINT etc. which is an issue that you have raised; that is, apart from the immediate everyday stuff like reading forum posts that turn out to be about the meaning of 'palindrome' :roll:

Kenneth

The problem when compiling with /64 /CHECK has been fixed. Please try the following download but keep a backup of your existing DLLs.

https://www.dropbox.com/s/4tlx2ynkeq9o8cj/newDLLs2.zip?dl=0

What does it matter what the speed of PRINT is, since Windows spools output to a printer and even buffers it?

It would have to be some primitive hardware for PRINT to the screen not to scroll past at unreadable speed unless one makes strenuous efforts to slow it down.

Eddie

Thanks for that update Paul. Works fine now 😄

Ken

Another problem with the new native %pl I have come across it that if you plot a step function and select [link=lines] the plot overshoots in both directions at the time when the derivative of the function is large. This is illustrated by the following:-

program step
implicit none
include<windows.ins>
integer i
real(kind=2), dimension(1:1000) :: time_plot, volt_plot
real(kind=2) delta_t, time

delta_t = 0.001d0
time = 0.d0

do i = 1, 1000
 time_plot(i) = time
 if (time .lt. 0.5d0) then
   volt_plot(i) = 0.d0
 else
   volt_plot(i) = 1.d0
 end if
 time = time+delta_t
end do
i = winio@('%ww&')
CALL winop@('%pl[native]')
call winop@('%pl[x_array]')
call winop@('%pl[n_graphs=1]')
call winop@('%pl[link=lines]')
CALL winop@('%pl[title='Voltage step']')
call winop@('%pl[x_axis='Time [s]']')
call winop@('%pl[y_axis='V [pu]']')
call winop@('%pl[y_min=0.d0]')
call winop@('%pl[y_max=1.1d0]')
call winop@('%pl[dy=0.2d0]')
call winop@('%pl[width=2]')
i = winio@('%pl&',400,400, 1000, time_plot, volt_plot)

CALL winop@('%pl[native]')
call winop@('%pl[x_array]')
call winop@('%pl[n_graphs=1]')
call winop@('%pl[link=none]')
call winop@('%pl[symbol=10]')
call winop@('%pl[symbol_size=1]')
CALL winop@('%pl[title='Voltage step']')
call winop@('%pl[x_axis='Time [s]']')
call winop@('%pl[y_axis='V [pu]']')
call winop@('%pl[y_min=0.d0]')
call winop@('%pl[y_max=1.1d0]')
call winop@('%pl[dy=0.2d0]')
call winop@('%pl[width=2]')
i = winio@('%pl',400,400, 1000, time_plot, volt_plot)
        
end program step

This code produces the output below with the problem areas marked up, the second plot just shows the data points [link=none].

The old %pl does not have this problem with the same data set.

Regards

Ken

The bigger the step change, the larger the overshoot. This is a screenshot of the problem which originally had me look into this in more detail.

I have mentioned this too. Suspect this is because new ℅pl always use smoothing of data. The linear interpolation option has to be introduced which is simpler (connects two points with the line) and has no such effect. There exist other types of smoothing, splines, B-splines etc

I agreed Dan it does appear to be the line option is trying to smooth out the data. I've implemented a quick fix by passing the signal I'm plotting through a 1/(1+sT) transfer function (lag block) - basically a filter to round off the sharp changes.

Yes I think that it is probably due to smoothing. If it is then I can add another 'link' option that uses 'poly-lines' instead. But that would remove the smoothing from the remainder of the graph.

Paul,

The help file says:- [link=lines] Join data points with straight lines (the default) which implies no smoothing (to me anyway). So I'm sure we need a new poly-line option - that's just joining the data points with straight lines.

The new %pl is really good - this is just a minor issue.

Ken

This turned out to be a simple ClearWin+ programming error. The two 'link' options 'lines' and 'curves' were implemented the wrong way around.

You can check this out by using [link=curves] to see if it gives what you would like to see for 'lines' but I will uploaded amended DLLs shortly. With these you would revert to your original coding.

Ken, Paul, By the way, which option makes the squared plotting region with two X and two Y axis like in the last plots (I still did not read the manuals)?