|
cds
1.2.0
|
Array of ready for destroying pointers. More...
#include <cds/gc/hrc/details/hrc_retired.h>
Public Types | |
| typedef vector_type::iterator | iterator |
| Iterator over retired pointer vector. | |
| typedef vector_type::const_iterator | const_iterator |
| Const iterator type. |
Public Member Functions | |
| retired_vector (const GarbageCollector &mgr) | |
| Cror. | |
| size_t | capacity () const |
| Capacity (max available size) of array. | |
| size_t | retiredNodeCount () const |
| Returns count of retired node in array. This function is intended for debug purposes only. | |
| void | push (ContainerNode *p, free_retired_ptr_func pFunc) |
| Push new item to the array. | |
| void | pop (size_t n) |
Pop item n from array. | |
| bool | isFull () const |
| Check if array is full. | |
| retired_node & | operator[] (size_t i) |
Get item by index i . It is not error if i >= capacity() | |
| iterator | begin () |
| Returns a random-access iterator to the first element in the retired pointer vector. | |
| const_iterator | begin () const |
| Const version of begin() | |
| iterator | end () |
| A random-access iterator to the end of the vector object. | |
| const_iterator | end () const |
| Const version of end() |
Private Types | |
|
typedef cds::details::bounded_array < retired_node > | vector_type |
| type of vector of retired pointer (implicit CDS_DEFAULT_ALLOCATOR dependency) |
Private Attributes | |
| size_t | m_nFreeList |
| Index of first free item in m_arr. | |
| vector_type | m_arr |
| Array of retired pointers (implicit CDS_DEFAULT_ALLOCATOR dependence) |
Array of ready for destroying pointers.
The array object is belonged to one thread: only owner thread may write to this array, any other thread can read one.
|
inline |
|
inline |


ONE of the largest indigenous groups of Sabah, the Murut people is made up of 29 sub-ethnic groups, including the Tagol, Timugon, Paluan, Nabaai, Kolor, Serudong, Bokan and Tangala.
The name “Murut” means “hill people”.
A large percentage of the Murut communities reside in the southwest interior of Sabah, in the districts of Keningau, Tenom, Nabawan, and Pensiangan, along the Sapulut and Padas rivers.
The last indigenous group of Sabah to renounce headhunting, the Murut were known as the silent headhunters and called “pengait”, or the hook.
Up until the 1960s, they beheaded their foes and collected the heads as trophies. – November 16, 2019.


This final story explores the concept of "mestizaje" through the Mexican food experiences passed down to me through my Irish mother, who had been taught how to cook by my Mexican grandmother.
As a child, I was always looking for a reason to go into the kitchen when my mom was cooking. Every legitimate excuse I could conjure up to be in there, the better sense I could gain of how long we had left to wait before eating. Our kitchen was small, so in retrospect, it must have been disruptive to have unnecessary bodies in the way. Regardless, whenever my mom was cooking, me and my siblings could be found consistently walking into the kitchen to “get a glass of water,” to “throw something away,” or just to “pass through” to the basement.
That was many years ago, but the scene is still so clear to me. My mother moving frantically back and forth between the stove, the counter, and the sink. Beads of sweat glistening on top of the white skin on her forehead and upper lip. I remember noticing that she used the same pan to make French toast as she did for mole. It had never occurred to me to think about how my mother—who is of Western European descent—learned to cook Mexican dishes like chicken mole and carne asada.
Long before I was born, my Mexican grandmother, Tina, began teaching her how to cook. My grandparents would host Sunday dinners, and my mom would go over early to help. At first Tina was guarded about passing on these recipes—partially because she worried that other people wouldn’t make them correctly. Eventually, my mom was equipped to make a handful of Mexican dishes on her own. This is what I grew up eating, and these dishes were one of the largest connections I felt to Mexican culture. I tell this story because I think it highlights the non-biological aspect of cultural continuance. That is, this story shows how, despite the fact that she is not Mexican herself, my mom was able to pass on Mexican traditions to me—not only by feeding me, but also by eventually teaching me how to cook.
Despite any positive usages that Xicanos or other people can garner from mestizaje, it cannot be minimized the extent to which mestizaje has been used violently against the Indigenous peoples of Turtle Island—the Americas. In Mexico Profundo: Reclaiming a Civilization, Guillermo Bonfil Batalla puts forth the argument that Mexico is not a mestizo nation, as is often claimed, but an Indigenous nation. From this perspective, Mesoamerican culture has remained central to Mexicans into the present moment, having been absorbed into the national identity of Mexico once it claimed “independence” from Spain. I agree with Batalla’s analysis that these Indigenous cultural practices persist into the present, that mestizaje has been used as a way to strip Mexicans of our Indigenous identities, and that mestizaje is an inappropriate way of understanding the mixing of cultural practices under colonial conditions: "...the mestizos are a contingent of "de-Indianized" Indians. 'De-Indianization' is a different process from the biological one of racial mixture. To use the term mestizaje in different sorts of situations...carries the risk of introducing an incorrect view. It is an inappropriate way of understanding non-biological processes, such as those that occur in the cultures of different groups in contact, within the context of colonial domination" (17). For Batalla, mestizaje runs the risk of introducing racial mixture as primarily a biological process, and has been systematically deployed through out Latin America specifically to De-Indianize Indians. While his book was published more than 20 years ago and focuses on Mexicans in Mexico, I would argue that this same dynamic also rings true today for many Xicanos in the United State as well.
Some Mesoamerican practices persist in a similar way to how Batalla describes them among rural Mexicans, yet the shifting context in the United States adds another layer of colonialism in between Chicanxs and Indigenous identity. In terms of food practice, the more important question might have to do with decolonizing our food ways. Enrique Salmón (Ratamuri) explain that “whenever I partake in Eloisa’s tamale recipe or my mother’s way of preparing salsa, I am eating the memories and knowledge associated with those foods…[i]t becomes a form of mimetic regeneration to eat one’s family’s recipes” (8). But while this form of knowledge is extremely important, he also emphasizes the importance of understanding the politics of food—how food production impacts the environment, how science disrupts the genetics of food and thereby our bodies, etc.
This is an extremely important point to make both within the contexts of cultural regeneration and social justice activism. For often times cultural initiatives are void of the radical political analysis necessary to confront the modern systems of power that colonize both our food and our identities. Conversely, social justice spaces are often void of the radical nature of cultural survivance and the need for many people to approach social justice organizing from specific cultural perspectives. Xicanos are in a unique position to bride the gap between culture and politics, because we have been re-made by a movement (El Movmiento) that was in many ways based on this very premise.
Works Cited
Salmón, E. (2012). Eating the Landscape: American Indian Stories of Food, Identity, and Resilience (2 edition). Tucson: University of Arizona Press.
Batalla, G. B. (1996). Mexico Profundo: Reclaiming a Civilization. Austin: University of Texas Press.


The LeanKit Integration Service connects a LeanKit account to a Target System, and synchronizes LeanKit cards between a LeanKit board and the Target System. Network access to both systems and valid login credentials are required.
Enter or update your LeanKit account settings to continue:


Duty Class
Class for the Duty of the ODRL Core Model
Constructor
Duty
()
Item Index
Methods
Methods
addAsset
(
-
uid
-
relation
Method for adding an asset to the Duty
Parameters:
-
uid
StringThe unique identifier of the asset
-
relation
StringThe relation of the asset to the Duty.
addConstraint
(
-
name
-
operator
-
rightOperand
-
dataType
-
unit
-
status
Method for adding a constraint to the Duty
Parameters:
-
name
StringThe identifing name of the Constraint
-
operator
StringThe identifyer of the operator
-
rightOperand
StringThe identifyer of the right operand
-
dataType
StringThe identifyer of the data type of the right operand
-
unit
StringThe identifyer of the unit of the right operand
-
status
StringThe identifyer of the status
addParty
(
-
uid
-
pfunction
-
scope
Method for adding a party to the Duty
Parameters:
-
uid
StringThe Unique Identifier of the Party
-
pfunction
StringThe identifier of the functional role this party takes
-
scope
StringThe scope of the party
setAction
(
-
actionname
Method for setting the action of the Duty
Parameters:
-
actionname
StringThe identifier of the action
setUid
(
-
uid
Method for setting the unique identifier of the Duty
Parameters:
-
uid
StringThe unique identifier of the Duty


Practical Scalaz: Make async operations with scalaz.Either and Futures
Many of us know about such library as scalaz. For those who don’t know it is a library for functional programming in scala. You can find it here. Then I was trying to learn and understand this lib it was quite difficult to realize how exactly it can be used in a real code in a real system. I looked thought lots of articles about it, but there were only abstract examples. So I`ve decided to write a little example in order to show how scalaz can be used in a real system.
Intro
Idea: Future and scalaz.Either can be used as a result of an asynchronous operation.
Reason: We must compose futures and eithers in order to deal with possible errors which may occur during execution of async operations.
For example we have to gather information from several different DBs and an external service like Twitter. We also don`t want to use exceptions as notifications about errors. Why? Because it sucks ^_^ It will be better if exceptions are used for something really exceptional. One more thing which we should implement is fail-fast error handling because it will be wasteful to continue program execution if it already contains some errors.
Simple example
You can find sources for this article here As a result of an operation we use scalaz.Either. Let`t redefine either classes for better readability like that:
type ActionResult[T] = String \/ T
val ActionSuccess = \/-
val ActionFailure = -\/
ServiceResult[T]
is a generic type for passing an operation result
We use String
as error object for passing information about error, -\/
indicates an error and \/-
indicates success.
Define one more type to make possible async actions:
type FutureActionResult[T] = Future[ActionResult[T]]
and one more as the outcome
case class Outcome(value: String)
Then define async methods:
def doSuccessAction1(): FutureActionResult[Outcome] = {
Future {
Thread.sleep(5000)
println("success-action#1 is completed")
ActionSuccess(Outcome("success#first"))
}
}
def doSuccessAction2(): FutureActionResult[Outcome] = { /*...*/ }
def doSuccessAction3(): FutureActionResult[Outcome] = { /*...*/ }
Now we have almost all what we need. Right now we have to write something like that to compose results of our methods:
def doUglyComplexAction(): FutureActionResult[String] = {
//start execution in parallel
val futureResult1 = doSuccessAction1()
val futureResult2 = doSuccessAction2()
val futureResult3 = doSuccessAction3()
for{
eitherResult1 <- futureResult1
eitherResult2 <- futureResult2
eitherResult3 <- futureResult3
} yield {
for {
result1 <- eitherResult1
result2 <- eitherResult2
result3 <- eitherResult3
} yield {
// if all operations complete successfully we will concatenate string
result1.value + " " + result2.value + " " + result3.value
}
}
}
There are several problems in the code above.
The first one is that the second for-comprehension
block will execute only after all of the futures will have finished. And the second problem is that code is quite a big bunch of text and we can write it in shorter way. But for this we need some additional scalaz magic: Monad[Future] and monad transformer.
Lets define
Monad[Future]`:
//define Monad[Future] for work with future`s monad transformer
implicit val FutureMonad = new Monad[Future] {
def point[A](a: => A): Future[A] = Future(a)
def bind[A, B](fa: Future[A])(f: (A) => Future[B]): Future[B] = fa flatMap f
}
And now we can replace two blocks of for-comprehension
by one nice block:
val result = for {
result1 <- eitherT(futureResult1)
result2 <- eitherT(futureResult2)
result3 <- eitherT(futureResult3)
} yield {
// if all operations complete successfully we will concatenate string
result1.value + " " + result2.value + " " + result3.value
}
//return final result
result.run
If we run it like this:
//print result of calculation
val futResult = doSuccessfulComplexAction().map{
case ActionSuccess(value) => println("success value: " + value)
case ActionFailure(error) => println("err value: " + error)
}
//Wait 20 seconds for result
Await.result(futResult, 20.seconds)
We will see that in console:
success-action#1 is completed
success-action#2 is completed
success-action#3 is completed
success value: success#first success#second success#third
Error handling
Let’s add a failed action in order to show how the code above behaves itself in case of return of ActionFailure
:
def doShortFailedAction(): FutureActionResult[Outcome] = {
Future {
println("short failed action is completed")
ActionFailure("failed#short")
}
}
Add a call of doShortFailedAction()
in for-comprehension
:
//...
val failedAction = doShortFailedAction()
//...
val result = for {
result1 <- eitherT(futureResult1)
failed <- eitherT(failedAction) //<-- this is fail
result3 <- eitherT(futureResult3)
} yield {
// if all operations complete successfully we will concatenate string
result1.value + " " + failed.value + " " + result3.value
}
If we execute this code we will see this in console:
short failed action is completed
success-action#1 is completed
err value: failed#short
As you can see this code doesn’t wait until all of futureResult-s will be available because in any case there will be ActionFailure
.
But there is still a problem. If we swap lines like that:
val result = for {
result1 <- eitherT(futureResult1)
result3 <- eitherT(futureResult3)
failed <- eitherT(failedAction)
} yield {
//...
}
We will see that we have to wait completion of all the futures despite failedAction
always finishes in first. In general there is no way to do using common scala. But after some magic tricks it will be possible ^_^ This kind of scala magic will be discussed in the next chapter.
Links
- EitherFutureSimpleExample.scala - an example app for this article
- coffius/koffio-examples - Repository with all the examples
- scalaz/scalaz - sources of scalaz. You can also find here simple examples how to use different parts of scalaz
- Learning scalaz - a really big source of information about most of parts of the library with shotr examples
UPD
- (14/08/2015) Get rid of
Function[Future]
in the article and in the code example because it’s unnecessary


Nepeta
mirror of original Nepeta repo and updates for future iOS versions
Mirrored from Chr0nicT's mirror
Contact the maintainer of this repo on Twitter: @digic3ll Reddit: /u/digic3ll email: digic3ll (at) gmail.com
Beware of fake nepeta accounts on Twitter. The only real one is @nepetadev any other similar account is fake.


@* * Copyright 2023 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @()(implicit request: Request[_], messages: Messages)
@Messages("modular.basicRecordKeeping.must_record")
@Messages("modular.basicRecordKeeping.keep_records")
@Messages("modular.basicRecordKeeping.software_suppliers")
@Messages("modular.basicRecordKeeping.organise_income")
@Messages("modular.basicRecordKeeping.must_keep")
@Messages("modular.basicRecordKeeping.vat_registered")
@Messages("modular.basicRecordKeeping.vat_threshold")
@Messages("modular.basicRecordKeeping.years_after")
@Messages("modular.basicRecordKeeping.example")
@Messages("modular.basicRecordKeeping.record_keeping_video")
@Messages("modular.basicRecordKeeping.record_keeping_transcript")


If you have noticed in an arcade, games automatically playing. This howto will show how it could be done.
Use this code to record input events and save to files.
In main.c
Find:
// executes only just after startup
void afterStartup()
{
}
And replace with:
#define REC 1
#define PLAY 2
int recOrPlay = REC;
char *readWriteAccess;
FILE *keyDownFilePtr;
FILE *keyUpFilePtr;
FILE *keyPressFilePtr;
// executes only just after startup
void afterStartup()
{
if (recOrPlay == REC)
readWriteAccess = "w+b";
if (recOrPlay == PLAY)
readWriteAccess = "r+b";
if (recOrPlay)
{
keyDownFilePtr = fopen("keyDown.dat", readWriteAccess);
keyUpFilePtr = fopen("keyUp.dat", readWriteAccess);
keyPressFilePtr = fopen("keyPress.dat", readWriteAccess);
}
}
Find:
// executes just before shutdown
void beforeShutdown()
{
}
And replace with:
// executes just before shutdown
void beforeShutdown()
{
if (recOrPlay)
{
fclose(keyPressFilePtr);
fclose(keyUpFilePtr);
fclose(keyDownFilePtr);
}
}
Find:
#include "initialize.c"
And replace with:
#include "initialize.c"
if (recOrPlay == REC)
{
eventRecToFile((void **)keyDown, 256, keyDownFilePtr);
eventRecToFile((void **)keyUp, 256, keyUpFilePtr);
eventRecToFile((void **)keyPress, 256, keyPressFilePtr);
}
if (recOrPlay == PLAY)
{
eventPlayFromFile((void **)keyDown, 256, keyDownFilePtr);
eventPlayFromFile((void **)keyUp, 256, keyUpFilePtr);
eventPlayFromFile((void **)keyPress, 256, keyPressFilePtr);
}
Compile and run.
Use this code to play input events that were saved to files.
Find:
int recOrPlay = REC;
And replace with:
int recOrPlay = PLAY;
Compile and run.
This can be setup to replay exactly the same over and over which makes it useful for debugging.


@Target(value=TYPE)
@Retention(value=RUNTIME)
@Documented
public @interface Consumer
Consumer of the producer annotated with @send(topic) of the method;
* Topic/queue(1:N or 1:1):
if event class annotated with @Consumer(XX); it must implements
com.jdon.domain.message.DomainEventHandler
the @Send(topicName) ==> @Consumer(topicName);
if there are many consumers, execution order will be
alphabetical list by Name of @Consumer class.
Domain Model producer /Consumer:
1. annotate the producer class with @Model and @Introduce("message")
the @Model
the @Introduce("message")
public class DomainEvent {}
2. annotate the method with @Send("mytopic") of the producer class;
the @Send("mytopic")
public DomainMessage myMethod() {
DomainMessage em = new DomainMessage(this.name);
return em;
}
3. the "mytopic" value in @Send("mytopic") is equals to the "mytopic" value
in @Consumer("mytopic");
4. annotate the consumer class with @Consumer("mytopic");
5. the consumer class must implements
com.jdon.domain.message.DomainEventHandler
'@Consumer("mychannel")'
public class MyDomainEventHandler implements DomainEventHandler {}
- 作者:
- banq
- 另请参阅:
@Send


{% extends "base_generic.html" %} {% block title %}delete image {% endblock %} {% block content %}
Are you sure you want to delete?


@import uk.gov.hmrc.hmrcfrontend.views.html.components._ @this(hmrcPageHeading : HmrcPageHeading) @() @hmrcPageHeading(PageHeading( text = "We could not confirm your identity" ))
You have entered information that does not match our records too many times. For security reasons, you must wait 24 hours and then sign in to try again.
You can change other VAT details without confirming your identity


ftp Library Package 2.1 for Tcl/Tk Manual Pages
The command returns 1 if the specified file can be successfully renamed or 0 if it fails.
# rename file ftp::Rename $conn index.htm index.htm.org # with fully qualified path name ftp::Rename $conn /usr/htdocs/index.htm /usr/htdocs/index.htm.org
[Contents] [Previous: ftp::Delete] [Next: ftp::Put]


treated amino CsaG, plants genes gelatin acid gene plant leaf expression Table module expressed growth Plant control using nitrogen NAC Figure acids {border-style increase px;} transport #ffffff;} Arabidopsis protein stress AAP high DEGs analysis total treatment used blue increased network significant transcription transporter abiotic capsule capsules membrane < (Supplementary ammonium biostimulant cDNA second time (CsaG), Seed Supplementary compared correlation effect emergence involved nitrate seed weight xylem (L) RNA RNA-seq Science T-L, area hydrolysate metabolism plasma samples week Molecular highly proteins seeds tissue transporters upregulated (CsaG, Biological CsaG; activity affinity associated cucumber differentially hub phase px; {font-family CsaG Horticulturae NEBNext article content data demonstrated eigengenes font-size function genes, identified library mRNA maize million roots study tolerance yellow yield (T) AAP, AMT Analysis CsaG) Ertani Expression However, T-L biostimulants coexpression crop differences double; enhanced family fresh frozen genome measured module, number phloem plants. qRT-PCR reference related root sequencing Acta Agriculture Amino Biostimulants Chemistry CsaG), Gelatin Genes Physiology RPKM Research Soil WGCNA Wang application assimilation biological border-color border-width cell different factor, following including isolated leaves levels mapped modules molecular placed plants, proton reads reported results revealed seedlings size solid; stimulate tomato treatments xenobiotic {font-style {font-weight (CsaG) ./s-()- ABC Bioinformatics Botany Experimental FDR Growth Illumina Kit Network Nitrogen S-transferase Total Using accumulation animal based biotic bold brown chemicals concentration courier; downregulated em; encapsulation enhance enzyme form genes. glutathione greenhouse grown however, hydrolysis intrinsic level million) organic parenchyma performed plant-derived positive possible provided pt;} relative salt selected showed suggests test thaliana transporter, treatment, turquoise version versus weeks weighted −.;


Boosting Black Box Variational Inference¶
Introduction¶
This tutorial demonstrates how to implement boosting black box Variational Inference [1] in Pyro. In boosting Variational Inference [2], we approximate a target distribution with an iteratively selected mixture of densities. In cases where a single denisity provided by regular Variational Inference doesn’t adequately approximate a target density, boosting VI thus offers a simple way of getting more complex approximations. We show how this can be implemented as a relatively straightforward extension of Pyro’s SVI.
Contents¶
Theoretical Background¶
Variational Inference¶
For an introduction to regular Variational Inference, we recommend having a look at the tutorial on SVI in Pyro and this excellent review [3].
Briefly, Variational Inference allows us to find approximations of probability densities which are intractable to compute analytically. For instance, one might have observed variables \(\textbf{x}\), latent variables \(\textbf{z}\) and a joint distribution \(p(\textbf{x}, \textbf{z})\). One can then use Variational Inference to approximate \(p(\textbf{z}|\textbf{x})\). To do so, one first chooses a set of tractable densities, a variational family, and then tries to find the element of this set which most closely approximates the target distribution \(p(\textbf{z}|\textbf{x})\). This approximating density is found by maximizing the Evidence Lower BOund (ELBO):
where \(q(\mathbf{z})\) is the approximating density.
Boosting Black Box Variational Inference¶
In boosting black box Variational inference (BBBVI), we approximate the target density with a mixture of densities from the variational family:
and \(s_t(\mathbf{z})\) are elements of the variational family.
The components of the approximation are selected greedily by maximising the so-called Residual ELBO (RELBO) with respect to the next component \(s_{t+1}(\mathbf{z})\):
Where the first two terms are the same as in the ELBO and the last term is the cross entropy between the next component \(s_{t+1}(\mathbf{z})\) and the current approximation \(q^t(\mathbf{z})\).
It’s called black box Variational Inference because this optimization does not have to be tailored to the variational family which is being used. By setting \(\lambda\) (the regularization factor of the entropy term) to 1, standard SVI methods can be used to compute \(\mathbb{E}_s[\log p(\mathbf{x}, \mathbf{z})] - \lambda \mathbb{E}_s[\log s(\mathbf{z})]\). See the explanation of the section on the implementation of the RELBO below for an explanation of how we compute the term \(- \mathbb{E}_s[\log q^t(\mathbf{z})]\). Imporantly, we do not need to make any additional assumptions about the variational family that’s being used to ensure that this algorithm converges.
In [1], a number of different ways of finding the mixture weights \(\gamma_t\) are suggested, ranging from fixed step sizes based on the iteration to solving the optimisation problem of finding \(\gamma_t\) that will minimise the RELBO. Here, we used the fixed step size method. For more details on the theory behind boosting black box variational inference, please refer to [1].
BBBVI in Pyro¶
To implement boosting black box variational inference in Pyro, we need to consider the following points: 1. The approximation components \(s_{t}(\mathbf{z})\) (guides). 2. The RELBO. 3. The approximation itself \(q^t(\mathbf{z})\). 4. Using Pyro’s SVI to find new components of the approximation.
We will illustrate these points by looking at simple example: approximating a bimodal posterior.
[11]:
import os
from collections import defaultdict
from functools import partial
import numpy as np
import pyro
import pyro.distributions as dist
import scipy.stats
import torch
import torch.distributions.constraints as constraints
from matplotlib import pyplot
from pyro.infer import SVI, Trace_ELBO
from pyro.optim import Adam
from pyro.poutine import block, replay, trace
The Model¶
Boosting BBVI is particularly useful when we want to approximate multimodal distributions. In this tutorial, we’ll thus consider the following model:
Given the set of iid. observations \(\text{data} ~ \mathcal{N}(4, 0.1)\), we thus expect \(p(\mathbf{z}|\mathbf{x})\) to be a bimodal distributions with modes around \(-2\) and \(2\).
In Pyro, this model takes the following shape:
[12]:
def model(data):
prior_loc = torch.tensor([0.])
prior_scale = torch.tensor([5.])
z = pyro.sample('z', dist.Normal(prior_loc, prior_scale))
scale = torch.tensor([0.1])
with pyro.plate('data', len(data)):
pyro.sample('x', dist.Normal(z*z, scale), obs=data)
The Guide¶
Next, we specify the guide which in our case will make up the components of our mixture. Recall that in Pyro the guide needs to take the same arguments as the model which is why our guide function also takes the data as an input.
We also need to make sure that every pyro.sample()
statement from the model has a matching pyro.sample()
statement in the guide. In our case, we include z
in both the model and the guide.
In contrast to regular SVI, our guide takes an additional argument: index
. Having this argument allows us to easily create new guides in each iteration of the greedy algorithm. Specifically, we make use of partial()
from the functools library to create guides which only take data
as an argument. The statement partial(guide, index=t)
creates a guide that will take only data
as an input and which has trainable parameters
scale_t
and loc_t
.
Choosing our variational distribution to be a Normal distribution parameterized by \(loc_t\) and \(scale_t\) we get the following guide:
[13]:
def guide(data, index):
scale_q = pyro.param('scale_{}'.format(index), torch.tensor([1.0]), constraints.positive)
loc_q = pyro.param('loc_{}'.format(index), torch.tensor([0.0]))
pyro.sample("z", dist.Normal(loc_q, scale_q))
The RELBO¶
We implement the RELBO as a function which can be passed to Pyro’s SVI class in place of ELBO to find the approximation components \(s_t(z)\). Recall that the RELBO has the following form:
Conveniently, this is very similar to the regular ELBO which allows us to reuse Pyro’s existing ELBO. Specifically, we compute
using Pyro’s Trace_ELBO
and then compute
using Poutine. For more information on how this works, we recommend going through the Pyro tutorials on Poutine and custom SVI objectives.
[14]:
def relbo(model, guide, *args, **kwargs):
approximation = kwargs.pop('approximation')
# We first compute the elbo, but record a guide trace for use below.
traced_guide = trace(guide)
elbo = pyro.infer.Trace_ELBO(max_plate_nesting=1)
loss_fn = elbo.differentiable_loss(model, traced_guide, *args, **kwargs)
# We do not want to update parameters of previously fitted components
# and thus block all parameters in the approximation apart from z.
guide_trace = traced_guide.trace
replayed_approximation = trace(replay(block(approximation, expose=['z']), guide_trace))
approximation_trace = replayed_approximation.get_trace(*args, **kwargs)
relbo = -loss_fn - approximation_trace.log_prob_sum()
# By convention, the negative (R)ELBO is returned.
return -relbo
The Approximation¶
Our implementation of the approximation \(q^t(z) = \sum_{i=1}^t \gamma_i s_i(z)\) consists of a list of components, i.e. the guides from the greedy selection steps, and a list containing the mixture weights of the components. To sample from the approximation, we thus first sample a component according to the mixture weights. In a second step, we draw a sample from the corresponding component.
Similarly as with the guide, we use partial(approximation, components=components, weights=weights)
to get an approximation function which has the same signature as the model.
[15]:
def approximation(data, components, weights):
assignment = pyro.sample('assignment', dist.Categorical(weights))
result = components[assignment](data)
return result
The Greedy Algorithm¶
We now have all the necessary parts to implement the greedy algorithm.   Parameters of component 2:
loc = 2.0046799182891846
scale = 0.06008879840373993
[18]:
# Plot the resulting approximation
X = np.arange(-10, 10, 0.1)
pyplot.figure(figsize=(10, 4), dpi=100).set_facecolor('white')
total_approximation = np.zeros(X.shape)
for i in range(1, n_iterations + 1):
Y = weights[i].item() * scipy.stats.norm.pdf((X - locs[i]) / scales[i])
pyplot.plot(X, Y)
total_approximation += Y
pyplot.plot(X, total_approximation)
pyplot.plot(data.data.numpy(), np.zeros(len(data)), 'k*')
pyplot.title('Approximation of posterior over z')
pyplot.ylabel('probability density')
pyplot.show()
We see that boosting BBVI successfully approximates the bimodal posterior distributions with modes around -2 and +2.
  Parameters of component 2:
loc = 1.998241901397705
scale = 0.01308442372828722
References¶
[1] Locatello, Francesco, et al. “Boosting black box variational inference.” Advances in Neural Information Processing Systems. 2018.
[2] Ranganath, Rajesh, Sean Gerrish, and David Blei. “Black box variational inference.” Artificial Intelligence and Statistics. 2014.
[3] Blei, David M., Alp Kucukelbir, and Jon D. McAuliffe. “Variational inference: A review for statisticians.” Journal of the American statistical Association 112.518 (2017): 859-877.


Rock Paper Scissors Lizard Spock
The Fan Art Game!
user
comp
0
:
0
Press play to start
Play
Instructions
Reset
Make your choice


JavaScript is a cross-platform, object-oriented scripting language. It is a small and lightweight language. Inside a host environment (for example, a web browser), JavaScript can be connected to the objects of its environment to provide programmatic control over them.
JavaScript contains a standard library of objects, such as Array, Date, and Math, and a core set of language elements such as operators, control structures, and statements. Core JavaScript can be extended for a variety of purposes by supplementing it with additional objects; for example:
This guide assumes you have the following basic background:
- Element 1
- Element 2
- Element 3
- Element 4
- Element 5
JavaScript and Java are similar in some ways but fundamentally different in some others. The JavaScript language resembles Java but does not have Java's static typing and strong type checking. JavaScript follows most Java expression syntax, naming conventions and basic control-flow constructs which was the reason why it was renamed from LiveScript to JavaScript.
In contrast to Java's compile-time system of classes built by declarations, JavaScript supports a runtime system based on a small number of data types representing numeric, Boolean, and string values. JavaScript has a prototype-based object model instead of the more common class-based object model. The prototype-based model provides dynamic inheritance; that is, what is inherited can vary for individual objects. JavaScript also supports functions without any special declarative requirements. Functions can be properties of objects, executing as loosely typed methods.
JavaScript is a very free-form language compared to Java. You do not have to declare all variables, classes, and methods. You do not have to be concerned with whether methods are public, private, or protected, and you do not have to implement interfaces. Variables, parameters, and function return types are not explicitly typed.
- Element 1
- Element 2
- Element 3
- Element 4
- Element 5
To get started with writing JavaScript, open the Scratchpad and write your first "Hello world" JavaScript code:
function greetMe(yourName) { alert("Hello " + yourName); }
greetMe("World");
Select the code in the pad and hit Ctrl+R to watch it unfold in your browser!
You use variables as symbolic names for values in your application. The names of variables, called identifiers, conform to certain rules.
A JavaScript identifier must start with a letter, underscore (_), or dollar sign ($); subsequent characters can also be digits (0-9). Because JavaScript is case sensitive, letters include the characters "A" through "Z" (uppercase) and the characters "a" through "z" (lowercase).
You can use ISO 8859-1 or Unicode letters such as å and ü in identifiers. You can also use the Unicode escape sequences as characters in identifiers. Some examples of legal names are Number_hits, temp99, and _name.
You can declare a variable in three ways:
With the keyword var. For example,
var x = 42.
This syntax can be used to declare both local and global variables.
By simply assigning it a value. For example,
x = 42.
This always declares a global variable. It generates a strict JavaScript warning. You shouldn't use this variant. With the keyword let. For example,
let y = 13.
This syntax can be used to declare a block scope local variable. See Variable scope below.
When you declare a variable outside of any function, it is called a global variable, because it is available to any other code in the current document. When you declare a variable within a function, it is called a local variable, because it is available only within that function.
JavaScript before ECMAScript 2015 does not have block statement scope; rather, a variable declared within a block is local to the function (or global scope) that the block resides within. For example the following code will log 5, because the scope of x is the function (or global context) within which x is declared, not the block, which in this case is an if statement.
if (true) { var x = 5; } console.log(x); // 5


RT @ManningBooks: Deal of the Day, Feb 8, TDD for a Shopping Web Site and select titles are on sale. Check them out: https://t.co/DcpsoLASz…
2/8/2022, 11:29:14 AM
Favs: 0
Retweets: 0
link--- layout: tweet ---
RT @ManningBooks: Deal of the Day, Feb 8, TDD for a Shopping Web Site and select titles are on sale. Check them out: https://t.co/DcpsoLASz…
2/8/2022, 11:29:14 AM
Favs: 0
Retweets: 0
link


This is some text I might include in h2 format
A Club Tournament
Ralph Ecton Triples
- Sunday August 10th @ Oxnard


Malta government rejects immunity bid by businessman in journalist murder
by Temisan AmoyeThe Malta government turned down a request from one of the island’s richest men on Friday for a pardon in return for his cooperation in the investigation into a journalist’s murder, after freeing a top official he was said to implicate.
After two years of stalled investigations, the authorities have moved rapidly in recent days in the case of journalist Daphne Caruana Galizia, who was blown up with a car bomb in 2017 while working on reports about official corruption.
ALSO READ: Trump makes surprise visit to Afghanistan, meets Afghan president
Her family responded with fury to the decision overnight to set free Keith Schembri, who quit this week as chief of staff to prime minister Joseph Muscat after being arrested in the case.
After a cabinet meeting that ended shortly before 3:00 a.m., Muscat’s government decided to reject a request for immunity by Yorgen Fenech, a businessman who was arrested last week while trying to leave Malta on his yacht.
In a separate case showing how corruption allegations have closed in on the government, a court-ordered three cabinet ministers on Friday to face a criminal probe over a hospital contract. Two of the ministers had already left the cabinet this week over links to Fenech as the murder case unfolded.
ALSO READ: Australian court hands out heavy sentences for Melbourne Christmas terror plotters
Three men have been awaiting trial for setting the bomb that killed Caruana Galizia, but so far the authorities have failed to track down the person who hired them.
The arrest this week of Schembri, the prime minister’s right-hand man, has entangled top officials in the case, and Caruana Galizia’s family accuses the government of a cover-up.
Angry supporters of the family gathered outside the cabinet meeting in the early hours of the morning. As one minister was driven away, one of Caruana Galizia’s sons hurled fruit at his car and shouted obscenities.
Source: Reuters


[321] Few events are as spectacular as that of a Saturn V at liftoff en route to the moon. In fact, the commanding role of the mammoth vehicle has tended to obscure its supporting players, the Saturn I and Saturn IB boosters. Chapter 11 recapitulates some of the milestones of these earlier rockets and describes some of the payloads and visual instrumentation used in early launches to acquire crucial information about the near-Earth environment and the behavior of exotic propellants in the weightlessness of space.
Perhaps the biggest gamble of the Apollo-Saturn program rode on the launch of AS-501, the first Saturn V to lift off from Cape Kennedy. The decision to go "all up" on this launch circumvented the costly and time-consuming process of incremental flight testing of each stage prior to launching a complete vehicle. This mission, followed by troubleshooting the problems of AS-502, the first manned Saturn V launch (AS-503), and the first lunar landing mission (AS-506, or Apollo 11), constitute the highlights of chapter 12.
[323] The Saturn I flight tests were uniformly successful, and the unique size and complexity of the clustered rocket made its success all the more remarkable. Midway in the Saturn flight test programs, Dr. F. A. Speer, Chief of MSFC's Flight Evaluation and operational Studies Division, Aero-Astrodynamics Laboratory, summarized the first five flights (which included the first live two-stage vehicle, SA-5); a summation that turned out to be a prognosis for all 10 vehicles of the Saturn I series. "All five flights were complete successes," Speer reported, "both in achieving all major test missions and in obtaining an unprecedented volume of system performance data for flight analysis." Speer asserted, "It is correct to state that, up to this point, no major unexpected design change had to be initiated on the basis of flight test-thus proving the design maturity of the Saturn I vehicle."1 Troubles occurred, to be sure; but they did not cause serious delays in the mission schedules, nor serious redesign efforts.
On 27 October 1961, the first Saturn lifted from the launch pad at Cape Canaveral. All the static tests, dynamic tests, and test firings before this first launch had pointed to a successful mission, but until the liftoff of SA-1, no one could say for certain that an eight-engine monster like the Saturn would really work. The long countdown demonstrated the compatibility of the ground support equipment, and the launch crew released the "bird" (as NASA crews called the rockets) with no technical "hold" to mar the mission. The SA-1 vehicle soared to an altitude of 137 kilometers and impacted the Atlantic Ocean 344 kilometers downrange. [324] The postmission report verified the confidence of the Marshall team in the structural rigidity of Saturn's airframe, and the quartet of gimbaled outboard engines demonstrated the design goals of vehicle control and reliability. The validity of the concept of the clustered Saturn booster could no longer be questioned.2
The 10 launches of the Saturn I booster included both Block I and Block II versions. The H-1 engine was common to all the vehicles, but a number of significant differences distinguished Block I from Block II. The most visible distinguishing feature for the Block I series, SA-1 through SA-4, was the absence of aerodynamic fins on the first stage. Moreover, the Block I vehicles did not include live upper stages. Consistent with NASA's building block concept and the requirements for validating the clustered concept first, these first Saturn I launches used live lower stages only. The dummy upper stages looked like the future live versions, had the same approximate center of gravity, and had identical weight. Inert S-IV and S-V stages, topped by a nose cone from an Army Jupiter rocket, brought the typical height of the Block I series to about 50 meters.
The flight of SA-1 was remarkable for the small number of modifications that were required for succeeding flights. Experience gained from successive launches inevitably resulted in changes, but the only major difficulty that turned up with SA-1 was an unanticipated degree of sloshing of propellants in the vehicle's tanks. Beginning with vehicle SA-3, additional antislosh baffles were installed, which brought this undesirable characteristic under control. None of the Block I missions called for separation of the upper stages after the S-1 first-stage engine cutoff, although the SA-3 and SA-4 vehicles experimentally fired four solid-fuel retrorockets, anticipating the separation sequence of Block II missions. Other preliminary test items on SA-4 included simulated camera pods and simulated ullage rockets on the inert S-IV stage. The last two vehicles also carried a heavier and more active load of electronics and telemetry equipment. The telemetry equipment and associated test programs varied with the goals of each mission, but the total array of such gadgetry and the means of acquiring information help explain not only the success of the Saturn program but also the comparatively low number of R&D flights required to qualify the vehicle as operational.
The flight of SA-4 culminated with only seven engines firing instead of eight. One of the appealing features of clustered engines involved the "engine-out capability"-the prospect that, if one engine quit, the remaining engines could compensate by burning longer than planned. So NASA technicians programmed a premature cutoff of one engine 100 seconds [325] into the flight. The experiment succeeded, the SA-4 performing as hoped on the remaining seven engines.
During this basically uneventful series of launches, the Saturn I carried its first payloads. The missions of SA-2 and SA-3 included one very unusual experiment, called Project Highwater, authorized by NASA's Office of Space Sciences. The inert S-IV and S-V stages for these launches carried 109 000 liters (30 000 gallons) of ballast water for release in the upper atmosphere. As NASA literature stated, "release of this vast quantity of water in a near-space environment marked the first purely scientific large-scale experiment concerned with space environments that was ever conducted." One of the questions apparently bothering NASA planners was the consequences of a stage explosion in space or the necessity of destroying one of the Saturn rockets at a high altitude. What would happen to the clouds of liquid propellants released in the upper atmosphere? Would there be radio transmission difficulties? What would it do to local weather conditions? Project Highwater gave answers to these questions. At an altitude of 105 kilometers, explosive devices ruptured the S-IV and S-V tanks, and in just five seconds, ground observers saw the formation of a huge ice cloud estimated to be several kilometers in diameter, swirling above the spent stage to a height of 145 kilometers above the sea. It was a dramatic sight for the observers below at Cape Kennedy and marked the first use of the Saturn launch vehicles for a purely scientific mission.3
During 1964, introduction of the Saturn I Block II vehicles marked a new milestone in large launch vehicle development. To the casual observer, the most obvious distinction was the addition of the eight aerodynamic fins to the lower stage for enhanced stability in flight. As far as NASA was concerned, the most significant feature of Block II was the addition of a live upper stage, the S-IV, built by Douglas. Moreover, the S-IV stage also marked the inauguration of liquid hydrogen propellant technology in the Saturn vehicle program; six RL-10 liquid hydrogen rocket engines supplied by Pratt & Whitney were used. These engines in the upper stage would allow orbital operations for the first time in Saturn I launches. Above the S-IV stage, the Block II vehicles also carried the first instrument canisters for guidance and control. The instrument canister controlled the powered ascent of the big rocket and carried an array of sensing and evaluation equipment for telemetry acquisition from the ground.
In addition to the untried cluster of six RL-10 liquid hydrogen engines for the S-IV, the Block II Saturns relied on uprated, 836 000-newton (188 000-pound) thrust H-1 engines, that gave the first stage a total thrust of slightly over 6 672 000 newtons (1.5 million pounds). Further, the new engines powered an improved S-1 first stage. The length of the propellant containers, for instance, had been increased to provide additional propellants for the uprated engines. Despite the added weight penalty of.....
|
|
.
|
|
|
. |
|
|
|
|
|
|
.....the extended container length, there was an overall gain in efficiency of the Saturn I first stage because of numerous changes. These included, for example, weight savings through simplification of the propellant interchange system that lessened the amount of residual fuel and oxidizer trapped in the propellant interchange lines. Heightened confidence in the reliability of the H-1 engines enabled reduction of the holddown time at launch from 3.6 seconds to 3.1 seconds; this savings shifted an additional 0.5 second of maximum boost to the powered flight phase, thereby enhancing the vehicle's performance. Efficiency of propellant depletion was also increased as a result of experience and numerous subsystems changes. The first SA-1 vehicle used 96.1 percent of its fuel, for example; by the time of the flight of SA-10, the use had reached 99.3 percent. Payload capability was also increased by reducing the amount of pressurants on board. The height of the Block II rockets [327] varied with the different missions they performed. With a Jupiter nose cone, SA-5 was about 50 meters high, but the remainder of the Block II vehicles, SA-6 through SA-10, carried prototype Apollo capsules and other payloads, which stretched them to approximately 57.3 meters.4
Although electronic instrumentation and telemetry provided reams of pertinent information on the health and performance of the rocket during a mission, flight-test personnel needed visual documentation as well. For this reason, the Saturn vehicles all carried an invaluable array of visual instrumentation equipment. The Block II series continued the visual instrumentation that was begun during Block I flights. MSFC engineers wanted very much to know about the behavior of propellants within the vehicle during flight, so a number of different visual instrumentation systems were carried. Great attention was given to on-board television systems. Work with on-board TV began at MSFC early in 1959 under the cognizance of the Astrionics Division. Research emphasized the development of a compact and extremely rugged camera to stand up under the punishment of liftoff, boost phase, and free trajectory coast in extreme temperature and pressure environments. MSFC tried out the system on 31 January 1961 on the Mercury-Redstone that carried the chimpanzee Ham. The real-time, high-resolution transmitting system worked very well from liftoff across the optical horizon to about 320 kilometers distant. At the same time, the MSFC group was perfecting multiple-camera, single-transmitter equipment for the Saturn I missions; it became operational just prior to SA-1 in the fall of 1961. The system offered "real-time display and permanent storage of pictures televised from the vehicle during test flight." As mounted on SA-6, for example, two camera locations were utilized. On the ground, a videotape recorder and a kinescope recorder provided real-time viewing and storage capability. To identify each picture image, the kinescope recorder system included a digital key, indicating the camera position and time-of-flight reference. Within five minutes of a completed flight, high-resolution individual shots could be available for study.5
Television was originally selected for use on rockets because recovery of motion picture film seemed uncertain. Still, the TV units had limitations because a number of critical vehicle functions were not compatible with television camera operations and imagery. For this reason, the Saturn I flights also incorporated motion picture coverage of test flights.
A technique to incorporate such coverage was successfully demonstrated during the Redstone program in 1961 when inflight photographic instrumentation captured the separation of a warhead from a Redstone rocket booster. Early in the Saturn development program, investigators recognized the need for a similar photo system for visual analysis of phenomena that could not be simulated during ground testing or acquired through vehicle telemetry. Plans provided for inflight [328] motion picture and television coverage for the first stage of the SA-1 mission in October 1961 on the basis of the Redstone camera technology. Lack of time and money prevented use of such equipment for the first Saturn launches, and effort was redirected toward the mission of SA-5, the first live, two-stage Saturn I. Responsibility for the camera became a joint program of MSFC's Astrionics Laboratory and the Propulsion and Vehicle Engineering Laboratory. With approval for the project in October 1961, Marshall named Cook Technological Center, a division of the Cook Electric Company of Chicago, as the major contractor. Cook Technological Center then proceeded with the development and manufacture of jettisonable and recoverable camera capsules to be flown on SA-5, 6, and 7.
The camera capsules consisted of three sections: the lens compartment, with camera lens and a quartz viewing window; the combined camera and its control unit in a separate compartment; and a recovery compartment, housing descent stabilization flaps and a paraballoon for descent and flotation, a radio and light beacon for aid in recovery operations, and more conventional recovery devices such as sea-marker dye and shark repellant. The capsules were designed to cope with the stresses of powered flight, ejection, reentry, impact into the sea, and immersion in saltwater. Four model "A" capsules were positioned to record external areas of the Saturn vehicle, facing forward. Four more model "B" capsules were mounted in an inverted position to record the phenomena inside designated LOX tanks and around the interstage between first and second stages. For the "B" models, technicians linked the cameras with fiberoptic bundles to transmit images from remote locations and used incandescent lights and strobe systems for illumination. Engineers preferred to use color film whenever possible because it provided a better three-dimensional image than the gray tones of the black and white film. One camera used an extremely fast and sensitive black and white film to record phenomena inside the center LOX tank because of the lighting inside the tank.6
The launch of SA-5, 29 January 1964, was what NASA liked to call "a textbook launch." As the first Block II vehicle, the SA-5 recorded a number of firsts: first S-IV stage to fly, first guidance and control packages, and first successful stage separation. The SA-5 was the first Saturn using uprated engines, marked the first successful recovery of motion picture camera pods, and was the first orbital Saturn vehicle.
 Unlike SA-4, this was not part of the programmed flight, but the Saturn performed beautifully, proving the engine-out capability built into it by Marshall engineers. With hardly a perturbation, the vehicle continued its upward climb; stage separation and orbit of the S-IV upper stage went as planned. Telemetry pinpointed [329] the engine problem in the number 8 engine turbopump, which shut down at 117.3 seconds into the flight. When telemetered information was analyzed, engineers concluded that the teeth had been stripped from one of the gears in the turbopump, accounting for the abrupt failure of the engine. Luckily, Marshall and Rocketdyne technicians, through previous ground testing of the turbopump, had already decided that its operating characteristics dictated a modified design. A change had already been planned to increase the width of the gear teeth in this particular turbopump model, and the redesigned flight hardware was to fly on the next vehicle, SA-7. Consequently, there were no delays in the Block II launch schedule and, incidentally, no further problems with any of the H-1 engines in flight.7
Otherwise, the flight of SA-6 was eminently successful. The SA-6 was the first to carry a dummy Apollo capsule into orbit, and it tested the capsule by jettisoning the launch escape system tower, part of the Apollo spacecraft hardware development. The performance of the Block II series progressed so well that the Saturn I boosters were declared fully operational by NASA officials after the SA-7 flight (18 September 1964), three launches earlier than expected. The unmanned Apollo spacecraft on board met guidelines for design and engineering, compatibility of the spacecraft and launch vehicle, and operation of the launch escape system. The launch also confirmed the integrity of major critical areas of the launch vehicle such as the Saturn I propulsion systems, flight control, guidance, and structural integrity. For SA-7, the only event that might be considered an anomaly involved the recovery of the cameras. After stage separation, the jettisoned camera pods descended by parachute and landed in the sea, downrange of the expected recovery area. Then Hurricane Gladys blew in and closed the sector. Seven weeks later, two of the ejected SA-7 camera capsules washed ashore, encrusted with barnacles, but with the important films undamaged.8 The last three Saturn I vehicles carried a redesigned instrument unit with more sophisticated components that did not require separate, pressurized sections; the result was a lighter and shorter vehicle with enhanced performance. With a different environmental control system, the new instrument unit was the prototype for the Saturn IB and Saturn V vehicles. The most significant feature that set all three vehicles apart from their predecessors was the payload-the unusual, winglike meteoroid technology satellite known as Pegasus.9
Project Pegasus was something of an anomaly in the Apollo-Saturn program. Responsibility for Pegasus management, design, manufacture, operation, and analysis of results was charged to Marshall Space Flight [330] Center. The reputation of the Marshall center rested not on satellites, but on the launch vehicles designed and engineered by the von Braun team. The Pegasus was also unique because it was the only NASA satellite to use Saturn boosters. It was especially significant from the standpoint of designing later versions of the Saturn vehicles. Data collected by Pegasus would either confirm the ability of existing designs to operate without danger from meteoroid impact or require new designs to cope with the dangers of meteoroid collisions. The Pegasus project was an example of the painstaking scope of the Apollo-Saturn program research and development to avert any sort of serious problem. Finally, the project demonstrated several ways in which the operation contributed to the general store of scientific knowledge, as well as to the design and operation of boosters, spacecraft, and associated systems.10
Meteoric particles striking the Earth travel at speeds up to 72 kilometers per second. A dust-speck particle, weighing a mere 0.0085 gram, at such a speed packs the energy of a .45-caliber pistol fired point blank. Meteoroid phenomena in the near-Earth space environment commanded serious attention, the more so because many critical moments of manned Apollo-Saturn missions occurred in potentially hazardous zones. The Gemini spacecraft experienced meteoroid impacts many times during a 24-hour period, but the specks encountered in the lower Gemini orbits were too small to cause a puncture in the spacecraft skin. Higher orbits for the Apollo series raised concerns about heavier meteoroid particles. "It is the stuff of intermediate size that concerns a space-vehicle designer," Wernher von Braun emphasized. "Particles of only a few thousandths of a gram, whizzing at fifteen to twenty miles a second, can penetrate a spacecraft's wall or a rocket's tank. They constitute a definite risk." A meteoroid puncture in a gas compartment or propellant tank could cause a serious leak, and in the case of a highly pressurized container create an explosive rupture. Particles also created heat at the moment of impact.  Even without complete penetration, impacts could cause "spalling." The shock of impact with the skin of a spacecraft could eject fragments from the skin's interior surface to ricochet inside the vehicle. These flying fragments raised a serious possibility of danger to a crew or to vital equipment. The need for information was clear.11
Late in 1962, designers of spacecraft of the Apollo-Saturn program had very limited knowledge of the abundance of meteoroids in the vicinity of Earth, where numerous manned flights were planned and where crucial phases of the lunar missions would occur. Astronomers could provide information on meteoroids with mass above 10-4 grams, since they could be sighted optically from observatories or tracked by radar. Vehicle sensors like those on Explorer XVI provided some statistics [331] on the abundance of smaller particles, but the lack of data on the intermediate-sized meteoroids caused persistent doubts, because information on the intermediate range presented configuration criteria "of utmost importance for the design of spacecraft." Pegasus was intended to fill in the gap. As stated in the official report: "The objective of the Pegasus Meteoroid Project is the collection of meteoroid penetration data in aluminum panels of three different thicknesses in near-earth orbits. ...In fact, the abundance of meteoroids in the mass range 10-5 to 10-3 will be decisive with respect to the necessary meteoroid protection for future long-duration manned missions."12
Attached to the S-IVB second stage, Pegasus deployed in 60 seconds, extending two wings to a span of 15 meters, with a width of 4.6 meters and a thickness of about 50 centimeters. The Pegasus wing mount also supported solar cell panels for powering the satellite's electronics.13 In full deployment, the Pegasus in flight exposed about 80 times more experimental surfaces than Explorer meteoroid detectors exposed. The meteoroid impact sensor was a charged capacitor with a thin dielectric, a metal foil on one side, and a sheet of aluminum on the other side. Perforation by a meteoroid caused a momentary short between the metal plates. The discharge burned off any conducting bridges between the two metal layers; thus the capacitor "healed" after each perforation. The shorts, or discharges, were recorded as hits.14 Special sensors carried by the satellite provided information on (1) the frequency and size of meteoroids capable of damaging the spacecraft structure and equipment, and (2) the direction of the meteoroids as a function of frequency and power of penetration.15
Planned as part of the qualification program for the Saturn I rocket, the three Pegasus flights instead assumed the status of completely operational flights following the success of SA-7. On 29 December 1964, Pegasus I, the first meteoroid detection satellite, arrived at Cape Kennedy to join its Saturn I booster, SA-9.16 The numerical designation of the boosters fell out of sequence because of variations in their manufacturing. After designing and building its own first-stage boosters for the Saturn I program, NASA-MSFC departed from the original concept of work in-house to rely on industrial contractors. Chrysler Corporation became the prime contractor for the S-I first stage of the Saturn I, and Douglas continued to supply the S-IV second stage. In the process of gaining experience, Chrysler's first Saturn booster, SA-8, moved less rapidly through manufacturing and test than the last booster produced by MSFC, SA-9. In retrospect, it seems appropriate that MSFC's last rocket launched the first Pegasus, MSFC's first satellite.17
[332] To carry the Pegasus aloft, the S-IV second stage and the instrument unit underwent some minor modifications. Because heat absorption could upset the satellites thermal balance, Douglas supplied the S-IV with a special coat of paint to reduce the heating factor. New equipment consisted of an "auxiliary nonpropulsive vent system" to cut down excessive tumbling and enhance the orbit stabilization. Designers also incorporated the reworked instrument unit. NASA officials scheduled the launch of SA-9 for 16 February 1965, and technicians at Cape Kennedy worked hard to meet their preflight deadlines. With the Pegasus payload shrouded in the Apollo service module and adapter, KSC personnel affixed it to the S-IV second stage on 13 January. The next day, at Launch Complex 37-B, workers finished mating the Apollo command module to the AS-9 vehicle. In their drive for flawless operations, NASA and contractor personnel continued to tinker with the satellite right up to the last minute. On 14 February, only two days before the launch, technicians from MSFC and Fairchild made final changes in the meteoroid detection subsystem.
On 16 February, the Saturn I vehicle SA-9 successfully lifted off from launch Complex 37-B with NASA's largest unmanned instrumented satellite to date. It was the first time a Saturn rocket had been used to loft a scientifically instrumented payload into space. In a flawless mission, the Saturn I put Pegasus into orbit, and inserted the command module into a separate orbit where it would not interfere with scientific measurements. A remotely controlled television camera, mounted atop the S-IV second stage, captured a vision of the eerie, silent wings of Pegasus I as they haltingly deployed.
Pegasus took 97 minutes to circumnavigate the Earth. From scattered Moonwatch stations, observers reported the magnitude of the satellite as zero to seven as it moved through space.18 When the residual fuel from the S-IV vented, Pegasus began to tumble, with occasional intense flashes when solar rays glanced off the large wings. With its moderate orbital inclination (31ū to the equator), the best path for observation in the United States ran close to Boston and Chicago, but conditions were difficult because the satellite hovered only a few degrees above the southern horizon and the extensive slant range made sightings difficult. However, at the Smithsonian Institution's observatory in South Africa, visual sightings were easily made. As the sun's light glittered on the outstretched wings of Pegasus, observers caught flashes of reflected light that lasted for as long as 35 seconds.19
Because Pegasus relied on solar cells for power, NASA spokesmen hoped that the satellite would work at least a year, but with 55 000 parts in the system, some project officials were reluctant to predict a full 12-month lifetime, at least for the first vehicle. In the beginning, everything seemed to be working well. On its fourth orbit, scientists thought they caught the first signal of a meteoroid hit, and by the end of .....
|
| ||
|
. |
|
|
|
|
.
|
|
....the first seven days of flight, they were eagerly anticipating the first full reports read out from the Pegasus memory banks. In the first two weeks, Pegasus indicated almost a score of hits by interplanetary objects. By late May, NASA verified more than 70 meteoroid penetrations. NASA spokesmen unhappily verified extensive failures in the Pegasus satellite as well, but MSFC and Fairchild personnel had just enough time to solve these difficulties before the launches of Pegasus II and III.20
The second of the meteoroid satellites, Pegasus II, arrived at KSC on 21 April 1965. The final countdown for SA-8 began on the afternoon of 24 May. With a scheduled 35-minute hold, the countdown ticked on without a hitch into the early morning of the launch, 25 May. The flight of SA-8 marked two especially notable departures from past experiences in the Saturn program. For one, the S-1 booster was manufactured by Chrysler, and Saturn flew with a first stage supplied by a contractor for the first time. It symbolized the end of an era for the von Braun team and the long-standing arsenal "in-house" philosophy transferred from the [334] old ABMA days to the young space program of NASA. For another, SA-8 blasted off at 2:35 a.m. in the first night launch of a Saturn rocket. Highlighted against the dark night skies, the winking lights of the launch tower and the blinding glare of the floodlights around the base of the launch pad gave the scene an unusual new fascination. The darkness gave even higher contrast to the fiery eruption of ignition and the lashing tongues of fire during liftoff. Always awesome, the thundering roar of the Saturn I's ascent seemed mightier than ever before, as it seared its way upward through the dark overcast above the Atlantic. NASA officials timed the launch to avoid conflict in the communications with Pegasus I, still in orbit. Both satellites transmitted on the same frequency, and the fiery night launch of Pegasus II put the second satellite at an angle of 120ū, one-third of an orbit apart from the first.21
The launch illustrated the accuracy of the propulsion systems and confirmed the reliability of the flight electronics, which were improved in successive launches of the Saturn I series. Wernher von Braun praised the flight as "a lesson in efficiency," and George Mueller, Associate Administrator for Manned Space Flight, commented that the flight was very significant to future space flights, with their need for very close timing for rendezvous missions. Time magazine considered the flight from other points of view. The magazine approvingly reported the success of the cluster concept used on the S-1 booster and the faultless performance of the second stage with its six RL-10 engines: "The smooth success of last week's launch suggests that LH2 has at last become a routine fuel." The editors acknowledged the need for more information on meteoroid hazards in space flight but found the greatest significance in the launch itself. "Far more encouraging for space exploration," said Time, "was the smoothness with which the many-tiered rocket was dispatched into the sky." So often a rocket vehicle spent weeks or months on the pad with delays, but no setbacks occurred in the launch of SA-8, "which left its pad as routinely as an ocean liner leaving its pier."22 The second Pegasus satellite began returning data in short order. Within one day after launch, it indicated two meteoroid penetrations. Modifications on Pegasus II included successful refinement of the detector electronics and a handful of minor readjustments. The second Pegasus experienced some troubles during its mission, primarily with the analog and digital telemetry channels. Technicians finally smoothed out the digital failure, and even though the analog transmissions continued intermittently, they worked well enough to rate the mission a success. Tracing the source of trouble, workers finally decided it originated in a thunderstorm during preparation of the spacecraft on the pad, because the wettest section contained the circuit failure.23
On 21 June 1965, the Apollo command module and associated hardware arrived at KSC for the launch of the last meteoroid detection satellite, Pegasus III. With planned modifications for Launch Complex [335] 37-B to service the uprated Saturn IB launch vehicle, NASA officials decided to move the flight of SA-10 ahead to 30 July to avoid delays in both the launch and the modifications of the launch pad. Technicians ran a series of checks to verify panel deployment and compatibility of systems, then joined Pegasus III to the instrument unit of the SA-10 vehicle. On 27 July 1965, the KSC launch crew ran an uneventful and successful countdown demonstration test for SA-10, the last Saturn I. By 29 July, the final phase of the launch countdown was under way and proceeded with no technical holds to liftoff on the next day. The SA-10 vehicle performed flawlessly, inserting the command module and Pegasus III into the planned orbital trajectory. On the basis of data from all three meteoroid detection satellites, NASA spokesmen announced in December that the Apollo-Saturn structure would be adequate to withstand destructive penetration by meteoroids during space missions. The Pegasus project was successful.24
The information gathered by the Pegasus trio included much more than variations in theoretical meteoroid penetration data. In his capacity as Director of the Space Sciences Laboratory, Ernst Stuhlinger praised the secondary results, which returned scientific data valuable to the design and engineering of future spacecraft, as well as knowledge of specific scientific nature. "It sometimes occurs that an experiment, planned for one specific objective, provides observational results far beyond the single-purpose mission for which it was originally conceived," he said. "Project Pegasus, which has the primary objective of measuring the near-Earth environment, is an example in case." For the benefit of spacecraft designers, the 65 000 hours accumulated in all three missions provided significant and valuable data on meteoroids, the gyroscopic motion and orbital characteristics of rigid bodies in space, lifetimes of electronic components in the space environment, and thermal control systems and the degrading effects of space on thermal control coatings. For physicists, the Pegasus missions provided additional knowledge about the radiation environment of space, the Van Allen belts, and other phenomena.25
The last of the meteoroid detection satellites, Pegasus III, carried a captivating experiment, one of the first intended to be left in space, to be personally retrieved by an astronaut at some future date. Eight large detector segments were removed from the Pegasus wings, replaced with "dummy" panels and 48 temporary coupons, cut from samples of the detector surfaces. The coupons, in turn, carried 352 items of test materials and thermal samples, some of them in use, others considered as candidates for future application. Examples of the test items included aluminum skin specimens, ranging from sandblasted and anodized surfaces to pieces covered with luminescent paint and gold plate. The launch of Pegasus III put it into an orbit of 530 kilometers. After 12 months, NASA planners expected the orbit of Pegasus III to decay some, [336] putting it in position for a potential rendezvous with a Gemini spacecraft. Theoretically, one of the Gemini astronauts could emerge from the Gemini capsule, maneuver himself to the Pegasus wings, recover a selected group of test specimens, and return to the spacecraft. With the return of the astronaut's armful of samples to Earth, scientists could not only make direct studies of the effect of meteoroid impacts on metals in interplanetary space but also examine specimens of meteoroids taken directly from the space environment. Unfortunately, the experiment was never possible during Gemini, and the final Pegasus reentered the atmosphere on 4 August 1969. Its destruction during reentry brought an untimely end to an intriguing experiment.26
In terms of rocket development, the series of Saturn I launches was remarkably successful. Most rocket programs had severe teething troubles early in the game; up to two or three dozen test shots and loss rates of 50 percent were not out of the ordinary. True, the Saturn I used engines and tanks extrapolated from earlier programs, but uprating the H-1 engine had brought difficulties, and a cluster of this magnitude was untried. Moreover, the later Saturn missions introduced a sizable new LH2 upper stage, powered by a cluster of six RL-10 engines.
For all this, there seems to have been persistent criticism of the Saturn I series of launches. Basically, it appeared to be a multimillion-dollar launch vehicle program with no significant missions or payloads. Even before the launch of SA-2 in the spring of 1962, NASA had announced the Saturn V. It was this vehicle, not Saturn I, that had the mission and payload that counted: a lunar voyage with a payload equipped to land men on the moon and get them back again. As a preliminary to Saturn V missions, plans were already in progress for the Saturn IB, which would test a Saturn V third stage in orbit and begin qualification of crucial hardware such as the command module and lunar module.
The Saturn I, as one NASA historian has written, was a "booster almost overtaken by events." A number of individuals, within NASA as well as on the outside, felt that Project Highwater and, to a lesser extent, Project Pegasus were makeshift operations to give Saturn I something to do and to placate critics who complained that the Saturn was contributing little to science. There is probably some truth in these allegations. Highwater in particular seems to have been an impromptu operation, revealing nothing new. Although NASA literature solemnly referred to scientific aspects, von Braun called Highwater a "bonus experiment," and noted that the water was already aboard Saturn I stages as ballast.27
With hindsight, the apparently superfluous Saturn I launches still contributed to the Saturn program, underscoring the innate conservatism [337] of Marshall Space Flight Center. Aware of potential early failures in a launch series, MSFC evidently planned for several, but to make the series as successful as possible, Marshall also went into each launch with vehicles tested and retested to the point where the possibility of failure was virtually eliminated. Marshall's own thoroughness made the remarkable string of 10 successful launches seem unnecessarily redundant. In any case, the launches verified many concepts for systems and subsystems applied to later Apollo-Saturn missions, provided valuable experience in the operation of LH2 stages, demonstrated the validity of the cluster concept, and tested early versions of Saturn guidance and control. Payloads for the Saturn I launches may not have been as dramatic as those for other vehicles, but Saturn I missions, overall, were nevertheless beneficial.
In a strict sense, the series of Pegasus launches was not very earthshaking. None of the three satellites promoted any fantastic new discoveries; no dramatic design changes occurred in either the Saturn launch vehicles or the Apollo spacecraft as a result of unexpected information about meteoroid penetration. The value of the Pegasus involved a positive, rather than a negative, reading of the test results. The satellites confirmed basic estimates about meteoroid frequency and penetration in the operational environment of the Apollo-Saturn vehicles. This confirmation provided a firm base of knowledge to proceed with basic designs already in the works. In fact, it was good that the Pegasus series did not turn up significantly different data, which would have entailed costly redesign and additional time and research into meteoroid phenomena as related to boosters and spacecraft. Instead, the effect was to add to the growing confidence of Apollo-Saturn designs already in process and to permit NASA to plunge ahead toward the goal of landing man on the moon within the decade. It would have been easy to dismiss what was, in fact, a successful developmental phase in the overall Apollo-Saturn program.28
In terms of subsequent programs, the legacy of Pegasus included significant contributions in the development of thermal coatings used on many major satellites, as well as on the Apollo spacecraft. The Pegasus also had a significant impact on the development of the communications satellite (comsat) project, because the results indicated that the comsat satellites would indeed have a profitable lifetime in orbit, the probability being high that they would survive or escape damage from meteoroids. Wernher von Braun was emphatic on this point: "I would say the Pegasus data have really become the main criteria of spacecraft design, ever since Pegasus, for all manned and unmanned spacecraft."29
The Saturn IB represented significant advances toward the hardware and techniques to be used in lunar landings. S-IB first stages included a [338] number of modifications to increase the overall vehicle performance, as compared with the S-I series. The aerodynamic fins were further modified, and changes in fabrication techniques saved considerable weight (see chapter 3). The eight H-1 engines were uprated from 836 000 to 890 000 newtons (188 000 to 200 000 pounds) of thrust each. Most importantly, the Saturn IB missions provided an opportunity to flight-test the first Saturn V hardware. The S-IVB upper stage with its single J-2 engine was nearly identical to the upper stage carried on the Saturn V, and the same was true of the instrument unit (see chapter 8).30
Saturn IB missions began with the unmanned launch of AS-201 from KSC Launch Complex 34 on 26 February 1966. With both stages live, the vehicle made a successful 32-minute suborbital flight, reaching an altitude of over 480 kilometers with impact into the south Atlantic about 320 kilometers from Ascension Island.
The primary tests concerned separation of the spacecraft, followed by the command module's reentry into Earth's atmosphere. The maneuver successfully demonstrated that the command module's heat shield could withstand the intense temperatures created by atmospheric friction during reentry. The first Saturn IB experienced relatively few problems in flight, although the mission was nearly canceled during countdown. Bad weather delayed the launch date for three days, and on the day of the liftoff, launch officials postponed the firing command for three hours while technicians did some trouble-shooting on several last-minute technical problems. The most serious difficulty involved the gaseous nitrogen purge system that cleaned out the engines and the related machinery prior to launch. At T-4 seconds, the gaseous nitrogen pressure limits had dropped below the red-line level and an automatic cutoff sequence was started. After resetting the equipment and starting the countdown once more, at T-5 minutes engineers perceived the problem again and requested a hold. Engineers estimated that it would possibly take two hours of work to recheck and reset all the equipment. Reluctantly, the recommendation was made to scrub the launch. Still searching for options, a group of launch crew engineers suggested a different test of the system to assess other alternatives, and stage engineers agreed; so the countdown was restarted at T-15 with the gaseous nitrogen pressures reset at different levels. The countdown and launch were finally completed successfully.31
Saturn IB missions carried inflight visual instrumentation perfected during the Saturn I missions. Only two movie cameras were used, however, and a ribbon parachute was added to the capsules to slow their descent even more, because some capsule damage had occurred on the SA-6 mission. Typically, the cameras were located atop the first stage to record stage separation and ignition of the S-IVB second stage. On the AS-201 flight neither of the parachutes worked properly, and the Air Force recovery team found only one capsule. On the other hand, the [339] guidance and control system performed as expected, telemetry was good, and no structural problems were discerned. The propellant utilization system worked as designed: the LOX and LH2 were depleted simultaneously. All things considered, the two-stage Saturn IB vehicle achieved a notable inaugural flight.32
The second launch of the Saturn IB series, on 5 July 1966, carried an out-of-sequence number designation, AS-203. Originally scheduled for the second launch in the series, AS-202 became third in line to gain additional time for checkout of its Apollo spacecraft payload. NASA made the announcement in April, explaining that the AS-203 mission primarily involved launch vehicle development. Mission objectives for the second Saturn IB launch concentrated on the orbital characteristics and operation of the S-IVB second stage, so the vehicle had a simple aerodynamic nose cone in place of the Apollo spacecraft. Launch officials considered the second stage itself, with 10 metric tons of liquid hydrogen aboard, as the payload. Testing was scheduled to gain further information about liquid hydrogen in the orbital environment and about procedures for reignition of the S-IVB in orbit, a requirement for Saturn V missions in the future. The reignition sequence was not to be live but simulated with the S-IVB and J-2 engine systems. In an attempt to telescope development of the stage and engine operations, last-minute consideration was given to an actual restart of the J-2 engine. A number of people within Marshall Space Flight Center, however, opposed restarting the J-2 because that would unduly complicate the developmental flight. In a letter to Major General Samuel C. Phillips, Eberhard Rees estimated that a complete restart sequence would require an additional 1800 kilograms of liquid oxygen and 1400 kilograms of other equipment and provisions and would compromise the main test goals of the behavior of liquid hydrogen in the orbital environment as well as other test procedures. "Douglas and MSFC are confident that a successful AS-203 mission, as presently defined," said Rees, "should establish whether or not successful restarts can be accomplished on Saturn V missions."33
For reignition under weightless conditions, fuel and oxidizer had to be settled in the bottoms of the propellant tanks. Engineers hoped to achieve this through the use of the hydrogen continuous vent system. The venting gas imparted thrust which pushed the propellants to the bottom of the tanks. This thrust could be augmented by occasionally opening the liquid oxygen tank propulsive vent valve. To study the stability of the liquid hydrogen in orbit and to check settling of the liquid hydrogen at the bottom of the tanks, the S-IVB carried a pair of TV cameras mounted inside the tank. Prior to launch, a checkout of the TV system uncovered trouble in one of the cameras. After a hold of almost two hours, NASA engineers decided not to postpone the launch any longer and the vehicle lifted off with only one of the cameras expected to work. Fortunately, the remaining camera functioned well, and the [340] images verified the hopes for proper propellant behavior during venting and for settling of the propellants prior to reignition. Motion picture color coverage of stage separation, recovered from the ocean in one of the camera capsules, was also of high quality and showed the desired performance.
Following the satisfactory TV coverage of the behavior of liquid hydrogen under weightless conditions and a simulated restart of the J-2, technicians proceeded with the plan to break up the S-IVB stage in orbit. This rather dramatic procedure was intended to verify ground tests that had been carried out on structural test models at Douglas facilities on the West Coast. Investigators from Douglas and MSFC wanted to establish design limits and the point of structural failure for the S-IVB common bulkhead when pressure differential developed in the propellant tanks. Ground tests were one thing; the orbital environment of space was another. Breakup occurred near the start of the fifth orbit when the common bulkhead failed and the stage disinte-grated. The results confirmed the Douglas ground experiments; the S-IVB stage could withstand tankage pressure differentials over three times that expected for normal mission operations.34
AS-202, launched on 25 August 1966, returned to the suborbital mission profile because the primary purpose was to test the heat shield on the command module (CM). Extensive holds, taking up three days, had been caused by problems with the spacecraft and ground telemetry. With the problems finally resolved, the AS-202 vehicle lifted off in a flawless launch. The S-IVB successfully tested its ullage rockets and ignited as planned despite some minor valve malfunctions in the recirculation system of the J-2. Separation of the S-IVB and the CM caused oscillatory motions of the S-IVB, which could have made for tricky maneuvers for CM docking with the lunar module (LM) in manned missions, but the S-IVB auxiliary propulsion system brought the stage back under control. In accordance with the planned profile, the CM made a "skipping" reentry to raise the heat loads and subject the heat shield to maximum punishment. Recovery of the scorched CM occurred near Wake Island in the Pacific Ocean.
The success of the first three Saturn-IB missions heightened expectations for the first manned launch, scheduled for 21 February 1967 as AS-204. The three-man crew included Virgil I. Grissom, Edward H. White II, and Roger B. Chaffee. During a checkout of the complete vehicle on the launch pad at KSC's Launch Complex 34 on 27 January, a flash fire erupted inside the CM. Trapped inside, the three astronauts died.35
The exhaustive investigation of the fire and extensive reworking of the CMs postponed any manned launch until NASA officials cleared the CM for manned flight. Saturn IB schedules were suspended for nearly a year, and the launch vehicle that finally bore the designation AS-204 carried an LM as the payload, not the Apollo CM. The missions of AS-201 and [341] AS-202 with Apollo spacecraft aboard had been unofficially known as Apollo 1 and Apollo 2 missions (AS-203 carried only the aerodynamic nose cone). In the spring of 1967, NASA's Associate Administrator for Manned Space Flight, Dr. George E. Mueller, announced that the mission originally scheduled for Grissom, White, and Chaffee would be known as Apollo 1 and said that the first Saturn V launch, scheduled for November 1967, would be known as Apollo 4. The eventual launch of AS-204 became known as the Apollo 5 mission (no missions or flights were ever designated Apollo 2 and 3).36
As Apollo 5, the original AS-204 vehicle lifted off from Launch Complex 37 at KSC on 22 January 1968 in an unmanned test of the lunar module in Earth orbit. The LM was enclosed in a spacecraft-lunar-module adapter and topped by an aerodynamic nose cone in place of the Apollo command and service modules (CSM). Evaluation of the LM included ignition of the descent and ascent stages and LM staging and structures. Engineers also intended to conduct an S-IVB propellant dumping experiment in orbit, following separation of the stage from the LM. Dumping was considered necessary to make the S-IVB safe before docking of the CSM with the S-IVB-attached LM.
Some months prior to the AS-204 mission, NASA planners realized that the vehicle was going to be sitting stacked on pad 37 for a considerable period of time awaiting the arrival of the LM. NASA took advantage of the opportunity to monitor the conditions of the launch vehicle over a long period of time, as it stood on the pad exposed to the elements on the Florida coast. On 7 April 1967, the first stage had been erected; the second stage and the instrument unit were added in the next four days. Marshall and contractor personnel devised a detailed set of criteria for periodic inspections of the vehicle starting that same month. No components had to be replaced because of corrosion; advance planning had paid off. The vehicle was under constant nitrogen purges to protect the engine compartment and other equipment areas from the salty atmosphere. The vehicle propellant tanks were also kept under pressure with dry nitrogen. These procedures were maintained during a kind of musical chairs operation as the LM and its associated hardware were moved in and out, off and on, for several weeks. After arrival of its ascent and descent engines and their mating, they had to be taken apart in August to repair leaks in the ascent engine. Then the two stages were mated again until September when a new leak required demating. Several items of LM hardware had to be shipped back to the contractor for additional work. The ascent and descent engines of the LM were put together again in October, and tests were run until November when the spacecraft was taken to the pad and mechanically mated with the booster. The flight readiness tests were not accomplished with the total vehicle until late in December with the LM in position, nearly nine months after the launch vehicle had been put in place on Launch Complex 37.
[343] The successful mission of AS-204 in January 1968 was therefore very gratifying to the launch vehicle crews as well as to the LM crews. Both the first and the second stages performed well, and a new liquid-hydrogen-recirculation-chilldown control valve on the S-IVB worked without a hitch, eliminating a potential problem uncovered on the AS-202 mission. The guidance and telemetry systems met requirements, the panels protecting the LM deployed, and the LM separated from the S-IVB with no trouble. During the S-IVB liquid oxygen dump and liquid-hydrogen dump experiments, the exhausting of propellants through the J-2 engine caused minor attitude variations in the stage, but these were corrected by the thrust vector control system and the auxiliary propulsion system modules. On the morning of 23 January 1968, the S-IVB stage disintegrated during reentry. AS-204 once more set the stage for the first manned launch in the Apollo-Saturn program: AS-205, known as Apollo 7.37
Launched on 11 October 1968 from KSC Launch Complex 34, the Apollo 7 had a crew made up of Walter M. Schirra, Jr., Donn F. Eisele, ....
|
|
.
|
|
[344] ....and R. Walter Cunningham. Primary objectives for the mission pertained to the CSM, crew performance, manned mission support facilities for the CSM, and CSM rendezvous techniques. With three astronauts aboard and the necessary provisions to sustain them in orbital flight, the launch of AS-205 marked again an increase in payload capability. Much of this increase came from the reduction of measurement instrumentation from the prior Saturn launches. AS-204 had required 1225 measurements; 720 sufficed in AS-205. The Apollo 7 spacecraft also was the product of extensive redesign since the disastrous fire the year before. It featured a quick-opening one-piece hatch, an extensive substitution of materials to reduce flammability, and a modification of the cabin atmosphere for testing and prelaunch operations. Even though primary attention centered on the manned aspects of the mission, NASA and Rocketdyne personnel were closely watching the augmented spark igniter lines for the J-2, which had been modified after they failed during the Apollo 6 mission on 4 April 1968 (see chapter 12).
The ascent of both Saturn IB stages went like clockwork. During the boost phase of the S-IC stage, Schirra routinely reported an instrument readout of the pitch program, and noted, "She['s] running-it's getting a little noisy now." Then Schirra called out the sequence of inboard and outboard shutdown of the H-1 engines, followed by confirmation of S-IVB ignition on cue at programmed thrust levels. In between comments from Schirra that the ride from the S-IVB was "a little bumpy," flight controllers in Houston also caught Schirra's enthusiastic remark, "She's riding like a dream," and a voice from the spacecraft that "the window view is sensational."38 After more than one hour in orbit, the instrument unit initiated the automatic "safing" sequence, which included the propellant dumping operation. Separation of the CSM from the spent S-IVB stage took place on schedule, and the astronaut crew turned the CSM around for the simulated docking maneuver (the AS-205 did not actually carry an LM). As part of the simulated LM rendezvous exercise, the CSM was maneuvered to a station-keeping position near the spent S-IVB stage as it tumbled through space. On 18 October, seven days after liftoff, the S-IVB reentered over the Indian Ocean. The three astronauts completed 63 orbits before successful reentry and splashed down into the Atlantic on 22 October, where they were picked up by teams from the recovery ship Essex. The Apollo 7 mission achieved all primary mission objectives, and the last of the Saturn IB flights was over. NASA intended the AS-201 through AS-205 flights to qualify the Apollo spacecraft, and the requirements had been met. The Saturn IB first stages had also performed as expected, but more importantly the S-IVB upper stage and the instrument unit for the Saturn V were successfully qualified in orbit.39 In less than a year, the space agency expected to land men on the moon. That mission required the giant Saturn V.
[345] With the exception of the S-IVB, every stage of the Saturn launch vehicles depended on clustered engines. The feasibility of large, high-thrust engine clusters was demonstrated by the first successful launch of the Saturn I and verified in one mission after another. Later Saturn I flights (the Block II series) proved the feasibility of using liquid hydrogen fuels in Saturn upper stages. The Saturn I series also provided the opportunity to perfect visual instrumentation systems and to try out evolving concepts of guidance and control as well as hardware and software tagged for the manned lunar landing program. Even though the Highwater experiments contributed little to astronautical science, the Pegasus flights yielded pertinent information that confirmed booster and spacecraft designs under way and accumulated scientific data that influenced the design and operations of later manned and unmanned spacecraft.
Introduction of the Saturn IB afforded NASA the opportunity to flight-test important elements of Apollo-Saturn flight hardware. This included the S-IVB upper stage, the instrument unit, the command and service modules, and the lunar module. During the Saturn IB missions, operations planned for the Saturn V were given a trial run, including orbital coast and restart of the S-IVB and stage separation of the S-IVB and lunar module. The orbital operations and restart of the J-2 engine subjected the instrument unit to the kind of sequencing critical for future lunar missions, and advanced telemetry and visual instrumentation yielded knowledge of the behavior of cryogenic propellants (particularly liquid hydrogen) in orbit.
Finally, the Saturn IB powered the first manned Apollo mission, Apollo 7. This manned, Earth-orbital mission cleared an important hurdle before the towering Saturn V lifted a similar payload and steered a course for the moon.


--- layout: post title: 田園に死す date: '2014-08-08T12:22:00+02:00' categories: - Resources picture_url: https://film-Storyboards.tumblr.com/post/94171055166/if-you-cant-control-your-dreams-or-edit-your ---
If you can’t control your dreams or edit your memories, you are still not a true creator.—ISAO KIMURA as the Film Critic in Shūji Terayama’s 田園に死す Den-en ni shishu (Pastoral Hide and Seek) 1974


filter viral RNA virus influenza Air using sampling OpenUrl Viral used recovery p-value vs. HBSS Trizol air extraction Kit PBS material methods wash Influenza filters materials No-Air No-Air: different significantly studies copies method viruses .). chamber detection type PTFE PVC Trizol, buffer relative resulted samples Mini airborne compared experiment. exposure higher previous recovery. samplers virus. Lot RT-qPCR affect collection effect environmental media standard (Kit, HBSS: However, PBS: QIAamp Using View aerosol aerosolized field humidity results treated use <; (i.e., Detection HBSS, Kit, aerosols commonly detect electrospun experimental fabricated greater novel polystyrene respiratory sample study supplied surface total (Life (p-value Balanced Download Figure Health PBS, Therefore, Total air, attached buffer, comparisons control did differences experiment followed future however, human inhalation measured molecular nanofiber placed pump quantification sample. set spiked target viruses. water


Connecting People App
Bolstered with a new identity, Equestrian Canada, the Canadian federation for equestrian sport mandated Locomotive with the redesign of its portal. The tram is a thing of a past, a thing from our childhood.
{{> head/head head.caseZendwoord}}
%=symbols=%


Join our mailing list for daily laundry tips!!
Here's a link to another similar site. This website has a much better lay out and has more content to work with. My page is just a rough draft of what might be. Content is easy to read and information is easy to access on the exampe page. Layout could be sleek, not much bad about the site.