Review of The Long-Term Pavement Performance (LTPP) Backcalculation Results

Chapter 5. LTPP Backcalculation Database Screening Methodology

LTPP DATA SOURCE USED IN THIS STUDY

The complete computed parameter tables of backcalculated pavement layer data plus the supporting tables (Release 16.0—July 2003 Upload) were used and screened in this study.

LTPP Data Tables Used

The following tables from the LTPP database were used in either computing the forwardcalculated moduli or screening the backcalculation values:

• EXPERIMENT_SECTION—Stores current experiment information that is driven by maintenance and rehabilitation (M and R) activities.

• TST_L05B—Table containing section representative layer thickness and descriptions for all constructions.

• MON_DEFL_FLX_BAKCAL_BASIN—Deflection basin parameters used for the pavement backcalculation computations using MODCOMP v4.2 computer program.

• MON_DEFL_FLX_BAKCAL_LAYER—Layer structure and material inputs for the pavement backcalculation computations using MODCOMP v4.2 computer program.

• MON_DEFL_FLX_BAKCAL_POINT—Interpreted results of backcalculated elastic layer moduli from FWD measurements for flexible and rigid pavement structures using MODCOMP v4.2 computer program.

• MON_DEFL_FLX_BAKCAL_SECT—Summary of results presented in MON_DEFL_FLX_BAKCAL_POINT by section and test date. Results in MON_DEFL_FLX_BAKCAL_POINT with greater than 2 percent ERROR_RMSE were excluded from summary statistics.

• MON_DEFL_FLX_NMODEL_POINT—Interpreted results of nonlinear backcalculated from FWD measurements for flexible and rigid pavement structures using MODCOMP v4.2 computer program.

• MON_DEFL_FLX_NMODEL_SECT—Summary of results presented in MON_DEFL_FLX_NMODEL_POINT by section and test date. Results in MON_DEFL_FLX_NMODEL_POINT with greater than 2 percent ERROR_RMSE were excluded from summary statistics.

• MON_DEFL_FWDCHECK_CMNTS—Comments generated during use of FWDCHECK for basic analysis of the deflection data (not part of the backcalculation process, but listed here as a possible information source even though it is only partially populated).

• MON_DEFL_LOC_INFO—Test point specific condition data for Dynatest FWD.

• MON_DEFL_MASTER—FWD data collection general site measurement information.

• MON_DEFL_RGD_BAKCAL_BASIN—Deflection basin parameters used in backcalculation of rigid pavement structures.

• MON_DEFL_RGD_BAKCAL_LAYER—Pavement structure input parameters used in the backcalculation of elastic layer moduli and pavement structural material properties.

• MON_DEFL_RGD_BAKCAL_POINT—Interpreted elastic layer moduli and pavement structural material properties from backcalculation and direct computations of FWD measurements of rigid pavement structures using version 2.2 of ERESBACK.

• MON_DEFL_RGD_BAKCAL_SECT—Test section statistics for interpreted elastic layer moduli and pavement structural material properties from backcalculation and direct computations of FWD measurements for rigid pavement structures for each measurement pass.

LTPP Backcalculation Tables Screened

All the LTPP tables containing backcalculated moduli were screened using the forwardcalculated values. Table 11 gives a list of these tables, as well as the number of records contained and screened in each computed parameter table in the LTPP database.

The first four lines of Table 11 are the MODCOMP data records, while the last two lines are the two-layer rigid pavement data using the dense liquid and elastic solid methodology. Almost all of the unscreened data from Table 11 resulted from the use of a rigid or stiff layer at some depth in the flexible section data tables (for both the flexible and some of the rigid section data) created by MODCOMP or an assumed layer modulus for any other structural layer when MODCOMP was used. These moduli were assumed, or fixed, and were therefore not screened.

In addition, with data migration and other issues, the records in tables *_BAKCAL_LAYER, *_BAKCAL_BASIN, and *_BAKCAL_POINT are no longer directly connectable with one another. Since data from these tables (plus TST_L05B and others) were used in the screening process, a very limited number (for example, <1 percent of the total number of records in the rigid backcalculated data tables from the last two lines of Table 11) of records that could not be connected were left unscreened.

Since the completion of the backcalculation project (in 1999), the LTPP program underwent a major change in the way the CONSTRUCTION_NO field is assigned. As a result, the CONSTRUCTION_NO values in the backcalculation tables do not directly correlate with the CONSTRUCTION_NO values in other key LTPP tables such as the EXPERIMENT_SECTION and TST_L05B tables. For this study, the forwardcalculation method used the deflection basins in the MON_DEFL_FLX_BAKCAL_BASIN table and the MON_DEFL_RGD_BAKCAL_BASIN table (which use the former CONSTRUCTION_NO assignments) while using the pavement structure data (material type and layer thicknesses) from the TST_L05B table (which uses the current CONSTRUCTION_NO assignments). To ensure the proper connection of the corresponding records, the following fields were compared to ensure the proper assignment of the CONSTRUCTION_NO values: EXPERIMENT_SECTION.CN_ASSIGN_DATE, MON_DEFL_FLX_BAKCAL_LAYER.CN_REF_DATE, and MON_DEFL_RGD_BAKCAL _LAYER.CN_REF_DATE. This process was successful in almost all cases, as indicated above.

KEY STEPS FOR SCREENING THE LTPP BACKCALCULATION DATA

The following steps were taken to screen backcalculated moduli:

1. Obtain the FWD deflection basin data.
2. Determine the forwardcalculation layer structures.
3. Conduct forwardcalculation for each basin with layer structure identified.
4. Compute section level summary statistics of forwardcalculation parameters.
5. Correspond (connect) the forwardcalculated moduli with the backcalculated moduli.
6. Screen the backcalculated moduli using the corresponding forwardcalculated moduli.

Each step is discussed in detail below.

Step 1. Obtain the FWD Deflection Basins for Forwardcalculation

The objective of this study was to screen the backcalculated moduli in the LTPP database and use the same deflection basins that were used to derive these backcalculated moduli. As a result, the deflection basins from the tables MON_DEFL_FLX_BAKCAL_BASIN and MON_DEFL_RGD _BAKCAL_BASIN were extracted and subsequently used in the forwardcalculation computations.

Step 2. Determine the Pavement Layer Structures for Forwardcalculation

As presented in chapter 4, elastic moduli for up to three layers are forwardcalculated for each deflection basin. Then the pavement systems were divided or combined into a two- or three-layer structure, as follows:

1. Surface (bound) layer (AC or PCC).
2. Base layer (unbound or granular).
3. Subgrade; depth to apparent stiff layer calculated from the deflection basin.

For rigid pavements, the uppermost base layer below the PCC slab was considered the base layer.

For flexible pavements, the layer system is more complex, and more than three layers were used in backcalculation for many flexible pavement sections. The researchers applied engineering judgment to assign each of the backcalculation layers to correspond to a forwardcalculation layer, according to the scheme shown in Table 12.

Step 3. Conduct Forwardcalculation

Forwardcalculation is carried out using the method discussed in chapter 3 for each of the two or three forwardcalculation layers (i.e., the bound surface course, base if present, and subgrade).

A small percentage of the FWD load-deflection data has been associated with nonstandard sensor positions. These nonstandard positions were adjusted to their actual positions before applying the forwardcalculation procedures.

Table 13 gives an outline of the deflection data where nonstandard sensor positions were considered, provided there were any backcalculated data in the database associated with these data (seldom the case).

Table 13. FWD- and time-specific sensor positioning anomalies in the LTPP database.

Region & FWD S/N	Dates Affected (inclusive)	Actual Sensor Positions (inches)	Approx. # of Test Dates
Reg. 1–s/n129	3 Nov ’95?14 Apr ’96	0, 8, 12, 18, 24, 36 & 48	21
Reg. 1–s/n129	15 Apr ’97?21 May ’97	0, 8, 12, 18, 24, 36 & 48	12
Reg. 2–s/n061*	4 Aug ’89?10 Aug ’89	0, 8, 12, 24, 30.5, 48 & 72	4
Reg. 2–s/n130	25 Aug ’94?7 Sep ’94	0, 8, 12, 18, 36, 48 & 60	16
Reg. 3–s/n075	17 Jan ’90?22 Jan ’90	0, 8, 12, 18, 30, 42 & 66	4
Reg. 3–s/n132	29 Jul ’96?25 Oct ’96	0, 8, 12, 18, 24, 36 & 48	29
Reg. 4–s/n061*	<26 Feb ’89?8 Sep ’89	0, 8, 12, 24, 30.5, 48 & 72	97
Reg. 4–s/n061	17 Jul ’95?31 Oct ’95	0, 8, 12, 18, 24, 36 & 48	65
Reg. 4–s/n131	<24 May ’ 94?30 Apr ’96	0, 8, 12, 18, 24, 36 & 48	191
Reg.4–s/n13110	16 Dec ’97?20 Jan ’98	0, 8, 18, 24, 36, 48 & 60	8

* Same FWD and overlapping dates—LTPP field tests conducted in two different LTPP Regions.

Step 4. Compute Section Level Summary Statistics of Forwardcalculated Parameters

For the section level data, to identify and remove outliers for a given section (and test date), the researchers used the so-called interquartile range (IQR) as outlined below.

Pavement engineers typically use two standard deviations as criteria for identifying outliers. The shortcoming of this approach is that neither the population mean nor the population standard deviation is available when evaluating the data for outliers. Instead, the sample mean and sample standard deviation are generally used, without consideration of the actual distribution. This technique introduces a bias in identifying the outliers when using the two standard deviation approach because outliers are (incorrectly) included in the computation of the sample mean and the sample standard deviation. In addition, the section standard deviation on an arithmetic basis is often large enough to compute negative values on the low end of the section level modulus range. This calculation results in elimination of few (if any) of the unreasonably low values and only eliminates the unreasonably high values. The nonnormal and asymmetric distribution of the modulus data usually causes this problem. In fact, the distribution of moduli generally is closer to a log-normal distribution than an arithmetic normal distribution.

To overcome these difficulties, the IQR method has been used to identify and remove outliers in the computed point-by-point moduli for each section (and date of test).⁽¹¹⁾ The following provides specifics of this method:

Figure 22. Equation. Interquartile range.

Outliers are defined as values that are outside the range: (Q₁ - 1.5 * IQR, Q₃ + 1.5 * IQR).

Data points that were outside of the above range were identified as outliers and not used to calculate the section means from forwardcalculation.

Step 5. Correspond the Forwardcalculated Moduli with the Backcalculated Moduli

After all forwardcalculation is completed, the forwardcalculated moduli were paired with the backcalculated moduli using their section IDs, according to table 12.

Step 6. Screen the Backcalculated Moduli Using the Corresponding Forwardcalculated Moduli

The LTPP database of backcalculated moduli was screened. This screening took place using the following sequential steps:

1. The modulus values in the backcalculation tables that were assumed or held constant were not screened—Since these values are presumably a good educated guess at the actual in situ stiffness, they were not screened and accordingly were left as is in the database with an appropriate flag.
2. Reasonableness screening—Various pavement materials are commonly associated with typical or reasonable moduli, depending on the material type and other factors. Assuming the backcalculated value was not fixed, a wide range of feasible modulus values was assigned to the various material types, and any value outside of these rather liberal ranges could then be called into question, whether the method of determining the modulus is back- or forwardcalculation. Table 14 lists these values. During screening of the database, also including the newly created forwardcalculated values, these limits were applied before applying the remaining criteria. In other words, if a given modulus calculation was outside of the broad ranges indicated in Table 14, then it was either flagged in the case of the existing tables or noted in the case of forwardcalculated values, and then not used in further screening routines.
3. Correspondence screening using forwardcalculated values – Provided the data did not become flagged during Steps 1 or 2 of the screening process, each backcalculated value was then compared to the corresponding forwardcalculated value. If the backcalculated modulus was within a factor of 1.5 of the forwardcalculated value, then it was assumed to be “acceptable” and not recommended for flagging (except through the use of a “0,” see Table 15) in the database. If it was outside of this reasonable range (1.5 times the forwardcalculated value or the forwardcalculated value divided by 1.5), then the flags shown in Table 15 were used to indicate that the existing value in the database was “suspect.” These flagging codes were used for both the “point” data tables and the “section” data tables.

Incorporation of the Screening Results into the LTPP Database

All applicable flags associated with the backcalculated moduli in the LTPP computed parameter database will be submitted to FHWA, including all records where the backcalculated values were assumed (fixed) or not reasonable. All remaining data will be submitted with an appropriate correspondence flag (i.e., 0, 1, 2, or 3—see Table 15) to be incorporated into the existing backcalculation data tables, as outlined above.

In addition, tables of all forwardcalculated moduli, both at the point and section levels, will be given to FHWA as candidates for incorporation into the LTPP database as computed parameters. These data will also include the “reasonableness flag” where applicable.