From furbish@quartz.gly.fsu.edu Mon Jun 18 15:59:08 2007 Return-Path: Delivered-To: fox@csit.fsu.edu Received: from quartz.gly.fsu.edu (quartz.gly.fsu.edu [128.186.10.36]) by mailer.csit.fsu.edu (Postfix) with ESMTP id AD7E723A09 for ; Mon, 23 Apr 2001 23:23:51 -0400 (EDT) Received: from dfurbish (dial578.acns.fsu.edu [146.201.34.71]) by quartz.gly.fsu.edu (8.10.2/8.10.2) with SMTP id f3O3KT150276 for ; Mon, 23 Apr 2001 23:20:30 -0400 (EDT) Message-ID: <003d01c0cc6e$b3748280$2b20c992@dfurbish> From: "David Jon Furbish" To: "Geoffrey Fox" References: <200104240305.XAA110902@dirac.csit.fsu.edu> Subject: Re: Prior NSF support Date: Mon, 23 Apr 2001 23:28:58 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C0CC4D.2BCBD2A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: furbish@quartz.gly.fsu.edu This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C0CC4D.2BCBD2A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks...!!! (incidently, the Access Grid setup is very cool...!) = David ----- Original Message -----=20 From: Geoffrey Fox=20 To: David Jon Furbish=20 Sent: Monday, April 23, 2001 11:05 PM Subject: Re: Prior NSF support=20 will do I am trying to find it! =20 Geoffrey Fox gcf@cs.fsu.edu or fox@csit.fsu.edu Phones Cell 315-254-6387 FSU Office 850-644-4587 FAX 850-644-0098 ------=_NextPart_000_003A_01C0CC4D.2BCBD2A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks...!!!  (incidently, the = Access Grid=20 setup is very cool...!)  David
----- Original Message -----
From:=20 Geoffrey Fox
Sent: Monday, April 23, 2001 = 11:05=20 PM
Subject: Re: Prior NSF support =

will do
I am trying to find = it!
 
 Geoffrey=20 Fox  gcf@cs.fsu.edu or fox@csit.fsu.edu
 Phones = Cell=20 315-254-6387 FSU Office 850-644-4587 FAX=20 850-644-0098
------=_NextPart_000_003A_01C0CC4D.2BCBD2A0-- From nobody@nowhere Mon Jun 18 15:59:08 2007 Replied: Mon, 23 Apr 2001 23:05:31 -0400 Replied: "David Jon Furbish" Return-Path: furbish@quartz.gly.fsu.edu Return-Path: Delivered-To: fox@csit.fsu.edu Received: from quartz.gly.fsu.edu (quartz.gly.fsu.edu [128.186.10.36]) by mailer.csit.fsu.edu (Postfix) with ESMTP id D0A8123A09 for ; Mon, 23 Apr 2001 22:47:20 -0400 (EDT) Received: from dfurbish (dial578.acns.fsu.edu [146.201.34.71]) by quartz.gly.fsu.edu (8.10.2/8.10.2) with SMTP id f3O2hx150109 for ; Mon, 23 Apr 2001 22:43:59 -0400 (EDT) Message-ID: <002d01c0cc69$99c17a00$2b20c992@dfurbish> From: "David Jon Furbish" To: Subject: Prior NSF support Date: Mon, 23 Apr 2001 22:52:27 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C0CC48.1221F1E0" X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: furbish@quartz.gly.fsu.edu This is a multi-part message in MIME format. ------=_NextPart_000_002A_01C0CC48.1221F1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Geoffrey: I hope that you can send your statement (one page or less) of prior NSF = support to me soon for the ITR proposal (due tomorrow)... PI/Co-PI = names, title, amount, duration, summary of results, resulting = publications. Thanks...! David ------=_NextPart_000_002A_01C0CC48.1221F1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello, Geoffrey:
 
I hope that you can send your statement = (one page=20 or less) of prior NSF support to me soon for the ITR proposal (due=20 tomorrow)...  PI/Co-PI names, title, amount, duration, summary = of=20 results, resulting publications.
 
Thanks...!
 
David
 
------=_NextPart_000_002A_01C0CC48.1221F1E0-- From furbish@quartz.gly.fsu.edu Mon Jun 18 15:59:08 2007 Return-Path: Delivered-To: fox@csit.fsu.edu Received: from quartz.gly.fsu.edu (quartz.gly.fsu.edu [128.186.10.36]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 5D9D423A13 for ; Tue, 24 Apr 2001 12:18:11 -0400 (EDT) Received: from pcb.gly.fsu.edu (pcb.gly.fsu.edu [128.186.10.4]) by quartz.gly.fsu.edu (8.10.2/8.10.2) with SMTP id f3OGEn154737 for ; Tue, 24 Apr 2001 12:14:49 -0400 (EDT) Message-ID: <009301c0ccda$b14faea0$040aba80@gly.fsu.edu> From: "David Jon Furbish" To: References: <002d01c0cc69$99c17a00$2b20c992@dfurbish> <3AE5CBC9.9010302@csit.fsu.edu> Subject: Re: Prior NSF support Date: Tue, 24 Apr 2001 12:22:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: furbish@quartz.gly.fsu.edu Geoffrey... Thank you...!!!! It looks great... David ----- Original Message ----- From: "Geoffrey Fox" To: "David Jon Furbish" Sent: Tuesday, April 24, 2001 2:54 PM Subject: Re: Prior NSF support > > I am sorry. I just found last NSF proposal I wrote which has prior work discussion > updated from what you have > I have been swamped with stuff and enclose proposal -- end of this is > what you want > ---------------------------------------------------------------------------- ---- > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % > %% Integration of High Performance Message-based Programming Environments > %% with distributed objects and the Web [working title] > %%%%% for NSF/ITR > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % > \chapter{Project Description} > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % > > > \section{Introduction} > > This proposal is concerned with enabling parallel, high-performance > computation in a world rife with Internet technologies. > Parallel computations may or may not be distributed {\em > across} the Internet, but in any case we assume the commodity > hardware and software technologies that will be most important in > the immediate future will be fine-tuned for the Internet environment. > These technologies will include massively parallel engines designed and > deployed as Internet servers, and software developed in network-aware > programming languages like Java---software engineered to survive in > heterogeneous and very dynamic environments. > > Partly through the activities of the {\em Java Grande Forum} > \cite{JavaGrande} (and, we expect, the newly formed > {\em Jini Activity Group} of the Global Grid Forum) > the prospect of using Java for essentially > ``scientific'' computing has has become increasingly realistic. Work > in industrial and academic sectors on optimizing compilers, JITs, > language enhancements and libraries have made it increasingly likely > that future Java environments will meet the performance constraints for > large-scale computations and simulations. The work on improving the > performance of Java is driven largely by its industrial application as > a programming language for high-performance Internet servers, but we > assume scientific programmers may also reap the benefits. > > The proposed work will further develop ongoing research by the current > authors into application of Java for parallel computing. Our {\em > HPJava} system is based around a small set of language extensions > designed to support parallel computation with distributed arrays. This > work received funding from an earlier NSF grant (see Section > \ref{sec:hpjava}). While the ongoing work emphasizes use of > language extensions and translators to provide a high-level programming > environment---assuming a native interface to a underlying, conventional > parallel programming environment---the proposed work will particularly > address uses of Java in the implementation of the {\em underlying} > environment. > > An influential development in parallel computing > was the publication in 1994 of the Message Passing Interface > (MPI) standard \cite{MPIStandard}. > MPI supports the Single Program Multiple Data > (SPMD) model of parallel computing, providing many modes of reliable > point-to-point communication, and a library of collective operations. > The MPI standards specify bindings for Fortran, C and C++. > But none of these languages is especially adapted to the Internet, where > code is often loaded dynamically across the network, resources > are frequently discovered and lost spontaneously, and fault tolerance > is a crucial issue. > > In the proposed work we will be concerned with using > network-oriented languages and in particular Java for high-performance > computing. One preoccupation is with refinement of > MPI-like programming models and APIs for high performance programming > in Java---researching ways to get the fastest message passing from > Java, and ways to exploit novel Java technologies like Jini (a Java > architecture for making services available over a network) to produce > richer message-passing environments. A complementary concern is with > use of Jini in a middle tier between client and MPI-based parallel > services. > > Java introduces implementation issues for message-passing APIs that do > not occur in conventional programming languages. One area of > research is how to transfer data between the Java program and the network > while reducing overheads of the Java Native Interface. We will > investigate how to apply ideas from projects like Jaguar \cite{Welsh99A} > and JaVIA \cite{Chang99} to MPI-like APIs. Another important issue is how > to minimize the overheads of serialization in communicating Java objects > and multidimensional arrays. We hope to integrate ideas on efficient object > serialization from the KaRMI project \cite{Nester99}, for example, > with MPI-specific ideas we started to explore in \cite{Carpenter99}. > We will be especially interested in supporting efficient communication > of scientific array objects like those supported by the Java Grande Numerics > Working Group. > > The programming model must address features specific to > distributed computing. To support computing in volatile Internet-oriented > environments, we will need features like dynamic > harnessing of process groups and parallel client/server interfaces. > These are features that the MPI Forum started to address in the MPI 2 > standard, but implementations in conventional parallel programming > environments have been slow to arrive. A > natural framework for dynamically discovering new compute resources and > establishing connections between running programs already exists in > Sun's Jini project. > > In the proposed work, an important emphasis will > be on researching synergies between parallel message-passing > programming and Jini-like systems. One defining characteristic of > distributed computing is the presence of {\em partial failures}. By > combining ideas from MPI with ideas from Jini we hope to facilitate an > environment that encourages scalable and fault-tolerant > parallel computing. > > > \section{Background and Motivations} > > \subsection{High-Performance computing and Java} > > We believe that Parallel computing must adapt itself to the Internet > environment, and embrace current Internet technologies. Many people > accept that the Java language is likely to continue its important role > in Internet software, but the idea that it should also be adopted as an > important language for large-scale technical computations still meets > some resistance. Over the last few years supporters of the {\em Java > Grande Forum} have been working actively to address some of the > difficulties. The goal of the forum has been to develop consensus on > enhancements to the Java language and platform to support large-scale > (``Grande'') applications. Through a series of workshops and > conferences \cite{Java_for_CSE,Java_for_CSE_II,Java98,Java99,Java00} > the forum has helped stimulate research on Java systems and > applications. > > Associated developments have helped establish the case that Java can > meet the vital performance constraints for numerically intensive > computing. A series of papers from IBM > \cite{Moreira98A,Moreira98B,Wu99}, for example, demonstrated how to > apply aggressive optimizations in Java compilers to obtain performance > competitive with Fortran. In a recent paper \cite{Moreira99} they > described a case study involving a data mining application that used > the Java Array package supported by the Java Grande Numerics Working > Group. Using the experimental IBM HPCJ Java compiler they reported > obtaining over 90\% of the performance of Fortran. > > The Java Grande Forum has a Concurrency and Applications Working > Group. This group has been looking directly at uses of Java in parallel > and distributed computing. We will refer to some of this work below. > > \subsection{Niches for parallel Java programs} > > Computers that host major Web sites will either be multiprocessors or > clusters of workstations. We already see this today, and the trend > will presumably continue. Since Java and parallel computers will > coexist in Internet servers, this is one place we expect to see roles > for Java-based parallel computation emerging. We may, for example, see > compute-intensive services appearing on the Web---perhaps supporting > data-mining queries that use parallel algorithms or financial analysis > programs involving complex simulations. > > Truly scalable servers are likely to be clusters rather than > symmetric multiprocessors. As a specific > example, consider the {\em Ninja} vision of the future of the Internet > elaborated by researchers at UC Berkeley \cite{Ninja}. In their view a > service should be {\em scalable} (able to support thousands of concurrent > users), {\em fault-tolerant}, and highly-available. > While a major concern is with mobile > code for service deployment, eventually services must maintain persistent > state. In the Ninja model this is held in a controlled environment > engineered to provide high availability and scalability---namely > a cluster of workstations \cite{Gribble99}. > This {\em Base} is not necessarily homogeneous and it is not completely > ``reliable'', so it is not exactly a conventional parallel computer. But > this is an environment where we might expect message-passing parallel > programs written in Java to find a natural home. > > A completely different place where we might see early uptake of Java-based > parallel computing is in the classroom. Java has become an important > teaching language in Universities. For teaching parallel computing > principles to students, Java is likely to be a more attractive language > than Fortran. For example, our {\em mpiJava} software \cite{mpiJava} > has been downloaded by about 500 people. On the basis of project > descriptions given when people download the software we estimated that > perhaps 10\% of potential users are teachers looking for classroom > software. This is a not a dominant proportion, but it is an > influential one so far as future uptake is concerned. In this context > highly tuned implementations are not essential. A pure Java MPI-like > package that is portable and can be installed easily on available > networks of PCs is probably ideal. > > Finally, because of its platform independence, mobility, and > other associations with the Internet, Java is a natural candidate as a > language for {\em metacomputing}. We interpret this to mean computation > by parallel programs distributed across the Internet itself. Within the > MPI community there is an ongoing effort to extend MPI specifications and > implementations to support metacomputing, by allowing logical process > groups to span geographically separated clusters and supercomputers > \cite{IMPI}. > Java-based metacomputing can exploit and supplement these ongoing > MPI activities in natural ways. > Many authors have discussed Java approaches to metacomputing. > Charlotte > \cite{Baratloo96,Baratloo98} and Javelin \cite{Neary99,Christiansen97} > concentrate on harvesting cycles of computers running Web browsers by > downloading {\em applets} to them. JavaParty > \cite{Philippsen97,Nester99} and Manta \cite{Nieuwpoort99} support an > interacting SPMD style of distributed programming, but emphasize > communication through {\em remote method invocation} (RMI). This work is > clearly important, but our interest leans towards more tightly coupled > parallel environments, and in fact metacomputing will not be a {\em > primary} focus of the work proposed here. In more tightly cooupled > environments it is more questionable whether remote method invocation > is the best model of communication within a running parallel program. > The message-passing model of synchronization seems a better fit to the > requirements. > > While remote method invocation may not be the best model for > communication within an {\em executing} parallel program, we assume that > RMI-based technologies can play a natural role at the level of > {\em coordinating} computational resources for execution---discovering, > monitoring and recovering those resources. The harmonious integration > of message-passing models for parallel computing with remote object > models at some outer level is an important theme in the proposed work. > > \subsection{Jini} > > \label{sec:jini} > > Jini is Sun's Java architecture for making services available over > a network. It is built on top of the Java Remote Method Invocation > (RMI) mechanism. The main additional features are a set of protocols > and basic services for ``spontaneous'' discovery of new services, and > a framework for detecting and handling {\em partial failures} in the > distributed environment. > > A Jini lookup service is typically discovered through multicast on a > well-known port. The discovered registry is a unified first point of > contact for all kinds of device, service, and client on the network. > This model of discovery and lookup is somewhat distinct from the more global > concept of discovery in, say, the CORBA trading services or HP's > e-speak \cite{HP99}. The Jini version is a lightweight protocol, especially > suitable for initial binding of clients and services within multicast > range. In the Ninja outlook, for example, Jini technology might fit > comfortably at the periphery, near the end-user devices, or {\em within} > the Base, addressing initial federation of nodes, crashes of individual > nodes, etc. The latter the kind of environment that especially interests us. > > The ideas of Jini run deeper than the lookup services. Jini completes a > vision of {\em distributed programming} started by RMI. In this vision > {\em partial failure} is a defining characteristic, distinguishing > distributed programming from the textbook discipline of concurrent > programming \cite{NoteDistributed}. > So in Jini remote objects and RMI replace ordinary > Java objects and methods; garbage collection for recovery of memory is > replaced by a {\em leasing} model for recovery of distributed resources; > the events of, say, AWT or JavaBeans are replaced by the distributed events > of Jini. Finally, the synchronized methods of Java are mirrored in the nested > transactions of the Jini model. Concurrent programming is not an identical > discipline to scalable parallel programming, but we need analogous > sets of abstractions for the parallel case. > > We are not alone in recognizing the potential of Jini for > coordinating resources in the context of large-scale computations. > Very recently a Jini Activity Group has been formed under the > umbrella of the Global Grid Forum \cite{GridForum}. This group > will investigate ways in which the Jini philosophy and technology can > be used as an infrastructure with Grid environments \cite{JiniGrid}, > especially for supporting resource and service discovery. We plan to > be actively involved in the workings of that group. > > While a proposal of this nature should not focus exclusively > on a proprietary (though open) technology like Jini, > it seems likely that we can exploit Jini and related systems to > create improved parallel computing environments, especially for Java. > > \subsection{Lessons} > > To support the parallel programmers of the future we believe we need Java > implementations of lightweight messaging systems akin to MPI---perhaps > the most successful platform developed for parallel computing. A likely > physical setting is in the more or less tightly coupled (but probably > heterogeneous, multi-user) clusters of trusted workstations that > will host the Web services of the future. While models of > distributed programming other than message-passing (including Linda-based > models like JavaSpaces or JavaNOW) certainly have a role, > experience with earlier generations of parallel computer > suggests that the low-latency message-passing model is a good fit > to requirements. > > But these are likely to be volatile environments that demand the > reliability provided by foundations like Java and Jini. The software > must be adaptive. Availability changes as workloads and network > traffic fluctuates---old nodes crash, new ones are attached and > discovered on the fly. Jini is a leading candidate for dealing with > these situations, and we expect it can play an important role in > implementing parallel-programming systems for these new environments. > > \section{Goals of the Proposed Work} > > There are three related strands in the proposed work. One strand will > investigate use of Java and especially {\em Jini} technologies in > a middle tier for initiating parallel MPI jobs. For definiteness we > refer to the architecture as {\em JiniMPI}. So far as the architecture > itself is concerned the parallel program could be written in Java or some > other language that invokes an MPI-style message layer. A second > activity will investigate implementation-level issues related > to developing high-performance message-passing systems > {\em in} Java (and potentially other object-oriented network > programming languages). We need to know how to efficiently > implement associated APIs in dynamic environments like > Internet servers and networks. The specific APIs will be derivatives of > the {\em MPJ} specifications from the Java Grande Message-Passing Working > Group (section \ref{sec:JGMPWG}). A third strand will continue > development of our {\em HPJava} system. HPJava is a relatively high-level > environment for parallel computing in Java. In the new work, we would > plan, in particular, to adapt the run-time system of the existing HPJava > software to work in the Java environments discussed above. Besides its > intrinsic value, this exercise will stress-test the new, underlying, > pure-Java layers that we propose. > > In principle the three levels, {\em JiniMPI}, {\em MPJ}, and {\em HPJava}, > are independent, but they complement each other and are expected to be > especially powerful when used together. > > \subsection{Jini-based middle tiers for parallel programming} > > \begin{figure}[tp] > \centerline{\psfig{figure=JiniMPI.ps,width=5.5in}} > \caption{JiniMPI Architecture\label{fig:JiniMPI}} > \end{figure} > > The envisaged JiniMPI architecture is illustrated in Figure > \ref{fig:JiniMPI}. The architecture supports MPI-based parallel computing. > It also includes ideas from systems like Condor and Javelin. > Our diagram only shows the server layer (bottom) and the service layer (top). > There would also a client layer that communicates directly with the ``Control > and Services'' module. > > Each workstation has a {\em Jini Parallel Computing > Embryo}---a Jini service that registers the availability of > the workstation to run applications. > The Jini embryo is the representative of the machine---advertising its > availability to run general applications or particular software. The > {\em Gateway}, or {\em Control and Services module} \cite{Akarsu99}, > queries the Jini lookup services to find appropriate computers to run a > particular MPI job. The mechanism could be used just to be run a > single job, or to set up a farm of independent workers > > The Gateway receives a proxy for each embryo it selects from the lookup > services in the usual Jini way. Once an initial RMI link is > established from the Gateway to each SPMD node, Java proxies are > created in turn for the individual node programs. The node programs > themselves can be written any language (Java, Fortran, C++ etc). > Acting on behalf of the client, the Gateway-Embryo negotiations will > also supply the Gateway with any additional data needed (e.g., > specification of required parameters for the job and how to input > them). An important theme is the separation of {\em control} from {\em > data transfer}. In the ``control layer'' we have Jini services > (registration, lookup and invocation), other services such as load > balancing, and fault recovery. In a ``fast transport layer'' we have > MPI style data messages. The Jini embryo is used to initiate (and > perhaps monitor) the process. It takes only a backseat role in the > actual execution of the parallel program. > > We will also investigate the implications of using a JavaSpace in the > control layer as the basis for a management environment. Note this is very > different from using Linda or JavaSpaces at the execution level, and > performance problems are not likely to be a primary concern. > > The proposals here would build on research in the ongoing {\em Gateway > project} \cite{Gateway}. This is an effort to build computational web > portals that allow users to access high performance computing > facilities via web browsers like Netscape and Internet Explorer. The > goal of Gateway is to provide a high level user interface that > simplifies access to various computing resources maintained by > computing centers with varying access and security policies. Gateway > provides a commodity-based solution to these problems, taking advantage > of the investment of the commercial sector into such technologies and > standards as CORBA, XML, and Java. > > \subsection{Research on high-performance message passing > models for Java} > > In the early stages of the project we will complete a reference > implementation of the {\em MPJ} specification, an MPI-inspired Java > API from the Java Grande Message-Passing Working Group (section > \ref{sec:JGMPWG}). Our existing {\em mpiJava} software (section > \ref{sec:mpiJava}) has been one basis for this work, but for further > research a portable, {\em pure Java} version will be needed. Section > \ref{sec:MPJ-RI} describes a design. One of the conclusions of the > design study was that difficult issues of reliability (and useability) > in a network environment are naturally addressed in the framework of > the Jini programming model. An initial reference implementation is > likely to make extensive use of Jini for job initiation and handling > failures. This implementation will be a foundation for subsequent > research in the project. > > The current MPJ specification supports essentially MPI-1.0 functionality, > with some extensions specific to object-oriented languages (for example > it has the facility to send and receive arbitrary serializable objects). > With the reference implementation in place, the project will > follow two directions > \begin{itemize} > \item > Research into optimizations specific to the language and network context, > to improve bandwidth and latency. > \item > Design and pilot implementation of extensions to the basic message-passing > model, improving support for highly dynamic environments. > \end{itemize} > Associated tasks are detailed in the following two subsections. > > \subsubsection{Fast message-passing for Java} > > An initial reference implementation will probably use Java sockets as the basic > transport. But research is needed into different approaches to low-level > transport---for example calling native MPI by standard JNI or other > methods, or using Java bindings to lower-level interfaces like VIA. > It is also likely to involve work on improving the efficiency of object > serialization, or exploiting the research of other groups on efficient > object serialization. > > Our earlier work on mpiJava already exploited the Java Native Interface > (JNI) to call native MPI implementations. But there are concerns with > the efficiency of crossing the JNI barrier. Detailed criticisms of > JNI can be found in \cite{Welsh99A} and \cite{Chang99}. The two groups > involved have described ways to go beyond standard JNI, specifically to > support efficient Java interfaces to VIA. Our research would attempt > to leverage this work, either by adapting similar techniques to make > low-overhead interfaces to native MPI, or (for suitable platforms) > adopting Java VIA interfaces as a low-level transport in our Java > implementation of the message-passing API (along lines comparable with > \cite{Dimitrov99}). Note that the new approaches often assume > limited changes to compiler or JVM, at least in the garbage collector. > > Another area that needs further research is specific to object-oriented > languages. To allow fast communication of {\em object graphs} between > processors we need very efficient object serialization. Important work > on improving Java serialization has been described in > \cite{Nester99}. The authors report that their UKA-Serialization can save > 76\% to 96\% of the time needed to serialize objects. Their work was > done in the context of an optimized reimplementation of RMI, but we can > use the same software in fast MPJ implementations. We may hope to combine > ideas from UKA-Serialization with the MPI-specific ideas we started to > explore in \cite{Carpenter99}, to facilitate fast communication of objects > in MPJ. For technical computation an especially pressing concern is > the case of multidimensional arrays ({\em one}-dimensional arrays can > often be communicated without expensive serialization). > > %{\em Multidimensional arrays.} > > \subsubsection{Extending the MPJ message-passing model} > > As noted above, an initial MPJ draft specifies functionality similar > to MPI 1.1, complemented by some object-oriented features. > > One set of extensions to this draft will be inspired by features of > the MPI 2 standard. This standard is not yet widely implemented > even for traditional languages, but it includes features that are > likely to be important in the volatile Java environments we target. > Dynamic process creation was not part of MPI 1 but it is > undoubtedly important for our environments. An early addition to the > baseline MPJ model will be operations similar to those in > MPI 2 start new groups of processes > and return intercommunicators connecting them to the inital group. > A new feature in our research will be adoption of Jini (or similar > technologies) for discovery of the required computational resources. > Another relevant feature of the MPI 2 specification is > its introduction of a parallel client/server model, by which two > running {\em parallel} programs (client and server) > can establish a connection, and thus operate > collectively for some period. > MPI 2 proposes fairly limited functionality here, and it seems that a > Java environment ought to be able to offer more flexible mechanisms > modelled on Jini lookup. > > Dynamic discovery of compute resources is one area where Jini-like ideas > can help us. A more difficult issue for scalable computing in networked > environments is how to deal with dynamic {\em loss} of resources, due to > a failure somewhere in the distributed platform. As emphasized in Section > \ref{sec:jini}, the general Jini framework incorporates various mechanisms > designed to support programming in the presence of partial failure. > One goal of our research will be to explore ways to incorporate similar > concepts in the parallel message-passing context, encouraging programs > that are truly scalable even in the presence of partial failure. > For example, it may be that a scalable version of the Jini {\em > transaction} model is ideal to support checkpointing of running > parallel programs. This is a more speculative area, but the goal would > be isolate a Jini-like kernel of key concepts for fault recovery in > SPMD parallel programs. Most likely these would be applied at the > level of large, collective operations, such as global checkpointing, > forking groups of slave processes for some subtask, and so on. > > \subsection{Continued development of the {\em HPJava} environment} > > A starting point for much of the work proposed here is our ongoing > HPJava project\cite{HPJava}. The HPJava system involves a translator > for an extended Java language with support for parallel programming > with distributed arrays, and a ``run-time system'' which is a library > of collective operations implemented on top of MPI. > > The proposed work would include some further development of the > HPJava translation system; we would be particularly interested in > moving the underlying run-time system to operate on top of the portable > pure-Java environments described in the previous subsections. > > One reason this is important is that supporting the higher level > HPJava distributed array communication model will give us a concrete > application of the lower-level APIs, and in particular it will > exercise the parts of the message-passing API that are concerned > with communication of {\em arrays}. We consider this to be a basic > issue for technical computing, and one that has not been addressed > in a fully satisfactory way by some earlier proposals. > > \subsection{A three year workplan} > > \paragraph{Year one:} > In the first year we will complete ongoing work on a Jini-based pure Java > implementation of MPJ---a message-passing environment with functionality > similar to MPI 1.1. This implementation will be an important foundation > for the subsequent research in the project. To support the later > research, the transport layer must be easily replacable (similar to KaRMI, > for example). This implies a layer analogous to the MPICH > device level, but we will need new features to support Java and objects. > Jini will be used for discovering compute hosts and (importantly) to > ensure clean global termination in the event of failures. To prove the > design, a native MPI-based implementation of the transport layer will > also be implemented. This will complement the initial socket-based > implementation, and will use standard JNI. (Our existing {\em mpiJava} > software will probably be phased out.) In this year we will also be > studying issues relating to concrete design of the JiniMPI Architecture, > using Jini technologies as a gateway to parallel computing resources. > > \paragraph{Year two:} > The basic message passing model will be extended with a version of > dynamic process spawning using Jini to find resources, and a parallel > client/server model, using Jini to establish connections between running > parallel programs. Suitable Java-centric APIs will be designed. > Relevant application codes from areas like parallel data-mining will > be produced. > We will study ideas following on from the Jaguar and JAVIA work at > Berkeley and Cornell, and try to make use of those ideas to optimize > our initial MPJ implementation, the goal being to develop genuine > high-bandwidth, low-latency message-passing in Java. We will integrate > UKA-serialization or successors, and further study MPI-specific > improvements for important cases such as multidimensional arrays. > Extensions needed to support efficient communication of the scientific > Array classes supported by Java Grande will be a prioriy. Pilot > implementations of JiniMPI architecture will be developed. We will > investigate reliable checkpointing primitives for parallel programming, > using Jini transactions, or related mechanisms. > > \paragraph{Year three:} > The experience of the first two years will feed into a practical model > of scalable Internet computing, combining parallel-programming ideas from > MPI with Jini ideas about fault tolerance. This model will be integrated > with the three-tier JiniMPI model. > > \section{Related Work} > > \subsection{The {\em HPJava} parallel programming environment} > > \label{sec:HPJava} > > We have been investigating a language model that combines characteristic > data-parallel features from the HPF (High Performance Fortran) language > with an explicitly SPMD programming style. A goal of this model > (the {\em HPspmd model}) is to facilitate calls to libraries for > parallel programming with distributed data from within an explicitly > SPMD-parallel program. > > In particular we have been implementing and testing these ideas within > an environment called HPJava, built around and implementation of the > HPspmd language extensions with Java as the base language > \cite{HPJava}. > > The current HPJava compiler is a source-to-source translation tool > taking a parallel program written in the HPspmd-extended Java language > as input, and generating a standard Java program with classes describing > the HPspmd distributed arrays. At the time of writing an initial version > of the HPJava compiler is operational. Recently we successfully compiled > and ran an 800-line multigrid benchmark, transcribed from an existing > Fortran 90 program. The explicitly parallelized HPJava program is about > the same length as the original (at best implicitly parallel) Fortran, > encouraging us in the belief that we have a good model for parallel > programming. > > The current translator uses a relatively naive translation scheme. > This will be replaced by a higher quality scheme over the next several > months (within the original HPspmd project). Still the underlying > communication libraries are based on Java interface to native MPI > software---we will not have a fully portable pure-Java environment. > One future task in the work proposed here would address this shortcoming. > > \subsection{Experience with {\em mpiJava}} > > \label{sec:mpiJava} > > {\em mpiJava} \cite{Baker98,Carpenter99,mpiJava} is our object-oriented Java > interface to MPI. > The system provides a fully-featured > Java binding of MPI 1.1 standard. The object-oriented API is modelled > largely on the C++ binding that appeared in the MPI 2 standard. > The implementation of mpiJava is through JNI (Java Native Interface) > wrappers to a suitable native implementation of MPI. The software comes > with a comprehensive test-suite translated from the IBM test-suite for > the C version of MPI. Platforms currently supported include Solaris using > MPICH or SunHPC-MPI, Linux using MPICH, and Windows NT using WMPI 1.1. > > %\begin{figure}[tp] > %\centerline{\psfig{figure=mpiJava.eps,width=4.5in}} > %\caption{Principal classes of mpiJava\label{hierarchy}} > %\end{figure} > > The MPI standard is explicitly object-based. The C and Fortran > bindings rely on ``opaque objects'' that can be manipulated only by > acquiring object handles from constructor functions, and passing the > handles to suitable functions in the library. The C++ binding > specified in the MPI 2 standard collects these objects into suitable > class hierarchies and defines most of the library functions as class > member functions. The mpiJava API follows this model, > lifting the structure of its class hierarchy directly from the C++ > binding. > %The major classes of mpiJava are illustrated in Figure \ref{hierarchy}. > > % *** Moved from its natural place in `sec:mpiJava' to get good page layout *** > \begin{figure}[tp] > \centerline{\psfig{figure=fig6.eps}} > \caption{PingPong Results in Distributed Memory mode\label{fig:distributed}} > \end{figure} > > The benchmarks in Figure \ref{fig:distributed} compare mpiJava (``J'') > timings with native C timings for communication between a pair of PCs. > The timings represent two different native MPI implementations (MPICH > and WMPI), and also compare with with raw Windows sockets. We see that > the mpiJava JNI wrappers introduce a modest extra latency relative to > native MPI, but for large messages bandwidth is not compromised. Although > these results are encouraging, we should remark that these benchmarks > were run using the Classic JVM. Current JIT compilers will degrade > bandwidth because Java arrays are usually copied when they are passed > to native methods. How best to avoid such overheads is an important > research question \cite{Chang99,Welsh99A}. > > mpiJava is part of the {\em HPJava} environment \cite{HPJava}. > We are actively developing and supporting the software. Downloads > run at about 30 per month. > > \subsection{Java Grande Message-passing Working group} > > \label{sec:JGMPWG} > > Java bindings to MPI were developed independently by several > teams. One Java MPI interface was produced by Getov and Mintchev > \cite{Mintchev97,Getov98}. In their work Java wrappers were automatically > generated from the C MPI header. This eased the implementation work, > but did not lead to a fully object-oriented API. A subset of MPI was > implemented in the DOGMA system for Java-based parallel programming > \cite{DOGMA}. Dincer and Kadriy described an instrumented Java interface > to MPI called {\em jmpi} \cite{Dincer98}. Java implementations of > the related PVM message-passing environment have been reported in > \cite{Yalamanchilli98} and \cite{Ferrari98}. > > The Message-Passing Working Group of the Java Grande Forum was formed > as a response to the appearance of these diverse APIs. > An immediate goal was to discuss a common API for MPI-like Java libraries. > An initial draft for a common API specification was distributed at > Supercomputing '98 \cite{MPIposition}. Since then the working group has > met in San Francisco and Syracuse, and a Birds of a Feather meeting was > held at Supercomputing '99. > Minutes of meetings were published on the > {\em java-mpi} mailing list \cite{java-mpi}. > To avoid confusion with standards published by the original MPI Forum > (which is not presently convening) the nascent API is now called {\em MPJ}. > A version of the specification was published last year \cite{MPJ}. > > \subsection{Case study: reference implementation of MPJ} > > \label{sec:MPJ-RI} > > Presently there is no complete implementation of the draft MPJ specification. > Our own Java message-passing interface, {\em mpiJava}, is moving towards > the ``standard''. The new version 1.2 of the software > supports direct communication of objects via object serialization, > which is an important step towards implementing the specification in > \cite{MPIposition}. > > The mpiJava wrappers rely on the availability of a platform-specific > native MPI implementation for the target computer. While this is a > reasonable basis in many cases, the approach has some disadvantages. > For one thing the two-stage installation procedure---get and build > a native MPI then install and match Java wrappers---can be tedious > and discouraging to potential users. Secondly, in the development of > mpiJava we sometimes saw conflicts between the JVM environment and the > native MPI runtime behaviour. The situation has improved, and mpiJava > now runs with several combinations of JVM and MPI implementation, but > some problems remain. Finally, this strategy simply conflicts with the > ethos of Java, where pure-Java, write-once-run-anywhere software is the > order of the day. > > Ideally, the first two problems would be addressed by the providers of the > original native MPI package. We envisage that they could provide a Java > interface bundled with their C and Fortran bindings. Ultimately, such > packages would presumably be the best, industrial-strength implementations > of systems like MPJ. > Meanwhile, to address the last shortcoming listed above, we have outlined > in \cite{Baker00} a design for a {\em pure-Java} reference implementation > for MPJ. Design goals were that the system should be as easy to install > on distributed systems as we can reasonably make it, and that it be > sufficiently robust to be useable in an Internet environment. > A particularly strong requirement is that in no circumstances should > the software leave resource-wasting orphan processes lingering after an > abrupt termination. > > We are by no means the first people to consider implementing > MPI-like functionality in pure Java. Working systems have already > been reported in \cite{DOGMA,Dincer98}, for example. Our goal was to > build on some lessons learnt in those earlier systems, and produce > software that is standalone, easy-to-use, robust, and fully implements > the specification of \cite{MPIposition}. > > We wish to simplify installation of message-passing software to > a bare minimum. A user should download a jar-file of MPJ library > classes to machines that may host parallel jobs, and run a parameterless > installation script on each. Thereafter parallel java codes can be > compiled on any host in the LAN (or subnet). An {\tt mpjrun} program > invoked on the development host transparently loads all the user's > class files to available compute hosts, and the parallel job starts. > The only {\em required} parameters for the {\tt mpjrun} program should be the > class name for the application's main program and the number of processors > the application is to run on. > > To be usable, an MPJ implementation should be fault-tolerent in at least > the following senses. If a remote host is lost during execution, either > because a network connection breaks or the host system goes down, or for > some other reason, {\em all} processes associated with affected > MPJ jobs must shut down within some short interval of time. On the > other hand, unless it is explicitly killed or its host system goes > down altogether, the MPJ {\em daemon} on a remote host should survive > unexpected termination of any particular MPJ job. Concurrent tasks > associated with other MPJ jobs should be unaffected, even if they > were initiated by the same daemon. > > The paper design suggests that Jini is a natural foundation for meeting > these requirements. The installation script can start a daemon on > the local machine by registering a persistent activatable object with > the {\tt rmid} daemon. The MPJ daemons automatically advertise their > presence through the Jini lookup services. The Jini paradigms of leasing and > distributed events are used to detect failures and reclaim resources > in the event of failure. These observations lead us to believe that > an initial reference implementation of MPJ should probably use Jini > technology\cite{Jini1,Jini2} to facilitate location of remote MPJ daemons > and to provide a framework for the required fault-tolerance. > > \begin{figure*}[tp] > \centerline{\psfig{figure=tower.eps,height=4in}} > \caption{Layers of proposed MPJ reference > implementation\label{fig:architecture}} > \end{figure*} > > A possible architecture is sketched in Figure \ref{fig:architecture}. > The base layer---process creation and monitoring---incorporates initial > negotiation with the MPJ daemon, and low-level services provided > by this daemon, including clean termination and routing of output streams > (Figure \ref{fig:process}). The daemon invokes the {\tt MPJSlave} > class in a new JVM. {\tt MPJSlave} is responsible for downloading > the user's application and starting that application. It may also > directly invoke routines to initialize the message-passing layer. > Overall, what this bottom layer provides to the next layer is a reliable > group of processes with user code installed. It may also provide some > mechanisms---presumably RMI-based (we assume that the whole of the bottom > layer is built on RMI)---for global synchronization and broadcasting > simple information like server port numbers. > > \begin{figure*}[tp] > \centerline{\psfig{figure=MPJ-Jini.eps,height=2.5in}} > \caption{Independent clients may find {\tt MPJService} daemons > through the Jini lookup service. Each daemon may spawn several > slaves.\label{fig:process}} > \end{figure*} > > Higher layers use Java sockets directly for efficient communication. > The first manages low-level socket connections, establishing all-to-all > TCP socket connections between the hosts. The idea of an ``MPJ device'' > layer is inspired by the abstract device interface of MPICH. A minimal > API includes non-blocking standard-mode send and receive operations. > Other point-to-point communication modes are implemented with > reasonable efficiency on top of this minimal set. The device level itself > is meant to be implemented on socket {\tt send} and {\tt recv} > operations, using standard Java threads and synchronization methods to > achieve its richer semantics. The next layer above this is base-level > MPJ, which includes point-to-point communications, communicators, groups, > datatypes and environmental management. On top of this are higher-level > MPJ operations including the collective operations. We anticipate that > much of this code can be implemented by fairly direct transcription of > the {\tt src} subdirectories in the MPICH release---the parts of the > MPICH implementation above the abstract device level. > > > > \newpage > > \subsection{Results from prior NSF support} > \label{sec:hpjava} > > Work on this proposal is related to previous NSF awards including > the research grant described below from the Division > of Advanced Computational Infrastructure and Research. This > ongoing project has transferred from Syracuse to > Florida State University. Fox is PI. > > \subsubsection*{Grant: 9872125, total award \$346,827 over period > 09/01/98-08/31/01, ``Data Parallel SPMD Programming Models from > Fortran to Java''.} > > This involves senior personnel Fox and Carpenter, who with two students > on the project have recently moved from Syracuse to Florida State. The > project focuses on the use of Java for {\em data parallel} programming > but the methods are applicable to other languages. Collaborator > Professor Xiaoming Li from Peking University is investigating applications > to traditional scientific languages---especially Fortran. We have > published several papers on this subject where the details are described. > The HPJava model is less ambitious than systems like High Performance > Fortran (HPF) and aims to support an SPMD model intermediate between > basic message passing (MPI) and HPF. One can incorporate pure MPI code > but also array based computation with automatic decomposition with a > user specified mapping in the spirit of HPF. An essential capability > is unified support of successful data parallel libraries like ScaLAPACK, > PetSC, Kelp, Global Array Toolkit, PARTI/CHAOS and Adlib. So far we > have developed an operational HPJava translator and linked to Global > Arrays and Adlib. As part of our collaboration we have prepared > and given in China a tutorial on HPJava and related approaches > (http://www.npac.syr.edu/projects/pcpc/HPJava/beijing.html). To > support MPI work from within HPJava programs we developed the > MPI Java binding {\em mpiJava} which is available for download from > (http:/www.npac.syr.edu/projects/pcrc/HP\-Java/mpiJava.html), and will > be form one of the foundations of the work described in the current > proposal. It is a reference implementation used by the Java Grande Message > Passing Working Group. Fox organized the Java Grande Forum > (http://www.javagrande.org) to address all the issues connected with > the use of Java in scientific computing and both the working groups > and associated conferences (now sponsored by ACM) have been quite > successful. HPJava ideas have greately benefitted from contacts in this > arena. As well as publications given below, Sung Hoon Ko completed > his Ph.D. in this area last year. > > \subsubsection*{Select publications} > > \begin{trivlist} > \item > B. Carpenter, G. Zhang, G. Fox, X. Li, X. Li and Y. Wen ``Towards a > {Java} environment for {SPMD} programming'', {\em 4th International > Europar Conference}, Springer, 1998. > \item > G. Zhang, B. Carpenter, G. Fox, X. Li and Y. Wen, ``The HPspmd > Model and its Java Binding.'', chapter in book, R. Buyya ed, > {\em High Performance Cluster Computing}, Vol 2, Prentice Hall 1999. > \item > M. Baker, B. Carpenter, G. Fox, S.H. Ko and S. Lim, ``mpiJava: > An Object-oriented Java Interface to MPI'', {\em Intl. Workshop on Java for > Parallel and Distributed Computing, IPPS/SPDP '99}, San Juan, Puerto Rico, > April 1999. > \item > B. Carpenter, V. Getov, G. Judd, A. Skjellum and G. Fox > ``{MPJ}: {MPI}-like message passing for {Java}'', > Concurrency: Practice and Experience, 12(11), 2000. > \end{trivlist} > > > > \renewcommand{\bibname}{Bibliography} > \bibliographystyle{plain} > \bibliography{\jobname} > > From furbish@quartz.gly.fsu.edu Mon Jun 18 15:59:08 2007 Return-Path: Delivered-To: fox@csit.fsu.edu Received: from snorkel.uits.indiana.edu (snorkel.uits.indiana.edu [129.79.6.186]) by mailer.csit.fsu.edu (Postfix) with ESMTP id B861523A1D for ; Fri, 3 Aug 2001 17:28:19 -0400 (EDT) Received: from quartz.gly.fsu.edu (quartz.gly.fsu.edu [128.186.10.36]) by snorkel.uits.indiana.edu (8.10.1/8.10.1/IUPO) with ESMTP id f73LSJq21405 for ; Fri, 3 Aug 2001 16:28:19 -0500 (EST) Received: from water (dial1066.acns.fsu.edu [146.201.36.202]) by quartz.gly.fsu.edu (8.10.2/8.10.2) with SMTP id f73LOHE49779; Fri, 3 Aug 2001 17:24:17 -0400 (EDT) From: "David Jon Furbish" To: , , , , , "Chris Paola" , , , , , , , , , "Hussaini" Cc: "Raymond Bye" Subject: ITR 2 Date: Fri, 3 Aug 2001 17:26:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0050_01C11C41.6A482710" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MS-TNEF-Correlator: Sender: furbish@quartz.gly.fsu.edu This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C11C41.6A482710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi: This is to let you know that our ITR proposal was declined. From Gary Strong at NSF... "I hope that you will consider the ITR competition in the coming year since your proposal was considered in the competitive range this year. The reviews should be processed and available soon." I shall forward copies of the reviews when I receive them. Many thanks to all of you for your contributions on this 2nd try... particularly when it got hectic near the deadline! David David Jon Furbish Department of Geological Sciences and Center for Earth Surface Processes Research Florida State University Tallahassee, Florida 32306-4100 (850)644-5892 dfurbish@garnet.acns.fsu.edu ------=_NextPart_000_0050_01C11C41.6A482710 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IhYVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCAADABEAGgAAAAUAEwEB A5AGAKQGAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAABgAAAElUUiAyAAAAAgFxAAEAAAAWAAAAAcEcYu7UKh2516wwSIqf9wRONmiFDgAAAgEdDAEA AAAZAAAAU01UUDpGVVJCSVNIQEdMWS5GU1UuRURVAAAAAAsAAQ4AAAAAQAAGDgDk9eNiHMEBAgEK DgEAAAAYAAAAAAAAAPXWDAHQzeNMrZw1hfg0HvrCgAAACwAfDgEAAAACAQkQAQAAAMMCAAC/AgAA wwMAAExaRnXNyjuCAwAKAHJjcGcxMjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBjaArAc/BldDAgBxMC gwBQA9WVEXV9CoF2CJB3awuAdGQ0DGBjAFALAwu1IDhIaToKogqECoBUaIUEACAWEXRvIGwRMIQg eQhgIGtubwfgDnQQ8AVACGEgSVRSRCBwA2Bwb3MHQCBsd2EEIAWBbAuACYAuSCAgRgNhIEcKwHkt BgB0A2APICAXkU5THEYuGzAVOgrzICJJdCBoGGBlF2QW4gPwbP8DIAWgAIEEgRdhHOAYAgWg8m0c 0HRpH0ACIBYwA6DPHnIe8QuAGrB5ZQrBAJD8bmMc4BbhBcAYSx3mCYDrH6kfJHYc4HIPERziFhFv IJIZkRXwJCFlE1IEIHPpHLB1bBxgYhzgGEEhEO8EECLhAHAnQXYLcAtgAmDJHOBzbwIgLiIbyRU0 3xyQJiAHQAMgAhByGNAcUc0FoHAIkAQgb2YeYyWm/ncegAOgHJAJcCEQJAIecTptG1tNAHAaQBdx bmv/FlMp8ishFuIqMSE0HeEacHhpYnUfYisBH8IWETL7J3EacHkbMRmgGDAKwB9AdmMmUArAbBpA LBMfUCCsZ28FQB6AYzKhIBlgpwrBHnIBAGFkGUIhFTq+RCegHiAbbijmAEAgNlNUIEofgUYIcGIE AGg9NfVlMnIHgAIwKxJHZc0I8WcN4BihU2MIkCEBvwQgJ2EVNQEwMkE4EkM6MWseQS+yRTKBaAYA CHBm2wDQHOBQJtUEIFIHkCCh2xDgFTRGCQEeIGEaUReQvRzgVQMAJBAREB9QeRWVzSnxYRDwJxFl LBmwQDWAMzIzMDYtNA9AAwFAFUMoODUwKTbANDQtNTg5DlAVQ2RkZjkEQGcKwBlgdJYuANAAgC4D 0HUuCYBfDHA3HwExFUMTEQBJIAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AI IAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAH1u AQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwANgAggBgAAAAAAwAAA AAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYA AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAD AFuACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAbIAIIAYAAAAAAMAAAAAAAABGAAAAAAaF AAAAAAAAAgH4DwEAAAAQAAAA9dYMAdDN40ytnDWF+DQe+gIB+g8BAAAAEAAAAPXWDAHQzeNMrZw1 hfg0HvoCAfsPAQAAAJUAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAA TklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXGRqZlxMb2NhbCBTZXR0 aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0AAAAAAMA /g8FAAAAAwANNP03AAACAX8AAQAAADMAAAA8T0RFTUtOSk1NQUZEUEVERk1PREhLRUxGQ0FBQS5m dXJiaXNoQGdseS5mc3UuZWR1PgAAAwAGEH88n0kDAAcQJgIAAAMAEBAAAAAAAwAREAAAAAAeAAgQ AQAAAGUAAABISTpUSElTSVNUT0xFVFlPVUtOT1dUSEFUT1VSSVRSUFJPUE9TQUxXQVNERUNMSU5F REZST01HQVJZU1RST05HQVROU0YiSUhPUEVUSEFUWU9VV0lMTENPTlNJREVSVEhFSVRSAAAAALGK ------=_NextPart_000_0050_01C11C41.6A482710-- From furbish@fsu.edu Mon Jun 18 15:59:08 2007 Return-Path: Delivered-To: fox@csit.fsu.edu Received: from fins.uits.indiana.edu (unknown [129.79.6.185]) by mailer.csit.fsu.edu (Postfix) with ESMTP id CA67423A02 for ; Wed, 19 Sep 2001 08:48:00 -0400 (EDT) Received: from quartz.gly.fsu.edu (quartz.gly.fsu.edu [128.186.10.36]) by fins.uits.indiana.edu (8.10.1/8.10.1/IUPO) with ESMTP id f8JCexb19500 for ; Wed, 19 Sep 2001 07:40:59 -0500 (EST) Received: from Furbish (furbish.cespr.fsu.edu [146.201.214.15]) by quartz.gly.fsu.edu (8.10.2/8.10.2) with SMTP id f8IKYjW54542; Tue, 18 Sep 2001 16:34:49 -0400 (EDT) Message-ID: <007901c14083$263d2780$0fd6c992@Furbish> From: "David Jon Furbish" To: "M. Yousuff Hussaini" , "Mark Schmeeckle" , "Geoffrey Fox" , "Greg Tucker" , "Rudy Slingerland" , "Patricia Wiberg" , "Alan Howard" , "Vaughan Voller" , "Gary Parker" , "Chris Paola" , "Tad Pfeffer" , "James Syvitski" , "William Dietrich" , "Robert Anderson" , "Jonathan Shewchuk" Subject: ITR 2 reviews Date: Tue, 18 Sep 2001 16:39:18 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01C14060.76174880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 This is a multi-part message in MIME format. ------=_NextPart_000_0074_01C14060.76174880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: Below are the reviews for ITR 2. I will be in touch again soon. Cheers, David David Jon Furbish Department of Geological Sciences and Center for Earth Surface Processes Research Florida State University Tallahassee, Florida 32306-4100 (850)644-7494 (CESPR) (850)644-5892 (Geological Sciences) furbish@fsu.edu =20 =20 PROPOSAL NO.: 0122483 INSTITUTION: Florida State University NSF PROGRAM: = ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, David J TITLE: ITR/AP: = A consortium for advanced computing in Earth surface dynamics = RATING:Good=20 REVIEW: What is the intellectual merit of the proposed activity? The = intellectual merit is high, and is a strength of the proposal. This = effort would bring together surface-process and computational scientists = in collaborative effort to address landscape modeling. The = multidisciplinary, multi-university interaction is a challenge and a = strength of the proposal. The challenges posed in numerical solvers, = adaptive meshes, data structures, visualization, and parallel = computation are high. The fusing of all these areas in a collaborative = infrastructure has high intellectual merit. What are the broader impacts = of the proposed activity? The collaborative infrastructure developed = would be valuable beyond the application focus of this effort, and would = contribute to computational science in general. There is also a strong = educational element targeting multidisciplinary graduate education and = post-docs, as well as a good outreach program to K-12 and the public. = Summary Statement This proposal has strong intellectual merit, addresses = an important and challenging area of multidisciplinary science, shows = good understanding of the relevant science and the literature thereon, = and puts forth a strong and balanced cross-disciplinary team of = investigators from several universities. The statement of the scientific = and technological challenges to be met is good. The three stated = objectives in the Preamble - a tools library, a computational model, and = a collaborative laboratory - are well-conceived and appropriate. All = these aspects are strengths. But the management plan is vague and weak, = and would appear to be inadequate to achieve the coordinated effort = needed. It is not at all clear how the needed research elements will be = planned, staffed, and implemented according to a strategic plan. Rather = the intention seems to be more an enablement of individual groups = following their own dictates and interests in research - with only = workshops, seminars, and visiting researchers to tie it all together. = None of the four Core Programs clearly includes strategically planned = research: one addresses the definition of year-long focuses for seminars = and conferences, two address visiting researchers, and the fourth = addresses education and outreach. The Scientific Steering Group is to = set the directions in these four Core Programs, but no provision for = strategic planning of research components is evident. Rather the SSG and = the PCDs all appear to operate at too high a level, leaving the actual = research projects to be executed to be determined locally by the various = investigators. This otherwise noteworthy proposal thus comes across as a = request for funding of an unresricted distributed center of excellence = without strategic research planning. But without effective strategic = planning and direction, the end result cannot be expected to exceed that = of separate and uncoordinated funding for the various research groups = involved - nor can the stated objectives be expected to be reached.=20 PROPOSAL NO.: 0122483 INSTITUTION: Florida State University NSF PROGRAM: = ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, David J TITLE: ITR/AP: = A consortium for advanced computing in Earth surface dynamics = RATING:Very Good=20 REVIEW: What is the intellectual merit of the proposed activity? This is = an ambitious project to create an integrated environment to to model = landscape dyanmics. The project involves model coupling, space/time = issues, algorithms, adaptive techniques, data management, user = interfaces, collaborative techniques, etc. coupled with field based = studies. The project is a bold step forward. There may be some major = hurdles but with good management many of the project objectives should = be achievable especially since the project team is well qualified to = perform the tasks that are identified. I expect that this project will = identify some problems that require additional work outside the scope of = this project. This will be ok so long as the framework is developed so = that when these problems are resolved the new software can be easily = incorporated into the framework. This project will certainly benefit = earth scientists, geophysicists and others plus will result in an = excellent testbed for computational scientists and others. What are the = broader impacts of the proposed activity? The framework, computational = tools, multiscale process solutions, algorithms, and visualization = results may have potential use in other application domains. The = proposed environment has the potential for becoming the framework on = which future work in the modeling of earth surface dynamics will be = based. Summary Statement Excellent project but may be trying to do too = much.=20 PROPOSAL NO.: 0122483 INSTITUTION: Florida State University NSF PROGRAM: = ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, David J TITLE: ITR/AP: = A consortium for advanced computing in Earth surface dynamics = RATING:Very Good=20 REVIEW: What is the intellectual merit of the proposed activity? I liked = this proposal. It promises significant scientific impact with = substantial relevance to human needs. It strikes me as an ambitious = program, perhaps too ambitious. The modeling questions (multi-scale = parametric modeling) are hard, the numerics are hard, the visualization = is hard, and portals take a lot of work. However, in addition to laying = out ambitious goals, it proposes concrete first steps (adapting = averaging of underlying equations to erosion sedimentation, diffusional = models of fluvial profile evolution, moving boundary formalism, tying = cellular models to PDE approaches for fan deltas). But are the = underlying equations well enough understood? Another innovative and = strong point is the close tie to the experimental facility (XES). It = shows why progress can be expected now. The proposal has good relevance = to high performance computing. I am concerned that there is not enough = manpower dedicated to this project. As I said above, the problems are = both hard, and hard work. What are the broader impacts of the proposed = activity? The proposers make a good case for why understanding earth = surface dynamics is socially important, and that 'society .. is required = to embrace an increasing level of stewardship of Earth's natural = resources and ecosystems', and that this requires 'access to predictive = modeling capabilities of unprecedented sophistication'. I find the = training mundane. There are no new courses or degree programs planned. = In the lead institution (Florida State), there are only 4 graduate = students/year and 2 postdocs/year being supported. Of course there are = analogous numbers in the affiliate institutions. I question how feasible = the mentorship is. I do think that the teacher program is innovative, = and the focus topics are worthwhile and feasible. Summary Statement I = find this proposal more a series of research projects than a fully = coordinated project. I wonder why, since the budget is so modest (in = comparison with others in this category), that the training program was = not more ambitious, and why the PI is not spending 2months/year on this, = or why Fox's effort is less than 1 month/year.=20 PROPOSAL NO.: 0122483 INSTITUTION: Florida State University NSF PROGRAM: = ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, David J TITLE: ITR/AP: = A consortium for advanced computing in Earth surface dynamics = RATING:Fair=20 REVIEW: What is the intellectual merit of the proposed activity? This = project focuses on modeling the earth's dynamic surface, which is = defined as the interface between the fluid and solid earth. While not an = unimportant area of research, it does not seem like a particularly = important one either. At least, it is not apparent on the surface (no = pun intended), and the investigators do not make a strong case for its = importance either. The CS research focuses mainly in two areas: advanced = algorithms, and large data sets and advanced visualization in landscape = modeling. The algorithm research appears to be narrowly focused and it = is unclear how generalizable the results would be. The project appears = to be more oriented towards research in the earth's surface dynamics = than in CS, which raises a question about its relative appropriateness = for the ITR program. It is not that it is inappropriate; it just seems = less appropriate than other projects reviewed. The research consortium, = while admirable in scope, appears large and unwieldy with much apparent = overlap in the areas of research that each member of the consortium will = conduct. For example, most of the 10 research areas proposed have two = insitutions (more in some cases) listed as having primary responsibility = for the area. This could lead to confusion, duplicate effort and wasted = time. The management plan focuses on describing all of the participants = rather than focusing on how they will be coordinated and their efforts = integrated. The principal investigators do not appear to have a broad = research record, strong funding record, or record of managing large = scale projects such as the one proposed. They do appear to be competent = within their fields. What are the broader impacts of the proposed = activity? I do not see broad impacts resulting from this proposed = project. This project will lead to training of earth surface scientists, = engineeers and some computer scientists. It will not make a large = contribution to the IT workforce, which I define in terms of the = computer science and information science communities. The project's = education, mentorship and science for teachers programs are good efforts = at reaching an extended community. Summary Statement This is a nice = effort in an area that is appropriate for ITR support, but this project = simply does not stack up as well as others reviewed for reasons related = to the subject matter, the amount of CS contribution, the research = consortium and the research team.=20 PROPOSAL NO.: 0122483 INSTITUTION: Florida State University NSF PROGRAM: = ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, David J TITLE: ITR/AP: = A consortium for advanced computing in Earth surface dynamics = RATING:Very Good=20 REVIEW: What is the intellectual merit of the proposed activity? This = would integrate and greatly enhance activities in understanding the = dynamics of Earth's surface. As they state, quantitative analysis of = such is a fairly undeveloped field, but one which is of increasing = importance as we become more concerned about natural resources, water = supplies etc. What are the broader impacts of the proposed activity? = Knowledge and tools to address societally-important issues. Useful = educational tools (maybe) Summary Statement Useful, but I don't give = this top rating due to a couple of concerns. Firstly, a lot of the = proposed work seems to be applied mathematics (pertaining to numerical = modeling) rather than IT. Namely, they spend a lot of time discussing = mesh generation, solution of PDEs etc. The IT aspect seems limited to = the data management and assimilation protocols, and web-based = e-collabatory. Secondly, they seem mostly interested in investigating = models, rather than linking models to data. Yes they do mention the = importance of data but it seems like an afterthought.=20 PROPOSAL NO.: 0122483 INSTITUTION: Florida State University NSF PROGRAM: = ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, David J TITLE: ITR/AP: = A consortium for advanced computing in Earth surface dynamics = RATING:Fair=20 REVIEW: What is the intellectual merit of the proposed activity? The = proposed project would be valuable and important, although hardly a = breakthrough, in the disciplinary field of computational landscape = modeling. The impacts on solving scale-related theoretical and = computational issues, creating new collaborative infrastructure and = providing immediately useful problem-solving tools are less clear. What = are the broader impacts of the proposed activity? The chances that the = multi-disciplinary web-based collaboratory outlined is implemented as = proposed seem small to this reviewer. If implemented, it would enhance = research and education greatly. The educational part of the proposal is = well laid out and convincing. Summary Statement Overall, I see this = proposal as a solid one with two important shortcomings. The project = description provides a lot of detail on the engineering and algorithmic = aspects. The team has an excellent track record and there is no doubt in = my mind that the team can develop and test the algorithms they propose = (that is, in fact, what they have been doing all along, and much text in = the proposal is taken from published material). The validation and field = component appears strong, with the proposed use of the Experimental = Earthscape facility and three well-studied and diversified experimental = systems. While not carrying particular CS innovation (not required under = the the Applied Science and Engineering section of the ITR program), the = study would certainly produce useful techniques that would benefit the = field of computational landscape modeling at large. What disappoints me = is the vagueness and lack of clear direction in the two areas where the = study would bring real innovation. These are: 1) The proposed plan for = addressing scale issues is unconvincing at best. The PIs correctly point = out that scaling landscape dynamics up and down is one of the most = crucial challenges. Unfortunately their plan to address the issue is = very vague and seems to suggest that they have little clue on how to = proceed. Most of the discussion focuses on engineering details on = coupling models and generic strategies (continuous modelling) that = carry, as explained, a very low signal-to-noise ratio. Most of the = relevant literature is ignored and many essential issues are left = untouched. As an example, the PIs do not seem to consider important to = explain how they plan to deal with aggregation error. This part strikes = me as too vague and disappointing to make anyone want to invest 8+ = million on it. 2) A consistent part of the proposal is devoted to the = development of a web-based collaboratory and a simulation laboratory = geared to technical as well as non-technical users. When the buzzwords = and the mandatory fashionable technologies are masked out, too little = detail remains to indicate how the goals would be achieved. The = abstractions that the PIs indicate (p. 10) as a starting point for a = component-based model of the simulation environment are extreme = oversimplifications, and the semantics is, to say the least, weak. These = abstractions embody many of the implementation details for the whole = project, and saying, as they do, that "extensive discussion between = physical modellers and library builders" will shape them is certainly = not enough to convince me that the investment is worthwile. These PIs = should know better from the first stage. Overall, this part of the = proposal is vague and disappointing, and leaves me with little reason to = believe that it would bring to the generic and very ambitious results = laid out in the summary - data integration, automatic algorithm = selection and tuning, and particularly user friendliness. Also, much of = this part is based on Fox's work who is also a PI in the NPACI = initiative - and in fact, the visualization, computational, and = collaborative infrastructure that this proposal aims to develop is = likely to be already very well funded that way. The management plan = appears well laid out, although its complexity and the delocalization of = the research team could turn out to be a drawback - there is a visible = tendency for such big project to get bogged down in internal politics. = The outreach and education part is good enough for a project this size. = Overall, I think the proposal needs a much better articulated plan for = the two fundamental aspects I indicate above before it can be considered = worth the investment.=20 PROPOSAL NO.: 0122483 INSTITUTION: Florida State University NSF PROGRAM: = ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, David J TITLE: ITR/AP: = A consortium for advanced computing in Earth surface dynamics = RATING:Excellent=20 REVIEW: What is the intellectual merit of the proposed activity? This is = an excellent proposal involving a very broad and diverse set of = excellent researchers. There is a very healthy mix of earth scientists, = applied mathematicians/computational scientists, and computer = scientists. There are members of the team who bridge these areas in each = university site who should be able to facilitate communication within = the team. The project is relatively clearly defined and well thought = out. Each aspect of the proposal appears to be an integral part of the = whole---it is not merely a set of disjoint projects. Moreover, the = overall project would appear to allow for enough synergism that it = exceeds the sum of the parts. The earth science aspects appear to be = first rate, and includes modeling and validation with experimental = results. The experimental studies are conducted at one of the = participating sites, so should be easily accessible for the proposed = validation studies. This should produce a scientifically sound set of = physical modeling modules in the ESSL. This is critical for acceptance = of the IT system by the larger society. Designing the ESSL for = extensibility is also key in this regard. The proposed numerics is very = well thought out, and appropriate for a project of this sort. The = methods to be used are cutting edge, and yet well enough studied that = one can be confident that they will succeed. Many unresolved issues = remain, and will be addressed in the research, especially dynamic = meshing issues to follow free boundaries and internal interfaces, and = multi-scale aspects of the modeling. It is particularly intriguing that = the project will investigate the coupling of discrete and continuum = models. The IT work in eCollaboration, visualization, and data = manipulation appears to be first rate, and it is an integral part of the = research effort. The level of technology leveraging is admirable. A = healthy amount of existing software will be used as appropriate, so the = project will focus on the novel aspects of the research and not on = duplication of well researched parts. The management plan appears to be = sound. It should allow the project both to refocus resources as needs = arise or individual subprojects prove unfruitful, and to coordinate = research efforts effectively. The project appears to be driven by the = scientific investigation, rather than by abstract IT questions. This is = needed in this type of project, where the IT technology developed needs = to be accepted and used by the scientific community. What are the = broader impacts of the proposed activity? The successful demonstration = of the eCollaboratory and ESSL could have an impact on the scientific = community, providing a blueprint for similar endeavors in other = disciplines. The impact is potentially very great and profound on = environmental studies and earth sciences both in terms of everyday = practice and in terms of training students in the use and proper design = of interdisciplinary computational tools. More broadly, advances in IT = (visualization and handling large data sets), meshing, and multi-scale = modeling can be valuable in a large number of other scientific = disciplines. The project includes community-extending programs in = undergraduate education activities and K-12 teacher training. The = proposal is to make the ESSL user-friendly down to the novice level. = This is a challenge not without risk, but should indeed revolutionize = the way earth science is viewed by High school and undergraduate = students. The project addresses plans for distributing the software, and = for making is usable. The dissemination part of the proposal may be a = bit weak, as it is targeted somewhat narrowly. Summary Statement This is = an excellent proposal, with an excellent and diverse team of researchers = spanning the experimental, modeling, numerical, IT, computer science, = and educational aspects of the project. The proposal is innovative and = risky, but likely to succeed in many important ways. It could = revolutionize the way earth scientists view their field by facilitating = the use of computational simulation. The educational component of the = proposal is strong, and spans high school through postdoctoral training. = ------=_NextPart_000_0074_01C14060.76174880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi:
 
Below are the reviews for ITR 2.  = I will be=20 in touch again soon.
 
Cheers,
David
 
David Jon Furbish
Department of = Geological=20 Sciences and
    Center for Earth Surface Processes=20 Research
Florida State University
Tallahassee, Florida=20 32306-4100
(850)644-7494 (CESPR)
(850)644-5892 (Geological = Sciences)
furbish@fsu.edu
 
 =20

PROPOSAL NO.: 0122483 INSTITUTION: Florida State = University NSF=20 PROGRAM: ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, = David J=20 TITLE: ITR/AP: A consortium for advanced computing in Earth = surface=20 dynamics RATING:Good

REVIEW: What is the intellectual merit of the proposed activity? = The=20 intellectual merit is high, and is a strength of the proposal. This = effort would=20 bring together surface-process and computational scientists in = collaborative=20 effort to address landscape modeling. The multidisciplinary, = multi-university=20 interaction is a challenge and a strength of the proposal. The = challenges posed=20 in numerical solvers, adaptive meshes, data structures, visualization, = and=20 parallel computation are high. The fusing of all these areas in a = collaborative=20 infrastructure has high intellectual merit. What are the broader impacts = of the=20 proposed activity? The collaborative infrastructure developed would be = valuable=20 beyond the application focus of this effort, and would contribute to=20 computational science in general. There is also a strong educational = element=20 targeting multidisciplinary graduate education and post-docs, as well as = a good=20 outreach program to K-12 and the public. Summary Statement This proposal = has=20 strong intellectual merit, addresses an important and challenging area = of=20 multidisciplinary science, shows good understanding of the relevant = science and=20 the literature thereon, and puts forth a strong and balanced = cross-disciplinary=20 team of investigators from several universities. The statement of the = scientific=20 and technological challenges to be met is good. The three stated = objectives in=20 the Preamble - a tools library, a computational model, and a = collaborative=20 laboratory - are well-conceived and appropriate. All these aspects are=20 strengths. But the management plan is vague and weak, and would appear = to be=20 inadequate to achieve the coordinated effort needed. It is not at all = clear how=20 the needed research elements will be planned, staffed, and implemented = according=20 to a strategic plan. Rather the intention seems to be more an enablement = of=20 individual groups following their own dictates and interests in research = - with=20 only workshops, seminars, and visiting researchers to tie it all = together. None=20 of the four Core Programs clearly includes strategically planned = research: one=20 addresses the definition of year-long focuses for seminars and = conferences, two=20 address visiting researchers, and the fourth addresses education and = outreach.=20 The Scientific Steering Group is to set the directions in these four = Core=20 Programs, but no provision for strategic planning of research components = is=20 evident. Rather the SSG and the PCDs all appear to operate at too high a = level,=20 leaving the actual research projects to be executed to be determined = locally by=20 the various investigators. This otherwise noteworthy proposal thus comes = across=20 as a request for funding of an unresricted distributed center of = excellence=20 without strategic research planning. But without effective strategic = planning=20 and direction, the end result cannot be expected to exceed that of = separate and=20 uncoordinated funding for the various research groups involved - nor can = the=20 stated objectives be expected to be reached.

PROPOSAL NO.: 0122483 INSTITUTION: Florida State = University NSF=20 PROGRAM: ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, = David J=20 TITLE: ITR/AP: A consortium for advanced computing in Earth = surface=20 dynamics RATING:Very Good

REVIEW: What is the intellectual merit of the proposed activity? = This is=20 an ambitious project to create an integrated environment to to model = landscape=20 dyanmics. The project involves model coupling, space/time issues, = algorithms,=20 adaptive techniques, data management, user interfaces, collaborative = techniques,=20 etc. coupled with field based studies. The project is a bold step = forward. There=20 may be some major hurdles but with good management many of the project=20 objectives should be achievable especially since the project team is = well=20 qualified to perform the tasks that are identified. I expect that this = project=20 will identify some problems that require additional work outside the = scope of=20 this project. This will be ok so long as the framework is developed so = that when=20 these problems are resolved the new software can be easily incorporated = into the=20 framework. This project will certainly benefit earth scientists, = geophysicists=20 and others plus will result in an excellent testbed for computational = scientists=20 and others. What are the broader impacts of the proposed activity? The=20 framework, computational tools, multiscale process solutions, = algorithms, and=20 visualization results may have potential use in other application = domains. The=20 proposed environment has the potential for becoming the framework on = which=20 future work in the modeling of earth surface dynamics will be based. = Summary=20 Statement Excellent project but may be trying to do too much.

PROPOSAL NO.: 0122483 INSTITUTION: Florida State = University NSF=20 PROGRAM: ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, = David J=20 TITLE: ITR/AP: A consortium for advanced computing in Earth = surface=20 dynamics RATING:Very Good

REVIEW: What is the intellectual merit of the proposed activity? = I liked=20 this proposal. It promises significant scientific impact with = substantial=20 relevance to human needs. It strikes me as an ambitious program, perhaps = too=20 ambitious. The modeling questions (multi-scale parametric modeling) are = hard,=20 the numerics are hard, the visualization is hard, and portals take a lot = of=20 work. However, in addition to laying out ambitious goals, it proposes = concrete=20 first steps (adapting averaging of underlying equations to erosion=20 sedimentation, diffusional models of fluvial profile evolution, moving = boundary=20 formalism, tying cellular models to PDE approaches for fan deltas). But = are the=20 underlying equations well enough understood? Another innovative and = strong point=20 is the close tie to the experimental facility (XES). It shows why = progress can=20 be expected now. The proposal has good relevance to high performance = computing.=20 I am concerned that there is not enough manpower dedicated to this = project. As I=20 said above, the problems are both hard, and hard work. What are the = broader=20 impacts of the proposed activity? The proposers make a good case for why = understanding earth surface dynamics is socially important, and that = 'society ……=20 is required to embrace an increasing level of stewardship of Earth's = natural=20 resources and ecosystems', and that this requires 'access to predictive = modeling=20 capabilities of unprecedented sophistication'. I find the training = mundane.=20 There are no new courses or degree programs planned. In the lead = institution=20 (Florida State), there are only 4 graduate students/year and 2 = postdocs/year=20 being supported. Of course there are analogous numbers in the affiliate=20 institutions. I question how feasible the mentorship is. I do think that = the=20 teacher program is innovative, and the focus topics are worthwhile and = feasible.=20 Summary Statement I find this proposal more a series of research = projects than a=20 fully coordinated project. I wonder why, since the budget is so modest = (in=20 comparison with others in this category), that the training program was = not more=20 ambitious, and why the PI is not spending 2months/year on this, or why = Fox's=20 effort is less than 1 month/year.

PROPOSAL NO.: 0122483 INSTITUTION: Florida State = University NSF=20 PROGRAM: ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, = David J=20 TITLE: ITR/AP: A consortium for advanced computing in Earth = surface=20 dynamics RATING:Fair

REVIEW: What is the intellectual merit of the proposed activity? = This=20 project focuses on modeling the earth's dynamic surface, which is = defined as the=20 interface between the fluid and solid earth. While not an unimportant = area of=20 research, it does not seem like a particularly important one either. At = least,=20 it is not apparent on the surface (no pun intended), and the = investigators do=20 not make a strong case for its importance either. The CS research = focuses mainly=20 in two areas: advanced algorithms, and large data sets and advanced=20 visualization in landscape modeling. The algorithm research appears to = be=20 narrowly focused and it is unclear how generalizable the results would = be. The=20 project appears to be more oriented towards research in the earth's = surface=20 dynamics than in CS, which raises a question about its relative = appropriateness=20 for the ITR program. It is not that it is inappropriate; it just seems = less=20 appropriate than other projects reviewed. The research consortium, while = admirable in scope, appears large and unwieldy with much apparent = overlap in the=20 areas of research that each member of the consortium will conduct. For = example,=20 most of the 10 research areas proposed have two insitutions (more in = some cases)=20 listed as having primary responsibility for the area. This could lead to = confusion, duplicate effort and wasted time. The management plan focuses = on=20 describing all of the participants rather than focusing on how they will = be=20 coordinated and their efforts integrated. The principal investigators do = not=20 appear to have a broad research record, strong funding record, or record = of=20 managing large scale projects such as the one proposed. They do appear = to be=20 competent within their fields. What are the broader impacts of the = proposed=20 activity? I do not see broad impacts resulting from this proposed = project. This=20 project will lead to training of earth surface scientists, engineeers = and some=20 computer scientists. It will not make a large contribution to the IT = workforce,=20 which I define in terms of the computer science and information science=20 communities. The project's education, mentorship and science for = teachers=20 programs are good efforts at reaching an extended community. Summary = Statement=20 This is a nice effort in an area that is appropriate for ITR support, = but this=20 project simply does not stack up as well as others reviewed for reasons = related=20 to the subject matter, the amount of CS contribution, the research = consortium=20 and the research team.

PROPOSAL NO.: 0122483 INSTITUTION: Florida State = University NSF=20 PROGRAM: ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, = David J=20 TITLE: ITR/AP: A consortium for advanced computing in Earth = surface=20 dynamics RATING:Very Good

REVIEW: What is the intellectual merit of the proposed activity? = This=20 would integrate and greatly enhance activities in understanding the = dynamics of=20 Earth's surface. As they state, quantitative analysis of such is a = fairly=20 undeveloped field, but one which is of increasing importance as we = become more=20 concerned about natural resources, water supplies etc. What are the = broader=20 impacts of the proposed activity? Knowledge and tools to address=20 societally-important issues. Useful educational tools (maybe) Summary = Statement=20 Useful, but I don't give this top rating due to a couple of concerns. = Firstly, a=20 lot of the proposed work seems to be applied mathematics (pertaining to=20 numerical modeling) rather than IT. Namely, they spend a lot of time = discussing=20 mesh generation, solution of PDEs etc. The IT aspect seems limited to = the data=20 management and assimilation protocols, and web-based e-collabatory. = Secondly,=20 they seem mostly interested in investigating models, rather than linking = models=20 to data. Yes they do mention the importance of data but it seems like an = afterthought.

PROPOSAL NO.: 0122483 INSTITUTION: Florida State = University NSF=20 PROGRAM: ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, = David J=20 TITLE: ITR/AP: A consortium for advanced computing in Earth = surface=20 dynamics RATING:Fair

REVIEW: What is the intellectual merit of the proposed activity? = The=20 proposed project would be valuable and important, although hardly a=20 breakthrough, in the disciplinary field of computational landscape = modeling. The=20 impacts on solving scale-related theoretical and computational issues, = creating=20 new collaborative infrastructure and providing immediately useful=20 problem-solving tools are less clear. What are the broader impacts of = the=20 proposed activity? The chances that the multi-disciplinary web-based=20 collaboratory outlined is implemented as proposed seem small to this = reviewer.=20 If implemented, it would enhance research and education greatly. The = educational=20 part of the proposal is well laid out and convincing. Summary Statement = Overall,=20 I see this proposal as a solid one with two important shortcomings. The = project=20 description provides a lot of detail on the engineering and algorithmic = aspects.=20 The team has an excellent track record and there is no doubt in my mind = that the=20 team can develop and test the algorithms they propose (that is, in fact, = what=20 they have been doing all along, and much text in the proposal is taken = from=20 published material). The validation and field component appears strong, = with the=20 proposed use of the Experimental Earthscape facility and three = well-studied and=20 diversified experimental systems. While not carrying particular CS = innovation=20 (not required under the the Applied Science and Engineering section of = the ITR=20 program), the study would certainly produce useful techniques that would = benefit=20 the field of computational landscape modeling at large. What disappoints = me is=20 the vagueness and lack of clear direction in the two areas where the = study would=20 bring real innovation. These are: 1) The proposed plan for addressing = scale=20 issues is unconvincing at best. The PIs correctly point out that scaling = landscape dynamics up and down is one of the most crucial challenges.=20 Unfortunately their plan to address the issue is very vague and seems to = suggest=20 that they have little clue on how to proceed. Most of the discussion = focuses on=20 engineering details on coupling models and generic strategies = (continuous=20 modelling) that carry, as explained, a very low signal-to-noise ratio. = Most of=20 the relevant literature is ignored and many essential issues are left = untouched.=20 As an example, the PIs do not seem to consider important to explain how = they=20 plan to deal with aggregation error. This part strikes me as too vague = and=20 disappointing to make anyone want to invest 8+ million on it. 2) A = consistent=20 part of the proposal is devoted to the development of a web-based = collaboratory=20 and a simulation laboratory geared to technical as well as non-technical = users.=20 When the buzzwords and the mandatory fashionable technologies are masked = out,=20 too little detail remains to indicate how the goals would be achieved. = The=20 abstractions that the PIs indicate (p. 10) as a starting point for a=20 component-based model of the simulation environment are extreme=20 oversimplifications, and the semantics is, to say the least, weak. These = abstractions embody many of the implementation details for the whole = project,=20 and saying, as they do, that "extensive discussion between physical = modellers=20 and library builders" will shape them is certainly not enough to = convince me=20 that the investment is worthwile. These PIs should know better from the = first=20 stage. Overall, this part of the proposal is vague and disappointing, = and leaves=20 me with little reason to believe that it would bring to the generic and = very=20 ambitious results laid out in the summary - data integration, automatic=20 algorithm selection and tuning, and particularly user friendliness. = Also, much=20 of this part is based on Fox's work who is also a PI in the NPACI = initiative -=20 and in fact, the visualization, computational, and collaborative = infrastructure=20 that this proposal aims to develop is likely to be already very well = funded that=20 way. The management plan appears well laid out, although its complexity = and the=20 delocalization of the research team could turn out to be a drawback - = there is a=20 visible tendency for such big project to get bogged down in internal = politics.=20 The outreach and education part is good enough for a project this size. = Overall,=20 I think the proposal needs a much better articulated plan for the two=20 fundamental aspects I indicate above before it can be considered worth = the=20 investment.

PROPOSAL NO.: 0122483 INSTITUTION: Florida State = University NSF=20 PROGRAM: ITR LARGE GRANTS PRINCIPAL INVESTIGATOR: Furbish, = David J=20 TITLE: ITR/AP: A consortium for advanced computing in Earth = surface=20 dynamics RATING:Excellent

REVIEW: What is the intellectual merit of the proposed activity? = This is=20 an excellent proposal involving a very broad and diverse set of = excellent=20 researchers. There is a very healthy mix of earth scientists, applied=20 mathematicians/computational scientists, and computer scientists. There = are=20 members of the team who bridge these areas in each university site who = should be=20 able to facilitate communication within the team. The project is = relatively=20 clearly defined and well thought out. Each aspect of the proposal = appears to be=20 an integral part of the whole---it is not merely a set of disjoint = projects.=20 Moreover, the overall project would appear to allow for enough synergism = that it=20 exceeds the sum of the parts. The earth science aspects appear to be = first rate,=20 and includes modeling and validation with experimental results. The = experimental=20 studies are conducted at one of the participating sites, so should be = easily=20 accessible for the proposed validation studies. This should produce a=20 scientifically sound set of physical modeling modules in the ESSL. This = is=20 critical for acceptance of the IT system by the larger society. = Designing the=20 ESSL for extensibility is also key in this regard. The proposed numerics = is very=20 well thought out, and appropriate for a project of this sort. The = methods to be=20 used are cutting edge, and yet well enough studied that one can be = confident=20 that they will succeed. Many unresolved issues remain, and will be = addressed in=20 the research, especially dynamic meshing issues to follow free = boundaries and=20 internal interfaces, and multi-scale aspects of the modeling. It is = particularly=20 intriguing that the project will investigate the coupling of discrete = and=20 continuum models. The IT work in eCollaboration, visualization, and data = manipulation appears to be first rate, and it is an integral part of the = research effort. The level of technology leveraging is admirable. A = healthy=20 amount of existing software will be used as appropriate, so the project = will=20 focus on the novel aspects of the research and not on duplication of = well=20 researched parts. The management plan appears to be sound. It should = allow the=20 project both to refocus resources as needs arise or individual = subprojects prove=20 unfruitful, and to coordinate research efforts effectively. The project = appears=20 to be driven by the scientific investigation, rather than by abstract IT = questions. This is needed in this type of project, where the IT = technology=20 developed needs to be accepted and used by the scientific community. = What are=20 the broader impacts of the proposed activity? The successful = demonstration of=20 the eCollaboratory and ESSL could have an impact on the scientific = community,=20 providing a blueprint for similar endeavors in other disciplines. The = impact is=20 potentially very great and profound on environmental studies and earth = sciences=20 both in terms of everyday practice and in terms of training students in = the use=20 and proper design of interdisciplinary computational tools. More = broadly,=20 advances in IT (visualization and handling large data sets), meshing, = and=20 multi-scale modeling can be valuable in a large number of other = scientific=20 disciplines. The project includes community-extending programs in = undergraduate=20 education activities and K-12 teacher training. The proposal is to make = the ESSL=20 user-friendly down to the novice level. This is a challenge not without = risk,=20 but should indeed revolutionize the way earth science is viewed by High = school=20 and undergraduate students. The project addresses plans for distributing = the=20 software, and for making is usable. The dissemination part of the = proposal may=20 be a bit weak, as it is targeted somewhat narrowly. Summary Statement = This is an=20 excellent proposal, with an excellent and diverse team of researchers = spanning=20 the experimental, modeling, numerical, IT, computer science, and = educational=20 aspects of the project. The proposal is innovative and risky, but likely = to=20 succeed in many important ways. It could revolutionize the way earth = scientists=20 view their field by facilitating the use of computational simulation. = The=20 educational component of the proposal is strong, and spans high school = through=20 postdoctoral training.

------=_NextPart_000_0074_01C14060.76174880-- From furbish@quartz.gly.fsu.edu Mon Jun 18 15:59:08 2007 Return-Path: Delivered-To: fox@csit.fsu.edu Received: from mask.uits.indiana.edu (mask.uits.indiana.edu [129.79.6.184]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 8A5C023A04 for ; Sun, 30 Sep 2001 16:13:01 -0400 (EDT) Received: from quartz.gly.fsu.edu (quartz.gly.fsu.edu [128.186.10.36]) by mask.uits.indiana.edu (8.10.1/8.10.1/IUPO) with ESMTP id f8UKAnr04429 for ; Sun, 30 Sep 2001 15:10:49 -0500 (EST) Received: from water (dial1487.acns.fsu.edu [146.201.38.202]) by quartz.gly.fsu.edu (8.10.2/8.10.2) with SMTP id f8UK8ht39367 for ; Sun, 30 Sep 2001 16:08:43 -0400 (EDT) From: "David Jon Furbish" To: Subject: RE: ITR 2 reviews Date: Sun, 30 Sep 2001 16:11:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3BB528B1.1060208@indiana.edu> Sender: furbish@quartz.gly.fsu.edu Geoffrey: I agree... I'm convinced that we delivered a prefectly fundable proposal. I've requested the panel review, and will forward it when NSF send it. Best regards David David Jon Furbish Department of Geological Sciences and Center for Earth Surface Processes Research Florida State University Tallahassee, Florida 32306-4100 (850)644-7494 (CESPR) (850)644-5892 (Geological Sciences) furbish@fsu.edu -----Original Message----- From: Geoffrey Fox [mailto:gcf@indiana.edu] Sent: Friday, September 28, 2001 9:50 PM To: David Jon Furbish Subject: Re: ITR 2 reviews These are pretty reasonable -- they could have funded it if they wanted to Is their no panel review? From nobody@nowhere Mon Jun 18 15:59:08 2007 Replied: Mon, 01 Oct 2001 15:29:59 -0400 Replied: "David Jon Furbish" Return-Path: furbish@fsu.edu Return-Path: Delivered-To: fox@csit.fsu.edu Received: from mask.uits.indiana.edu (mask.uits.indiana.edu [129.79.6.184]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 4D2DE23A01 for ; Mon, 1 Oct 2001 15:15:34 -0400 (EDT) Received: from quartz.gly.fsu.edu (quartz.gly.fsu.edu [128.186.10.36]) by mask.uits.indiana.edu (8.10.1/8.10.1/IUPO) with ESMTP id f91JDKk12568 for ; Mon, 1 Oct 2001 14:13:21 -0500 (EST) Received: from Furbish (furbish.cespr.fsu.edu [146.201.214.15]) by quartz.gly.fsu.edu (8.10.2/8.10.2) with SMTP id f91JAtt44876; Mon, 1 Oct 2001 15:10:55 -0400 (EDT) Message-ID: <019001c14aad$6d018ba0$0fd6c992@Furbish> From: "David Jon Furbish" To: "Jonathan Shewchuk" , "Robert Anderson" , "William Dietrich" , "James Syvitski" , "Tad Pfeffer" , "Chris Paola" , "Gary Parker" , "Vaughan Voller" , "Alan Howard" , "Patricia Wiberg" , "Rudy Slingerland" , "Greg Tucker" , "Geoffrey Fox" , "Mark Schmeeckle" , "M. Yousuff Hussaini" Subject: NSF panel summary Date: Mon, 1 Oct 2001 15:15:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018D_01C14A8B.E34C9100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 This is a multi-part message in MIME format. ------=_NextPart_000_018D_01C14A8B.E34C9100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi - The Panel Summary (below) for the ITR 2 proposal was just released... David Panel Summary #1 PROPOSAL NO.: 0122483=20 PANEL SUMMARY: The panel ranks this proposal as competitive.=20 The general sense was that this was an ambitious proposal, with strong = intellectual merit. There was concern about whether this was too = ambitious, and about the proposed management. These and other concerns = are reflected in the individual reviews.=20 All unconflicted panelists have read and approved this summary.=20 PANEL RECOMMENDATION: Competitive ------=_NextPart_000_018D_01C14A8B.E34C9100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi -
 
The Panel Summary (below) for the ITR 2 = proposal=20 was just released...
 
David
 
 
 

Panel Summary #1

PROPOSAL=20 NO.: 0122483=20

PANEL SUMMARY:
The panel ranks this proposal as = competitive.=20

The general sense was that this was an ambitious proposal, with = strong=20 intellectual merit. There was concern about whether this was too = ambitious, and=20 about the proposed management. These and other concerns are reflected in = the=20 individual reviews.

All unconflicted panelists have read and = approved=20 this summary.



PANEL RECOMMENDATION:=20 Competitive

------=_NextPart_000_018D_01C14A8B.E34C9100-- From furbish@fsu.edu Mon Jun 18 15:59:08 2007 Return-Path: Delivered-To: fox@csit.fsu.edu Received: from quartz.gly.fsu.edu (quartz.gly.fsu.edu [128.186.10.36]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 8F34123A03 for ; Mon, 1 Oct 2001 15:34:32 -0400 (EDT) Received: from Furbish (furbish.cespr.fsu.edu [146.201.214.15]) by quartz.gly.fsu.edu (8.10.2/8.10.2) with SMTP id f91JUEt45061 for ; Mon, 1 Oct 2001 15:30:14 -0400 (EDT) Message-ID: <01b701c14ab0$1d553ef0$0fd6c992@Furbish> From: "David Jon Furbish" To: "Geoffrey Fox" References: <200110011929.PAA86460@dirac.csit.fsu.edu> Subject: Re: NSF panel summary Date: Mon, 1 Oct 2001 15:34:40 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B4_01C14A8E.9632D610" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 This is a multi-part message in MIME format. ------=_NextPart_000_01B4_01C14A8E.9632D610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Geoffrey... Yes, they played it perfectly safe! djf ----- Original Message -----=20 From: Geoffrey Fox=20 To: David Jon Furbish=20 Sent: Monday, October 01, 2001 3:29 PM Subject: Re: NSF panel summary=20 Content free! =20 Geoffrey Fox gcf@indiana.edu FAX 8128567972 Phones Cell 315-254-6387 Home 8123239196 Lab 8128567977 CS 8128553788 ------=_NextPart_000_01B4_01C14A8E.9632D610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Geoffrey...   Yes, they = played it=20 perfectly safe!   djf
 
----- Original Message -----
From:=20 Geoffrey Fox
Sent: Monday, October 01, 2001 = 3:29=20 PM
Subject: Re: NSF panel summary =

Content free!
 
 Geoffrey Fox  gcf@indiana.edu FAX=20 8128567972
 Phones Cell 315-254-6387 Home 8123239196 Lab = 8128567977 CS=20 8128553788
------=_NextPart_000_01B4_01C14A8E.9632D610-- From furbish@quartz.gly.fsu.edu Mon Jun 18 15:59:08 2007 Return-Path: Delivered-To: fox@csit.fsu.edu Received: from mask.uits.indiana.edu (mask.uits.indiana.edu [129.79.6.184]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 84A0223A1F for ; Mon, 1 Oct 2001 20:26:34 -0400 (EDT) Received: from quartz.gly.fsu.edu (quartz.gly.fsu.edu [128.186.10.36]) by mask.uits.indiana.edu (8.10.1/8.10.1/IUPO) with ESMTP id f920OIk12294 for ; Mon, 1 Oct 2001 19:24:19 -0500 (EST) Received: from water (dial1459.acns.fsu.edu [146.201.38.174]) by quartz.gly.fsu.edu (8.10.2/8.10.2) with SMTP id f920Kjt46611; Mon, 1 Oct 2001 20:20:45 -0400 (EDT) From: "David Jon Furbish" To: "Alan Howard" , "Chris Paola" , "David Jon Furbish" , "Gary Parker" , "Geoffrey Fox" , "Greg Tucker" , "James Syvitski" , "Jonathan Shewchuk" , "M. Yousuff Hussaini" , "Mark Schmeeckle" , "Patricia Wiberg" , "Robert Anderson" , "Rudy Slingerland" , "Tad Pfeffer" , "Vaughan Voller" , "William Dietrich" Subject: ITR 3... :-( Date: Mon, 1 Oct 2001 20:23:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_01C14AB6.E11ECD00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: furbish@quartz.gly.fsu.edu This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C14AB6.E11ECD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi - If one of you wishes to take a lead on an ITR 3, I shall do whatever I can to help if you ask me to. (The pre-proposal deadline is early November.) But otherwise I'm done. I sincerely thank you for your input and help on the earlier tries; we gave it a couple good shots. Cheers, David David Jon Furbish Department of Geological Sciences and Center for Earth Surface Processes Research Florida State University Tallahassee, Florida 32306-4100 (850)644-7494 (CESPR) (850)644-5892 (Geological Sciences) furbish@fsu.edu ------=_NextPart_000_0013_01C14AB6.E11ECD00 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgYAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCgABABQAFgAAAAEADgEB A5AGAEwGAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAEQAAAElUUi4uLiAgSSdtIGRvbmUAAAAAAgFxAAEAAAAWAAAAAcFK1kiHzWA0nF1lTJO0SseL YGUIWAAAAgEdDAEAAAAZAAAAU01UUDpGVVJCSVNIQEdMWS5GU1UuRURVAAAAAAsAAQ4AAAAAQAAG DgBElUDYSsEBAgEKDgEAAAAYAAAAAAAAAPXWDAHQzeNMrZw1hfg0HvrCgAAACwAfDgEAAAACAQkQ AQAAAF4CAABaAgAACwMAAExaRnUA3fMcAwAKAHJjcGcxMjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBj aArAc/BldDAgBxMCgwBQA9WVEXV9CoF2CJB3awuAdGQ0DGBjAFALAwu1IHBIaSAtCqIKhAqASbRm IAIgZRYgFhB5CGBKIAPxaAeRdG8XQGECaxZQYSBsZWFkBxYhF8ADoElUUiAzuiwYkCAXAAdAAyBk F2BidxDwdGV2BJAZAWPHA5EXURcQbHAgBpAWkzBhc2sgB4AXQS4gSCAoVBcQIHAJcC3hHLBvcG9z B0AZgBgBLmwLgBZQBAAgGABybDp5B7BvGhAG0ASQLilJHEBCdQVAb3QXEHLjA/EWUEknbRmBFkAc MfsZEQuAYwSQGvAegB+wAHB/G8AWogIQBcAWoQXAC4Bw/x9xAHAYIBrjGEEfsR4zCJEzF0AIgXM7 FtAWUGdhfxoQGyAjIRpgCGALUCVBb6cEcBkhH6BzLhVKQxcQqQSQcywVREQlcGkLMUsVaBHxICiz IEoYQUatCHBiFvEoVWUKsXQHgNMCMBZiR2UI8WcN4B1R/FNjCJAhMQQgI0EpZhFQuxxAKcJDK+Ea ISJSRSuhtmgGAAhwZgDQFlBQA2D3LVERIAQgUgeQHkEQ4BVEbkYJASjgF9BTAZAZ8CBOVQMAGhEA kHR5FURUbRlRYRDwMKFlGPAx1jPAMjMwNi00D0ABQAEt1yg4NTApNjRANC03NDk0HFBD4EVTUFIp EfIVUzZH2DU4OQ5QLjIoLF8HkJU3iGYqtEAD0HUuCYAvDHApGzWVExEAPaAAAAsAAYAIIAYAAAAA AMAAAAAAAABGAAAAAAOFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeA CCAGAAAAAADAAAAAAAAARgAAAABShQAAfW4BAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAAB AAAABAAAADkuMAALAA2ACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsAOoAIIAYAAAAAAMAA AAAAAABGAAAAAA6FAAAAAAAAAwA8gAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAD2ACCAG AAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAMAW4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAA CwBsgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAACAfgPAQAAABAAAAD11gwB0M3jTK2cNYX4 NB76AgH6DwEAAAAQAAAA9dYMAdDN40ytnDWF+DQe+gIB+w8BAAAAlQAAAAAAAAA4obsQBeUQGqG7 CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBh bmQgU2V0dGluZ3NcZGpmXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0 XE91dGxvb2tcb3V0bG9vay5wc3QAAAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMwAAADxPREVN S05KTU1BRkRQRURGTU9ESElFQkRDQkFBLmZ1cmJpc2hAZ2x5LmZzdS5lZHU+AAADAAYQ6y38IwMA BxCuAQAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEhJLUlGT05FT0ZZT1VXSVNIRVNUT1RB S0VBTEVBRE9OQU5JVFIzLElTSEFMTERPV0hBVEVWRVJJQ0FOVE9IRUxQSUZZT1VBU0tNRVRPKFRI RVBSRS1QUk9QT1NBTERFQURMSU4AAAAADWo= ------=_NextPart_000_0013_01C14AB6.E11ECD00-- From James.Syvitski@colorado.edu Mon Jun 18 15:59:08 2007 Return-Path: Delivered-To: fox@csit.fsu.edu Received: from fins.uits.indiana.edu (fins.uits.indiana.edu [129.79.6.185]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 5539A23A0A for ; Tue, 2 Oct 2001 16:56:05 -0400 (EDT) Received: from stripe.colorado.edu (stripe.Colorado.EDU [128.138.129.14]) by fins.uits.indiana.edu (8.10.1/8.10.1/IUPO) with ESMTP id f92Ku4E14523 for ; Tue, 2 Oct 2001 15:56:04 -0500 (EST) Received: from [128.138.153.45] (litr153-45.Colorado.EDU [128.138.153.45]) by stripe.colorado.edu (8.11.6/8.11.2/ITS-5.0/standard) with ESMTP id f92KtrQ27017; Tue, 2 Oct 2001 14:55:53 -0600 (MDT) X-Sender: syvitski@stripe.colorado.edu Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 Oct 2001 14:56:08 -0600 To: "David Jon Furbish" From: James Syvitski Subject: Re: ITR 3... :-( Cc: "Alan Howard" , "Chris Paola" , "David Jon Furbish" , "Gary Parker" , "Geoffrey Fox" , "Greg Tucker" , "Jonathan Shewchuk" , "M. Yousuff Hussaini" , "Mark Schmeeckle" , "Patricia Wiberg" , "Robert Anderson" , "Rudy Slingerland" , "Tad Pfeffer" , "Vaughan Voller" , "William Dietrich" Dave you have done a great job. It reminds me of an ODP leg I want to get drilled. After pushing the project for five years I was spent and turned it over to John Andrews and David Piper who after another five years have almost got the project off the ground. I smile as I hear the latest efforts towards the drilling, with memory of my original efforts long forgotten. In the end we do this stuff for our science and discipline. Seldom does recognition for failed effort properly tracked or rewarded. In this case, we should all make an exception because you have done a fantastic service to our community. Chris P, Rudy S and myself need to concentrate on getting the Source to Sink MARGINS Community Sediment Model meeting off the ground with the first workshop in Boulder in Feb 20, 22. I think that you should come, represent, flag and take the credit for our ITR proposal. It provides all with a firm foundation for us to collectively move forward. Again thanks for your valiant efforts. James >Hi - > >If one of you wishes to take a lead on an ITR 3, I shall do whatever I can >to help if you ask me to. (The pre-proposal deadline is early November.) >But otherwise I'm done. I sincerely thank you for your input and help on >the earlier tries; we gave it a couple good shots. > >Cheers, >David > >David Jon Furbish >Department of Geological Sciences and > Center for Earth Surface Processes Research >Florida State University >Tallahassee, Florida 32306-4100 >(850)644-7494 (CESPR) >(850)644-5892 (Geological Sciences) >furbish@fsu.edu /\ James Syvitski /\/ /\ Director, Institute of Arctic & Alpine Research / /\/\ University of Colorado at Boulder / /\/ \ 1560 30th Street, Campus Box 450 / / \ \ Boulder CO, 80309-0450 / /\ \ \ 303-492-7909 or fax 303-492-3287 / / \ INSTAAR \ email: james.syvitski@colorado.edu http://instaar.colorado.edu/geophysics