Search NASA⌕ Search

SEARCH · Search NASA

Results for “Linux cluster”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2003

Scalability of a Low-Cost Multi-Teraflop Linux Cluster for High-End Classical Atomistic and Quantum Mechanical Simulations

Scalability of a low-cost, Intel Xeon-based, multi-Teraflop Linux cluster is tested for two high-end scientific applications: Classical atomistic simulation based on the molecular dynamics method and quantum mechanical calculation based on the density functional theory. These scalable parallel applications use space-time multiresolution algorithms and feature computational-space decomposition, wavelet-based adaptive load balancing, and spacefilling-curve-based data compression for scalable I/O. Comparative performance tests are performed on a 1,024-processor Linux cluster and a conventional higher-end parallel supercomputer, 1,184-processor IBM SP4. The results show that the performance of the Linux cluster is comparable to that of the SP4. We also study various effects, such as the sharing of memory and L2 cache among processors, on the performance.

Kikuchi, Hideaki↗
NASA NTRS2008

Benchmark Comparison of Dual- and Quad-Core Processor Linux Clusters with Two Global Climate Modeling Workloads

This viewgraph presentation details the science and systems environments that NASA High End computing program serves. Included is a discussion of the workload that is involved in the processing for the Global Climate Modeling. The Goddard Earth Observing System Model, Version 5 (GEOS-5) is a system of models integrated using the Earth System Modeling Framework (ESMF). The GEOS-5 system was used for the Benchmark tests, and the results of the tests are shown and discussed. Tests were also run for the Cubed Sphere system, results for these test are also shown.

McGalliard, James↗
NASA NTRS2005

Testing the Archivas Cluster (Arc) for Ozone Monitoring Instrument (OMI) Scientific Data Storage

The Ozone Monitoring Instrument (OMI) launched on NASA's Aura Spacecraft, the third of the major platforms of the EOS program on July 15,2004. In addition to the long term archive and distribution of the data from OM1 through the Goddard Earth Science Distributed Active Archive Center (GESDAAC), we are evaluating other archive mechanisms that can archive the data in a more immediately available method where it can be used for futher data production and analysis. In 2004, Archivas, Inc. was selected by NASA s Small Business Innovative Research (SBIR) program for the development of their Archivas Cluster (ArC) product. Arc is an online disk based system utilizing self-management and automation on a Linux cluster. Its goal is to produce a low cost solution coupled with the ease of management. The OM1 project is an application partner of the SBIR program, and has deployed a small cluster (5TB) based on the beta Archwas software. We performed extensive testing of the unit using production OM1 data since launch. In 2005, Archivas, Inc. was funded in SBIR Phase II for further development, which will include testing scalability with the deployment of a larger (35TB) cluster at Goddard. We plan to include Arc in the OM1 Team Leader Computing Facility (TLCF) hosting OM1 data for direct access and analysis by the OMI Science Team. This presentation will include a brief technical description of the Archivas Cluster, a summary of the SBIR Phase I beta testing results, and an overview of the OMI ground data processing architecture including its interaction with the Phase II Archivas Cluster and hosting of OMI data for the scientists.

Tilmes, Curt↗
NASA NTRS2006

Architecture Adaptive Computing Environment

Architecture Adaptive Computing Environment (aCe) is a software system that includes a language, compiler, and run-time library for parallel computing. aCe was developed to enable programmers to write programs, more easily than was previously possible, for a variety of parallel computing architectures. Heretofore, it has been perceived to be difficult to write parallel programs for parallel computers and more difficult to port the programs to different parallel computing architectures. In contrast, aCe is supportable on all high-performance computing architectures. Currently, it is supported on LINUX clusters. aCe uses parallel programming constructs that facilitate writing of parallel programs. Such constructs were used in single-instruction/multiple-data (SIMD) programming languages of the 1980s, including Parallel Pascal, Parallel Forth, C*, *LISP, and MasPar MPL. In aCe, these constructs are extended and implemented for both SIMD and multiple- instruction/multiple-data (MIMD) architectures. Two new constructs incorporated in aCe are those of (1) scalar and virtual variables and (2) pre-computed paths. The scalar-and-virtual-variables construct increases flexibility in optimizing memory utilization in various architectures. The pre-computed-paths construct enables the compiler to pre-compute part of a communication operation once, rather than computing it every time the communication operation is performed.

Dorband, John E.↗
NASA NTRSDate not supplied

TPSAS-NF1676L-32060-DND

All previous PSP testing done in the Unitary Plan Wind Tunnel (UPWT) have required a significant amount of manual operation of the system. This has resulted in decreased testing efficiency and precluded the ability to provide near real-time data analysis to the customer. The overall goal of this project is to integrate the PSP data acquisition system into the supersonic UPWT data acquisition system (DAS) and create an adaptive software platform from which PSP data acquisition can be triggered by the tunnel and critical testing conditions can be recorded in real time for rapid analysis of the PSP data. This analysis includes the mapping of up to eight camera views onto a surface grid for analysis and converting to pressure using parameters supplied by the DAS. To fully implement this solution, communication must first be established between the Unitary DAS and the PSP DAS. This will be done by employing multiple scripts written in Python and C++ and implemented on a Linux cluster. These will be demonstrated and refined on an upcoming test (December 2018), and the successful completion will result in the ability to have automatic collection of PSP images and near real-time analysis capabilities.

Juliette Eddins↗
NASA NTRS2004

The Development of Two Science Investigator-led Processing Systems (SIPS) for NASA's Earth Observation System (EOS)

In 2001, NASA Goddard Space Flight Center's Laboratory for Terrestrial Physics started the construction of a science Investigator-led Processing System (SIPS) for processing data from the Ozone Monitoring Instrument (OMI) which will launch on the Aura platform in mid 2004. The Ozone Monitoring Instrument (OMI) is a contribution of the Netherlands Agency for Aerospace Programs (NIVR) in collaboration with the Finnish Meteorological Institute (FMI) to the Earth Observing System (EOS) Aura mission. It will continue the Total Ozone Monitoring System (TOMS) record for total ozone and other atmospheric parameters related to ozone chemistry and climate. OMI measurements will be highly synergistic with the other instruments on the EOS Aura platform. The LTP previously developed the Moderate Resolution Imaging Spectrometer (MODIS) Data Processing System (MODAPS), which has been in full operations since the launches of the Terra and Aqua spacecrafts in December, 1999 and May, 2002 respectively. During that time, it has continually evolved to better support the needs of the MODIS team. We now run multiple instances of the system managing faster than real time reprocessings of the data as well as continuing forward processing. The new OMI Data Processing System (OMIDAPS) was adapted from the MODAPS. It will ingest raw data from the satellite ground station and process it to produce calibrated, geolocated higher level data products. These data products will be transmitted to the Goddard Distributed Active Archive Center (GDAAC) instance of the Earth Observing System (EOS) Data and Information System (EOSDIS) for long term archive and distribution to the public. The OMIDAPS will also provide data distribution to the OMI Science Team for quality assessment, algorithm improvement, calibration, etc. We have taken advantage of lessons learned from the MODIS experience and software already developed for MODIS. We made some changes in the hardware system organization, database and software to adapt the system for OMI. We replaced the fundamental database system, Sybase, with an Open Source RDBMS called PostgreSQL, and based the entire OMIDAPS on a cluster of Linux based commodity computers rather than the large SGI servers that MODAPS uses. Rather than relying on a central I/O server host, the new system distributes its data archive among multiple server hosts in the cluster. OMI is also customizing the graphical user interfaces and reporting structure to more closely meet the needs of the OMI Science Team. Prior to 2003, simulated OMI data and the science algorithms were not ready for production testing. We initially constructed a prototype system and tested using a 25 year dataset of Total Ozone Mapping Spectrometer (TOMS) and Solar Backscatter Ultraviolet Instrument (SBUV) data. This prototype system provided a platform to support the adaptation of the algorithms for OMI, and provided reprocessing of the historical data aiding in its analysis. In a recent reanalysis of the TOMS data, the OMIDAPS processed 108,000 full orbits of data through 4 processing steps per orbit, producing about 800,000 files (400 GiB) of level 2 and greater data files. More recently we have installed two instances of the OMIDAPS for integration and testing of OM1 science processes as they get delivered from the Science Team. A Test instance of the OMIDAPS has also supported a series of "Interface Confidence Tests" (ICTs) and End-to-End Ground System tests to ensure the launch readiness of the system. This paper will discuss the high-level hardware, software, and database organization of the OMIDAPS and how it builds on the MODAPS heritage system. It will also provide an overview of the testing and implementation of the production OMIDAPS.

Tilmes, Curt↗
NASA NTRS2000

PVM Support for Clusters

The latest version of PVM (3.4.3) now contains support for a PC cluster running Linux, also known as a Beowulf system. A PVM user of a computer outside the Beowulf system can add the Beowulf as a single machine.

Beowulf PVM cluster interactive supercomputing↗
NASA NTRS2006

Forecasting of Storm-Surge Floods Using ADCIRC and Optimized DEMs

Increasing the accuracy of storm-surge flood forecasts is essential for improving preparedness for hurricanes and other severe storms and, in particular, for optimizing evacuation scenarios. An interactive database, developed by WorldWinds, Inc., contains atlases of storm-surge flood levels for the Louisiana/Mississippi gulf coast region. These atlases were developed to improve forecasting of flooding along the coastline and estuaries and in adjacent inland areas. Storm-surge heights depend on a complex interaction of several factors, including: storm size, central minimum pressure, forward speed of motion, bottom topography near the point of landfall, astronomical tides, and, most importantly, maximum wind speed. The information in the atlases was generated in over 100 computational simulations, partly by use of a parallel-processing version of the ADvanced CIRCulation (ADCIRC) model. ADCIRC is a nonlinear computational model of hydrodynamics, developed by the U.S. Army Corps of Engineers and the US Navy, as a family of two- and three-dimensional finite-element-based codes. It affords a capability for simulating tidal circulation and storm-surge propagation over very large computational domains, while simultaneously providing high-resolution output in areas of complex shoreline and bathymetry. The ADCIRC finite-element grid for this project covered the Gulf of Mexico and contiguous basins, extending into the deep Atlantic Ocean with progressively higher resolution approaching the study area. The advantage of using ADCIRC over other storm-surge models, such as SLOSH, is that input conditions can include all or part of wind stress, tides, wave stress, and river discharge, which serve to make the model output more accurate. To keep the computational load manageable, this work was conducted using only the wind stress, calculated by using historical data from Hurricane Camille, as the input condition for the model. Hurricane storm-surge simulations were performed on an eight-node Linux computer cluster. Each node contained dual 2-GHz processors, 2GB of memory, and a 40GB hard drive. The digital elevation model (DEM) for this region was specified using a combination of Navy data (over water), NOAA data (for the coastline), and optimized Interferometric Synthetic Aperture Radar data (over land). This high-resolution topographical data of the Mississippi coastal region provided the ADCIRC model with improved input with which to calculate improved storm-surge forecasts.

Valenti, Elizabeth↗
NASA NTRS2014

The Roots of Beowulf

The first Beowulf Linux commodity cluster was constructed at NASA's Goddard Space Flight Center in 1994 and its origins are a part of the folklore of high-end computing. In fact, the conditions within Goddard that brought the idea into being were shaped by rich historical roots, strategic pressures brought on by the ramp up of the Federal High-Performance Computing and Communications Program, growth of the open software movement, microprocessor performance trends, and the vision of key technologists. This multifaceted story is told here for the first time from the point of view of NASA project management.

Beowulf↗
NASA NTRS2009

The Transition of High-Resolution NASA MODIS Sea Surface Temperatures into the WRF Environmental Modeling System

The NASA Short-term Prediction Research and Transition (SPoRT) Center has developed a Moderate Resolution Imaging Spectroradiometer (MODIS) sea surface temperature (SST) composite at 2-km resolution that has been implemented in version 3 of the National Weather Service (NWS) Weather Research and Forecasting (WRF) Environmental Modeling System (EMS). The WRF EMS is a complete, full physics numerical weather prediction package that incorporates dynamical cores from both the Advanced Research WRF (ARW) and the Non-hydrostatic Mesoscale Model (NMM). The installation, configuration, and execution of either the ARW or NMM models is greatly simplified by the WRF EMS to encourage its use by NWS Weather Forecast Offices (WFOs) and the university community. The WRF EMS is easy to run on most Linux workstations and clusters without the need for compilers. Version 3 of the WRF EMS contains the most recent public release of the WRF-NMM and ARW modeling system (version 3 of the ARW is described in Skamarock et al. 2008), the WRF Pre-processing System (WPS) utilities, and the WRF Post-Processing program. The system is developed and maintained by the NWS National Science Operations Officer Science and Training Resource Coordinator. To initialize the WRF EMS with high-resolution MODIS SSTs, SPoRT developed the composite product consisting of MODIS SSTs over oceans and large lakes with the NCEP Real-Time Global (RTG) filling data over land points. Filling the land points is required due to minor inconsistencies between the WRF land-sea mask and that used to generate the MODIS SST composites. This methodology ensures a continuous field that adequately initializes all appropriate arrays in WRF. MODIS composites covering the Gulf of Mexico, western Atlantic Ocean and the Caribbean are generated daily at 0400, 0700, 1600, and 1900 UTC corresponding to overpass times of the NASA Aqua and Terra polar orbiting satellites. The MODIS SST product is output in gridded binary-1 (GRIB-1) data format for a seamless incorporation into WRF via the WPS utilities. The full-resolution, 1-km MODIS product is sub-sampled to 2-km grid spacing due to limitations in handling very large dimensions in the GRIB-1 data format. The GRIB-1 files are posted online at ftp://ftp.nsstc.org/sstcomp/WRF/, which is directly accessed by the WRF EMS scripts. The MODIS SST composites are also downloaded to the EMS data server, which is accessible by the WRF EMS users and NWS WFOs. The SPoRT MODIS SST composite provides the model with superior detail of the ocean gradients around Florida and surrounding waters, whereas the operational RTG SST typically depicts a relatively smooth field and is not able to capture sharp horizontal gradients in SST. Differences of 2-3 C are common over small horizontal distances, leading to enhanced SST gradients on either side of the Gulf Stream and along the edges of the cooler shelf waters. These sharper gradients can in turn produce atmospheric responses in simulated temperature and wind fields as depicted in LaCasse et al. Differences in atmospheric verification statistics over a several month study were generally small in the vicinity of south Florida; however, the validation of SSTs at specific buoy locations revealed important improvements in the biases and RMS errors, especially in the vicinity of the cooler shelf waters off the east-central Florida coast. A current weakness in the MODIS SST product is the occurrence of occasional discontinuities caused by high latency in SST coverage due to persistent cloud cover. An enhanced method developed by Jedlovec et al. (2009, GHRSST User Symposium) reduces the occurrence of these problems by adding Advanced Microwave Scanning Radiometer -- EOS (AMSR-E) SST data to the compositing process. Enhanced SST composites are produced over the ocean regions surrounding the Continental U.S. at four times each day corresponding to Terra and Aqua equator crossing times. For a given day and overpass time, both MODInd AMSR-E data from the previous seven days form a collection used in the compositing. At each MODIS pixel, cloud-free SST values from the collection are used to form a weighted average based on their latency (number of days from the current day). In this way, recent SST data are given more weight than older data. One of the primary issues involved in incorporating the AMSR-E microwave data in the composites is the tradeoff between the decreased spatial resolution of the AMSR-E data (25 km) and the increased coverage due to its near all-weather capability. Currently, the AMSR-E is given a weight of 20% compared to MODIS data, thereby preserving the spatial structure observed in the MODIS data. Day-time (night-time) AMSR-E SST data from Aqua are used with both Terra and Aqua MODIS day-time (night-time) SST data sets.

Case, Jonathan L.↗
NASA NTRS2000

Implementing Journaling in a Linux Shared Disk File System

In computer systems today, speed and responsiveness is often determined by network and storage subsystem performance. Faster, more scalable networking interfaces like Fibre Channel and Gigabit Ethernet provide the scaffolding from which higher performance computer systems implementations may be constructed, but new thinking is required about how machines interact with network-enabled storage devices. In this paper we describe how we implemented journaling in the Global File System (GFS), a shared-disk, cluster file system for Linux. Our previous three papers on GFS at the Mass Storage Symposium discussed our first three GFS implementations, their performance, and the lessons learned. Our fourth paper describes, appropriately enough, the evolution of GFS version 3 to version 4, which supports journaling and recovery from client failures. In addition, GFS scalability tests extending to 8 machines accessing 8 4-disk enclosures were conducted: these tests showed good scaling. We describe the GFS cluster infrastructure, which is necessary for proper recovery from machine and disk failures in a collection of machines sharing disks using GFS. Finally, we discuss the suitability of Linux for handling the big data requirements of supercomputing centers.

Preslan, Kenneth W.↗
NASA NTRS2001

Efficiency of parallel direct optimization

Tremendous progress has been made at the level of sequential computation in phylogenetics. However, little attention has been paid to parallel computation. Parallel computing is particularly suited to phylogenetics because of the many ways large computational problems can be broken into parts that can be analyzed concurrently. In this paper, we investigate the scaling factors and efficiency of random addition and tree refinement strategies using the direct optimization software, POY, on a small (10 slave processors) and a large (256 slave processors) cluster of networked PCs running LINUX. These algorithms were tested on several data sets composed of DNA and morphology ranging from 40 to 500 taxa. Various algorithms in POY show fundamentally different properties within and between clusters. All algorithms are efficient on the small cluster for the 40-taxon data set. On the large cluster, multibuilding exhibits excellent parallel efficiency, whereas parallel building is inefficient. These results are independent of data set size. Branch swapping in parallel shows excellent speed-up for 16 slave processors on the large cluster. However, there is no appreciable speed-up for branch swapping with the further addition of slave processors (>16). This result is independent of data set size. Ratcheting in parallel is efficient with the addition of up to 32 processors in the large cluster. This result is independent of data set size. c2001 The Willi Hennig Society.

NASA Discipline Evolutionary Biology↗
NASA NTRS2009

DSN Beowulf Cluster-Based VLBI Correlator

The NASA Deep Space Network (DSN) requires a broadband VLBI (very long baseline interferometry) correlator to process data routinely taken as part of the VLBI source Catalogue Maintenance and Enhancement task (CAT M&E) and the Time and Earth Motion Precision Observations task (TEMPO). The data provided by these measurements are a crucial ingredient in the formation of precision deep-space navigation models. In addition, a VLBI correlator is needed to provide support for other VLBI related activities for both internal and external customers. The JPL VLBI Correlator (JVC) was designed, developed, and delivered to the DSN as a successor to the legacy Block II Correlator. The JVC is a full-capability VLBI correlator that uses software processes running on multiple computers to cross-correlate two-antenna broadband noise data. Components of this new system (see Figure 1) consist of Linux PCs integrated into a Beowulf Cluster, an existing Mark5 data storage system, a RAID array, an existing software correlator package (SoftC) originally developed for Delta DOR Navigation processing, and various custom- developed software processes and scripts. Parallel processing on the JVC is achieved by assigning slave nodes of the Beowulf cluster to process separate scans in parallel until all scans have been processed. Due to the single stream sequential playback of the Mark5 data, some ramp-up time is required before all nodes can have access to required scan data. Core functions of each processing step are accomplished using optimized C programs. The coordination and execution of these programs across the cluster is accomplished using Pearl scripts, PostgreSQL commands, and a handful of miscellaneous system utilities. Mark5 data modules are loaded on Mark5 Data systems playback units, one per station. Data processing is started when the operator scans the Mark5 systems and runs a script that reads various configuration files and then creates an experiment-dependent status database used to delegate parallel tasks between nodes and storage areas (see Figure 2). This script forks into three processes: extract, translate, and correlate. Each of these processes iterates on available scan data and updates the status database as the work for each scan is completed. The extract process coordinates and monitors the transfer of data from each of the Mark5s to the Beowulf RAID storage systems. The translate process monitors and executes the data conversion processes on available scan files, and writes the translated files to the slave nodes. The correlate process monitors the execution of SoftC correlation processes on the slave nodes for scans that have completed translation. A comparison of the JVC and the legacy Block II correlator outputs reveals they are well within a formal error, and that the data are comparable with respect to their use in flight navigation. The processing speed of the JVC is improved over the Block II correlator by a factor of 4, largely due to the elimination of the reel-to-reel tape drives used in the Block II correlator.

Rogstad, Stephen P.↗
NASA NTRS2005

A Parallel Processing Algorithm for Remote Sensing Classification

A current thread in parallel computation is the use of cluster computers created by networking a few to thousands of commodity general-purpose workstation-level commuters using the Linux operating system. For example on the Medusa cluster at NASA/GSFC, this provides for super computing performance, 130 G(sub flops) (Linpack Benchmark) at moderate cost, $370K. However, to be useful for scientific computing in the area of Earth science, issues of ease of programming, access to existing scientific libraries, and portability of existing code need to be considered. In this paper, I address these issues in the context of tools for rendering earth science remote sensing data into useful products. In particular, I focus on a problem that can be decomposed into a set of independent tasks, which on a serial computer would be performed sequentially, but with a cluster computer can be performed in parallel, giving an obvious speedup. To make the ideas concrete, I consider the problem of classifying hyperspectral imagery where some ground truth is available to train the classifier. In particular I will use the Support Vector Machine (SVM) approach as applied to hyperspectral imagery. The approach will be to introduce notions about parallel computation and then to restrict the development to the SVM problem. Pseudocode (an outline of the computation) will be described and then details specific to the implementation will be given. Then timing results will be reported to show what speedups are possible using parallel computation. The paper will close with a discussion of the results.

Gualtieri, J. Anthony↗
NASA NTRS2006

PVM Enhancement for Beowulf Multiple-Processor Nodes

A recent version of the Parallel Virtual Machine (PVM) computer program has been enhanced to enable use of multiple processors in a single node of a Beowulf system (a cluster of personal computers that runs the Linux operating system). A previous version of PVM had been enhanced by addition of a software port, denoted BEOLIN, that enables the incorporation of a Beowulf system into a larger parallel processing system administered by PVM, as though the Beowulf system were a single computer in the larger system. BEOLIN spawns tasks on (that is, automatically assigns tasks to) individual nodes within the cluster. However, BEOLIN does not enable the use of multiple processors in a single node. The present enhancement adds support for a parameter in the PVM command line that enables the user to specify which Internet Protocol host address the code should use in communicating with other Beowulf nodes. This enhancement also provides for the case in which each node in a Beowulf system contains multiple processors. In this case, by making multiple references to a single node, the user can cause the software to spawn multiple tasks on the multiple processors in that node.

Springer, Paul↗
NASA NTRS2000

Level 1 Processing of MODIS Direct Broadcast Data From Terra

In February 2000, an effort was begun to adapt the Moderate Resolution Imaging Spectroradiometer (MODIS) Level 1 production software to process direct broadcast data. Three Level 1 algorithms have been adapted and packaged for release: Level 1A converts raw (level 0) data into Hierarchical Data Format (HDF), unpacking packets into scans; Geolocation computes geographic information for the data points in the Level 1A; and the Level 1B computes geolocated, calibrated radiances from the Level 1A and Geolocation products. One useful aspect of adapting the production software is the ability to incorporate enhancements contributed by the MODIS Science Team. We have therefore tried to limit changes to the software. However, in order to process the data immediately on receipt, we have taken advantage of a branch in the geolocation software that reads orbit and altitude information from the packets themselves, rather than external ancillary files used in standard production. We have also verified that the algorithms can be run with smaller time increments (2.5 minutes) than the five-minute increments used in production. To make the code easier to build and run, we have simplified directories and build scripts. Also, dependencies on a commercial numerics library have been replaced by public domain software. A version of the adapted code has been released for Silicon Graphics machines running lrix. Perhaps owing to its origin in production, the software is rather CPU-intensive. Consequently, a port to Linux is underway, followed by a version to run on PC clusters, with an eventual goal of running in near-real-time (i.e., process a ten-minute pass in ten minutes).

Lynnes, Christopher↗
NASA NTRS2001

Level 1 Processing of MODIS Direct Broadcast Data at the GSFC DAAC

The GSFC DAAC is working to test and package the MODIS Level 1 Processing software for Aqua Direct Broadcast data. This entails the same code base, but different lookup tables for Aqua and Terra. However, the most significant change is the use of ancillary attitude and ephemeris files instead of orbit/attitude information within the science data stream (as with Terra). In addition, we are working on Linux: ports of the algorithms, which could eventually enable processing on PC clusters. Finally, the GSFC DAAC is also working with the GSFC Direct Readout laboratory to ingest Level 0 data from the GSFC DB antenna into the main DAAC, enabling level 1 production in near real time in support of applications users, such as the Synergy project. The mechanism developed for this could conceivably be extended to other participating stations.

Lynnes, Christopher↗