Local Wind Box Grids: 08/24/10

1. Retry a Rejected Idea:

Just mentioned in the previous page, above was the statement:

"Couldn't we just use the simpler local downwind coordinates (x,y) and rotate them to the local grid portion of the absolute grid points xg,yg? Yes, but the math and rounding off errors, we may not have a unique grid point xg,yg for each x,y. Also the possibility exists that some xg,yg's may be missed while others may be counted twice. This makes for a ragged receptor grid while we are trying to smooth the process." We will examine this possibility again. Maybe we could fill in these grid holes with more grids points and average the multiple counts on a single grid point.

A. Double Hits or Misses?:

If we rotate a downwind grid box system .1 mi apart between cross wind and downwind, what will be the corresponding new grid points still being in the same absolute grid system? Let some new pics explain a thousand words. Two examples are given in Rotate Grid # 4 and Rotate Grid # 2 . The yellow box still has the .1 mi square that would capture or miss the unrotated grids. The situation is worse with the 2nd pic.

The gruesome details are listed in Grid 0 & O . Summary was 9 missing, 14 duplicates and 47 unique out of 70 possible. The problem is that we will have over 40000 grid points for even a Cap with no dwr downwind value. What happens when we rotate a full 45 degrees? This is reviewed and explained in Fewer Grids . This should show the max number of multiple grid plots and missing grid points.

B. Graphics tell the Story?:

The final radfo plot is composed of 1000's similar plots below being superimposed, scattered or rotated throughout the grid. We now isolated the one wind, one case Cap 3.25 dwr cylinder to test the rotation which becomes one new hairy topic. To see an actual plot by the program RADFORUG.c then to Google Earth, view Oily Doily . Here the discolored spots are the multi plots on a grid point while the pattern of a doily indicates holes or missed grid points. Now we switch the multi count colors off and see without Google Earth Holes # 4 and Holes # 1 . Now another rotation yields Holes # 2 . This shows we have more complicated problems on the horizon.

Now let's take out the disgr color values and work with just multi colors by multi plots of a constant value at grid points as seen in Holes # 11 . This could be called a band aid? Now to see only the holes, we just use one color regardless of values so we have Holes # 5 . Thinking that rounding off would help the problem, it just shifts the problem and makes it worst in Holes # 6 , Holes # 7 and Holes # 8 . Since we have a program to make a doily, then here is one for a web page background in White Doily .

If we add more grid points in the local wind box before it is rotated, then after rotation, it should fill up some of the holes. You see these results in before Holes 1.00 and after where we multiplied the # of grids by 1.25 in x & y each = 1.56 times as many grid points. This reduces the # of holes in Holes 1.25 , but if we multiply by 1.5, this is 2.25 times as many grids that fills up the holes in Holes 1.50 .

(2) Problem Solved?:

Now with the holes filled, all we have to do is account for the multi-values at each grid. So the easiest way to keep track is on another grid file, parallel to the 40 gb radfo.grd by the same file positions ix,iy, all the multiple values. Well we store each disgr value as one of 255 character so even 6 times this would be 1530 and we are allowed to go to 62,000 with 2 bytes, therefore, we add 10,000 for each count without the 2 count - value conflicting.

To make this simpler, we just consider the downwind x and up direction wind y as + for each major axis, that is each quadrant. Then all we have to do is rotate the grid +,-90 or 180 degrees. All that is required is a track of the sign switch of ix,iy and the ix -> iy & iy -> ix axis switch with the proper sign as the axes are rotated around ixo,iyo. See AxeQuad.dia .

Now all seemed well so we now put the disgr colors values back in and try rotation pics again until we get near at 340 degrees. Note all fell apart as seen by SM 340 . This was so bad, we reduce the grid multiplier back to unity to see how bad it really could be and we have SM 340 A. Then we increased to grid multiplier gm to 2 and we have an improvement to SM 340 E. Improvement but not satisfactory. We have so many multiple values at grid points that we are reaching that 6 limit. The same happened as we corrected at SM 314 to SM 314 PH .

We thought the computer accuracy of rotating near 100 miles around a point to be accurate within .1 mi was exceeded. However, even with double precision, we got the same results. So now rotating just 10 degrees off from the axis produced SM 260 and SM 260 A with more gm's. It appears that it's not the amount of rotation but the alignment. This is analogous as if we took 2 flat screens and put a thin nail through both, then rotated one on top of the other, many patterns would develop. With both aligned, they appear as one but the rotation produces various effects as the square holes between the two screens align differently with each discrete rotation.

The effect of these interference patterns is called the Moire Patterns. The Wikipedia definition and display is deep but an excellent example of this, as just explained by the 2 rotating screens above, is their animated rotation demonstration given 3/4 of the way down their page on the right side.

(3) The Court's Ruling:

This was an utter waste of time but maybe some code could be salvaged for some later use for something else? The quote at the top of this page still stands. There isn't a one to one correspondence between the local down wind grid with the absolute grid locations after rotation. Multiplying the # of grids multiplies problems with multiple hits on grids and still may leave some holes for gm = 2. The correct procedure is to rotate the absolute grid into the local down wind grid for disgr values.

However, we have to know all these grid points to rotate. Thus, we rotate the local down wind box into the absolute unrotated grid and calculate xg,yg from the formulas of the box boundaries then each xg,yg to be rerotated back for the disgr values stored in the local down wind grid. We have done all this before but can we also speed up the cpu time by a new procedure? We give this effort below.

2. New Rotated Boundary Box Formulas:

Previously, we found the equations of the box's top, bottom and side lines. Also, we extended the corners to identify left & right corner pairs, then cut off that extension to find the Lower Left corner 0. Then we calculated each yg and xg. This time, we will use the side slopes from it's corners to calculate the boundaries of the xg's for each yg. We predetermine the bottom corner 'bot' depending on which quadrant the rotated box falls into.

The best diagram and explanation for this now is in Wind Box Rotate.dia . The emphasis here is to keep track of the rotated original 0 -> 3 corners by assigning them to their appropriate bot,top,lc,rc variable names. The 4 corners become either the indexed top, bottom, left or right assigned i in xc[i],yc[i]. This is determined by the rotation into the quadrant. Since the corners are numbered in clockwise rotation, with the quadrant numbers also rotated, if we sequence the quads, there is a math modular relationship that links quads vs. the 4 corner as seen in the bottom of the diagram. Here we predetermined this and link all this with 5 lines of simple code.

B. Only One Slope Calculated:

Rather than 4 equations of lines and calculating the y-intercept of each, we just need one - that is, use the longest length, top or bottom, for greater accuracy dydx=dyl/dxl and since the side slopes are parallel, their slopes are both the negative reciprocal -1/dydx. We see dxl=xc[rc]-xc[bot] and dyl=yc[rc]-yc[bot]. We run the line slopes between corners and calculate the left & right xg limits by the distance above the corners as seen by the 4 equations depending upon the height of the left yc[lc] or right yc[rc].

C. xg,yg's on Call:

Now yg is simply yg=yc[bot]+iyc*.1. For each yg, we find xg1 left & xg2 right along each appropriate slope and increment for all xg's in between. Somewhat of a blowup and more explanation is seen in Near Grid.dia .

D. Rerotate xg,yg's to Local Downwind Grid:

Next is to rerotate the xg,yg's back to the local downwind grid to become x,y after we use other variables to calculate xg,yg's corresponding absolute grid positions ix,iy. The x,y is converted to file position coordinates xi,yi for use in the appropriate dwrs&c files explained earlier for the disgr values. The best illustration & explanation for tracing all the variables in this rotate, find grids and re-rotate to extract disgr values is given in Integrated Grids.dia .

E. More Graphics & Results:

The plot's above were done with this new method. In order to have the orientation right, we worked to just duplicate the rectangular box as seen in Rect 260 . This was correct and we continued to rotate for all quads. Then we applied the real 16 color 100*disgr values for this one particle size cylinder at Cap 3.25 dwr. Viewing, Radfo 250 , Radfo 290 and Radfo 120 and even along the axis correction of + .4 degrees as seen in Radfo 270 and Radfo 180 . These were all run from the main RADFORUG.c program and screen captured by PanGrid.c .

(1) A Sneaky Flaw:

Just by chance, we noticed Hang Thread at 340 degrees. What does this mean? With all the rotation and rounding off for the bottom corner, when rerotated back, with a few cases, we could be out of the disgr file range. In this case, it was along the rectangular box. If the file position 'filpd' is outside the file range, it reads a max character 255. This converts to a max disgr=1, the max overlap. This would be an erroneous peak where this white thread occurs. At least it's consistent and actually shows that this method works. A one line code solved the problem as if(filpd >= filsz) continue - since disgr = 0 anyway. This produced the thread free Radfo 340 .

F. CPU Results:

After sitting 2 months on the hard drive, the data for the last run was still there. The CPU from this old run was 76 minutes. Picking up with the new features, the new run was 43 minutes. So, the ratio of new to old was 56.6% which made the effort all worth it as we now have a more accurate, smoother and faster display.