Hi Marcus, OK, I see I have mis-categorizd Ccaffeine/GUI, it belongs with PCS tools. Regarding the tight integration of messaging and events with components, I see that more of an issue in Pipeline Execution than in System Control & Management. I am not yet convinced one technology applies to messaging/events in both of those contexts. Looking forward to discussing this at the MW telecon. Thanks!
Jeff > From: "W. Marcus Miller" <[EMAIL PROTECTED]> > Organization: LLNL > Reply-To: [EMAIL PROTECTED] > Date: Tue, 25 Apr 2006 16:10:16 -0700 > To: [email protected] > Cc: Jeffrey P Kantor <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: [LSST-data] MiddleWG - Re: UCF Paper and the State of the > Middleware Baseline > > Hi Jeff, > > A few comments in context below. > >> OK, so according to Marcus it sounds like we are in a promising space with >> CCA frameworks. The combination of tools Marcus mentioned in the last >> paragraph sounds like an environment worth evaluating. I have also >> recently been having Robyn look at MPI 2.0/OpenMPI for pipeline glue as >> well, and it also looks promising. All of these evaluations make sense in >> the overall D&D phase. >> >> But we still don't have a good picture of the reference design for the >> MREFC proposal estimate. I want to identify the gaps as of now. Looking >> at our current middleware baseline, if I understand things properly we >> have: >> >> DM System Control and Management >> - OGRE/Elf for facility-level control/workflow >> - DTS, Gridftp for data transfers between facilities ( I think we also >> need to look at Alex Szalay's contact at University of Chicago for a >> UDP-based protocol stack that facilitates high-speed data transfer over >> long-haul networks. This has been used on internet2 land speed records) > > There are also one or more Parallel FTP (PFTP) and Parallel Sockets (Psocks) > protoypes that use multiple simultaneous connections to obtain higher > B/W (for both WAN and SAN). PFTP is just an application replacement for > FTP that uses the conventional BSD sockets API. Psocks is a reimplementation > of the BSD sockets library to exploit parallelism and is "mostly" transparent > to the application. > >> - StageCollection/globus-url-copy for data staging within a facility >> - TBD Middleware for events, messaging, logging across facilities and >> integration with OCS (evaluating RTI NDDS, MULE, JMS, what else?) > > See below, but a tight integration of messaging and events with the component > framework would allow the component builder to do consistency checks > and allow the mechanism to support multi-laungage bindings. >> >> Pipeline Execution Middleware >> - Python Framework Classes (per the UML Model), encapsulating Application >> Layer calls to the following: >> - MPI for intra-stage science data communications (within a parallelized >> processing stage) >> - TBD middleware for inter-stage science data communications, aka "pipeline >> glue" (evaluating ZeroC ICE, OpenMPI, RTI NDDS, MULE, JMS, what else?) >> - TBD Middleware for events, messaging, logging by an executing pipeline >> (evaluating ZeroC ICE, RTI NDDS, MULE, JMS, what else?) >> - GridDB descendent for smart re-processing analysis >> >> Pipline Construction >> - Python, C++, Java for creating "raw" components >> - Eclipse with CCA plug-in, Babel/SIDL, SWIG for component wrapping/ >> integration with Pipeline Execution Middleware > > To use CCA to build an LSST pipeline one could: > > 1) Create component interfaces for Astronomy algorithms by defining > CCA "ports" and "methods" that implement those ports (ports are > programming language neutral and allow components to be written in > any supported language). > -> Write SIDL definition for ports and implementation interface. > > 2) Compile and Store component interface definition (SIDL) in repository. > -> Run Babel compiler to produce XML representation for component interface. > > 3) Target component. > -> Run Babel compiler to build and link executable component for specific > platform and framework targets. > > 4) Sequence and execute components using CCA component framework > (Ccaffeine, SCIRun2, XCAT, etc., or LSST Custom framework). > > Step 4 is the area that needs the most specialization for LSST pipelines. > Ideally we would have an LSST specific framework that constitute 90% of > the PCS and 50-70% of the PE middleware. > > Eclipse with the appropriate plugin could provide a component creation > and editing GUI with CCA port compatibility and validity checking capabilities > (by manipulating and creating SIDL and runing Babel to create the XML files). > A GUI similar to the Ccaffeine GUI could be adapted to assemble components > into a pipeline. >> >> Data Access Framework >> - MySQL, Xrootd, C++ for DBMS with parallel ingest/query >> - DCI, SRB, Ibrix (or Lustre? Xrootd?) for image file storage, replication >> >> Securit and Administration >> - NSA/Public Domain Certificate Manager for Security >> - Other tools, services? >> >> User Interface Services >> - Ccaffeine/GUI for ??? > > Ccaffeine is a CCA framework (considered the CCA reference implementation) > that supports using and executing components in distributed memory parallel > computing with single program, multiple data (SPMD) style programming. > Ccaffeine/GUI is the reference GUI that can be used to graphically assemble > the componets into an executable program, i.e. connect CCA "uses" and > "provides" ports. > > XCAT is another CCA framework (Indiana University) that supports grid > based parallel execution of CCA components. > >> - Mirage/Java for web-enabled scientific plots and graphs, in a >> multi-window environment >> - All manner of VO-compliant tools >> >> Am I mis-stating or missing anything? >> >> My biggest concern is validating this and filling in the TBDs. Is there a >> CCA framework that fills in TBDs and if so where does it fit? > > I'm not aware of a framework that provides 100% of the LSST pipeline > requirements, but there are many frameworks and more coming > in development, so there is hope that we may leverage a large amount > of existng framework code (most CCA based frameworks I know of are > open source). As I suggested above, I think we are going to need to > customize an existing framework for LSST to meet the multi-language > PCS and multi-target PE requirements. > >> What >> evaluations can be done by May 20 to resolve TBDs in time for inclusion in >> the cost estimates/development schedules? > > With respect to PCS, we should write and test some "simplistic" > CCA components (perhaps a single pipeline algorithm), then run this against > several of the framework candidates to better understand the pitfalls. > An investigation of the "events" and "bulletin board" implementation > using a CCA framework after this would also be good, but likely not feasible > by May 20 deadline. > > -Marcus > >> >> Jeff >> >>> From: "W. Marcus Miller" <[EMAIL PROTECTED]> >>> Organization: LLNL >>> Reply-To: [EMAIL PROTECTED] >>> Date: Mon, 24 Apr 2006 17:21:11 -0700 >>> To: Jeffrey P Kantor <[EMAIL PROTECTED]> >>> Cc: Ray Plante <[EMAIL PROTECTED]>, Michelle Miller >>> <[EMAIL PROTECTED]>, Tim Axelrod <[EMAIL PROTECTED]>, don Dossa >>> <[EMAIL PROTECTED]>, Ghaleb Abdulla <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >>> Subject: Re: UCF Paper >>> >>> Hi Jeff, >>> >>> It has taken a while to slog though all my e-mail after last weeks >>> travel, so this comes a bit delayed. >>> >>> SciRun/2 and UCF/Uintah are both Frameworks based on the Common >>> Components Architecture (CCA) Forum specification. UCF is a components >>> framework for simulating PDEs in parallel on Structured Adaptive Mesh >>> Refinement Grids (much like the LLNL SAMRI package). After reading the >>> attached paper, my sense is that UCF is likely too domain specific (PDE >>> solver using SAMR) for LSST pipelines. >>> >>> Other CCA implementations/tools such as Ccaffeine/GUI, Eclipse with >>> CCA plugin support and Babel/SIDL (cross language interoperability >>> components compiler) provide the capability for creating interoperable >>> components in C/C++/Python/Fortran90/Java without the domain specific >>> specializations of UCF. A CCA framework that couples LSST Pipeline >>> Middleware and Astronomy specific domain libraries could provide >>> both multi-language component support, and LSST specific methods >>> (pipelline event registration/notifications, bulletin board >>> services/common address space, etc). >>> >>> -Marcus >>> >>> On Wednesday 19 April 2006 11:50, Jeffrey P Kantor wrote: >>>> Hi Ray, Marcus, Michelle, >>>> >>>> This UCF framework looks very interesting, lighter weight than UIMA, >>>> some features for "steering" execution, and is based on SciRun, which >>>> Michelle worked on. I think it should move up to the top of the eval >>>> list, along with the rest of the messaging/glue middleware. However, >>>> I'm not sure it is publicly available, so we may need to see if Michelle >>>> can work a connection at Utah. Thanks! >>>> >>>> Jeff >>> >>> -- >>> W. Marcus Miller, Ph.D. >>> Lawrence Livermore National Laboratory >>> Mail Stop L-560 Tel : (925) 424-4147 >>> 7000 East Avenue FAX : (925) 422-6287 >>> Livermore, CA 94550 e-mail: [EMAIL PROTECTED] >> >> _______________________________________________ >> LSST-data mailing list >> [email protected] >> http://www.lsstmail.org/mailman/listinfo/lsst-data > > -- > W. Marcus Miller, Ph.D. > Lawrence Livermore National Laboratory > Mail Stop L-560 Tel : (925) 424-4147 > 7000 East Avenue FAX : (925) 422-6287 > Livermore, CA 94550 e-mail: [EMAIL PROTECTED] > _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
