I was able to get the x-axis drawn out in a logarithmic scale, get the plot drawn on the same scale, and do it in a somewhat modular fashion. It needs a few pixel-level tweaks still and to be replumbed to separate the relevant sections of code, but conceptually the hard problems are solved.
In this mode you can clearly see the different sections of the plot in different colors.
I started working through the graphs of the various thermodynamic functions vs. pressure and recognized that the standard format wasn’t showing all of the detail contained in the fits across the different ranges of input pressure. If the plotable width of the graph is about 350 pixels over a range of 1800 psi on a linear scale that would mean that every pixel represents a range of over 5 psi. As you can see from the function below the lower two ranges cover less than that and as a result would not even show up on a standard plot.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
function PFind_T(P) { var temp = 0.0; if (P <= 0.0) { graphCycle = graphCycleBottom0; } else if (P < 0.0019) { graphCycle = 1; temp = (-40 + (0.0019 - P)*(-7142.857)); } else if (P < 0.08866) { graphCycle = 2; P = Math.log(P); P = P + 6.26590139280974E+0000 + 2; temp = -6.89351170861096E+0001; temp += ( 1.30050423829122E+0001 * P); temp += ( 7.31258080071309E-0001 * P * P); } else if (P <= 0.8) { graphCycle = 3; temp = 3.33934342833700E+0001 * P; temp += ( 2.17077559430164E-0001 / P); temp += (-2.49565709833529E+0001 * Math.sqrt(P)); temp += ( 2.81308744499854E+0001 * Math.log(P)); temp += (-1.25784522492054E+0001 * P * P); temp += ( 3.34979532697040E+0000 * P * P * P); temp += 1.02298078764073E+0002; } else if (P <= 50) { graphCycle = 4; temp = -2.99124380544527E-0001 * P; temp += ( 2.68463065388278E+0000 / P); temp += ( 1.32892779311514E+0001 * Math.sqrt(P)); temp += ( 2.94664325500198E+0001 * Math.log(P)); temp += ( 1.51666454163202E-0004 * P * P); temp += ( 2.28440791389534E-0006 * P * P * P); temp += -1.56749381553382E+0001; temp += 1.01699999999953E+0002; } else if (P <= 180) { graphCycle = 5; temp = 3.74987064978268E+0000 * P; temp += ( 2.16828072878346E+0003 / P); temp += (-1.02468079912476E+0002 * Math.sqrt(P)); temp += ( 2.99347435622010E+0002 * Math.log(P)); temp += (-3.92313778545628E-0003 * P * P); temp += ( 3.50250493113408E-0006 * P * P * P); temp += -6.67984428873286E+0002; temp += 2.81029999999795E+0002; } else if (P <= 1800) { graphCycle = 6; temp = -7.86998246486519E-0002 * P; temp += (-4.87149019710720E+0002 / P); temp += ( 9.75184636544145E+0000 * Math.sqrt(P)); temp += ( 2.73146506017656E+0001 * Math.log(P)); temp += ( 1.16067971316358E-0005 * P * P); temp += (-1.69705925255891E-0009 * P * P * P); temp += -2.56172361345496E+0002; temp += 3.73129999999888E+0002; } else { graphCycle = graphCycleTop0; temp = 0; } return temp; } |
Expanding the plot to around 2000 pixels still doesn’t show all the details in a meaningful way. (The graph below is scrollable sideways.)
Generating plots over smaller and smaller ranges of pressure shows that each range of the function is smooth.
A way of getting these details to display is to do the plot on a logarithmic scale. I’ve done some of the work toward making that happen but that work will continue next week. I realize that I neglected to add this feature to the master list I created earlier this week, even though I was thinking about it. I’ve solved the basic parts of the problem but have to integrate the solution into the overall flow of code. As always, that may require breaking things apart into different functions. We’ll see how it goes.
Here are plots of the standard thermodynamic values for saturated water, all as a function of temperature. Tomorrow I’ll plot them all out as a function of pressure.
I extended the range of each function below 32 degrees Fahrenheit to address conditions that occurred in a model I build earlier in my career. For those lower temperatures the water is not saturated but exists either in a subcooled state in the liquid phase of the superheated state in the vapor phase. Many of these function exhibit a discontinuity at 32 degrees. I apparently used data from a different set of tables which I’ll try to identify going forward, particularly as I work through the process of recreating the curve fits I did and correcting those that seem obviously in error. I’ll be working through that process next week.
I also believe that I’ve figured out why the plotted lines are so thick and why they often include small bulges that make the plot look like it’s chattering up and down unexpectedly. The effect appears to be caused by drawing lines with the lineCap mode set to “square,” which adds nearly a full pixel to either end of each plotted line segment. Since the curves are drawn at one-pixel intervals along the x-axis any pixel changes along the y-axis should result in extra thick lines or lone pixels above or below the plotted line. Tomorrow I will try producing the graphs with the lineCap mode set to “butt.”
There are clearly a few segments that look awry on these graphs, and they are usually at the lower end of the temperature scale, above 32 and less than 100 degrees. Re-fitting the curves will require me to implement a few of the features on my to-do list for the graph project, as well as demonstrating how the curve function were created in the first place.
Finally, here is an example of one of the thermodynamic functions. It is composed of individual curve fits across a limited range or temperatures, and the value for a global variable called graphCycle is set to an index based on which of the fits are used. That index is used to select the color in which that section of the function’s output curve is to be drawn. If the input value is out of the range covered by the function the value for graphCycle is set to a different constant indicating that the input value is lower or higher than the active range. In those cases no line segments are added to the graph.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
function TFind_P(T) { var temp = 0.0; if (T < -40.0) { graphCycle = graphCycleBottom0; temp = 0.0; } else if (T < 32.018) { graphCycle = 1; T = T + 4.00000000000000E+0001 + 2; temp = -5.82750190795537E-0004; temp += ( 3.10138202245116E-0004 * T); temp += (-9.96845835382852E-0006 * T * T); temp += ( 2.93452465077397E-0007 * T * T * T); temp += 1.90000000000000E-0003; } else if (T <= 95) { graphCycle = 2; temp = 1.02291643993728E-0001 * T; temp += (-1.56461430882940E+0001 / T); temp += (-7.77500161911500E-0001 * Math.sqrt(T)); temp += (-5.68581901662451E-0001 * Math.log(T)); temp += (-5.57135053654371E-0004 * T * T); temp += ( 2.68643222990479E-0006 * T * T * T); // temp += 4.06678025391659E+0000 + 8.86600000000000E-0002;} temp += 4.15544025391659E+0000; } else if (T <= 281.03) { graphCycle = 3; temp = 3.92079417112400E+0001 * T; temp += ( 4.01213788918853E+0004 / T); temp += (-1.28706905409880E+0003 * Math.sqrt(T)); temp += ( 3.50936122348532E+0003 * Math.log(T)); temp += (-3.40581930733492E-0002 * T * T); temp += ( 3.01211718278793E-0005 * T * T * T); temp += -7.30111133292317E+0003; temp += 0.00000000000000E+0000; } else if (T <= 373.13) { graphCycle = 4; temp = -4.46073180369288E+0003 * T; temp += (-2.91401612241211E+0007 / T); temp += ( 2.35876174171448E+0005 * Math.sqrt(T)); temp += (-1.02466834830570E+0006 * Math.log(T)); temp += ( 1.41416476892482E+0000 * T * T); temp += (-3.85708716196032E-0004 * T * T * T); temp += 3.07749988717651E+0006; temp += 5.00000000000000E+0001; } else if (T <= 621.21) { graphCycle = 5; temp = 6.08822615030408E+0003 * T; temp += ( 6.96757841217041E+0007 / T); temp += (-3.68132442183495E+0005 * Math.sqrt(T)); temp += ( 1.83794467631912E+0006 * Math.log(T)); temp += (-1.51896496594964E+0000 * T * T); temp += ( 3.61841945230257E-0004 * T * T * T); temp += -6.03886787577057E+0006; temp += 1.80000000000000E+0002; } else { graphCycle = graphCycleTop0; temp = 0.0; } return temp; } |
A friend asked me what my recent series of posts is trying to communicate, so here is a brief rundown.
When not writing here about my previous experience or reactions to things I’ve seen or read, the goal is to work on a series of projects that accomplish the following ends:
When I started this process I was able to generate a list of about 130 subjects I could write on, and so far I’ve probably addressed half of those. That exercise was useful for getting me into a consistent process that I hoped would make the ideas flow and force me into contact with new things on a regular basis. I have found a rhythm that works for me for the time being, and doubtless these communications will improve as time goes on.
This process reminds me of a very brief Reader’s Digest story I encountered when I was young, that for some reason has always stuck with me. Like the little girl in the story, finding new things to describe now has ceased to be a problem.
Today I think I’m just going to list all of the TO DO items for the project while taking a moment to see if anything in the basic structure of the existing code might be reworked. Rather than continuously banging through these items, the list of which is rather extensive, I am likely to use the project for the reasons that inspired me to start it in the first place, and then work items off the list as the need appears.
For the next day or two I’ll be testing out all of the thermodynamic functions of saturated water (liquid and vapor) I created many years ago. Then I’ll work on describing the creation of the functions from the steam tables using the curve fit program I wrote (also a long time ago). Those activities will definitely require extension of the graph object, and I will ultimately be able to finish creating the online steam table page I started a few weeks ago.
Today I continued to dive into smaller and smaller details of how the tick value labels get placed when they are rotated. When it seemed like I was done I set the graph up to continually modify the angle of the labels on each axis, along with the font size of the graph label, all at different speeds. What I saw was that the anchor positioning of the text for the tick value labels flicked around more than I thought it should. One thing that confused me was that I was trying to judge single-pixel alignment of text elements that varied in shape on either end, depending on the beginning or ending numeral.
I therefore decided to temporarily pad the label text with a capital letter “M” on each end. That told me that my initial design intent was correct and that I probably didn’t need most of the adjustment factors I was adding in.
I also added a small reference rectangle at the origin point for each text element (in green, upper left pixel is actual anchor, colors to not always reset correctly if drawing context is rotated). That turned out to be really interesting because I could clearly see that a certain amount of the location “chatter” I was seeing was due to the displacements accumulated as the HTML canvas object draws each character in the string supplied to the fillText function. These errors aren’t large, but when you’re trying to nudge things down to the last pixel they do become noticeable, especially over the course of drawing a longer series of characters. I therefore decided that things are good enough as they are for the time being. If things aren’t continuously moving you’d be unlikely to notice most of the issues.
The continuous cycling of the graph’s elements shows how the spacing is determined from each outside edge of the canvas in towards the drawing area. This isn’t the kind of thing you’d normally do with a graphing widget, but it seemed to illustrate things well for this purpose.
Today the X-axis tick value labels can be rotated, though I may need to rethink what the angles actually mean. Also, a bit of spacing has been added to let the presentation breathe and some gentler colors were chosen for the gridlines in the graph area.
Today I reorganized things so that the location of the graph axes are calculated automatically. The first image just shows the typical arrangement of items in their normal sizes.
The graph and axis labels are larger in this image.
In this image the graph and axis labels are back to their original size but the axis value labels are larger. In this case in particular you can see that the top value on the y-axis requires more clearance than the top graph label so there is extra space below the top graph label. If the y-axis text were tilted the other way there could be extra clearance at the bottom of the graph if the lowest value text was sufficiently long.
Next up is to reflect all functionality from the y-axis to the x-axis and make a few other tweaks. Then I can start adding different plotting functions and the ability to display axes on either side of the graph and also add additional vertical axes.
The screenshots below show the graph object with different amounts of text rotation on the y-axis labels and the buffer spaces (shown as green bars) that indicate how the spacing of elements is to be determined from the outside edge in towards the graph area itself. All that remains to do now is actually implement the part where the location of the axes is calculated automatically (with errors if the size of the entire canvas is too small) from each edge and to reflect the code for the y-axis to apply also to the x-axis.
I had been working on all of this for a little while when I realized I was making the selection of the rotation point for the axis text way too complicated. That was followed by some very relaxing pruning and simplification. I think I got the solution fairly well generalized, but the slight offsets around text objects mean that getting things tuned just the way you want is a bit of a black art, though perhaps there is a slightly different way to approach the problem that I haven’t thought of yet.
I’ve also added the ability to draw major and minor grid lines on the graphing area and separated that functionality from the drawing of the tick marks, which can now be drawn inside the axis, outside the axis, inside and outside the axis, or not at all. The colors and fonts (at least the font sizes) can be set independently for all elements.
One interesting thing I noticed was that when rotating the y-axis label 90 degrees and then drawing the buffer bars on either side of it, is that there is actually a one-pixel shift in the text. Either the first half or second half of the text was higher (or farther left or right) by one pixel halfway through. I tried different angles of rotation but couldn’t find one that would not produce this artifact (at least in Firefox). I tried more and more subtle tweaks to the numbers and ended up with a rotation angle of Math.PI * 0.499999453 (give or take a 9) that seemed to be the critical point. I searched for a while (top 30 or so Google results) to see if anyone else has noticed this but haven’t found any mentions. I understand how such an artifact can creep into the canvas functionality but the perfectionist in me can’t help but be moderately annoyed. If anyone else has seen this, especially if they know what to do about it, please leave a comment here.
Today I implemented the ability to rotate the tick labels on the graph axes. There are a few little tweaks left to implement and describe, but the figures below show how the various offsets work to position each label relative to the end of its associated tick mark. I added a small square to each label, the upper left pixel of which indicates the base location given to the textFill command to place the right-justified text. Finally, I added some text labels to show the relevant parameters as they are calculated and used. I’ll describe some of the more subtle details next time.
Notice how in the bottom example, with -45 degrees of rotation, the top of the y-axis label text reaches higher than the graph label text. When the code is written to locate the axes automatically, the calculation will take things like that into account.
