CARDINAL+Users+Manual CEE281

Cardinal
Structural Reliability Software

CopyrightDr.CharlesMenun,2004
Dr.CharlesMenun
CARDINALisaprogramforanalyzingreliabilityproblems.ThesoftwarewasdevelopedbyDr.
Charles Menun at Stanford University. Dr. Menun is an experienced structural engineer with
expertise in the use of probabilistic methods for safety and performance assessment in
earthquakeandwindengineering.HeiscurrentlyaconsultantforRiskManagementSolutions,
Inc.
CARDINAL USERS MANUAL

INTRODUCTION
The field of structural reliability is concerned with the solution of problems of the form
p f = f X ( x ) dx
(1)
where X is a vector of random variables that describe the probabilistic nature of the problem
under consideration, f X (x) is the joint probability distribution (PDF) of these random variables
and the domain defines those combinations of random variables for which the system is said
to have failed. The above integral, therefore, is referred to as the probability of failure, which
we denote p f . As an alternative to this measure of reliability, the generalized reliability index,
, given by the one-to-one transformation
= 1 ( p f )
(2)
is often used in reliability analyses.

When the boundary that separates the safe and failure domains of a problem can be
described by a single, continuous and differentiable function g (x) = 0 , the problem defined by
(1) is called a component reliability problem. By convention, the failure domain, , for
component reliability analyses is defined by
g ( x) 0 .
(3)
The function g (x) is called the limit state function and the boundary in the x-space defined by
g (x) = 0 is called the limit state surface.
When n > 1 limit state functions are needed to describe the failure domain, the problem
defined by (1) is called a system reliability problem since it can be thought of as a system of n
components each having its own limit state function, g i (x) , i = 1,2,L, n . A system is said to
have failed when a collection of its components, called a cut set, fail simultaneously. Thus, in
set theoretic terms, a cut set failure event is defined by the intersection
I g i ( x) 0
iC k
(4)
of component failure events, gi (x) 0 , i Ck , contained within the kth cut set, Ck , identified for
the system. In general, a system can fail as a result of the failure of any one of a number of cut
sets; hence the failure event for system reliability analyses is the union of cut set failure events
nC
U I g i ( x) 0
k =1 iC k
where nC is the number of cut sets identified for the system.
(5)
CEE281 Structural Reliability
CARDINAL Users Manual
CARDINAL is a program for analyzing reliability problems like those described above. As
input, the analyst must provide information that describes the basic random variables, X, and the
limit state functions, g i (x) , i = 1,2,L, n that define problem to be studied. Using this input,
CARDINAL can compute first- and second-order estimates of the probability of failure given by
(1) for components and systems as well as various reliability indices. In addition, CARDINAL can
compute the sensitivity of the results to the parameters used to define the random variables and
limit state function. Monte Carlo simulations can also be performed with CARDINAL to estimate
the integral defined in (1).
Running CARDINAL
CARDINAL is a Windows-based program for PCs. To run an analysis, double click on the
executable file cardinal.exe, which will open a window in which the desired analyses can be
selected and controlled.
The window opened by CARDINAL is simply a shell. The input for an analysis is specified
in one or more ASCII files that the analyst must provide. To run an analysis, first select the
desired input file by clicking on the Input button on the menu bar. Once the input file has been
selected, click on the Analyze button to perform the analyses. Additional analyses can be
performed by repeating the above steps1.
This manual provides a description of the ASCII input files required to run CARDINAL.
Templates for two of these files (the input file and the optional cardinal.ini) can be generated
from the analysis window by clicking on the Create button and selecting the desired file
template to be created. The examples listed in Appendix A of this manual can also be generated
from the Create submenu.
If the same input file is being used, then you do not need to reload it with the Input button. Instead, simply click
on the Analyze button to repeat the analyses.
2
CARDINAL INPUT FILE
Syntax
The operation of CARDINAL is controlled by an ASCII (plain text) input file provided by the
analyst. This file must include
1. descriptions of the basic RANDOM variables and their correlation structure
2. a description of the limit state functions (or the files in which they are defined) for the
COMPONENTS included in the analyses and
3. the type of ANALYSES to be performed.
After an initial (and optional) title block, there are four levels of instructions found in a
CARDINAL input file, namely,
KEYWORDS
COMMANDS
subcommands and
sub-subcommands
In this document, these instructions are shown in the above fonts for clarity2. In general,
KEYWORDS control the overall progress of the program while COMMANDS, subcommands
and sub-subcommands describe the desired operations to be carried out in a given segment.
The following eleven keywords are currently used in CARDINAL:
RANDOM
(page 6)
ECHO
(page 17)
PARAMETERS
(page 10)
ANALYSES
(page 19)
USER-DEFINED
(page 12)
EVALUATE
(page 30)
COMPONENTS
(page 13)
REPEAT
(page 31)
SYSTEMS
(page 15)
STOP
(page 32)
OUTPUT
(page 16)
However, only RANDOM, COMPONENTS and ANALYSES are required for every analysis; the
remaining keywords are optional and provide additional control over the computations.
A keyword or command is often followed by a block of commands or subcommands,
respectively, that are enclosed by braces { }. In general, the opening brace { is the last character
on the line containing a keyword (or command) and the closing brace } is on a separate line
following the block of commands or subcommands. To ensure CARDINAL recognizes an
opening brace, always leave a space to the left of it, as shown in the examples included in this
manual.
2
Of course, in actual input files the font is not important. In fact, any input file created with a word processor
capable of changing the fonts in a document will probably cause the program to crash.
3
Title Block
The non-blank lines in a CARDINAL input file before the first keyword is encountered are
assumed to be part of the title block used to document the analyses3. When the CARDINAL input
file is analyzed, the title block is written at the beginning of the output file. If a title block is not
specified, then a default title block is written to the output file.
As an example, if the CARDINAL input file has the lines shown in Example 1a at its
beginning, then the output file (specified with the OUTPUT keyword described later in this
document) will contain the five lines of text shown in Example 1b at its beginning.
Example 1a
A component reliability analysis
used to predict the probability of failure
of a simply-supported beam.
CEE204 homework assignment 3
Stanford University
RANDOM {
# This is a comment. Note the space between the

# keyword RANDOM and the opening brace.
M
}
# The closing brace is on a separate line following

# a block of commands.
Example 1b
A component reliability analysis
used to predict the probability of failure
of a simply-supported beam.
CEE204 homework assignment 3
Stanford University
Note that the blank lines in the title block of the input file are ignored by CARDINAL. Also note
the use of the pound sign # in Example 1a. CARDINAL interprets this symbol as an end of
line flag and ignores all text following it. This symbol is therefore useful for entering comments
into the input file, as illustrated in Example 1a and other examples that follow in this manual.
Because the program assumes that the title block is complete once it encounters a KEYWORD, you should avoid
using any of the eleven keywords listed on page 3 as the first word in a line in the title block.
4
Keywords
Descriptions of the eleven keywords used in a CARDINAL input file follow. Unless noted
otherwise, the order in which the keywords are specified is not important. Of course, the
information about the random variables and components must be defined before any analyses are
conducted; however, the order in which this information is specified is not critical. Also, it is
acceptable to use a keyword more than once in an input file if you wish to alter some aspect of
the problem as the analyses proceed. The examples in Appendix A illustrate this point. Finally,
except when noted, the keywords, commands and subcommands are not case-sensitive; for
example, RANDOM, random and RaNdoM are equivalent.
RANDOM
The keyword RANDOM is used to specify a block of information describing the random
variables in the problem to be analyzed. The random variables are grouped in PARTITIONs
which contain information about (1) the marginal and conditional distributions in the problem,
(2) the correlation matrix that defines the dependence between the random variables within a
partition and (3) initial values for the random variables to be used in the constrained optimization
algorithm for finding the design point. In terms of the lexicon described earlier, PARTITION is a
command with marginal, conditional, correlation and initial as subcommands.
Use of the RANDOM keyword is illustrated in Examples 2, 3 and 4. The general form of a
RANDOM block is shown in Example 2. Within the block are one or more PARTITIONs, which
are assigned unique and case-sensitive names. In Example 2, there are three PARTITIONs
identified as Loads, Resistances and Others. These names are used to reference the
partition once it has been defined. For example, the information within the PARTITION
Resistances can be changed later in the analyses by referring to it in another RANDOM block
such that shown in Example 3.
Example 2
Example 3
RANDOM {
RANDOM {
PARTITION Resistances {
PARTITION Loads {
}
Specify some changes to the

random variables in this
partition
PARTITION Resistances {
}
M
}
PARTITION Others {
}
Example 4 illustrates the structure within a PARTITION block. The information about the
distributions of the random variables is enclosed in a marginal block when the distributions do
not depend on other distributions, or in a conditional block when the distributions are defined in
terms of other distributions within the partition4.
Conditional distributions cannot be defined in terms of random variables that are not within the same partition.
6
Example 4
RANDOM {
PARTITION 1 {
marginal distributions {
X {
normal
mean = 10.0
standard deviation = 2.0
}
Z {
triangular
a = 0.0
b = 2.0
}
# see Example B.4
}
BoB {
lognormal
mean = 10.0
variance = 4.0
}
conditional distributions {
Sue {
type I smallest
u = X
alpha = 0.01
}
y {
gamma
lambda = BoB
k = 2.0
}
}
correlation matrix {
0.2
0.0 0.1
}
initial values {
X
= 10.0 8.0 -6.0
BoB = 2.5 3.0
Sue = 2.2 5.0
}
Each random variable (marginal and conditional) is identified by a unique, case-sensitive name.
In Example 4, the random variables are X, y, Z, Sue and BoB. Virtually any name can
be assigned to a random variable except for the function and operation names listed at the end of
Appendix B and the internally defined variables listed in Appendices C and D. The random
variable names specified in the input file can be referenced in the limit state functions and their
gradient vectors provided by the user. They are also used in the definition of conditional
distributions as illustrated in Example 4.
In Example 4, variables X, Z and BoB are marginal distributions. Random variables
Sue and y, on the other hand, are conditional distributions because they are defined in terms
of random variables X and BoB. Note that random variable BoB is not enclosed within
either a marginal block or a conditional block. In such cases, CARDINAL assumes the random
variable is a marginal one. In other words, it is not necessary to use the marginal subcommand to
specify marginal distributions; the marginal subcommand is for convenience only. Finally, as
illustrated in Example 4, all marginal distributions within a partition must be specified before
any conditional distributions are specified. Also, every partition must have at least one marginal
distribution.
Following each random variable declaration is a block containing information about the
distribution of the random variable. The first line in these blocks is the distribution type.
CARDINAL has twelve built-in distributions listed in Appendix E. For those distributions that are
not listed in Appendix E, the analyst must provide an ASCII file that specifies the PDF, CDF,
inverse of the CDF, mean, standard deviation and upper and lower bounds (if any) of the
distribution. In Example 4, random variable Z is defined in this way. Note that the name of the
distribution assigned to this random variable is triangular, which CARDINAL expects to find in
the user-defined ASCII file named triangular.distribution (i.e., the distribution name with
distribution as its extension). The programming language used in this ASCII file is
documented in Appendix B.
Following the distribution type are values for the parameters of the distribution. The
distribution parameters can be specified directly, as is the case for random variables y, Sue
and Z in Example 4. The parameter names for each distribution type available in CARDINAL
are given in Appendix E. Note that for user-defined distributions, these (unique and casesensitive) parameter names, which the analyst provides, can be referenced in the ASCII file
containing the user-defined distribution (see Example B.4 in Appendix B). For marginal
distributions, one can choose to specify the mean and standard deviation (or variance) of a builtin distribution rather than the distribution parameters. This is done for random variables X and
BoB in Example 4.
The correlation matrix for the marginal distributions in a partition is specified with the
correlation subcommand. The random variables within a partition are assumed to be uncorrelated
with all random variables that are not in that partition. Furthermore, a correlation matrix cannot
be specified for conditional distributions (the relationship of these distributions to the random
8
variables they are conditioned on defines their correlation structure). The first time a PARTITION
is specified, the correlation matrix is initialized to be the identity matrix; i.e., the marginal
random variables within the partition are uncorrelated. If the correlation subcommand is not
specified, then these random variables remain uncorrelated. Because correlation matrices are
symmetric with ones on the diagonal, only the lower triangle of the correlation matrix below the
diagonal is specified in the block following the correlation subcommand. Thus in Example 4,
random variables X and Z have a correlation coefficient of 0.2, random variables Z and
BoB have a correlation coefficient of -0.1 and random variables X and BoB are
uncorrelated.
Reliability analyses require the solution of a nonlinear constrained optimization problem. As
with any algorithm designed to solve nonlinear problems, an iterative procedure is necessary. By
default, the HLRF algorithm is used for this purpose in CARDINAL. The algorithm is started at
an initial point in the space of the basic random variables. The initial subcommand is used to
specify one or more points to use as the initial point of the HLRF algorithm. If the initial
subcommand is not issued, or an initial value is not specified for a particular random variable,
then the mean value of the random variable is assumed for the initial point. In Example 4, three
initial values are specified for X, and two initial values are specified for BoB and Sue. No
initial values are specified for random variables y or Z. Based on this input, three initial
value vectors will be created. The values of X in these vectors will be as defined by the initial
subcommand. The first two initial value vectors will use the values specified for BoB and
Sue by the initial subcommand but the third vector will assume the mean values of these
random variables. The mean values of random variables y and Z will be assigned to all three
initial value vectors.
Sometimes it is desirable to remove a partition of random variables when they are no longer
required for subsequent analyses. This can be done by issuing the DELETE command as shown
in Examples 5 and 6. In Example 5, the previously defined partition of random variables Loads
is removed while in Example 6, three previously defined partitions (Loads, Resistances and
Others) are removed.
Example 5
RANDOM {
Example 6
RANDOM {
DELETE {
DELETE Loads
}
Loads
Resistances
Others
}
}
PARAMETERS
The PARAMETERS keyword is used to specify any parameters used in the limit state function.
As an example, consider the limit state function g ( X 1 , X 2 ) = BX 1 CX 2 , where X 1 and X 2 are
the random quantities. The deterministic parameters in this function, B , and C can be
specified within a PARAMETERS block. Apart from the obvious need to specify the values of
these parameters, additional options, which control how the parameters are handled in any
sensitivity analyses, can be specified within a PARAMETERS block. If only the value of a
parameter needs to be specified (i.e., the control options are not of interest or their default values
are acceptable), then the PARAMETERS block can have the form shown in Example 7. If, on
the other hand, one or more options need to be specified, a block of subcommands must follow
the name of the parameter as shown in Example 8. As for random variables, the parameter names
must be unique (with respect to other parameters and random variables) and are case-sensitive. A
parameter cannot be assigned one of the function or operation names listed at the end of
Appendix B or any of the internally defined names listed in Appendices C and D.
Example 7
PARAMETERS {
Example 8
PARAMETERS {
theta {
value = 2.5
lower bound = 0.0
upper bound = 3.0
}
theta = 2.5
B
= 1.0
C
= 3.0
B = 1.0
C {
value = 3.0
exclude
}
In Example 8, the value subcommand is used to specify the value of the parameter. The
upper and lower subcommands specify upper and lower bounds on the parameter that must be
respected when the parameter is perturbed during any sensitivity analyses. These bounds are
usually used to prevent the program from assigning a negative value to a physical quantity that
must be positive. The default lower and upper bounds are and + , respectively.
Consequently, in Example 8, 0 3 , < B < + and C < + . Finally, the
subcommand exclude is used to exclude the parameter from the sensitivity analyses. As the
default, all parameters are included in any sensitivity analyses. The subcommand include can be
used to explicitly include a parameter in the sensitivity analyses. As for the RANDOM keyword,
a PARAMETERS block can be specified as many times as necessary. Changes to the value of a
10
parameter or any of its optional information take effect immediately and are used until they are
changed again or the program terminates.
Sometimes it is desirable to remove parameters when they are no longer required for
subsequent analyses. This can be done by issuing the DELETE command as shown in Examples
9 and 10. In Example 9, the previously defined parameter theta is removed while in Example
10, two previously defined parameters (B and C) are removed.
Example 9
PARAMETERS {
}
Example 10
PARAMETERS {
DELETE theta
DELETE {
B
C
}
11
USER-DEFINED
Like the PARAMETERS keyword, USER-DEFINED is used to specify parameters that define the
problem being analyzed. However, unlike the parameters defined within a PARAMETERS
block, sensitivity analyses are never performed with respect to USER-DEFINED parameters;
consequently, there is no need to specify lower and upper bounds on USER-DEFINED
parameters. Thus, parameter C specified in Example 8, could also be defined as a USERDEFINED parameter as shown in Example 11; CARDINAL would treat this parameter the same
way in both cases. As was the case for PARAMETERS, a USER-DEFINED parameter cannot be
assigned one of the function or operation names listed at the end of Appendix B or any of the
internally defined names listed in Appendices C and D.
The DELETE command can be used to remove any USER-DEFINED parameters that are no
longer needed. The execution of a DELETE command for USER-DEFINED parameters is
identical to that shown in Examples 9 and 10 for PARAMETERS.
Example 11
USER-DEFINED {
}
C = 3.0
12
COMPONENTS
Every reliability analysis requires the COMPONENTS keyword to specify the limit state function
and, optionally, its gradient vector with respect to the random variables for each component
included in the analyses.
As indicated in the examples below, each component included in the analyses must be
assigned a unique and case-sensitive name followed by a block of LIMIT and GRADIENT
commands that are used to specify its limit state and gradient vector functions, respectively.
These functions may be specified in an ASCII file provided by the analyst or in blocks within the
input file. If the GRADIENT command is omitted, then the gradient of the limit state function is
computed numerically by finite differences. The programming language used to specify the limit
state function and its gradient vector is documented in Appendix B.
As an example, for a component that we have named myComp, which has the limit state
function g = 2 R S 3 , where R and S are random variables, the limit state function and gradient
vector ( g = [2, 3S 2 ]T ) may be specified as shown in Examples 12 through 15. Note that in
Examples 13 and 15, CARDINAL computes the gradient vector numerically by finite differences
since it was not explicitly specified by the user. In Examples 14 and 15, the limit state function is
specified in the ASCII file g.fun shown in Example 16, while in Example 14 the gradient
vector is specified in the ASCII file dgdx.fun shown in Example 17.
The ASCII files specified by the LIMIT and GRADIENT commands can contain more than
one limit state function. The variable component defined internally by CARDINAL can be
referenced in the limit state function and gradient function files to specify the limit state function
to use (see Examples B.2 and B.3 in Appendix B).
Sometimes it is convenient to specify the complement of a component, e.g., when describing
the architecture of a system. In CARDINAL, if component C1 has been defined with the
COMPONENTS keyword, then its complement is internally defined as component ~C1, which
may be used anywhere in the CARDINAL input file as desired5. Note that performing any
analysis on components C1 and ~C1 will yield complementary results; e.g., if a FORM
analysis performed on component C1 yields a reliability index FORM , then the FORM
reliability index computed for component ~C1 will be FORM
We remark that if the limit state function of component C1 is g(x), then the limit state function corresponding to
~C1 is g(x), since changing the sign of a limit state function effectively swaps the safe and failure regions of
the x-space so that g(x) and g(x) represent complementary events.
13
Example 12
COMPONENTS {
Example 13
COMPONENTS {
myComp {
LIMIT state function {
g = 2*R S^3
}
}
myComp {
LIMIT state function {
g = 2*R S^3
}
GRADIENT vector {
gradient(1) = 2
gradient(2) = -3*S^2
}
}
}
Example 14
COMPONENTS {
myComp {
LIMIT state function = g.fun
GRADIENT vector = dgdx.fun
}
}
Example 16
# ASCII file g.fun
if(component==myComp) {
g = 2*R S^3
}
Example 15
COMPONENTS {
myComp {
LIMIT state function = g.fun
}
}
Example 17
# ASCII file dgdx.fun
if(component==myComp) {
gradient(1) = 2
gradient(2) = -3*S^2
}
14
SYSTEMS
The different modes of failure that are to be included in a system reliability analysis are specified
in terms of the cut sets that define the system function. Recall that a system is said to have failed
when a collection of its components, called a cut set, fail simultaneously.
The SYSTEMS keyword is used to define the systems to be analyzed in terms of their cut
sets . Each system is specified by a unique, case-sensitive name followed by a block that, after
the first line, defines the components (or previously defined systems) in each cut set on a
separate line. In Example 18, assume that four components named C1, C2, C3 and C4
have been previously defined with the COMPONENTS keyword. Systems Sys2, Sys3 and
Sys4 listed in Example 18 specify the general system shown in Figure 1 while system Sys1
specifies the parallel subsystem composed of components C2 and C3 in this figure. Note
how we have replaced this parallel subsystem (in the second cut set) in the definition of system
Sys2 with the previously defined system Sys1 in the definition of system Sys3. Also note
how we have used the complement of component C1 to define the general system shown in
Figure 1 in terms of two disjoint cut sets as system Sys4. Systems Sys2, Sys3 and Sys4
are equally valid representations of the system shown in Figure 1.
6
Example 18
Figure 1
SYSTEMS {
Sys1 {
CUTSET definition
C2 C3
}
Sys2 {
CUTSET definition
C1 C4
C2 C3 C4
}
C2
C1
C3
C4
Sys3 {
CUTSET definition
C1 C4
Sys1 C4
}
Sys4 {
CUTSET definition
C1 C4
C2 C3 C4 ~C1
}
Actually, there are several ways of specifying the architecture of a system within CARDINAL. For bevity, only the
CUTSET definition, which is always sufficient (but not necessarily the most efficient way of defining a system), is
described in this manual. The syntax for the other methods can be found in the template input file that can be
generated from the Create submenu in the CARDINAL analysis window.
15
OUTPUT
The OUTPUT keyword is used to specify the ASCII file in which the output of the analyses is to
be recorded. The syntax for this keyword is illustrated in Example 19 for the case when the
desired output file is named myfile.out.
Example 19
OUTPUT file = myfile.out
16
ECHO
The ECHO keyword is used to control the amount of output generated by the program. The
commands associated with this keyword are:
PROGRESS
Display the progress of the program to the analysis window.

INPUT
Echo the input to the output file.

OUTPUT
Echo the output to the output file.

ALL
When more than one initial value vector specified, output the solutions obtained for all
initial value vectors.
BEST
When more than one initial value vector specified, output only the best solution obtained
for all initial value vectors.
ITERATIONS
Output the results at the end of each iteration of the HLRF algorithm (primarily used for
debugging).
STEP
Output the results of the step size calculation in the HLRF algorithm (primarily used for
debugging).
DATE
Print the time and date at which the analyses were performed.
TIME
Record the length of time to perform each analysis requested.

EVALUATIONS
Record the number of limit state function, gradient vector and Hessian matrix evaluations
required for each analysis requested.
OFF
Do not print anything to the output file, including the actual output.
DEFAULT
Equivalent to setting INPUT, OUTPUT, PROGRESS and BEST, which are the default
settings when an ECHO command is not specified.
These commands can be specified in the two ways shown in Example 20.
17
Example 20
ECHO {
DATE
PROGRESS
ALL
}
ECHO TIME
ECHO EVALUATIONS
18
ANALYSES
The ANALYSES block specifies how the problem is to be analyzed. The commands that can be
executed in an ANALYSES block are
MVFOSM
Mean-value, first-order, second-moment analysis.

FOSM
First-order, second-moment analysis.

FORM
First-order, reliability method.

SORM
Second-order, reliability method.

SENSITIVITY
Component sensitivity analyses.

MONTE CARLO
Monte Carlo simulation analyses.

SYSTEM
System reliability analyses.

EMPIRCAL CDF
Generate the empirical CDF of one or more random quantities.

PLOT
Plot the PDF or CDF of a random variable.

SAVE
Instructs the program to store the results for a component reliability analysis.
LOAD
Instructs the program to retrieve the results stored by a previously executed SAVE
command.
COMPONENT
Specifies the component to analyze.

EVALUATE
Instructs the program to evaluate a block of program language.

RESET
Instructs the program to reset all previous results computed in an analysis block.
STOP
Stop the analyses and terminate the program.
19
Descriptions of the analyses and operations associated with these commands and the available
subcommands are described below. Typical ANALYSES blocks are shown in Examples 21 and
22.
MVFOSM
The only subcommand available for MVFOSM analyses is component, which is used to specify
the component to use. The component subcommand can be issued more than once, as shown in
Example 21. In this case, an MVFOSM analysis is done for each of the components listed. If no
components are specified, the default value is the component previously analyzed by any
method.
FOSM and FORM
For FOSM and FORM analyses, in addition to a component subcommand that operates in a
manner identical to that described above for MVFOSM, there is also an initial subcommand that
can be used to specify the initial value vector with which to start the HLRF algorithm. As for the
component subcommand, the initial subcommand can be issued more than once in a block. When
the initial subcommand is not specified, the default is to use only the first initial value vector
specified.
The analyst can also specify the algorithm used to find the design point through the
subcommands HLRF or reduced gradient7. When neither HLRF nor reduced gradient is specified
in a FOSM or FORM analysis block, the default algorithm is as specified by the variable HLRF
in the cardinal.ini file (when HLRF = 0, the reduced gradient algorithm is used; otherwise the
HLRF algorithm is used). When cardinal.ini is not found or the variable HLRF is not specified
in cardinal.ini, then CARDINAL uses the HLRF algorithm.
SORM
For SORM analyses, the component subcommand can be specified as described above.
However, before SORM analyses can be performed for a particular component, FORM results for
that component must be available. Three other subcommands are available within a SORM
analysis block to specify the desired approximation.

The subcommands curvature and point-fitting specify how the curvatures of the limit state
surface at the design point are to be computed for use in the approximate formulae proposed by
Breitung (1984) and Hohenbichler and Rackwitz (1988). If curvature is specified, then the
Hessian matrix of the limit state surface at the design point is evaluated and used to determine
the principal curvatures. If point-fitting is specified, then the curvatures are approximated as
described by Der Kiureghian etal. (1987).
The reduced gradient algorithm attempts to locate the design point in the standard normal space through a series of
line searches directed away from the origin.
20
The subcommand piecewise-linear instructs the program to idealize the limit state surface in
a piecewise-linear manner with a collection of auxiliary hyper-planes (each corresponding to
what can be thought of as an additional component) and perform a first-order system reliability
analysis to estimate the probability content of the failure domain8. The piecewise-linear
subcommand may be followed by a block of sub-subcommands (enclosed in braces {}) that
control how the system analyses are to be performed. The sub-subcommands include
decompose, cull, display, unimodal, bimodal, first-order and seed. The purpose of each of these
sub-subcommands is as described for the evaluate subcommand associated with SYSTEM
analyses below.
When neither curvature, point-fitting nor piecewise-linear is specified, the curvature
subcommand acts as the default value.
SENSITIVITY
For SENSITIVITY analyses, the component subcommand can be specified as described above.
However, before SENSITIVITY analyses can be performed for a particular component, FORM
results for that component must be available. Three other subcommands, beta, alpha and
approximate, are also available within a SENSITIVITY block. These subcommands specify the
type of sensitivity analyses to be computed. The beta subcommand is issued if the sensitivity of
the FORM reliability index with respect to the distribution and limit state function parameters is
desired. The alpha and approximate subcommands specify sensitivity calculations for the unit
vector alpha with respect to the distribution and limit state function parameters. approximate
analyses make some assumptions that simplify the sensitivity calculations at the expense of
accuracy. If none of these subcommands is specified, the beta subcommand acts as the default
value.
MONTE CARLO
MONTE CARLO analyses can be used to compute the failure probabilities and corresponding
generalized reliability indices of any components specified by component subcommands or the
reliability of any systems, which are specified with system subcommands. The analyses are
controlled by the following five optional subcommands

cov = < targetvalue >
The target coefficient of variation at which the simulations are terminated is set equal to
< targetvalue >. The default value is set by the parameter mccov in the cardinal.ini
file. When cardinal.ini is not found or the variable mccov is not specified, cov = 0.05.
This approximation is described in Menun, C. and Tarjn, G. 2004. Piecewise-linear system reliability estimates.
Proceedings of the Eleventh IFIP WG 7.5 Working Conference on Reliability and Optimization of Structural
Systems, 2-5 November 2003,Banff, Canada, p. 213-220.
21
iterations = < iter >
The maximum number of simulations to allow before terminating the analyses is set
equal to the integer < iter >. The default value is set by the parameter mciter in the
cardinal.ini file. When cardinal.ini is not found or the variable mciter is not specified,
iterations = 10000.
print = < freq >
The frequency at which the progress of the Monte Carlo simulation is reported is set
equal to the integer < freq >. The default value is set by the parameter mcprintfreq in
the cardinal.ini file. When cardinal.ini is not found or the variable mcprintfreq is not
specified, print = 1000.
radius = < rad >
The radius of the Harbitz hyper-sphere outside of which the sampling is to be done is set
equal to < rad >. If < rad > = 0.0, then importance sampling with the Harbitz hypersphere is not performed. If < rad > is less than zero, then CARDINAL computes the
optimal value of the hyper-sphere radius and uses it for importance sampling. The default
value is radius = 0.0 (no importance sampling).
seed = < seedvalue >
The seed value used to initialize the random number generator is set equal to
< seedvalue >. If seed is not specified (or set less than or equal to zero), then CARDINAL
randomly generates a seed value to use.
When any of these subcommands are omitted, default values are assumed.
SYSTEM
The SYSTEM command instructs CARDINAL to perform one or more operations and/or analyses
on a system previously defined by the SYSTEMS keyword. The subcommands available within a
SYSTEM analysis are
display < sys1 > < sys2 > < sys3 >
Display the cut set representation(s) of systems < sys1 > , < sys2 > and < sys3 >. If no
systems are specified, then display all currently defined systems.
delete < sys1 > < sys2 > < sys3 >
Remove previously defined systems < sys1 > , < sys2 > and < sys3 >.
copy < sys1 > < sys2 >
Copy previously defined system < sys1 > to system < sys2 >.
complement < sys1 > < sys2 >
Compute the complement of system < sys1 > and save it as system < sys2 >.
22
decompose < sys1 > < sys2 >

Decompose system < sys1 > into an equivalent collection of disjoint cut sets and save the
resulting system as < sys2 >.
piecewise-linear < sys1 > < sys2 >
Use the procedures described by Menun and Tarjn (see footnote 8) to idealize each
component in system < sys1 > and save the resulting system representation as system
< sys2 >.
cull < sys1 > < threshold >
Sort the cut sets in system < sys1 > according to their probabilities and remove the largest
subset of the cut sets whose combined probability (computed as a simple sum) is less
than the probability specified by < threshold >.
evaluate < sys1 >
Compute the reliability of system < sys1 > by one of several methods specified in (an
optional) block of sub-subcommands (enclosed in braces {}). If no method is specified,
then the default operation is to evaluate the first-order system reliability only. The
available methods are
unimodal bounds
Compute the unimodal bounds on the system reliability.

bimodal bounds
Compute the bimodal bounds on the system reliability.

relaxed bimodal bounds
Compute the relaxed bimodal bounds on the system reliability (ignored if the
system sys1 is not a simple series system.
first-order estimate
Compute the first-order system reliability estimate.

< seedvalue >. If seed is not specified (or set less than or equal to zero), then
CARDINAL randomly generates a seed value to use.
sensitivity < sys1 >
Compute the sensitivity of the first-order system reliability estimate computed for system
< sys1 > with respect to one or more parameters in the problem. The type(s) of sensitivity
analyses may by specified in (an optional) block of sub-subcommands (enclosed in
braces {}). If a block of sub-subcommands is not provided, then the default operation is
to evaluate the sensitivity with respect to the component reliability indices only. The firstorder system reliability must be computed with the evaluate subcommand before any
23
sensitivity analyses (expect for Birnbaum importance) can be evaluated. The available
types of sensitivity analyses are
beta sensitivity
Compute the sensitivity of the system reliability with respect to the reliability
index of each component.
correlation sensitivity
Compute the sensitivity of the system reliability with respect to the correlation
coefficients between the component failure modes.
parameter sensitivity
Compute the sensitivity of the system reliability with respect to the distribution
and limit state function parameters. The beta and correlation sensitivity of the
system must be computed prior to evaluating the parameter sensitivity.
Additionally, beta and alpha (or approximate) sensitivity results for each
component in the system must be computed with the component SENSITIVITY
command before parameter sensitivity analyses can be performed.
improvement potential
Compute the improvement potential in the system reliability with respect to each
component.
Birnbaum importance
Compute the Birnbaum importance of each component within a system.

< seedvalue >. If seed is not specified (or set less than or equal to zero), then
CARDINAL randomly generates a seed value to use.
EMPIRICAL CDF
The EMPIRICAL CDF command instructs CARDINAL to use Monte Carlo simulation to generate
the empirical cumulative distribution function (CDF) of one or more random quantities
associated with a component. In addition, CARDINAL computes and records (in the analysis
output file specified with the OUTPUT keyword) the first four sample moments and the median
of each random quantity and, when more than one quantity is being recorded, the sample
correlation coefficients. The EMPIRICAL CDF command is always followed by a block of
subcommands (enclosed in braces {}) that define the desired analyses. These subcommands are
component < componentName >
The component to consider.
24
record < quantity >
Random quantity to record. Any quantity that is simulated (i.e., the basic random
variables in the problem) or computed when evaluating the limit state function of the
component under consideration (i.e., a derived random quantity) may be recorded. More
than one quantity may be recorded simultaneously by specifying several record
subcommands. If no record subcommands are specified, then the default is to record the
limit state function value returned by the internally defined variable g.
output < fileName >
Name of the output file to save the output. If an output subcommand is not specified, then
the default is to save the output in the file named componentName.ecdf, where
componentName is the name of the component specified by the component
subcommand.
iterations = < iter >
The number of simulations to use to create the empirical CDF is set equal to the integer
< iter >. The default value is iterations = 10000.
print = < freq >
The frequency at which the progress of the empirical CDF computation is reported is set
equal to the integer < freq >. The default value is print = 1000.
< seedvalue >. If seed is not specified (or set less than or equal to zero), then CARDINAL
randomly generates a seed value to use.
PLOT
The PLOT command instructs CARDINAL to generate and save the data required to plot the PDF
or CDF of one of the basic random variables in the problem. The PLOT command is always
followed by a block of distribution subcommands (enclosed in braces {}) that define each desired
plot. Each plot is specified by a block of sub-subcommands (enclosed in braces {}) that follow a
9
distribution subcommand . These sub-subcommands are
random = < variableName >
The random variable to consider is specified by the argument < variableName >. If the
sub-subcommand random is not specified or its argument < variableName > is missing or
an invalid random variable name, then the default action is to use the first random
variable defined in the CARDINAL input file.
The PLOT command has been set up so that in future versions of CARDINAL other quantities of interest (e.g., limit
state surfaces) may be specified. Consequently, the commands used to plot a distribution function are enclosed in
(what currently appears to be) an unnecessary distribution block.
25
function = < functionType >
The argument < functionType > is either PDF or CDF, depending on the desired
function to be plotted. If the sub-subcommand function is not specified or its argument
< functionType > is missing or neither PDF nor CDF, then the default action is to
plot the PDF.
output = < fileName >
Name of the output file to save the output. If the output sub-subcommand is not specified,
then the default is to save the output in the file named variableName.pdf or
variableName.cdf (depending on the function type specified by the sub-subcommand
function), where variableName is the name of the random variable specified by the subsubcommand random.
points = < pnts >
The number of points to use to plot the distribution is set equal to the integer < pnts >.
The default value is points = 100.
lower value = < value >
The lower value of the plotted range is set equal to < value >.
lower percentile = < percentile >
The lower value of the plotted range is set equal to that value that corresponds to the
< percentile > specified.
lower = < value >
Equivalent to lower value = < value >. If neither lower value, lower percentile nor lower
is specified, then CARDINAL assumes lower percentile = 0.001.
upper value = < value >
The upper value of the plotted range is set equal to < value >.
upper percentile = < percentile >
The upper value of the plotted range is set equal to that value that corresponds to the
< percentile > specified.
upper = < value >
Equivalent to upper value = < value >. If neither upper value, upper percentile nor upper
is specified, then CARDINAL assumes upper percentile = 0.999.
SAVE
The SAVE command is used to save the results of any MVFOSM, FOSM, FORM, SORM,
SENSITIVITY and MONTE CARLO analyses performed for a component to a separate file that
can be retrieved at a later time using the LOAD command. The SAVE command has two
subcommands. The component subcommand specifies the component to save and the file
subcommand specifies the name of the file to use. When the component subcommand is omitted,
26
the default component is the last component previously analyzed by any method. When the file
subcommand is omitted, the default file name is componentName.dat, where
componentName is the name of the component specified by the component subcommand (or
last analyzed by any method when the component subcommand is omitted).
LOAD
The LOAD command retrieves the data stored by a previously executed SAVE command. The
file name to be retrieved must be specified immediately after the LOAD command (on the same
line). The saved data can be from the current CARDINAL analysis or a previous analysis. The
primary use of the SAVE and LOAD commands is for system reliability analyses that are
composed of a large number of components. These commands allow the analyst to perform the
required component analyses via a number of short analyses (rather than one long analysis) that
can be retrieved at a later time to evaluate the system reliability.
COMPONENT
The COMPONENT command is used to set the component to be analyzed. This command is
similar to the component subcommand in MVFOSM, FOSM, FORM, SORM, SENSITIVITY and
MONTE CARLO analyses. However, unlike the operation of the component subcommand, only
the last component specified by the COMPONENT command is used.
EVALUATE
See the description for the keyword EVALUATE.

RESET
All results previously computed results in an analysis block are deleted from memory, but not
from the output file if they have already been recorded.
STOP
The STOP command instructs the program to terminate immediately. Like the STOP keyword,
this command is useful when you want to run only the first part of a long ANALYSES block.
Note that all instructions following a STOP command are ignored, including all instructions
following the current ANALYSES block.
27
Example 21
ANALYSES {
MVFOSM {
component C1
component C2
}
# Conduct MVFOSM analyses on components C1 and C2
FOSM
# Conduct FOSM analyses on component C2 only

# using the first initial value vector specified
COMPONENT = C1
# Use component C1
FORM {
initial value vector 1
initial value vector 2
}
# Conduct FORM analyses on component C1
# using initial value vectors 1 and 2
SORM {
curvature
point-fitting
}
# Compute second-order estimate of the reliability for
# component C1. Compute the curvature of the
# limit state surface using two different methods
SAVE {
component = C1
file = component.C1
}
# Save the results computed for component C1
# to the file component.C1 for later use
FORM {
component = C2
}
# Conduct FORM analyses on component C2
SAVE {
component = C2
file = component.C2
}
# Save the results computed for component C2
# to the file component.C2 for later use
}
# End of the ANALYSES block
28
Example 22
ANALYSES {
LOAD component.C2
# Load the results obtained from a previous
# analysis of component C2. See Example 21.
SENSITIVITY {
component = C2
beta
approximate Alpha
}
# Compute the sensitivity of the FORM analyses for component C2.
# Compute the sensitivity of the reliability index with respect
# to the distribution and limit state function parameters.
# Use the approximate method to compute the sensitivity with
# respect to the unit vector alpha
MONTE CARLO {
component = C2
cov = 0.01
iterations = 50000
print = 10000
radius = -1
}
# Use a Monte Carlo simulation with importance sampling
# to estimate the reliability of component C2.
# The simulations are terminated when either the uncertainty
# in the estimate has a coefficient of variation that is less
# than 0.01 or the number of simulations exceeds 50000.
# The Monte Carlo estimate is reported to the output file after
# every 10000 iterations.
LOAD component.C1
# Load the results obtained from a previous
# analysis of component C1. See Example 21.
FORM {
component = C3
}
# Perform FORM analyses for component C3.
SYSTEM {
evaluate Sys1 {
first-order
unimodal
bimodal
}
}
# Compute the first-order system reliability index of system
# Sys1 and its unimodal and bimodal bounds.
}
# End of ANALYSES block
29
EVALUATE
The EVALUATE keyword (or command within an ANALYSES block) instructs CARDINAL to
evaluate a block of the program language documented in Appendix B. The resulting values of
any variables evaluated in an EVALUATE block are available to the rest of the program input
file, as shown in Example 23, in which the mean value of the lognormal random variable X is
assigned the value of the variable myMean computed in the EVALUATE block that comes
before the RANDOM block in which X is defined.
EVALUATE blocks are also able to access many of the internally computed quantities (see
Appendix D) for the purposes of doing specialized calculations with the results generated within
ANALYSES blocks, like that shown in Example 24, in which the reliability indices computed by
five FORM analyses with different values for the mean of random variable X are summarized
in a separate file my.output specified within the EVALUATE block. The resulting my.output
file is shown in the inset in Example 24.
Example 23
EVALUATE {
myMean = 1.0
}
RANDOM VARIABLES {
PARTITION 1 {
X {
lognormal
mean
=
std dev =
}
Y {
lognormal
mean
=
std dev =
}
myMean
1.0
1.0
1.0
# defined in above EVALUATE block
# CARDINAL recognizes std dev

# as standard deviation
}
}
}
30
REPEAT (num)
The REPEAT keyword instructs CARDINAL to repeat the block of commands contained between
the braces {} that follow the REPEAT keyword num times. A typical use of the REPEAT
keyword is illustrated in Example 24, in which five FORM analyses of component C1 are
performed with different values for the mean of random variable X (specified by the variable
myMean, which is computed in an EVALUATE block). Also note the use of the EVALUATE
keyword to extract the reliability indices computed by the FORM analyses using the internally
defined variable C1.form.beta (see Appendix D) and summarize them in the file my.output
shown in the inset.
Example 24
EVALUATE {
open(my.output,write)
write("
Mean") write("
close(my.output)
myMean = 0.0
}
Beta")
newline
REPEAT(5) {
EVALUATE {
myMean = myMean + 1.0
}
RANDOM VARIABLES {
PARTITION 1 {
X {
lognormal
mean
=
myMean
std dev =
1.0
}
Y {
lognormal
mean
=
1.0
std dev =
1.0
}
}
}
}
ANALYSIS {
COMPONENT = C1
FORM
}
EVALUATE {
open(my.output,append)
format(xxx.xxx)
write(myMean) write(C1.form.beta)
close(my.output)
}
File my.output
Mean
1.000
2.000
3.000
4.000
5.000
Beta
1.739
1.758
1.853
2.003
2.190
newline
31
STOP
The STOP keyword instructs the program to terminate immediately. This command is useful
when you want to run only the first part of a long input file.
32
APPENDIX A Sample CARDINAL Input Files

Example A.1
Examples 15.1 and 15.2 in CEE204 lecture notes
ECHO {
DATE
ITERATIONS
}
OUTPUT file = exampleA1.out
COMPONENTS {
C1 {
LIMIT state function file = exampleA1.g
GRADIENT vector file
= exampleA1.dgdx
}
C2 {
= exampleA1.dgdx
}
}
# see Example B.2

# see Example B.3
# see Example B.2
# see Example B.3
RANDOM VARIABLES {
PARTITION 1 {
X1 {
normal
mean
= 10.0
variance = 4.0
}
X2 {
normal
mean
= 20.0
variance = 25.0
}
correlation matrix
0.5
}
}
}
PARAMETERS {
p1 = 2
p2 = 3
}
ANALYSES {
COMPONENT = C1
MVFOSM
FOSM
COMPONENT = C2
MVFOSM
FOSM
}
A1
Example A.2
Basic component reliability problem
Safety margin formulation: g = R - S
Safety factor formulation: g = ln(R/S)
ECHO DATE
COMPONENTS {
C1 {
= exampleA2.dgdx
}
C2 {
= exampleA2.dgdx
}
}
# see inset
# see inset
# see inset
# see inset
RANDOM VARIABLES {
PARTITION 1 {
R {
Rayleigh
u = 70
}
S {
Exponential
lambda = 0.05
}
}
correlation matrix
0.5
}
}
}
ANALYSES {
MVFOSM {
component C1
component C2
}
# Limit state function file exampleA2.g

if(component==C1) {
g = R S
}
if(component==C2) {
g = ln(R/S)
}
FOSM {
component C1
component C2
}
FORM {
component C1
component C2
}
}
# Gradient function file exampleA2.dgdx

if(component==C1) {
gradient(1) = 1
gradient(2) = -1
}
if(component==C2) {
gradient(1) = (S/R)*(1/S)
gradient(2) = (S/R)*(-R/(S^2))
}
A2
Example A.3
Perform FORM analyses on component C1 (safety margin formulation) only
Assume two different correlation matrices
ECHO DATE
COMPONENTS {
C1 {
= exampleA2.dgdx
}
C2 {
= exampleA2.dgdx
}
}
# see inset in Example A.2

RANDOM VARIABLES {
PARTITION 1 {
R {
Rayleigh
u = 70
}
S {
Exponential
lambda = 0.05
}
}
correlation matrix
0.5
}
}
}
ANALYSES {
COMPONENT C1
FORM
}
RANDOM VARIABLES {
PARTITION 1 {
R {
Rayleigh
u = 70
}
S {
Exponential
lambda = 0.05
}
}
correlation matrix
0.0
}
}
}
ANALYSES {
COMPONENT C1
FORM
}
A3
Example A.4
The parameter for the exponential function is now a lognormally-distributed random variable
R and S are uncorrelated
ECHO DATE
COMPONENTS {
C1 {
= exampleA4.dgdx
}
C2 {
= exampleA4.dgdx
}
}

# see inset below
# see inset below
RANDOM VARIABLES {
PARTITION 1 {
Z {
lognormal
mean
= 0.05
std dev = 0.01
}
R {
Rayleigh
u = 70
}
}
conditional distribution {
S {
Exponential
lambda = Z
}
}
}
}
ANALYSES {
COMPONENT C1
FORM
}
# Gradient function file exampleA4.dgdx

if(component==C1) {
gradient(1) = 0
gradient(2) = 1
gradient(3) = -1
}
if(component==C2) {
gradient(1) = 0
gradient(2) = (S/R)*(1/S)
gradient(3) = (S/R)*(-R/(S^2))
}
A4
Example A.5
Z has the user-defined distribution defined in example B.4 of the CARDINAL user manual
ECHO DATE
COMPONENTS {
C1 {
= exampleA4.dgdx
}
C2 {
= exampleA4.dgdx
}
}

RANDOM VARIABLES {
PARTITION 1 {
Z {
triangular
a = 0.025
b = 0.100
}
R {
Rayleigh
u = 70
}
}
# see example B.4
S {
Exponential
lambda = Z
}
}
}
}
ANALYSES {
COMPONENT C1
FORM
}
A5
Example A.6
Z has the user-defined distribution defined in example B.4
S is exponential, but is specified as a user-defined distribution
(there is no advantage in doing this we are just demonstrating that it can be done)
ECHO DATE
COMPONENTS {
C1 {
= exampleA4.dgdx
}
C2 {
= exampleA4.dgdx
}
}

RANDOM VARIABLES {
PARTITION 1 {
Z {
triangular
a = 0.025
b = 0.100
}
R {
Rayleigh
u = 70
}
}
S {
myExponential
lambda = Z
}
}
}
}
ANALYSES {
COMPONENT C1
FORM
}
# see example B.4
# User-defined distribution file myExponential.distribution

# (exponential distribution)
if(computeBounds) lowerbound = 0
if(computePDF) {
if(arg<0) pdf = 0
else pdf = lambda*exp(-lambda*arg)
}
if(computeCDF) {
if(arg<0) cdf = 0
else cdf = 1 - exp(-lambda*arg)
}
if(computeInverseCDF) {
if(arg<0) invcdf = 0
else {
if(arg>=1) invcdf = +INF
else invcdf = -ln(1-arg)/lambda
}
}
if(computeMean) mean = 1/lambda
if(computeStddev) stddev = 1/lambda
A6
APPENDIX B Programming Language

The programming language used in the ASCII files that specify the limit state function, the
gradient vector of the limit state function and any user-defined distributions is documented in
this appendix. This programming language is also used within EVALUATE blocks in the
CARDINAL input file. All arithmetic and logical operations are supported by the language as well
as most commonly used mathematical functions and some matrix and array operations. The
available functions are listed at the end of this appendix. There are also several control structures
implemented in the language, including for and while loops, and if/else structures.
Matrices and arrays are be specified with the var command and the memory assigned to
them is returned to the stack with the free command, as illustrated in Example B.1. This
example also demonstrates how the elements of a matrix or array can be specified and accessed.
Note that the first index of a row or column in a matrix or an array is i = 1.
Example B.1
var a(5)
var M(2,3)
var i,j,r,s
for(i=1;i<=5;i++) {
a(i) = i
}
for(i=1;i<=2;i++) {
for(j=1;j<=3;j++) {
M(i,j) = i^2 + ln(j)
#
#
#
#
#
an array having 5 elements

a matrix with 2 rows and 3 columns
scalar quantities. Note, it is not necessary to declare scalar
variables with a var command; however, it is acceptable to do
so, as shown here.
# initialize the values in array a
# initialize the values in matrix M
}
}
r = a(2)
s = M(2,1)
# assign the value of the second element of array a to variable r

# assign the value of the second row and first column of matrix M
# to variable s
a(1) = r*s
# assign the product of r*s to the first element of array a
free a,M
# return the memory assigned to a and M by the var command

# back to the stack
free i,j,r,s
# if scalar variables are declared with the var command, as was

# done here, then the memory assigned to them should be explicitly
# returned to the stack with the free command
An example limit state function file, gradient function file and user-defined distribution file
follow to further clarify the required syntax of these files. The CARDINAL input file that
references the following limit state function and gradient vector function files is listed in
example A.1 of Appendix A. The CARDINAL input files that reference the user-defined
distribution file shown in Example B.4 are listed in Examples A.5 and A.6.
B1
Limit State Function File

Example B.2 lists the limit state function file for Examples 15.1 and 15.2 in the CEE204 lecture
notes. The corresponding CARDINAL input file that references this limit state function file is
listed in Example A.1.
Example B.2
# Limit state functions for Examples 15.1 and 15.2 in CEE 204 lecture notes
# See Example A.1 for CARDINAL input file
if(component==C1) {
g = X1^p1 - p2*X2
}
if(component==C2) {
g = 1 - p2*X2/(X1^p1)
}
In this example, the limit state functions of two components, C1 and C2 are specified.
The limit state function that CARDINAL uses is determined by the value of the internally defined
variable component, which is set by the COMPONENT command or the component
subcommand in the ANALYSES block of the CARDINAL input file.
For the problem under consideration in the above example, there are two random variables
(defined in a RANDOM block of the CARDINAL input file listed in example A.1) called X1
and X2. There are also two parameters, p1 and p2 (defined in the PARAMETERS block
of the input file). Note that, unlike the CARDINAL input file, the programming language and
function files discussed in this appendix are always case-sensitive (this is why the random
variable names and parameter names in the CARDINAL input file are case-sensitive).
As indicated in the above code, the value of the limit state function must be assigned to the
internally defined variable g. The value assigned to g is returned to the main program for use
in the analyses. Note that because component and g are internally defined variables, you
should not declare them with a var command nor return the memory assigned to them to the
stack with a free command.
B2
Gradient Vector Function File

Example B.3 lists the gradient vector function file for Examples 15.1 and 15.2 of the CEE204
lecture notes. The corresponding CARDINAL input file that references this limit state function
file is listed in Example A.1.
Example B.3
# Gradients of limit state functions for Examples 15.1 and 15.2 in CEE 204 lecture notes
# See Example A.1 for CARDINAL input file
if(component==C1) {
gradient(1) = p1*X1^(p1-1)
gradient(2) = -p2
}
if(component==C2) {
gradient(1) = p1*p2*X2/(X1^(p1+1))
gradient(2) = -p2/(X1^p1)
}
The basic structure for a gradient vector function file is similar to that of a limit state
function file. The main difference, of course, is that the gradient vector function file must return
an array of numbers (equal in length to the number of random variables in the problem). As
indicated in the above example, the result is returned in the internally defined array gradient.
The elements of the gradient vector are assigned in the order in which the random variables
were originally defined in the CARDINAL input file. For this example, random variable X1
was defined before random variable X2 (see listing in Example A.1); therefore, the derivative
of the limit state function with respect to X1 is assigned to the first element of gradient and
the derivative with respect to X2 is assigned to the second element of gradient. Note that
because gradient is an internally defined variable, you should not declare it with a var
command nor return the memory assigned to it to the stack with a free command.
If the gradient function file is not specified or cannot be found, CARDINAL computes the
gradient vector by finite differences.
B3
User-Defined Distribution Files

Example B.4 lists the user-defined distribution file triangular.distribution referenced by
random variable Z in the CARDINAL input files listed in Examples A.5 and A.6.
Example B.4
# User-defined distribution file triangular.distribution
# A triangular distribution bounded by a and b (see inset)
# The internally defined variable arg is used as the argument
# for the PDF, CDF and inverse CDF functions
if(computeBounds) {
lowerbound = a
upperbound = b
}
# a and b are the parameters specified in

# the definition of this distribution in
# the input file
if(computePDF) {
if(arg<a) pdf = 0
else {
if(arg<b) pdf = 2*(b-arg)/((b-a)^2)
else pdf = 0
}
}
if(computeCDF) {
if(arg<a) cdf = 0
else {
if(arg<b) cdf = 1 - ((b-arg)^2)/((b-a)^2)
else cdf = 1
}
}
if(computeInverseCDF) {
if(arg<0) invcdf = a
else {
if(arg<1) invcdf = b - sqrt((1-arg)*((b-a)^2))
else invcdf = b
}
}
f Z (z )
if(computeMean) {
mean = (2*a + b)/3
}
if(computeStddev) {
stddev = ((b-a)^2)/18
}
A user-defined distribution is identified by a unique name specified in the CARDINAL input

file (e.g., triangular for random variable Z in Examples 4, A.5 and A.6). In this case,
information about the distribution must be provided by the analyst in an ASCII file called
triangular.distribution (i.e., the distribution name with distribution as its extension), as
shown in Example B.4. Any parameters specified for a user-defined distribution (e.g. parameters
a and b for the triangular distribution specified in Examples 4, A.5 and A.6), can be accessed
directly within the ASCII file, as indicated in Example B.4.
B4
In general, a user-defined distribution file must be able to return the following quantities
through the internally defined variables shown when the internally defined flag associated with
the quantity is TRUE.
Quantity
Internally defined variable
Internally defined flag
PDF
pdf
computePDF
CDF
cdf
computeCDF
inverse of the CDF
invcdf
computeInverseCDF
mean
mean
computeMean
standard deviation
stddev
computeStddev
lower bound
lowerbound
computeBounds
upper bound
upperbound
computeBounds
The internally defined variable arg is used as the argument for the PDF, CDF and inverse CDF
functions, as indicated in Example B.4. When evaluating the PDF and CDF, lowerbound arg
upperbound; when evaluating the inverse of the CDF, 0 arg 1. The internally defined
variables and flags are case-sensitive.
The flags listed above are used to make the computations more efficient; e.g., when
CARDINAL needs to evaluate the PDF of a user-defined distribution, it sets all of the flags listed
above equal to FALSE except computePDF so that it does not spend any time computing the
other quantities. In general, it is acceptable to evaluate any of the above quantities when they are
not needed (which will be the case when the values of the internally defined flags are ignored),
but this will naturally increase the time required to carry out an analysis.
The variable upperbound need not be evaluated when the distribution function is
unbounded for positive realizations of the random variable (CARDINAL assumes that the upper
bound on the distribution function is + when a value for upperbound is not specified within
a user-defined distribution file). Similarly, the variable lowerbound need not be evaluated
when the distribution function is unbounded for negative realizations of the random variable.
B5
Programming Language Functions and Operations

The following is a list of functions and operations available in the programming language.
Common functions
EULER
INF
ERR
TRUE
FALSE
PI
the Euler constant

a very large number (infinity)
error return value
1
0
the ratio of a circles circumference to its diameter
abs(arg)
acos(arg)
asin(arg)
atan(arg)
beta.func(arg1,arg2)
comb(arg1,arg2)
cos(arg)
cosh(arg)
cot(arg)
csc(arg)
exp(arg)
fact(arg)
fib(arg)
frac(arg)
gamma.func(arg)
gaussianrand
gaussianrand(arg)
incgamma(arg1,arg2)
int(arg)
log(arg)
ln(arg)
lncomb(arg1,arg2)
lnfact(arg)
lngamma(arg)
max(arg1,arg2)
min(arg1,arg2)
mod(arg1,arg2)
pow(arg1,arg2)
rand
rand(arg)
round(arg)
sec(arg)
signof(arg)
sin(arg)
sinh(arg)
sqrt(arg)
tan(arg)
tanh(arg)
absolute value function

arccosine function
arcsine function
arctangent function
beta function
number of combinations of size arg2 from sample size arg1
cosine function
hyperbolic cosine function
cotangent function
cosecant function
exponential function
factorial
arg-th number in the Fibonacci sequence
fractional part of arg
gamma function
Gaussian random number (random seed value)
Gaussian random number (user specified seed value arg)
incomplete gamma function
integer part of arg
base 10 logarithm
natural logarithm
natural logarithm of comb(arg1,arg2)
natural logarithm of fact(arg)
natural logarithm of gamma.func(arg)
maximum of arg1 and arg2
minimum of arg1 and arg2
remainder when arg1 is divided by arg2
arg1 raised to the power of arg2
uniform [0,1] random number (random seed value)
uniform [0,1] random number (user specified seed value arg)
round arg to nearest integer
secant function
sign of arg
sine function
hyperbolic sine function
square root
tangent function
hyperbolic tangent function
arg!
arg1%arg2
arg1~arg2
arg1^arg2
=
=
=
=
fact(arg)
mod(arg1,arg2)
comb(arg1,arg2)
pow(arg1,arg2)
B6
Probability functions
Normal distribution
normal.pdf(arg,mean,stddev)
normal.cdf(arg,mean,stddev)
normal.invcdf(arg,mean,stddev)
Lognormal distribution
lognormal.pdf(arg,lambda,zeta)
lognormal.cdf(arg,lambda,zeta)
lognormal.invcdf(arg,lambda,zeta)
lognormal.mean(lambda,zeta)
lognormal.stddev(lambda,zeta)
Gumbel distribution
gumbel.pdf(arg,u,alpha)
gumbel.cdf(arg,u,alpha)
gumbel.invcdf(arg,u,alpha)
gumbel.mean(u,alpha)
gumbel.stddev(u,alpha)
Type I smallest distribution
type1s.pdf(arg,u,alpha)
type1s.cdf(arg,u,alpha)
type1s.invcdf(arg,u,alpha)
type1s.mean(u,alpha)
type1s.stddev(u,alpha)
Type II largest distribution
type2l.pdf(arg,u,k)
type2l.cdf(arg,u,k)
type2l.invcdf(arg,u,k)
type2l.mean(u,k)
type2l.stddev(u,k)
Weibull distribution
weibull.pdf(arg,u,k,a)
weibull.cdf(arg,u,k,a)
weibull.invcdf(arg,u,k,a)
weibull.mean(u,k,a)
weibull.stddev(u,k,a)
Gamma distribution
gamma.pdf(arg,lambda,k)
gamma.cdf(arg,lambda,k)
gamma.invcdf(arg,lambda,k)
gamma.mean(lambda,k)
gamma.stddev(lambda,k)
Shifted Rayleigh distribution
rayleigh.pdf(arg,u,a)
rayleigh.cdf(arg,u,a)
rayleigh.invcdf(arg,u,a)
rayleigh.mean(u,a)
rayleigh.stddev(u,a)
continued . . .
B7
Probability distribution functions (continued)

Shifted exponential distribution
exponential.pdf(arg,lambda,a)
exponential.cdf(arg,lambda,a)
exponential.invcdf(arg,lambda,a)
exponential.mean(lambda,a)
exponential.stddev(lambda,a)
Uniform distribution
uniform.pdf(arg,a,b)
uniform.cdf(arg,a,b)
uniform.invcdf(arg,a,b)
uniform.mean(a,b)
uniform.stddev(a,b)
Beta distribution
beta.pdf(arg,q,r,a,b)
beta.cdf(arg,q,r,a,b)
beta.invcdf(arg,q,r,a,b)
beta.mean(q,r,a,b)
beta.stddev(q,r,a,b)
Shifted chi-squared distribution
chisquared.pdf(arg,n,a)
chisquared.cdf(arg,n,a)
chisquared.invcdf(arg,n,a)
chisquared.mean(n,a)
chisquared.stddev(n,a)
Special functions
integrate(integrand,arg,low,high)
numerically integrate the expression integrand

with respect to arg over the interval
bounded by low and high
call(progname)
suspend current program evaluation to

execute the external program progname
call(progname,cmdline)
suspend current program evaluation to

execute the external program progname
with command line cmdline
dump
display the values of all variables currently

defined within the program (primarily used
for debugging)
setstring(mystring,strng)
assign the character string strng to the

string variable mystring. Once defined,
all occurrences of [mystring] (note the
square brackets) are replaced by the character
string strng.
B8
Logic operations
TRUE
FALSE
1
0
arg1 and arg2

arg1 or arg2
not arg
FALSE when arg1 = 0 or arg2 = 0, TRUE otherwise

FALSE when arg1 = 0 and arg2 = 0, TRUE otherwise
TRUE when arg = 0, FALSE otherwise
arg1&&arg2 = arg1 and arg2

arg1||arg2 = arg1 or arg2
!arg
= not arg
Program control structures
if(condition) {
<statements to evaluate when condition = TRUE>
}
else {
<statements to evaluate when condition = FALSE>
}
for(i=startValue;i<stopValue;i++) {
<statements to evaluate stopValue-startValue times>
}
while(condition) {
<statements to evaluate repeatedly as long as condition = TRUE>
}
repeat(count) {
<statements to evaluate count times>
}
return arg
stop
exit the file being evaluated, returning the value arg

exit the file being evaluated
Memory allocation operations

var arg1,arg2
var arg(n)
var arg(m,n)
assigns memory for variables arg1 and arg2

assigns memory for array arg of length n
assigns memory for matrix arg with m rows and n columns
free arg1,arg2
returns memory allocated to variables arg1 and arg2

back to the stack
exists(arg)
TRUE if variable arg has been assigned memory, FALSE otherwise
B9
Matrix functions and operations

load(fname,arg)
save(arg,fname)
load matrix stored in ASCII file fname into arg

save matrix arg in ASCII file fname
rows(arg)
columns(arg)
number of rows in matrix arg

number of columns in matrix arg
det(arg)
dotproduct(arg1,arg2)
determinant of square matrix arg

dot product of arrays arg1 and arg2
sort(arg)
sort(arg,c)
sort the first column of matrix arg in ascending order

sort column c of matrix arg in ascending order
sample.average(arg)
sample.average(arg,c)
sample.variance(arg)
sample.variance(arg,c)
sample.stddev(arg)
sample.stddev(arg,c)
sample.moment(arg,m)
sample.moment(arg,m,c)
sample.median(arg)
sample.median(arg,c)
sample.fractile(arg,f)
sample.fractile(arg,f,c)
sample.maximum(arg)
sample.maximum(arg,c)
sample.minimum(arg)
sample.minimum(arg,c)
average of the first column of matrix arg

average of column c of matrix arg
variance of the first column of matrix arg
variance of column c of matrix arg
standard deviation of the first column of matrix arg
standard deviation of column c of matrix arg
mth sample moment of the first column of matrix arg
mth sample moment of column c of matrix arg
median of the first column of matrix arg
median of column c of matrix arg
fth percentile of the first column of matrix arg
fth percentile of column c of matrix arg
maximum value in the first column of matrix arg
maximum value in column c of matrix arg
minimum value in the first column of matrix arg
minimum value in column c of matrix arg
B10
Input/output operations
Streams
open(fname,read)
open(fname,write)
open(fname,append)
use(fname)
echo
close(fname)
Input
readline
countwords
blankline
word(n)
find(strg)
findexact(strg)
eof
Output
format(xxx.xxxxxx)
format(xxx.xxxxxxE)
writeline
write(strng)
write(arg)
newline
open ASCII file fname for reading

open ASCII file fname for writing (an existing file is
overwritten)
open ASCII file fname for writing (output is appended
to a file if it already exists)
specify which among several open files to read from or
write to
direct output to the screen
close I/O stream to ASCII file fname
read the next line from an ASCII file opened with the
open(fname,read) operation
the number of words (groups of characters separated by
spaces) in the last line returned by the readline operation
TRUE when there are no words in the last line returned by the
readline operation, FALSE otherwise
the value of the nth word in the last line returned by the
readline operation
location (word number) of the string of characters in the last
line returned by the readline operation that match strg;
returns 0 if strg is not found
location (word number) of the string of characters in the last
line returned by the readline operation that exactly match
strg; returns 0 if an exact match is not found
TRUE when the end-of-file character detected by the
readline operation
display numbers in decimal format

display numbers in scientific format
write the last line returned by the readline operation to an
ASCII file opened with the open(fname,write) or
open(fname,append) operation
write the string of characters strng to an ASCII file opened
for writing
write the value of variable arg to an ASCII file opened
for writing
insert a newline character (carriage return) into an ASCII
file opened for writing
B11
APPENDIX C Internally Defined Variables

The following is a list of internally defined variables used by CARDINAL. Random variables,
parameters, user-defined quantities, components and systems should not be assigned these
names. The names are case-sensitive.
component
g
gradient
arg
computePDF
computeCDF
computeInverseCDF
computeMean
computeStddev
computeBounds
pdf
cdf
invcdf
mean
stddev
lowerbound
upperbound
C1
APPENDIX D Internally Computed Quantities

CARDINAL records many of the quantities computed during an analysis into internally defined
variables that can be accessed using the EVALUATE command or subcommand. Suppose that a
set of analyses have been performed on a component C1 and a system S1. The internally
defined variables listed in Example D.1 contain the results of the analyses performed on this
component and system1. If a quantity is undefined (i.e., the analyses needed to evaluate the
quantity have not been performed), then the internally defined variable associated with that
quantity is set equal to -10299, which CARDINAL interprets as undefined. This list of internally
defined variables can also be generated from within the CARDINAL analysis window by
selecting Variable list from the Create submenu.
Example D.1
GENERAL INFORMATION
randomVariables
parameters
(the number of random variables in the analysis)

(the number of parameters in the analysis)
COMPONENT RELIABILITY ANALYSES

MVFOSM
C1.mvfosm.beta
C1.mvfosm.pf
C1.mvfosm.mean
C1.mvfosm.sigma
C1.mvfosm.xstar
C1.mvfosm.dgdxstar
FOSM
C1.fosm.beta
C1.fosm.pf
C1.fosm.xstar
C1.fosm.ustar
C1.fosm.alpha
C1.fosm.gamma
FORM
C1.form.beta
C1.form.pf
C1.form.xstar
C1.form.ustar
C1.form.alpha
C1.form.gamma
SORM
C1.sormCurvature.beta
C1.sormCurvature.pf
C1.sormCurvature.improvedbeta
C1.sormCurvature.improvedpf
C1.sormCurvature.kappa
C1.sormPointfitted.beta
C1.sormPointfitted.pf
C1.sormPointfitted.improvedbeta
C1.sormPointfitted.improvedpf
C1.sormPointfitted.kappa
C1.sormPiecewiseLinear.beta
C1.sormPiecewiseLinear.pf
C1.sormPiecewiseLinear.cov
C1.sormPointfitted.unimodal
C1.sormPointfitted.bimodal
Monte Carlo
C1.mc.beta
C1.mc.pf
C1.mc.cov
C1.mc.iter
Sensitivity
C1.dBdq
C1.dBdp
C1.dBdmu
C1.dBdsigma
C1.dAdp
C1.approxdAdp
C1.dAdq.<RV number>
C1.approxdAdq.<RV number>
Hessian Matrix
C1.hessian
1
Variables in blue are vector quantities and variables in green are matrix quantities.
D1
Example D.1 (continued)

SYSTEM RELIABILITY ANALYSES
S1.components
(the components in the system)
First-order estimate
S1.firstorder.beta
S1.firstorder.pf
S1.firstorder.cov
Monte Carlo
S1.mc.beta
S1.mc.pf
S1.mc.cov
S1.mc.iter
Bounds
S1.unimodal
S1.bimodal
S1.relaxed
Component reliability sensitivity
S1.dBdbeta
Failure mode correlation sensitivity
S1.dBdrho
Distribution and limit state function parameter sensitivity
S1.dBdq
S1.dBdp
S1.dBdmu
S1.dBdsigma
Improvement potential
S1.IP
Birnbaum importance
S1.Birnbaum
D2
APPENDIX E Built-in Probability Distributions

The following is a list of probability distributions available in CARDINAL. The distributions can
be defined in terms of their mean and standard deviation or in terms of the parameters listed
below (see example 4).
= mean
= standard deviation
(k , x) = incomplete gamma function
= Eulers constant
Parameter names for random variable definitions

= alpha
= lambda
= mu
= sigma
(x) = gamma function
= zeta
Normal Distribution
f ( x) =
1 x 2
1
exp

2
2
x
F ( x ) =
< x <
Lognormal Distribution
f ( x) =
1 ln x 2

exp
2 x
2

1
2
= ln + 1
1
= ln( ) ln + 1
2
ln x
F ( x) =

0< x<
Gumbel Distribution
f ( x) = exp{ ( x u ) exp[ ( x u )]}

u=
F ( x) = exp{ exp[ ( x u )]}

< x <
Type I Smallest Distribution
f ( x) = exp{ ( x u ) exp[ ( x u )]}

u=+
F ( x) = 1 exp{ exp[ ( x u )]}

< x <
E1
Type II Largest Distribution
k u
f ( x) =
u x
k +1
u k
exp
x
1
k
u k
F ( x) = exp
x
= u 1
2
k
1
k
= u 1 2 1
k >0
0< x<
Weibull Distribution
k xa
f ( x) =
u au a
k 1
x a k
exp

u a
1
k
x a k
F ( x) = 1 exp

u a
= a + (u a ) 1 +
2
k
1
k
= (u a) 1 + 2 1 +
k >0
a<x<
Gamma Distribution
f ( x) =
(x) k 1 exp(x)
(k )
k =

= 2
F ( x) =
(k , x)
( k )
0< x<
Shifted Rayleigh Distribution
f ( x) =
u=
x a 2
2( x a)
exp

u2
u
2( a)
2
4
x a 2
F ( x) = 1 exp

u
a=
a<x<
E2
Shifted Exponential Distribution

f ( x) = exp[ ( x a )]
F ( x) = 1 exp[ ( x a )]
a =
a<x<
Uniform Distribution
f ( x) =
1
ba
F ( x) =
a = 3
b = + 3
xa
ba
a< x<b
Beta Distribution
f ( x) =
(q + r ) ( x a) q 1 (b x) r 1
(q ) (r )
(b a ) q + r 1
ar + bq
q+r
ba
qr
q + r q + r +1
Note: < ( a )(b )
( a)(b ) b
r=
1
2
b a
a
( a)(b ) a
r =
1
q =
2
b a
a< x<b
Shifted Chi-squared Distribution

n 1
[
( x a) 2] 2 exp[ ( x a) 2]
f ( x) =
2 (n 2)
a=
2
2
n=
2
2
n is an integer
F ( x) =
(n 2 , ( x a) 2)
(n 2)
a<x<
E3
APPENDIX F The cardinal.ini File

The performance of CARDINAL can be controlled by parameters that are defined in an optional
ASCII file named cardinal.ini that is located in the same directory as the input file. If
cardinal.ini is not present, then default values are assumed. Example F.1 lists a cardinal.ini
file with all the parameters set to their default values. This file can be generated from within the
CARDINAL analysis window by selecting Cardinal.ini from the Create submenu.
Example F.1
debug
betaIter
blankSpaces
HLRF
matlab
maxIter
maxNoImprovement
maxNoMerit
maxNRIter
maxStep
mciter
mcprintfreq
scisflag
silent
=
=
=
=
=
=
=
=
=
=
=
=
=
=
0
100
0
1
0
100
10
100
10
50
10000
1000
0
0
Armijo_a
Armijo_b
Armijo_j0
betaMax
cfactor
drho
epsilon
error1
error2
kappaTol
kBeta
mccov
noImprovementTol
scischk
sciscov
scisiter
sciseig
scissig
sciszero
sysfac
sysrho
tolerance
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
5.000000e-001
5.000000e-001
0.000000e+000
1.000000e+001
5.000000e+000
1.000000e-002
1.000000e-006
1.000000e-003
1.000000e-003
1.000000e-003
0.000000e+000
5.000000e-002
1.000000e-003
1.000000e+003
5.000000e-002
1.000000e+005
1.000000e-012
1.000000e-012
1.000000e+004
5.000000e+000
9.990000e-001
1.000000e-003
format(xxxx.xxxxxxE)
F1

CARDINAL+Users+Manual CEE281

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CARDINAL+Users+Manual CEE281

Uploaded by

Copyright:

Available Formats

Cardinal

Structural Reliability Software

CARDINAL USERS MANUAL

is often used in reliability analyses.

where nC is the number of cut sets identified for the system.

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

CARDINAL INPUT FILE

CEE281 Structural Reliability

CARDINAL Users Manual

# This is a comment. Note the space between the

# The closing brace is on a separate line following

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

Specify some changes to the

CEE281 Structural Reliability

CARDINAL Users Manual

# see Example B.4

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

Display the progress of the program to the analysis window.

Echo the input to the output file.

Echo the output to the output file.

Record the length of time to perform each analysis requested.

CEE281 Structural Reliability

CARDINAL Users Manual

CEE281 Structural Reliability

CARDINAL Users Manual

Mean-value, first-order, second-moment analysis.

First-order, second-moment analysis.

First-order, reliability method.

Second-order, reliability method.

Component sensitivity analyses.

Monte Carlo simulation analyses.

System reliability analyses.

Generate the empirical CDF of one or more random quantities.

Plot the PDF or CDF of a random variable.

Specifies the component to analyze.

Instructs the program to evaluate a block of program language.

Stop the analyses and terminate the program.

CEE281 Structural Reliability