| Class | Description |
|---|---|
| AddLookupAttributes |
This class determines whether or not the lookup discovery service can
successfully add a new set of attributes to the its current set of
attributes.
|
| AddLookupAttributesNull |
This class determines whether or not the lookup discovery service can
successfully modify its current set of attributes.
|
| AddLookupAttributesSC |
This class determines whether or not the lookup discovery service can
successfully add a new set of attributes to the its current set of
attributes.
|
| AddLookupGroups |
This class determines whether or not the lookup discovery service can
successfully add a new set of groups to the set of groups with which
it has been configured to join.
|
| AddLookupGroupsAllToAll |
This class determines whether or not the lookup discovery service can
successfully add a new set of groups to the set of groups with which it
has been configured to join.
|
| AddLookupGroupsAllToFinite |
This class determines whether or not the lookup discovery service can
successfully add a new set of groups to the set of groups with which it
has been configured to join.
|
| AddLookupGroupsDups |
This class determines whether or not the lookup discovery service can
successfully add a new set of groups to the set of groups with which it
has been configured to join.
|
| AddLookupGroupsFiniteToAll |
This class determines whether or not the lookup discovery service can
successfully add a new set of groups to the set of groups with which it
has been configured to join.
|
| AddLookupGroupsFiniteToNone |
This class determines whether or not the lookup discovery service can
successfully add a new set of groups to the set of groups with which it
has been configured to join.
|
| AddLookupGroupsNoneToFinite |
This class determines whether or not the lookup discovery service can
successfully add a new set of groups to the set of groups with which it
has been configured to join.
|
| AddLookupLocators |
This class determines whether or not the lookup discovery service can
successfully add a new set of locators to the set of locators with
which it has been configured to join.
|
| AddLookupLocatorsDups |
This class determines whether or not the lookup discovery service can
successfully add a new set of locators to the set of locators with
which it has been configured to join.
|
| AddLookupLocatorsEmptyToFinite |
This class determines whether or not the lookup discovery service can
successfully add a new set of locators to the set of locators with
which it has been configured to join.
|
| AddLookupLocatorsFiniteToEmpty |
This class determines whether or not the lookup discovery service can
successfully add a new set of locators to the set of locators with
which it has been configured to join.
|
| AddLookupLocatorsNullToFinite |
This class determines whether or not the lookup discovery service can
successfully add a new set of locators to the set of locators with
which it has been configured to join.
|
| GetLookupAttributes |
This class determines whether or not the lookup discovery service can
successfully return the attributes with which it is currently configured.
|
| GetLookupGroups |
This class determines whether or not the lookup discovery service can
successfully return the groups with which it has been configured to join.
|
| GetLookupGroupsAll |
This class determines whether or not the lookup discovery service can
successfully return the groups with which it has been configured to join.
|
| GetLookupGroupsAllFinite |
This class determines whether or not the lookup discovery service can
successfully return the groups with which it has been configured to join.
|
| GetLookupGroupsDups |
This class determines whether or not the lookup discovery service can
successfully return the groups with which it has been configured to join.
|
| GetLookupGroupsNone |
This class determines whether or not the lookup discovery service can
successfully return the groups with which it has been configured to join.
|
| GetLookupGroupsNoneFinite |
This class determines whether or not the lookup discovery service can
successfully return the groups with which it has been configured to join.
|
| GetLookupGroupsPublic |
This class determines whether or not the lookup discovery service can
successfully return the groups with which it has been configured to join.
|
| GetLookupLocators |
This class determines whether or not the lookup discovery service can
successfully return the locators with which it has been configured to join.
|
| GetLookupLocatorsDups |
This class determines whether or not the lookup discovery service can
successfully return the locators with which it has been configured to join.
|
| ModifyLookupAttributes |
This class determines whether or not the lookup discovery service can
successfully modify its current set of attributes.
|
| ModifyLookupAttributesDeleteAll |
This class determines whether or not the lookup discovery service can
successfully modify its current set of attributes.
|
| ModifyLookupAttributesDeleteOne |
This class determines whether or not the lookup discovery service can
successfully modify its current set of attributes.
|
| ModifyLookupAttributesNullInput |
This class determines whether or not the lookup discovery service can
successfully modify its current set of attributes.
|
| ModifyLookupAttributesNullTmpl |
This class determines whether or not the lookup discovery service can
successfully modify its current set of attributes.
|
| ModifyLookupAttributesSC |
This class determines whether or not the lookup discovery service can
successfully modify its current set of attributes.
|
| RemoveLookupGroups |
This class determines whether or not the lookup discovery service can
successfully remove a set of groups from the set of groups with which
it has been configured to join.
|
| RemoveLookupGroupsAllFromAll |
This class determines whether or not the lookup discovery service can
successfully remove a set of groups from the set of groups with which
it has been configured to join.
|
| RemoveLookupGroupsAllFromFinite |
This class determines whether or not the lookup discovery service can
successfully remove a set of groups from the set of groups with which
it has been configured to join.
|
| RemoveLookupGroupsDups |
This class determines whether or not the lookup discovery service can
successfully remove a set of groups from the set of groups with which
it has been configured to join.
|
| RemoveLookupGroupsFiniteFromAll |
This class determines whether or not the lookup discovery service can
successfully remove a set of groups from the set of groups with which
it has been configured to join.
|
| RemoveLookupGroupsFiniteFromNone |
This class determines whether or not the lookup discovery service can
successfully remove a set of groups from the set of groups with which
it has been configured to join.
|
| RemoveLookupGroupsNoneFromFinite |
This class determines whether or not the lookup discovery service can
successfully remove a set of groups from the set of groups with which
it has been configured to join.
|
| RemoveLookupLocators |
This class determines whether or not the lookup discovery service can
successfully remove a set of locators from the set of locators with
which it has been configured to join.
|
| RemoveLookupLocatorsDups |
This class determines whether or not the lookup discovery service can
successfully remove a set of locators from the set of locators with
which it has been configured to join.
|
| RemoveLookupLocatorsEmptyFromFinite |
This class determines whether or not the lookup discovery service can
successfully remove a set of locators from the set of locators with
which it has been configured to join.
|
| RemoveLookupLocatorsFiniteFromEmpty |
This class determines whether or not the lookup discovery service can
successfully remove a set of locators from the set of locators with
which it has been configured to join.
|
| RemoveLookupLocatorsNullFromFinite |
This class determines whether or not the lookup discovery service can
successfully remove a set of locators from the set of locators with
which it has been configured to join.
|
| SetLookupGroups |
This class determines whether or not the lookup discovery service can
successfully replace the set of groups with which it has been configured
to join with a new set of groups.
|
| SetLookupGroupsAllToFinite |
This class determines whether or not the lookup discovery service can
successfully replace the set of groups with which it has been configured
to join with a new set of groups.
|
| SetLookupGroupsDups |
This class determines whether or not the lookup discovery service can
successfully replace the set of groups with which it has been configured
to join with a new set of groups.
|
| SetLookupGroupsFiniteToAll |
This class determines whether or not the lookup discovery service can
successfully replace the set of groups with which it has been configured
to join with a new set of groups.
|
| SetLookupGroupsFiniteToNone |
This class determines whether or not the lookup discovery service can
successfully replace the set of groups with which it has been configured
to join with a new set of groups.
|
| SetLookupGroupsNoneToFinite |
This class determines whether or not the lookup discovery service can
successfully replace the set of groups with which it has been configured
to join with a new set of groups.
|
| SetLookupLocators |
This class determines whether or not the lookup discovery service can
successfully replace set of locators with which it has been configured
to join with a new set of locators.
|
| SetLookupLocatorsDups |
This class determines whether or not the lookup discovery service can
successfully replace set of locators with which it has been configured
to join with a new set of locators.
|
| SetLookupLocatorsEmptyToFinite |
This class determines whether or not the lookup discovery service can
successfully replace set of locators with which it has been configured
to join with a new set of locators.
|
| SetLookupLocatorsFiniteToEmpty |
This class determines whether or not the lookup discovery service can
successfully replace set of locators with which it has been configured
to join with a new set of locators.
|
| SetLookupLocatorsFiniteToNull |
This class determines whether or not the lookup discovery service can
successfully replace set of locators with which it has been configured
to join with a new set of locators.
|
Copyright 2007-2013, multiple authors.
Licensed under the Apache License, Version 2.0, see the NOTICE file for attributions.


Installation guide
Font version
Latest release
<link rel="stylesheet"<EMAIL_ADDRESS>Experimental version (It's not needed to update)
<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/vedico-org/vedico/font.css">
SVG version
It's not needed to install this version, just choose between the latest or experimental version.
Latest release
<EMAIL_ADDRESS>Experimental version (It's not needed to update)
https://cdn.jsdelivr.net/gh/vedico-org/vedico/svg/{Put_icon_name_here}.svg


You are located at:
1 Saarinen CirSterling, VA, 20166-7547
By clicking on Get Connected I accept the AT&T Wi-Fi Terms of Service and Acceptable Use Policy


The rise of 'facadism' in London
London blogger The Gentle Author has been photographing the changing face of London, focusing on what is known as "facadism", the practice of destroying everything apart from the front wall and constructing a new building behind it.
Here, we present a few pictures from the series and the story of the buildings that once stood.
National Provincial Bank, Threadneedle Street, City of London, EC2
This Grade I listed building was designed by John Gibson as London's largest banking hall, in 1863-65, with figures along the roofline representing locations where the bank did business including:
- Manchester
- Birmingham
- Dover
- Newcastle
- London
Above the arched windows, eight sculpted panels of heroic allegorical scenes represent the achievements of mankind:
- the arts
- commerce
- science
- manufacturing
- agriculture
- navigation
- shipbuilding
- mining
The Cock & Hoop, Artillery Lane, Spitalfields, E1
Thomas Lloyd is recorded as this pub's first landlord, in 1805.
After it closed for good, in 1908, the building was incorporated into the Providence Row Night Refuge and, in 2006, converted into student housing for the London School of Economics.
London Fruit & Wool Exchange, Brushfield Street, Spitalfields, E1
This building was designed by Sydney Perks, in 1927, as a state-of-the-art auction room with a roof that simulated sunlight on cloudy days, parquet floors, careful detailing and significant craft elements throughout.
Since the fruit and vegetable market left Spitalfields, in 1991, it has housed many small independent local businesses.
The tenant of the new development is an international legal corporation.
465 Caledonian Road, Islington, N7
Mallett, Porter & Dowd built this handsome warehouse for their business, in 1874.
Redevelopment by University College London for student housing was turned down by Islington Council, citing inadequate daylight, due to the windows of the new building not aligning with those in the facade.
But this judgement was later overturned by the Planning Inspectorate.
And the development won Building Design's Carbuncle Cup for 2013.
College East, Toynbee Hall, Wentworth Street, Spitalfields, E1
Designed by Elijah Hoole, this part of the Toynbee Hall campus, built in 1884-85, was demolished and facaded for the construction of Attlee House, which was completed in 1971 but itself demolished in 2016.
It will next front Gatsby Apartments, a development of flats for the commercial market.
Former Unitarian Chapel, Stamford Street, Blackfriars, SE1
Designed in 1821 by Charles Parker, the architect of Hoare's Bank, in the Strand, this chapel was demolished in the 1960s apart from the portico and part of the ground floor, which stood in front of a car park for many years.
The Grade II listed Doric hexastyle portico is topped by a triglyph frieze and a pediment.
Its central door has a shouldered architrave and iron gates.
The Spotted Dog, 38 High Road, Willesden, NW10
The Spotted Dog was described as "a well accustomed public house" in 1792, by which time it was at least 30 years old.
In the 19th Century, it was famous for its pleasure gardens and in the 1920s housed a dancehall.
18 Broadwick Street, Soho, W1
Decorative brick inlay on the Berwick Street elevation declares this facade was built in 1886.
Originally a bakery, it became Central Chemists in 1950 when the ground floor and basement premises were acquired by Gertrude Kramer.
Michael Moss acquired the pharmacy and freehold to the building from Mrs Kramer in the 1970s and enlarged it to include 85-86 Berwick Street in the late 1980s, naming it Broadwick Pharmacy.
Richard Piercy bought the shop in 1990 and ran it as Zest Pharmacy until 2016.
In recent memory, the upper parts of the building were used as offices by music, film and voice-over businesses.
All photographs © The Gentle Author from the book The Creeping Plague of Ghastly Facadism.


Output¶
Image¶
Maps can be exported as image. MyTilemapEditor supports the PNG format [8]. User can export current map as image by choose File -> Export -> PNG.
XML¶
The XML format is the most common additional file format supported by MyTilemapEditor. All the files are saved and read as XML files by the third-party tool TinyXML2.
Unity¶
Unity, as people know, is a powerful game engine, but it also provides functions for the user to create a tool kit. Once the XML file is generated by MyTilemapEditor and imported the MyTilemapEditor package into Unity, then go to Unity and open the MyTilemapEditor window. Press the “Import map” button to generate a tilemap in Unity. If the user assigns a Grid, then it will try to update the current tilemap under the Grid
In Unity, it has a Tile Palette component. Tile Palette allows the user to paint the tiles on Tilemap component. It is a case that the user may want to keep editing the map. Therefore, by checking the Import Palette check box, it will generate Unity Tile Palette component files, but it takes more time to load. Loading time based on how many tiles require to be sliced on the image. For example, if an image requires to be sliced into 32 by 32 tiles, it will generate 1024 tile assets on the project folder.


Checkout
Continue with Login
Continue without Login
Login Details
Email:
Password:
Payment Details
Payment Method
Total amount:
Total items:
Transaction ID:
Billing Details
Full Name
Email
Phone no
District
Full Address
Payment Details
Payment Method
Total amount:
Total items:
Transaction ID:


This website requires cookies to be enabled so that it can remember you during your visit. Use of cookies improves security but can raise concerns over privacy. Cookies appear to be blocked by your browser or you may have requested that they be removed.
Instructions on how to enable cookies and manage privacy settings are typically specific to each device or browser.
For technical information about cookies see Wikipedia.


{% extends "simple.html" %} {% block content %}
Your effective identity {{loginstat["identity"]}} is not an ACCESS-CI identity.
Please visit the Manage Consents page and clear the consent for {{pagetitle}}. Then come back here and login again.


The object is initially passive, and is stored in the object store as an instance of the
class
OutputObjectState
.
When required by an application, the object is automatically activated by reading it
from the store
using a
read_committed
operation and is then converted from an
InputObjectState
instance into a fully-fledged object by the
restore_state
operation of the object.
When the application has finished with the object, it is deactivated by converting it
back into an
OutputObjectState
instance using the
save_state
operation, and is then stored back into the object store as a shadow copy using
write_uncommitted
. This shadow copy can be committed, overwriting the previous
version, using the
commit_state
operation. The existence of shadow copies is
normally hidden from the programmer by the transaction system. Object deactivation normally only occurs
when the top-level transaction within which the object was activated commits


Organization name is required.
Organization description required.
Website link required.
Point of Contact info required.


CFM outputs¶
The CFM writes its outputs to a single.hdf5-format file. By default, all nodes are written to file. The output is only saved at the time steps specified by the user with the variable TWrite. Most of the outputs should be self-explanatory. Many of them are big 2D matrices; the first column is time, and the values throughout are the particular values at the depth found in the corresponding cell in the depth output. Set the outputs you want in the .json file. The available outputs are: depth: (m) The depth of each model node. density: (kg m-3) The density at the depths in ‘depth temperature: (K) Temperature at the depths in ‘depth’ age: (years) Firn Age at the depths in ‘depth’ dcon: Dcon is a layer-tracking routine; to use it you need to dig into the code a bit and program it how you want, but for example you could set it up so that each model node that has liquid water gets a 1 and all others get a zero. Corresponds to depth.
bdot_mean: (m a-1 ice equivalent) the mean accumulation rate over the lifetime of each parcel of firn, corresponds with ‘depth’
climate: The temperature (K) and accumulation rate (m a-1 ice equivalent) at each time step – useful if using interpolation to find determine the climate.
compaction: (m) Total compaction of each node since the previous time step; corresponds to ‘depth’. To get compaction rate you need to divide by the time-step size. To get compaction over an interval you need to sum numerous boxes.
grainsize: (mm2) the grain size of the firn, corresponds to ‘depth’ temp_Hx: the temperature history of the firn (See Morris and Wingham, 2014)
isotopes: (per mil) water isotope values, corresponds to ‘depth’
LWC: (m3) volume of liquid present in that node, corresponds to ‘depth’
DIP: the depth-integrated porosity and change in surface elevation. 4 columns: The first is time, second is DIP to the bottom of the model domain (m), third is change in domain thickness since last time step (m), fourth is change in domain thickness since start of model run (m). DIP also saves a variable called DIPc, which is a matrix of the cumulative porosity to the depth in ‘depth’
BCO: bubble close-off properties. 10 columns: time, Martinerie close-off age, Marinerie close-off depth, age of 830 kg m-3 density horizon, depth of 830 kg m-3 density horizon, Martinerie lock-in age, Marinerie lock-in depth, age of 815 kg m-3 density horizon, depth of 815 kg m-3 density horizon, depth of zero porosity.
FirnAir: only works if FirnAir is true in the config.json. Saves gas concentrations, diffusivity profile, gas age, and advection rates of air and firn, all corresponding to ‘depth’.


{{ reason.note }}
|
{{ status.date | formatDate }}
{{ status.date | formatDate: 'h:mm a' }}
|
The enrollee status changed to {{ status.name }}{{ (status.adjudicator) ? ', by ' + status.adjudicator : '.'}} {{ status.note }} 0">
This Enrollee was manually adjudicated for the following reasons:
{{ reason.name }}
User's Explanation:
{{ reason.note }} |
|---|


HTML5, CSS3, Javascript, jQuery, MERN Stack (Mongo, Express, React, Node)
Sold over $4,000,000 in education technology at Macmillan Learning. Products included Launchpad, Sapling, and FlipIt
Coding Certificate, Rutgers University - January 2018
Bachelor of Arts, Rutgers University -
May 2014
For as long as I can remember, I loved video games. From the first time I picked up a Sega Genesis controller to play Sonic the Hedgehog, to getting my very first Nintendo console, the Gamecube in 2001, my passion for the creation, technology, and design of these games were born.
I was hired as a member of All Jersey Studios in high school, where my job was to shoot, edit, and ship video for NJ events including Weddings, Birthdays, Graduations, and various Corporate functions. I worked with Adobe Premiere and their suite of products, picking up best practices and creative direction as I went along. Coding is a lot like video editing, in that there is a way to make it all look good without sacrificing your personal touch.
At Rutgers, I studied classic literature and writing and earned a Bachelor's Degree. I acted in plays, wrote my own, and hosted the campus-wide morning TV show, which also included Freshman Orientation to tens of thousands of students and families.At Rutgers Television, I furthered my video editing and computer skills as a responsibility to my fellow students. I learned how to be sociable and engaging, and connected with people of all backgrounds, this as being crucial to strong web services.
My skills in technology and communication led me to Macmillan Learning to begin my career post-college. I worked with thousands of professors and university figures across Pennsylvania, Texas, Minnesota, Wisconsin, Arizona, West Virginia, Maine, Idaho, Connecticut, and Massachusetts to ensure their students used our tech and services to increase grades and graduation rates. Over $4,000,000 of business later, our influence on effective student learning is boundless.
In January, I earned a Coding Certificate from my Alma Mater. With years of sales experience behind me, I look forward to working with and for people like me, who love great ideas and forward-moving technologies, and being able to communicate all of these in a professional, high quality manner.


OR
Select all shapes you want:
Steps size of shapes
Viewing Size pixels
Initial transparency of
Compute Size of pixels
Try optimisation times
Start every try with shapes
Background color of image


|
| class | SumAccumulator |
| | Class to track the total increase of a signal while a condition is true. More...
|
| |
| class | AvgAccumulator |
| | Class to track the average value of a signal while a condition is true. More...
|
| |
| class | SumAccumulatorImp |
| |
| class | AvgAccumulatorImp |
| |
| class | Admin |
| |
| class | Agent |
| |
| class | AgentFactory |
| |
| class | All2allModelRegion |
| |
| class | ApplicationIO |
| |
| class | ApplicationIOImp |
| |
| class | ApplicationRecordLog |
| | Provides an abstraction for a shared memory buffer that can be used to pass entry, exit, epoch and short region events from Profile to ApplicationSampler. More...
|
| |
| class | ApplicationRecordLogImp |
| |
| class | ApplicationSampler |
| |
| class | ApplicationSamplerImp |
| |
| class | ApplicationStatus |
| | Object that encapsulates application process information such as the process ID, region hash, or region hint. There will be one ApplicationStatus for the node (board domain) on each side of the shared memory. More...
|
| |
| class | ApplicationStatusImp |
| |
| class | BarrierModelRegion |
| |
| class | Comm |
| | Abstract base class for interprocess communication in geopm. More...
|
| |
| class | CommFactory |
| |
| class | NullComm |
| |
| class | Controller |
| |
| class | CPUActivityAgent |
| | Agent. More...
|
| |
| class | CSV |
| | CSV class provides the GEOPM interface for creation of character separated value tabular data files. These CSV formatted files are created with a header containing some meta-data prefixed by the '#' character and then one line that defines the field name for the column. The separation character is a '|' not a comma. More...
|
| |
| class | CSVImp |
| |
| class | Daemon |
| |
| class | DaemonImp |
| |
| class | DebugIOGroup |
| | IOGroup that Agents can use to expose internal values. More...
|
| |
| class | DefaultProfile |
| |
| class | DenseLayer |
| | Class to store dense layers and perform operations on the layers' 1D and 2D Tensors, aka vectors and matrices, suitable for use in feed-forward neural networks. More...
|
| |
| class | DenseLayerImp |
| |
| class | DGEMMModelRegion |
| |
| class | DomainNetMap |
| | Class to load neural net from file, sample signals specified in that file, feed those signals into the neural net and manage the output from the neural nets. More...
|
| |
| class | DomainNetMapImp |
| |
| class | EditDistEpochRecordFilter |
| |
| class | EditDistPeriodicityDetector |
| |
| class | ELF |
| | Class encapsulating interactions with ELF files. More...
|
| |
| class | ELFImp |
| |
| class | Endpoint |
| |
| struct | geopm_endpoint_policy_shmem_header |
| |
| struct | geopm_endpoint_sample_shmem_header |
| |
| struct | geopm_endpoint_policy_shmem_s |
| |
| struct | geopm_endpoint_sample_shmem_s |
| |
| class | EndpointImp |
| |
| class | EndpointPolicyTracer |
| |
| class | EndpointPolicyTracerImp |
| |
| class | EndpointUser |
| |
| class | EndpointUserImp |
| |
| class | Environment |
| | Environment class encapsulates all functionality related to dealing with runtime environment variables. More...
|
| |
| class | EnvironmentImp |
| |
| class | EpochIOGroup |
| |
| class | FFNetAgent |
| | Feed Forward Net Agent. More...
|
| |
| class | FilePolicy |
| |
| class | FrequencyGovernor |
| |
| class | FrequencyGovernorImp |
| |
| class | FrequencyLimitDetector |
| | Detect maximum achievable frequency limits of CPU cores. More...
|
| |
| class | FrequencyMapAgent |
| |
| class | FrequencyTimeBalancerImp |
| |
| class | FrequencyTimeBalancer |
| |
| class | GEOPMBenchConfig |
| |
| class | GEOPMBenchConfigImp |
| |
| class | GPUActivityAgent |
| | Agent. More...
|
| |
| class | IgnoreModelRegion |
| |
| class | InitControl |
| |
| class | InitControlImp |
| |
| class | LocalNeuralNet |
| | Class to manage data and operations of feed forward neural nets required for neural net inference. More...
|
| |
| class | LocalNeuralNetImp |
| |
| class | ModelApplication |
| |
| class | ModelRegion |
| |
| class | MonitorAgent |
| | Agent used to do sampling only; no policy will be enforced. More...
|
| |
| class | CommWindow |
| |
| class | MPIComm |
| | Implementation of the Comm interface using MPI as the underlying communication mechanism. More...
|
| |
| class | NNFactory |
| | Class to generate objects related to feed-forward neural nets, i.e. TensorOneD, TensorTwoD, DenseLayer, and LocalNeuralNet objects. More...
|
| |
| class | NNFactoryImp |
| |
| class | OMPTImp |
| |
| class | OMPT |
| |
| class | OptionParser |
| |
| class | PlatformIOProf |
| |
| class | PolicyStore |
| |
| class | PolicyStoreImp |
| |
| class | PowerBalancer |
| | Stay within a power cap but redistribute power to optimize performance. An average per compute node power maximum is maintained, but individual nodes will be allowed above or below this average. More...
|
| |
| class | PowerBalancerAgent |
| |
| class | CircularBuffer |
| |
| class | PowerBalancerImp |
| |
| class | PowerGovernor |
| |
| class | PowerGovernorAgent |
| |
| class | PowerGovernorImp |
| |
| class | ProcessRegionAggregator |
| | Class responsible for reading records from the ApplicationSampler and calculating the per-process runtimes within each region. More...
|
| |
| class | ProcessRegionAggregatorImp |
| |
| class | Profile |
| | Enables application profiling and application feedback to the control algorithm. More...
|
| |
| class | ProfileImp |
| |
| class | ProfileIOGroup |
| | IOGroup that provides signals from the application. More...
|
| |
| class | ProfileTracer |
| |
| class | ProfileTracerImp |
| |
| class | ProxyEpochRecordFilter |
| | Filter that can be used to synthesize epoch events from a sequence of region entry events. The filter suppresses received epoch events and passes through all other events. More...
|
| |
| struct | record_s |
| | Record of an application event. More...
|
| |
| struct | short_region_s |
| |
| class | RecordFilter |
| | Base class for filters that can be applied to ApplicationSampler record streams produced by a single process. More...
|
| |
| class | ReduceModelRegion |
| |
| class | RegionHintRecommender |
| | Class ingesting the output from a DomainNetMap and a frequency map json file and determining a recommended frequency decision. More...
|
| |
| class | RegionHintRecommenderImp |
| | Class ingesting region classification logits and a frequency map json file and determining a recommended frequency decision. More...
|
| |
| class | Reporter |
| | A class used by the Controller to format the report at the end of a run. Most of the information for the report is passed into the generate() method at the end of a run, however the Reporter is also responsible for pushing some per-region signals to indicate that they should be tracked by the PlatformIO. More...
|
| |
| class | ReporterImp |
| |
| class | SampleAggregator |
| |
| class | SampleAggregatorImp |
| |
| class | ScalingModelRegion |
| |
| class | Scheduler |
| |
| class | SchedulerImp |
| |
| class | SleepModelRegion |
| |
| class | SpinModelRegion |
| |
| class | SSTClosGovernor |
| | Govern class of service (CLOS) controls. More...
|
| |
| class | SSTClosGovernorImp |
| |
| class | SSTFrequencyLimitDetector |
| |
| class | StreamModelRegion |
| |
| class | TensorMath |
| | Class to perform operations on 1D and 2D Tensors, aka vectors and matrices, suitable for use in feed-forward neural networks. More...
|
| |
| class | TensorMathImp |
| |
| class | TensorOneD |
| | Class to store and perform operations on 1D Tensors, aka vectors, suitable for use in feed-forward neural networks. More...
|
| |
| class | TensorTwoD |
| | Class to manage data and operations related to 2D Tensors required for neural net inference. More...
|
| |
| class | TimedScalingModelRegion |
| |
| class | Tracer |
| | Abstract base class for the Tracer object defines the interface. More...
|
| |
| class | TracerImp |
| | Class used to write a trace of the telemetry and policy. More...
|
| |
| class | TreeComm |
| |
| class | TreeCommImp |
| |
| class | TreeCommLevel |
| |
| class | TreeCommLevelImp |
| |
| class | TRLFrequencyLimitDetector |
| |
| class | ValidateRecord |
| | Checks validity and self consistency of a record stream from a single process. This check is applied by the ApplicationSampler when updates are provided and after the filter is applied. More...
|
| |
| class | Waiter |
| | Class to support a periodic wait loop. More...
|
| |
| class | SleepWaiter |
| | Class to support a periodic wait loop based on clock_nanosleep() using CLOCK_REALTIME. More...
|
| |
|
| AgentFactory & | agent_factory (void) |
| |
| CommFactory & | comm_factory (void) |
| |
| std::shared_ptr< ELF > | elf (const std::string &file_path) |
| | Factory method to construct an ELF pointer from a path to an ELF encoded file. More...
|
| |
| std::map< size_t, std::string > | elf_symbol_map (const std::string &file_path) |
| | Get a map from symbol location to symbol name for all symbols in an ELF file. More...
|
| |
| std::pair< size_t, std::string > | symbol_lookup (const void *instruction_ptr) |
| | Look up the nearest symbol lower than an instruction address. More...
|
| |
| const Environment & | environment (void) |
| |
| const GEOPMBenchConfig & | geopmbench_config (void) |
| |
| void | model_parse_config (const std::string config_path, uint64_t &loop_count, std::vector< std::string > ®ion_name, std::vector< double > &big_o) |
| |
| void | check_mpi (int err) |
| |
| template<typename T > |
| void | bind_value_to_statement (sqlite3_stmt *, int, T)=delete |
| |
| std::string | event_name (int event_type) |
| | Format an event_e type as a string. More...
|
| |
| int | event_type (const std::string &event_name) |
| | Convert a human-readable event type string to an event_e. More...
|
| |
| std::string | hint_name (uint64_t hint) |
| | Format a string to represent a hint enum from the geopm_region_hint_e. More...
|
| |
| uint64_t | hint_type (const std::string &hint_name) |
| | Parse a string representing the hint name. More...
|
| |
| template<typename type > |
| std::map< uint64_t, std::shared_ptr< type > >::iterator | sample_aggregator_emplace_hash (std::map< uint64_t, std::shared_ptr< type > > &hash_accum_map, uint64_t hash) |
| |
| template<typename type > |
| void | sample_aggregator_update_epoch (type &signal, int epoch_count) |
| |
| template<typename type > |
| void | sample_aggregator_update_hash_exit (type &signal, uint64_t hash) |
| |
| template<typename type > |
| void | sample_aggregator_update_hash_enter (type &signal, uint64_t hash) |
| |
| template<typename type > |
| void | sample_aggregator_update_period (type &signal, int period) |
| |


AP Top Business News at 4:19 a.m. EST
by EndPlayMcDonald's CEO's ouster reflects trend on workplace romances
Global stocks higher after possible US-China trade snag
EU hopes US will rethink choice to pull out of climate pact
EU's Barnier warns of tough times ahead on UK trade deal
Japan's SoftBank tumbles into losses over costly investments
Jersey City voters pass limits on Airbnb, short-term rentals
New SUV models boost BMW profits despite technology costs
'I was appalled': Black customers say host told them to move
German factory orders rise in September after 2 declines
At trade show, Xi pledges steps to open Chinese markets


WOJ
问题描述 :
problem is solved. Alex loves balloons, especially when they’re in a consecutive column, from which he can get a sense of
accomplishment.
Problems on WOJ have a variety of difficulties. Hard problems cost more time, while easy ones may be "killed in 1
second". Now we know that WOJ has N problems, numbered from 1 to N. Alex calls the solved problems in one
consecutive column as a "successful string". The length of a successful string is the number of problems it contains. Also
he defines the value of a successful string as the square of the string’s length. Alex hopes to solve a certain number of
problems in M time, so he can get some successful strings, now he wants to maximize the sum of all the strings’ value.
输入:
The input consists of several test cases. Each test case starts with a line containing two integers N and M.
Each of the following N lines contains a single integer Mi indicating the time cost on solving the i-th problem.
(1<=N, M<=100)
[Technical Specification]
T is an integer, and T <= 15;
N and M are integers, 1 <= N, M <= 100.
Mi are integers and, 0 <= Mi <= 100
输出:
The input consists of several test cases. Each test case starts with a line containing two integers N and M.
Each of the following N lines contains a single integer Mi indicating the time cost on solving the i-th problem.
(1<=N, M<=100)
[Technical Specification]
T is an integer, and T <= 15;
N and M are integers, 1 <= N, M <= 100.
Mi are integers and, 0 <= Mi <= 100
样例输入:
1 10 9 6 1 3 1 5 3 2 5 5 5
样例输出:
10
dp[i][j]:从前i个中挑出某些且cost不超过j的最大val。
dp[i][j]:应该有1到i-1的dp[k][j-?]来更新！！
/* DP dp[i][j]:从前i个中挑出某些且cost不超过j的最大val。 */ #include<stdio.h> #include<string.h> #include<stdlib.h> #include<algorithm> #include<iostream> #include<queue> #include<map> #include<stack> #include<set> #include<math.h> using namespace std; typedef long long int64; //typedef __int64 int64; typedef pair<int64,int64> PII; #define MP(a,b) make_pair((a),(b)) const int maxn = 105; const int inf = 0x7fffffff; const double pi=acos(-1.0); const double eps = 1e-8; int dp[ maxn ][ maxn ]; int a[ maxn ]; int main(){ int T; scanf("%d",&T); while( T-- ){ int n,sum; scanf("%d%d",&n,&sum); int MinCost = inf; for( int i=1;i<=n;i++ ){ scanf("%d",&a[i]); if( a[i]<MinCost ) MinCost = a[i]; } if( MinCost>sum ){ printf("0\n"); continue; } if( MinCost==sum ){ puts("1"); continue; } int ans = 0; memset( dp,0,sizeof( dp ) ); for( int i=1;i<=n;i++ ){ for( int j=0;j<=sum;j++ ){ int cnt = 0; for( int k=1;k<=i;k++ ){ cnt += a[ i+1-k ]; if( cnt>j ) break; dp[i][j] = max( dp[i][j],dp[i-k][j-cnt]+k*k ); } dp[i][j] = max( dp[i][j],dp[i-1][j] ); ans = max( ans,dp[i][j] ); } } printf("%d\n",ans); } return 0; }
解题转自：http://www.cnblogs.com/justforgl/archive/2013/08/13/3256043.html
最左边那个是石女吧。。。
其实不需要用LCA，用DFS+vector更简单
我想整理一下leetcode的题解，站长能不能给权限
根本过不了。。。。
惊艳了，没想到代码如此简洁
这个问题别太纠结了，不同的编译器结果不一
说的就是无向图啊，有向图的算法也是类似的
我觉得是D哎……
原来欧几里德定理应用这么多
嗯 分析得很到位，确实用模板编程能让面试官对你的印象更好。在设置辅助栈的时候可以这样：push时，比较要push的elem和辅助栈的栈顶，elem<=min.top()，则min.push(elem).否则只要push（elem）就好。在pop的时候，比较stack.top()与min.top(),if(stack.top()<=min.top()),则{stack.pop();min.pop();}，否则{stack.pop();}.
,,,,,,,,,,,,,,,
学习了
第15行代码，/n/n，应该改为nn
I go through some of your put up and I uncovered a good deal of expertise from it. Many thanks for posting this sort of exciting posts
这个 。。。。不是动态规划吧？


--- layout: data_model title: PESectionHeaderStructType this_version: 1.1.1 ---
The PESectionHeaderStruct type is intended as container for the properties relevant to a PE binary's section header structure.
| Field Name | Type | Description |
|---|---|---|
| Name0..1 | StringObjectPropertyType |
The Name field specifies the name of the PE binary section. |
| Virtual_Size0..1 | HexBinaryObjectPropertyType |
The Virtual_Size field is the total size of the PE binary section when loaded into memory. It is valid only for executables and should be 0 for object files. |
| Virtual_Address0..1 | HexBinaryObjectPropertyType |
The Virtual_Address field specifies the relative virtual address (RVA) of the PE binary section. |
| Size_Of_Raw_Data0..1 | HexBinaryObjectPropertyType |
The Size_Of_Raw_Data field specifies the size of the data contained in the PE binary section. |
| Pointer_To_Raw_Data0..1 | HexBinaryObjectPropertyType |
The Pointer_To_Raw_Data field specifies the file offset of the beginning of the PE binary section. |
| Pointer_To_Relocations0..1 | HexBinaryObjectPropertyType |
The Pointer_To_Relocations field specifies the offset of the PE binary section relocations, if applicable. |
| Pointer_To_Linenumbers0..1 | HexBinaryObjectPropertyType |
Specifies the beginning of line-number entries for the section. Should be 0. |
| Number_Of_Relocations0..1 | NonNegativeIntegerObjectPropertyType |
The Number_Of_Relocations field specifies the number of relocations defined for the specified PE binary section. |
| Number_Of_Linenumbers0..1 | NonNegativeIntegerObjectPropertyType |
Specifies the number of line number entries for the section. Should be 0. |
| Characteristics0..1 | HexBinaryObjectPropertyType |
The Characteristics field specifies any flags defined for the specified PE binary section. |


| Python | {{ frames[0].filename }} in {{ frames[0].function }}, line {{ frames[0].lineno }} |
|---|---|
| Web | {{ request_method }} {{ request_path }} |
{{ frame.filename }}
in {{ frame.function }}
{% if frame.context_line %}
{{ response_output }}
You're seeing this because you have the debug
setting
set to True
. Set that to False
if you don't to see this.


#include <uip.h>
Data Fields | |
| struct { | |
| uip_stats_t drop | |
| uip_stats_t recv | |
| uip_stats_t sent | |
| uip_stats_t vhlerr | |
| uip_stats_t hblenerr | |
| uip_stats_t lblenerr | |
| uip_stats_t fragerr | |
| uip_stats_t chkerr | |
| uip_stats_t protoerr | |
| } | ip |
| IP statistics. | |
| struct { | |
| uip_stats_t drop | |
| uip_stats_t recv | |
| uip_stats_t sent | |
| uip_stats_t typeerr | |
| } | icmp |
| ICMP statistics. | |
| struct { | |
| uip_stats_t drop | |
| uip_stats_t recv | |
| uip_stats_t sent | |
| uip_stats_t chkerr | |
| uip_stats_t ackerr | |
| uip_stats_t rst | |
| uip_stats_t rexmit | |
| uip_stats_t syndrop | |
| uip_stats_t synrst | |
| } | tcp |
| TCP statistics. |
|
|
Number of TCP segments with a bad ACK number.
|
|
|
Number of TCP segments with a bad checksum.
|
|
|
Number of dropped TCP segments.
|
|
|
Number of packets dropped since they were IP fragments.
|
|
|
Number of packets dropped due to wrong IP length, high byte.
|
|
|
Number of packets dropped due to wrong IP length, low byte.
|
|
|
Number of packets dropped since they were neither ICMP, UDP nor TCP.
|
|
|
Number of recived TCP segments.
|
|
|
Number of retransmitted TCP segments.
|
|
|
Number of recevied TCP RST (reset) segments.
|
|
|
Number of sent TCP segments.
|
|
|
Number of dropped SYNs due to too few connections was avaliable.
|
|
|
Number of SYNs for closed ports, triggering a RST.
|
|
|
Number of ICMP packets with a wrong type.
|
|
|
Number of packets dropped due to wrong IP version or header length.
|


Pharmacy Store & Inventory Management Dashboard
Filter By
Patient Type
Patient
Staff
Billing Type Item
Dispensing Store
Select Patient Type
{{type.CategoryName}}
Enter Patient's Hospital Number
Enter Staff's Username Here
Set Filter


Home
About Us
Service
Contact Us
SIGN UP
Menu
Learn
Anywhare
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque sit amet volutpat libero.
Get Started
Or Contact


Youth Pizza Ninjas
Order Now
+
Enter Delivery Information
Name*
Phone Number*
Address Type*
House
Apartment
Business
Campus
Hotel
Dorm
Other
Other
Address*
City*
Zip*
Order
* required


| Methods' Summary |
| initialize |
initializes the object.
|
| Methods' Details |
initialize
| void |
| initialize( |
[in] sequence< any > |
aArguments ) |
| raises( |
::com::sun::star::uno::Exception ); |
- Description
- initializes the object.
It should be called directly after the object is created.
|
|
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.


| Exception | Description |
|---|---|
| OpenCycUnsupportedFeatureException |
Indicates that a particular piece of functionality is categorically unsupported by OpenCyc
servers.
|
| SessionCommandException |
SessionCommandException indicates that Session implementation code could communicate with a Cyc
server, but encountered a problem issuing a command or interpreting a result.
|
| SessionCommunicationException |
SessionCommunicationException indicates that an application library encountered a problem when
attempting to communicate with a Cyc server.
|
| SessionConfigurationException |
CycSessionException indicates that a Cyc session has been mis-configured or not been configured
at all.
|
| SessionException |
SessionException is the base exception which indicates that an application library has
encountered a problem in interacting with a Cyc server.
|
| SessionInitializationException |
SessionInitializationException indicates that a problem was encountered when initializing a
CycSession.
|
| SessionManagerConfigurationException |
Indicates that a
SessionManagerConfiguration has been mis-configured or not been
configured at all. |
| SessionManagerException |
Indicates an error with an existing
SessionManager . |
| SessionRuntimeException |
SessionRuntimeException is the base runtime exception which indicates that an application library
has encountered a problem in interacting with a Cyc server.
|
| SessionServiceException |
SessionServiceException occur when the Session API has trouble loading a service provider.
|
| UnsupportedCycOperationException |
Thrown to indicate that a Cyc server does not support a particular operation.
|
Copyright © 2015–2018 Cycorp, Inc. All rights reserved.


|
e2e/app.po.ts
|
class
|
AngularMaterialAppPage
|
0 %
(0/3)
|
|
src/app/admin/admin.component.ts
|
component
|
AdminComponent
|
0 %
(0/9)
|
|
src/app/analysis/analysis.service.ts
|
injectable
|
AnalysisService
|
0 %
(0/7)
|
|
src/app/analysis/crowd/age/age.component.ts
|
component
|
AgeComponent
|
0 %
(0/10)
|
|
src/app/analysis/crowd/brand/brand.component.ts
|
component
|
BrandComponent
|
0 %
(0/3)
|
|
src/app/analysis/crowd/consumer/consumer.component.ts
|
component
|
ConsumerComponent
|
0 %
(0/10)
|
|
src/app/analysis/crowd/crowd.component.ts
|
component
|
CrowdComponent
|
0 %
(0/12)
|
|
src/app/analysis/crowd/gender/gender.component.ts
|
component
|
GenderComponent
|
0 %
(0/3)
|
|
src/app/analysis/crowd/operators/operators.component.ts
|
component
|
OperatorsComponent
|
0 %
(0/10)
|
|
src/app/analysis/crowd/permeability/permeability.component.ts
|
component
|
PermeabilityComponent
|
0 %
(0/14)
|
|
src/app/analysis/crowd/region/region.component.ts
|
component
|
RegionComponent
|
0 %
(0/3)
|
|
src/app/analysis/equipment/brand/brand.component.ts
|
component
|
EquipmentBrandComponent
|
0 %
(0/14)
|
|
src/app/analysis/equipment/equipment.component.ts
|
component
|
EquipmentComponent
|
0 %
(0/7)
|
|
src/app/analysis/population/population.component.ts
|
component
|
PopulationComponent
|
0 %
(0/3)
|
|
src/app/analysis/preference/field/field.component.ts
|
component
|
PreferenceFieldComponent
|
0 %
(0/14)
|
|
src/app/analysis/preference/preference.component.ts
|
component
|
PreferenceComponent
|
0 %
(0/9)
|
|
src/app/analysis/scene-portrait/scene-portrait.component.ts
|
component
|
ScenePortraitComponent
|
0 %
(0/14)
|
|
src/app/apm/apm.service.ts
|
injectable
|
ApmService
|
0 %
(0/2)
|
|
src/app/apm/error/detail/detail.component.ts
|
component
|
DetailComponent
|
0 %
(0/12)
|
|
src/app/apm/error/error.component.ts
|
component
|
ErrorComponent
|
0 %
(0/11)
|
|
src/app/apm/performance/performance.component.ts
|
component
|
PerformanceComponent
|
0 %
(0/5)
|
|
src/app/apm/performance/view/view.component.ts
|
component
|
ViewComponent
|
0 %
(0/3)
|
|
src/app/app.component.ts
|
component
|
AppComponent
|
0 %
(0/1)
|
|
src/app/chart/bar/bar.component.ts
|
component
|
BarComponent
|
0 %
(0/11)
|
|
src/app/chart/chart.component.ts
|
component
|
ChartComponent
|
0 %
(0/2)
|
|
src/app/chart/doughnut/doughnut.component.ts
|
component
|
DoughnutComponent
|
0 %
(0/8)
|
|
src/app/chart/line/line.component.ts
|
component
|
LineComponent
|
0 %
(0/10)
|
|
src/app/chart/pie/pie.component.ts
|
component
|
PieComponent
|
0 %
(0/8)
|
|
src/app/chart/polar/polar.component.ts
|
component
|
PolarComponent
|
0 %
(0/9)
|
|
src/app/chart/radar/radar.component.ts
|
component
|
RadarComponent
|
0 %
(0/8)
|
|
src/app/chats/chat/chat.component.ts
|
component
|
ChatComponent
|
0 %
(0/15)
|
|
src/app/chats/chats.component.ts
|
component
|
ChatsComponent
|
0 %
(0/10)
|
|
src/app/chats/chats.model.ts
|
class
|
Chat
|
0 %
(0/5)
|
|
src/app/chats/chats.service.ts
|
injectable
|
ChatsService
|
0 %
(0/12)
|
|
src/app/chats/contacts/contacts.component.ts
|
component
|
ContactsComponent
|
0 %
(0/6)
|
|
src/app/chats/notice/notice.component.ts
|
component
|
NoticeComponent
|
0 %
(0/1)
|
|
src/app/component/amap/amap.component.ts
|
component
|
AmapComponent
|
0 %
(0/13)
|
|
src/app/component/amap/amap.token.ts
|
interface
|
IMapAPILoaderConfig
|
0 %
(0/4)
|
|
src/app/component/button/button.component.ts
|
component
|
ButtonComponent
|
0 %
(0/2)
|
|
src/app/component/button/button.directive.ts
|
directive
|
ButtonDirective
|
0 %
(0/2)
|
|
src/app/component/date-picker/calendar/calendar.component.ts
|
component
|
CalendarComponent
|
0 %
(0/18)
|
|
src/app/component/date-picker/date-display/date-display.component.ts
|
component
|
DateDisplayComponent
|
0 %
(0/4)
|
|
src/app/component/date-picker/date-picker.component.ts
|
component
|
DatePickerComponent
|
0 %
(0/9)
|
|
src/app/component/date-picker/date-picker.pipe.ts
|
pipe
|
DatePickerPipe
|
0 %
(0/1)
|
|
src/app/component/date-picker/day-button/day-button.component.ts
|
component
|
DayButtonComponent
|
0 %
(0/7)
|
|
src/app/component/date-picker/month/month.component.ts
|
component
|
MonthComponent
|
0 %
(0/6)
|
|
src/app/component/date-picker/toolbar/toolbar.component.ts
|
component
|
ToolbarComponent
|
0 %
(0/6)
|
|
src/app/component/file-upload/file-upload.component.ts
|
component
|
FileUploadComponent
|
0 %
(0/4)
|
|
src/app/component/file-upload/file-upload.directive.ts
|
directive
|
FileUploadDirective
|
0 %
(0/12)
|
|
src/app/component/file-upload/file-upload.model.ts
|
class
|
Upload
|
0 %
(0/8)
|
|
src/app/component/file-upload/file-upload.service.ts
|
injectable
|
FileUploadService
|
0 %
(0/7)
|
|
src/app/component/loading/loading.component.ts
|
component
|
LoadingComponent
|
0 %
(0/2)
|
|
src/app/component/loading/loading.directive.ts
|
directive
|
LoadingDirective
|
0 %
(0/2)
|
|
src/app/component/loading/loading.interface.ts
|
interface
|
LoadingInterface
|
0 %
(0/4)
|
|
src/app/component/notification/notification.component.ts
|
component
|
NotificationComponent
|
0 %
(0/10)
|
|
src/app/component/notification/notification.config.ts
|
class
|
NotificationConfig
|
0 %
(0/12)
|
|
src/app/component/notification/notification.directive.ts
|
directive
|
NotificationContainerDirective
|
0 %
(0/3)
|
|
src/app/component/notification/notification.injector.ts
|
class
|
NotificationInjector
|
0 %
(0/3)
|
|
src/app/component/notification/notification.interface.ts
|
interface
|
NotificationIconClasses
|
0 %
(0/5)
|
|
src/app/component/notification/notification.interface.ts
|
interface
|
NotificationInterface
|
0 %
(0/8)
|
|
src/app/component/notification/notification.ref.ts
|
class
|
NotificationRef
|
0 %
(0/10)
|
|
src/app/component/notification/notification.service.ts
|
injectable
|
NotificationService
|
0 %
(0/11)
|
|
src/app/component/notification/notification.service.ts
|
interface
|
Activate
|
0 %
(0/9)
|
|
src/app/component/pagination/pagination.component.ts
|
component
|
PaginationComponent
|
0 %
(0/11)
|
|
src/app/component/popover/popover.component.ts
|
component
|
PopoverComponent
|
0 %
(0/22)
|
|
src/app/component/popover/popover.directive.ts
|
directive
|
PopoverDirective
|
0 %
(0/5)
|
|
src/app/component/search/search.component.ts
|
component
|
SearchComponent
|
0 %
(0/8)
|
|
src/app/component/table/table.component.ts
|
component
|
TableComponent
|
0 %
(0/33)
|
|
src/app/core/auth.service.ts
|
injectable
|
AuthService
|
16 %
(2/12)
|
|
src/app/crm/contact/contact.component.ts
|
component
|
ContactComponent
|
0 %
(0/5)
|
|
src/app/crm/contact/contact.component.ts
|
component
|
ContactUpdateComponent
|
0 %
(0/3)
|
|
src/app/crm/contract/contract.component.ts
|
component
|
ContractComponent
|
0 %
(0/3)
|
|
src/app/crm/crm.component.ts
|
component
|
CrmComponent
|
0 %
(0/3)
|
|
src/app/crm/customer-common/customer-common.component.ts
|
component
|
CustomerCommonComponent
|
0 %
(0/3)
|
|
src/app/crm/customer/customer.component.ts
|
component
|
CustomerComponent
|
0 %
(0/3)
|
|
src/app/crm/lead/lead.component.ts
|
component
|
LeadComponent
|
0 %
(0/15)
|
|
src/app/crm/lead/lead.service.ts
|
injectable
|
LeadService
|
0 %
(0/3)
|
|
src/app/crm/opportunities/opportunities.component.ts
|
component
|
OpportunitiesComponent
|
0 %
(0/3)
|
|
src/app/crm/product/product.component.ts
|
component
|
ProductComponent
|
0 %
(0/3)
|
|
src/app/customizer/customizer.component.ts
|
component
|
CustomizerComponent
|
0 %
(0/12)
|
|
src/app/customizer/customizer.interface.ts
|
interface
|
CustomizerInterface
|
0 %
(0/6)
|
|
src/app/dashboard/dashboard.component.ts
|
component
|
DashboardComponent
|
0 %
(0/3)
|
|
src/app/footer/footer.component.ts
|
component
|
FooterComponent
|
0 %
(0/3)
|
|
src/app/forms/editor/editor.component.ts
|
component
|
EditorComponent
|
0 %
(0/3)
|
|
src/app/forms/elements/elements.component.ts
|
component
|
ElementsComponent
|
0 %
(0/3)
|
|
src/app/forms/forms.component.ts
|
component
|
FormsComponent
|
0 %
(0/3)
|
|
src/app/forms/validation/validation.component.ts
|
component
|
ValidationComponent
|
0 %
(0/9)
|
|
src/app/header/header.component.ts
|
component
|
HeaderComponent
|
0 %
(0/9)
|
|
src/app/header/toolbar-help/toolbar-help.component.ts
|
component
|
ToolbarHelpComponent
|
0 %
(0/3)
|
|
src/app/header/toolbar-notification/toolbar-notification.component.ts
|
component
|
ToolbarNotificationComponent
|
0 %
(0/9)
|
|
src/app/header/toolbar-notification/toolbar-notification.model.ts
|
class
|
ToolbarNotificationModel
|
0 %
(0/5)
|
|
src/app/header/toolbar-notification/toolbar-notification.service.ts
|
injectable
|
ToolbarNotificationService
|
0 %
(0/6)
|
|
src/app/header/toolbar-user/toolbar-user.component.ts
|
component
|
ToolbarUserComponent
|
0 %
(0/8)
|
|
src/app/home/home.component.ts
|
component
|
HomeComponent
|
0 %
(0/3)
|
|
src/app/mail/compose/compose.component.ts
|
component
|
ComposeComponent
|
0 %
(0/9)
|
|
src/app/mail/detail/detail.component.ts
|
component
|
DetailComponent
|
0 %
(0/5)
|
|
src/app/mail/list/list.component.ts
|
component
|
ListComponent
|
0 %
(0/6)
|
|
src/app/mail/mail.component.ts
|
component
|
MailComponent
|
0 %
(0/11)
|
|
src/app/mail/mail.service.ts
|
injectable
|
MailService
|
0 %
(0/6)
|
|
src/app/mail/toolbar/toolbar.component.ts
|
component
|
ToolbarComponent
|
0 %
(0/7)
|
|
src/app/materials/amap/amap.component.ts
|
component
|
AmapComponent
|
0 %
(0/3)
|
|
src/app/materials/buttons/buttons.component.ts
|
component
|
ButtonsComponent
|
0 %
(0/3)
|
|
src/app/materials/calendar/calendar.component.ts
|
component
|
CalendarComponent
|
0 %
(0/11)
|
|
src/app/materials/cards/cards.component.ts
|
component
|
CardsComponent
|
0 %
(0/3)
|
|
src/app/materials/date-picker/date-picker.component.ts
|
component
|
DatePickerComponent
|
0 %
(0/3)
|
|
src/app/materials/dialogs/dialogs.component.ts
|
component
|
DialogsComponent
|
0 %
(0/5)
|
|
src/app/materials/icon/icon.component.ts
|
component
|
IconComponent
|
0 %
(0/3)
|
|
src/app/materials/lists/lists.component.ts
|
component
|
ListsComponent
|
0 %
(0/3)
|
|
src/app/materials/markdown/markdown.component.ts
|
component
|
MarkdownComponent
|
0 %
(0/6)
|
|
src/app/materials/menu/menu.component.ts
|
component
|
MenuComponent
|
0 %
(0/3)
|
|
src/app/materials/pagination/pagination.component.ts
|
component
|
PaginationComponent
|
0 %
(0/5)
|
|
src/app/materials/popover/popover.component.ts
|
component
|
PopoverComponent
|
0 %
(0/5)
|
|
src/app/materials/slider/slider.component.ts
|
component
|
SliderComponent
|
0 %
(0/3)
|
|
src/app/materials/tabs/tabs.component.ts
|
component
|
TabsComponent
|
0 %
(0/8)
|
|
src/app/materials/toast/toast.component.ts
|
component
|
ToastComponent
|
0 %
(0/12)
|
|
src/app/materials/tooltips/tooltips.component.ts
|
component
|
TooltipsComponent
|
0 %
(0/3)
|
|
src/app/navigation/navigation.component.ts
|
component
|
NavigationComponent
|
0 %
(0/16)
|
|
src/app/navigation/navigation.service.ts
|
injectable
|
NavigationService
|
0 %
(0/4)
|
|
src/app/pages/about/about.component.ts
|
component
|
AboutComponent
|
0 %
(0/3)
|
|
src/app/pages/blog/blog.component.ts
|
component
|
BlogComponent
|
0 %
(0/3)
|
|
src/app/pages/collection/collection.component.ts
|
component
|
CollectionComponent
|
0 %
(0/3)
|
|
src/app/pages/contact/contact.component.ts
|
component
|
ContactComponent
|
0 %
(0/3)
|
|
src/app/pages/file-manager/file-manager.component.ts
|
component
|
FileManagerComponent
|
0 %
(0/3)
|
|
src/app/pages/file-manager/file-manager.firebase.ts
|
injectable
|
FileManagerFirebase
|
0 %
(0/8)
|
|
src/app/pages/pages.component.ts
|
component
|
PagesComponent
|
0 %
(0/3)
|
|
src/app/pages/profile/profile.component.ts
|
component
|
ProfileComponent
|
0 %
(0/3)
|
|
src/app/pages/project/project.component.ts
|
component
|
ProjectComponent
|
0 %
(0/1)
|
|
src/app/pages/services/services.component.ts
|
component
|
ServicesComponent
|
0 %
(0/3)
|
|
src/app/pages/signin/signin.component.ts
|
component
|
SigninComponent
|
0 %
(0/13)
|
|
src/app/pages/signup/signup.component.ts
|
component
|
SignupComponent
|
0 %
(0/9)
|
|
src/app/pages/user/user.component.ts
|
component
|
UserComponent
|
0 %
(0/10)
|
|
src/app/pages/user/user.service.ts
|
injectable
|
UserService
|
0 %
(0/3)
|
|
src/app/sidenav/item/item.component.ts
|
component
|
ItemComponent
|
37 %
(3/8)
|
|
src/app/sidenav/item/item.model.ts
|
class
|
SidenavItem
|
0 %
(0/15)
|
|
src/app/sidenav/sidenav.component.ts
|
component
|
SidenavComponent
|
0 %
(0/9)
|
|
src/app/sidenav/sidenav.service.ts
|
injectable
|
SidenavService
|
0 %
(0/14)
|
|
src/app/tables/datatable/datatable.component.ts
|
component
|
DatatableComponent
|
0 %
(0/6)
|
|
src/app/tables/datatable/datatable.service.ts
|
injectable
|
DataTableService
|
0 %
(0/10)
|
|
src/app/tables/dynamic/dynamic.component.ts
|
component
|
DynamicComponent
|
0 %
(0/8)
|
|
src/app/tables/static/static.component.ts
|
component
|
StaticComponent
|
0 %
(0/5)
|
|
src/app/tables/tables.component.ts
|
component
|
TablesComponent
|
0 %
(0/3)
|
|
src/app/todo/todo-header/todo-header.component.ts
|
component
|
TodoHeaderComponent
|
0 %
(0/8)
|
|
src/app/todo/todo-item/todo-item.component.ts
|
component
|
TodoItemComponent
|
0 %
(0/9)
|
|
src/app/todo/todo-list/todo-list.component.ts
|
component
|
TodoListComponent
|
0 %
(0/9)
|
|
src/app/todo/todo-search/todo-search.component.ts
|
component
|
TodoSearchComponent
|
0 %
(0/2)
|
|
src/app/todo/todo-sidenav/todo-sidenav.component.ts
|
component
|
TodoSidenavComponent
|
0 %
(0/1)
|
|
src/app/todo/todo-toolbar/todo-toolbar.component.ts
|
component
|
TodoToolbarComponent
|
0 %
(0/2)
|
|
src/app/todo/todo.component.ts
|
component
|
TodoComponent
|
0 %
(0/11)
|
|
src/app/todo/todo.model.ts
|
class
|
Todo
|
0 %
(0/7)
|
|
src/app/todo/todo.service.ts
|
injectable
|
TodoService
|
0 %
(0/9)
|
|
src/app/widget/state/state.component.ts
|
component
|
StateComponent
|
0 %
(0/10)
|
|
src/app/widget/switch/switch.component.ts
|
component
|
SwitchComponent
|
0 %
(0/6)
|


WITNESS LIST Land & Resource Management Committee March 24, 2003-10:00A HB 1129 Registering, but not testifying: For: O'Brien, Mike (Houston Homeowners Association) HB 1454 For: McClendon, Sidney (West Galveston Island POA) Mohn, Jerry (West Galveston Island Property Owners Assoc.) Registering, but not testifying: For: Heyer, Connie (Texas Community Associations Institute) HB 1456 For: McClendon, Sidney (West Galveston Island Property Owner's Assoc) Mohn, Jerry (West Galveston Island Property Owners Assoc.) Patterson, Jerry (Texas General Land Office) On: Fisher, Eddie R. (Texas General Land Office) HB 1457 For: McClendon, Sidney (Galveston County Beach Erosion Task Force, West Galveston Island POA) Mohn, Jerry (West Galveston Island Property Owners Assoc.) Patterson, Jerry (Texas General Land Office) Against: Marston, Jim (Enviromental Defense) McNamara, Dan (Lone Star Chapter of the Sierra Club) Schwartz, A. R. "Babe" (Self) Turner, Keeton (Self and Surfrider Foundation (Texas Chapters)) On: Kornell, Karen W. (Office of the Attorney General) Registering, but not testifying: Against: Hallmark, Dr. Terry (Self and Texas Chapter, Surfrider Foundation) HB 1563 For: Patterson, Jerry (Texas General Land Office) On: Dorsey, Susan Smith (General Land Office) Kilpatrick, Joan (General Land Office) HB 1680 For: Clayton, Bill (Northwest Austin Municipal Utility District No. 1) Coleman, Harold G. (Self) Mueller, Paul (Self) Smith, Jennifer (N.W. Austin MUD No. 1, Named Plaintiffs in NW Austin MUD et.al. v. City of Austin) Weiss, Alan R. (Self and NW Austin #1 M.U.D.) Zimmerman, Don (President, NW Austin MUD #1) Against: Matebus, Nancy (City of Austin) Registering, but not testifying: For: Arlitt, Mark (Self) Ban, Oliver K. (Self) Bowers, Dr. Chris (Self) Chung, Dae-Suk (Self) Cook, Molly (Self) Costa, Pierre (Self) Curley, Sherri (Self) Davis, Robyn (Self) Devenport, John T. (Self) Devenport, Virginia (Self) Dixon, Sam (Self) Dwyer, Pat W. (Self) Fischer, Lauri (Self) Gingrich, Paul (Self) Hall III, Clifford L. (Self) Howard, John (Self) Keefer, Shelia (Self) Krishnan, Gopal N. (Self) Livaudais, Frank (Self and 13 Colonies Software) Ludwick, Gail (Self) Ludwig, Ann (Self) Luttrell, Amy (Self) Lyon, Charles F. (Self) Matwiczak, Barbara (Self) Matwiczak, Ken (Self) Mayer, Dan E. (Self) Olin, Constance (Self) Payne, Kathryn M. (Self) Pena, Arthur J. (Self) Reilly, Frank (Northwest Austin Munic. Utility Dist. #1) Rouder, Robert (Self) Sabrsula, Paula (Self and Canyon Creek Subdivision) Sabrsula, Scott (Canyon Creek Subdivision) Schuler, Bernhard (Self) Smith, Patrick R. (Self) Stanley, James F. (Self) Temborius, Karen (Self) Vanzant, Charles V. (Self and Claudia Q. Vanzant) Vinecombe, Rita (Self) Walsh, Edward (Self) Walsh, Susan (Self) Wei, Hua (Self) Yamamoto, Keiichi (Self) Yang, Shenling (Self) Yu, Jim (Self) Zhou, Ting (Self) HB 2130 For: Douglas, Craig (Home Builders Assn. of Greater Austin) Harris, John B. (Self and HBA Greater Austin) Savio, Harry (Home Builders Association of Greater Austin) Against: Rockwell, Brad (Save Our Springs Alliance) Registering, but not testifying: For: Barton, Lisa (Texas Hotel & Motel Asn) Erben, Andy (KB Home) Haywood, Alan (Self) Heyer, Connie (Texas Building Owners and Managers Association (BOMA)) Heyer, Connie (Texas Mini Storage Association (TMSA)) Mintz, David (Texas Apartment Association) Norman, Scott (Texas Association of Builders) Against: Alvarez, Raul (Self) Baker Jr., Roger C. (Self) Bulla, Pat (Self) Ellison, Deborah L. (Self) Marston, Jim (Enviromental Defense) HB 2130 Committee Substitute (2130) Against: Murphy, Patrick (City Of Austin)


This material may be excerpted, quoted, or distributed freely provided that attribution to the author (Carey Sublette), the document name (Nuclear Weapons Frequently Asked Questions) and this copyright notice is clearly preserved, and the URL of this website is included: Nuclear Weapon Archive
Only authorized host sites may make this document publicly available on the Internet through the World Wide Web, anonymous FTP, or other means.
Unauthorized host sites are expressly forbidden.
The only authorized host site for the NWFAQ in English is the Nuclear Weapon Archive (nuclearweaponarchive)
Since the various design elements of a thermonuclear weapon combine to form a complex integrated system, discussing the design space of these weapons involves complicated tradeoffs between design objectives and has many possible design variations.
In an attempt to address this in some kind of orderly fashion I first sketch out several basic structures for the overall weapon, in rough order of increasing sophistication (Subsection 4.5.1 Principle Design Types). Following this, I address a series of possible tradeoffs and the issues connected wit each.
4.5.1 Principle Design Types The descriptions of weapon designs, and the developmental sequence described is speculative, but it is consistent with all facts about weapons, weapon development programs, and physics of which I am currently aware.
<IP_ADDRESS> Early Designs The earliest radiation implosion designs seem to have used a single large cylindrical chamber encompassing both the primary and cylindrical secondary. The casing was hemispherical at one end, where the primary sphere was located. The thermonuclear weapon was integral to the bomb casing itself - i.e. the ballistic shell of the bomb was the support structure for the radiation case, and the physical structure that held the entire thermonuclear device together.
Both the US and UK initially used casings made of steel, which were lined with lead or lead bismuth alloy to form the radiation case (probably 1-3 cm thick). The secondary pusher, which made up the inner wall of the radiation channel, was made of either natural uranium or lead (possibly as a lead- bismuth alloy). Operational bombs probably all used uranium tampers to maximize yield, but some test devices were equipped with lead tampers to hold down yield and fallout production. A massive radiation shield (uranium or lead) was located between the primary and secondary to prevent fuel preheating by the thermal radiation flux. A boron neutron shield was used in some designs to reduce neutron preheating.
The secondary stage consisted of the exterior pusher/tamper, a standoff gap, and a cylinder filled with fusion fuel. Lithium deuteride, highly enriched in Li-6, was the preferred fuel for maximum yield but early shortages in lithium enrichment capacity lead to the deployment of bombs containing partially enriched lithium (40% and 60% Li-6 in the U.S.), or natural lithium. Down the axis of the fusion fuel cylinder was a solid (or nearly solid) rod of plutonium or HEU for the spark plug.
The design approach of these early bombs followed that of Mike and the test devices exploded during Castle: the use of a standoff gap to create the necessary gradual compression required a large diameter (Mike was 80 inches wide, all of the Castle series devices had diameters from 54 to 61.5 inches). The rapid energy release from the primary followed by a relatively lengthy implosion required a thick casing for radiation containment, making the entire bomb very heavy. Mike weighed an anomalous 164,000 pounds, but even the Castle devices all weighed in between 23,500 and 40,000 lb.
These early bombs were thus quite massive, and had high yields. The Mk 17 and Mk 24 (the weaponized version of Castle Romeo, using unenriched lithium deuteride) had a diameter of 61.4 inches and a weight of 42,000 lb (yield: 15-20 megatons). The relatively compact and light Mk 15, whose development was completed somewhat later (and used 95% Li-6 deuteride), still had a diameter of 34.6 inches and weighed over 7,000 lb (yield: 3.8 megatons). And all of these weapons *were* bombs, since no missile could carry them. In fact, only the very largest aircraft could carry them - one per plane.
Although the primaries used in these bombs were much improved over early fission designs, they were still relatively massive initially. The TX-5 primary used in the Mike device still weighed in at well over 1000 kg, and the comparatively thick tamper and explosive layers delayed the escape of both photons and neutrons significantly, by up to 100 nanoseconds.
<IP_ADDRESS> Modular Weapons
During the fifties the diameter of the bomb casing and the primary shrank as US and Soviet weapons became more compact, partly driven by improved primary designs. Lighter weight megaton-range weapons were desired for greater flexibility in the types of aircraft that could carry them, and for increased payload. Light weight high yield weapons were especially important for the early ICBMs, which had limited payloads, and low accuracy. Only a light weight, high yield weapon would give a reasonable chance of destroying a designated target when carried by an ICBM. It was also useful if the same basic weapon design could be used in different weapon systems (bombs, ballistic missiles, cruise missiles, etc.)
This led to a modular approach to the weapon system. Instead of the aerodynamic casing of the delivered munition, the electronics, and the "physics package" being a single integrated entity - these three things were separated. The nuclear warhead proper (the "physics package") was self- contained, except for a cable connector to the electronics that detonated the explosives, and fired the neutron generator. The electronics package was separate, and could be different for each type of weapon (especially important for the varying fuzing requirements). These two components could then be fitted into different bomb or missile bodies to create multiple types of deployable systems.
Since the warhead casing no longer needed to withstand the environmental rigors of the completed weapon, it could be made out of lighter and less rugged materials. This led to the use of a light casing (aluminum alloy, or even plastic) that was lined with a high-Z material to form a radiation case.
<IP_ADDRESS> Compact Light Weight Designs More efficient implosion systems and the advent of boosting made primaries more compact and less massive without sacrificing yield of efficiency. At this point (which occurred in the U.S. around 1955-1956), there seem to have been different development paths available.
One path followed the existing design principles, harnessing the increased temperatures and pressures generated by boosted light weight primaries through greater radiation confinement by increasing the thickness of the radiation case at the primary end. This evolved into a separate radiation case for the primary, a spherical shell of uranium (for example) surrounding the high explosive shell of the implosion system, with an aperture for releasing the radiation into the secondary radiation chamber (the chamber made by lining the external casing). The energy absorbed by the primary case wall at a high temperature was reradiated as the temperature in the chamber dropped. This made confinement and channeling of the thermal radiation more effective. Baffles or other barriers could be added to modulate the energy transfer into the secondary radiation case.
It appears that an alternate path may have been followed by the US starting with the Hardtack I test series (although possibly first pioneered in Redwing). According to statements made by LLNL scientists Wood and Nuckolls, and LASL Director Bradbury, new design ideas were introduced at this time that extended the Teller-Ulam concept. This coincides with the development of the very light W-47 warhead for the Polaris missile (600 lb weight and 600 kt yield, later increased to 800 kt). I speculate that the design approach introduced here was the use of modulated primary energy release.
<IP_ADDRESS> Two Chamber Designs
At some point, the development trend toward a separate radiation case around the primary lead to a full two chamber design for the weapon, with some means of regulating radiation flow between the chambers (like a temporary radiation barrier). With better control over the radiation flux around the secondary, a reduced standoff with a reduced secondary diameter (and perhaps a lighter pusher/tamper) became possible.
This could also be conveniently combined with a spherical secondary design. This has been described as the "peanut design" - two spherical hollow chambers joined at the waist, with a primary sphere in one, and a spherical sphere in the other. Alternatively, a two chamber - spherical secondary design can be used with a modulated primary.
This approach offers the inherent advantages of spherical implosion - a smaller radius change for compression in 3-dimensions to attain a given density compared to two. Smaller radius change translates directly into faster implosion, an important consideration in a smaller, lighter, higher pressure weapon design which would be prone to disassemble faster.
In a spherical secondary the radiation shield between the primary and secondary would evolve into a baffle between the two chamber to prevent the primary from directly (and thus unevenly) heating the side of the secondary facing it, forcing the radiation flux to diffuse into the channel around the secondary.
The primary in a two-chamber design may be effectively encased in a heavy, close fitting uranium shell that can act as an implosion tamper. By trapping the explosive gases, this shell can act as the wall of a spherical piston, forcing the expanding gases to transfer all of their energy to the inward moving beryllium/plutonium shell, and minimizing the amount of explosive required. Such a primary may use a thin uranium or tungsten tamper between the beryllium and plutonium shell layers to enhance inertial confinement of the fissile mass.
<IP_ADDRESS> Hollow Shell Designs
It was pointed out earlier that it is difficult to efficiently compress more than the outermost layers of a solid cylindrical or spherical fuel mass. In any case, only the outermost layers actually *need* to be compressed, since they contain the lion's share of the fuel mass. It would be logical then to dispense with the idea of using a solid fuel mass in the center, and only use a hollow shell of fuel in the first place. A hollow spark plug shell could be nested directly inside the fuel shell, but a second tamper layer may be included between the two.
A hollow shell could be used with either a cylindrical secondary (making it "totally tubular"), or with a spherical design.
Several advantages are obtained with this approach.
The fuel near the center that would be inefficiently compressed is eliminated, improving overall fuel utilization.
The addition of the dense second tamper or spark plug on the inner side of the fuel layer can also directly enhance compression. Whenever a shock reaches the inner side of the fuel, it will be reflected back into the fuel at higher pressure, compressing the fuel further. If the compression gradient is continuous, it will tend to "pile up" at the inner interface, with the same effect of compression enhancement. The dense inertial tamper on the inner side of the fuel layer will also help keep it at a constant high density.
Finally, the hollow shell design allows the spark plug to accelerate to very high velocities before it goes critical. The implosion velocity at criticality could be even higher than the average maximum implosion velocity for the secondary, due to the effects of thick shell collapse and convergence. An implosion velocity exceeding 1000 km/sec is conceivable. This is so fast that densities much higher than those achieved by high explosive systems would be attained before energy production from fission becomes high enough to halt implosion. Even relatively small masses of fissile material (< 1 kg) could be fissioned efficiently.
Hollow shell secondaries would be essential for use with primaries that rely on modulated energy release to create efficient compression.
<IP_ADDRESS> High Yield and Multiple Staged Designs
The first thermonuclear devices were high yield by most any standard (10.4 Mt for Ivy Mike, 15 Mt for Castle Bravo). But they were also very heavy, and difficult to push to even greater yields. High yield weapons with greater yield-to-weight ratios, providing even higher yields in deliverable packages were desired.
As a rough approximation, we can say that the amount of energy required to implode a secondary is proportional to its mass, since the primary energy/secondary mass ratio defines the achievable implosion velocity. The yield of the secondary should also be roughly proportional to its mass. Thus there is a roughly proportional relationship between the primary and secondary yields, using similar design principles.
From available data (based on known trigger tests, and fizzles where only the primary fired), it appears that this range can be from 10-200, with 30- 50 being more typical ratios.
If a very large yield is desired, then we must obviously have a very large primary. Large fission primaries are expensive, heavy, and potentially dangerous (due to the large amount of fissile material present). Even in very heavy weapons, the yield of the primary is limited to no more than a few hundred kilotons, limiting total yield to a maximum of 10-20 megatons.
The high yield designs actually developed (mostly in the fifties and early sixties) seem to have used refined versions of the basic thermonuclear weapon design approach, as described above, with the addition of multiple staging to achieve even higher yields. The relatively light weight W-53 9 Mt warhead/bomb deployed by the US (still in service!), was one of the highest yield warheads the US ever deployed, and probably is a 3 stage weapon.
This is really large enough for almost any conceivable destructive use (except maybe blowing up asteroids). Nonetheless, military requirements for even larger weapons have been drafted, and in the case of the Soviet Union, actually built, tested, and deployed. At one point in the mid-fifties the US military requested a 60 megaton bomb! This military "requirement" was apparently driven by the fact that this was the highest yield device that could be delivered by existing aircraft. The Soviets eventually went on to develop a 100+ megaton design (tested in a 50 megaton configuration). To make such megaweapons, a bigger driving explosion is required to implode the main fusion stage. This has led to the design of three stage weapons, where a thermonuclear secondary is the main driving force to implode a gigantic tertiary stage.
Building gargantuan bombs is not the only motivation for adopting three stage weapons however. If the fusion neutrons are not harnessed to cause fission in the tamper (either because the bomb is intended to be very clean, or very dirty) then the ratio in yields between stages is correspondingly reduced - to a range of something like 10 to 15. This limits the practical maximum yield to 3 to 5 megatons. It may be doubted whether even this is much of a limitation since out of a current arsenal of over 10000 warheads, the US only has 50 bombs with yields over 3 megatons. In the fifties however this seemed unacceptably small, so "clean" weapons were deemed to require three stage design.
Three stage design can provide other advantages though. By offering the weapon designer additional freedom in design, it may be useful even if the bomb is not especially large, clean, or dirty. For example, in optimizing a weapon to minimize weight for a given yield, a designer can consider which type of driver for the main stage is the lightest - a large fission primary or a compact two stage device. If weapon-grade fissile material is very precious, then a two-stage driver might be chosen simply to minimize the over utilization of this material.
In a three stage weapon the radiation cases for the secondary and tertiary might be kept separate initially. The primary would implode the secondary but a barrier would prevent energy from reaching the tertiary. This barrier could be designed to ablate away during the secondary implosion, so that when the secondary energy release occurred, it would have become transparent.
Alternatively it may be useful to harness a portion of the primary's energy to create an initial weak compression shock in the tertiary to enhance compression efficiency.
4.5.2 "Dirty" and "Clean" Weapons
Whether to make a fission-fusion weapon into a fission-fusion-fission weapon is one of the most basic design issues. A fission-fusion weapon uses an inert (or non-fissionable) tamper and will obtain most of its yield from the fusion reaction directly. A fission-fusion-fission weapon will obtain at least half of its yield (and often far more) from the fusion neutron induced fission of a fissionable tamper.
The basic advantage of a fission-fusion-fission weapon is that energy is extracted from a tamper which is otherwise deadweight as far as energy production in concerned. The tamper has to be there, so a lighter weapon for a given yield (or a more powerful weapon for the same weight) can be obtained without varying any other design factors. Since it is possible to do this at virtually no added cost or other penalty, compared to an inert material like lead, by using natural or depleted uranium or thorium there is basically no reason not to do it if the designer is simply interested in making big explosions.
Fission of course produces radioactive debris - fallout. Fallout can be reduced by using a material that does not become highly radioactive when bombarded by neutrons (like lead or tungsten). This requires a heavier and more expensive weapon to produce a given yield, but is also considerably reduces the short and long term contamination associated with that yield.
This is not to say that the weapon is "clean" in any commonsense meaning of the term. Neutrons escaping the weapon can still produce biohazardous carbon-14 through nitrogen capture in the air. The primary and spark plug may still contribute 10-20% fission, which for a multi-megaton weapon may still be a megaton or more of fission. Significant contamination may also occur from the "inert" tamper radioisotopes, and even from the unburned tritium produced in the fusion stage. Reducing these contributions to the lowest possible level is the realm of "minimum residual radiation" designs discussed further below.
During the fifties interest in both the US and USSR was given to developing basic design that had both clean and dirty variants. The basic design tried to minimize the essential fission yield by using a small fission primary, and spark plug sizes carefully chosen to meet ignition requirements for each stage, without being excessive (note that although only part of the spark plug will fission to ignite the fusion stage, the essentially complete fission of the remainder by fusion neutrons is inevitable). These weapons appear to have all been three-stage weapons to allow multi-megaton yields (even in the clean version) with a relatively small primary. The dirty version might simply replace the inert tamper of the tertiary with a fissionable one to boost yield.
The three-stage Bassoon and Bassoon Prime devices tested in Redwing Zuni (27 May 1956, 3.5 Mt, 15% fission) and Redwing Tewa (20 July 1956, 5 Mt, 87% fission) are US tests of this concept. Clearly though, the second test was not simply a copy of the first with a different tamper. The fusion yield dropped from 3 Mt to 0.65 Mt, and the device weight increased from 5500 kg to 7149 kg between the two tests. The inference can be made that the tertiary in the first used a large volume of relatively expensive (but light) Li-6D in a thin tamper, which was replaced by a heavier, cheaper tertiary using less fusion fuel, but a very thick fissionable tamper to capture as many neutrons as possible.
The 50 Mt three stage Tsar Bomba (King of Bombs) tested by the Soviet Union on 30 October 1961 was the largest and cleanest bomb ever tested, with 97% of its yield coming from fusion (fission yield approximately 1.5 Mt). Assuming a primary of 250 kt (to keep the fissile content relatively low for safety reasons), we might postulate secondary and tertiary stages of 3.5 Mt and 46 Mt respectively. This fusion stages would require 1700 kg of Li6D (at 50% fusion efficiency), and something like 250 kt of fission for reliable ignition. If the initial spark plug firings were 25% efficient, later fission would release another 750 kt - placing the total at 1.25 Mt (close enough to the claimed parameters to match within the limits of accuracy).
This was a design though for a 100-150 Mt weapon! A lead tamper was used in the tested device, which could have been replaced with U-238 for the dirty version (thankfully never tested!).
4.5.3 Maximum Yield/Weight Ratio
Except for safety, the weight of a weapon required to provide a given yield is the most important design criterion. In the years since the first nuclear weapon was exploded, far more money has been spent in building nuclear weapon delivery systems than in the weapons themselves. The high cost of delivery for what is basically a rather small package is due to the fact that nuclear delivery systems are generally intended to be used only once. Clearly this is true for missiles, but it is true for bombers as well since recovery and reuse is not part of their nuclear mission profile.
Since the cost of the delivery vehicle is much greater than the cost of the warhead, making the warhead as light as possible for the intended yield quickly came to dominate the weapon design process. this is normally expressed in terms of the yield-to-weight (YTW) ratio (kt/kg).
Naturally it is easier to get a high ratio for a larger bomb. The highest ratio for any warhead in the US arsenal is the 9 Mt Mk-53/B-53 bomb, which happens to be the oldest weapon in service (operational since 1962), but also the largest. At 4000 kg, it has a ratio of 2.25 kt/kg. The Tsar Bomba, as tested, had a ratio of 1.7 kt/kg (its weight was 30 tonnes). As *designed* it had a ratio of 3.4-5 kt/kg!
Table 4.5.3-1. Yield-to-Weight Ratios of Current US Weapons
Weapon YTW Ratio Yield(kt)/Weight(kg) In Service Date Mk-53 2.25 9000/4000 1962 W-88 1.5 475/330 W-80 1.31 170/130 B-83 1.10 1200/1090 W-87 1.0 300/300 W-78 0.96 335/350 W-76 0.61 100/165
The much earlier W-47 warhead seems to have achieved ratios of 2.2-2.7 kt/kg. However YTW ratio is not every thing. The W-87 and W-88 are said to use reduced amounts of expensive nuclear materials (deemed important when ambitious expansion of the US nuclear arsenal was planned in the early eighties) which, coupled with the much larger payloads of the MX and Trident II missiles, may account for the reduced (but still quite respectable) YTW ratios of these warheads.
Part of optimizing the YTW ratio is careful weight management. Very light weight primaries, the use of light weight weapon cases, and multiple radiation cases are innovations to minimize weight. Since the tamper is one of the heaviest parts of the weapon, squeezing as much energy out of this is very important too.
The end of surface testing of nuclear weapons after the atmospheric test ban treaty effectively removed "cleanliness" as a significant concern for designers. Complaints about fall-out vanished, and so did the ability of the international community to monitor weapon design through fall-out analysis. The cost-effectiveness of lighter weapons put great pressure on designers to extract weight saving however they could, and it is likely that the idea of using non-fissile tampers disappeared very quickly. There is scant evidence that so-called "clean" designs were ever deployed in any quantity.
The fission yield of the tamper can be increased even further by adding slow-neutron fissionable material to it. Basically this means using enriched uranium instead of natural or depleted uranium.
Highly enriched uranium is definitely known to be used in U.S. weapons. About half of the U.S. inventory of weapons-associated HEU is less than "weapons grade" (<93.4% that is). The probable use of most or all of this uranium (generally with an enrichment of 20-80%) was in thermonuclear weapon tampers.
The W-87 Peacekeeper warhead (to be redeployed on the Minuteman-III) has a current yield of 300 kt, that can be increased to 475 kt by adding a HEU sleeve or rings to the secondary. Whether this represents an actual addition to the existing secondary, or whether it replaces an existing unenriched sleeve is not known. The W-88 Trident warhead is a closely related design, and has a current yield of 475 kt indicating that it is already equipped with this addition. The 175 kt yield difference amounts to the complete fission of 10 kg of U-235.
Now, once one considers using substantial amounts of HEU in the secondary, the question of why the fusion fuel is needed at all arises. The answer: it probably is not essential. The idea of imploding fissile material is what set Stanislaw Ulam on the path to that led eventually to thermonuclear weapons. But with the availability of large amounts of HEU, and the trend toward smaller weapon yields (compared to the multimegaton behemoths of the fifties), the Ulam's idea of using radiation implosion to create a light weight high-efficiency pure fission weapon returns as a viable possibility. It is an interesting question whether all modern strategic nuclear weapons *are* in fact thermonuclear devices!
4.5.4 Minimum Residual Radiation (MRR or "Clean") Designs
It has been pointed out elsewhere in this FAQ that ordinary fission-fusion- fission bombs (nominally 50% fission yield) are so dirty that they merit consideration as radiological weapons. Simply using a non-fissile tamper to reduce the fission yield to 5% or so helps considerably, but certainly does not result in an especially clean weapon by itself. If minimization of fallout and other sources of residual radiation is desired then considerably more effort needs to be put into design.
Minimum residual radiation designs are especially important for "peaceful nuclear explosions" (PNEs). If a nuclear explosive is to be useful for any civilian purpose, all sources of residual radiation must be reduced to the absolute lowest levels technologically possible. This means elimination neutron activation of bomb components, of materials outside the bomb, and reducing the fissile content to the smallest possible level. It may also be desirable to minimize the use of relatively hazardous materials like plutonium.
The problems of minimizing fissile yield and eliminating neutron activation are the most important. Clearly any MRR, even a small one, must be primarily a fusion device. The "clean" devices tested in the fifties and early sixties were primarily high yield strategic three-stage systems. For most uses (even military ones) these weapons are not suitable. Developing smaller yields with a low fissile content requires considerable design sophistication - small light primaries so that the low yields still produce useful radiation fluxes and high-burnup secondary designs to give a good fusion output.
Minimizing neutron activation form the abundant fusion neutrons is a serious problem since many materials inside and outside the bomb can produce hazardous activation products. The best way of avoiding this is too prevent the neutrons from getting far from the secondary. This requires using an efficient clean neutron absorber, i.e. boron-10. Ideally this should be incorporated directly into the fuel or as a lining of the fuel capsule to prevent activation of the tamper. Boron shielding of the bomb case, and the primary may be useful also.
It may be feasible to eliminate the fissile spark plug of a MRR secondary by using a centrally located deuterium-tritium spark plug similar to the way ICF capsules are ignited. Fusion bombs unavoidably produce tritium as a by- product, which can be a nuisance in PNEs.
Despite efforts to minimize radiation releases, PNEs have largely been discredited as a cost-saving civilian technology. Generally speaking, MRR devices still produce excessive radiation levels by civilian standards making their use impractical.
MRRs may have military utility as a tactical weapon, since residual contamination is slight. Such weapons are more costly and have lower performance of course.
This leads to another reason why PNEs have lost their attractiveness - there is no way to make a PNE device unsuitable for weapons use. "Peaceful" use of nuclear explosives inherently provides opportunity to develop weapons technology. As the saying goes, "the only difference between a PNE and a bomb is the tail fins".
4.5.5 Radiological Weapon Designs This is the opposite extreme of an MRR. Earlier several tamper materials were described that could be used to tailor the radioactive contamination produced by a nuclear explosion - tantalum, cobalt, zinc, and gold. Uranium tampers produce contamination in abundance - but quite a lot of energy too. In some applications it may be desired that the ratio of contamination to explosive force be increased, or tailored to a narrower spectrum of decay times compared to fission by-products.
Practical radiological weapons must incorporate the precursor isotope directly into the secondary. This is because the high compression of the secondary allows the use of reasonable masses of precursor material. In an uncompressed state, the thickness of most materials required to capture a substantial percentage of neutrons is 10-20 cm, leading to a very massive bomb. A layer of 1 cm or less will do as well when compressed by radiation implosion.
Some radioisotopes that would be very attractive for certain applications are difficult to produce in a weapon. A case in point is sodium-24, an extremely prolific producer of energetic gammas with a half-life of 14.98 hours. This isotope produces a remarkable 5.515 MeV of decay energy, with two hard gammas per decay (2.754 MeV and 1.369 MeV) and might be desired for very short-lived radiation barriers. The most obvious precursor, natural Na- 23, has a minuscule capture cross section for neutrons in the KeV range (although it is a significant hazard from induced radioactivity in soil after low altitude nuclear detonations). The best for precursor candidate for Na-24 is probably magnesium-24 (78.70% of natural magnesium) through an n,p reaction.
4.6.1 Weapon Safety
Due to their enormous destructive power, it is extremely important to ensure that nuclear weapons cannot explode at either their full yield, or at reduced yield, unless stringent and carefully specified conditions are met.
Weapons must be resist:
To meet these requirements elaborate provisions for weapon safety are required. This issue has been of major concern since the first nuclear weapons, and many of the major advances in weapon design are related to weapon safety.
Weapons are invariably designed with a series of disabling mechanisms, all of which must be successfully overridden before an explosion can occur. These include locking mechanisms requiring special keys or codes, redundant safeties that must be removed to arm the weapon, environmental sensing switches (disabling mechanisms that are overridden only when the weapon has experienced environmental conditions and stresses expected during operational employment), and sophisticated fuzing systems to detonate the device at the proper place and time. Often these multiple safety systems require cooperation by more than one person to complete weapon arming.


{% trans "HTML5 Rocks Terms of Service" %}
{% blocktrans %} The HTML5ROCKS website (the "Website") is hosted by Google. By using and/or visiting the Website, you consent to be bound by these terms of service as well as Google's general Terms of Service and Google's general Privacy Policy. {% endblocktrans %}


Working with relations: Creating a music anthology
A distinction should be made between anthologies regarded as
one work and anthologies regarded as a collection of individual works.
For instance, a song cycle may be regarded as one work or not,
depending on the circumstances, the project's aim etc. The decision
implies different workflows.
Anthologies regarded as one work are simply works with a number of constituent components, and they are treated just like any other work with a number of movements. The components are defined at the Music tab:
- Near the bottom of the page, create the desired number of components using the add buttons.
- Save your work and start editing the components one at a time by clicking the component's edit button.
- Enter the details about the component, such as the title and the text author.
- Click the "save and close" button to save your work and return to the Music tab.
Anthologies of individual works are a little more complicated. They can be created as separate works (files), linked together by work-to-work relations:
- First, create and save the individual works. However, sources representing the entire anthology should not be defined at this stage.
- Then, create another work to represent the anthology. At the Work tab, start defining relations to the contained works by clicking the "Add relation" button.
- Select the "has part:" relation ("part" in this case is not
to be understood musically).
- Open the works browser by clicking the "Select file..."
button. In the works browser, locate and click the desired work.
It may be convenient to narrow the search to a specific file collection or enter search terms such as the title.
Please note that the file browser may need some time to load and to update.
(If you know the work's file name, you may also enter it as the target attribute using the attribute editor). - Repeat this with each of the contained works and save your
work. You should end up with something like this:
- Add any other desired information about the anthology, such as title, source descriptions etc.
Remember that relations are bidirectional. In order to create links both ways (from the anthology to the individual works and back), edit each of the contained works to add a relation back to the anthology. You have easy access to the contained works (and back) clicking the "Go to linked resource" icon .
In the HTML preview, the result could look something like the following:


Whiley
PLAY
Sign Up
% if ERROR is True:
${ERRORMSG}
% endif
Username
Email
Password
Confirm Password
Given Name:
Surname:
Enrolled in an institution
Sign Up
Cancel


Suspect charged in connection with 39 deaths in U.K. shipping container
by The Associated Press, StaffLONDON -- British prosecutors have charged a 23-year-old man from Northern Ireland in the deaths of 39 people from Vietnam whose bodies were found in a refrigerated container truck last month.
Essex Police said Sunday that Christopher Kennedy was charged with conspiracy to arrange people trafficking and conspiracy to break UK immigration law.
He is scheduled to appear in court Monday.
The bodies were found Oct. 23 in the English town of Grays.
British police have already charged 25-year-old Maurice Robinson, a truck driver also from Northern Ireland, with 39 counts of manslaughter and conspiracy to traffic people. They say he drove the cab of the truck to Purfleet, England, where it picked up the container, which had arrived by ferry from Zeebrugge in Belgium.
Another suspect is being held in Ireland.