forums.silverfrost.com

Kenneth_Smith · Posted: Mon Mar 20, 2017 9:47 pm Post subject:

Dan,

Thanks for your sample code. It is always interesting to see other peoples approaches. I realise that I have much to learn having spent a few hours reading the Clearwin+ help pages after working my way through your code.

Generally my programs (some written 25 or more years ago) do a lot of number crunching and then spit out some results. My motivation for using Clearwin and FTN95 stems from the fact that younger engineers will not prepare a text file for input to a program, or accept a long file with many columns of data as an output. Since I started using Clearwin I have actually got some of our younger graduate engineers interested in writing Fortran rather than try to manipulate massive data sets in excel - which I think is a good thing. It's much easier to check some code than some of the complex spreadsheets I've seen created in my organisation. A good example is manipulation of harmonic impedance data for contingency analysis in power systems - this took an engineer 2 weeks in excel - 3000 lines of Fortran does the same job in 20 minutes - including generating all the required plots.

Thanks again

Ken

DanRRight · Posted: Mon Mar 20, 2017 11:56 pm Post subject:

Ken, We all learn from each other here. I have question to you too - what settings in native %pl did you use in the last plots to get x and y axis linewidths more then 1 pixel wide? It clearly is not "etched"

Kenneth_Smith · Posted: Tue Mar 21, 2017 12:20 am Post subject:

Dan, John,

The plots in the previous post did not use the new options in the latest dll from Paul (no 5)

Using these options with the new dll:-

PaulLaidler · Posted: Tue Mar 21, 2017 8:14 am Post subject:

John

Logarithmic scales are implemented in the latest DLLs.

Kenneth

Can you check the effect of using [link=lines] against [link=curves]. They were implemented the wrong way round in some contexts. You need "lines" to avoid overshoot with step like functions.

Kenneth_Smith · Posted: Tue Mar 21, 2017 9:57 am Post subject:

Apologies Paul, [link=lines] and [link=curves] is fine as this example shows:-

DanRRight · Posted: Tue Mar 21, 2017 10:22 am Post subject:

Ken, John,
Then obviously the Ken's graphs look here better then they actually are. Because either posting service, or the browser, or the lose graphics JPG format was used, which scale the lines from their original 1 pixel size, or better say distort, doing that by antialiasing way. To see that i made PrintScreen and magnified plots above and my own plots. I used lossless PNG format. Compare axis Ken plotted at the left with my plot at the right below. In my plot axis width is not broadened by fake antialiasing, it is strictly 1 pixel.

By the way noticed the way Silverfrost realized "etching" ? Left and bottom axis have approximately 1.5 pixel linewidth. If it is done by antialiasing (Clearwin is specifically good at that, better then most professional software, see the curves when smoother) then the linewidth could be not integer number 1,2,3 ... which is very crude but floating point number like 1.5, 2.3, 3.4 ... Would be very good if Silverfrost implemented axis linewidth parameter and have done that the way like the etching was done.

PaulLaidler · Posted: Tue Mar 21, 2017 10:23 am Post subject:

You should use 1.2, 1.2e0 or 1.2E0. In C, sscanf is called using %f.

Kenneth_Smith · Posted: Tue Mar 21, 2017 10:13 pm Post subject:

Thanks Paul.

The code below replicates the problem I've observed in my much larger program. Originally I thought there was some dependency on the order in which the %pl options are assembled into the %pl string. In both cases below the %pl options are the same, only the order of the options is different. In both cases [link=lines].

PaulLaidler · Posted: Wed Mar 22, 2017 7:48 am Post subject:

The syntax %pl[framed][link=lines] is incorrect it should be %pl[framed,link=lines].

ClearWin+ should have faulted this.

Kenneth_Smith · Posted: Wed Mar 22, 2017 9:58 am Post subject:

doh

why is the blindingly obvious sometimes so difficult to see? Thanks for your perseverance Paul.

Kenneth_Smith · Posted: Wed Mar 22, 2017 10:59 pm Post subject:

It's taken three weeks, but I got there. Very Happy

Thanks for all your help folks.

Regards

Ken

PaulLaidler · Posted: Thu Mar 23, 2017 7:51 am Post subject:

John

The logarithmic values don't need to be converted beforehand.

Given this and the extra options in the readme, the only documentation that is needed can be found in the latest ftn95.chm at ClearWin+->SIMPLEPLOT->Native graph plotting.

Kenneth_Smith · Posted: Thu Mar 23, 2017 10:24 pm Post subject:

Paul,

Another one for you to take a look at when you have time. In an x-y plot, if all the y data is negative, pl may choose some strange range values for the y-axis and not display the x axis. The programmer needs to set y_min and y_max carefully, and y_max must be zero to ensure the x axis is displayed.

DanRRight · Posted: Fri Mar 24, 2017 9:44 pm Post subject:

1) And here are probably partially the same LOG_LOG, LOG_LINEAR problems like in the post above. The code below either does not display anything or complains that "Y contain zero or negative numbers" and automatically switches to LINEAR scale. The Y values as one can see do not contain zero or negative numbers

Displayed Y axis numbers in all scales including LINEAR have problem too.

2) In log scale it also does not like call winop@("%pl[Y_min=1e-8]") or
call winop@("%pl[Y_max=1e-5]") and making numbers like 1d-5, 1d-8
immediately gets new %pl on strike Smile

3) As a suggestion if there exist CALL Winop@("%pl[Y_min=1e-8]") and zero/negative numbers in the data indeed are present the native %pl should not switch to linear scale but should keep going with LOG scale and just ignore and do not plot anything below Y_min

PaulLaidler · Posted: Sat Mar 25, 2017 8:16 am Post subject:

I guess that users will always be able to find data that the native %pl can't handle. It is after all a quick fix for the missing 64 bit SIMPLEPLOT which is a non-trivial product.

Naturally it can't handle log y for negative y and to switch to a linear scale seems reasonable to me. Negative values of log y are more difficult to handle because the automatic y min can get very large but we can look into that.

The good news is that users can always draw their own by using %gr or %pl with a callback to draw extra things on the graph. There is a subroutine that gives you the origin for the axes and the x and y pixel scaling.