Software Coordinating Committee Conference Call August 30, 2001 1:00 PM EDT Recorder: C. DeTar Present: Brower, DeTar, Edwards, Mendez, Watson, Mawhinney Absent: Holmgren, Simone, Pochinski ** = action required 1. Jlab meeting date: Thurs - Sat if possible ** Watson: Will confirm. 2. Robert Edwards presents his LQCD Linear Algebra (Level 2) proposal Q: What layout assumptions are being made at this level? Mawhinney: Most code isn't written to this layer, and will not deliver the best performance. DeTar: Want to maintain flexibility so shift operation can handle an arbitrary layout if it has to. Edwards: Need to allow different possible data layouts Want to overlap computations and communications Watson: Specify layout index Edwards: Predefined channels open for communications Brower: Can the proposed interface be done in C? Edwards: No, needs C++. DeTar: Do you mean to combine shifts and ops so the ops can act on local data while waiting for off-node data? Edwards: Yes - details to be worked out. Brower: Are we assuming we are going to use a macro language? Edwards: It could be implemented entirely with C++. Mawhinney: What are the functions visible to the user? Edwards: See example 2. Mawhinney: Should think about size of code we are writing to assure it fits into instruction cache. The PowerPC 440 has 32 KB instruction cache - 4 MB on chip, so maybe 0.5 MB for code. DeTar: Would like to see how to overlap communication and computation within C++ Edwards: In C++ - for shift and multiply - shift returns a new shifted data type. Overloaded multiply would act on the shifted type by calling an appropriate multiply-shift routine. This is standard lazy type technique in C++. Brower: How long would this take to implement? Let's carve out a vertical slice we can deliver by Nov 7. Mawhinney: What about our goal of implementing existing code on the API? Robert's illustration would be fine if we are starting from scratch. What do we need for existing code? Brower: How many variants of data layouts are we dealing with with legacy code? Three: MILC, CPS, SZIN? Others? ** Brower: Let's all write up a specification of data layouts for gauge fields and spinors. ** Watson: and how much work it would require to change it? ** Mawhinney: and start from the Dirac operator to get connection convention. Brower: At the very least, we should present at the Jlab meeting a statement of where we are heading. DeTar: For immediate results, MILC code can be ported quickly at the Level 1 MP_API. Brower: And Level 2 is what we will need as we go forward. Mawhinney: Level 1 LINALG might be incorporated into future CPS Brower: Need a working example to present for discussion at Jlab and we need to list the supported repertoire of functions. 3. API's - general issues Mawhinney: C, C++ callable variants Mawhinney: What about memory management in MP-API? ** Watson: Can expand existing document to include C++ Latest document is: http://www.jlab.org/~watson/lqcd/MessageAPI.htm ** Brower: Will make it easier to find latest document on SciDAC web site. 4. Priorities DeTar: Getting the MP API fleshed out would be my highest priority. ** Brower: Send document saying what we think critical projects are and who can work on them. Need specific schedule. e.g. MP_API: MPI version. by Sept 30 ** Brower: Will set a regular biweekly meeting time to reserve telebridge. Next call TBA Friday Sep 14 if possible. Call concluded at 5:00 PM EDT.