7/12/2016 Topic: How the Backcalculation Error is Calculated Fritz Jooste Administrator	The Rubicon Online Deflection Analysis tools use the following approach to calculate errors during backcalculation: Step 1: Calculate the absolute difference between the Measured and Calculated deflection (= A) Step 2: (a) If the difference is less than the Precision level X, then the error at that sensor is regarded as zero; (b) If the difference is more than the Precision level X, then reduce the difference by subtracting the precision, to get B = A - X; Step 3: Calculate the percentage error as: Error = [B/(Meas + 0.001)] * 100 % Note that: The precision level X is now set to 5 micron. In the older Rubicon Desktop procedure a slightly different algorithm was used with a 10 micron precision. Explanation: The reason for the precision correction is to ensure that small deflections, such as those often measured at the outer sensors, do not distort the apparent percentage error and inappropriately drive the backcalculation process. For example, if the measured outer sensor deflection is 4 micron, and the calculated outer sensor deflection is 8 micron, that would register as 100% error even though the absolute difference between measured and calculated deflections is less than 5 micron. By making a correction to take into account the precision of measurements and slight instabilities at the surface, a more reasonable error is calculated, thus ensuring that the backcalculation algorithm focuses on the "big picture", much like an experienced analyst would do in a manual backcalculation. Note that the 0.001 adjustment in the final step 3 above is done to ensure stability when measured deflections are zero or very close to zero. By adding 0.001 to the Measured deflection, a division by zero error is always avoided.
8/3/2016 Topic: How License Check-In and Check-Out Works Fritz Jooste Administrator	In the Rubicon Online Tools, licenses for different tools are assigned to a business (or "account"). A business can be an entire corporation or a branch of a corporation - this depends on how clients want license costs to be invoiced. If a client has 2 licenses for tool A, then a license is "checked out" when any user opens Tool A. If a second user then opens Tool A, the second license is checked out. Thus if another user tries to open Tool A while the first two users have the 2 licenses checked out, they will get an "Unlicensed" notification because both available licenses are checked out. IMPORTANT! A license is only "checked in" when a tool is closed and the user returns to the Online Tools page. If a user closes the browser without returning to the Online Tools page, then the license will remain checked out under that user's name until they log back in and open the Online Tools page. Thus if you see an "Unlicensed" notification when you do not expect to see one, check that none of your colleagues have a license checked out. If they do, ask them to log back in - this should automatically check back the license that was checked out under their name. We are working on a feature that will notify users if a license is checked out to other persons in their organisation - also showing the names of the users that have licenses checked out. This should make it quite easy for you to understand why you see an "Unlicensed" option when you expect a license to be available. edited by fenella@rubsol.co.za on 8/10/2016
6/21/2017 Topic: Updated Backcalculation Algorithm - June 2017 Fritz Jooste Administrator	During June 2017, some improvements were made to the automated backcalculation algorithm. These changes mean that you may find that the backcalculation algorithm now yields slightly different results compared to earlier backcalculation runs. The differences may not occur on all bowls, and the magnitude is likely to be quite small. The following improvements were made (applied only to the Online Tools version of the backcalculation tool): In the initial implementation, we stored imported deflections as integers (whole numbers). However, we found that even decimal deflection values could influence results. So we modified the storage procedure to include decimals in measured deflections. We found that the specified backcalculation error was not being properly applied in the backcalculation algorithm. Essentially, it was allowing the search process to terminate at 10% errors. This has now been fixed. The fact that some of your earlier stored analysis (that may be in a report by now) will now yield different results if you run it again is of course not ideal. But we have to keep on making improvements where we can, and in the interest of constant improvement, we decided to implement these improvements as soon as possible in the online tools. If for some reason you really need to reproduce the exact result set that you reported earlier, you can try the following: 1. Re-import your deflection data from your original Excel Template 2. Re-Run the backcalculation using the exact same layer properties and search ranges, BUT with a specified allowable error of 10%. Please feel free to get in touch with the engineering support team if you have any questions about this issue. edited by Fritz Jooste on 1/30/2020
1/21/2020 Topic: Backcalculation Algorithm and Seed Values Fritz Jooste Administrator	The Rubicon Toolbox backcalculation algorithm uses a search methodology which employs heuristics and elements of the Secant-numerical search method. The heuristics component ensures that the search progresses from the lower layers towards to top using a search strategy that approximates the approach an experienced user would adopt when doing manual backcalculation. The Secant-search method ensures a near-optimal convergence rate. Seed values are simply the mid-points of the search ranges for each layer. This means the search could be made more intelligent and faster when a user selects an appropriate and relatively narrow search range. It is always recommended that a manual backcalculation be performed on a few typical bowls in the set so that the analyst can determine the behaviour patterns and likely deterioration mechanism in the pavement. This will help the analyst pick appropriate search ranges which in turn will ensure the backcalculation results are realistic. For the sub-stratum layer, the search is automatically limited between a lower stiffness value of 20 MPa (deep/weak/wet substratum) and 1500 MPa (strong sandy or shallow substratum). The initial seed value for the sub-stratum layer is again the midpoint of these two limits, thus 760 MPa. Note that a distinction is made between the sub-stratum and the upper subgrade. The sub-stratum is assumed to be semi-infinite whereas the upper subgrade is typically assigned a thickness of around 500 mm to 1500 mm depending on the type of subgrade. The user should decide on the most appropriate upper subgrade thickness to use, and experience and site information should be used to guide this decision. If, for example, the subgrade is known to consist of deep clay then the thickness of the upper subgrade should be set to 1500 mm or deeper. If, however, there are signs of a shallow subgrade such as rock outcrops, or if the subgrade consists of coarse-grained, stress-stiffening materials, then a shallower depth should be assumed. This is discussed in more detail in the post titled Subgrade Characterization. Note that the sub-stratum layer does not have to be included in design forward calculations. This is because the stresses-and-strains in the pavement structure are not influenced by the deeper subgrade. The deflections, however, are influenced by deeper subgrade conditions and therefore in backcalculation the sub-stratum needs to be included to mimic deeper subgrade conditions. edited by Fritz Jooste on 1/30/2020 edited by on 11/20/2020 edited by on 11/20/2020
3/31/2020 Topic: Degree-Extent Strip for Visuals Fritz Jooste Administrator	The Degree-Extent strip is designed to plot visual data collected in a Degree and Extent format. Degree and Extent Data can also be plotted in a bar chart format. See this post for details The Degree-Extent will represent your data by colouring a representative length of each assessment area with the appropriate colour. In the example below, we show Degree = 1 (colour blue) and Extent = 1, mapped to 5% length for the area from 1000 m to 1100 m. Similarly, in the area from 1200 m to 1300 m, we used a Degree = 3 (colour yellow), and Extent 3 (mapped to 30% area). So the idea is that the colours plotted in an area give you a visual idea of the extent of the distress. Below is an example of how you need to define a Degree-Extent strip in your Stripmap Setup file. The figure below highlights the most important properties that need to be defined for a Degree-Extent strip. For all the other properties, please use the values shown in this example, even though these properties are not explicitly used by the Degree-Extent strip. Note that the value you supply for the "Decimals" property is used as the Random seed value to randomly position bars over the specified extent. If you do not like the random way the bars are placed, you can try using another value in the Decimals property field. Keeping this value fixed will ensure your plot looks the same every time, unless you change the value in the Decimals field. You will also note that for the example above, we are retrieving our data from the "Visuals" sheet (you can use any name you want). Also, we are retrieving our Degree ratings from the column "Croc_D" and we get the Extent (%) rating from the "Croc_Perc" column. The figure below shows how your data will typically be defined for this strip type. Note that we are using Excel's VLOOKUP function to convert Extent RATINGS (values typically 1 to 5) to Extent Percentages. For your strip, you need to point to the column that holds the Extent Percentage, and not to the Extent Rating. To specify the colour ratings for various Degree ratings, you can define and then use an Interpretation Range such as shown below: Finally, below is an example of a finalized stripmap that includes a Degree-Extent strip at the bottom. You can download the template that was used to create this strip by clicking on the attachments link at the bottom of this post. edited by Fritz Jooste on 3/31/2020 edited by Fritz Jooste on 3/31/2020 edited by on 9/15/2020 edited by on 11/20/2020 edited by on 11/20/2020 edited by on 10/24/2023
8/24/2020 Topic: Layered Elastic Theory Algorithm Accuracy Fritz Jooste Administrator	This post gives an example of the accuracy of the Rubicon Online Tools' Layered Elastic Theory (LET) algorithm. This algorithm is coded in the C# language specifically for Rubicon Toolbox online tools and can handle any number of layers, although generally Rubicon Toolbox online tools restrict you to between 6 and 8 layers depending on the tool you are using. In this post, we show how the Rubicon Toolbox Online Tools LET Algorithm compares with other well-established and proven algorithms. Specifically, we use the example on page 120 to 122 of Huang's book on Pavement Analysis and Design. Please note that the example provided here is from the First Edition of Huang's book. The pavement structure used in Huang's analysis is given in the figure below. Note that Huang only provides Imperial units and thus there is a degree of rounding error in the conversion of thicknesses and stiffness values and - more importantly - in the conversion of stresses and strains between these two unit systems. Huang's results are reported only in Imperial units with one or two decimal rounding. In Huang's example, a rather complex load configuration is assumed. The load configuration is given below, with evaluation positions numbered and indicated in red dots. For each of the four evaluation positions, stresses and strains are evaluated at the bottom of the asphalt layer (depth 151.9 mm) and at the top of the subgrade (457.02 mm). In Huang's book, stresses, strains and deflections are provided at each evaluation position for the Kenlayer and ELSYM5 algorithms. Huang shows that Kenlayer's results are generally within 2% of those of the older, more established ELSYM5 algorithm. In the table below, we compare the results obtained with Rubicon Toolbox's Stress-Strain calculator with those given by Huang for ELSYM5. Please note that results had to be converted from SI Units (which are used in Rubicon Toolbox), to Imperial Units. Some errors due to rounding can therefore be expected. We present the comparison of results in three tables: (a) Vertical Deflection; (b) Strains; and (c) Principal Stresses: The "% Difference" column values were calculated using the ELSYM5 results as base value. Positions where the % difference is above 2% are highlighted in red. A discussion of these results follows below the three tables. Table (a): Vertical Deflection Table (b): Strains Table (c): Principal Stresses Discussion: The three tables above shows a close agreement between the Rubicon Online Tools LET Algorithm and the results given by the ELSYM5 algorithm. In most cases, the differences are below 2%, similar to the comparison between Kenlayer and ELSYM5 reported by Huang. In the case of strain comparisons, two locations (positions 1 and 3, top of the subgrade) have horizontal tensile strains that differ by 7.4% and 8.6% respectively. The reason for this deviation is not known, but comparisons between the (also well established) WESLEA algorithm suggested less than 1% difference between the Rubicon Online Tools algorithm and the WESLEA algorithm. It is suspected that these differences represent edge cases where small differences between the inputs used by Huang for ELSYM5, and here with the Online Tools, have a significant impact on the results. We believe the weaker correspondence is due to these differences in setup/input assumptions, combined with conversion of printed values, rather than an algorithmic error. It should also be noted that tensile strains at the top of the subgrade are not commonly used in mechanistic analyses. In the case of Principal Stresses, most results are close to or below 2%. One value, at the top of the subgrade, position 2, has a difference of 5.7%. This higher difference is believed to be a result of the rounding issues related to conversion of results between unit systems. Again, when comparing the results of the Rubicon Online tools with WESLEA, differences are below 1%. edited by on 8/24/2020 edited by on 10/17/2023

---