Kitura Server Style Guide
This guide covers a way of structuring your project code to make future development easier and keep your project files looking clean.
Prerequisites
- Kitura Server: Learn how to create one in our Getting Started guide.
Recommended Project Structure
We recommend you follow the Model-View-Controller (MVC) design pattern for your Kitura project (with controllers in our case called routes). An example file structure for a project following this patten is:
MyKituraApp ├── Package.swift ├── Sources │ ├── MyKituraApp │ │ └── main.swift │ └── Application │ ├── Application.swift │ ├── Routes │ │ └── HealthRoutes.swift │ ├── Models │ │ └── Book.swift │ └── Middlewares │ └── CheckoutSession.swift ├── Views │ └── Template.stencil ├── public │ └── Img.jpg └── Tests └── ApplicationTests
If you used the Kitura CLI, or Kitura macOS app, to create your project your files will already be in this structure.
This might seem a bit complex, so let's break down what these folders and files are:
- Package.swift – defines packages that your app depends on and their versions
- main.swift - the file that is run to initialize your app and run your server
- Application.swift - the application that glues everything together
- Routes – (also known as controllers) defines your app routes and their logic
- Middlewares – Kitura middlewares which process the incoming requests before handing them down to the routes
- Models – represents data, implements business logic and handles storage
- public – contains all the static files like images, styles and javascript
- Views – provides templates which are rendered and served by your routes
- Tests – contains the Swift tests for your project
Throughout these guides we will assume you have a project set up as described above. If you generated your project with the Kitura macOS app or Kitura CLI, skip ahead to Step 5: Defining a Book model. If you generated your project using the Swift Package Manager (SPM), the following steps will produce the above structure.
Step 1: Create the Application directory
Within our Sources directory we will first create an Application directory:
mkdir Sources/Application
This is the directory where we will store all of our application code. Note, code in the project's main.swift file isn't easy to test because you can't import an executable target as a module, so to encourage the creation of easily testable code we have minimal code in our main.swift file and recommend putting application code into a separate Application directory.
Next we will create our Application.swift file:
touch Sources/Application/Application.swift
Next we need to create our Routes directory:
mkdir Sources/Application/Routes
This is where we will store all of our route handlers.
Next we will rename the directory within Tests to ApplicationTests:
mv Tests/MyKituraAppTests/ Tests/ApplicationTests
Step 2: Update the Package.swift file
Next we need to configure the targets within our Package.swift file to add in Application as a dependency so that we can build our new project structure:
targets: [
.target(name: "MyKituraApp", dependencies: [ .target(name: "Application"), "Kitura"]),
.target(name: "Application", dependencies: [ "Kitura" ]),
.testTarget(name: "ApplicationTests" , dependencies: [.target(name: "Application"), "Kitura" ])
]
Now we can rebuild our project:
swift build
If you are on macOS and would like to work within an Xcode project then you need to regenerate your Xcode project:
swift package generate-xcodeproj
You may need to reopen the Xcode project for these changes to take effect.
Step 3: Add code to the Application.swift file
Earlier, we created the Application.swift file but we didn't add any code to it.
Open the Application.swift file in our default text editor:
open Sources/Application/Application.swift
The Application.swift file will be responsible for starting our Kitura server.
Add the following code to the Application.swift file:
import Kitura
public class App {
let router = Router()
public init() throws {
}
func postInit() throws {
}
public func run() throws {
try postInit()
Kitura.addHTTPServer(onPort: 8080, with: router)
Kitura.run()
}
}
This code creates an instance of Router, which will route incoming requests to the correct endpoints. Within the run() method we register our router instance to run on port 8080. The call to Kitura.run() does not return immediately - it will block until the server is stopped.
The postInit() function is where we configure and set up the router, prior to starting the server.
Step 4: Add code to the main.swift file
Now that we have created our App class in our Application.swift file we can use it within our main.swift file.
Open the main.swift file in your editor:
open Sources/MyKituraApp/main.swift
Replace the existing code with the following:
import Application
do {
let app = try App()
try app.run()
} catch let error {
print(error.localizedDescription)
}
This code will create an App instance and run it.
Step 5: Defining a Book model
As we are simulating a bookstore in our guides, we are going to need to define a book. The book is a model so the first thing we need to do is create our Models folder:
mkdir Sources/Application/Models
This is the directory where we will store all of our models.
Next we will create our Book.swift file:
touch Sources/Application/Models/Book.swift
We will open the Book.swift file in our default text editor:
open Sources/Application/Models/Book.swift
Inside this file we define our Book:
struct Book: Codable {
let id: Int
let title: String
let price: Double
let genre: String
init(id: Int, title: String, price: Double, genre: String) {
self.id = id
self.title = title
self.price = price
self.genre = genre
}
}


Models can be used to improve the accuracy of your backtesting. We provide basic default models which assume you are trading on highly liquid assets, but if you are trading high volumes, or on low volume assets you should update these models to be more realistic.
All models are set on a per security basis. To set a model first fetch the security object and apply your model.
//Set IBM to have a constant $1 transaction fee. Securities["IBM"].FeeModel = new ConstantFeeTransactionModel(1);
All models should be setup in your Initialize() method.


I'm a small town girl born in Northern California with big ambition and, as my father said, "... didn't know what couldn't be done." I learned that from him. I come from my father's lineage that fled Palatinate, Germany in 1729 and my mother's that came to America in 1897 from Troyes, France.
My passion: EVERYTHING creative! I paint and draw, write poetry and screenplays, produce videos and live-recorded broadcasts, and host TV and radio shows, as well as, celebrity red-carpet events. I also study herbology, alchemy, quantum physics and the human brain. And, of course, I love coding.
Some fun facts most people don't know: I bungee jumped off the Alderpoint Bridge in Northern California and from a crane at the Sturgis, South Dakota Harley Run. For years I created art, using French artist Yves Klein's "Living Brushes" technique (human paintbrushes), in front of a live audience.


Issue: DEFINE-CONDITION-SYNTAXForum: Cleanup
References: Condition System, Version 18
CLOS Specification, 88-002R
Issue CLOS-CONDITIONS
Issue CONDITION-ACCESSORS-SETFABLE
Category: CHANGE/CLARIFICATION
Edit History: Version 1, 1/3/90 by Kim A. Barrett
Problem Description:
Issue CLOS-CONDITIONS incompatibly changed the slot specification syntax
for DEFINE-CONDITION to match the slot specification syntax for DEFCLASS.
This leaves us with two defining macros whose general forms are very
similar but which have small idiosyncratic differences.
Notes on voting:
Vote for just 1 of MORE-LIKE-DEFCLASS, INCOMPATIBLY-MORE-LIKE-DEFCLASS, or
MORE-LIKE-DEFINE-CONDITION.
In addition, vote yes or no to EMPHASIZE-READ-ONLY.
Proposal (DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS):
Define the syntax for DEFINE-CONDITION to be
DEFINE-CONDITION name ({supertype}*) [({slot}*) {option}*]
option ::= (:DEFAULT-INITARGS initarg-list) |
(:DOCUMENTATION string) |
(:REPORT exp)
The :default-initarg option is defined in the same way as for DEFCLASS. The
:documentation and :report options are unchanged.
If no supertypes are specified, then the condition being defined inherits
directly from CONDITION.
Proposal (DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS):
As DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS, but make the slot
specification list required.
Proposal (DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFINE-CONDITION):
As DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS, but change the syntax of
DEFCLASS so that the slot specification list is optional.
Proposal (DEFINE-CONDITION-SYNTAX:EMPHASIZE-READ-ONLY)
As either of the above proposals, but remove the :WRITER and :ACCESSOR
slot options.
Rational:
This provides the added functionality provided by :DEFAULT-INITARGS, and
the convenience of not having to explicitly write CONDITION as the only
super for some conditions.
INCOMPATIBLY-MORE-LIKE-DEFCLASS makes the basic syntax identical, but at
the cost of an incompatible change, since the list of slot specifications
will no longer be optional.
EMPHASIZE-READ-ONLY emphasizes the point that it is an error to attempt
to assign a condition's slots using SETF. Condition objects are supposed
to be at least conceptually read-only.
Current Practice:
IIM supports the :DEFAULT-INITARGS option. They may support the behavior
specified for an empty supertype list (if they don't, then they still
require at least one supertype).
Cost to Implementors:
Supporting an empty supertype list in the specified way is probably fairly
trivial. For an implementation of conditions which is not based on an
implementation of CLOS, adding the support for :default-initargs might not
be trivial.
Cost to Users:
MORE-LIKE-DEFCLASS is upwardly compatible for the status quo.
The other two proposals will probably require some programs to be modified.
As an interim solution implementations could support MORE-LIKE-DEFCLASS and
issue warnings for cases which were incompatible with the other two
proposals.
Benefits:
Programmers would need to remember fewer idiosyncratic differences in the
syntax of two very similar and important macros.
Discussion:
Barrett supports MORE-LIKE-DEFINE-CONDITION. He thinks that
EMPHASIZE-READ-ONLY would be a good idea if there isn't too much concern
about the incompatibility issues.
Pitman supports MORE-LIKE-DEFCLASS but mostly because the CLOS crew are
a stubborn bunch and it seems more likely that we can bend the rest of the
spec to be like their polished piece of prose than vice versa.
(i.e., MORE-LIKE-DEFINE-CONDITION is technically just as good to him.)
Pitman also supports EMPHASIZE-READ-ONLY.
-----
Additional comments in response to write-up:
Moon (11 Jan 90):
This issue raises good points that I think were overlooked in past
discussions of unifying Conditions and CLOS.
I am neutral among MORE-LIKE-DEFCLASS, INCOMPATIBLY-MORE-LIKE-DEFCLASS,
or MORE-LIKE-DEFINE-CONDITION. The incompatibilities here (either making
the slot-specifier list optional where it's mandatory or mandatory where
it is optional) are of little concern since the adjustment is tiny. Any
one of these would be a significant improvement over the status quo.
I am definitely in favor of EMPHASIZE-READ-ONLY and not impressed by the
compatibility arguments. An existing program that is incompatible with
this either actually modifies condition objects, in which case it can't
work, or it just accidentally says :ACCESSOR but only uses the reader,
in which case it is trivial to fix.


Breeders' Cup horse named 'Covfefe' pokes fun at Trump, favorite to win
by Sam DormanFans at Saturday's Breeders' Cup will get to see a competitor bearing one of President Trump's signature lines from Twitter.
Jamie Roth, who runs a LNJ Foxwoods stable, thought Trump's apparent typo -- "covfefe" -- would be a good name for one of her horses.
“We gave the name to her because we thought she was special and we thought the name was kind of funny," she told USA Today.
"Covfefe" the horse, 3, is reportedly the morning line favorite for the Breeders' Cup and even has her own Twitter account that pokes fun at the president. Titled "RealCovfefeRacehorse," the account often plays off of Trump's statements online.
TRUMP TWEETS 'COVFEFE,' CAUSES TWITTER FRENZY
"The Greatest #CovfefeHunt In American History!" the account tweeted on Thursday, clearly playing off of Trump's "witch hunt" label for the impeachment inquiry.
Roth said she hasn't heard from the White House and generally tries not to get too political.
“I don’t try to get too political,’’ she said. “He’s not for me, but obviously he is for some other people. He just doesn’t stand for the things that I believe it. But I believe in Covfefe.’’
TRUMP'S TWITTER TYPOS: FROM 'COVFEFE' TO 'UNPRESIDENTED'
Trump famously caused a social media uproar when he mysteriously decried the "constant negative press covfefe," in 2017. The president has since poked fun at himself, appearing in a White House video in which he jokes about the word.
CLICK HERE TO GET THE FOX NEWS APP
Roth reportedly said that she was considering naming another horse "Trump Tweets" and reserved it through a breed registry for thoroughbreds.


Hacker News
new
threads
past
comments
ask
show
jobs
submit
{{title}}
(
{{domain}}
)
position
{{position}}.
upvote
More


Measurement Kit is now deprecated. Please, check Measurement Kit's README for more information.
Measurement Kit is a network measurement engine. It implements open network measurement methodologies (performance, censorship, etc.) on Unix-like operating systems such as Android, iOS, Linux, and macOS, as well as on Windows. It is meant to be embedded by third party applications with specific network measurement needs and/or to be used by researchers to implement novel network measurement tools. It started as an engine implementing OONI nettests and since then has grown to include also other nettests.
Measurement Kit is currently used to implement OONI apps for all platforms. It is also integrated by other parties, mainly to run our implementation of the NDT network performance test on mobile platforms.
All our code is inside the measurement-kit GitHub organization. The main repository, also called measurement-kit is the entry point to learn more about Measurement Kit. It allows you to easily provide feedback and contribute.
In case you need to reach out to us to report a vulnerability, please write to the OONI team putting in Cc Simone Basso, using the email addresses and PGP keys listed on the OONI website.
Measurement Kit is a project by @bassosimone, @hellais, et al, carried out in 2013—2017 in the context of Nexa Center's MORFEO and Neubot projects, and financed by the European Commission (for MORFEO) and by Measurement Lab and Google through two distinct research grants. In 2018 Measurement Kit has been financed through a ICFP OTF Fellowship at Measurement Lab. Since 2019 Measurement Kit is a OONI project.


The model by Eisenman 68 calculates an energy balance for a well-mixed box of ocean water, covered with ice of a single thickness (see Supplementary Information). When ice is present, the enthalpy E is negative and proportional to the ice thickness. In the absence of ice, E is positive and proportional to the ocean temperature. The bifurcation parameter L m represents the annual mean outgoing long-wave radiation budget at the surface (not including temperature feedbacks) and becomes smaller when the climate warms. For values of L m between approx. 65 W/m 2 (which roughly represents the present-day climate) and 50 W/m 2, two stable solutions can be found: a seasonally ice-covered ocean and an ice-free ocean (Fig. 5a).
Solutions of the Arctic sea ice model in dependence on the mean long-wave radiation balance L m. ( a) Full range of periodic solutions between L m = 75 and 45 W/m 2. The blue surface demarcates between sea ice (E < 0) and open ocean (E > 0). Panels b–d show the solutions for three different values of L m in red; green and blue lines show equilibria for fixed solar and terrestrial irradiation representing a certain day of year when starting from very high (green) or very low (blue) E. The ranges where two equilibria are possible for the same irradiation are shown as blue shaded areas.
The solutions in Fig. 5 are periodic in time because of the prescribed annual cycle in the long-wave budget L, and downwelling short-wave radiation, S. Figure 5b–d again displays the annual cycle for three distinct values of L m (red lines). In addition, we show to what state the sea-ice system would evolve if there was no annual cycle (green and blue lines). To this end, we fix S and L to the values corresponding to a particular day in a year and integrate the model forward in time, starting from large positive and negative E. For most days in the year, only one asymptotic solution exists. For example, under permanent summer conditions, all ice melts away and the ocean becomes so warm that the outgoing long-wave radiation balances the absorbed radiation (Fig. 5, green line). Under permanent winter conditions, the ice grows to an infinite thickness, because there is no negative feedback in the model to limit the ice growth. In such cases of failed convergence we artificially set the enthalpy to −7 GJ/m 2 (corresponding to a thickness of approx. 23 m). As the ice-ocean system cannot fully adjust to the fast insolation changes in the course of a year, the amplitude of its annual cycle is very small compared to the difference of its steady state solutions. The solutions overlap only during a short period in spring and an even shorter period in autumn, in the rest of the year only one solution exists. Nonetheless, the existence of multiple solutions still carries over to the periodically forced system for a certain parameter regime.
The bifurcations in this default model (Fig. 5a) can thus be understood from the change of the asymptotic solutions with L m. In a cold climate, the summer is too short and insolation is too low to melt enough ice within one summer; a perennial ice cover is therefore the only solution of the periodically forced system. Under global warming (decreasing L m), the asymptotic solution moves to larger E and the melting season becomes longer (Fig. 5c); this is where the periodically forced system has multiple solutions, balancing between the cold and warm attractors. Finally, the winter becomes too short for the formation of sea ice thick enough to survive the following summer, and the ice-free solution is the only one that remains (Fig. 5d).
In conclusion, the fact that a certain comprehensive model does not show multiple solutions under the same external conditions does not automatically suggest that tipping points are not possible. This has two reasons: First, tipping points can remain hidden in a parameter range related to periodic forces that is not explored when varying one parameter (such as CO 2) alone. As Eisenman’s single column model above shows, the existence of multiple equilibria under fixed seasonal conditions in a model is a ‘smoking gun’ pointing to a strong positive feedback. Such a feedback indicates that the system is prone to tipping points even if the multistability is not apparent in the seasonally forced (non-autonomous) system. Changes in the insolation forcing (for instance due to changes in the annual cycle of cloud cover) can hence bring the system into a regime where abrupt changes are possible. The same can occur due to changes in the intrinsic relaxation time of the system, for instance related to the fact that the growth rate of sea ice depends on its thickness and hence the background climate 69, 70. Second, abrupt shifts can also occur in systems without multiple states. Specifically, the freezing point of water acts as a natural threshold for the formation of sea ice, making ice cover very sensitive on temperature in a certain regime and prone to reversible abrupt shifts 64. The quasi-periodic changes in insolation related to Milankovitch forcing might therefore switch the Arctic back and forth between an ice-free and a seasonal ice regime (in analogy to the monsoon switches outlined above). A similar switch-mechanism determining the growth and melt of ice sheets has also been discussed as an explanation of ice ages during the Pleistocene 71.


Welcome to Theme Builder
Tour
Theme Builder shows examples of custom themes and the files needed to create them.
On the , you can select platform and custom themes. , you can see at least one example of each component that shows the effect of the selected theme.
Theme Builder is also set up with a custom theme for you to edit. Click the 'Instructions' tab for documentation that walks you through how to edit the custom theme files.
View Selection
Components
Component Category Filter
transparent panel background


 Please install them using the Stremio client.
List of addons that should be available on this server:


:: com :: sun :: star :: drawing ::
|
| unpublished |
interface XSlideRenderer |
|
|
|
- Usage Restrictions
- not published
- Description
- Create preview bitmaps for single slides.
|
| Methods' Summary |
| createPreview |
Create a preview for the given slide that has the same aspect ratio
as the page and is as large as possible but not larger than the
specified size.
The reason for not using the given size directly as preview size and
thus possibly changing the aspect ratio is that
a) a different aspect ratio is not used often, and
b) leaving the adaption of the actual preview size (according to the
aspect ratio of the slide) to the slide renderer is more convenient
to the caller than having to this himself.
|
| createPreviewForCanvas |
Exactly the same functionality as createPreview(),
only a different return type:
com::sun::star::rendering::XBitmap instead
of com::sun::star::awt::XBitmap.
|
| calculatePreviewSize |
Return a size that has the given aspect ratio and shares either the
width or the height with the given maximum size.
|
| Methods' Details |
createPreview
| ::com::sun::star::awt::XBitmap |
| createPreview( |
[in] XDrawPage |
xSlide, |
| [in] ::com::sun::star::awt::Size |
aMaximumPreviewPixelSize, |
| [in] short |
nSuperSampleFactor ); |
- Description
- Create a preview for the given slide that has the same aspect ratio
as the page and is as large as possible but not larger than the
specified size.
The reason for not using the given size directly as preview size and
thus possibly changing the aspect ratio is that
a) a different aspect ratio is not used often, and
b) leaving the adaption of the actual preview size (according to the
aspect ratio of the slide) to the slide renderer is more convenient
to the caller than having to this himself.
- Parameter xSlide
- The slide for which a preview will be created.
- Parameter aMaximumPreviewPixelSize
- The maximum size of the preview measured in pixels. When the
aspect ratios of this size and of the given slide differ, then
resulting preview will either have the width or the height of
this size.
- Parameter nSuperSampleFactor
- When larger than the default 1 then internally a larger preview
is created which, before it is returned, is scaled down to the
requested size. The intermediate size is nSuperSampleFactor
times the original size. Values larger than 1 result in higher
memory consumption and longer runtime.
This value is an attempt to provide some antialiasing and so to
provide more readable slide previews. May become obsolete in
the future when true antialiasing suppport will be integrated.
|
|
createPreviewForCanvas
- Description
- Exactly the same functionality as createPreview(),
only a different return type:
com::sun::star::rendering::XBitmap instead
of com::sun::star::awt::XBitmap.
- Parameter xCanvas
- This canvas is used create a canvas specific bitmap.
- See also
- createPreview
|
|
calculatePreviewSize
| ::com::sun::star::awt::Size |
| calculatePreviewSize( |
[in] double |
nSlideAspectRatio, |
| [in] ::com::sun::star::awt::Size |
aMaximumPreviewPixelSize ); |
- Description
- Return a size that has the given aspect ratio and shares either the
width or the height with the given maximum size.
- Parameter nSlideAspectRatio
- The aspect ratio must not be 0.
- Parameter aMaximumPreviewPixelSize
- The maximum size of the returned preview size.
|
|
Top of Page
Copyright © 2013, The Apache Software Foundation, Licensed under the Apache License, Version 2.0. Apache, the Apache feather logo, Apache OpenOffice and OpenOffice.org are trademarks of The Apache Software Foundation. Other names may be trademarks of their respective owners.


{{ partial "head.html" . }}
{{ partial "nav.html" . }} {{ partial "boxes.html" . }}
{{ .Content }}
{{ partial "twitter.html" . }}
{{ partial "testimonials.html" . }} {{ partial "see_more.html" . }} {{ partial "clients.html" . }} {{ partial "footer.html" . }}
{{ partial "scripts.html" . }}


| Interface | Description |
|---|---|
| BatchItemCallback |
Interface to implement callback functionality for batches
when an item in the batch was processed.
|
| HITDataInput | |
| HITDataOutput |
| Class | Description |
|---|---|
| AbstractHITDataOutput | |
| HITDataBuffer | |
| HITDataCSVReader | |
| HITDataCSVWriter | |
| HITDataReader | Deprecated |
| HITDataWriter | Deprecated |
| HITProperties |
The HITProperties class provides a structured way to read HIT properties
from a file.
|
| HITQuestion |
The HITQuestion class provides a structured way to read a HIT Question XML
from a file.
|
| HITQuestionHelper |
The HITQuestionHelper class provides helper methods for HITQuestion.
|
| HITResults |
The HITResults class provides a way to hold Assignment results for a particular HIT.
|
| HITTypeResults |
The HITResults class provides a way to hold HIT results for a particular HIT Type.
|
| MTurkConstants | |
| QAPValidator |
Validate a Turk QAP file using the Turk XSD schema Requires a copy of the
Turk schema "QuestionForm.xsd" in the current directory available from:
http://mechanicalturk.amazonaws.com/AWSMechanicalTurkDataSchemas/2005-10-01/QuestionForm.xsd
|
| XhtmlValidator |
| Enum | Description |
|---|---|
| HITProperties.AssignmentField | |
| HITProperties.HITField |


Select Column module which allows you to choose a column of data to visualize.
Input Ports
Name Type Description Colums_In Data_Array Columns to select Parameters
Name Type Description UI Control labels string Name of Column. Field selected int Flag depicting selected column. Radio Box Output Ports
Name Type Description Columns Out Data Array Selected Columns are output.
This project contains a definition of a module which allows the user to select columns of data. The input data for this module is a table
Columns_In
Data_Array that provides the columns to select from. This Data_Array can be provided by the Read_Column_File module.
labels
String parameter which specifies the title of the column of data selected.
selected
Integer parameter that specifies which column of data has been selected.
Columns Out
Integer output specifying the columns that the user has selected.
The SelectColumnFunc functional macro uses the SelectColumnCore low-level module. The SelectColumn user macro uses this functional macro and the SelectColumnUI user interface macro. All of these macros use the SelectColumnParams parameter block to communicate parameters between themselves.
One example application is provided with the SelectColumn project. The SelectColumnApps example application reads in a data file and allows the user to select various columns.
xp_comm_proj/selcol/scolmods.v Creates the SelectColumnMods library containing the low-level SelectColumnCore module and the SelectColumnParams parameter block.
xp_comm_proj/selcol/scolmacs.v Creates the SelectColumnMacs library containing the user interface macro SelectColumnUI, The functional macro SelectColumnFunc and the high-level user macro SelectColumn.
xp_comm_proj/selcol/scolapps.v Creates the SelectColumnApps library containing the example application SelectColumnEg.
Mary McDerby, Manchester Visualization Centre Tobias Schiebeck, Manchester Visualization Centre


Son-of-Spectro (SOS) Documentation
This document desribes the real-time reductions of spectroscopic data
taken with the SDSS 2.5-m. These reductions are robotically posted
to the
SOS web page and archived at the
Princeton mailing list.
In this document:
Related documents:
Son-of-Spectro is a cron job that runs from the "observer" account
on "sos.apo.nmsu.edu". It should always be running, and
should even recover (as any cron job) if that machine is power-cycled.
It has been run previously on the machines "hoggpt.apo" and
"plate-mapper.apo".
Log into "sos.apo" as user "observer". Check if the SOS is running
by typing:
% sos_status
If it is not running, then you will see a response beginning with:
The Son-of-Spectro cron job is NOT running for USER=observer MACHINE=sos.
If it is running, then you will see a response beginning with:
The Son-of-Spectro cron job IS running for USER=observer MACHINE=sos.
This is then followed with some other information that may be useful
for trouble-shooting.
To start up SOS, type:
% sos_start
To stop up SOS, type:
% sos_stop
All of these commands can also be run from a remote machine.
A second argument should be the machine name with an optional user-name, i.e.:
% sos_status sos
% sos_status<EMAIL_ADDRESS>Note that the following directories should exist on sos.apo and be
write-able by the observer account:
/data/spectro
/data/spectro/astrolog
/data/spectro/spectrologs
/data/spectro/spectrologs/html
Note that the following link should exist if running on sos.apo:
ln -s /usr/local/www/data /data/spectro/spectrologs/html
Note that the following link should exist if running on hoggpt.apo:
ln -s /data/spectro/spectrologs/html /usrdevel/skent/inventory/www/apo2d
Note that the following link should exist if running on plate-mapper.apo:
ln -s /data/spectro/spectrologs/html /home/skent/inventory/www/apo2d
-
You can run a different version of Son-of-Spectro by setting up
the relevant version of idlspec2d before you launch it with "sos_start".
This should be done from the "observer" account on "sos.apo.nmsu.edu".
Check which version of the code is being run with:
% sos_status
Stop this version from running with:
% sos_stop
-
Wait a minute or two for any running SOS reductions to complete.
-
The output files of different versions of Son-of-Spectro
can be incompatable with one another.
We recommend deleting (or at least renaming) the
current working directory:
mv /data/spectro/spectrologs/$MJD /data/spectro/spectrologs/$MJD.old
The file whose existence will cause a new version of code to crash is:
/data/spectro/spectrologs/$MJD/logfile-$MJD.fits
-
Now set up and start the new version:
% setup idlspec2d v4_9_1
% sos_start
If you type "sos_status", it should tell you which version is now running.
Note that Son-of-Spectro is actually general enough to be run from any
account on any remote computer. The only requirements are as following:
- The directory /data/spectro must exist on the remote machine,
and be write-able by the user.
- This user@machine must have permission to copy files with "ssh"
"from sdsshost.apo.nmsu.edu". This must be set up to work without
typing a passphrase.
Follow the instructions for
CVS install w/UPS and evilinstall.
This is the short-cut to installing code using UPS. It will cvs-export
code, build it, install it, and declare it current. If the code is already
installed, then it simply declares it the specified version current.
At APO, install both on the SOS machine (currently sos.apo), and
on sdsshost.apo. This is because the documentation on the sdsshost.apo
procedures web page is linked to the installed version on that machine.
Now you are ready to launch this new version of the code.
Son-of-Spectro is a cron job that runs from the "observer" account
on "sos.apo.nmsu.edu". This cron job invokes rsync once
every minute to copy raw spectro data from "sdsshost" to "sos.apo",
then launches a package of shell scripts and IDL commands to reduce
the data one frame at a time. It is part of the idlspec2d data product.
There are actually two rsync processes that run, one for the blue
camera images and one for the red. We did this so that both processors on the
computer can be utilized. All 4 cameras should be reduced for an exposure
within a few minutes.
The raw data is copied into these directories on sos.apo:
/data/spectro/astrolog/$MJD - Copy of the same from sdsshost
/data/spectro/$MJD - Copy of /astrolog from sdsshost
The data reduction is not the same as the full-up spectroscopic pipeline.
A number of shortcuts are taken to speed up the reductions and make them
very robust. For example, boxcar extraction of the spectra is used instead
of optimal extraction.
The reduced data will appear in the directory:
/data/spectro/spectrologs/$MJD
Files like the following can be found in that directory:
splog-b1-00006541.log - Text history of exp #6541 reduction
tset-51795-0389-00006541-b1.fits - Fiber traces (from flat exposure #6541)
wset-51795-0389-00006542-r1.fits - Wavelength solution (from arc exp #6542)
fflat-51795-0389-00006542-b1.fits - Flat-field vectors (w/ arc exp #6542)
sci-0389-b2-00006546.fits - Science spectra for plate 389 (exp #6546)
logfile-51795.fits - Summary info for night in FITS format
logfile-51795.html - Summary info for night in HTML format
snplot-51795-0389.ps - Signal-to-noise plot for nplate 389
If a particular frame does not get reduced and appear on the Son-of-Spectro
web site, then you can look at its log file (splog*.log). If the file
does not end with the line "Finished at", then that exposure must have
crashed.
The HTML files and S/N plots for the web page are copied into the directory:
/data/spectro/spectrologs/html
The most recent HTML file has a second copy as the file "logfile-current.html".
This is the file pointed to by the
SOS web page.
The following FITSheader cards are required to be correct for either
Son-of-Spectro or Spectro-2D to reduce the data properly.
The AIRMASS is not read from the header, but computed from RADEG,DECDEG
and the TAI-BEG,TAI-END keywords.
EXPOSURE= Exposure number. We always override the value of this keyword
with the exposure number in the file name.
CAMERAS = Camera name, e.g. "b1". We always override the value of this keyword
with the exposure number in the file name.
FLAVOR = The flavor of the observation, which can be "bias", "dark",
"arc", "flat", and "science" or "target". Files with other
flavors, such as "unknown", are not reduced.
MJD = MJD of observation, which must agree with the directory in which
the file resides, "/data/spectro/$MJD".
PLATEID = The plate ID, which must match that in the NAME header card.
NAME = Plug name, e.g. "0328-52277-01" for plate 328, plugged on 52277
with a plugging ID of 01. We assume that there is a plug-map
file at APO with the name "/astrolog/$MJD/plPlugMapM-$NAME.par".
EXPTIME = The exposure time, which is used along with TAI-BEG to compute
the airmass. It is also used to determine whether the sky
brightness or scattered light is larger than tolerances.
TAI-BEG = The TAI time for the beginning of the exposure, which is used
to compute the airmass and sky-brightness gradients for sky-
subtraction. If this keyword is missing, we guess it from
EXPTIME and TAI.
TAI-END = Used with TAI-BEG. If this keyword is missing, we guess it from
EXPTIME and TAI.
TAI = This keyword is used if TAI-BEG,TAI-END are missing.
FFS = Flat-field screen positions, which should be
"0 0 0 0 0 0 0 0" for science exposures (all petals open)
"1 1 1 1 1 1 1 1" for flat or arc exposures (all petals closed)
FF = Flat-field (quartz) lamp status, which should be
"0 0 0 0" for science or arc exposures (all off)
"1 1 1 1" for flat exposures (all on)
NE = Neon lamp status, which should be
"0 0 0 0" for science or flat exposures (all off)
"1 1 1 1" for arc exposures (all on)
HGCD = HgCd lamp status, which should be
"0 0 0 0" for science or flat exposures (all off)
"1 1 1 1" for arc exposures (all on)
OBSCOMM = This keyword is used to identify the dithered flat sequence
taken in the Monthly Checkout with the "specFlats" script in SOP.
The flats in this sequence must have OBSCOMM="{dithered flats-flat}".
The arcs in this sequence must have OBSCOMM="{dithered flats-arc}".
This keyword also identifies the Hartmann focus exposures, with
the entries OBSCOMM="{focus, hartmann l}" or "{focus, hartmann r}".
Science exposures all have OBSCOMM="science ".
QUALITY = The observer-input quality for an exposure: "excellent", "test",
or "bad". Exposures are declared "test" or "bad" using the
APOFIX procedure.
The following FITS header cards are informational. We would very much
appreciate the observers to correct errors in these keywords so that
our book-keeping of survey progress is done properly:
TILEID = Tile ID for this plate from the plug-map file
CARTID = Cartridge ID number (1 through 9)
RA = Right ascension of telescope boresight (in degrees)
DEC = Declination of telescope boresight (in degrees)
RADEG = Right ascension of plate center for plug-map file (in degrees)
DECDEG = Declination of plate center for plug-map file (in degrees)
AIRTEMP = Temperature (deg C)
Incorrect FITS header cards for the raw spectro sdR files can be
corrected by adding entries in the sdHdrFix file
"/astrolog/$MJD/sdHdrFix-$MJD.par". The interesting header cards
from these files can be listed with the
APOHEADER
procedure run from the IDL prompt on sos.apo. The proc
APOFIX
can be used to add entries to the sdHdrFix file to denote edits.
This structure should have the following definition in the sdHdrFix file:
typedef struct {
char fileroot; # Root of file name, without any ".fit" suffix
char keyword; # Keyword name
char value; # Keyword value (as a string)
} ophdrfix;
Following are some examples of what should appear in the sdHdrFix files
in order to correct faulty headers. (The typedef struct above must
also be in the file.)
-
Example 1: The exposure time is in the file sdR-b1-00001142.fit should be
60 seconds:
ophdrfix sdR-b1-00001142 EXPTIME 60
-
Example 2: Exposure number 1234 was bad, and should be given an 'unkown'
flavor for all cameras:
ophdrfix sdR-??-00001234 FLAVOR "unknown"
-
Example 3: The mapping name for all cameras of exposures 1137-1139
should be '0198-51433-01':
ophdrfix sdR-??-0000113[7-9] NAME "0198-51433-01"
-
Example 4: Telescope status information is missing for the pre-flat
exposure 10850:
ophdrfix sdR-??-00010850 FFS "1 1 1 1 1 1 1 1"
ophdrfix sdR-??-00010850 FF "1 1 1 1 "
ophdrfix sdR-??-00010850 NE "0 0 0 0 "
ophdrfix sdR-??-00010850 HGCD "0 0 0 0 "
If you have edited the sdHdrFix file and need to re-reduce an exposure,
you can do so with the sos_redo command.
When Son-of-Spectro reads in the raw FITS files, it then patches the
headers with the information in the ophdrfix entries of the sdHdrFix file.
But note that the one piece of information that cannot be patched this
way is MJD, since we need the MJD in order to find the correct sdHdrFix file!!
Son-of-Spectro reduces four flavors of observations:
bias/dark, flat, arc, & science/smear. Select information is tabulated
for each of these types of observation. These values are tabulated in
yellow
if they are going out of spec, and in
red
if they are very much out of spec.
The values reported are:
- BIAS/DARK PERCENTILE98
The value in electrons of the 98-th percentile on the (overscan-corrected)
image. For example, if this is 8, then 98% of the pixels are below 8
electrons. Bad regions on the CCD and saturated pixels are excluded
from this evaluation.
The CCDs can also accumulate charge during the day that may need several
bias exposures to completely flush. If this does not work, then the
CCD is probably warm.
- FLAT NGOODFIBER
The number of illuminated fibers. This should be 320 if all the
fibers are plugged and unbroken. Note that fibers that fall on particularly
bad parts of the CCD can also be excluded from the good fiber list
(the red CCDs have some of these cases). If this number is less than
about 315, then you should be suspicious that some fibers have dropped out.
- FLAT XMIN (XMAX)
The minimum (maximum) X position of the spectra on the CCD. If this is
less than 0 (greater than 2047), then some of the spectra fall off the
left (right) side of the CCD. This probably means that no one ran
the Spectro Monthly Checkout. If it is off by more than 5 pix or so,
you should probably run the Monthly Checkout.
- FLAT XSIGMA
The profiles in the spatial (X) dimension have a gaussian fit with
a width of this sigma. The median of this width is taken independently in
each of 4 quadrants on a CCD, and the maximum of those 4 values reported.
If the spectrographs are in focus, then this value should be about 1.0 pix.
If it is larger, then the spectrographs may be out-of-focus, or the
slit-heads may not be properly latched.
- ARC WAVEMIN (WAVEMAX)
The minimum (maximum) wavelength (in Angstroms) of any spectra on this CCD.
Because of the optical distortions, this is always for the central
fiber. The edge fibers have less wavelength coverage.
This probably means that no one ran
the Spectro Monthly Checkout. If it is off by more than 5 pix or so,
you should probably run the Monthly Checkout.
- ARC BESTCORR
The linear correlation coefficient between the arc spectra and a template
arc spectrum. If they agree perfectly, then this is 1. The value of
this correlation is typically 0.80. If it drops too much lower, then
the arc spectra do not look as they should. This could happen if
the arcs did not turn on, the flat field screens did not close, or some
of the arc lines are missing -- if, for example, the Hg lamps all failed.
If the correlation is less than 0.5 or so, then it's even possible that
the code has found the incorrect wavelength solution.
- ARC NLAMPS
The number of arc lines used to generate the wavelength solution.
There are many more on the red CCD's because neon has many more lines
there. If this drops to too few lines, then some of the lamps have not
turned on properly, have not warmed up, or have warmed up too much.
- ARC WSIGMA
The arc-line profiles in the wavelength (Y) dimension have a gaussian
fit with a width of this sigma. The median of this width is taken
independently in each of 4 quadrants on a CCD, and the maximum of
those 4 values reported.
If the spectrographs are in focus, then this value should be about 1.0 pix.
If it is larger, then the spectrographs may be out-of-focus, or the
slit-heads may not be properly latched.
(One would expect that both XSIGMA and WSIGMA would go out-of-focus
at the same time.)
- SCIENCE/SMEAR SKY/SEC
The median sky counts in electrons per pixel.
If this is too large, then there must be a light source near the
telescope, or the night sky (the moon) is bright, or the CCD's are
warming up and generating dark current.
- SCIENCE/SMEAR (S/N)^2
The signal-to-noise squared for objects at the fiducial magnitude limit.
We choose (S/N)^2 because it is an additive quantity with additional
integration time. When all the cameras reach a total (S/N)^2 of 15,
then all these entries turn from red to black, and
we can declare a plate done. Exactly how this quantity is
measured is described below.
- EXPTIME
The exposure time (EXPTIME) header keyword from the first camera
of this exposure to be reduced. The assumption is that all 4 cameras
have the same EXPTIME.
- AIRTEMP
The air temperature (AIRTEMP) header keyword from the first camera
of this exposure to be reduced. The assumption is that all 4 cameras
have the same AIRTEMP. We think this is the temperature from
the galileo weather station.
- UT
The UT time computed from TAI in the header from the first camera
of this exposure to be reduced.
- QUALITY
This is the observer-input quality for this exposure.
It can be set independently for each of the 4 cameras, but only one
camera value (the first reduced frame) is reported in this table.
The default value is "excellent" for everything except for dithered
flats or spectro focus frames which are "test". The observers have
the option of declaring exposures "excellent", "test", or "bad"
using the APOFIX command.
The exact values of these yellow/red limits and further explanation can
be found in the "idlspec2d" product in the file "examples/opLimits.par".
There are a number of
WARNING
and
ABORT
messages that can appear if the pipeline runs into trouble when processing
a frame. These messages appear at the bottom of each table.
Each one-line message begins with the relevant file name, WARNING or ABORT,
then a brief plain-text message.
Note that a single problem may cascade into a large number of warning
messages. For example, an out-of-focus spectrograph will first produce
the "Median spatial widths" message, probably followed by warnings about
bad sky-residuals.
The following messages may appear:
- Error reading sdHdrFix file
The sdHdrFix file (sdHdrFix-$MJD.par) in sos.apo:/data/spectro/astrolog/$MJD
exists but is not a valid Yanny parameter file. This file is written
by the IDL procedure
APOFIX
if the observers' have run that proc on sos.apo, but can also be edited
by hand. If the file is invalid, you should edit it to be valid,
or delete it. If the
APOFIX
command somehow generated an invalid file, then file a PR against sospectro.
- Exposure number in header disagrees w/filename
This means that IOP/SOP is in a very confused state, and it
is putting a different exposure number in the header (EXPOSURE
keyword) from what is being used to generate file names.
You should probably exit SOP, re-start SOP, then issue a "goStare -init".
- Sun above the horizon by ... deg for non-test exposure
This warning message is to trap flat, arc, or science exposures taken
during the day that have not been marked as either "test" or "bad" data.
If these are test data, be sure to mark them as such. This is to prevent
such data from being used later in the full reductions.
- Amp #... expected read noise = ..., measured = ... DN
The number reported is the standard deviation in the bias region
for either amplifier #2 (left side) or amplifier #3 (right side).
This calculation is done clipping the half-percent of lowest and
highest values. We trigger this warning if the value is ever 1.0 DN
above the expected value. This can happen
if there are a huge number of cosmic rays (if you've been integrating
for hours), or if there is an electronics problem. This would pick
up the problem seen on 22/23 Aug 2000 (MJD 51779) when the left amplifier
on r2 was randomly flipping bits (c.f., PR #2335). Or, the problems
seen in Aug 2004 (PR #6143), when r2 was digitally mixing bits between the
left and right amplifiers.
- Amp #... bias region difference at xxx-th-percentile =... DN
This measures another statistic of the bias region for either
amplifier #2 (left side) or amplifier #3 (right side).
This measures the difference between the 16th-percentile and
84th-percentile, which should be equal to twice the read noise
(e.g., 1-sigma). This test is done at the 68.2-percentile (1 sigma),
95.4-percentile (2 sigma), and 99.7-percentile (3 sigma).
A warning is reported if this difference is either significantly too
small or too large, as compared to what gaussian statistics dictate.
This should catch the same sorts of electronics problems as listed
for the above warning message.
- Amp #... way too many pixels (xxx%) below bias-5*sigma=... DN
This test looks for anomolously low pixel values in the data region
of the CCD. There should essentially never be any pixel values below
5-sigma less than the bias level, unless there is something wrong with
the electronics. This did happen in Aug 2004 (see PR #6143).
- Fixing shifted rows (from electronics)
This is very, very bad. This is indicative of an electronics problem
that we first saw on MJD=51578 to 51580 (3 to 5 Feb 2000).
The raw images have rows shifted to the right, sometimes by
many pixels. Call Connie immediately.
- Fixing dropped-pixel rows (from electronics)
This is very bad. This is indicative of an electronics problem
that we first saw on MJD=51688 (23 May 2000).
The raw images actually have some rows shifted by 1 or 2 pixels,
usually more so near the bottom of the CCD (the first rows to be read).
Call Connie immediately.
- More than 10% of the image is rejected
This is very bad. This can probably only happen if most of the CCD
has saturated pixels, which probably means you're observing during
twilight, the CCDs are warm, or the dome lights are on.
- Flat-field screens not closed
The "FFS" keyword in the header indicates that at least one of the
flat-field petals was not closed. When this happens, the flat or arc
is not reduced.
- Flat-field lamps not turned on
The "FF" keyword in the header indicates that at least one of the four
flat-field lamps was not turned on.
When this happens, the flat is not reduced.
- Reject flat (or arc) ... % bad pixels
This condition is triggered when more than 2% of the non-masked pixels
on the image are bad (saturated).
When this happens, the flat (or arc) is not reduced.
This probably happens if the CCDs are warm, the dome lights are on,
or if for some reason the shutters were open too long.
- Reject flat (or arc) ... saturated rows
This condition is triggered when there are more than 100 saturated rows
on the image.
When this happens, the flat (or arc) is not reduced.
This probably happens if the CCDs are warm, the dome lights are on,
or if for some reason the shutters were open too long.
- Reject flat as too faint
This condition is triggered when the 80-th percentile of the image
is less than 1000 electrons.
When this happens, the flat is not reduced.
Either the flat field screens were not closed, the lamps were not
turned on, or the shutter didn't open.
- Reject science ...
A science exposure can be rejected if the header keywords indicate
that the flat-field petals are closed, any flat-field or arc lamps
are turned on, too many pixels are bad or saturated, or if the
25-th percentile of the image too large.
- Possible Argon lines in superflat
Emission lines are present in the quartz-halogen flat-field images,
which are supposed to be featureless. When a number follows this message,
that is a measure of the line strength -- the trigger is set to 0.01,
but we usually see it as 0.1 to 0.5 when present.
We have identified these rogue lines as argon.
JEG's best guess is that these
contaminating lines come from trace amounts of argon in the HgCd lamps,
which must still have current running through them when they are supposed
to be off. We can still reduce the data with these lines, but you should
re-open PR 1859 if this problem is seen again.
- Arc lamps not turned on
The "NE" and "HGCD" keywords in the header indicates that either the
neon or HgCd lamps are not fully turned on.
When this happens, the arc is not reduced.
- Best arc correlation = ...
The cross-correlation of the arc spectrum with the template arc spectrum
was bad. This problem also triggers BESTCORR as bad in the table (see
above). This may be due to too little signal in the lamps, e.g. if
the flat field petals did not close or the lamps did not turn on.
If those are not the problems, then look at the raw image.
- Big wavelength gap
Some arc lines were not found in the arc spectra, and there is a large
gap in wavelength space without any lines. This will produce a poor
wavelength solution. More arcs should be taken until this message
does not appear.
- Scattered light
There was a high baseline count rate on the CCD, and appears even
between fibers. This can most obviously occur if there are light
sources in the CCD (such as the LED's we had for some time), or
if the CCD's are warming up and generating dark current.
There can also be a scattered light contribution just from a very
bright sky, or if there are super-bright objects on some fibers that
are scattering or bleeding light across the CCD.
It's best to carefully inspect the raw images for problems
(see Displaying Spectra at APO).
- Median spatial widths = ...
The spatial (X) widths of the fibers typically are gaussians with a
sigma of 0.85 to 1.05 pixels. If the sigma is larger than 1.10 pixels
in any of the 4 quadrants of a CCD (lower-left, lower-right, upper-left,
upper-right), then this warning is triggered. It means
that either the spectrographs are out of focus, or the slit-heads are
not properly latched. Note that these widths are computed for both
the flat and science exposures (but not for arcs -- we compute the
widths in the dispersion dimension for arcs, and not for smears since
they have low S/N).
- Median wavelength widths = ...
The widths of the arc lines in the dispersion (Y) dimension typically
are gaussians with a sigma of 0.90 to 1.10 pixels.
If the sigma is larger than 1.10 pixels
in any of the 4 quadrants of a CCD (lower-left, lower-right, upper-left,
upper-right), then this warning is triggered. It means
that either the spectrographs are out of focus, or the slit-heads are
not properly latched.
- Too few sky fibers to model sky-sub variance
There are not enough good sky fibers on the CCD. This will only happen
if for some reason there were far fewer than the mandated 16 sky fibers
on a CCD, or most of those fibers just happened to be dead fibers.
You should never see this message. If you do, the data is un-reducable.
You could try one more exposure, but something is probably horribly
wrong with this plate.
- Airmass range = ...
This warning is triggered if the airmass exceeds 2.5. At such large
airmasses, the atmospheric refraction terms are getting large and the
sky background is bright. The data is still perfectly usable, it's
just not as good as taking data at lower airmass. Keep observing if
you must, but the airmass will rapidly approach infinity!
- Large flexure flat<->science
There is a large shift (more than 0.15 pix) between the flat-field and
the science exposure, presumably from flexure in the spectrographs.
When this happens, another set of flat-fields (post-calibs) is
recommended. (However, don't bother to take a set of calibrations
on a different night. The Spectro-2D reductions never use calibrations
from one night for science exposures on another.)
- Whopping fiber ....
The fibers listed have very bright objects that affect their neighbors
on the CCD. If the objects are bright enough (12th mag?), then this can
trigger other warnings such as "scattered light". I think it's safe
to say that whopping fibers only show up when there has been a mistake
made in the plate designs -- this is already recorded in PR 2471.
You should check that this object does not saturate (> 30,000 ADU)
the raw sdR image
(see Displaying Spectra at APO).
Should it be saturating, reduce the exposure time to prevent saturation
or move on to the next plate.
- Wrong number of elements for REDDEN_MED
This is a warning that the reddening vector for this plate (reddeningMed
in the plPlugMapM file) is not a 5-element vector, as expected).
In this case, reddening values of zero are assumed. This means that
the plate will not be observed as deep as it would have if non-zero
reddening values were provided.
- SOS disk is ...% full
The specified disk on sos.apo is more than 95% full. This could be
either the disk used to copy the raw sdR images from sdsshost.apo,
or the disk used for SOS outputs (/data/spectro/spectrologs/$MJD).
If you must clean out old data, do not delete files from sos.apo
whose original copies still exist on sdsshost.apo or they will be
re-rsynced and re-reduced
(see How Son-of-Spectro Works).
You could delete files from a previous night first on sdsshost.apo,
then from sos.apo.
The following warning messages are all based upon the quality of
the sky-subtraction. Typically, we are able to model the sky spectrum
(from the 16 sky fibers on each spectrograph) with a relative chi^2
of around unity. At very bright sky lines, like 5577 Ang, the relative
chi^2 may be as large at 25. If the relative chi^2 is large at
other wavelengths, this means that there is excess light down the fibers
that varies across the plate. This could be due to a light source near the
telescope, or possibly a bright, non-uniform sky. Strong auroral activity
is something that can do this, since the O I lines at 6300 and 6366 Ang
are resolved on the sky.
- Median sky-residual chi2 = ... at ... Ang
The median reduced chi^2 for sky-subtraction is always around unity.
If it is greater than 2, this message is triggered. If this message
appears and you are not observing during twilight or with warm CCDs,
then there must be a serious problem. Seriously out-of-focus
spectrographs might trigger this, or lights on near the telescope.
- Max sky-residual chi2 = ... at ... Ang (ignoring 5577)
This is an informational message triggered if the reduced chi^2 is
greater than 100 anywhere other than at the 5577 Ang sky line.
If there is auroral activity, then this could be triggered at a few
specific lines like O I at 6300 and 6366 Ang. These O I lines has
reduced chi^2 values of about 100 on MJD 51999 during a solar storm
(i.e. plate 336/51999).
The Spectro-2D pipeline will automatically mask these wavelengths
for any down-stream analyses.
- Bad sky residuals at ....
This warning is triggered if there is a range of at least 25 Angstroms
with a reduced chi in the sky-subtraction worse than 2.
This could be due to a light source near the telescope, a bright,
non-uniform sky, a warm CCD, scattered light, or out-of-focus spectrographs.
For most of those cases, there should be other relevant warning messages
preceding this one (like a warm CCD message).
This message should be ignored at the edges of the CCDs
wavelength coverage -- near 3800 or 6200 Ang for b1,b2 or near
5800 or 9200 Ang for r1,r2 (c.f. PR 3656).
If none of the above explanations apply, then there is some real problem.
I would look at the images and/or spectra to look for any obvious problems,
and file a PR against sospectro
(see Displaying Spectra at APO).
Might as well keep observing?
- Red Monster at ....
This warning is triggered if we see bad sky residuals (above) that
is specifically in the wavelength range of about 6400-6600 Ang.
We think this happens when the handpaddle is still plugged in,
in which case the observers should unplug it immediately.
The treshhold is set at reduced chi=2, and the worst that we have ever seen
is at about the level chi=6. The last time we definitively saw this was on
plate 426 on 3/4 Dec 2000 (MJD 51882).
You should be able to see a bump in the extracted spectra, especially
for the sky fibers
(see Displaying Spectra at APO).
If you cannot find the source
of the excess light, keep observing but file a PR against sospectro.
If the reduction of an exposure is catastrophically bad, it may not
appear at all in the Son-of-Spectro table. However, there should still
be a log file for this exposure on the sos.apo computer:
/data/spectro/spectrologs/$MJD/splog-$CAMERA-$EXPOSURE.log
Reading this file should tell you what failed. The first and last lines
of these files should contain "Started at" and "Finished at"
followed by timestamps.
A median signal-to-noise is computed for each object in the
wavelength ranges [4000,5500] Angstroms (synthetic g-band)
and [6910,8500] Angstroms (synthetic i-band).
We plot these S/N values versus the PHOTO fiber magnitudes, which were
measured in approximately a 3-arcsec diameter aperature (the same size
as our fibers). If everything is working perfectly, then our S/N values
should correlate very well with these PHOTO magnitudes.
We determine whether a plate is "done" based upon the signal-to-noise
of the fainter objects on the plate. We do this by fitting a line to
the (S/N)-vs.-magnitude plot in a specified wavelength range, then evaluating
this fit at g=20.2 mag (blue CCDs), and i=19.9 mag (red CCDs).
Approximately 10% of the main galaxy sample, 60% of the BRG's and 15% of
the QSO's are fainter than g=20.2. Very few objects (1, 1, and 5%) are
fainter than i=19.9.
When the sky level is higher, we gain S/N more slowly at
the fainter magnitudes where we are sky-limited rather than photon-limited.
Without moon, we have typically found:
log(S/N_g) = (zeropoint) - 0.31 * g
log(S/N_i) = (zeropoint) - 0.31 * i
With partial moon, the slope steepens to -0.34 or worse.
The fitting regions are denoted on the plot with vertical dotted lines.
Arrows point to the evaluation of the fit on each of the 4 cameras, with
the top panels corresponding to the blue CCD's (synthetic g-band) and
the bottom panels corresponding to the red (synthetic r-band).
The thick blue line on the figure is only a meaningless, fixed reference line.
The right-hand figures plot the residuals of each object from the fit.
Symbol sizes on those right-hand plots indicate the magnitude of the
deviation from the fit line. Symbol color is the same on the left
as on the right, so
green
objects have more flux and
red
ones less.
If the scale of the telescope is wrong, then you will see a radial drop-off
in flux (red points on the edge of the plate).
If you are observing too far over in air mass, then typically you correct
to first order with a scale change, but a quadropole is left in these
residuals.
If one spectrograph has problems, then this will show up as red points
in half of one of these figures.
Note that the (S/N)^2 totals listed in the table and the figure might
not exactly agree. This is because the fitting to (S/N)-vs.-magnitude
is done on individual frames for the table, but on the summed S/N over
all frames for the figure. The tabulated values are the ones we use
to declare a plate done.
The Son-of-Spectro (SOS) reduction robot has proven to be quite robust.
However, if it appears to not be working one could check the following:
- Has a "loadCartridge" command been issued?
If this has not been done from SOP, then there is no PLATE entry
in the images. This prevents SOS from reducing anything but bias
and dark frames.
- Is the cron job running?
Log into<EMAIL_ADDRESS>and issue a "sos_status"
command. This should report that SOS is running.
If not, then restart the cron job.
- Is the data being copied over?
The raw data files should be copied from "sdsshost" to "sos.apo"
in the /data/spectro/$MJD directory. If it is not, then the disk
may be full (see SOS disk is full warning message).
Or, the rsync command may not be working.
This could be due to a rogue
"aporsync" process sitting around. The "sos_status" command will
report any such processes.  It's a harmless thing to do, since
SOS will just start it up again within a minute.
- Are there old "lock" files sitting around?
SOS generates "lock" files to prevent multiple processes from changing
these files simultaneously. The "sos_status" command will report
all "lock" files and their last modification times.
If any have been sitting around for several minutes or more,
then something is wrong. You should delete the file ending with ".lock".
However, this could result in a corrupted "logfile*.fits".
- Is the IDL license manager running?
You can issue the following command to check that the IDL license
manager is indeed running:
% $IDL_DIR/bin/lmstat -a
This should display the number of licenses available, and the current
number in use. The server running on galileo.apo has 110 licenses,
each IDL session uses 6, so there can be at most 18 IDL sessions
running concurrently. Note that Son-of-Spectro, the fiber mapper,
and HoggPT all use IDL licenses.
- Is anything amiss with running the scripts?
Perhaps there is a communication problem between sdsshost.apo and sos.apo,
or a problem running the code on sos.apo. There is logging information
written once per minute into the file
/data/spectro/spectrologs/sos.log
which may indicate such problems.
- Is the logfile corrupted?
This is probably the worst thing that could happen. If the file
/data/spectro/spectrologs/$MJD/logfile-$MJD.fits
gets corrupted, then SOS will repeatedly crash. One could just
delete this file, which would basically wipe out all the previous
reductions for that night from the web page. Alternatively, one
could delete all the raw and reduced data for that night from
"sos.apo" (but not from sdsshost.apo!). Best to stop the SOS robot
before doing this:
% sos_stop
% sos_status <-- Wait for any running processes to complete.
% rm -rf /data/spectro/spectrologs/$MJD
% rm -rf /data/spectro/$MJD
% sos_start
That might sound extreme, but SOS will simply start re-copying
everything from "sdsshost" and re-build the reductions for the night.
Obviously, this could take a couple of hours if its already late
into the night.
There is a mechanism to re-reduce exposures with "sos_redo".
You may need to do this if a reduction failed, or the pre-calibs failed
and SOS could not reduce the science exposures, or if you needed
to edit the sdR header information by putting entries in the sdHdrFix
file (see APOFIX).
It is fastest to only re-reduce a specific exposure number.
To force a re-reduction of exposure number 12345 on all 4 cameras
(whether it has already been reduced or not) use the EXPNUM option:
% ssh<EMAIL_ADDRESS>% sos_redo expnum=12345
If you want to find and reduce only failed reductions for a plate
use the PLATE option. This may take several more minutes because
all of the FITS headers for the night are parsed.
To re-reduce only missing exposures for plate 666:
% ssh<EMAIL_ADDRESS>% sos_redo plate=666
The last exposure taken is not re-reduced unless explicitly told to
with the EXPNUM option. Currently, either EXPNUM or PLATE must be
specified.
Note that science exposures for a plate cannot be reduced until both
flat and arc exposures have been successfully reduced for that same plate.
This is from version $Name: v5_2_0 $ of procedures.
Maintained by
David Schlegel
and Scott Burles


2 endangered Florida panthers found dead
by Associated PressLABELLE, Fla. (AP) – Two endangered Florida panthers have been found dead in as many days, bringing the total number of deaths this year to 26.
The Florida Fish and Wildlife Conservation Commission says the remains of a 4-month-old female were collected last Thursday on a road running through Okaloacoochee Slough State Forest, and the remains of a 4-year-old male were collected last Wednesday west of Felda. Both were killed by vehicles.
Florida panthers once roamed the entire Southeast, but now their habitat mostly is confined to a small region of Florida along the Gulf of Mexico. Up to 230 Florida panthers remain in the wild.


Xiaomi CC9 Pro with 108MP camera - Complete specs now available - Gizchina.com
by Efe UdinXiaomi CC9 Pro with 108MP camera – Complete specs now available
4.2 (83.48%) 23 votes
Chinese manufacturing giant, Xiaomi, will hold a launch conference in China on November 5th where the company will release its latest flagship – Xiaomi CC9 Pro. Over the past few days, there has been a lot of speculations and confirmations regarding this smartphone. However, putting all the information together, we now have a fairly complete spec sheet of this upcoming flagship.
Design & Appearance
The upcoming Xiaomi CC9 Pro comes with a new slightly curved display design. When there is an incoming call or notification, the curves on the display will emit dazzling lights. This gives the phone a premium and cool appearance. It boasts of a hyperbolic waterdrop 6.47-inch AMOLED display with a Full HD+ resolution. The CC9 Pro comes with a Corning Gorilla Glass 5 protection on both front and back. In addition, it uses an on-screen fingerprint scanner for biometric authentification. This smartphone will be available in green and white colour options.
Hardware & Battery
Defiling the rumors of SD855, the Xiaomi CC9 Pro will come with a Qualcomm Snapdragon 730G chip which uses the same architecture as the Snapdragon 855. It is built with the 8nm process technology and when compared with the previous generation performance, there is a significant improvement. The CPU is 35% better, GPU 25% better and the AI performance 2 times better.
The Snapdragon 730G is based on Snapdragon 730 but its GPU is optimized for gaming This is an upgrade for gamers as it enhances GPU performance and DSP image rendering speed. It supports the Snapdragon Elite Gaming function and the GPU frequency is higher than Snapdragon 730. This smartphone comes with 6GB/8GB/12GB of RAM and 64GB/128GB/256GB of internal storage.
To keep its lights on is a 5260 mAh battery which supports 30W fast charge. Although Xiaomi has a few phones with a higher battery size (e.g. Mi Max 3 – 5500 mAh), the 30W fast charge of the CC9 Pro’s 5260mAh batter makes it better. Although the power does not seem to be large, it can fully charge in 65 minutes.
Camera
This smartphone will come with Penta-rear camera setup, while a 32MP selfie shooter sits within the water-drop notch upfront. Speaking of the rear cameras, the Xiaomi CC9 Pro is well on the way to be the first smartphone with a primary 108MP ISOCELL HMX CMOS sensor.
It is the world’s first large-size dynamic image sensor with a 1/1.33 inch photosensitive area, which can be used in low light conditions. It captures more light than other small sensors. The 108MP sensor output images with a resolution of 10000 x 11852 and the size per image easily exceed 20MB. The other four cameras include a 12MP portrait sensor with 10x optical zoom, a 5MP sensor with 50x digital zoom, a 20MP super wide-angle lens, and a 2MP 1.5cm super macro lens. According to Xiaomi, the two optical anti-shake systems ensure that the telephoto lens is stable, and the second is to shoot a better super night image.
Software & Other Features
This device will come with MIUI 11 based on Android 10 out of the box and we will a USB Type-C interface as well as a 3.5 mm headphone jack.
Price and Availability
According to Xiaomi, the hardware cost of the Xiaomi CC9 Pro is very high. The cost of the camera module alone is five times that of the previous generation CC9. Having considered the specs and features of this smartphone, experts believe that it will not cost less than 3000 yuan ($425). Nevertheless, there is no official statement on its pricing for now.


Shop the Apple Online Store (1-800-MY-APPLE), visit an Apple Retail Store, or find a reseller. Apple Info | Site Map | Hot News | RSS Feeds | Contact Us
Copyright 2014 Apple Inc. All rights reserved. Terms of Use Updated Privacy Policy


pymatgen.io.abinit.nodes module¶
This module defines the Node class that is inherited by Task, Work and Flow objects.
-
class
Dependency
(node, exts=None)[source]¶ Bases:
object
This object describes the dependencies among the nodes of a calculation.
A Dependency consists of a Node that produces a list of products (files) that are used by the other nodes (Task or Work) to start the calculation. One usually creates the object by calling work.register
Example
# Register the SCF task in work. scf_task = work.register(scf_strategy)
# Register the NSCF calculation and its dependency on the SCF run via deps. nscf_task = work.register(nscf_strategy, deps={scf_task: “DEN”})
Parameters: - node – The task or the worfklow associated to the dependency or string with a filepath.
- exts – Extensions of the output files that are needed for running the other tasks.
-
apply_getters
(task)[source]¶ This function is called when we specify the task dependencies with the syntax:
deps={node: “@property”}In this case the task has to the get property from node before starting the calculation.
At present, the following properties are supported:
- @structure
-
connecting_vars
()[source]¶ Returns a dictionary with the variables that must be added to the input file in order to connect this
Node
to its dependencies.
-
get_filepaths_and_exts
()[source]¶ Returns the paths of the output files produced by self and its extensions
-
info
¶
-
class
FileNode
(filename)[source]¶ Bases:
pymatgen.io.abinit.nodes.Node
A Node that consists of a file. May be not yet existing
Mainly used to connect
Task
objects to external files produced in previous runs.-
color_rgb
= array([0.4, 0.2, 1. ])¶
-
filechildren
¶ List with the children (nodes) of this FileNode.
-
products
¶
-
status
¶ The status of the Node.
-
-
class
GridFsFile
(path, fs_id=None, mode='b')[source]¶ Bases:
monty.collections.AttrDict
Information on a file that will stored in the MongoDb gridfs collection.
-
class
HistoryRecord
(level, pathname, lineno, msg, args, exc_info, func=None)[source]¶ Bases:
object
A HistoryRecord instance represents an entry in the
NodeHistory
.HistoryRecord instances are created every time something is logged. They contain all the information pertinent to the event being logged. The main information passed in is in msg and args, which are combined using str(msg) % args to create the message field of the record. The record also includes information such as when the record was created, the source line where the logging call was made
-
levelno
¶ Numeric logging level for the message (DEBUG, INFO, WARNING, ERROR, CRITICAL)
-
levelname
¶ Text logging level for the message (“DEBUG”, “INFO”, “WARNING”, “ERROR”, “CRITICAL”)
-
pathname
¶ Full pathname of the source file where the logging call was issued (if available)
-
filename
¶ Filename portion of pathname
-
module
¶ Module (name portion of filename)
-
lineno
¶ Source line number where the logging call was issued (if available)
-
func_name
¶ Function name
-
created
¶ Time when the HistoryRecord was created (time.time() return value)
-
asctime
¶ Textual time when the HistoryRecord was created
-
message
¶ -
The result of record.getMessage(), computed just as the record is emitted
Initialize a logging record with interesting information.
-
-
class
Node
[source]¶ Bases:
object
Abstract base class defining the interface that must be implemented by the nodes of the calculation.
Nodes are hashable and can be tested for equality
-
ALL_STATUS
= [<Status: Initialized, at<PHONE_NUMBER>>, <Status: Locked, at<PHONE_NUMBER>>, <Status: Ready, at<PHONE_NUMBER>>, <Status: Submitted, at<PHONE_NUMBER>>, <Status: Running, at<PHONE_NUMBER>>, <Status: Done, at<PHONE_NUMBER>>, <Status: AbiCritical, at<PHONE_NUMBER>>, <Status: QCritical, at<PHONE_NUMBER>>, <Status: Unconverged, at<PHONE_NUMBER>>, <Status: Error, at<PHONE_NUMBER>>, <Status: Completed, at<PHONE_NUMBER>>]¶
-
Results
¶ alias of
NodeResults
-
S_ABICRITICAL
= <Status: AbiCritical, at<PHONE_NUMBER>>¶
-
S_DONE
= <Status: Done, at<PHONE_NUMBER>>¶
-
S_ERROR
= <Status: Error, at<PHONE_NUMBER>>¶
-
S_INIT
= <Status: Initialized, at<PHONE_NUMBER>>¶
-
S_LOCKED
= <Status: Locked, at<PHONE_NUMBER>>¶
-
S_OK
= <Status: Completed, at<PHONE_NUMBER>>¶
-
S_QCRITICAL
= <Status: QCritical, at<PHONE_NUMBER>>¶
-
S_READY
= <Status: Ready, at<PHONE_NUMBER>>¶
-
S_RUN
= <Status: Running, at<PHONE_NUMBER>>¶
-
S_SUB
= <Status: Submitted, at<PHONE_NUMBER>>¶
-
S_UNCONVERGED
= <Status: Unconverged, at<PHONE_NUMBER>>¶
-
SpectatorError
¶ alias of
SpectatorNodeError
-
add_deps
(deps)[source]¶ Add a list of dependencies to the
Node
.Parameters: deps – List of Dependency
objects specifying the dependencies of the node. or dictionary mapping nodes to file extensions e.g. {task: “DEN”}
-
classmethod
as_node
(obj)[source]¶ Convert obj into a Node instance.
Returns: obj if obj is a Node instance, cast obj to FileNode
instance of obj is a string. None if obj is None
-
color_hex
[source]¶ //en.wikipedia.org/wiki/Web_colors#Hex_triplet
Type: Node color as Hex Triplet https
-
color_rgb
= array([0.41176471, 0.41176471, 0.41176471])¶
-
corrections
¶ List of dictionaries with infornation on the actions performed to solve AbiCritical Events. Each dictionary contains the AbinitEvent who triggered the correction and a human-readable message with the description of the operation performed.
-
deps
¶ List of
Dependency
objects defining the dependencies of this Node. Empty list if thisNode
does not have dependencies.
-
deps_status
¶ Returns a list with the status of the dependencies.
-
event_handlers
¶ The list of handlers registered for this node. If the node is not a Flow and does not have its own list of handlers the handlers registered at the level of the flow are returned.
This trick allows one to registered different handlers at the level of the Task for testing purposes. By default, we have a common list of handlers for all the nodes in the flow. This choice facilitates the automatic installation of the handlers when we use callbacks to generate new Works and Tasks!
-
finalized
¶ True if the Node has been finalized.
-
gc
¶ Garbage collector. None if garbage collection is deactivated. Use flow.set_garbage_collector to initialize the object.
-
get_children
()[source]¶ Return the list of nodes in the
Flow
that depends on thisNode
Note
This routine assumes the entire flow has been allocated.
-
get_graphviz_dirtree
(engine='automatic', **kwargs)[source]¶ Generate directory graph in the DOT language. The graph show the files and directories in the node workdir.
Returns: graphviz.Digraph <https://graphviz.readthedocs.io/en/stable/api.html#digraph>
-
get_vars_dataframe
(*varnames)[source]¶ Return pandas DataFrame with the value of the variables specified in varnames. Can be used for task/works/flow. It’s recursive!
-
in_spectator_mode
¶
-
install_event_handlers
(categories=None, handlers=None)[source]¶ Install the EventHandlers for this `Node. If no argument is provided the default list of handlers is installed.
Parameters: - categories – List of categories to install e.g. base + can_change_physics
- handlers – explicit list of
EventHandler
instances. This is the most flexible way to install handlers.
Note
categories and handlers are mutually exclusive.
-
is_file
¶ True if this node is a file
-
is_flow
¶ True if this node is a Flow
-
is_task
¶ True if this node is a Task
-
is_work
¶ True if this node is a Work
-
isinstance
(class_or_string)[source]¶ Check whether the node is a instance of class_or_string. Unlinke the standard isinstance builtin, the method accepts either a class or a string. In the later case, the string is compared with self.__class__.__name__ (case insensitive).
-
log_correction
(event, action)[source]¶ This method should be called once we have fixed the problem associated to this event. It adds a new entry in the correction history of the node.
Parameters: - event –
AbinitEvent
that triggered the correction. - action (str) – Human-readable string with info on the action perfomed to solve the problem.
- event –
-
name
¶ The name of the node (only used for facilitating its identification in the user interface).
-
node_id
¶ Node identifier.
-
num_corrections
¶
-
relworkdir
¶ Return a relative version of the workdir
-
remove_deps
(deps)[source]¶ Remove a list of dependencies from the
Node
.Parameters: deps – List of Dependency
objects specifying the dependencies of the node.
-
send_signal
(signal)[source]¶ Send signal from this node to all connected receivers unless the node is in spectator mode.
signal – (hashable) signal value, see dispatcher connect for details
Return a list of tuple pairs [(receiver, response), … ] or None if the node is in spectator mode.
if any receiver raises an error, the error propagates back through send, terminating the dispatch loop, so it is quite possible to not have all receivers called if a raises an error.
-
show_event_handlers
(stream=<_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>, verbose=0)[source]¶ Print to stream the event handlers installed for this flow.
-
status
¶ The status of the Node.
-
-
class
NodeCorrections
[source]¶ Bases:
list
Iterable storing the correctios performed by the
EventHandler
-
class
NodeHistory
[source]¶ Bases:
collections.deque
Logger-like object
-
class
NodeResults
(node, **kwargs)[source]¶ Bases:
dict
,monty.json.MSONable
Dictionary used to store the most important results produced by a
Node
.-
JSON_SCHEMA
= {'properties': {'exceptions': {'required': True, 'type': 'array'}, 'files': {'required': True, 'type': 'object'}, 'in': {'description': 'dictionary with input parameters', 'required': True, 'type': 'object'}, 'node_class': {'required': True, 'type': 'string'}, 'node_finalized': {'required': True, 'type': 'boolean'}, 'node_history': {'required': True, 'type': 'array'}, 'node_id': {'required': True, 'type': 'integer'}, 'node_name': {'required': True, 'type': 'string'}, 'node_status': {'required': True, 'type': 'string'}, 'out': {'description': 'dictionary with the output results', 'required': True, 'type': 'object'}}, 'type': 'object'}¶
-
exceptions
¶
-
gridfs_files
¶ List with the absolute paths of the files to be put in GridFs.
-
register_gridfs_files
(**kwargs)[source]¶ This function registers the files that will be saved in GridFS. kwargs is a dictionary mapping the key associated to the file (usually the extension) to the absolute path. By default, files are assumed to be in binary form, for formatted files one should pass a tuple (“filepath”, “t”).
Example:
results.register_gridfs(GSR="path/to/GSR.nc", text_file=("/path/to/txt_file", "t"))
The GSR file is a binary file, whereas text_file is a text file.
-
-
class
Product
(ext, path)[source]¶ Bases:
object
A product represents an output file produced by ABINIT instance. This file is needed to start another Task or another Work.
Parameters: - ext – ABINIT file extension
- path – (asbolute) filepath
-
connecting_vars
()[source]¶ Returns a dictionary with the ABINIT variables that must be used to make the code use this file.
-
filepath
¶ Absolute path of the file.
-
exception
SpectatorNodeError
[source]¶ Bases:
pymatgen.io.abinit.nodes.NodeError
Exception raised by
Node
methods when the node is in spectator mode and we are calling a method with side effects.


Extraterm Nightly Builds
These builds are generated from the
Extraterm
master branch each night and may be unstable.


WATCH | Bystanders scramble for loot after cash van bombing in Pretoria
by Iavan PijoosVideo footage shows how onlookers flocked to the scene of a brazen cash-in-transit heist at an intersection on the R566 on the N4 north of Pretoria - hoping to find money.
National police spokesperson Colonel Brenda Muridili said the cash van was travelling from Rosslyn to Silverton when it came under attack on Monday.
Suspects travelling in three SUVs, and armed with rifles, fired several shots at the cash van’s tyres, bringing it to a halt.
“The suspects were wearing blue overalls with balaclavas and hand gloves. They approached, pointed firearms, opened the door and took the driver's firearm.

A video of the aftermath of the heist showed people scouring the scene of the blast for bank notes.
No injuries were reported and no arrests were made.


Chris Evans
"Captain America"
Anna Kendrick
"Pitch Perfect"
Beyonce
Lemonade
Scarlett Johanssen
"The Avengers"
Chris Hemsworth
"Thor"
Joseph Gordon-Levitt
"The Night Before"
Ryan Gosling
"La La Land"
Zoe Saldana
"The Gaurdians of the Galaxy"
Angelina Jolie
"Mr. and Mrs. Smith"
Chris Pratt
"The Guardians of the Galaxy"
Cobie Smulders
"The Avengers"
Daniel Radcliffe
"Harry Potter"
Donald Glover
"Atlanta"
Emma Watson
"Beauty and the Beast"
Gal Gadot
Wonder Woman
Emma Stone
"La La Land"
Ashton Kutcher
"That 70's Show"
Jamie Chung
"Once Upon a Time"
Matt Bomer
"White Collar"
Michelle Rodriguez
"Fast and Furious"
Mila Kunis
"Bad Moms"
Neil Patrick Harris
"How I Met Your Mother"
Paul Walker
"Fast and Furious"
Selena Gomez
"Wizards of Waverly Place"
Vin Diesel
"Fast and Furious"
Jennifer Lawrence
"The Hunger Games"
Robert Downey Jr.
"Iron Man"
Mark Ruffalo
"The Hulk"


Registering a Resource with the Oracle iPlanet Web Server
See Also
- Before you can register a resource with the server, you must set up the resource object.
After you set up a resource object, you must register that resource with the server. Once registered, the object is available to all the applications and resources. You must register each resource individually in the IDE.
When you set up a resource object for a project with the New File wizard, the resource is added to the project and appears in two places:
- In the Server Resources node in the Projects window.
- In the setup folder in the Files window.
To register an individual resource:
- Locate the object in the Projects window or Files window.
- Right-click the object and choose Register.
- Click Register and then click Close when you get the registration successful message.
After the object is registered with the server it is visible in the Runtime window under the Servers node under the node corresponding to the type of resource. You can modify some of the properties of the resource object by opening the properties window for the object.
To delete a resource from the server:
- Locate the object you wish to delete in the Runtime window.
- Right-click the object node and select Delete.
When you delete a resource from the server it is no longer visible in the Runtime window.
- The JNDI name for a resource must be unique. If the JNDI name is already taken by another resource, that resource will be updated with the attributes and properties of the current resource. A message will appear to inform you that the resource has been updated.
- See Also
- Setting Up a Custom Resource on the Oracle iPlanet Web Server
- Setting Up an External JNDI Resource on the Oracle iPlanet Web Server
- Setting Up a JavaMail Resource on the Oracle iPlanet Web Server
- Setting Up a JDBC Resource on the Oracle iPlanet Web Server
- Registering a Oracle iPlanet Web Server
Copyright © 2006 Sun Microsystems, Inc. All rights reserved.
Legal Notices


|
Exodus
6.36
|
EXODUS is the successor of the widely used finite element (FE) data file format EXODUS (henceforth referred to as EXODUS I) developed by Mills-Curran and Flanagan. It continues the concept of a common database for multiple application codes (mesh generators, analysis codes, visualization software, etc.) rather than code-specific utilities, affording flexibility and robustness for both the application code developer and application code user. By using the EXODUS data model, a user inherits the flexibility of using a large array of application codes (including vendor-supplied codes) which access this common data file directly or via translators.
The uses of the EXODUS data model include the following:
The EXODUS library is licensed under the BSD open source license.
Copyright (c) 2005 Sandia Corporation. Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains certain rights in this software.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
The ExodusII library source code is available on Github at https://github.com/gsjaardema/seacas
For bug reports, documentation errors, and enhancement suggestions, contact:
The evolution of the EXODUS data model has been steered by FE application code developers who desire the advantages of a common data format. The EXODUS model has been designed to overcome deficiencies in the EXODUS I file format and meet the following functional requirements as specified by these developers:
To address these requirements, the open source database library etCDF (http://www.unidata.ucar.edu/software/netcdf/) was selected to handle the low-level data storage. The EXODUS II library functions provide the mapping between FE data objects and netCDF dimensions, attributes, and variables. Thus, the code developer interacts with the data model using the vocabulary of an FE analyst (element connectivity, nodal coordinates, etc.) and is relieved of the details of the data access mechanism.
Because an EXODUS file is a netCDF file, an application program can access data via the EXODUS API or the netCDF API directly. Although accessing the data directly via the netCDF API requires more in-depth understanding of netCDF, this capability is a powerful feature that allows the development of auxiliary libraries of special purpose functions not offered in the standard EXODUS library. For example, if an application required access to the coordinates of a single node (the standard library function returns the coordinates for all of the nodes in the model), a simple function could be written that calls netCDF routines directly to read the data of interest.
The data in EXODUS files can be divided into three primary categories: initialization data, model, and results.
Initialization data includes sizing parameters (number of nodes, number of elements, etc.), optional quality assurance information (names of codes that have operated on the data), and optional informational text.
The model is described by data which are static (do not change through time). These data include nodal coordinates, element connectivity (node lists for each element), element attributes, and node sets and side sets (used to aid in applying loading conditions and boundary constraints).
The results are optional and include five types of variables – nodal, element, nodeset, sideset, and global – each of which is stored through time. Nodal results are output (at each time step) for all the nodes in the model. An example of a nodal variable is displacement in the X direction. Element, nodeset, and sideset results are output (at each time step) for all entities (elements, nodes, sides) in one or more entity block. For example, stress may be an element variable. Another use of element variables is to record element status (a binary flag indicating whether each element is "alive" or "dead") through time. Global results are output (at each time step) for a single element or node, or for a single property. Linear momentum of a structure and the acceleration at a particular point are both examples of global variables. Although these examples correspond to typical FE applications, the data format is flexible enough to accommodate a spectrum of uses.
A few conventions and limitations must be cited:
The EXODUS database can store integer bulk data, entity map data, and mesh entity (block/set) ids in either 32-bit or 64-bit integer format. The data considered "bulk data" are:
The entity map data is any data stored in one of the 'map' objects on the exodus file. This includes:
A mesh entity id is the id of any block (element block, edge block, ...); set (node set, face set, ...), coordinate frame, and communication map.
When an EXODUS file is created via the ex_create() function, the 'mode' argument provides the mechanism for specifying how integer data will be passed as arguments to the API functions and also how the integer data will be stored on the database. The ex_open() function also provides a mechanism for specifying how integer data will be passed as arguments.
The method uses the 'mode' argument to the ex_open() and ex_create() functions. The mode is a 32-bit integer in which certain bits are turned on by or'ing certain predefined constants.
exoid = ex_create( EX_TEST_FILENAME, EX_CLOBBER|EX_MAPS_INT64_DB|EX_MAPS_INT64_API, &appWordSize, &diskWordSize );
The constants related to the integer size (32-bit or 64-bit) specification are:
The constants that end with "_DB" specify that that particular integer data is stored on the database as 64-bit integers; the constants that end with "_API" specify that that particular integer data is passed to/from API functions as 64-bit integers.
If the range of the data being transmitted is larger than the permitted integer range (for example, if the data is stored on the database as 64-bit ints and the application specifies passing data as 32-bit ints), the api function will return an error.
The three types of integer data whose storage can be specified are
The function ex_int64_status(exoid) is used to determine the integer storage types being used for the EXODUS database 'exoid'. It returns an integer which can be and'ed with the above flags to determine either the storage type or function parameter type.
For example, if (EX_MAPS_INT64_DB & ex_int64_status(exoid)) is true, then map data is being stored as 64-bit integers for that database.
It is not possible to determine the integer data size on a database without opening the database via an ex_open() call. However, the integer size specification for API functions can be changed at any time via the ex_set_int64_status(exoid, mode) function. The mode is one or more of EX_MAPS_INT64_API, EX_IDS_INT64_API, or EX_BULK_INT64_API, or'd together. Any exodus function calls after that point will use the specified integer size. Note that a call to ex_set_int64_status(exoid, mode) overrides any previous setting for the integer sizes used in the API. The ex_create() function is the only way to specify the integer sizes specification for database integers.
The fortran api is uses the same mechanism as was described above for the C API. If using the "8-byte real and 8-byte int" fortran mode typically used by the SEACAS applications (the compiler automatically promotes all integers and reals to 8-byte quantities), then the fortran exodus library will automatically enable the *_API options; the client still needs to specify the *_DB options.
The new capability to pass 64-bit integer data through the fortran and C API functions simplifies the implementation of the "8-byte real 8-byte int" usage of the exodus library. Previously, the wrapper routines in addrwrap.F were required to convert the 8-byte integer data on the client side to/from 4-byte integers on the library side. This required extra memory allocation and complications that are now handled at the lowest level in the netcdf library. The map-related functions in the fortran api have all been converted to pass 64-bit integers down to the C API which has removed some code and simplified those functions.
The ex_set_option() function call is used to set various options on the database. Valid values for 'option' are:
| Option Name | Option Values |
|---|---|
| EX_OPT_MAX_NAME_LENGTH | Maximum length of names that will be returned/passed via api call. |
| EX_OPT_COMPRESSION_TYPE | Not currently used; default is gzip |
| EX_OPT_COMPRESSION_LEVEL | In the range [0..9]. A value of 0 indicates no compression |
| EX_OPT_COMPRESSION_SHUFFLE | 1 if enabled, 0 if disabled |
| EX_OPT_INTEGER_SIZE_API | 4 or 8 indicating byte size of integers used in api functions. |
| EX_OPT_INTEGER_SIZE_DB | Query only, returns 4 or 8 indicating byte size of integers stored on |
the database.
The compression-related options are only available on netcdf-4 files since the underlying hdf5 compression functionality is used for the implementation. The compression level indicates how much effort should be expended in the compression and the computational expense increases with higher levels; in many cases, a compression level of 1 is sufficient.


Greetings, My name is Sa'ed Al-Khateeb am a coullage graduate majored in computer science, am 23 years old. i have been working since 8th grade in varus things from hard labor all the way to retail jobs and online marketing. this is as absract as it can be , Invite me to a cup of coffee to know more about me!.
Fav movies
- Star wars
- The harry potter series
- Wrath of the titans
- The hunger games
- klaus
- 12 angry men
- deadpool series
- The kingsmen
- Logan
- Watchmen


| This page includes the QR code generator
below. Basically Your setting a delimited string as the QR Code string. This string is then read by the app and the data is tokenized for the database or viewing. In this demo the | is used to split each record and the semi-colon is used to split the fields. The android apps sqlite database is pretty simple with 1 table that has 7 basic fields: rec_id, rec_type, rec_val_a, rec_val_b, rec_val_c, date_added and date_modified. see UtilSQLiteAdapter and UtilDBRecord. The rec_id is androids _id column and the rest are used in the delimted strings below. The rec_type determines if its a leaflet, recipe, etc. rectypes 5 - leaflet ; id ; title; .. 10 - recipe ; id ; title ;.. 50 - product ; promo id ; title ; pricing ; favorite.. When using this for testing, dont forget to change the id paramater 5;300 ... 5;301 .. 5;302 .. etc., or it will read records with that id already inserted in db. |
| Other Notes: |
| You can use search and replace to replace repetitive long string
with shorter ones in your delimited string. You can also use compression scripts. In the images folder is a masked QR Code image to give you an ideia of how masking is done to spice up your QR code images. |


--- class: slide title: Data Fresh Daily permalink: /#data-fresh-daily description: Just Who and Where you want them. section: data-fresh-daily ---
24 hours a day, 365 days a year curated and continuous custom collection proximity based data.


--- layout: default title: Kamon - Tools for Reactive Applications Monitoring ---
Kamon is a set of tools that helps you to get metrics out of your reactive applications.
We need your help! Our site is under construction, if you came here looking for info and couldn't find what you are looking for please drop us a line on the mailing list, raise a issue on github or just let us know at twitter, we are here to help! Hopefully next time you come there will be more info here :D.
Be prepared to get metrics of:
Kamon already understands when a request starts and ends in a Spray application, you will get:
StatsD is everywhere, let your metrics data be everywhere too: