To:soft Subject: REMINDER SOFTWARE CALL TOMORROW --text follows this line-- All, Dates: January 23, 2003 Day: Thursdays Time: 3 PM to 5 PM, EDT Telephone Number Assigned: 617-258-7910 Agenda:=============================================================== 1.) REMINDER: We have a Software Workshop on Thursday, Feb 20 -- starting at 9:00AM, the day before the All Hands Meeting. Remind SciDAC postdocs and other crucial members of our effort to come! There will also be a "tutorial" on using SciDAC software on Feb 22 Saturday afternoon, after the All Hands meeting, being organized by Robert E, Carleton D. and myself. Remind interested participants to schedule late flights. 2.) QCDOC Acceptance Tests Prior to funding a full scale QCDOC machine in 2004, to satisfy the the DOE (let alone our SciDAC community!) we must submit the prototype machine to an adequate set of acceptance tests. They fall into 4 categories: Hardware OS Reliability Application code performance. The first three are the responsibility of the builder for the QCDOC but the Software Commmitte needs to flesh out the last set of tests (see bullet one under Oct 1, 2003 in http://physics.bu.edu/~brower/tests/). They should be exclusively focussed on the QCDOC. They should be definite, few in number but adequate to convince ourselves that the QCDOC is a viable production machine. We must specify fully who is doing them and all the steps need to insure they are ready in time --- possibly as early as mid summer 2003 but more likely no sooner that Sept 1, 2003. I think they should be real applications that are being run on the FNAL/JLab clusters during summer 2003 so relative performance and easy of use can easily be compared. My first thoughts: a.) Generic C application code: (e.g. MILC Asqtad HMC over QMP without and with level 3 inverter. Carleton make suggestions.) b.) SciDAC QDP++ application code: (e.g. QDP++ Clover Wilson code for structure functions without and with level 3 inverter. See Robert E's suggestion.) c.) CPS application code: Bob M sepecify application and performance. These should be honest production level tests, with remote access, file I/O etc. What % of peak should we set? I think it should not be too high but high enough to ensure that physics can be accomplished at a price competative level compared to the same code running on clusters. 3.) I/O work ---- what's next? Rich -- Prof. Richard C. Brower Physics Department --Boston University 590 Commonwealth Ave. Boston, MA 02215 Tele: 617 353 6052 (BU) 617 253 2599 (MIT) 617 497 8296 (HOME) Fax: 617 353 9393 Email: brower@bu.edu brower@lns.mit.edu ====================================================================== Stawman Acceptance Test (Robert Edwards, Jan 22, 2003) SciDAC Acceptance requirements for Phase II hardware Justification: Current SciDAC grant funding software and hardware infrastructure for next generation (Phase II) hardware. The new hardware should support this software (and vice-versa). Performance (minimal requirements): Phase I software should allow inclusion (call-outs) to suitable specialized inverters/operators. No other major performance criteria set for Phase I software. Assumptions: User code written using Level 2 QDP++ applications built over QMP. Application description (short): Under a queuing system (PBS), a script runs launching a QDP++ application which reads input parameters and a config. It computes a clover propagator - saves to disk. Next application reads said prop and config, ties to make seq. source, inverts, and combines to compute a nucleon formfactor. Sample application: 1) User writes shell script suitable for running under PBS or some other queuing system. (NOTE: assumption for QCDOC there is a front-end where the script runs. For a cluster, this maybe a compute node or a front-end.) 2) Script calls some job launcher to run job on hardware. 3) Input (parameter) file for QDP++ read and parameters broadcasted throughout computing notes. a) (Minimal) Input can be simple ascii with no markup. b) (Advanced) Input in QDP I/O format with markup 4) QDP++ application initialized and reads a SU(3) configuration with parallel I/O. a) (Minimal) Configuration can be a simple binary in a proprietary format. b) (Advanced) I/O done using QDP I/O. 5) QDP++ applications computes the (complete - all 12 color/spin sources) Clover propagator a) (First option) Using only level 2 interface b) (Second option) Using callout to optimized inverter 6) Application writes propagator to disk with parallel I/O. a) (Minimal) Propagator written in a simple binary format. b) (Advanced) I/O dones using QDP I/O. 7) Application exits returning control to script. 8) Script launches another QDP++ application. 9) As in (3) and (4), input file read and configuration read. 10) Application reads propagator (inverse of (6)) 11) Sequential source constructed for a nucleon E&M formfactor 12) Clover progagator computed and saved (6) 13) Propagators tied and formfactor computed. 14) Application writes observables to disk (ultimately front-end) a) (Minimal) Written in simple ascii b) (Advanced) Written in QDP I/O with markup. 15) Application exits returns control to script. 16) Possibly any files returned to front-end. Script exits. Next job in queue runs. From brower@lns.mit.edu Wed Jan 22 18:41:27 2003 Date: Wed, 22 Jan 2003 18:40:25 -0500 From: Richard Brower To: cmendes@cs.uiuc.edu, detar@physics.utah.edu, djholm@fnal.gov, edwards@jlab.org, watson@jlab.org, rdm@phys.columbia.edu, brower@lns.mit.edu, avp@lns.mit.edu, simone@fnal.gov, osborn@physics.utah.edu, petrov@physics.columbia.edu, mdp@fnal.gov, dgr@jlab.org, hneff@bu.edu, jhetrick@uop.edu CC: sugar@savar.physics.ucsb.edu, rebbi@pthind.bu.edu Subject: REMINDER SOFTWARE CALL TOMORROW All, Dates: January 23, 2003 Day: Thursdays Time: 3 PM to 5 PM, EDT Telephone Number Assigned: 617-258-7910 Agenda:=============================================================== 1.) REMINDER: We have a Software Workshop on Wednesday, Feb 20 -- starting at 9:00AM, the day before the All Hands Meeting. Remind SciDAC postdocs and other crucial members of our effort to come! There will also be a "tutorial" on using SciDAC software on Feb 22 Saturday afternoon, after the All Hands meeting, being organized by Robert E, Carleton D. and myself. Remind interested participants to schedule late flights. 2.) QCDOC Acceptance Tests Prior to funding a full scale QCDOC machine in 2004, to satisfy the the DOE (let alone our SciDAC community!) we must submit the prototype machine to an adequate set of acceptance tests. They fall into 4 categories: i. Hardware ii. OS iii. Reliability iv. Application code performance. The first three are the responsibility of the builders of QCDOC but the Software Commmitte needs to flesh out the last set of tests (see bullet one under Oct 1, 2003 in http://physics.bu.edu/~brower/tests/). They should be exclusively focussed on the QCDOC. They should be definite, few in number but adequate to convince ourselves that the QCDOC is a viable production machine. We must specify fully who is doing them and all the steps need to insure they are ready in time --- possibly as early as mid summer 2003 but more likely no sooner that Sept 1, 2003. I think they should be real applications that are being run on the FNAL/JLab clusters during summer 2003 so relative performance and easy of use can easily be compared. My first thoughts: a.) Generic C application code: (e.g. MILC Asqtad HMC over QMP without and with level 3 inverter. Carleton make suggestions.) b.) SciDAC QDP++ application code: (e.g. QDP++ Clover Wilson code for structure functions without and with level 3 inverter. See Robert E's suggestion.) c.) CPS application code: Bob M sepecify application and performance. These should be honest production level tests, with remote access, file I/O etc. What % of peak should we set? I think it should not be too high but high enough to ensure that physics can be accomplished at a price competative level compared to the same code running on clusters. 3.) I/O work ---- what's next? Rich -- Prof. Richard C. Brower Physics Department --Boston University 590 Commonwealth Ave. Boston, MA 02215 Tele: 617 353 6052 (BU) 617 253 2599 (MIT) 617 497 8296 (HOME) Fax: 617 353 9393 Email: brower@bu.edu brower@lns.mit.edu ====================================================================== Stawman Acceptance Test (Robert Edwards, Jan 22, 2003) SciDAC Acceptance requirements for Phase II hardware Justification: Current SciDAC grant funding software and hardware infrastructure for next generation (Phase II) hardware. The new hardware should support this software (and vice-versa). Performance (minimal requirements): Phase I software should allow inclusion (call-outs) to suitable specialized inverters/operators. No other major performance criteria set for Phase I software. Assumptions: User code written using Level 2 QDP++ applications built over QMP. Application description (short): Under a queuing system (PBS), a script runs launching a QDP++ application which reads input parameters and a config. It computes a clover propagator - saves to disk. Next application reads said prop and config, ties to make seq. source, inverts, and combines to compute a nucleon formfactor. Sample application: 1) User writes shell script suitable for running under PBS or some other queuing system. (NOTE: assumption for QCDOC there is a front-end where the script runs. For a cluster, this maybe a compute node or a front-end.) 2) Script calls some job launcher to run job on hardware. 3) Input (parameter) file for QDP++ read and parameters broadcasted throughout computing notes. a) (Minimal) Input can be simple ascii with no markup. b) (Advanced) Input in QDP I/O format with markup 4) QDP++ application initialized and reads a SU(3) configuration with parallel I/O. a) (Minimal) Configuration can be a simple binary in a proprietary format. b) (Advanced) I/O done using QDP I/O. 5) QDP++ applications computes the (complete - all 12 color/spin sources) Clover propagator a) (First option) Using only level 2 interface b) (Second option) Using callout to optimized inverter 6) Application writes propagator to disk with parallel I/O. a) (Minimal) Propagator written in a simple binary format. b) (Advanced) I/O dones using QDP I/O. 7) Application exits returning control to script. 8) Script launches another QDP++ application. 9) As in (3) and (4), input file read and configuration read. 10) Application reads propagator (inverse of (6)) 11) Sequential source constructed for a nucleon E&M formfactor 12) Clover progagator computed and saved (6) 13) Propagators tied and formfactor computed. 14) Application writes observables to disk (ultimately front-end) a) (Minimal) Written in simple ascii b) (Advanced) Written in QDP I/O with markup. 15) Application exits returns control to script. 16) Possibly any files returned to front-end. Script exits. Next job in queue runs.