Dynamics of Bond Dissociation and Formation in Gas-Surface reactions
by Dr. H.K. Shin, University of Nevada, Reno, Dept. of Chemistry
Adsorption, desorption and formation of new bonds are key
elementary steps in gas surface reaction. The study of the kinetics
and mechanisms of reactions taking place on solid surfaces is a
subject of great importance, since many reactions occur at a very slow
rate in the absence of a catalyst but can be accelerated greatly by a
solid surface. Chemically active atoms or molecules bound to solids
are attractive model systems for studying the chemistry and physics on
surfaces. The O2(g)/H(ads)/surface system contains
such an active species and the study of this system is important in
evaluating the practicality of using the adatom as a model reagent in
studies of surface chemistry, where (g) indicates a molecule in
the gas phase and (ads) means an atoms absorbed on the surface
of a metal. The O2(g)/H(ads) collision in the
system is not only a fundamental step involved in the H2
+ O2 reaction taking place on a metal surface but also
a prototype model for the development of general concepts in surface
reactions. The fundamental processes taking place in the
O2(g)/H(ads)/surface system are vibrational energy
transfer to H-surface and O2 bonds,
dissociation of H-surface bond, formation of
H-O2 bond, redissociation of H-O2,
and dissociation of O2 bond. These processes
sensitively depend on the initially in a highly excited state. The
desorption of absorbed atoms occurs when the H-surface
coordinated accumulates energy in excess of the depth of the
attractive potential well. Thus, the probability of this desorption
process is dependent on the efficiency of energy transfer between the
absorbed atom and the incident oxygen molecule. When the atom
desorbs, it turns into a very reactive atom and it can then serve as
an effective reagent for subsequent surface catalyzed reactions. In
the treatment of the kinetics of surface reactions involving the
hydrogen molecule as one of the reactant molecules, it is necessary to
recognize the dissociative chemisorption of H2 on
surface sites if the metal before the reaction takes place.
Figure: The probability of collision-induced
dissociation of the hydrogen-metal bond in the
oxygen/hydrogen/surface system as a function
of the collision energy.
Currently, we are studying the process of vibrational energy
transfer to the H-surface bond and the subsequent desorption of
this atom from a metal surface and formation of free radicals in the
O2(g)/H(ads)/surface system by classical mechanics.
Through this study, we are interested in learning the dynamics and
mechanism of the peroxyl radical H-O2 formation, and
the accumulation of vibrational energy in the newly formed
H-O2 bond. We solve the equations of motion of the
collision system for the coordinates and momenta of each atom on the
Cray. The time step in these calculations is set at 0.2 femtoseconds
or approximately 1/100th the vibrational period of
O2. We randomly sample many trajectories over a
wide range of the collision energy. We then determine the average
lifetime of this radical, which is important in understanding the
rater of subsequent processes such as H-O2
redissociation. When this occurs, the product is the hydroxyl radical
OH and oxygen atom O. These are also very reactive
species and their release into the gas phase can lead to important
atmospheric elementary reactions. In particular, when the oxygen atom
encounters an oxygen molecule, an ozone molecule can form, so the
simple model O2(g)/H(ads) collision on a metal
surface can lead to secondary chemical reactions which are of
fundamental importance to the understanding of atmospheric phenomena.
Furthermore, when the absorbed H atom is in the low-lying
vibrational state, collision leads to translation-to-vibration energy
flow. The heavy metal atoms can block the dissipation of energy into
the bulk metal phase resulting in a temporary storage of energy on the
metal surface. This energy can be utilized for the initiation of
further chemical reactions.
Solid-State Storage Device (SSD)
by Sam West, AIC, NSCEE
IN this article we will describe the model 3I Solid-State
Storage Device (SSD) on the NSCEE Cray y-MP 2/216. We will
also discuss its performance and uses, which from a user's viewpoint,
can be passive or active.
The SSD is a tightly-coupled on-line storage device that
provides fast access (1000MB/s), large capacity (32MW)* secondary
memory that is readable and writeable directly from Cray central
memory and IOS buffer memory.
The model 3I, unlike earlier versions of the device which had their
own chassis, is located in the IOS chassis along with this system's 3
IOPs. The device is comprised of 72 single layer memory
modules (DRAM), 7 two-layer vhisp (very-high-speed channel - 1000MB)
And vhisp controller modules and 6 hisp (high-speed channel - 100MB)
and hisp controller modules. The 1000MB channel is used for direct
SSD<-->CM (central memory) transfers and the 100MB channels are
used for SSD<-->BMR (IOS buffer memory) transfers.
Although the SSD memory controller deals with 64 word blocks, the
IOS typically will read or write 512 word blocks that mimic disk
behavior. This allows the system to deal with the SSD as a very fast
disk (sort of a ramdisk, for you pc'ers).
With that discussion out of the way, let's proceed to the more
important topic: How do you make use of this device?
There are three ways to use SSD memory:
- As a file system
- As ldcache
- As SDS (secondary data segments - don't be confused by the
confusing state of acronyms)
SSD as filesystem
When the system is configured, block-structures physical devices
are partitioned into slices. These slices are assembled into
numerous, block-structured, logical devices. These logical devices
are then useable as filesystems (/, /usr, /tmp, etc ...). The SSD, as
a block-structured device, is really no different in this regard, and,
with its 32MW (which translates into the equivalent of 65536 disk
blocks), it could be used as a filesystem of respectable size. The
improved transfer rate would lead to substantially improved
performance for I/O to files on that filesystem. At NSCEE we have
opted for a broader use of what is, for us, a scarce resource.
Therefore, on clark the SSD is not used in this manner.
SSD as ldcache
As an alternative to assembling the SSD's physical slices (in our
case it's a single slice) into a logical device and using it as a
filesystem, the logical device can be assigned the distinction of
serving as SDSDEV (Secondary Data Segment DEVice.) Chunks of
this device can then be dynamically allocated (on the running system)
to two uses; ldcache and SDS. Ldcache (Logical Device
Cache) allows for selective augmentation of the system buffer cache.
Selective, in this case, means that we can pick which particular
logical device (and, therefore, which filesystem) will be cached. The
operating system's buffer cache currently is comprised of 838656 words
(or 1639 buffers); but, those buffers are shared among all block
devices, whereas chunks of ldcache can be allocated where they are
needed: /tmp, /usr, etc. currently, 7.7MW of the SSD is allocated to
ldcaching /, /usr, /usr/spool and /usr/tmp. What this means is that,
if you've logged on, you've already been a passive user of the SSD.
SSD as user SDS
Finally, we come to individually controlled usage of SSD. A chunk
of SDSDEV can be allocated by a process and I/O to it performed as if
it were a normal file. So, if your program is already doing the sort
of I/O that is appropriate (e.g. an out-of-core solution of a large
model), it will probably need no changes to use the SSD instead of a
disk file. The assign(1) command (see the article on assign(1) in the
August NSCEE newsletter) allows you simultaneously to allocate SDS and
make a correspondence between it and a logical filename used by your
program. An NQS job that demonstrates this type of usage and
the appropriate assign command can be found on clark in
/usr/local/examples in file sdstest.j. stdout and
stderr from this job are also located in the examples directory
in files sdstest.o and sdstest.e. The job profile can
be copied and used as is by issuing the command:
clark% qsub
sdstest.j
NQS will route the output back to you automatically.
If an out-of-core solution is required for your particular
application 9remember that this is a real memory machine, and our
current maximum job size is 10MW) using SDS instead of disk files
could significantly improve your program's performance.
For further information, please see the following Cray
documentation: INICOS I/O Technical Note, SN-3075; UNICOS User
Commands Reference Manual, SR-2011.
If you need the SSD, then your account will have to be allocated
SSD usage. Please contact NSCEE staff for further information.
Note: *A Cray word = 64 bits = 8 bytes. The YMP has 16MW
(128MB) of CM (central memory), 8MW (64MB) of BMR (buffer memory
resident - IOS buffer memory), and 32MW (256MB) of SSD.
