text:
Version of the Day
MOOCHO (Multifunctional Object-Oriented arCHitecture for Optimization) is a Trilinos package written in C++ designed to solve large-scale, equality and inequality nonlinearly constrained, non-convex optimization problems (i.e. nonlinear programs) using reduced-space successive quadratic programming (SQP) methods. The most general form of the optimization problem that can be solved is:
where the vector of optimization variables, is the nonlinear scalar objective function, (where ) are the nonlinear constraints, and and are the upper and lower bounds on the variables. The current algorithms in MOOCHO are well suited to solving optimization problems with massive numbers of unknown variables and equations but few so-called degrees of optimization freedom (i.e. the degrees of freedom = the number of variables minus the number of equality constraints = ). Various line-search based globalization methods are available, including exact penalty functions and a form of the filter method. Many of the algorithms in MOOCHO are provably locally and globally convergent for a wide class of problems in theory but in practice the behavior and the performance of the algorithms varies greatly from problem to problem.
MOOCHO was initially developed to solve general sparse optimization problems where there is no clear distinction between state variables and optimization parameters. For these types of problems a serial sparse direct solver must be used (i.e. MA28) to find a square basis that is needed for the variable reduction decompositions that are current supported.
More recently, MOOCHO has been interfaced through Thyra
and the Thyra::ModelEvaluator
interface to address very large-scale, massively parallel, simulation-constrained optimization problems that take the form:
where are the "dependent" state variables, are the "independent" optimization parameters and are the discrete nonlinear state simulation equations. Here the state Jacobian must be square and nonsingular and the partitioning of into state variables and optimization variables must be known a priori and this partitioning can not change during a solve. Warning, the Thyra::ModelEvaluator
interface uses a overlapping and inconsistent set set of names for the variables and the problem functions than the names used by MOOCHO. All of the functionality needed for MOOCHO to solve a simulation-constrained optimization problem can be specified through sub-classing the Thyra::ModelEvaluator
interface, and related Thyra
interfaces. Epetra-based applications can instead implement the EpetraExt::ModelEvaluator
interface and never need to work with Thyra directly except in trivial and transparent ways.
For simulation-constrained optimization problems, MOOCHO can utilize the full power of the massively parallel iterative linear solvers and preconditioners available in Trilinos through Thyra through the Stratimikos
package by just flipping a few switches in a parameter list. These include all of the direct solves in Amesos, the preconditioners in Ifpack and ML, and the iterative Krylov solvers in AztecOO and Belos (Belos is not being released but is available in the development version of Trilinos). For small to moderate numbers of optimization parameters, the only bottleneck to parallel scalability is the linear solver used to solve linear systems involving the state Jacobian . The reduced-space SQP algorithms in MOOCHO itself achieve extremely good parallel scalability. The parallel scalability of the linear solvers is controlled by the simulation application and the Trilinos linear solvers and preconditioners themselves. Typically, the parallel scalability of the linear solve is limited by the preconditioner as the problem is partitioned to more and more processes.
MOOCHO also includes a minimally invasive mode for reduced-space SQP where the simulator application only needs to compute the objective and constraint functions and and solve only forward linear systems involving . All other derivatives can be approximated with directional finite differences but any exact derivatives that can be computed by the application are happily accepted and fully utilized by MOOCHO through the Thyra::ModelEvaluator
A more detailed mathematical overview of nonlinear programming and the algorithms that MOOCHO implements are described in the document A Mathematical and High-Level Overview of MOOCHO. This document also defines the mapping of mathematical notation to C++ identifiers used by MOOCHO. User's should at least browse this document in order to understand the basics of what MOOCHO is doing.
An PDF version of his doxygen collection can be found here for people who want to print this documentation out and read hard copy.
In order to get started using MOOCHO to solve your NLPs you must first build MOOCHO as part of Trilinos and install it.
Quickstart Outline
Once an NLP is defined, a driver program must be constructed to setup a MOOCHO solver and configure it given options set by the user. When building a driver program to solve an NLP based on an NLPInterfacePack::NLPSerialPreprocessExplJac
subclass object, one should directly use the "Facade" solver class MoochoPack::MoochoSolver
(see NLPWBCounterExampleMain.cpp
). However, when using an NLP based on a Thyra::ModelEvaluator
object, then the more specialized "Facade" solver class MoochoPack::MoochoThyraSolver
should be used (see NLPThyraEpetraModelEval4DOptMain.cpp
). The class MoochoPack::MoochoThyraSolver
just uses MoochoPack::MoochoSolver
internally for the main solve but provides a great deal of extra functionality to set initial guesses (also from an input file) and wrap the model evaluator object with various "Decorator" skins and to capture and return the final solution.
Once an NLP is defined and a driver program is in place (see the above driver programs), then MOOCHO can be run to try to solve the optimization problem. Most of the options that affect MOOCHO (and the Trilinos linear solvers accessed through Stratimikos) can be read in from various input files or specified entirely on the command line. The diver programs shown above show examples of how to setup a Techos::CommandLineProcessor object to accept a number of different command-line arguments that can be used to read in MOOCHO and Trilinos linear solver options. For example, consider the simple driver program NLPThyraEpetraModelEval4DOptMain.cpp
. This example shows the use of both MOOCHO options and Stratimikos linear solver options.
Here are the command-line arguments that the program NLPThyraEpetraModelEval4DOptMain.cpp
Teuchos::GlobalMPISession::GlobalMPISession(): started serial run Echoing the command-line: ../thyra/example/NLPThyraEpetraModelEval4DOpt/NLPThyraEpetraModelEval4DOpt.exe --echo-command-line --help Usage: ../thyra/example/NLPThyraEpetraModelEval4DOpt/NLPThyraEpetraModelEval4DOpt.exe [options] options: --help Prints this help message --pause-for-debugging Pauses for user input to allow attaching a debugger --echo-command-line Echo the command-line but continue as normal --linear-solver-params-file string Name of an XML file containing parameters for linear solver options to be appended first. (default: --linear-solver-params-file="") --extra-linear-solver-params string An XML string containing linear solver parameters to be appended second. (default: --extra-linear-solver-params="") --linear-solver-params-used-file string Name of an XML file that can be written with the parameter list after it has been used on completion of this program. (default: --linear-solver-params-used-file="") --moocho-options-file string Set the name of the MOOCHO options file in the OptionsFromStream format. File is ignored if it does not exist! (default: --moocho-options-file="Moocho.opt") --moocho-extra-options string Extra MOOCHO options specified in the format "OptGrp1{name1=val1,...,namen=valn}:OptGr2{name1=val1,...,namen=valn}:..." (default: --moocho-extra-options="") --moocho-thyra-params-file string Name of an XML file containing parameters for linear solver options to be appended first. (default: --moocho-thyra-params-file="") --extra-moocho-thyra-params string An XML string containing linear solver parameters to be appended second. (default: --extra-moocho-thyra-params="") --moocho-thyra-params-used-file string Name of an XML file that can be written with the parameter list after it has been used on completion of this program. (default: --moocho-thyra-params-used-file="") --xt0 double No documentation (default: --xt0=1) --xt1 double No documentation (default: --xt1=1) --pt0 double No documentation (default: --pt0=2) --pt1 double No documentation (default: --pt1=0) --d double No documentation (default: --d=10) --x00 double No documentation (default: --x00=1) --x01 double No documentation (default: --x01=1) --p00 double No documentation (default: --p00=2) --p01 double No documentation (default: --p01=0) --pL0 double No documentation (default: --pL0=-1e+50) --pL1 double No documentation (default: --pL1=-1e+50) --pU0 double No documentation (default: --pU0=1e+50) --pU1 double No documentation (default: --pU1=1e+50) --xL0 double No documentation (default: --xL0=-1e+50) --xL1 double No documentation (default: --xL1=-1e+50) --xU0 double No documentation (default: --xU0=1e+50) --xU1 double No documentation (default: --xU1=1e+50) --support-derivs bool No documentation --no-support-derivs (default: --support-derivs)
Below, the various types of input and output are described. Input parameters/options are separated into linear solver parameters for Stratimikos and algorithm options for MOOCHO.
When using a Thyra::ModelEvaluator
-based NLP, the linear solver options for inverting the basis of the equality constraints are read in through a Teuchos::ParameterList
object which is accepted through the Stratimikos class Stratimikos::DefaultLinearSolverBuilder
. When a MoochoPack::MoochoThyraSolver
object is used to build a driver program, it can add options to the Teuchos::CommandLineProcessor
object through the function Stratimikos::DefaultLinearSolverBuilder::setupCLP()
(see NLPThyraEpetraModelEval4DOptMain.cpp
). This adds the command-line arguments –linear-solver-params-file
and –extra-linear-solver-params
which are used to read in parameters for the Stratimikos-wrapped linear solvers in XML format.
The linear solver parameters file is specified in XML and the list of all of the valid options can be found in the documentation for the class Stratimikos::DefaultLinearSolverBuilder
An example of a linear solver options input file that specifies the use of the Amesos solver Amesos_Klu
is shown below:
<ParameterList> <Parameter isUsed="true" name="Linear Solver Type" type="string" value="Amesos"/> <ParameterList name="Linear Solver Types"> <ParameterList name="Amesos"> <ParameterList name="Amesos Settings"/> <Parameter name="Solver Type" type="string" value="Klu"/> </ParameterList> </ParameterList> <Parameter name="Preconditioner Type" type="string" value="None"/> </ParameterList>
The XML input for the linear solver parameters can be read from a file using the –linear-solver-params-file
argument and/or from the command-line itself using the –extra-linear-solver-params
argument. Note that any parameters specified by the –extra-linear-solver-params
argument will append and overwrite those read in from the file specified by the –linear-solver-params-file
argument. If the argument –linear-solver-params-file
is missing, then a set of internal options is looked for instead.
The input for the MOOCHO options currently uses a completely different system than for linear solver parameters used by Stratimikos. The class OptionsFromStreamPack::OptionsFromStream
is used to read in MOOCHO options from a text string (or a file) and is used to represent an options data base that is used by MOOCHO. The function MoochoPack::MoochoSolver::setup_commandline_processor()
can be used to set the command-line arguments –moocho-options-file
and –moocho-extra-options
to read in MOOCHO options. The format of the options file and a listing, with documentation, of all of the valid MOOCHO options is shown here.
An example of an options file showing some of the common options that a user might want to set is shown below:
begin_options options_group NLPSolverClientInterface { max_iter = 20; max_run_time = 2.0; *** In minutes opt_tol = 1e-2; feas_tol = 1e-7; * journal_output_level = PRINT_NOTHING; * No output to journal from algorithm * journal_output_level = PRINT_BASIC_ALGORITHM_INFO; * O(1) information usually journal_output_level = PRINT_ALGORITHM_STEPS; * O(iter) output to journal [default] * journal_output_level = PRINT_ACTIVE_SET; * O(iter*nact) output to journal * journal_output_level = PRINT_VECTORS; * O(iter*n) output to journal (lots!) * journal_output_level = PRINT_ITERATION_QUANTITIES; * O(iter*n*m) output to journal (big lots!) * null_space_journal_output_level = DEFAULT; * Set to journal_output_level [default] * null_space_journal_output_level = PRINT_ACTIVE_SET; * O(iter*nact) output to journal * null_space_journal_output_level = PRINT_VECTORS; * O(iter*(n-m)) output to journal (lots!) null_space_journal_output_level = PRINT_ITERATION_QUANTITIES; * O(iter*(n-m)^2) output to journal (big lots!) journal_print_digits = 10; calc_conditioning = true; calc_matrix_norms = true; *** (costly?) calc_matrix_info_null_space_only = true; *** (costly?) } options_group DecompositionSystemStateStepBuilderStd { * null_space_matrix = AUTO; *** Let the solver decide [default] null_space_matrix = EXPLICIT; *** Compute and store D = -inv(C)*N explicitly * null_space_matrix = IMPLICIT; *** Perform operations implicitly with C, N (requires adjoints) * range_space_matrix = AUTO; *** Let the algorithm decide dynamically [default] * range_space_matrix = COORDINATE; *** Y = [ I; 0 ] (Cheaper computationally) range_space_matrix = ORTHOGONAL; *** Y = [ I; -N'*inv(C') ] (more stable) } options_group NLPAlgoConfigMamaJama { * quasi_newton = AUTO; *** Let solver decide dynamically [default] quasi_newton = BFGS; *** Dense BFGS * quasi_newton = LBFGS; *** Limited memory BFGS * line_search_method = AUTO; *** Let the solver decide dynamically [default] * line_search_method = NONE; *** Take full steps at every iteration * line_search_method = DIRECT; *** Use standard Armijo backtracking line_search_method = FILTER; *** [default] Use the Filter line search method } end_options
For more detailed documentation on what each of these options mean and more, see the full listing of the options here.
The command-line argument –moocho-options-file
is used to read in an set of MOOCHO options from a file using the format shown above. If the argument –moocho-options-file
is missing, then a file with the name "Moocho.opt" is looked for in the current directory. If this file is not found, then a warning is printed and a default set of options are used. The user is warned to check that their opinions file was actually read and that it will be ignored if it is not found!
The argument –moocho-extra-options
can be used to specify MOOCHO options directly on the command line in a slightly more terse format than the format of a MOOCHO options file. For example, the command-line equivalent to a subset of the options set in the above example MOOCHO options file is:
--moocho-extra-options="\ NLPSolverClientInterface{max_iter=20,max_run_time=2.0,opt_tol=1e-2,feas_tol=1e-7\ ,journal_output_level= PRINT_ALGORITHM_STEPS\ ,null_space_journal_output_level=PRINT_ITERATION_QUANTITIES\ ,journal_print_digits=10,calc_conditioning=true,calc_matrix_norms=true\ ,calc_matrix_info_null_space_only=true}\ :DecompositionSystemStateStepBuilderStd{\ null_space_matrix=EXPLICIT,range_space_matrix=ORTHOGONAL}\ :NLPAlgoConfigMamaJama{quasi_newton=BFGS,line_search_method=FILTER}"
The options specified in the –moocho-extra-options
argument will append and override those read in from a MOOCHO input file specified by the –moocho-options-file
When a MOOCHO optimization algorithm is run, by default, several different types of output are generated. By default, output is sent to the console (i.e. standard out) and to three different files: MoochoSummary.out
, MoochoAlgo.out
, and MoochoJournal.out
. These four output streams provide different types of information about the MOOCHO algorithm.
To demonstrate the output files, here we show example output generated by the example program NLPThyraEpetraModelEval4DOptMain.cpp
. This example is used since it is fairly simple but can be used to generate more interesting output files. The output from running MOOCHO on a Thyra::ModelEvaluator
-based NLP looks very similar to running on one based on the more general NLP interface.
The example program NLPThyraEpetraModelEval4DOpt.exe
when run with the command-line arguments:
--echo-command-line --nD=3000 --bw=10 --diag-scal=1e+3 --nI=5 --xIl=1e-5 --xo=0.1
with the above sample Moocho.opt
options file, creates the output:
Each of these different types of output are described below and the major types of output that are included in each output stream are discussed. The purpose of this treatment is to familiarize the user with the contents of these outputs and to give hints of where to look for a certain types of information.
Before going into the details of each individual type of output, first a few general comments are in order. First, at the top of every output file (except for the console output) a header is included that briefly describes the general purpose of the output file. This header is followed by an echo of the options that where read into the OptionsFromStreamPack::OptionsFromSteam
object. These options include those set in the input file Moocho.opt
or by some other means (e.g.~in the executable or on the command line) as described above. The purpose of echoing the options in each file is to help record what setting were used to produce the output in the file. Of course the output is also influenced by other factors (e.g. other command-line options, properties of the specific NLP being solved etc.) and therefore these options do not determine the complete behavior of the software.
Console Output (output) Console outputting is generated by a default IterationPack::AlgorithmTracker
subclass subclass object of type MoochoPack::MoochoTrackerConsoleStd
. This output is designed to approximately fit in an 80 character wide console. Here is the output that is generated for this example program:
Teuchos::GlobalMPISession::GlobalMPISession(): started serial run Echoing the command-line: ../example/ExampleNLPBanded/ExampleNLPBanded.exe --moocho-options-file=../example/Moocho.sample.opt --echo-command-line --nD=3000 --bw=10 --diag-scal=1e+3 --nI=5 --xIl=1e-5 --xo=0.1 ***************************** *** MoochoSolver::solve() *** ***************************** test_nlp = true: Testing the NLP! ... Testing the supported NLPFirstOrder interface ... Successful end of testing of the nlp ******************************** *** Start of rSQP Iterations *** n = 3005, m = 3000, nz = 59910 k f ||c||s ||rGL||s QN #act ||Ypy||2 ||Zpz||2 ||d||inf alpha time(sec) ---- --------- --------- --------- -- ---- -------- -------- -------- -------- --------- 0 15 1.2e+02 9.8 IN 0 1 1e+02 1e+01 0.06 0.631657 1 2.2 70 0.21 UP 0 1 0.06 0.3 1 1.217418 2 0.62 16 0.28 SK 0 0.4 0.06 0.07 1 1.802403 3 0.39 1.3 0.28 SK 0 0.04 0.05 0.02 1 2.388064 4 0.34 0.045 0.27 DU 0 0.001 0.2 0.1 1 2.973937 5 0.17 0.0062 0.2 UP 1 0.0002 0.6 0.3 1 3.564072 6 4.3e-09 0.0016 2.4e-05 UP 4 9e-05 4e-06 3e-06 1 4.150871 ---- --------- --------- --------- -- ---- 7 3.1e-10 7.9e-09 1.5e-05 UP 4 3e-10 2e-06 2e-06 - 4.73415 Total time = 4.7342 sec Jackpot! You have found the solution!!!!!! Number of function evaluations: ------------------------------- f(x) : 18 c(x) : 18 Gf(x) : 9 Gc(x) : 9 Solution Found!
Above, one of the the first things printed is the size of the NLP where n
is the total number of variables, m
is the total number of equality constraints and nz
is the number of nonzeros in the Jacobian (Gc
). Note that for a simulation-constrained optimization problem that nz
will not give any useful information since this is not available through the Thyra interfaces.
Following the global dimensions of the problem, a table containing summary information for each rSQP iteration is printed in real time. Each column in this table has the following meaning:
: The SQP iteration counter. This count starts from zero so the total number of SQP iterations is one plus the final k
: The value of the objective function (possibly scaled) at current estimate of the solution
: The scaled residual of the norm of the equality constraints at current estimate of the solution . The scaling is determined by the convergence check (see the step "CheckConvergence" in MoochoAlgo.out and MoochoJournal.out) and this value is actually equal to the iteration quantity feas_kkt_err
(see the file MoochoAlgo.out). This is the error that is compared to the tolerance feas_tol
in the convergence check (which is equal to the option NLPSolverClientInterface{feas_tol}
). The unscaled constraint norm can be viewed in the more detailed iteration summary table printed in the file MoochoSummary.out.
: The scaled norm of the reduced gradient of the Lagrangian at current estimate of the solution . The scaling is determined by the convergence check (see the step "CheckConvergence" in MoochoAlgo.out and MoochoJournal.out) and this value is actually equal to the iteration quantity opt_kkt_err
(see the file MoochoAlgo.out). This is the error that is compared to the tolerance opt_tol
in the convergence check (which is equal to the option NLPSolverClientInterface{opt_tol}
). The unscaled norm can be viewed in the more detailed summary table printed in the file MoochoSummary.out.
: This field indicates whether a quasi-Newton update of the reduced Hessian was performed or not. The following are the possible values:
: Reinitialized (usually to identity ) DU
: A dampened update was performed UP
: An undamped update was performed SK
: The update was skipped on purpose IS
: The update was skipped because it was indefinite #act
: Number of active constraints in the QP subproblem. This field only has meaning for an active-set algorithms. For interior-point algorithms, this will just equal the number of bounded variables and does not provide any useful information. For problems without any bounds or inequality constraints, this column is not shown.
: The norm of the quasi-normal contribution . This norm gives a sense of how large the feasibility steps are.
: The norm of the tangential contribution . This norm gives a sense of how large the optimality steps are.
: The norm of the total step . This norm gives a sense of how large the full SQP steps are in .
: The step length taken along . A step length of represents a major event in the algorithm such as a line search failure followed by the selection of a new basis or a QP failure followed by a reinitialization of the reduced Hessian. A small number for indicates that many backtracking line search iterations where required and is an indication that the computed search direction is of poor quality. A value of alpha=1.0
usually indicates that the algorithm is taking full spaces and may be performing well.
: The total wall-clock time consumed by the algorithm to that point. By differencing the times between iterations, one can compute the amount of time taken for each iteration. See the more detailed timing output in the file MoochoSummary.out.
After the iteration summary is printed, the total wall-clock time is given in Total time
. This is the wall-clock time that is consumed from the time that the MoochoPack::MoochoTrackerConsoleStd
object is first initialized up until the time that the final state of the algorithm is reported. Therefore, this wall-clock time may contain more than just the execution time of the algorithm proper. For more detailed built-in timings, see the table at the end of the file MoochoSummary.out.
Following the total runtime, the total number of function and gradient evaluations is given for the objective and the constraints. Note that if finite difference testing is turned on, then many extra evaluations will be performed and this will inflate these counters.
Algorithm Configuration Output (MoochoAlgo.out) In addition to output the console, MOOCHO will also write a file called MoochoAlgo.out by default that gives information about what MOOCHO algorithm is configured and what logic went into its configuration. This file is too long to be shown here. This file provides the road map for determining what iteration quantities are being used by the algorithm, what the algorithmic steps are, and what the logic of the algorithm is using a shorthand, Matlab-like, notation. This file is the first place to go when trying to figure out what a MOOCHO algorithm is doing and is critical to understand the MoochoJournal.out file.
Many of the options specified in the options file are shown in the printed algorithm. The user can therefore study the algorithm printout to see what effect some of the options have. For example, the option NLPSolverClientInterface{opt_tol}
is used in the Step "CheckConvergence" under the name opt_tol
in the files MoochoAlgo.out and MoochoJournal.out. Some of the options only determine the algorithm configuration, which affects what steps are included, how steps are set up and in what order they are included. These option names are not specifically shown in the algorithm printout per-say. For example, the option NLPAlgo_ConfigMamaJama{max_dof_quasi_newton_dense}
determines when the algorithm configuration will switch from using dense BFGS to using limited-memory BFGS but this identifier name max_dof_quasi_newton_dense
is not shown anywhere in the listing. However, the configuration object can print out a short log (to the MoochoAlgo.out
file) to show the user how these options impact the configuration of the algorithm.
Algorithm Summary and Timing Output (MoochoSummary.out) The file MoochoSummary.out contains a more detailed summary table than what is sent to the console, a table of the timings for each algorithm step for each iteration, and some limited profiling-type output (produced by Teuchos::TimeMonitor
Algorithm Journal Output (MoochoJournal.out) The file MoochoJournal.out contains more detailed, iteration by iteration, step by step information on what the algorithm is doing. The steps shown in this output are the same that are shown in the pseudo algorithm description shown in the file MoochoAlgo.out described above. The amount of output produced in this file is mainly controlled by the option NLPSolverClientInterface{journal_output_level}
and the value of PRINT_ALGORITHM_STEPS
is usually the most appropriated in most cases and prints only output, where is the SQP iteration counter. The value of ITERATION_QUANTITIES
will produce obscene amounts of debugging output and will dump nearly every vector and every matrix used in the algorithm. There are many options in the Moocho.opt options file that control exactly what type of output is generated to meet different needs. Note that the option NLPSolverClientInterface{null_space_journal_output_level}
will override NLPSolverClientInterface{journal_output_level}
for quantities that lie in the null space. This is helpful for seeing the progress of the algorithm where there are few degrees of optimization freedom.
All MOOCHO algorithms can be interrupted at any time while the algorithm is running and result in a graceful termination, even for parallel runs with MPI. When running in interactive mode (i.e. the user has access to standard in and standard out at the console) then typing Ctrl-C
will cause the algorithm to pause at the end of the current algorithm step and menu like the following will appear:
IterationPack::Algorithm::interrupt(): Received signal SIGINT. Wait for the end of the current step and respond to an interactive query, kill the process by sending another signal (i.e. SIGKILL). IterationPack::Algorithm: Received signal SIGINT. Just completed current step curr_step_name = "EvalNewPoint", curr_step_poss = 1 of steps [1...9]. Do you want to: (a) Abort the program immediately? (c) Continue with the algorithm? (s) Gracefully terminate the algorithm at the end of this step? (i) Gracefully terminate the algorithm at the end of this iteration? Answer a, c, s or i ?
To terminate the algorithm gracefully at the end of the current step, type 's
', which brings up the next question:
Terminate the algorithm with true (t) or false (f) ?
Answering false ('f
'), which is interpreted as failure, results in the algorithm exiting immediately with the partial solution being returned to the NLP object and everything being cleaned up correctly on exit. The full output from this type of interrupt looks something like:
******************************** *** Start of rSQP Iterations *** n = 1331, m = 1111, nz = 1478741 k f ||c||s ||rGL||s QN ||Ypy||2 ||Zpz||2 ||d||inf alpha time(s) ---- --------- --------- --------- -- -------- -------- -------- -------- --------- 0 2.1 0.11 0.095 IN 1e+001 7 5 1 1.152 1 4.3 0.00025 0.27 UP 0.1 2 0.1 1 2.294 2 4.1 8.5e-006 0.25 DU 0.007 3 0.3 1 3.405 IterationPack::Algorithm::interrupt(): Received signal SIGINT. Wait for the end of the current step and respond to an interactive query, kill the process by sending another signal (i.e. SIGKILL). IterationPack::Algorithm: Received signal SIGINT. Just completed current step curr_step_name = "EvalNewPoint", curr_step_poss = 1 of steps [1...9]. Do you want to: (a) Abort the program immediately? (c) Continue with the algorithm? (s) Gracefully terminate the algorithm at the end of this step? (i) Gracefully terminate the algorithm at the end of this iteration? Answer a, c, s or i ? s Terminate the algorithm with true (t) or false (f) ? f ---- --------- --------- --------- -- 3 3.4 - - - - - - - 7.762 Total time = 7.762 sec Oops! Not the solution. The user terminated the algorithm and said to return non-optimal! Number of function evaluations: ------------------------------- f(x) : 10 c(x) : 10 Gf(x) : 5 Gc(x) : 5 Some algorithmic error occurred!
A MOOCHO algorithm can also be interrupted without access to standard in or standard out (i.e. when running in batch mode) by setting up an interrupt file. When the interrupt file is found, the algorithm is terminated. MOOCHO must be told to look for an interrupt file by setting the option IterationPack_Algorithm{interrupt_file_name="interrupt.in"}
where any file name can be substituted for the name "interrupt.in"
. At the end of each algorithm step, MOOCHO will look for the file "interrupt.in"
, usually in its current working directory (or an absolute path can be specified as well). If it finds the file it will read it for termination instructions. For example, a interruption file that contains
i f
will result in the algorithm terminating at the end of the current iteration with the condition 'false
', which means failure. The output generated from this type of interrupt looks something like:
******************************** *** Start of rSQP Iterations *** n = 1331, m = 1111, nz = 1478741 k f ||c||s ||rGL||s QN ||Ypy||2 ||Zpz||2 ||d||inf alpha time(s) ---- --------- --------- --------- -- -------- -------- -------- -------- --------- 0 2.1 0.11 0.095 IN 1e+001 7 5 1 1.161 1 4.3 0.00025 0.27 UP 0.1 2 0.1 1 2.293 2 4.1 8.5e-006 0.25 DU 0.007 3 0.3 1 3.455 IterationPack::Algorithm: Found the interrupt file "interrupt.in"! Just completed current step curr_step_name = "EvalNewPoint", curr_step_poss = 1 of steps [1...9]. Read a value of abort_mode = 'i': Will abort the program gracefully at the end of this iteration! Read a value of terminate_bool = 'f': Will return a failure flag! 3 3.4 1.6e-005 0.23 DU 0.006 7 2 1 4.616 ---- --------- --------- --------- -- 3 3.4 1.6e-005 0.23 DU 0.006 7 2 1 4.626 Total time = 4.626 sec Oops! Not the solution. The user terminated the algorithm and said to return non-optimal! Number of function evaluations: ------------------------------- f(x) : 11 c(x) : 11 Gf(x) : 5 Gc(x) : 5 Some algorithmic error occurred!
Currently when an algorithm is interrupted and terminated, only the current status of the solution variables are returned to the NLP (i.e. through the Thyra::ModelEvaluator::reportFinalPoint()
callback function) and no internal check-pointing is performed. Therefore, a user should not expect to be able to restart an interrupted algorithm and have it behave the same as if it was never interrupted. MOOCHO currently does not support general check-pointing and restarting but this is a feature that is on the wish list for MOOCHO for an upcoming release.
This brings the MOOCHO quickstart to a conclusion. The remaining sections provide more detailed information on topics mentioned in the above quickstart.
In order to utilize the most powerful rSQP algorithms in MOOCHO the NLP subclass must support the NLPInterfacePack::NLP
, NLPInterfacePack::NLPFirstOrder
, and NLPInterfacePack::NLPVarReductPerm
interfaces and must supply an object that supports the AbstractLinAlgPack::BasisSystem
and AbstractLinAlgPack::BasisSystemPerm
interfaces. The details of these interfaces are really not the concern of a general user who just wants to solve an NLP. Therefore, here we will only discuss some of the basic issues associated with these interfaces and what adapter-support subclasses are available to help implement the needed functionality.
As described above in the quickstart, there are two well supported tracts to developing concrete NLP subclasses to be used with MOOCHO. Each of these tracts provides support software that allow the user to provide only the most basic types of information needed to define the NLP. The first type of NLPs that are supported are general NLPs with explicit derivative components and these NLPs can only be solved in serial. This first type requires a direct linear solver that can be used to select a basis matrix. The second type are simulation-constrained NLPs that can be solved on massively parallel computers by utilizing preconditioned iterative linear solvers. This type of NLP is supported through the Thyra::ModelEvaluator
interface and can utilize much of the linear solver capability in Trilinos. The key difference in this second type of NLP is that the application must know a priori what the selection of state (or dependent) variables is in order to obtain a square and well conditioned basis matrix.
These two approaches to defining NLPs are described in the next two sections Representing General Serial NLPs with Explicit Jacobian Entries and Representing Simulation-Constrained Parallel NLPs through Thyra.
One type of NLP that MOOCHO can solve are general NLPs where explicit gradient and Jacobian entries are available. This means that the gradient of the objective function must be available in vector coefficient form and the gradient of the constraints matrix (i.e. the rectangular Jacobian ) must be available in sparse matrix form. In this type of problem, a basis matrix for the constraints need not be known a priori but this requires the availability of a linear direct solver that can be used to find a square nonsingular basis from a rectangular matrix. There are a few direct solvers available that could in principle find a square basis given a rectangular input matrix but MOOCHO only currently contains wrappers for LAPACK (i.e. dense factorization using DEGETRF(...)
) and the Harwell Subroutine Library (HSL) routine MA28. The MA28 routine is the only viable option currently supported for handling large sparse linear systems. In the past, other direct solvers have been experimented with and an ambitious user can provide support for any direct solver they would like (with the ability to find a square basis) by providing an implementation of the AbstractLinAlgPack::DirectSparseSolver
interface. If your NLP can also provide explicit objective function gradients, then your concrete subclass should derive from the NLPInterfacePack::NLPSerialPreprocessExplJac
subclass. More details are given below.
The first utility base subclass for general serial (i.e. runs in a single process or perhaps on an SMP) NLPs is NLPInterfacePack::NLPSerialPreprocess
. This utility class derives from the NLPInterfacePack::NLP
, NLPInterfacePack::NLPObjGrad
, and NLPInterfacePack::NLPVarReductPerm
interfaces and takes care of a lot of details like preprocessing out fixed variables, converting general inequality constraints to equalities by the addition of slack variables and maintaining the current basis permutations. All of this is done to transform the "original" NLP into standard form. The "original" NLP can include general inequality constraints in addition to general equality constraints. The "original" NLP, however, can also includes fixed variables (i.e. ). There are several different intermediate forms of the NLP that a NLPSerialPreprocess
object maintains in the transformation from the ``original'' NLP to the final form. The first type of transformation is the addition of slack variables to convert the general inequality constraints into an extra set of equality constraints. This is called the "full" form of the NLP. The second type transformation is the removal of fixed variables which are preprocessed out of the problem but leaving the general inequalities intact which some parts of a MOOCHO algorithm may access (e.g. globalization steps) through the NLP
interface. The last type of transformation is the permutation of the variables and the constraints according to the current basis selection. All of this functionality is very useful and this makes the NLPSerialPreprocess
subclass the place to start when going to implement any type of serial NLP to be used with an rSQP algorithm. Note that this subclass does not address the structure or handling of the Jacobian or Hessian matrices in any way. The handling of these matrices is deferred to subclasses to define.
While it may seem that the details of the transformations performed by NLPInterfacePack::NLPSerialPreprocess
are of no concern to end users, this is not always the case. For example, a user must understand how their original NLP is transformed in order to understand the output printed in the MoochoJournal.out file when the journal output level NLPSolverClientInterface{journal_print_level}
is set to a value equal to or higher than PRINT_VECTORS
Subclasses that wish to use a generic sparse data structure for the Jacobian matrix and a generic sparse direct linear solver to select, factor and solve linear systems with the basis matrix should derive from the NLPInterfacePack::NLPSerialPreprocessExplJac
subclass (which itself derives from NLPSerialPreprocess
). This subclass performs all of the same types of transformations as its NLPSerialPreprocess
base class (i.e. removal of entries for fixed variables, addition of slack variables and basis permutations) with the explicit Jacobian entries that are supplied by the concrete NLP subclass. The concrete implementations of both the Jacobian matrix subclass for Gc
and the BasisSystem
subclass can be overridden by the client but yet have good default implementations. The default implementation for the matrix class for Gc
is AbstractLinAlgPack::MatrixSparseCOORSerial
(which uses a coordinate sparse matrix format). The implementation of the AbstractLinAlgPack::BasisSystem
object is handled through a subclass of AbstractLinAlgPack::BasisSystemFactory
called AbstractLinAlgPack::BasisSystemFactoryStd
The AbstractLinAlgPack::BasisSystemFactoryStd
subclass can create AbstractLinAlgPack::BasisSystem
objects implemented through several different direct linear solvers. Currently, only the solvers LAPACK
(for small, dense Jacobians)and MA28 (for large, sparse systems) are currently supported (see the options group BasisSystemFactoryStd
to select what solver to use manually). Note that MOOCHO must be configured with MOOCHO_ENABLE_MA28
to support the MA28 solver.
Warning! This NLP adapter-support software is going to most likely change in a major way before the next major release of Trilinos. Therefore, it is recommended that, if possible, users derive their NLPs from the Thyra-based simulation-constrained interfaces described in the next section Representing Simulation-Constrained Parallel NLPs through Thyra. However, this set of software is the only currently supported way to solve certain types of general NLPs and therefore remains for the time being.
See examples above in the section moocho_explicit_nlps_examples_sec.
Another type of NLP that can be solved using MOOCHO are simulation-constrained NLPs where the basis section is known up front. For these types of NLPs, it is recommended that the NLP be specified through the Thyra::ModelEvaluator
interface and this provides access to a significant linear solver capability through Trilinos. These types of NLPs can also be solved in single program multiple data (SPMD) mode in parallel on a massively parallel computer.
The Thyra::ModelEvaluator
interface uses a different notation than the standard MOOCHO NLP notation. The model evaluator notation is:
where are the state variables, are the optimization parameters, are the discrete nonlinear state simulation equations, and is the scalar-valued objective function. Here the state Jacobian must be square and nonsingular. The partitioning of variables into state variables and optimization variables must be known a priori and this partitioning can not change during an optimization solve.
Comparing the MOOCHO notation for optimization problems using variable decomposition methods which is
we can see the mapping between the MOOCHO notation and the Thyra::ModelEvaluator
notation as summarized in the following table:
MOOCHO Notation | Thyra::ModelEvaluator Notation |
Number of state variables | ||
Number of optimization parameters | ||
Total number of optimization variables | ||
State variables | ||
Optimization parameters | ||
State equation residual function | ||
Objective function | ||
Nonsingular state Jacobian | ||
Optimization Jacobian | ||
Derivative of objective with respect to state variables | ||
Derivative of objective with respect to optimization parameters |
It is unfortunate that the notation used with the Model Evaluator interfaces and software are different than those used by MOOCHO. The reason for this change in notation is that the Model Evaluator had to first appeal to the forward solve community where is the standard notation for the parameterized state equation and changing the notation of all of MOOCHO after the fact to match this would be very tedious to perform. We can only hope that the user can keep the above mapping of notation straight between MOOCHO and the Model Evaluator.
Currently, and more so in the near future, a great deal of capability will be automatically available when a user provides an implementation of the EpetraExt::ModelEvaluator
interface (as shown in the section moocho_simulation_constrained_nlps_examples_sec). For these types of NLPs, a great deal of linear solver capability is available through the linear solver and preconditioners wrappers in the Stratimikos package. In addition, the application will also have access to many other nonlinear algorithms provided in Trilinos (see the Trilinos packages NOX, LOCA, and Rythmos).
See examples above in the section moocho_simulation_constrained_nlps_examples_sec.
MOOCHO has direct dependencies on the following Trilinos packages:
teuchos: This package supplies basic utility classes such as Teuchos::RCP
and Teuchos::BLAS
that MOOCHO software is dependent on.
rtop: This package supplies the basic interfaces for vector reduction/transformation operators as well as support code and a library of pre-written RTOp subclasses. Much of the software in MOOCHO depends on this code.
MOOCHO also optionally directly depends on the following Trilinos packages:
thyra: This package supplies interfaces and support software for SPMD and other types of computing platforms and defines the interface Thyra::ModelEvaluator
for simulation-constrained optimization that MOOCHO can use to define NLPs.
epetraext: This package provides an Epetra-specific interface for the model evaluator called EpetraExt::ModelEvaluator
and contains some concrete examples that are used by MOOCHO.
stratimikos: This package supplies Thyra-based wrappers for several serial direct and massively parallel iterative linear solvers and preconditioners.
Below are links to individual doxygen collections that make up MOOCHO:
MoochoUtilities: Collection of a small amount of utility code that is peculiar to MOOCHO. Some of the software that is now in Teuchos
such as Teuchos::RCP
and Teuchos::CommandLineProcessor
were once in this collection.
IterationPack: "Framework" for building iterative algorithms that MOOCHO is based on.
RTOpPack: Legacy RTOp code that predates Thyra the Trilinos RTOp package but it still used by MOOCHO. The current version of the Trilinos RTOp
package was developed from refactored code that once lived in this collection.
DenseLinAlgPack: A C++ class library for dense, BLAS-compatible, serial linear algebra that is similar to classes like Teuchos::SerialDenseVector
and Teuchos::SerialDenseMatrix
. This class library is used exclusively by MOOCHO to deal with serial dense linear algebra.
AbstractLinAlgPack: A C++ class library for abstract linear algebra. These interfaces predate and helped to inspire Thyra but at this point should be considered legacy software that should only be used within MOOCHO. It is likely that a future refactoring of MOOCHO will involve largely removing these classes and using Thyra-based software directly instead.
NLPInterfacePack: Set of abstract interfaces based on AbstractLinAlgPack
for representing nonlinear programs (NLPs) (i.e. optimization problems). These interfaces serve a similar role as the Thyra::ModelEvaluator
interface but there are many differences. In the future, it is likely that these interfaces will be refactored to look more like the Thyra::ModelEvaluator
interface but are likely to remain distinct.
ConstrainedOptPack: Collection of utility software for building constrained optimization algorithms that is based on AbstractLinAlgPack
. Included here are interfaces and adapters for QP solvers (with QPSchur
being included by default), line search interfaces and implementations, range/null space decompositions and other such capabilities.
MoochoPack: Provides nonlinear optimization algorithms for primarily rSQP methods based on the IterationPack
framework. This is where the real algorithmic meat of nonlinear programing is found in MOOCHO. This collection provides the "Facade" class MoochoPack::MoochoSolver
MOOCHO/Thyra Adapters: Provides adapter classes for allowing MOOCHO to solve simulation-constrained optimization problems presented as Thyra::ModelEvaluator
objects. Also included is the higher-level "Facade" class MoochoPack::MoochoThyraSolver
You can browse all of MOOCHO as a single doxygen collection. Warning, this is not the recommended way to learn about MOOCHO software. However, this is a good way to browse the directory structure of MOOCHO, to locate files, etc.
Thyra: This package defines basic interfaces and support software for abstract numerical algorithms.
Thyra ANA Operator/Vector Adapters for Epetra: This software includes the basic adapters needed to wrap Epetra objects and Thyra objects.
Various Thyra Adapters for EpetraExt: Included here are adapters and interfaces that allow a perspective nonlinear application to specify everything needed to define a wide range of nonlinear problems in terms by subclassing an Epetra-based version of the Thyra::ModelEvaluator
interface (called EpetraExt::ModelEvaluator
). This software allows an appropriately defined Epetra-based model to be used to define a Thyra-based model to be used to define an optimization problem that MOOCHO can then solve.
Stratimikos: Unified Wrappers for Thyra Linear Solver and Preconditioner Capabilities: Stratimikos contains neatly packaged access to all of the Thyra linear solver and preconditioner wrappers. Currently, these allow the creation of linear solvers for nearly any Epetra_RowMatrix


text:
Gomer takes a stab in the stars as to who the next Robot Master would be in the weakness order! Is he right? And can he handle all the gravity screwing?
Intro music: "A New Beginning" by CarbyHydroM
- https://www.youtube.com/watch?v=X0xdf8hk8Q0
Want to play the game? Grab it here:
- https://www.facebook.com/MegamanROTF/
Ending slate music: "Glitchy G Funk Summer" by teknoaxe
- https://www.youtube.com/watch?v=IdZ12hFw_Ho
SPECIAL THANKS to all our wonderful Patreon supporters!
Elizabeth Cody
David A. Scott, Jr.
Timothy Sheridan
Ricky Temple
Check out Invest With Beth!
- https://itunes.apple.com/us/podcast/invest-with-beth-podcast/id1103366249?mt=2
If you want to become a Patreon supporter and help support videos like this, head to: http://www.patreon.com/gomer21xx
Twitter/Tumblr: gomer21xx
Facebook: https://www.facebook.com/gomerrantingthespian
Check out Becky's webcomic, Otherworldly: http://otherworldly-comics.cfw.me/
Becky's Website: http://becky-hopkins.com
Becky's Patreon: http://www.patreon.com/beckyhop
Becky's Society6 store: https://society6.com/beckyhop

subset: commoncrawl


text:
Advocate.com correspondent Job Brother takes a look at Starwood Hotels' newest property on Kauai and some of the resort group's recently remodeled gems on Oahu.
July 02 2008 12:00 AM EST
November 17 2015 5:28 AM EST
By continuing to use our site, you agree to our Private Policy and Terms of Use.
Advocate.com correspondent Job Brother takes a look at Starwood Hotels' newest property on Kauai and some of the resort group's recently remodeled gems on Oahu.
Like many people who call Los Angeles home, I am accustomed to a certain lifestyle: long hours at a day job to cover a rent that rivals the national debt, freelance gigs that dominate my "time off," traffic that turns an errand to buy some milk and eggs into a daylong road trip, and breathing air that can not only be seen but sometimes even tasted.
It's difficult to leave such a glamorous life behind, but when I was offered a chance to visit the Hawaiian Islands and check out some of the posh vacation destinations offered by Starwood Hotels & Resorts, I bravely accepted.
I packed a few essentials -- swim trunks, my iPod, and my boyfriend -- and boarded a flight for Honolulu. Having been raised on the island of Oahu, it felt curious to return as one of the many tourists I used to poke fun at. I made a mental checklist of the things I wouldn't do, such as wearing my camera like a necklace or overusing the word mahalo.
My first destination was the W Honolulu Diamond Head (2885 Kalakaua Ave., Honolulu; 808-922-1700). The hotel was unassuming -- so much so that we missed it on our initial drive down Kalakaua Avenue, sending us back around the circumference of the neighboring Kapiolani Park.
We were in a corner suite, which gave us a beautiful view of the inactive volcano of Diamond Head and a view of the ocean that was partially obstructed by larger hotels next door. The suite had lanai -- or patio -- appointments on two sides, which promoted a delicious breeze. (Be careful with your food, however -- lunching on the lanai led to a Hitchcockian experience of birds muscling in.) Our room's decor was an uninspired mix of Polynesian wood furnishings amid white backdrops. All in all it was not up to the standard of urban cool that the W is famous for, a fact spokespeople seemed aware of as they showed us what the redesigned rooms would soon look like: Cobalt blue predominated over polished white furniture, while intricately designed sliding-glass fixtures maximized use of the small space. White netting resembled a sail over a bed, while a chair featured a blue woven back meant to resemble deep-water vegetation. It was a decidedly W postmodern vision of an undersea lounge.
The hotel does provide comfortable beach chairs and towels at the front desk, but unfortunately, the nearest beach is mostly waveless and located next to the historic but dilapidated Waikiki War Memorial Natatorium, a swimming pool built by the military that is now a depressing visage, in such disrepair that people may no longer enter it.
Rumor has it that the W hosts some swinging nightlife as well, but having escaped from hipster Los Angeles ourselves, we opted out of experiencing it.
Instead we enjoyed our first dinner at the Moana Surfrider Resort on Waikiki Beach (2365 Kalakaua Ave., Honolulu; 808-922-3111). First opened in 1901 and having undergone a $50 million restoration in the late '80s, the hotel is a gorgeous example of beaux arts architecture, easily evoking a feeling of Old World glamour. Its restaurant, Beach House, is a joy to behold, with both patio and indoor seating offering panoramic views of the ocean. But the real joy lies in the food. Our waitress bragged that the steaks are so good we wouldn't need the accompanying sauce, and it was true. Her knowledge and enthusiasm made her a welcome guide as we navigated the menu. Ultimately, we ordered diver scallop potato cakes with kula citrus-herb butter, and filet mignon seasoned with alaea salt blend and served with citrus bearnaise and cabernet jus. We also drank the first of what would be many pina coladas on our vacation, eventually judging each establishment on their preparation of this cocktail. The scallop potato cakes were rich without being oily; the potato flavor practically vanished and complimented the texture of the dish while allowing for the taste of scallop to predominate. The filet mignon, very rare, as I ordered it, was so tender it was like pudding, and boldly salty. Despite our waitress's boast, I used the bearnaise sauce, which added a flavor of melted savory pastry -- my eyes rolled back in my head.
The next day we moved into the Sheraton Waikiki (2255 Kalakaua Ave., Honolulu; 808-922-4422). The expansive lobby bustled with families, shops, a virtual-surfing game -- all of which made for a discombobulating Vegas-style vibe. We were later informed the hotel was originally designed to reflect exactly that.
Our room was on the top floor of the 30-story hotel. It was small, mostly white, and minimal in decor. It offered a flat-screen TV with terrible reception. Oddly, the restroom had shutters that opened across a bar-like top, as though the designers thought you might want to prepare and serve martinis as you brushed your teeth. The best features of the room came from outside: a god's eye view of the Pacific and the lulling sound of waves. At night, the poolside floor show sent echoes of Hawaiian music and applause up to our room; I found it cheerily atmospheric, but it annoyed my boyfriend.
The hotel had a tiny adjacent beach that was packed with families. When requesting towels for the beach we were given small bath towels. We indicated we wanted the larger towels that were also available, but the brusque employee informed us those were "actually called chair covers" and were not allowed outside the pool area (a mere 10 yards from the beach), so we settled for six small towels between us.
The highlight of this hotel was its tapas bar, Rum Fire, which boasts the largest selection of vintage rum in the United States. The decor was swanky and urban and, we learned, an intentional departure from Polynesian aesthetics; apparently its operators hoped to distinguish it as "happening." From the perspective of two people from Los Angeles specifically hoping to discover the islands' unique style, this approach was a miss, because the bar looked like one more citified, hipster hop -- not bad, per se, just not what we flew in for.
We were given a crash course in rum varieties and did some taste testing, all of which was fun and illuminating. Of all the drinks we tried -- and there were many -- our favorite was something called the "deconstructed pina colada": Cruzan single-barrel rum and pineapple juice, topped with coconut foam and sprinkled with li hing mui (salted dried plum, a candy originally from Vietnam that's a favorite on the islands and a cherished childhood memory of mine, though when most mainlanders first try its intense flavor they spit it out and cuss repeatedly). I'll be honest. I don't remember actually leaving Rum Fire, only waking up the next morning.
That night we set out in search of Oahu's gay scene. We hit three bars: Hula's Bar & Lei Stand, Fusion, and Angles Waikiki.
Hula's Bar & Lei Stand (134 Kapahulu Ave., Honolulu; 808-923-0669), located on the second story of the Waikiki Grand Hotel, was buzzing with energy and felt neighborly. It's a large, dimly lit space with many hidden alcoves and tiny tables, and there are screens from every angle showcasing music videos. It was delightful to see people in shorts and flip-flops rocking out to the latest club singles -- a scene I could easily adapt to. Hula's was my pick of Oahu's gay nightlife.
Our next stop, Fusion (2260 Kuhio Ave., Honolulu; 808-924-2422), was nothing short of a David Lynch experience. A dance floor cuts the awkward L-shaped space in half. A tiny audience of about 10 took in Fusion's drag show, which seemed to feature three performers for every spectator. The acts themselves were fun -- brazen and energetic -- but the meager audience proved an unsettling match, making it seem like we were watching auditions.
Angles Waikiki (2256 Kuhio Ave., Honolulu; 808-923-1130) had the most meat-market feel of the three. We had been inside a total of 20 seconds before I was hit on. Well-lit and sparse, it felt a little like an army mess hall, and seemed to be populated more by out-of-town businessmen on the down low than by the cheery locals who seemed drawn to Hula's. As we enjoyed a local microbrew on the lanai we listened to a pornographer as he tried to recruit two American soldiers to perform on his website. Aloha!
The next day we left Oahu for the more remote island of Kauai. Our home for the next few days would be the Westin Princeville Ocean Resort Villas (3838 Wyllie Rd., Princeville), located on the lush, northern side of the island. We knew we were in for good times when we accidentally tried to check in at the wrong resort and the hotel clerk said, "Oh, you're staying at the Westin? You guys are stoked!"
The Westin Princeville is still undergoing construction of future villas, but the features are in full effect, with multiple swimming pools and cabana bars. (Of note is the kids' pool, which includes a waterslide and soft, giant turtle fountains, which we just had to get in after all the kids had gone to bed.) The suites are like condos and include a washer and dryer, a kitchenette equipped with dishes and cookware, a shower for two, and a Jacuzzi-style tub, all of which is laid out comfortably in an understated cream and chestnut color scheme. Instead of an ocean view, one is treated to picturesque green rolling hills that multitudes of feral roosters and chickens call home. Yes, thousands of wild roosters -- they don't tell you that in the tourist brochures, but the sound grows on you and is eventually charming. And these are some handsome roosters, the kind you see hanging upside down in the paintings of Dutch masters.
Because our suite came equipped with a kitchen and the grounds feature many BBQ grills, we initially thought we'd do a little grocery shopping and cook for ourselves. One night at the resort's restaurant, Nanea, changed our minds. For the next three days we ate every meal, save one, right there. Though the entrees started around $25, not including cocktails, the cost of groceries was also high, making restaurants seem less cost inefficient in the end.
Nanea has an intimate wood-carved interior and ample outdoor seating situated next to man-made waterfalls and a koi pond set in lava rock. Tiki torches cast a warm, romantic glow at night. The staff was easygoing and friendly, though not at the expense of professionalism. Because we eventually sampled nearly the entire menu, I won't list our choices here except for one notable dish that threatened to make me break up with my guy and marry it instead: "duck two ways" -- five-spice seared breast and Kalua duck laulau with lilikoi citrus glaze. Laulau refers to a style of cooking in which meat is wrapped in Taro leaf and simmered in an imu (an underground oven), though this step is often accomplished today by steaming on a stovetop.
Furthermore, both my boyfriend and I agreed that the Westin Princeville had won our pina colada contest. You could have hooked us up to an IV drip of the stuff.
The following day we went on a kayaking trip down the Hanalei River, courtesy of Princeville Ranch Adventures. Our friendly guide was a laid-back local who regaled us with stories of the island's history as we made our way to a secluded cove for some snorkeling. The boyfriend and I regressed to excited 8-year-olds as we splashed amongst Hawaii's glorious, aquatic natives.
Because this is a cruel, heartless world, the time came when we had to leave. By then we were on a first-name basis with the friendly staff and had almost certainly developed a chemical dependence on their pina coladas, so it was with heavy hearts that we flew home. Even so, the magic of the islands and the luxury that marked our stay remained with us.
Want more breaking equality news & trending entertainment stories?
Check out our NEW 24/7 streaming service: the Advocate Channel!
Download the Advocate Channel App for your mobile phone and your favorite streaming device!


text:
34 S.Ct. 179
58 L.Ed. 377
PHOENIX RAILWAY COMPANY, Plff. in Err.,
LEE H. LANDIS, Administrator of the Estate of George W. Sanders, Deceased.
No. 61.
Argued November 12, 1913.
Decided December 22, 1913.
Messrs. Charles Cowles Tucker, Louis H. Chalmers, Edward Kent, A. B. Browne, Alexander Britton, and Evans Browne for plaintiff in error.
Messrs. J. M. Jamison and John Mason Ross for defendant in error.
Mr. Justice Hughes delivered the opinion of the court:
This action was brought by the administrator of the estate of George W. Sanders against the Phoenix Railway Company to recover damages for negligence causing the death of the intestate. Judgment in favor of the administrator was affirmed by the supreme court of the territory. 13 Ariz. 80, 108 Pac. 247, 13 Ariz. 279, 112 Pac. 844.
The first assignment of error is to the effect that the court below misconstrued the statute under which the action was brought. Rev. Stat. (Ariz.) 1901, &Par;2764-2766. The ruling was upon the sufficiency of the complaint, and the court followed Southern P. Co. v. Wilson (1906) 10 Ariz. 162, 85 Pac. 401, and De Amado v. Friedman, (1907) 11 Ariz. 56, 89 Pac. 588, which held that the action was for the benefit of the estate, and that it was not necessary for the plaintiff to allege or prove the existence of beneficiaries, or the amount of damages suffered by them.
In the first case cited, the history of the legislation was reviewed and the conclusion was rested upon the terms of the statute of 1901, as compared with the earlier act. The court has frequently stated that it is disposed to accept the construction which the territorial court has placed upon a local statute. Sweeney v. Lomme, 22 Wall. 208, 213, 22 L. ed. 727, 728; Fox v. Haarstick, 156 U. S. 674, 679, 39 L. ed. 576, 578, 15 Sup. Ct. Rep. 457; Northern P. R. Co. v. Hambly, 154 U. S. 349, 361, 38 L. ed. 1009, 1014, 14 Sup. Ct. Rep. 983; Copper Queen Consol. Min. Co. v. Territorial Bd. of Equalization, 206 U. S. 474, 479, 51 L. ed. 1143, 1146, 27 Sup. Ct. Rep. 695; Lewis v. Herrea, 208 U. S. 309, 314, 52 L. ed. 506, 508, 28 Sup. Ct. Rep. 412; English v. Arizona, 214 U. S. 359, 361, 53 L. ed. 1030, 1032, 29 Sup. Ct. Rep. 658; Santa Fe County v. New Mexico, 215 U. S. 296, 305, 54 L. ed. 202, 207, 30 Sup. Ct. Rep. 111; Albright v. Sandoval, 216 U. S. 331, 339, 54 L. ed. 502, 508, 30 Sup. Ct. Rep. 318; Clason v. Matko, 223 U. S. 646, 653, 56 L. ed. 588, 593, 32 Sup. Ct. Rep. 392. The applicable considerations gain in force where, as in this case, the construction of the statute, deliberately established and followed, has been reaffirmed upon the eve of statehood, and we are of the opinion that the ruling of the supreme court of the territory of Arizona should not be disturbed.
The next contention is that the court below should have reversel the judgment of the trial court because of inconsistent instructions to the jury. After charging the jury that if they found for the plaintiff they should award such damages as should fairly compensate the estate of the deceased for the loss sustained by reason of his death, not exceeding the amount fixed by the statute, the trial court gave a further instruction that it was 'not necessary on the part of the plaintiff to show the precise money value of the life of the deceased, or the exact amount of damages suffered by the beneficiaries, in order to sustain a recovery for substantial damages.' It is urged that the latter instruction was inconsistent with the former, and impliedly submitted a distinct basis of recovery; that is, the loss to beneficiaries. It appeared in evidence that the decedent left a wife and two adult children, and that his wife, at least, had enjoyed the benefit of his support. The court below, while conceding that the term 'beneficiaries,' in the light of its construction of the statute, was 'technically inappropriate,' was of the opinion that the action was tried throughout upon the theory that the damages to be awarded were such as were suffered by the estate, and that, no considering the course of the trial and the instructions given to the jury just prior to, and immediately following, the one in question, it could not be said that the language complained of might have confused or misled the jury. We concur in this view and find in this assignment of error no ground for reversal.
It is said further that the court erred in holding that the plaintiff was entitled to recover substantial damages for the benefit of the estate 'without evidence showing or tending to show that deceased had ever saved or would have saved any portion of his earnings.' We have not been referred to any ruling to this effect. No such instruction was given to the jury, and the record does not disclose any request for an instruction which was refused by the trial court. The argument, in substance, is that the verdict was without sufficient basis in the evidence. It cannot be said, however, that there was no evidence to go to the jury, and, as we are limited to those questions which may be appropriately raised on writ of error, an objection that the verdict is against the weight of evidence, or that the damages allowed were excessive, cannot be considered in this court. Act of April 7, 1874, chap. 80, § 2, 18 Stat. at L. 27; Wilson v. Everett, 139 U. S. 616, 35 L. ed. 286, 11 Sup. Ct. Rep. 664; AEtna L. Ins. Co. v. Ward, 140 U. S. 76, 91, 35 L. ed. 371, 376, 11 Sup. Ct. Rep. 720; New York, L. E. & W. R. Co. v. Winter, 143 U. S. 60, 75, 36 L. ed. 71, 80, 12 Sup. Ct. Rep. 356, 8 Am. Neg. Cas. 690; Herencia v. Guzman, 219 U. S. 44, 45, 55 L. ed. 81, 82, 31 Sup. Ct. Rep. 135.
The trial court charged the jury that it might 'take into consideration the income and earning capacity of the deceased, his business capacity, experience, and habits, his health, physical condition, energy, and perseverance during what would probably have been his lifetime if he had not received the injuries from which death ensued.' The court below granted a rehearing upon the question whether there was error in giving this instruction because of a failure to specify particularly what habits the jury was authorized to consider. 13 Ariz. 279, 112 Pac. 844. It was concluded that if the appellant desired an instruction with greater particularity upon this point it should have made a suitable request; and , having failed to do so, was not entitled to complain of the omission. This ruling is assigned as error. It is urged that the instruction as given by the trial court was wrong in itself, in that it directed the jury, in effect, to find for the plaintiff the amount the deceased would have earned during the years of his life expectancy. But this is manifestly a misconstruction of the charge. It was not erroneous to instruct the jury, as did the court, with respect to what might be taken into consideration in determining the damages sustained by the estate, and the court below was right in saying that, if the plaintiff in error desired explicit reference to particular habits, an instruction to that effect should have been requested. Pennock v. Dialogue, 2 Pet. 1, 15, 7 L. ed. 327, 332; Congress & E. Spring Co. v. Edgar, 99 U. S. 645, 659, 25 L. ed. 487, 491, 1 Am. Neg. Cas. 375; Texas & P. R. Co. v. Volk, 151 U. S. 73, 78, 38 L. ed. 78, 80, 14 Sup. Ct. Rep. 239. A further objection to the charge of the trial court upon the subject of damages, with respect to the number of years which should be deemed to constitute the deceased's expectation of life, concededly was not presented to the court below, and, being raised in this court for the first time, comes too late. Clark v. Fredericks (Davis v. Fredericks) 105 U. S. 4, 26 L. ed. 938; Robinson v. Belt, 187 U. S. 41, 50, 47 L. ed. 65, 69, 23 Sup. Ct. Rep. 16.
The remaining assignments of error involve a question of appellate practice in the supreme court of the territory. That court held, with respect to the action of the trial court in permitting answers to certain hypothetical questions addressed to physicians, that the mere general objections disclosed by the abstract of record filed under its rules were unavailing, and it declined to scrutinize the reporter's transcript for the purpose of discovering the objections said to have been actually made. On this course, the court but applied its rule that 'abstracts of record, as filed, will be treated by the court as containing such protlons of the record as the parties deem sufficient upon which to try the assignments of error.' Rule I, subdiv. 6, 8 Ariz. iv., 71 Pac. vi. It is urged that the refusal to examine the reporter's transcript was in violation of the act of 1907 (Laws of Arizona, 1907, chap. 74, p. 122). But the statute has not been thus construed, and we find no ground upon which we should be justified in holding that the court committed error in following the established practice to which the court alludes in its opinion. 13 Ariz. 80, 84, 108 Pac. 247, 248; Laws of Arizona 1907, chap. 74, pp. 130, 131; Liberty Min. & Smelting Co. v. Geddes, 11 Ariz. 54, 90 Pac. 332; Donohoe v. ElPaso & S. W. R. Co. 11 Ariz. 293, 94 Pac. 1091; Title Guaranty & Surety Co. v. Nichols, 12 Ariz. 405, 100 Pac. 825; Sanford v. Ainsa, 13 Ariz. 287, 114 Pac. 560, 228 U. S. 705, 707, 57 L. ed. 1033, 1035, 33 Sup. Ct. Rep. 704.
The judgment is affirmed.


text:
Stop, squat, and (possibly) bring your own roll in South Korea
PYEONGCHANG, SOUTH KOREA (Nexstar) — Differences in U.S. and Korean culture are myriad, but one thing sticks out to our American journalists abroad: The bathrooms, which include unfamiliar toilets and ways of disposing of your toilet paper.
We start with some of the unusual signage in some of the bathrooms. This one below looks like what we may see in the USA:
But what about this sign–is the bathroom for Olympic sledders only?
Instead of having a toilet seat to do your business, you might have to use a squatter toilet–maybe more accurately described as a porcelain hole in the floor.
Squatter toilets are leftovers from before Korea's rapid modernization, and are commonly found in less developed areas of Korea. The Korea Herald reports the government replaced many squat toilets with flush toilets in 1988, when the Summer Olympics were held in Seoul. Before those Olympics, nearly 70 percent of public bathrooms in Seoul had squat toilets without plumbing systems. But you will still find them even in modern cities, usually in older buildings.
If you ever encounter one, face the hooded end when you squat.
You may also noticed that some stalls in Korea also have trash cans next to them, which is another holdover from the past. People are often discouraged from flushing toilet paper, especially in public restrooms in older buildings. Instead, you throw it into the trash can near the toilet.
Don't worry though. The restrooms are cleaned very frequently.
Have TP, will travel
In the past, many bathrooms did not provide toilet paper, so it became common to carry a stash around just in case.
Public transportation will even provide a spot to hang your roll, as WFLA's Annie Sabo demonstrates. Just make sure you throw it away instead of flushing.
Highway rest stops a world away
Rest stop restrooms in Korea are a far cry from what we're used to in the United States.
For starters, some have themes. A September 2016 Kotaku.com article highlighted an Apollo rocket-themed rest stop and a restroom inspired by "The Little Prince." You could even find Audrey Hepburn staring back at you inside the restroom of the "Roman Holiday" rest stop.
The Korea Herald reports some rest stops are even sought out for the cuisine served inside.
Our Nexstar Olympics team found one with a garden–yes, a garden inside. And no, your eyes aren't fooling you– that really is a toothbrush dispenser on the wall.
Hand dryers and mouthwash are often always found readily available for anyone to use.


text:
This article is more than 1 year old
WebKit passes third Acid test
Recovers from trip
WebKit - the framework that underpins Apple's Safari, Google's Chrome browser, and its Android phone platform - has become the first browser to pass the full Acid 3 test.
The Acid tests are designed to check how compliant a browser is with the web standards laid down by the Web Standards Project (WaSP). Acid 3, reckoned to be the most stringent test, was introduced earlier this year and WebKit is first of the industry's browsers to yield a good result under the test.
It had failed earlier on one count - to render smooth animation - until last week. The improved result has been attributed to "speedups in JavaScript DOM and rendering."
The achievement puts WebKit ahead of other browsers in the race to meet the Acid 3 test - although other leading browser builders have rejected the test as irrelevant. Chris Wilson, platform architect for Microsoft's Internet Explorer, has stated that while Acid 3 is "a collection of interesting tests," it is not Microsoft's goal to comply.
And don't all you open-source lot start tutting and muttering "typical Microsoft" either. Mozilla's Firefox 3 team has also dismissed Acid 3 saying: "None of the issues on the Acid 3 list are important enough." ®


text:
The Library of Congress / Ameritech National Digital Library Competition (1996-1999) | |
Competition Home |
Technical Information for 1998/99 Competition > Guidelines and Resources Prepared for Applicants > Digital Historical Collections: Types, Elements, and Construction |
NOTE: Links to resources outside the Library of Congress are to URLs that were active when this set of archived documentation was actively maintained. Some links may no longer be active because resources have been removed. If a link is active, the resource may have changed substantially since the documentation was created. No attempt will be made to trace the linked resources or to suppress bad links. The URLs are being retained for their value as historical evidence.
This document and two others are intended to take the place of the 1994 document titled Elements of Digital Historical Collections. The new documents have been prepared, in part, to offer guidance to applicants in the Library of Congress/Ameritech competition. The other two documents are Digital Formats for Content Reproductions and Access Aids and Interoperability.
The trio of documents present a snapshot of the Library of Congress digital conversion activity as of August 1996. The ideas and approaches outlined represent the collection-digitization effort of the American Memory pilot program (1990-1994) and the operational National Digital Library Program (1995-1996) that has followed the pilot. The institution recognizes that many avenues remain unexplored and that new technology will lead to changing practices.
Historical collections. At the Library of Congress, the fundamental building block for online historical materials is the collection, a coherent body of related materials. Collection types include:
Elements in the Library's Digital Collections
Each Library of Congress online collection consists of the following elements:
Framework. A set of illustrated HTML (HyperText Markup Language) text files that serve as the collection home page or home page family. The framework is so named because it provides an intellectual frame for the collection and embraces the other collection elements. The family of texts includes scope and content notes, chronologies, technical notes, and bibliographies. The framework may be compared to a book's main title page, table of contents, front matter, and back matter.
Access aid. The data set that describes the items in the collection and supports searching and browsing by users. The access aid may be thought of as descriptive metadata. In Library of Congress online collections, the most familiar and frequent access aid is a collection-specific catalog consisting of bibliographic records. For a few Library collections, access is provided by sets of menus that serve as rough-and-ready finding aids. In the future, access to some collections will be provided by fully realized finding aids that conform to the emerging Encoded Archival Description (EAD) model. (See also Access Aids and Interoperability.)
Reproductions. The digital images, searchable texts, recorded-sound files, and moving-image files that reproduce original items. Some items are reproduced by a combination of the above. When stored in a computer system, the digital reproductions contain and/or are associated with administrative and structural metadata that may be used to track the location of the reproductions in the system, report the specific digital type or format, control access, indicate relationships for multipart reproductions, and provide other technical information. See also Digital Formats for Content Reproductions.
Supplementary programs. Elements that introduce collections to users, explaining what they contain and how they may be used. Called Special Presentations at the Library's WWW site, in their simplest form, they are brief texts or "slide shows," while at their most elaborate, they take the form of interactive multimedia programs.
Digital historical collections include a variety of elements that may be used for access. These include not only the catalog records and finding aids mentioned above, but also full texts (when, say, a printed book has been converted to searchable text), and expository introductory materials. Although the Library has not yet instituted a search system that embraces all of these elements (indeed, at this writing, no EAD finding aids linked to digital content are in place at the Library's WWW site), the Library foresees that a search system with a broader embrace will be established in mid-term future. (See also Access Aids and Interoperability.)
When the access aid takes the form of bibliographic records, the level of cataloging perfection may vary. In some cases, Library staff members produced full cataloging adhering to relevant rules and authorities; in others, a variety of simplifications, variations, and unorthodoxies were employed or tolerated. For a few of the collections, item-level prose annotations have been provided. To the degree possible (when sufficient resources exist), subject terms have been drawn from Library of Congress Subject Headings (LCSH) or Library of Congress Thesaurus for Graphic Materials (LCTGM).
This existence of a diverse array of access elements inevitably diminishes the effectiveness of "classic" bibliographic records--records that employ a structured vocabulary and make careful use of authorities for names and subjects--within the larger corpus. Thesaurus-governed subject terms, for example, will not always be present in a working database that provides item-level access within a single collection, in EAD finding aids that resemble traditional manuscript registers, or in the searchable full texts provided for some manuscript and many printed-matter collections, whose vocabulary consists of "ordinary English" words and terms.
The Library hopes to develop additional aids to access as well as a search system powerful enough to plumb the jumble of structured and unstructured vocabulary. A first step will be to create a catalog of collection-level bibliographic records for the historical collections. This database of collection-level records will serve as a point of entry for many users.
Identifiers, Logical Names, and the Digital
The Library is developing an approach to assigning names or identifiers to digital reproductions. These identifiers link the reproductions and the access aid, just as library call numbers link catalog records to the books on the shelf. The discussion below describes current Library practice and the use of a two-part identifier.(See also Identifiers for Digital Resources.)
Why are identifiers needed? In the Library of Congress digital repository, reproductions move from one device to another, e.g., when data are backed up or when obsolete hardware is replaced. This migration of data requires that identifiers be logical rather than physical names. The physical location of the files in the repository will be recorded in a document locator system. Thus a query made of the access aid will yield the identifier (logical name) for the desired item. When sent to the locator system, the logical name will be translated into the current physical name, and the reproduction will be retrieved.
The Library's extensive use of contractors to create the reproductions has led to the practice of using identifiers as physical names at delivery time. The digital materials produced by contractors (and often those produced by staff as well) spend part of the life cycle in DOS operating-system computers; e.g., contractors often deliver data on write-once CD-ROMs. Thus the Library requires that directory names and filenames adhere to DOS naming requirements.
The current identifier system works within the closed system of the Library's servers and does not provide pointers to the institution itself, e.g., the address for the server that holds the data (including the domain name "loc" for Library of Congress). Thus, if access aids with the current identifiers were loaded into, say, the catalog of another library, the data could not be used to link back to reproductions in the Library's servers. The development of the Library's repository is intended to address this circumstance. The Library is analyzing the option of treating the two-part identifier as a single unit, adding the missing pointer, and formalizing the result as a Uniform Resource Name (URN). If adopted, the use of URNs will change the structure of the identifier and its placement in the bibliographic record but not the explanatory concepts outlined here. Readers will recognize that this proposed use of the URN springs from the same impulse that led to the definition of Persisent Uniform Resource Locators (PURLs), which may serve other archives as identifiers. (See also Access Aids and Interoperability and Handle Server: Overview.)Items, Aggregates, and Identifiers
The Library is assigning the identifiers described in the preceding section to both items and groups of items, called aggregates. These are, in fact, the identifier's two parts. In the context of digital collections, the Library uses the term item in a flexible way. Depending upon the archivist's judgment and collection design, an item may be:
The archivist's definition of an item will reflect his or her determination of the level of detail desired (or affordable) in the access aid at hand. When high levels of detail are to be offered, the collection item will be a truly discrete unit; when group-level description is provided, the term item will name what is in fact a group of items. Readers should note, therefore, that in this context item is defined as the unit of content referenced by an individual bibliographic record or by a line in a finding aid. In the Library's bibliographic records, items are referenced in MARC field 856 subfield f. The Library has not yet established a parallel convention for EAD finding aids.
When archived in the digital repository, reproduction items are placed in groups called aggregates. Smaller, single-medium collections may be represented by a single aggregate, while larger, complex collections may be represented by multiple aggregates. An emerging Library practice is to place like items in separate aggregates, i.e., one aggregate will contain reproductions of photographs, another books, and still another sound recordings.
The establishment of separate aggregates for groupings of items in like original formats permits the Library to regularize the invocation of presentation and display routines. (At this writing, this emerging practice has not been fully implemented.) The online presentation and display of, say, a photograph is different from the presentation and display of a book. When the Library presents the bibliographic record for a photograph, for example, the system accompanies the record with a display of a thumbnail image. In the case of a book, the access aid provides links to a searchable full text which in turn links to the set of page images. By having photographs in one aggregate and books in another, the system knows the item's type and can activate the needed delivery routines. In bibliographic records, aggregates are referenced in MARC field 856 subfield d. The Library has not yet established a parallel convention for EAD finding aids.
As noted above, the Library is investigating the possibility of using a URN (Uniform Resource Name) for linking; if adopted, the URN would be placed in a to-be-determined subfield in MARC field 856.
For additional discussion of the topics covered in this section, see also Access Aids and Interoperability.
Single Reference, Many Parts or Versions
Since a collection item may be multipart, the online presentation must offer the user some means of retrieving all of the parts from the single identifier found in the access aid. Although examples like multi-image manuscript folders spring readily to mind, one-to-many links often exist even when the item described is a singular original. A large theater poster, for example, may be reproduced by (1) high- and moderate-resolution versions (two reproductions) or (2) an image containing the whole poster and a set of six image "tiles," each of which contains a segment of the original (seven reproductions). Similarly, a book may be described in a single bibliographic record but--due to its length--be presented online as a set of chapters.
A number of devices may be employed to provide users with the many reproductions (or reproduction "parts") that are linked via the one reference. The simplest albeit least elegant device is to create a table of contents or menu (see the current version of the American Memory Walt Whitman notebooks collection). Here, an HTML file lists the pages by number and links each one to its reproduction image. As an alternate option, some observers have suggested consideration of multipage PDF files (the Portable Document Format was developed by the Adobe corporation and PDF files are viewed in Acrobat software).
Meanwhile, other organizations are developing models for paging through a document using a set of images that are displayed "inline" (in the browser). The TEI planners are developing a envelope, while a group at the library at the University of California, Berkeley, is testing what they call Ebind. A paging approach has been applied to a set of serials in the Making of America project organized by Cornell University and the University of Michigan. These presentations provide tables of contents, sets of inline page images (in the GIF format, at moderate resolution), tools for navigation ("paging"), and (in some cases) fetchable or printable access to higher-resolution versions of the images.
Each of these one-to-many devices has its own advantages and disadvantages; the Library foresees that it may employ all three over time, making its selection after analyzing the needs of a particular collection. While it implements additional approaches for paging through or selecting the parts of a multi-part item, the Library will continue to rely upon HTML table-of-contents files.
Producing the Elements, Assembling the
Library staff produce frameworks, access aids, and introductory programs. Generally speaking, the frameworks, access aids, and introductory programs are produced by Library of Congress staff, typically specialists in the Special Collections divisions. A variety of software is used: the Library's mainframe-based cataloging system (MUMS), MARC software (Minaret, running on DOS or UNIX systems), and various database and word-processing programs.
When data records destined to serve as bibliographic records have been created in word-processing or database software, they are marked with tags and field delimiters, and are subsequently loaded into Minaret or other MARC software. In addition, some records created in MUMS are edited in Minaret, at which time certain fields or data not supported by MUMS can be added. Meanwhile, the Library is very interested in the move toward cataloging simplification represented by the development of the Dublin Core set of fields for bibliographic information and hopes to begin to implement this approach in the near future.
The Library is also exploring other options for access aids. Current production activities have suggested a role for relational databases, the content of which may have some of the characteristics of bibliographic records. Meanwhile, the Library is bringing its first content-linked EAD finding aids online and is investigating software options for their efficient production.
For additional discussion of the topics covered in this section, see also Access Aids and Interoperability.Contractors and staff produce reproductions. Most reproductions are produced by specialist contractors; some are produced by Library staff. In both cases, specialized equipment and techniques are used. Requirements are outlined in the statements of work (to be placed online in the very near future) found in the requests for proposal (RFPs) associated with Library of Congress digitizing contracts.
Multiple reproductions. The Library's projects often produce multiple digital reproductions. For example, an historical photograph may be digitized as:
For works converted to searchable-text form:
In some cases, a project will produce analog as well as digital reproductions. For example, the desire to create long-lasting, high resolution copies for preservation has led photographic curators to recommend a production path that, first, produces a film intermediate and, second, a digital reproduction. Since the futurity for current-day digital moving-image formats is uncertain, and since most digital-movie formats are derived from analog video, the Library's plans for motion picture collections always include, first, the production of a video master tape and, second, the production of the digital versions.
The Library archives all versions of the reproductions but generally selects one or two for online access. In the examples noted in the paragraph above, the Library would provide online access to the compressed digital images of the photograph and the digital movie file.
For additional discussion of the topics covered in this section, see also Digital Formats for Content Reproductions.
The preceding discussion highlights the uncertainties that surround the role of digital reproductions in the Library's preservation activities. When and how can the digital project contribute to preservation? The NDLP staff believes that a digital project can make three contributions:
For some materials, digital reproductions faithfully reproduce the original and, if they endure, will rival or surpass analog reproductions as preservation copies. The NDLP believes that this is the case for manuscripts, printed matter, and sound recordings. It may also be the case for photographs up to a certain size, e.g., 35mm negatives.
Closely related to the preceding, but when the reproduction is slightly less than faithful, digital copies may serve all typical uses. For example, digital images of photographs with a spatial resolution of 4,000x3,000 pixels may not capture every nuance of the original but are capable of serving virtually every user's needs. Thus, for a collection of historical images with moderate artistic value, such as a set of digital images, if they endure, will provide the same service as a set of copy negatives. In a time of scarce resources, such copies may suffice for some collections. This approach will be especially appealing when the original materials can be conserved, e.g., providing cold storage to halt the deterioration of older negatives.
For some projects, the production scheme will create both an analog preservation copy and a digital reproduction. For example, a project to preserve a collection of nitrate negatives may create a set of analog interpositives which are then scanned to produce the digital reproduction.
The phrase "if they endure" in 1 and 2 above reveals the principal anxiety about digital information: will obsolescent hardware, software, and media render digital information unreadable? The Library shares that anxiety but at the same time hopes that the repository for digital information alluded to elsewhere in this document--with its accompanying routines for backing up and migrating data--will succeed in sustaining digital information.
Once produced, the framework, access aid, reproductions, and introductory program are ready to be loaded into retrieval software; once loaded, the various links are actualized and the assembled collection is ready for use.
The Library's vehicle for patron access is the World Wide Web (WWW). Collections are currently loaded for WWW hyperlinking; the access aids are indexed for searching in Inquery software. Meanwhile, the Library welcomes private-sector initiatives that will lead to other forms of dissemination, e.g., CD-ROM publications or commercial online service.
Competition Home |
Technical Information for 1998/99 Competition > Guidelines and Resources Prepared for Applicants > Digital Historical Collections: Types, Elements, and Construction |
The Library of Congress
>> American Memory
Content updated: 1996-08-21
Contact Us |


text:
- TRW Aftermarket brake pads are the best in the business, offering high quality, reliable performance that you can trust whenever you need it. With the advanced silicate coating (COTEC), along with scorching added to the manufacturing process, TRW brake pads provide great stopping performance from the get go.
- Compliant with ECE R90 regulations
- Guaranteed performance meeting or exceeding OE standards
- Advanced silicate coating (COTEC) provides improved contact between the brake disc and pad
Trust TRW Brake Pads & Brake Shoes for enhanced braking safety
TRW's extensive range of brake pads and brake shoes cover a large number of vehicles in the Australia and New Zealand car parc. They cut stopping distances by up to 7 metres during the bedding in of the brake pads or shoes. Each set of TRW brake pads come with any fitting accessories required to put them on your vehicle. They back their product with a 24,000km warranty to give you peace of mind that you are purchasing a quality product.
TRW designs and manufacturers OE braking systems so they know what they are doing when it comes to supplying replacement brake parts.High quality shims are provided to act as a noise reducing damper between the pad and the caliper. It is the same type of metal shim that is found in the Original Equipment provided by the vehicle manufacturer. TRW shims are tested in a laboratory and on the road to make sure the NVH (Noise Vibration Harshness) levels are reduced. The brake pads meet ECE R90 specifications and are laboratory and road tested to ensure they meet a high standard. The brake pad backing plates are made from a high quality steel and are powder coated to stop them rusting. A special adhesive that can tolerate extremely high temperatures and has a high sheer strength is used to bond the pad friction material to the backing plate. The friction material is heated to 700 degrees Celsius to remove any trapped gases and resins. All this is done to make sure TRW products are fit for purpose for your next brake service.
Repco have all the tools and and parts you require to maintain your brakes. Use the rego search function on the Repco website, or talk to one of our staff at your local Repco store today to view our whole range of Brake Pads, Brake Shoes and Brake Fluids for your next brake job.
Bazaarvoice SAP Hybris Integration Version 2.8.0
Bazaarvoice SAP Hybris Integration Version 2.8.0