<div dir="ltr">Mike, my answers below:<div><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 8, 2013 at 12:00 PM, Michael Wilde <span dir="ltr"><<a href="mailto:wilde@mcs.anl.gov" target="_blank">wilde@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">was: Re: Swift team meeting today - 2PM central - Agenda<br>
<br>
Ketan, what did people think about this? Did you discuss what Swift/T has?<br></blockquote><div><br></div><div style>Mihael opined that it makes sense for small and simple apps but worried it could grow out of control over time as there are numerous ways in which apps could be written currently. I know Swift/T uses import lot but we did not discuss it in app library context.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
How would this be driven by real needs?<br></blockquote><div><br></div><div style>Start with demoing the idea by using import "applib" in Swift source so users do not need to write app declarations in there code. They just need to define data, loops and make app calls. 'type file;' should also be part of applib as it is used in 99% of Swift scripts. Promote this style of programming and gradually build app libraries for science use cases by domain say "chemlib", "mdlib", and so on.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What doc would be needed to make it useful and used?<br></blockquote><div><br></div><div style>We will need to identify app patterns and document them. Then try to fit as many real app calls as possible in these patterns. We will need to document and illustrate their usage. There will be outliers which won't fit in any patterns and then there will be users who would want to declare there own apps. Hopefully, users would be encouraged to put their apps in their own libs and re-use them. We could absorb new apps into our applibs as they get widely used.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- Mike<br>
<br>
----- Original Message -----<br>
> From: "Ketan Maheshwari" <<a href="mailto:ketancmaheshwari@gmail.com">ketancmaheshwari@gmail.com</a>><br>
> To: "Justin M Wozniak" <<a href="mailto:wozniak@mcs.anl.gov">wozniak@mcs.anl.gov</a>><br>
> Cc: "Michael Wilde" <<a href="mailto:wilde@mcs.anl.gov">wilde@mcs.anl.gov</a>>, "David Kelly" <<a href="mailto:davidk@ci.uchicago.edu">davidk@ci.uchicago.edu</a>>, "Mihael Hategan"<br>

> <<a href="mailto:hategan@mcs.anl.gov">hategan@mcs.anl.gov</a>>, "Ketan Maheshwari" <<a href="mailto:ketan@mcs.anl.gov">ketan@mcs.anl.gov</a>>, "Tim Armstrong" <<a href="mailto:tga@uchicago.edu">tga@uchicago.edu</a>>, "Yadu Nand"<br>

> <<a href="mailto:yadudoc1729@gmail.com">yadudoc1729@gmail.com</a>>, "Scott Krieder" <<a href="mailto:skrieder@iit.edu">skrieder@iit.edu</a>>, "Daniel S. Katz" <<a href="mailto:dsk@ci.uchicago.edu">dsk@ci.uchicago.edu</a>>, "Swift Devel"<br>

> <<a href="mailto:swift-devel@ci.uchicago.edu">swift-devel@ci.uchicago.edu</a>><br>
> Sent: Saturday, June 8, 2013 10:28:52 AM<br>
> Subject: Re: Swift team meeting today - 2PM central - Agenda<br>
><br>
><br>
> Additionally, I proposed we create a small standard library of basic<br>
> apps and ship it with Swift. This library could contain app<br>
> declarations for simple apps such as cat, hostname, date, etc. This<br>
> library could then be imported into a Swift script making Swift<br>
> script look compact. Will add reusability value too.<br>
><br>
><br>
> We could steadily grow this to add more app declarations, say from<br>
> SwiftApps repo.<br>
><br>
><br>
><br>
> On Fri, Jun 7, 2013 at 2:39 PM, Justin M Wozniak <<br>
> <a href="mailto:wozniak@mcs.anl.gov">wozniak@mcs.anl.gov</a> > wrote:<br>
><br>
><br>
> On 06/07/2013 12:52 PM, Michael Wilde wrote:<br>
><br>
> Ketan is working on two power grid apps and had some minor questions<br>
> about Coasters for Mihael.<br>
><br>
> Yadu is working on the multi-site test suite which is itself<br>
> implemented as a Swift script.<br>
><br>
> Scott is looking at CUDA BLAS, OOPS, and mdproxy apps for GPU.<br>
><br>
> Justin added some minor new syntax in Swift/T. Made significant<br>
> additions to the Swift/T web materials. Provided Scott with an<br>
> eigenvalue code based on BLAS compatible with our model for Swift/T<br>
> and the GPU. Lots of conversation with the RDCEP and APS app cases.<br>
> For RDCEP, now have a better sense of how to validate and compare<br>
> the Swift/T implementation to the previous pure Fortran/MPI app. For<br>
> APS, have a better sense of overall workflow and some ideas on where<br>
> to find concurrency to target with Swift/T. Also working with Ketan<br>
> on Swift storage access on the cloud, focusing on the Chirp<br>
> experiments.<br>
><br>
> Tim is working on fixing up some remaining broken Swift/T tests.<br>
><br>
> Mihael is looking at some coasters data movement timeout errors<br>
> reported by Yadu.<br>
><br>
><br>
><br>
><br>
> o David outline strategy for swift command rework (esp. tc wildcards)<br>
> David is investigating pre-processing the Swift/K command line with<br>
> Perl. Mihael suggested some improvements to automatic app<br>
> configuration without tc.data .<br>
><br>
><br>
><br>
> o David: outline priority for corresponding User Guide revamp<br>
> David will have more time shortly to work on this.<br>
><br>
><br>
><br>
> o David: plans to phase in <a href="http://swift-lang.org" target="_blank">swift-lang.org</a> and SWFT email list<br>
> David is in touch with David Forero about this.<br>
><br>
><br>
><br>
> o Mihael: help Yadu and David start documenting the protocol for<br>
> coasters in prep for coaster provider staging file caching feature<br>
> work<br>
> Done somewhere- Mihael will send Yadu and David the link.<br>
><br>
><br>
><br>
> o Yadu: review your observed Swift weaknesses and discuss & file (in<br>
> bugz) suggestions to address each<br>
> o Justin, Tim: next steps in Coaster integration<br>
> Yadu has the coasters C client running. Discussed a list of next<br>
> steps with Justin, including wrapping the client in SWIG and running<br>
> it from Swift/T. Justin provided code samples for reference.<br>
><br>
><br>
><br>
> o Ketan: perhaps discuss next steps for making AWS resources easy to<br>
> use by Swift end users<br>
> Ketan is doing this for the power grid app people.<br>
><br>
><br>
><br>
><br>
> o All: any other topics<br>
><br>
> Please report anything notable to swift-devel<br>
><br>
> Thanks, All, and have a great weekend.<br>
><br>
> - Mike<br>
><br>
><br>
><br>
<span class="HOEnZb"><font color="#888888">><br>
> --<br>
> Justin M Wozniak<br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Ketan<br>
><br>
><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><font face="'courier new', monospace">Ketan</font><br><br>
</div></div></div>