Assay Nomenclature

The definition of an “assay” is, for the purposes of this package, broken into:

• assay_source: the vendor/origination of the data
  
• assay: the procedure to generate the component data
• assay_component: the raw data readout(s)
  
• assay_component_endpoint: the normalized component data

Assay source, assay, assay component, and assay endpoint are registered via tcpl scripting into a collection of tables. These assay element tables broadly describe who conducted the assay, what platform was used, what was being measured (raw readout), and how the measurement was interpreted (normalized component data). A hierarchical structure of the assay elements is as follows: assay source > assay > assay component > assay component endpoint.

As one moves down the hierarchy, each additional level has a ‘one-to-many’ relationship with the previous level. For example, an assay component can have multiple assay endpoints, but an assay endpoint can derive only from a single assay component.

Minimum Required Fields

Throughout the tcpl R package, the levels of assay hierarchy are defined and referenced by their auto-incremented primary keys in the tcpl database: \(asid\) (assay source ID), \(aid\) (assay ID), \(acid\) (assay component ID), and \(aeid\) (assay endpoint ID). These abbreviations mirror the abbreviations for the identifiers (ids) with “nm” in place of “id” in the abbreviations, e.g. assay_component_name is abbreviated \(acnm\).

All processing occurs by assay component or assay endpoint, depending on the processing type (single-concentration or multiple-concentration) and level. No data is stored at the assay or assay source level. The assay and assay_source tables store annotations to help in the processing and down-stream understanding of the data. Additional details for registering each assay element and updating annotations are provided below. In addition to each assay element’s id, the minimal registration fields in order to ‘pipeline’ are:

• \(assay\_source\_name\) (\(asnm\))
• \(assay\_name\) (\(anm\))
• \(assay\_footprint\)
• \(assay\_component\_name\) (\(acnm\))
• \(assay\_component\_endpoint\_name\) (\(aenm\))
• \(normalized\_data\_type\)

Assay Source

Assay source refers to the vendor or origination of the data. To register an assay source, an unused \(asid\) must be selected to prevent overwriting of existing data. When adding a new assay source, this should be an abbreviation, as subsequent levels will build on this assay source name.

tcplLoadAsid()
tcplRegister(what = "asid", flds = list(asid = 1, asnm = "Tox21"))

The tcplRegister() function takes the abbreviation for \(assay\_source\_name\), but the function will also take the un-abbreviated form. The same is true of the tcplLoadA-**() functions, which load the information for the assay annotations stored in the database.

Assay

Assay refers to the procedure, conducted by some vendor, to generate the component data. To register an assay, an \(asid\) must be provided to map the assay to the correct assay source. One source may have many assays. To ensure consistency of the naming convention, first check how other registered assays within the assay source were conducted and named. The assay names follow an abbreviated and flexible naming convention of Source_Assay. Notable assay design features to describe the assay include:

• Technology (i.e., detection technology),
• Format (e.g., organism, tissue, cell short name, or cell free component source name),
• Target (i.e., intended target, intended target family, gene), or
• Objective aspects (e.g., timepoint or assay footprint).

The most distinguishing features will be selected to create a succinct assay name. Variation depends on the assay itself as well as other assays provided by the vendor. If multiple features are needed to describe an assay, order will be based on relative importance in describing the assay and the assay’s relation to other assays provided by the vendor to limit confusion. Source_Technology_Format_Target is a commonly used naming order. However, if one target is screened on different assay platforms by the vendor, Source_Target_Technology is a more appropriate naming convention. This is the case for the Tox21 assays. Additional features may be relevant, including agonist or antagonist mode, or “Follow-up” if the assay is a secondary specificity assay. Conversely, some assays utilize a cell-based format to screen a functional profile of targets. These assays follow a naming convention, Source_Format, where specific target information is defined at the component and endpoint level. Bioseek and Attagene are sources that provide cell-based assays. Considering the diversity of the data sources and HTS assays in ToxCast, a flexible naming approach is best used in conjunction with subject matter expert discretion.

tcplLoadAid(what = "asid", val = 1)
tcplRegister(what = "aid", flds = list(asid = 1, anm = "TOX21_ERa_BLA_Agonist", assay_footprint = "1536 well"))

When registering an assay (\(aid\)), the user must give an \(asid\) to map the assay to the correct assay source. Registering an assay, in addition to an assay_name (\(anm\)) and \(asid\), requires \(assay\_footprint\). The \(assay\_footprint\) field is used in the assay plate visualization functions (discussed later) to define the appropriate plate size. The \(assay\_footprint\) field can take most string values, but only the numeric value will be extracted, e.g. the text string “hello 384” would indicate to draw a 384-well microtiter plate. Values containing multiple numeric values in \(assay\_footprint\) may cause errors in plotting plate diagrams.

Assay Component

Assay component, or “component” for short, describes the raw data readouts. Like the previous level, one assay may have many components. To register an assay component and create an \(acid\), an \(aid\) must be provided to map the component to the correct assay. The assay component name will build on its respective assay name, to describe the specific feature being measured in each component. If there is only one component, the component name can be the same as the assay name. If there are multiple components measured in an assay, understanding the differences, and how one component may relate to another within an assay, are important naming considerations to prevent confusion. Assay component names will usually follow the naming convention of Source_Assay_Component, where “Component” is a brief description of what is being measured.

tcplLoadAcid(what = "asid", val = 1, add.fld = c("aid", "anm"))
tcplRegister(what = "acid", flds = list(aid = 1, acnm = "TOX21_ERa_BLA_Agonist_ratio"))

The final piece of assay information needed is the assay component source name (abbreviated \(acsn\)), stored in the assay_component_map table. The assay component source name is intended to simplify level 0 pre-processing by defining unique character strings (concatenating information if necessary) from the source files that identify the specific assay components. An assay component can have multiple \(acsn\) values, but an \(acsn\) must be unique to one assay component. Assay components can have multiple \(acsn\) values to minimize the amount of data manipulation required (and therefore potential errors) during the Level 0 Pre-processing if assay source files change or are inconsistent. The unique character strings (\(acsn\)) get mapped to \(acid\).

tcplRegister(what = "acsn", flds = list(acid = 1, acsn = "TCPL-mc-Demo"))

Assay Component Endpoint

Assay component endpoint, or “endpoint” for short, represents the normalized component data. To register an endpoint and create an \(aeid\), an \(acid\) must be provided to map the endpoint to the correct component. In past tcpl versions, each component could have up to two endpoints therefore endpoint names would express directionality (\(\_up\)/\(\_down\)). tcpl v3.0+ allows bidirectional fitting to capture both the gain and loss of signal, therefore the endpoint name will usually be the same as the component name.

tcplLoadAeid(fld = "asid", val = 1, add.fld = c("aid", "anm", "acid", "acnm"))
tcplRegister(what = "aeid", flds = list(acid = 1, aenm = "TOX21_ERa_BLA_Agonist_ratio", normalized_data_type = "percent_activity", export_ready = 1, burst_assay = 0))

Registering an assay endpoint also requires the \(normalized\_data\_type\) field. The normalized_data_type is used when plotting and currently, the package supports the following values: percent_activity, log2_fold_induction, log10_fold_induction, and fold_induction. Any other values will be treated as “percent_activity.”

Other required fields to register an assay endpoint do not have to be explicitly defined and will default to 0 if not provided. These fields represent Boolean values (1 or 0, 1 being TRUE). The \(export\_ready\) field indicates (1) the data is done and ready for export or (0) still in progress. The \(burst\_assay\) field is specific to multiple-concentration processing and indicates (1) the assay endpoint is included in the burst distribution calculation or (0) not.

Naming Revision

There are circumstances where assay, assay component, and assay endpoint names change. The \(aid\), \(acid\), and \(aeid\) are considered more stable in the database, and these auto-incremented keys should not change. To revise naming for assay elements, the correct ID must be specified in the tcplUpdate() statement to prevent overwriting data.

tcplUpdate(what = "acid", flds = list(aid = 1, acnm = "TOX21_ERa_BLA_Agonist_ratio"))

Reasons for name changes could include:

• Feedback from subject matter experts or assay data generators;
• Clarifications on cell line and cell line drift;
• Addition of new assay data that makes the old naming convention insufficient, such as antagonist assays run with different concentrations of an agonist; or
• Laboratory or Center reorganizations.

Thus, users should be advised that while assay naming is used to infer information about the biology of the assay, assay naming will change over time to reflect progress in building ToxCast as a data resource.

Chemicals

The example below details how sample and chemical information can be loaded. Similar to the order in registering assay information, the user must first register chemicals, then register the samples that map to the corresponding chemical.

The following table of chemical and sample information will be referred to as “chdat”:

Registering chemicals requires a chemical’s CAS registry number (\(casn\)) and name (\(chnm\)). In the above example, only the unique chemicals were loaded. The casn and chnm fields have unique constraints; trying to register multiple chemicals with the same name or CAS registry number is not possible and will result in an error.

# Obtain chemicals already registered in the database.
cmap <- tcplLoadChem()
# Find chemicals in 'chdat' that are not registered yet.
chdat.register <- chdat[!(chdat$code %in% cmap$code)] 
# Register the chemicals not yet in the database.
tcplRegister(what = "chid", flds = chdat.register[,unique(.SD), .SDcols = c("casn", "chnm", "dsstox_substance_id", "code", "chid")])

Samples

Chemical and sample information must be registered separately as there may be multiple samples of the same chemical. With the chemicals registered, the samples can be registered by mapping the sample ID (\(spid\)) to the chemical ID. Note, the user needs to load the chemical information to get the chemical IDs then merge the new chemical IDs with the sample IDs from the original file by chemical name or CASRN.

tcplRegister(what = "spid",
             flds = merge(chdat[ , list(spid, casn)],
                          chdat.register[ , list(casn, chid)], by = "casn")[ , list(spid, chid)])

Chemical Lists

Optionally, the user can subdivide the chemical IDs based on presence in different chemical lists using tcplLoadChemList(). These chemical lists are curated by the US EPA in the Distributed Structure-Searchable Toxicity (DSSTox) database. Chemicals can belong to more than one chemical list, and will be listed as separate entries when loading chemical list information.

tcplLoadChemList(field = "chid", val = 1:2)

Required Fields

The Required_NULL_allowed column in the above table indicates whether the field can be NULL in the pre-processed data when writing Level 0. In past versions of tcpl, there were some exceptions where concentrations could be NULL. All \(conc\) values must be numeric for processing. For blank and neutral control wells, NULL concentrations will automatically be set to zero if not provided. If other concentrations are left NULL, user will get a warning and be unable to write Level 0. Additionally, if the raw value is NULL, well quality (wllq) must be 0.

The well type (wllt) field is used to differentiate wells in numerous applications, including normalization and definition of the assay noise level. Package users are encouraged to utilize additional well types (for example, well types “x”, “y”, “z”) or suggest new methods to better accommodate their data.

Well Types

Writing New Data

Before writing and processing any data to the database, the user must register the assay and chemical information, as described above. tcpl includes three functions for adding new data:

• tcplRegister(): To register a new assay element or chemical
• tcplUpdate(): To change or add additional information for existing assay or chemical ids
• tcplWriteLvl0(): To load formatted source Level 0 data

The final step in level 0 pre-processing is to load the data into the database. The tcplWriteLvl0() function loads data into the database by checking each required field for expected input, such as correct class or registered sample IDs and concentration values for test wells. Assay component source name, if provided, will map to the appropriate \(acid\). The type argument is used throughout the package to distinguish the screening paradigm (SC or MC) and therefore processing required. See Required Fields section for format of the Level 0 mcdat dataframe.

# Write/load the Level 0 into the database. 
tcplWriteLvl0(dat = mcdat, type = "mc")

To confirm data has been written, the tcplLoadData() function is used to load data from the database into user’s R session. Furthermore, the tcplPrepOtpt() function can be used in conjunction with tcplLoadData() to prepare the data in a readable format with additional chemical and assay annotation information. See Data Retrieval sections for further details.

# Load the level 0 data from the database to R
tcplLoadData(lvl = 0, fld = "acid", val = 1, type = "mc")
tcplPrepOtpt(tcplLoadData(lvl = 0, fld = "acid", val = 1, type = "mc"))

In the loaded Level 0 data, \(acsn\) is replaced with correct \(acid\) and the \(m0id\) field is added. These “m#” fields in MC data are primary keys for each level of data and can link the various levels of data. All keys are auto-generated and will change anytime data are reprocessed. Note, the primary keys only change for the levels affected, e.g. if the user reprocesses level 1, the level 0 keys will remain the same.

Overview

All processing in the tcpl package occurs at the assay component or assay endpoint level. There is no capability in either SC or MC processing to combine data from multiple assay components or assay endpoints. Any combining of data must occur before or after processing. For example, a ratio of two raw values could be processed if the user calculated the ratio during the custom pre-processing and uploaded values as a single “component”.

Once the Level 0 data are loaded, data processing occurs via the tcplRun() function for both SC and MC screening. tcplRun() can either take a single ID (\(acid\) or \(aeid\), depending on the processing type and level) or an \(asid\). If given an \(asid\), the tcplRun() function will attempt to process all corresponding components/endpoints. When processing by \(acid\) or \(aeid\), the user must supply correct ID for each level.

The processing is sequential, and every level of processing requires successful processing at the antecedent level. Any processing changes will trigger a “delete cascade”, removing any subsequent data affected by the processing change to ensure complete data fidelity. For example, processing level 3 data will first require data from levels 4 through 6 to be deleted for the corresponding IDs. Changing method assignments will also trigger a delete cascade for any corresponding data.

For tcplRun(), the user must supply a starting level (\(slvl\)) and ending level (\(elvl\)). There are four phases of processing, as reflected by messages printed in console: (1) data for the given IDs are loaded, (2) the data are processed, (3) data for the same ID in subsequent levels are deleted, and (4) the processed data is written to the database. The outfile parameter can give the user the option of printing this output text to a file. If an ID fails while processing multiple levels, the function will not attempt to process the failed ID in subsequent levels. When finished processing, a list indicating the processing success of each ID is returned. For each level processed, the list will contain two elements: (1) “l#” a named Boolean vector where TRUE indicates successful processing, and (2) “l#_failed” containing the names of any IDs that failed processing, where “#” is the processing level.

Processing of multiple assay components or endpoints can be executed simultaneously. This is done with the internal utilization of the mclapply function from the parallel R package. Parallel processing is done by id. Depending on the system environment and memory constraints, the user may wish to use more or less processing power. For processing on a Windows operating system, the default is \(mc.cores = 1\), unless otherwise specified. For processing on a Unix-based operating system, the default is \(mc.cores = NULL\) i.e. to utilize all cores except for one, which is necessary for ‘overhead’ processes. The user can specify more or less processing power by setting the mc.cores parameter to the desired level. Note, this specification should meet the following criteria \(1 \space \leq \space \mathit{mc.cores} \space \leq \space \mathit{detectCores()}-1\).

Level IDs

In this table, the Input ID column indicates the ID used for each processing step where Method ID indicates the ID used for assigning methods for data processing, when necessary. SC1 requires an \(acid\) input, but the methods are assigned by \(aeid\). The same is true for mc3 processing. SC1 and mc3 are the normalization steps and convert \(acid\) to \(aeid\). Only mc2 has methods assigned by \(acid\).

The processing requirements vary by screening paradigm and level, which later sections cover in detail. However, in general, specific method assignments will be required to accommodate different experimental designs or data processing approaches.

Methods

To promote reproducibility, all method assignments are saved in the database and utilize methods described in the available list of methods for each processing level. In general, methods data are stored in the “_methods” and “_id” tables for each corresponding level. For example, the sc1 table is accompanied by the sc1_methods table which stores the available list of methods for SC1, and the sc1_aeid table which stores the method assignments and execution order.

There are three functions to easily modify and load method assignments:

• tcplMthdAssign(): To assign methods to specified id(s)
• tcplMthdClear(): To clear method assignments to specified id(s)
• tcplMthdLoad(): To query the database and return the method assignments for specified id(s)
  
• tcplMthdList(): To query the database and return available methods at specified level(s)
  

The following code blocks provides examples of the method-related functions:

## Methods Assignment ##
# For illustrative purposes, assign level 2 mc methods to ACIDs 97, 98, and 99.
# First check for available methods.
mthds <- tcplMthdList(lvl = 2, type = "mc")
mthds[1:2]
# Assign some methods to ACID 97, 98, and 99.
tcplMthdAssign(lvl = 2, 
               id = 97:99, 
               mthd_id = c(3, 4, 2), 
               ordr = 1:3, 
               type = "mc")
# Check the assigned methods for ACID 97, 98, and 99 in the database.
tcplMthdLoad(lvl = 2, id = 97:99, type = "mc")

# Methods can be cleared one at a time for the given ID(s)
tcplMthdClear(lvl = 2, id = 99, mthd_id = 2, type = "mc")
# Check the assigned methods for the single ID updated, namely ACID 99.
tcplMthdLoad(lvl = 2, id = 99, type = "mc")

# Clear assigned methods for the given ID(s)
tcplMthdClear(lvl = 2, id = 97:98, type = "mc")
# Check the assigned methods for the all updated ID(s), namely ACID 97 and 98.
tcplMthdLoad(lvl = 2, id = 97:98, type = "mc")

Later sections of this vignette provide level-specific method assignment examples and more details on the methods themselves. Most examples will reflect commonly-used methods assigned, but one should consider the data at hand and all methods available for the level prior to assigning.

Data Normalization

Data normalization occurs in both SC and MC processing paradigms at levels 1 and 3, respectively. While the two paradigms use different methods, the normalization approach is the same for both. Data normalization does not have to occur within the package as pre-normalized data can be loaded into the database at Level 0. However, data must be zero-centered. Thus, the data must either be zero-centered in Level 0 Pre-processing or the user must pick a methodology from the associated level 1 and 3 methods to zero-center the data before model fitting occurs.

Fold-change and a percent of control are typical approaches to normalization. Given data must be zero-centered, fold-change data in general is log-transformed. Log-scale transformations for fold-change data is typically base 2 (\(log_2\)), but other bases may be more appropriate in some circumstances.

Normalizing to a percent of control requires three normalization methods: 1. One to define the baseline value (\(bval\)), 2. One to define the control value (\(pval\)), and 3. One to calculate percent of control (resp.pc).

Normalizing to fold-change also requires the following normalization methods: 1. One to define the baseline value (\(bval\)), and 2. One to calculate the fold-change (resp.fc), or using log-transformed values (resp.logfc).

(\(cval\)) is the corrected response value for a test well defined in mc2. Methods defining a baseline value (\(bval\)) have the “bval” prefix, methods defining the positive control value (\(pval\)) have the “pval” prefix. \(Pval\) may be set as 0 if no positive control wells are provided and measuring decreases in signal. Finally, methods that calculate the final response value (\(resp\)) have the “resp” prefix. For example, resp.log2 does a log-transformation of the response value using a base value of 2. The formulae for calculating the percent of control and fold-change response are listed in equations 1 and 2, respectively. Note that the fold-change calculation divides by the baseline value and thus must have some non-zero values associated with the baseline to successfully calculate fold-change.

\[ resp.pc = \frac{cval - bval}{pval - bval}*100 \]

\[ resp.fc = \frac{cval}{bval} \]

\[ resp.logfc = cval - bval \]

Order matters when assigning normalization methods. The \(bval\), and \(pval\) if normalizing as a percent of control, need to be calculated prior to calculating the response value. Examples of normalization schemes are presented below:

If the data does not require any normalization, the none method will be assigned. The none method simply copies the input data to the response field. Without assigning none, the response field will not get generated and processing will fail.

With tcpl v2, responses were only fit in the positive analysis direction. Therefore, a signal in the negative direction needed to be “flipped” to the positive direction during normalization. Multiple endpoints stemming from one component were created to enable multiple normalization approaches when the assay measured gain and loss of signal. Negative direction data was inverted by multiplying the final response values by \(-1\) via the resp.multneg1 methods. For tcpl v3.0 onward, the tcplfit2 package is utilized which allows for bidirectional fitting, meaning the resp.multneg1 method is now only required in special cases to support data interpretation.

In addition to the required normalization methods, the user can apply additional methods to transform the normalized values. For example, resp.blineshift.50.spid corrects for baseline deviations by \(spid\). A complete list of available methods, by processing type and level, can be accessed with tcplMthdList. More information is also available in package documentation, ??tcpl::Methods.

SC Data Processing

The goal of single-concentration processing is to identify potentially active compounds from a broad screen at a single concentration. SC processing consists of 2 levels:

> Level 1

Level 1 processing converts the assay component to assay endpoint(s), defines the normalized response value (\(resp\)), and optionally, derives the baseline value (\(bval\)) and positive control value (\(pval\)). The purpose of level 1 is to normalize the raw values to either the percentage of a control or fold-change from baseline.

- Methods Assignment

The first step in beginning the processing is to identify which assay endpoints stem from the assay component(s) being processed. With the corresponding endpoints identified, the appropriate methods can be assigned.

# Load the 'aeid' values for acid 2
tcplLoadAeid(fld = "acid", val = 2)

# Assign the Level 1 methods to aeid 1 and 2
tcplMthdAssign(lvl = 1,  # processing level
               id = 1:2, # assay endpoint ID's to assign methods
               mthd_id = c(1, 11, 13), # method(s) to be assigned
               ordr = 1:3, # order the method(s) should be applied
               type = "sc") # the data/processing type

Above, methods 1, 11, and 13 were assigned for both endpoints. The method assignments instruct the processing to: (1) calculate \(bval\) for each assay plate ID by taking the median of all data where the well type equals “n”; (2) calculate a fold-change with respect to the \(bval\) (i.e. \(\frac{resp}{bval}\)); (3) log-transform the fold-change values with base 2. For a complete list of normalization methods see tcplMthdList(lvl = 1, type = "sc") or ?SC1_Methods.

If a user needs to add a method to the end of a normalization sequence, as shown above, then the user can use a second method assignment statement. For example, if AEID 2 should indicate a change of directionality to be more biologically interpretable, all responses can be multiplied by \(-1\). Reminder, the order of methods assignment matters, particularly in the normalization step.

# Assign an additional method to invert data for AEID 2 only
tcplMthdAssign(lvl = 1, # processing level
               id = 2, # assay endpoint ID's to assign methods
               mthd_id = 16, # method(s) to be assigned
               ordr = 4, # order the method(s) should be applied
               type = "sc") # the data/processing type

With the normalization methods defined, the data are ready for SC1 processing. Before normalization occurs within tcplRun(), all wells with poor well quality (\(wllq = 0\)) are removed.

> Level 2

Level 2 processing defines the baseline median absolute deviation (\(BMAD\)), collapses any replicates by sample ID (\(spid\)), and determines the activity.

- Methods Assignment

Before the data are collapsed by \(spid\), the \(BMAD\) is calculated as the median absolute deviation of all treatment wells (\(wllt = t\), the default \(BMAD\) option for SC) or neutral control wells (\(wllt = n\)). The calculation defines \(BMAD\) for the entire endpoint. If additional data is added, the \(BMAD\) for the associated endpoints will be recalculated. Note, this \(BMAD\) equation is different from MC screening.

\[ BMAD_{sc} = 1.4826*median(\big | y_{i} - \tilde{y} \big |)\]

Where \(y_i\) is the \(i^{th}\) observation of all wells within a well type in the assay component and \(\tilde{y}\) is the median across all \(y_i\)’s. The constant value, \(1.4826\), is the default adjustment value used in the underlying R function to ensure \(BMAD\) is a consistent estimator of the standard deviation (\(\sigma\)) assuming the sample size (\(N\)) of the observations is large and they are normally distributed (i.e. Gaussian), see mad() in R and unbiased mad for further details.

To collapse the data by spid, the median response of replicates at each concentration index is calculated. SC data screening involves testing at 1-3 concentrations, which is insufficient for fitting. Data are then further collapsed by taking the maximum of those median values (\(max\_med\)). Once collapsed, such that each endpoint-sample has one value, the activity is determined. For an active hit call (\(hitc\)), the sample’s \(max\_med\) must be greater than a specified efficacy cutoff (\(coff\)).

In the below code, methods are assigned such that the cutoff value is \(log_2(1.2)\). Thus, if the maximum median value (\(max\_med\)) is greater than or equal to the efficacy cutoff (\(coff = log_2(1.2)\)), then the sample ID is considered active and the hit call (\(hitc\)) is set to 1. The \(coff\) is defined as the maximum of all values given by the assigned level 2 methods. Failing to assign a level 2 method will result in every sample being called active. For a complete list of level 2 methods, see tcplMthdList(lvl = 2, type = "sc") or ?SC2_Methods. With the methods assigned and the cutoff set, the data are ready for SC2 processing.

# Assign a cutoff value of log2(1.2)
tcplMthdAssign(lvl = 2, # processing level
               id = 1,  # assay endpoint ID's to assign methods
               mthd_id = 3, # method(s) to be assigned 
               type = "sc") # the data/processing type

# Run Level 2 processing for acid 1
tcplRun(id = 1, slvl = 2, elvl = 2, type = "sc")

- Overwrite Bidirectionality

Sometimes it is necessary to prevent hitcalling for responses in the biologically irrelevant direction. SC2 contains two methods for overwriting the \(max\_med\) value. If applied, negative hitcalling will be given for any \(max\_med\) greater or less than cutoff in the biologically unintended direction, by comparing the \(max\_med\) to either the positive or negative cutoff instead examining absolute values.

MC Data Processing

The goal of multiple-concentration processing is to estimate the activity, potency, efficacy, and other parameters for sample-assay pairs.

> Level 1

Level 1 processing defines the replicate and concentration index fields to facilitate downstream processing. Because of cost, availability, physicochemical, and technical constraints, screening efforts may utilize different experimental designs. The resulting data may contain an inconsistent number of concentration groups, concentration values, and technical replicates. To enable quick and uniform processing, level 1 processing explicitly defines concentration and replicate indices as \(1 \dots N\) for increasing concentrations and technical replicates, where \(1\) represents the lowest concentration or first technical replicate.

To assign replicate and concentration indices, we assume one of two experimental designs. The first design assumes samples are plated in multiple concentrations on each assay plate, such that the concentration series all fall on a single assay plate. The second design assumes samples are plated in a single concentration on each assay plate, such that the concentration series falls across many assay plates.

For both experimental designs, data are ordered by source file (\(srcf\)), assay plate ID (\(apid\)), column index (\(coli\)), row index (\(rowi\)), sample ID (\(spid\)), and concentration (\(conc\)). Concentration is rounded to three significant figures to correct for potential rounding errors. After ordering the data, a temporary replicate ID is created for each concentration series. For test compounds in experimental designs with the concentration series on a single plate and all control compounds, the temporary replicate ID consists of the sample ID, well type (\(wllt\)), source file, assay plate ID, and concentration. The temporary replicate ID for test compounds in experimental designs with concentration series that span multiple assay plates is defined similarly, but does not include the assay plate ID.

Once the data are ordered, and the temporary replicate ID is defined, the data are scanned from top to bottom and the replicate index (\(repi\)) incremented every time a replicate ID is duplicated. Then, for each replicate, the concentration index (\(cndx\)) is defined by ranking the unique concentrations, with the lowest concentration starting at 1. No methods need to be applied and the following demonstrates how to carry out the mc1 processing and look at the resulting data:

The package also contains a function, tcplPlotPlate(), for visualizing the data at the assay plate level. This function can be used to visualize the data at levels 1 to 3.

tcplPlotPlate(dat = m1dat, apid = "4009721")

Design of Assay Plate 4009721 (View in Full Resolution)