[Swift-devel] Swift Performance Data

[Mike Wilde]

I have not been reading email this weekend and need to catch up on this and 
related threads.

I want to ask that for the moment Ben and Mihael stay focused on what they are 
working on, and I will work with Nika and Tibi on application status and issues, 
and move the measurement issue along.

I agree fully with Mihael's point that we can and should start gathering all 
execution logs into a uniformly structured gathering place. Then we can organize 
the current log tools and determine whats needed next in that area.

For now:

Ben: Swift 0.2 and mapper/language improvements

Mihael: get to a closure point on I2U2 to get the last 4 months of work into 
production (or at a stable development lab for a next-generation production 
system). Determine when you can be back on Swift.

Nika: MolDyn-244 and defining the MolDyn parameter sweep workflow;
  Next steps (TBD) on LQCD progress;

Tibi: Econ - next workflow; set up environment for Econ to adopt tools. Work 
with new people in Econ to take over from Gabrielle. I2U2 load sharing into 
production, and assist in LIGO app.  SIDGrid Wavelet: tbd.

Nika and Tibi: application writeups

Next apps: FLASH, RADCAD; possibly SCEC exploration.

- Mike


Ben Clifford wrote, On 6/25/2007 8:54 AM:
> On Mon, 25 Jun 2007, Mihael Hategan wrote:
> 
>> Another difficulty is that if we want meaningful things in that 
>> particular format, the whole software stack needs to be changed 
>> (including cog and jglobus and perhaps other things). This sounds a bit 
>> difficult, especially considering the fact that the information is 
>> there, but the format is not. I'd rather write a few simple parsers than 
>> try to change all logging messages everywhere.
> 
> 'a few simple parsers' is not necessarily 'simple'.
> 
> changing logging messages in code everywhere definitely isn't, though.
> 
> if there is going to be more than one analysis tool, converting log files 
> to a common format somewhere in between generating application and 
> analysing application might be a good idea, and not massively different 
> from defining a language level API to abstract out log file format 
> differences.
> 

-- 
Mike Wilde
Computation Institute, University of Chicago
Math & Computer Science Division
Argonne National Laboratory
Argonne, IL   60439    USA
tel 630-252-7497 fax 630-252-1997