From wilde at mcs.anl.gov  Fri Nov  2 12:05:12 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Fri, 2 Nov 2012 12:05:12 -0500 (CDT)
Subject: [Swift-devel] Swift 0.94 release planning
In-Reply-To: <40830745.154854.1350970119511.JavaMail.root@zimbra-mb2.anl.gov>
Message-ID: <67946644.14168.1351875912606.JavaMail.root@zimbra.anl.gov>

I created a preliminary 0.94 for Beagle under
/soft/swift/0.94-2012.1102

As soon as you start tagging release candidates, we should use 0.93RC2 etc as the dir name.

I did not create a module, but we should for each usable RC.  (Lorenzo will do this).

- Mike


----- Original Message -----
> From: "David Kelly" <davidk at ci.uchicago.edu>
> To: "swift-devel" <swift-devel at ci.uchicago.edu>
> Sent: Tuesday, October 23, 2012 12:28:39 AM
> Subject: [Swift-devel] Swift 0.94 release planning
> Hello all,
> 
> I just wanted to let you all know that I've created branches to
> prepare for an eventual 0.94 release.
> 
> The SVN paths are:
> https://cogkit.svn.sourceforge.net/svnroot/cogkit/branches/4.1.10/src/cog
> https://svn.ci.uchicago.edu/svn/vdl2/branches/release-0.94
> 
> I will be working to add more tests to the suite, and to make sure
> that any known issues are documented in bugzilla.
> 
> Regards,
> David
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From iraicu at cs.iit.edu  Sun Nov  4 19:47:34 2012
From: iraicu at cs.iit.edu (Ioan Raicu)
Date: Sun, 04 Nov 2012 19:47:34 -0600
Subject: [Swift-devel] Call for Participation: IEEE MTAGS 2012 at SC12 on
 November 12th -- Win a Google Nexus 7!
Message-ID: <50971AB6.1090404@cs.iit.edu>

Call for Participation

---------------------------------------------------------------------------------------
The 5th Workshop on Many-Task Computing on Grids and Supercomputers (MTAGS) 2012
http://datasys.cs.iit.edu/events/MTAGS12/
---------------------------------------------------------------------------------------
November 12th, 2012
Salt Lake City, Utah, USA

Co-located with with IEEE/ACM International Conference for
High Performance Computing, Networking, Storage and Analysis (SC12)

Location: 155-C
Date: November 12th, 2012
Time: 9AM - 5:30PM

=======================================================================================
The 5th workshop on Many-Task Computing on Grids and Supercomputers (MTAGS) will
provide the scientific community a dedicated forum for presenting new research,
development, and deployment efforts of large-scale many-task computing (MTC)
applications on large scale clusters, Grids, Supercomputers, and Cloud Computing
infrastructure. The workshop will be co-located with the IEEE/ACM Supercomputing 2012
Conference in Salt Lake City Utah on November 12th, 2012. For more information, please
see http://datasys.cs.iit.edu/events/MTAGS12/.

Some highlights of the upcoming workshop program:
* Win a Google Nexus 7 tablet (visit http://datasys.cs.iit.edu/events/MTAGS12/prize.html);
   Must be present at 5:30PM on November 12th, 2012, at the workshop to win.
* Keynote Talk: Adaptive Runtime Systems meet needs of many task computing by
                 Dr. Laxmikant (Sanjay) Kale, Professor of Computer Science, University
                 of Illinois at Urbana Champaign
* Invited Talk: Petascale Challenge Award: Data Management for Parallel Scripting, by
                 Zhao Zhang (UChicago)
* Invited Talk: Biggest Impact Award: IaaS Cloud Benchmarking: Approaches, Challenges,
                 and Experience, by Alex Iosup (TUDelft)
* Invited Talk: Cloud Challenge Award: Portable Data Mining on Azure and HPC Platforms,
                 by Judy Qiu (IndianaU)
* Paper Talk:   Accessible Datastore of High-Throughput Calculations: Experiences from
                 the Materials Project
* Paper Talk:   Resource Management for Dynamic MapReduce Clusters in Multicluster
                 Systems
* Paper Talk:   A Comparative Study of Data Processing Approaches for Text Processing
                 Workflows
* Paper Talk:   A Scalable Master-Worker Architecture for PaaS Clouds
* Paper Talk:   HOG:Distributed Hadoop MapReduce on the Grid
* Paper Talk:   A Hybrid Scheduling Approach for Scalable Heterogeneous Hadoop Systems
* Paper Talk:   Software-as-a-Service: The iPlant Foundation API
      
=======================================================================================
General Chairs
     Ioan Raicu, Illinois Institute of Technology & Argonne National Laboratory, USA
     Ian Foster, University of Chicago & Argonne National Laboratory, USA
     Yong Zhao, University of Electronic Science and Technology of China, China
    
Program Committee Chair
     Justin Wozniak, Argonne National Laboratory, USA
    
=======================================================================================
Generous sponsorship has been confirmed from University of Chicago (Computation Institute)
and Illinois Institute of Technology (College of Science and Letters, and Graduate School)!
See http://datasys.cs.iit.edu/events/MTAGS12/index.html#Sponsors for more details.

-- 
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel:    1-847-722-0876
Office: 1-312-567-5704
Email:  iraicu at cs.iit.edu
Web:    http://www.cs.iit.edu/~iraicu/
Web:    http://datasys.cs.iit.edu/
=================================================================
=================================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20121104/20d2056d/attachment.html>

From wilde at mcs.anl.gov  Mon Nov  5 10:31:23 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Mon, 5 Nov 2012 10:31:23 -0600 (CST)
Subject: [Swift-devel] Need advice on running multi-node coaster MPI jobs
In-Reply-To: <518588569.17928.1352132839558.JavaMail.root@zimbra.anl.gov>
Message-ID: <2063925217.17942.1352133083666.JavaMail.root@zimbra.anl.gov>


Hi All,

Urgent for me this week is to get Pagoda MPI runs for the ParVis project, due Friday.

Im stuck getting MPI multi-node jobs running under coasters.

Im trying two approaches: David's approach with standard, fixed-size coaster jobs, and Justin's Jets-like mechanism.

>From everying I can see, David's approach should work. When I test this in a simple shell, even with nested shells, it works, but when mpiexec is run from a coaster worker, even a local one, it fails.

What I get from MPICH2 mpiexec is:

[mpiexec at vs37] HYDT_dmx_register_fd (./tools/demux/demux.c:82): registering duplicate fd 0
[mpiexec at vs37] HYDT_bscd_external_launch_procs (./tools/bootstrap/external/external_launch.c:295): demux returned error registering fd
[mpiexec at vs37] HYDT_bsci_launch_procs (./tools/bootstrap/src/bsci_launch.c:21): bootstrap device returned error while launching processes
[mpiexec at vs37] HYD_pmci_launch_procs (./pm/pmiserv/pmiserv_pmci.c:298): bootstrap server cannot launch processes
[mpiexec at vs37] main (./ui/mpich/mpiexec.c:298): process manager returned error launching processes


I think the failure is related to something that either perl, or the worker.pl perl code, is doing when it forks the job. I thought the culprit was that worker.pl closes STDIN, but commenting out that close doesnt correct the problem.

Any suggestions?

Now, I just discovered that ParVis needs these runs done on an ORNL PBS system called "lens" with OpenMPI. So Im shifting my tests to PADS OpenMPI for now, which may work or fail differently.

But regardless we should get this mechanism working.

I'll also go back and re-test with Justin's  muti-node coaster MPI launching mechanism as well. But that wont work for OpenMPI, so for now I need to stick with making David's mechanism work multinode on OpenMPI.

Ive requested a 4-node PADS reservation for testing.

- Mike

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From davidk at ci.uchicago.edu  Mon Nov  5 10:59:12 2012
From: davidk at ci.uchicago.edu (David Kelly)
Date: Mon, 5 Nov 2012 10:59:12 -0600 (CST)
Subject: [Swift-devel] Need advice on running multi-node coaster MPI jobs
In-Reply-To: <2063925217.17942.1352133083666.JavaMail.root@zimbra.anl.gov>
Message-ID: <478914505.10084.1352134752882.JavaMail.root@zimbra-mb2.anl.gov>

Mike,

I have seen a very similar error on Fusion when trying to use mvapich2. With mvapich2 on Fusion I can run the executable directly from qsub -I and it works fine. When the same executable is run by swift it fails with errors similar to what you are seeing. The only workaround I have found for this is to use OpenMPI, which seems to consistently work for me.

----- Original Message -----
> From: "Michael Wilde" <wilde at mcs.anl.gov>
> To: "swift-devel" <swift-devel at ci.uchicago.edu>
> Sent: Monday, November 5, 2012 10:31:23 AM
> Subject: [Swift-devel] Need advice on running multi-node coaster MPI jobs
> Hi All,
> 
> Urgent for me this week is to get Pagoda MPI runs for the ParVis
> project, due Friday.
> 
> Im stuck getting MPI multi-node jobs running under coasters.
> 
> Im trying two approaches: David's approach with standard, fixed-size
> coaster jobs, and Justin's Jets-like mechanism.
> 
> From everying I can see, David's approach should work. When I test
> this in a simple shell, even with nested shells, it works, but when
> mpiexec is run from a coaster worker, even a local one, it fails.
> 
> What I get from MPICH2 mpiexec is:
> 
> [mpiexec at vs37] HYDT_dmx_register_fd (./tools/demux/demux.c:82):
> registering duplicate fd 0
> [mpiexec at vs37] HYDT_bscd_external_launch_procs
> (./tools/bootstrap/external/external_launch.c:295): demux returned
> error registering fd
> [mpiexec at vs37] HYDT_bsci_launch_procs
> (./tools/bootstrap/src/bsci_launch.c:21): bootstrap device returned
> error while launching processes
> [mpiexec at vs37] HYD_pmci_launch_procs
> (./pm/pmiserv/pmiserv_pmci.c:298): bootstrap server cannot launch
> processes
> [mpiexec at vs37] main (./ui/mpich/mpiexec.c:298): process manager
> returned error launching processes
> 
> 
> I think the failure is related to something that either perl, or the
> worker.pl perl code, is doing when it forks the job. I thought the
> culprit was that worker.pl closes STDIN, but commenting out that close
> doesnt correct the problem.
> 
> Any suggestions?
> 
> Now, I just discovered that ParVis needs these runs done on an ORNL
> PBS system called "lens" with OpenMPI. So Im shifting my tests to PADS
> OpenMPI for now, which may work or fail differently.
> 
> But regardless we should get this mechanism working.
> 
> I'll also go back and re-test with Justin's muti-node coaster MPI
> launching mechanism as well. But that wont work for OpenMPI, so for
> now I need to stick with making David's mechanism work multinode on
> OpenMPI.
> 
> Ive requested a 4-node PADS reservation for testing.
> 
> - Mike
> 
> --
> Michael Wilde
> Computation Institute, University of Chicago
> Mathematics and Computer Science Division
> Argonne National Laboratory
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel


From wozniak at mcs.anl.gov  Mon Nov  5 11:09:07 2012
From: wozniak at mcs.anl.gov (Justin M Wozniak)
Date: Mon, 05 Nov 2012 11:09:07 -0600
Subject: [Swift-devel] Need advice on running multi-node coaster MPI jobs
In-Reply-To: <2063925217.17942.1352133083666.JavaMail.root@zimbra.anl.gov>
References: <2063925217.17942.1352133083666.JavaMail.root@zimbra.anl.gov>
Message-ID: <5097F2B3.9070600@mcs.anl.gov>


Do you know why they need OpenMPI?  If we are going to launch the 
application using JETS, we should be able to use a user MPICH, 
regardless of what the scheduler or whatever uses by default.

Would getting this working on Gadzooks as a first step still help?

On 11/5/2012 10:31 AM, Michael Wilde wrote:
> Hi All,
>
> Urgent for me this week is to get Pagoda MPI runs for the ParVis project, due Friday.
>
> Im stuck getting MPI multi-node jobs running under coasters.
>
> Im trying two approaches: David's approach with standard, fixed-size coaster jobs, and Justin's Jets-like mechanism.
>
>  From everying I can see, David's approach should work. When I test this in a simple shell, even with nested shells, it works, but when mpiexec is run from a coaster worker, even a local one, it fails.
>
> What I get from MPICH2 mpiexec is:
>
> [mpiexec at vs37] HYDT_dmx_register_fd (./tools/demux/demux.c:82): registering duplicate fd 0
> [mpiexec at vs37] HYDT_bscd_external_launch_procs (./tools/bootstrap/external/external_launch.c:295): demux returned error registering fd
> [mpiexec at vs37] HYDT_bsci_launch_procs (./tools/bootstrap/src/bsci_launch.c:21): bootstrap device returned error while launching processes
> [mpiexec at vs37] HYD_pmci_launch_procs (./pm/pmiserv/pmiserv_pmci.c:298): bootstrap server cannot launch processes
> [mpiexec at vs37] main (./ui/mpich/mpiexec.c:298): process manager returned error launching processes
>
>
> I think the failure is related to something that either perl, or the worker.pl perl code, is doing when it forks the job. I thought the culprit was that worker.pl closes STDIN, but commenting out that close doesnt correct the problem.
>
> Any suggestions?
>
> Now, I just discovered that ParVis needs these runs done on an ORNL PBS system called "lens" with OpenMPI. So Im shifting my tests to PADS OpenMPI for now, which may work or fail differently.
>
> But regardless we should get this mechanism working.
>
> I'll also go back and re-test with Justin's  muti-node coaster MPI launching mechanism as well. But that wont work for OpenMPI, so for now I need to stick with making David's mechanism work multinode on OpenMPI.
>
> Ive requested a 4-node PADS reservation for testing.
>
> - Mike
>



From wilde at mcs.anl.gov  Mon Nov  5 12:37:56 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Mon, 5 Nov 2012 12:37:56 -0600 (CST)
Subject: [Swift-devel] Need advice on running multi-node coaster MPI jobs
In-Reply-To: <5097F2B3.9070600@mcs.anl.gov>
Message-ID: <466800553.18314.1352140676266.JavaMail.root@zimbra.anl.gov>

The need OpenMPI because they are running the ORNL "lens" system, and thats what they use there and all their tools are built for.  I dont have access to that system yet, so I cant readily explore other options there.

But if David's experience with OpenMPI bears out, that might work in our favor.

- Mike

----- Original Message -----
> From: "Justin M Wozniak" <wozniak at mcs.anl.gov>
> To: swift-devel at ci.uchicago.edu
> Sent: Monday, November 5, 2012 11:09:07 AM
> Subject: Re: [Swift-devel] Need advice on running multi-node coaster MPI jobs
> Do you know why they need OpenMPI? If we are going to launch the
> application using JETS, we should be able to use a user MPICH,
> regardless of what the scheduler or whatever uses by default.
> 
> Would getting this working on Gadzooks as a first step still help?
> 
> On 11/5/2012 10:31 AM, Michael Wilde wrote:
> > Hi All,
> >
> > Urgent for me this week is to get Pagoda MPI runs for the ParVis
> > project, due Friday.
> >
> > Im stuck getting MPI multi-node jobs running under coasters.
> >
> > Im trying two approaches: David's approach with standard, fixed-size
> > coaster jobs, and Justin's Jets-like mechanism.
> >
> >  From everying I can see, David's approach should work. When I test
> >  this in a simple shell, even with nested shells, it works, but when
> >  mpiexec is run from a coaster worker, even a local one, it fails.
> >
> > What I get from MPICH2 mpiexec is:
> >
> > [mpiexec at vs37] HYDT_dmx_register_fd (./tools/demux/demux.c:82):
> > registering duplicate fd 0
> > [mpiexec at vs37] HYDT_bscd_external_launch_procs
> > (./tools/bootstrap/external/external_launch.c:295): demux returned
> > error registering fd
> > [mpiexec at vs37] HYDT_bsci_launch_procs
> > (./tools/bootstrap/src/bsci_launch.c:21): bootstrap device returned
> > error while launching processes
> > [mpiexec at vs37] HYD_pmci_launch_procs
> > (./pm/pmiserv/pmiserv_pmci.c:298): bootstrap server cannot launch
> > processes
> > [mpiexec at vs37] main (./ui/mpich/mpiexec.c:298): process manager
> > returned error launching processes
> >
> >
> > I think the failure is related to something that either perl, or the
> > worker.pl perl code, is doing when it forks the job. I thought the
> > culprit was that worker.pl closes STDIN, but commenting out that
> > close doesnt correct the problem.
> >
> > Any suggestions?
> >
> > Now, I just discovered that ParVis needs these runs done on an ORNL
> > PBS system called "lens" with OpenMPI. So Im shifting my tests to
> > PADS OpenMPI for now, which may work or fail differently.
> >
> > But regardless we should get this mechanism working.
> >
> > I'll also go back and re-test with Justin's muti-node coaster MPI
> > launching mechanism as well. But that wont work for OpenMPI, so for
> > now I need to stick with making David's mechanism work multinode on
> > OpenMPI.
> >
> > Ive requested a 4-node PADS reservation for testing.
> >
> > - Mike
> >
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From davidk at ci.uchicago.edu  Tue Nov  6 14:00:16 2012
From: davidk at ci.uchicago.edu (David Kelly)
Date: Tue, 6 Nov 2012 14:00:16 -0600 (CST)
Subject: [Swift-devel] Swift 0.94 release planning
In-Reply-To: <67946644.14168.1351875912606.JavaMail.root@zimbra.anl.gov>
Message-ID: <1189475332.18480.1352232016542.JavaMail.root@zimbra-mb2.anl.gov>

I have created a Swift 0.94RC1 package. It is located at http://www.ci.uchicago.edu/swift/packages/swift-0.94RC1.tar.gz.

----- Original Message -----
> From: "Michael Wilde" <wilde at mcs.anl.gov>
> To: "David Kelly" <davidk at ci.uchicago.edu>
> Cc: "swift-devel" <swift-devel at ci.uchicago.edu>
> Sent: Friday, November 2, 2012 12:05:12 PM
> Subject: Re: [Swift-devel] Swift 0.94 release planning
> I created a preliminary 0.94 for Beagle under
> /soft/swift/0.94-2012.1102
> 
> As soon as you start tagging release candidates, we should use 0.93RC2
> etc as the dir name.
> 
> I did not create a module, but we should for each usable RC. (Lorenzo
> will do this).
> 
> - Mike
> 
> 
> ----- Original Message -----
> > From: "David Kelly" <davidk at ci.uchicago.edu>
> > To: "swift-devel" <swift-devel at ci.uchicago.edu>
> > Sent: Tuesday, October 23, 2012 12:28:39 AM
> > Subject: [Swift-devel] Swift 0.94 release planning
> > Hello all,
> >
> > I just wanted to let you all know that I've created branches to
> > prepare for an eventual 0.94 release.
> >
> > The SVN paths are:
> > https://cogkit.svn.sourceforge.net/svnroot/cogkit/branches/4.1.10/src/cog
> > https://svn.ci.uchicago.edu/svn/vdl2/branches/release-0.94
> >
> > I will be working to add more tests to the suite, and to make sure
> > that any known issues are documented in bugzilla.
> >
> > Regards,
> > David
> > _______________________________________________
> > Swift-devel mailing list
> > Swift-devel at ci.uchicago.edu
> > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
> 
> --
> Michael Wilde
> Computation Institute, University of Chicago
> Mathematics and Computer Science Division
> Argonne National Laboratory


From wilde at mcs.anl.gov  Tue Nov  6 21:22:18 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Tue, 6 Nov 2012 21:22:18 -0600 (CST)
Subject: [Swift-devel] Cant get trunk running on midway slurm
Message-ID: <433094543.21956.1352258538966.JavaMail.root@zimbra.anl.gov>

David,

Im having a heck of a time getting trunk running on midway.

Question: does your slurm provider generate an job that invokes the slurm-qsub script, or does it use native slurm commands?

Have you tried trunk on midway lately?  (coaster with jobmanager local:slurm)

Thanks,

- Mike

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From davidk at ci.uchicago.edu  Tue Nov  6 21:27:26 2012
From: davidk at ci.uchicago.edu (David Kelly)
Date: Tue, 6 Nov 2012 21:27:26 -0600 (CST)
Subject: [Swift-devel] Cant get trunk running on midway slurm
In-Reply-To: <433094543.21956.1352258538966.JavaMail.root@zimbra.anl.gov>
Message-ID: <1425466809.21251.1352258846919.JavaMail.root@zimbra-mb2.anl.gov>

It should use the slurm-qsub script.. I will give it a try and see what I can find.

----- Original Message -----
> From: "Michael Wilde" <wilde at mcs.anl.gov>
> To: "David Kelly" <davidk at ci.uchicago.edu>
> Cc: "swift-devel" <swift-devel at ci.uchicago.edu>
> Sent: Tuesday, November 6, 2012 9:22:18 PM
> Subject: Cant get trunk running on midway slurm
> David,
> 
> Im having a heck of a time getting trunk running on midway.
> 
> Question: does your slurm provider generate an job that invokes the
> slurm-qsub script, or does it use native slurm commands?
> 
> Have you tried trunk on midway lately? (coaster with jobmanager
> local:slurm)
> 
> Thanks,
> 
> - Mike
> 
> --
> Michael Wilde
> Computation Institute, University of Chicago
> Mathematics and Computer Science Division
> Argonne National Laboratory


From davidk at ci.uchicago.edu  Tue Nov  6 21:34:39 2012
From: davidk at ci.uchicago.edu (David Kelly)
Date: Tue, 6 Nov 2012 21:34:39 -0600 (CST)
Subject: [Swift-devel] Cant get trunk running on midway slurm
In-Reply-To: <1425466809.21251.1352258846919.JavaMail.root@zimbra-mb2.anl.gov>
Message-ID: <562756790.21322.1352259279359.JavaMail.root@zimbra-mb2.anl.gov>

I gave it a try with trunk and it seems to be working well for me. Here is the sites.xml I used. I didn't make any other modifications.

<config>
  <pool handle="midway">
    <execution provider="coaster" jobmanager="local:slurm"/>
    <!-- replace with your project depth is adjusted to 16 for Midway -->
    <profile namespace="globus" key="jobsPerNode">16</profile>
    <profile namespace="globus" key="maxTime">7200</profile>
    <profile namespace="globus" key="maxwalltime">0:5:00</profile>
    <profile namespace="globus" key="lowOverallocation">100</profile>
    <profile namespace="globus" key="highOverallocation">100</profile>
    <profile namespace="globus" key="queue">sandyb</profile>
    <profile namespace="globus" key="slots">20</profile>
    <profile namespace="globus" key="nodeGranularity">1</profile>
    <profile namespace="globus" key="maxNodes">1</profile>

    <profile namespace="karajan" key="jobThrottle">4</profile>
    <profile namespace="karajan" key="initialScore">10000</profile>

    <filesystem provider="local"/>
    <!-- replaced with the project home on Midway -->
    <workdirectory>/home/davidkelly999/work</workdirectory>
  </pool>
</config>


----- Original Message -----
> From: "David Kelly" <davidk at ci.uchicago.edu>
> To: "Michael Wilde" <wilde at mcs.anl.gov>
> Cc: "swift-devel" <swift-devel at ci.uchicago.edu>
> Sent: Tuesday, November 6, 2012 9:27:26 PM
> Subject: Re: [Swift-devel] Cant get trunk running on midway slurm
> It should use the slurm-qsub script.. I will give it a try and see
> what I can find.
> 
> ----- Original Message -----
> > From: "Michael Wilde" <wilde at mcs.anl.gov>
> > To: "David Kelly" <davidk at ci.uchicago.edu>
> > Cc: "swift-devel" <swift-devel at ci.uchicago.edu>
> > Sent: Tuesday, November 6, 2012 9:22:18 PM
> > Subject: Cant get trunk running on midway slurm
> > David,
> >
> > Im having a heck of a time getting trunk running on midway.
> >
> > Question: does your slurm provider generate an job that invokes the
> > slurm-qsub script, or does it use native slurm commands?
> >
> > Have you tried trunk on midway lately? (coaster with jobmanager
> > local:slurm)
> >
> > Thanks,
> >
> > - Mike
> >
> > --
> > Michael Wilde
> > Computation Institute, University of Chicago
> > Mathematics and Computer Science Division
> > Argonne National Laboratory
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel


From hategan at mcs.anl.gov  Fri Nov  9 23:54:45 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Fri, 09 Nov 2012 21:54:45 -0800
Subject: [Swift-devel] changes in trunk (tracing and usability)
Message-ID: <1352526885.5892.10.camel@blabla>

Hello,

I added a few things in trunk meant to make it easier to debug issues
with scripts.

The major one is tracing. It's disabled by default, but can be enabled
with -tracing.enabled on the command line (or with the tracing.enabled
property).
What it does is it traces app calls, compound calls, assignments, etc.
It does it with line numbers, threads, and run-time information where
available (such as the exact values of the k, v pair for an iteration,
the exact arguments to a function or app, etc.).
Not all things are traced yet, but I wanted to see if it's useful before
putting too much effort into it.

The minor ones are:
- stack traces for errors. When swift fails, it prints a swift stack
trace instead of just the error message with no location information.
This is in non-lazy error mode, and lazy errors might need more work.
- the "invalid path" errors are gone. You now get "Array index <value>
not found for <array> of <size>" or "Invalid field name <name> for
<struct_variable> of type <type>". These types of errors should be
caught at compile-time, but there are still places where the static
system can be bypassed.
- there was a race condition in the creation of array elements of struct
type which would sometimes produce the "Invalid path
<valid_struct_field> for <variable>". It's fixed now.

Mihael



From wilde at mcs.anl.gov  Sat Nov 10 07:34:33 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Sat, 10 Nov 2012 07:34:33 -0600 (CST)
Subject: [Swift-devel] changes in trunk (tracing and usability)
In-Reply-To: <1352526885.5892.10.camel@blabla>
Message-ID: <1636974473.29613.1352554473709.JavaMail.root@zimbra.anl.gov>

All sounds very cool - Im eager to try this. We may want to update 0.94 with these features, or push 0.94 out sooner and release this as 0.95.

- Mike

----- Original Message -----
> From: "Mihael Hategan" <hategan at mcs.anl.gov>
> To: "Swift Devel" <swift-devel at ci.uchicago.edu>
> Sent: Friday, November 9, 2012 11:54:45 PM
> Subject: [Swift-devel] changes in trunk (tracing and usability)
> Hello,
> 
> I added a few things in trunk meant to make it easier to debug issues
> with scripts.
> 
> The major one is tracing. It's disabled by default, but can be enabled
> with -tracing.enabled on the command line (or with the tracing.enabled
> property).
> What it does is it traces app calls, compound calls, assignments, etc.
> It does it with line numbers, threads, and run-time information where
> available (such as the exact values of the k, v pair for an iteration,
> the exact arguments to a function or app, etc.).
> Not all things are traced yet, but I wanted to see if it's useful
> before
> putting too much effort into it.
> 
> The minor ones are:
> - stack traces for errors. When swift fails, it prints a swift stack
> trace instead of just the error message with no location information.
> This is in non-lazy error mode, and lazy errors might need more work.
> - the "invalid path" errors are gone. You now get "Array index <value>
> not found for <array> of <size>" or "Invalid field name <name> for
> <struct_variable> of type <type>". These types of errors should be
> caught at compile-time, but there are still places where the static
> system can be bypassed.
> - there was a race condition in the creation of array elements of
> struct
> type which would sometimes produce the "Invalid path
> <valid_struct_field> for <variable>". It's fixed now.
> 
> Mihael
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From iraicu at cs.iit.edu  Sat Nov 10 09:08:46 2012
From: iraicu at cs.iit.edu (Ioan Raicu)
Date: Sat, 10 Nov 2012 09:08:46 -0600
Subject: [Swift-devel] CFP: IEEE/ACM CCGrid 2013 -- deadline extension to
	November 22
Message-ID: <509E6DFE.6040705@cs.iit.edu>

                       **** CALL FOR PAPERS ****

                 The 13th IEEE/ACM International Symposium on
                      Cluster, Cloud and Grid Computing
                             (CCGrid 2013)

           Delft University of Technology, Delft, the Netherlands

                            May 13-16, 2013

http://www.pds.ewi.tudelft.nl/ccgrid2013


**********************************************************************
*******   Extension of paper deadline until November 22, 2012 ******
**********************************************************************


***** The CCGrid 2013 Workshops have been posted on the website *****


Rapid advances in architectures, networks, and systems and middleware 
technologies
are leading to new concepts in and platforms for computing, ranging from 
Clusters and
Grids to Clouds and Datacenters. CCGrid is a series of very successful 
conferences,
sponsored by the IEEE Computer Society Technical Committee on Scalable 
Computing (TCSC)
and the ACM, with the overarching goal of bringing together 
international researchers,
developers, and users to provide an international forum to present 
leading research
activities and results on a broad range of topics related to these 
concepts and platforms,
and their applications. The conference features keynotes, technical 
presentations,
workshops, tutorials, and posters, as well as the SCALE challenge 
featuring live demonstrations.

In 2013, CCGrid will come to the Netherlands for the first time, and 
will be held in Delft,
a historical, picturesque city that is less than one hour away from 
Amsterdam-Schiphol airport.
The main conference will be held on May 14-16 (Tuesday to Thursday), 
with tutorials and
affiliated workshops taking place on May 13 (Monday).


**** IMPORTANT DATES ****
Papers Due:                22 November 2012 Anywhere on Earth (extended)
Author Notifications:            24 January 2013
Final Papers Due:            22 February 2013


**** TOPICS OF INTEREST ****
CCGrid 2013 will have a focus on important and immediate issues that are 
significantly
influencing all aspects of cluster, cloud and grid computing. Topics of 
interest include,
but are not limited to:

* Applications and Experiences: Applications to real and complex 
problems in science,
   engineering, business, and society; User studies; Experiences with 
large-scale deployments,
   systems, or applications
* Architecture: System architectures, design and deployment; Power and 
cooling; Security
   and reliability; High availability solutions
* Autonomic Computing and Cyberinfrastructure: Self-managed behavior, 
models and technologies;
   Autonomic paradigms and systems (control-based, bio-inspired, 
emergent, etc.); Bio-inspired
   optimizations and computing
* Cloud Computing: Cloud architectures; Software tools and techniques 
for clouds
* Multicore and Accelerator-based Computing: Software and application 
techniques to utilize
   multicore architectures and accelerators in clusters, grids, and clouds
* Performance Modeling and Evaluation: Performance prediction and 
modeling; Monitoring and
   evaluation tools; Analysis of system and application performance; 
Benchmarks and testbeds
* Programming Models, Systems, and Fault-Tolerant Computing: Programming 
models and
   environments for cluster, cloud, and grid computing; Fault-tolerant 
systems, programs and
   algorithms; Systems software to support efficient computing
* Scheduling and Resource Management: Techniques to schedule jobs and 
resources on cluster,
   cloud, and grid computing platforms; SLA definition and enforcement


**** PAPER SUBMISSION GUIDELINES ****
Authors are invited to submit papers electronically in PDF format. 
Submitted manuscripts
should be structured as technical papers and may not exceed 8 
letter-size (8.5 x 11) pages
including figures, tables and references using the IEEE format for 
conference proceedings.
Submissions not conforming to these guidelines may be returned without 
review. Authors
should make sure that their file will print on a printer that uses 
letter-size (8.5 x 11)
paper. The official language of the conference is English. All 
manuscripts will be reviewed
and will be judged on correctness, originality, technical strength, 
significance, quality of
presentation, and interest and relevance to the conference attendees.

Submitted papers must represent original unpublished research that is 
not currently under
review for any other conference or journal. Papers not following these 
guidelines will be
rejected without review and further action may be taken, including (but 
not limited to)
notifications sent to the heads of the institutions of the authors and 
sponsors of the
conference. Submissions received after the due date, exceeding the page 
limit, or not
appropriately structured may not be considered. Authors may contact the 
conference chairs
for more information. The proceedings will be published through the IEEE 
Computer Society
Press, USA, and will be made available online through the IEEE Digital 
Library.


**** CALL FOR TUTORIAL AND WORKSHOP PROPOSALS ****
Tutorials and workshops affiliated with CCGrid 2013 will be held on May 
13 (Monday). For
more information on the tutorials and workshops and for the complete 
Call for Tutorial and
Workshop Proposals, please see the conference website.


**** GENERAL CHAIR ****
Dick Epema, Delft University of Technology, the Netherlands


**** PROGRAM CHAIR ****
Thomas Fahringer, University of Innsbruck, Austria


**** PROGRAM VICE-CHAIRS ****
Rosa Badia, Barcelona Supercomputing Center, Spain
Henri Bal, Vrije Universiteit, the Netherlands
Marios Dikaiakos, University of Cyprus, Cyprus
Kirk Cameron, VirginiaTech, USA
Daniel Katz, University of Chicago & Argonne Nat Lab, USA
Kate Keahey, Argonne National Laboratory, USA
Martin Schulz, Lawrence Livermore National Laboratory, USA
Douglas Thain, University of Notre Dame, USA
Cheng-Zhong Xu, Shenzhen Inst. of Advanced Techn, China


**** WORKSHOPS CO-CHAIRS ****
Shantenu Jha, Rutgers and Louisana State University, USA
Ioan Raicu, Illinois Institute of Technology, USA


**** TOTORIALS CHAIR ****
Radu Prodan, University of Innsbruck, Austria


**** DOCTORAL SYMPOSIUM CO-CHAIRS ****
Yogesh Simmhan, University of Southern California, USA
Ana Varbanescu, Delft Univ of Technology, the Netherlands


**** SUBMISSIONS AND PROCEEDINGS CHAIR ****
Pavan Balaji, Argonne National Laboratory, USA


**** FINANCE AND REGISTRATION CHAIR ****
Alexandru Iosup, Delft Univ of Technology, the Netherlands


**** PUBLICITY CHAIRS ****
Nazareno Andrade, University Federal de Campina Grance, Brazil
Gabriel Antoniu, INRIA, France
Bahman Javadi, University of Western Sysney, Australia
Ioan Raicu, Illinois Institute of Technology and Argonne National 
Laboratory, USA
Kin Choong Yow, Shenzhen Inst. of Advanced Technology, China


**** CYBER CHAIR ****
Stephen van der Laan, Delft University of Technology, the Netherlands

-- 
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel:    1-847-722-0876
Office: 1-312-567-5704
Email:  iraicu at cs.iit.edu
Web:    http://www.cs.iit.edu/~iraicu/
Web:    http://datasys.cs.iit.edu/
=================================================================
=================================================================



From hategan at mcs.anl.gov  Sat Nov 10 13:23:59 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Sat, 10 Nov 2012 11:23:59 -0800
Subject: [Swift-devel] changes in trunk (tracing and usability)
In-Reply-To: <1636974473.29613.1352554473709.JavaMail.root@zimbra.anl.gov>
References: <1636974473.29613.1352554473709.JavaMail.root@zimbra.anl.gov>
Message-ID: <1352575439.11344.0.camel@blabla>

On Sat, 2012-11-10 at 07:34 -0600, Michael Wilde wrote:
> All sounds very cool - Im eager to try this. We may want to update 0.94 with these features, or push 0.94 out sooner and release this as 0.95.

I think it's 0.95 material because it needs testing. And I do think we
should release more often.

Mihael

> 
> - Mike
> 
> ----- Original Message -----
> > From: "Mihael Hategan" <hategan at mcs.anl.gov>
> > To: "Swift Devel" <swift-devel at ci.uchicago.edu>
> > Sent: Friday, November 9, 2012 11:54:45 PM
> > Subject: [Swift-devel] changes in trunk (tracing and usability)
> > Hello,
> > 
> > I added a few things in trunk meant to make it easier to debug issues
> > with scripts.
> > 
> > The major one is tracing. It's disabled by default, but can be enabled
> > with -tracing.enabled on the command line (or with the tracing.enabled
> > property).
> > What it does is it traces app calls, compound calls, assignments, etc.
> > It does it with line numbers, threads, and run-time information where
> > available (such as the exact values of the k, v pair for an iteration,
> > the exact arguments to a function or app, etc.).
> > Not all things are traced yet, but I wanted to see if it's useful
> > before
> > putting too much effort into it.
> > 
> > The minor ones are:
> > - stack traces for errors. When swift fails, it prints a swift stack
> > trace instead of just the error message with no location information.
> > This is in non-lazy error mode, and lazy errors might need more work.
> > - the "invalid path" errors are gone. You now get "Array index <value>
> > not found for <array> of <size>" or "Invalid field name <name> for
> > <struct_variable> of type <type>". These types of errors should be
> > caught at compile-time, but there are still places where the static
> > system can be bypassed.
> > - there was a race condition in the creation of array elements of
> > struct
> > type which would sometimes produce the "Invalid path
> > <valid_struct_field> for <variable>". It's fixed now.
> > 
> > Mihael
> > 
> > _______________________________________________
> > Swift-devel mailing list
> > Swift-devel at ci.uchicago.edu
> > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
> 




From wilde at mcs.anl.gov  Mon Nov 12 13:38:05 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Mon, 12 Nov 2012 13:38:05 -0600 (CST)
Subject: [Swift-devel] How to adapt auto-ssl feature from ssh to persistent
	coasters?
In-Reply-To: <1344314724.29080.5.camel@blabla>
Message-ID: <1556825783.32339.1352749085578.JavaMail.root@zimbra.anl.gov>

Mihael, All,

Can we use parts of the ssh-based solution below for persistent automatic coasters on a local machine?

I was able to create the two local coaster worker pools I need for a mixed MPI/Serial swift script by starting two coaster servers after I created an x509 proxy using globus.

Even though the servers were started with -nosec, I was not able to get swift to use these servers with automatic workers. The swift command complained about not finding a proxy file in /tmp. When I created such a proxy manual using grid-proxy-init, everything worked as desired.

Now I want to hand this solution off to a user to test, and the user does not have a suitable cert. Do the tools and/or temp certs exist in the current swift release to create a suitable proxy manually? 

Or, is there a way to have the swift command not insist on a proxy - as the servers and workers are all on the same local cluster?

- Mike

----- Forwarded Message -----
From: "Mihael Hategan" <hategan at mcs.anl.gov>
To: "Michael Wilde" <wilde at mcs.anl.gov>
Cc: "Kyle Chard" <kyle at ci.uchicago.edu>, "David Kelly" <davidk at ci.uchicago.edu>
Sent: Monday, August 6, 2012 11:45:24 PM
Subject: Re: Devel help needed for CMTS project

There is a solution now in trunk. Whenever you use SSH as the coaster
boot handler, a set of CA keys, user keys and a proxy are created. The
SSH provider also now knows how to automatically forward both the proxy
and the CA cert.

The result is that when you use SSH you don't have to care about any GSI
issue. It should just work.

Right now there is a minimum lifetime of one week on the use of the
proxies (the CA certs have a lifetime of two weeks, but they will be
re-used if the have at least one week left). Point being that swift
stuff running for more than one week with these may have problems. That
can be changed.

Anyway, give it a try and let me know how it works.

Mihael

On Thu, 2012-08-02 at 22:33 -0500, Michael Wilde wrote:
> We're trying to not require the user to do either of these two things:
> as long as the user can ssh to the remote system, coasters sith say
> ssh:pbs should work with no other security setup by the user.
> 
> So the problem could be solved (1) with the kind of shared-secret
> solution you have mentioned in the past, or (2) with making -nosec
> work for automatic remote coasters (assuming we determine that is
> sufficiently safe), or (3) we could include in Swift a single user
> cert/proxy and a CA signing cert for it, and automatically place that
> on the remote side as part of bootstrap. Eg, a SimpleCA cert, if
> anyone can get SimpleCA working, or just find a set of matching certs.
> Or (4) we  require that the user create a valid proxy based on a known
> supported CA, before running Swift, and we grab that proxy and place
> it on the remote side at or before bootstrap. I *think* that David
> could implement this last solution on his own, as part of swiftrun or
> cmtsrun.  It (4) might be the most reasonable for CMTS, given that
> their workflows will likely require access to at least one GridFTP
> server if any apps run remotely.
> 
> Does that analysis and list of 4 alternatives seem sound?
> 
> - Mike
> 
> 
> ----- Original Message -----
> > From: "Mihael Hategan" <hategan at mcs.anl.gov>
> > To: "Michael Wilde" <wilde at mcs.anl.gov>
> > Cc: "Kyle Chard" <kyle at ci.uchicago.edu>, "David Kelly" <davidk at ci.uchicago.edu>
> > Sent: Thursday, August 2, 2012 9:35:16 PM
> > Subject: Re: Devel help needed for CMTS project
> > On Fri, 2012-07-27 at 14:08 -0500, Michael Wilde wrote:
> > 
> > > - Ability to run remote coasters jobs without an x509 user and ca
> > > cert. Alternatively as a stopgap: a pair of certs that either our
> > > scripts or users could install to solve the problem. Eg, from
> > > SimpleCA
> > > or some other source.
> > 
> > What problem are we trying to solve here?
> > 
> > 1. Said users not having a gsi certificate
> > 
> > 2. Coasters and ssh requiring a proxy on the remote side
> 



-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From hategan at mcs.anl.gov  Mon Nov 12 13:43:29 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Mon, 12 Nov 2012 11:43:29 -0800
Subject: [Swift-devel] How to adapt auto-ssl feature from ssh to
	persistent coasters?
In-Reply-To: <1556825783.32339.1352749085578.JavaMail.root@zimbra.anl.gov>
References: <1556825783.32339.1352749085578.JavaMail.root@zimbra.anl.gov>
Message-ID: <1352749409.2106.2.camel@blabla>

Shouldn't we fix the local:x version instead? I think it's both easier
to use and easier to fix and faster and less demanding on resources.

On Mon, 2012-11-12 at 13:38 -0600, Michael Wilde wrote:
> Mihael, All,
> 
> Can we use parts of the ssh-based solution below for persistent automatic coasters on a local machine?
> 
> I was able to create the two local coaster worker pools I need for a mixed MPI/Serial swift script by starting two coaster servers after I created an x509 proxy using globus.
> 
> Even though the servers were started with -nosec, I was not able to get swift to use these servers with automatic workers. The swift command complained about not finding a proxy file in /tmp. When I created such a proxy manual using grid-proxy-init, everything worked as desired.
> 
> Now I want to hand this solution off to a user to test, and the user does not have a suitable cert. Do the tools and/or temp certs exist in the current swift release to create a suitable proxy manually? 
> 
> Or, is there a way to have the swift command not insist on a proxy - as the servers and workers are all on the same local cluster?
> 
> - Mike
> 
> ----- Forwarded Message -----
> From: "Mihael Hategan" <hategan at mcs.anl.gov>
> To: "Michael Wilde" <wilde at mcs.anl.gov>
> Cc: "Kyle Chard" <kyle at ci.uchicago.edu>, "David Kelly" <davidk at ci.uchicago.edu>
> Sent: Monday, August 6, 2012 11:45:24 PM
> Subject: Re: Devel help needed for CMTS project
> 
> There is a solution now in trunk. Whenever you use SSH as the coaster
> boot handler, a set of CA keys, user keys and a proxy are created. The
> SSH provider also now knows how to automatically forward both the proxy
> and the CA cert.
> 
> The result is that when you use SSH you don't have to care about any GSI
> issue. It should just work.
> 
> Right now there is a minimum lifetime of one week on the use of the
> proxies (the CA certs have a lifetime of two weeks, but they will be
> re-used if the have at least one week left). Point being that swift
> stuff running for more than one week with these may have problems. That
> can be changed.
> 
> Anyway, give it a try and let me know how it works.
> 
> Mihael
> 
> On Thu, 2012-08-02 at 22:33 -0500, Michael Wilde wrote:
> > We're trying to not require the user to do either of these two things:
> > as long as the user can ssh to the remote system, coasters sith say
> > ssh:pbs should work with no other security setup by the user.
> > 
> > So the problem could be solved (1) with the kind of shared-secret
> > solution you have mentioned in the past, or (2) with making -nosec
> > work for automatic remote coasters (assuming we determine that is
> > sufficiently safe), or (3) we could include in Swift a single user
> > cert/proxy and a CA signing cert for it, and automatically place that
> > on the remote side as part of bootstrap. Eg, a SimpleCA cert, if
> > anyone can get SimpleCA working, or just find a set of matching certs.
> > Or (4) we  require that the user create a valid proxy based on a known
> > supported CA, before running Swift, and we grab that proxy and place
> > it on the remote side at or before bootstrap. I *think* that David
> > could implement this last solution on his own, as part of swiftrun or
> > cmtsrun.  It (4) might be the most reasonable for CMTS, given that
> > their workflows will likely require access to at least one GridFTP
> > server if any apps run remotely.
> > 
> > Does that analysis and list of 4 alternatives seem sound?
> > 
> > - Mike
> > 
> > 
> > ----- Original Message -----
> > > From: "Mihael Hategan" <hategan at mcs.anl.gov>
> > > To: "Michael Wilde" <wilde at mcs.anl.gov>
> > > Cc: "Kyle Chard" <kyle at ci.uchicago.edu>, "David Kelly" <davidk at ci.uchicago.edu>
> > > Sent: Thursday, August 2, 2012 9:35:16 PM
> > > Subject: Re: Devel help needed for CMTS project
> > > On Fri, 2012-07-27 at 14:08 -0500, Michael Wilde wrote:
> > > 
> > > > - Ability to run remote coasters jobs without an x509 user and ca
> > > > cert. Alternatively as a stopgap: a pair of certs that either our
> > > > scripts or users could install to solve the problem. Eg, from
> > > > SimpleCA
> > > > or some other source.
> > > 
> > > What problem are we trying to solve here?
> > > 
> > > 1. Said users not having a gsi certificate
> > > 
> > > 2. Coasters and ssh requiring a proxy on the remote side
> > 
> 
> 
> 




From wilde at mcs.anl.gov  Mon Nov 12 14:03:25 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Mon, 12 Nov 2012 14:03:25 -0600 (CST)
Subject: [Swift-devel] How to adapt auto-ssl feature from ssh to
	persistent coasters?
In-Reply-To: <1520263183.32432.1352750574447.JavaMail.root@zimbra.anl.gov>
Message-ID: <1600269085.32434.1352750605970.JavaMail.root@zimbra.anl.gov>

Yes, that would work. I'll see if we can work around this for now with manual coasters.

- Mike

----- Original Message -----
> From: "Mihael Hategan" <hategan at mcs.anl.gov>
> To: "Michael Wilde" <wilde at mcs.anl.gov>
> Cc: "swift-devel" <swift-devel at ci.uchicago.edu>
> Sent: Monday, November 12, 2012 1:43:29 PM
> Subject: Re: How to adapt auto-ssl feature from ssh to persistent coasters?
> Shouldn't we fix the local:x version instead? I think it's both easier
> to use and easier to fix and faster and less demanding on resources.
> 
> On Mon, 2012-11-12 at 13:38 -0600, Michael Wilde wrote:
> > Mihael, All,
> >
> > Can we use parts of the ssh-based solution below for persistent
> > automatic coasters on a local machine?
> >
> > I was able to create the two local coaster worker pools I need for a
> > mixed MPI/Serial swift script by starting two coaster servers after
> > I created an x509 proxy using globus.
> >
> > Even though the servers were started with -nosec, I was not able to
> > get swift to use these servers with automatic workers. The swift
> > command complained about not finding a proxy file in /tmp. When I
> > created such a proxy manual using grid-proxy-init, everything worked
> > as desired.
> >
> > Now I want to hand this solution off to a user to test, and the user
> > does not have a suitable cert. Do the tools and/or temp certs exist
> > in the current swift release to create a suitable proxy manually?
> >
> > Or, is there a way to have the swift command not insist on a proxy -
> > as the servers and workers are all on the same local cluster?
> >
> > - Mike
> >
> > ----- Forwarded Message -----
> > From: "Mihael Hategan" <hategan at mcs.anl.gov>
> > To: "Michael Wilde" <wilde at mcs.anl.gov>
> > Cc: "Kyle Chard" <kyle at ci.uchicago.edu>, "David Kelly"
> > <davidk at ci.uchicago.edu>
> > Sent: Monday, August 6, 2012 11:45:24 PM
> > Subject: Re: Devel help needed for CMTS project
> >
> > There is a solution now in trunk. Whenever you use SSH as the
> > coaster
> > boot handler, a set of CA keys, user keys and a proxy are created.
> > The
> > SSH provider also now knows how to automatically forward both the
> > proxy
> > and the CA cert.
> >
> > The result is that when you use SSH you don't have to care about any
> > GSI
> > issue. It should just work.
> >
> > Right now there is a minimum lifetime of one week on the use of the
> > proxies (the CA certs have a lifetime of two weeks, but they will be
> > re-used if the have at least one week left). Point being that swift
> > stuff running for more than one week with these may have problems.
> > That
> > can be changed.
> >
> > Anyway, give it a try and let me know how it works.
> >
> > Mihael
> >
> > On Thu, 2012-08-02 at 22:33 -0500, Michael Wilde wrote:
> > > We're trying to not require the user to do either of these two
> > > things:
> > > as long as the user can ssh to the remote system, coasters sith
> > > say
> > > ssh:pbs should work with no other security setup by the user.
> > >
> > > So the problem could be solved (1) with the kind of shared-secret
> > > solution you have mentioned in the past, or (2) with making -nosec
> > > work for automatic remote coasters (assuming we determine that is
> > > sufficiently safe), or (3) we could include in Swift a single user
> > > cert/proxy and a CA signing cert for it, and automatically place
> > > that
> > > on the remote side as part of bootstrap. Eg, a SimpleCA cert, if
> > > anyone can get SimpleCA working, or just find a set of matching
> > > certs.
> > > Or (4) we require that the user create a valid proxy based on a
> > > known
> > > supported CA, before running Swift, and we grab that proxy and
> > > place
> > > it on the remote side at or before bootstrap. I *think* that David
> > > could implement this last solution on his own, as part of swiftrun
> > > or
> > > cmtsrun. It (4) might be the most reasonable for CMTS, given that
> > > their workflows will likely require access to at least one GridFTP
> > > server if any apps run remotely.
> > >
> > > Does that analysis and list of 4 alternatives seem sound?
> > >
> > > - Mike
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Mihael Hategan" <hategan at mcs.anl.gov>
> > > > To: "Michael Wilde" <wilde at mcs.anl.gov>
> > > > Cc: "Kyle Chard" <kyle at ci.uchicago.edu>, "David Kelly"
> > > > <davidk at ci.uchicago.edu>
> > > > Sent: Thursday, August 2, 2012 9:35:16 PM
> > > > Subject: Re: Devel help needed for CMTS project
> > > > On Fri, 2012-07-27 at 14:08 -0500, Michael Wilde wrote:
> > > >
> > > > > - Ability to run remote coasters jobs without an x509 user and
> > > > > ca
> > > > > cert. Alternatively as a stopgap: a pair of certs that either
> > > > > our
> > > > > scripts or users could install to solve the problem. Eg, from
> > > > > SimpleCA
> > > > > or some other source.
> > > >
> > > > What problem are we trying to solve here?
> > > >
> > > > 1. Said users not having a gsi certificate
> > > >
> > > > 2. Coasters and ssh requiring a proxy on the remote side
> > >
> >
> >
> >

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From marialemos72 at gmail.com  Fri Nov 16 11:33:37 2012
From: marialemos72 at gmail.com (WorldCIST)
Date: Fri, 16 Nov 2012 17:33:37 +0000
Subject: [Swift-devel] Best papers published in JCR/ISI JOURNALS - Deadline:
	November 25
Message-ID: <20121116173256.D11E57CC08D@mailrelay.anl.gov>

Apologies if you are receiving this mail more than once...

Please disseminate by colleagues, researchers, students, etc. Thanks a lot!


**********************************************************************************
                             WorldCIST'13
The 2013 World Conference on Information Systems and Technologies
                   March 27 - 30, Algarve, Portugal
                   http://www.aisti.eu/worldcist13/
**********************************************************************************

SCOPE

The 2013 World Conference on Information Systems and Technologies (WorldCIST'13: http://www.aisti.eu/worldcist13/) is a global forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Information Systems and Technologies.

We are pleased to invite you to submit your papers to WorldCISTI'13. All submissions will be reviewed on the basis of relevance, originality, importance and clarity.


THEMES

Submitted papers should be related with one or more of the main themes proposed for the Conference:

A) Information and Knowledge Management (IKM);

B) Organizational Models and Information Systems (OMIS);

C) Intelligent and Decision Support Systems (IDSS);

D) Software Systems, Architectures, Applications and Tools (SSAAT);

E) Computer Networks, Mobility and Pervasive Systems (CNMPS);

F) Human-Computer Interaction (HCI).


TYPES OF SUBMISSIONS AND DECISIONS

Four types of papers can be submitted:

Full paper: Finished or consolidated R&D works, to be included in one of the Conference themes. These papers are assigned a 10-page limit.

Short paper: Ongoing works with relevant preliminary results, open to discussion. These papers are assigned a 7-page limit.

Poster paper: Initial work with relevant ideas, open to discussion. These papers are assigned to a 4-page limit.

Company paper: Companies' papers that show practical experience, R & D, tools, etc., focused on some topics of the conference. These papers are assigned to a 4-page limit.

Submitted papers must comply with the format of Advances in Intelligent Systems and Computing Series (see http://www.aisti.eu/worldcist13/springerformat.doc) be written in English, must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors? identification. Therefore, the authors? names, affiliations and bibliographic references should not be included in the version for evaluation by the Program Committee. This information should only be included in the camera-ready version.

All papers will be subjected to a ?double-blind review? by at least two members of the Program Committee.

Based on Program Committee evaluation, a paper can be rejected or accepted by the Conference Chairs. In the later case, it can be accepted as the type originally submitted or as another type. Thus, full papers can be accepted as short papers or poster papers only. Similarly, short papers can be accepted as poster papers only. In these cases, the authors will be allowed to maintain the original number of pages in the camera-ready version.

The authors of accepted poster papers must also build and print a poster to be exhibited during the Conference. This poster must follow an A1 or A2 vertical format. The Conference includes Work Sessions where these posters are presented and orally discussed, with a 5 minute limit per poster.

The authors of accepted full papers will have 15 minutes to present their work in a Conference Work Session; approximately 5 minutes of discussion will follow each presentation. The authors of accepted short papers and company papers will have 11 minutes to present their work in a Conference Work Session; approximately 4 minutes of discussion will follow each presentation.

PUBLICATION AND INDEXING

To ensure that a full paper, short paper, poster paper or company paper is published in the Proceedings, at least one of the authors must be fully registered by the 11th of January 2013, and the paper must comply with the suggested layout and page-limit. Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.

No more than one paper per registration will be published in the Conference Proceedings. An extra fee must be paid for publication of additional papers, with a maximum of two additional papers per registration.

Full and short papers will be published in Proceedings by Springer, in Advances in Intelligent Systems and Computing Series. Poster and company papers will be published in Proceedings by AISTI.

Published full and short papers will be indexed by ISI, EI-Compendex, SCOPUS, DBLP and EBSCO, among others, and will be available in the SpringerLink Digital Library. Published poster and company papers will be indexed in EI-Compendex and EBSCO.

The authors of the best selected papers will be invited to extend them for publication in edited books and in international journals indexed by ISI/JCR, SCOPUS and/or DBLP, among others, such as:

- ACM Transactions on Modeling and Computer Simulation (TOMACS)
- Online Information Review (OIR)
- Informatics for Health and Social Care (IHSC)
- Computer Science and Information Systems (ComSIS)
- Telecommunication Systems Journal (TSJ)
- INFORMATION - An International Interdisciplinary Journal
- Journal of Organizational and End User Computing (JOEUC)
- Information Researh (IR)
- International Journal of Internet Protocol Technology (IJIPT)
- Studies in Computational Intelligence (SCI)
- Journal of Advanced Computational Intelligence and Intelligent Informatics (JACIII)
- Journal of Electrical and Computer Engineering (JECE): Special Issue in Advances in Radar Technology
- WSEAS Transactions on Systems (TS)
- Library Review (LR)
- Education for Information (EI)
- International Journal of IT/Business Alignment and Governance (IJITBAG)
- International Journal of Systems and Service-Oriented Engineering (IJSSOE)
- International Journal of Interactive Multimedia and Artificial Intelligence (IJIMAI)


IMPORTANT DATES

Paper Submission: November 25, 2012

Notification of Acceptance: December 30, 2012

Camera-ready Submission: January 9, 2013

Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: January 11, 2013.

-

Kind regards,

Maria Lemos
WorldCIST'13
http://www.aisti.eu/worldcist13/




From hategan at mcs.anl.gov  Sun Nov 18 05:04:57 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Sun, 18 Nov 2012 03:04:57 -0800
Subject: [Swift-devel] duplicate mappings detector
Message-ID: <1353236697.14391.13.camel@blabla>

I added a duplicate mapping detector to trunk. It was motivated by a
not-so-simple script a user sent. It works at run-time, but it provides
a more clear message than "file not found" or "the cache already
contains...":

Duplicate mapping found:
	h5part_files (line 272) is used to read from
file://localhost/run-0/sph-0/sph.output.h5part
	sphOut (line 234) is used to write to
file://localhost/run-0/sph-0/sph.output.h5part

It only produces a warning on stderr, since there might be cases when
duplicating mappings may work (it's still incorrect, but if the current
implementation allows it, we should at least talk before making it an
error), such as with iterate and files mapped across iterations.

Reads through multiple variables from the same file are allowed (since
they don't produce nondeterminism). Reads and writes are not allowed
together. Nor are multiple writes. These are determined based on the
input parameter to the mapper. This may not detect all problems since,
for non-input variables, it only makes the check if a static mapper is
specified, but it's a start.

It might not work quite right, so let me know if you find cases when you
get a warning but you shouldn't.



From iraicu at cs.iit.edu  Sun Nov 18 19:27:18 2012
From: iraicu at cs.iit.edu (Ioan Raicu)
Date: Sun, 18 Nov 2012 19:27:18 -0600
Subject: [Swift-devel] Fwd: [DistComp] CFP: 2nd IEEE International Workshop
 on Workflow Models, Systems,
 Services and Applications in the Cloud (CloudFlow) 2013
In-Reply-To: <CAAMCf2s1GW6fXLRR1VMr=RYQQSetBktR0rjBkrFksUhyMYS2jQ@mail.gmail.com>
References: <CAAMCf2s1GW6fXLRR1VMr=RYQQSetBktR0rjBkrFksUhyMYS2jQ@mail.gmail.com>
Message-ID: <50A98AF6.2090602@cs.iit.edu>

This seems relevant to the Swift community!
Ioan


-------- Original Message --------
Subject: 	[DistComp] CFP: 2nd IEEE International Workshop on Workflow 
Models, Systems, Services and Applications in the Cloud (CloudFlow) 2013
Date: 	Mon, 19 Nov 2012 09:22:18 +0800
From: 	yong zhao <yongzh04 at gmail.com>
To: 	distributed-computing-announce at datasys.cs.iit.edu



*Second IEEE International Workshop on Workflow Models, Systems, 
Services and Applications in the Cloud (CloudFlow) 2013*
/To be held in conjunction with the 27th IEEE International Parallel & 
Distributed Processing Symposium (IPDPS) 2013, Cambridge, Boston, 
Massachusetts, USA, May 20-24, 2013./
http://www.cloud-uestc.cn/cloudflow/home.html
*Overview*
Cloud computing is gaining tremendous momentum in both academia and 
industry, more and more people are migrating their data and applications 
into the Cloud. We have observed wide adoption of the MapReduce 
computing model and the open source Hadoop system for large scale 
distributed data processing, and a variety of ad hoc mashup techniques 
that weave together Web applications. However, these are just first 
steps towards managing complex task and data dependencies in the Cloud, 
as there are more challenging issues such as large parameter space 
exploration, data partitioning and distribution, scheduling and 
optimization, smart reruns, and provenance tracking associated with 
workflow execution.
Cloud needs structured and mature workflow technologies to handle such 
issues, and vice versa, as Cloud offers unprecedented scalability to 
workflow systems, and could potentially change the way we perceive and 
conduct research and experiments. The scale and complexity of the 
science and data analytics problems that can be handled can be greatly 
increased on the Cloud, and the on-demand nature of resource allocation 
on the Cloud will also help improve resource utilization and user 
experience.
As Cloud computing provides a paradigm-shifting utility-oriented 
computing model in terms of the unprecedented size of datacenter-level 
resource pool and the on-demand resource provisioning mechanism, there 
are lots of challenges in bringing Cloud and workflows together. We need 
high level languages and computing models for large scale workflow 
specification; we need to adapt existing workflow architectures into the 
Cloud, and integrate workflow systems with Cloud infrastructure and 
resources; we also need to leverage Cloud data storage technologies to 
efficiently distribute data over a large number of nodes and explore 
data locality during computation etc. We organize the CloudFlow workshop 
as a venue for the workflow and Cloud communities to define models and 
paradigms, present their state-of-the-art work, share their thoughts and 
experiences, and explore new directions in realizing workflows in the Cloud.
*Topics:*
We welcome the submission of original work related to the topics listed 
below, which include (in the context of Cloud):
? Models and Languages for Large Scale Workflow Specification
? Workflow Architecture and Framework
? Large Scale Workflow Systems
? Service Workflow
? Workflow Composition and Orchestration
? Workflow Migration into the Cloud
? Workflow Scheduling and Optimization
? Cloud Middleware in Support of Workflow
? Virtualized Environment
? Workflow Applications and Case Studies
? Performance and Scalability Analysis
? Peta-Scale Data Processing
? Event Processing and Messaging
? Real-Time Analytics
? Provenance
*Paper Submission*
Authors are invited to submit papers with unpublished, original work. 
The papers should not exceed 10 single-spaced double-column pages using 
10-point size font on 8.5x11 inch pages (IEEE conference style), 
including figures, tables, and references.
Paper submission should be done via the online CMT system, Microsoft?s 
Academic Conference Management Service 
(*https://cmt.research.microsoft.com/CF2013*) by midnight January 9th, 
2013 Pacific Time. The final format should be in PDF. Proceedings of the 
workshop will be published by the IEEE Digital Library (indexed by EI) 
and distributed at the conference. Selected excellent work may be 
eligible for additional post-conference publication as journal articles 
or book chapters. Submission implies the willingness of at least one of 
the authors to register and present the paper.
*Important Dates*
**
Paper submission: January 9th, 2013
Acceptance notification: February 8th, 2013
Final paper due: Feb 19th, 2013
*Organization*
Workshop Chairs:
Dr. Yong Zhao
University of Electronic Science and Technology of China, China
yongzh04 at gmail.com <mailto:yongzh04 at gmail.com>
Dr. Cui Lin
California State University, Fresno, USA
clin at csufresno.edu <mailto:clin at csufresno.edu>
Dr. Shiyong Lu
Wayne State University, USA
shiyong at wayne.edu <mailto:shiyong at wayne.edu>
Program Chair:
Dr. Wenhong Tian
University of Electronic Science and Technology of China, China
Publicity Chair:
Dr. Ruini Xue
University of Electronic Science and Technology of China, China
*Steering Committee *
? Daniel S. Katz, University of Chicago, U.S.A.
? Mike Wilde, University of Chicago, U.S.A.
? Ewa Deelman, University of South California, U.S.A.
? Tevfik Kosar, University at Buffalo, U.S.A.
? Ilkay Altintas, San Diego Supercomputer Center, U.S.A.
? Ioan Raicu, Illinois Institute of Technology, U.S.A.
? Yogesh Simmhan, University of Southern California, U.S.A.
? Ian Taylor, Cardiff University, U.K.
? Weimin Zheng, Tsinghua University, China
? Hai Jin, Huazhong University of Science and Engineering, China
? Wanchun Dou, Nanjing University, China
? Hui Zhang, National Science  and Technology Infrastructure, China
*Program Committee *
? Shawn Bowers, Gonzaga University, U.S.A.
? Douglas Thain, University of Notre Dame, U.S.A.
? Ian Gorton, Pacific Northwest National Laboratory, U.S.A.
? Artem Chebotko, University of Texas at Pan American, U.S.A.
? Weisong Shi, Wayne State University, U.S.A.
? Paolo Missier, Newcastle University, U.K.
? Wei Tan, IBM T. J. Watson Research Center, U.S.A.
? Jianwu Wang, San Diego Super Computer Center, U.S.A.
? Ping Yang, Binghamton University, U.S.A.
? Jian Guo, Harvard University, U.S.A.
? Liqiang Wang, University of Wyoming, U.S.A.
? Paul Groth, VU University Amsterdam, the Netherlands
? Zhiming Zhao, University of Amsterdam, the Netherlands
? Marta Mattoso, Federal University of Rio de Janeiro, Brazil
? Wenhong Tian, University of Electronic Science and Technology of 
China, China
? Ruini Xue, Tsinghua University, China
? Jian Cao, Shanghai Jiaotong University, China
? Jianxun Liu, Hunan University of Science and Technology, China
? Song Zhang, Chinese Academy of Sciences, China
? Hua Hu, Hangzhou Dianzi University, China
==========================================================
Yong Zhao
yongzh04 at gmail.com <mailto:yongzh04 at gmail.com>
Director, Extreme Scale Network Computing and Service Laboratory
Professor, School of Computer Science and Engineering
University of Electronic Science and Technology of China
http://cloud-uestc.cn
==========================================================




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20121118/1852afbe/attachment.html>
-------------- next part --------------
_______________________________________________
distributed-computing-announce mailing list
distributed-computing-announce at datasys.cs.iit.edu
http://datasys.cs.iit.edu/mailman/listinfo/distributed-computing-announce


From wilde at mcs.anl.gov  Tue Nov 20 09:05:37 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Tue, 20 Nov 2012 09:05:37 -0600 (CST)
Subject: [Swift-devel] STOMP script problems - Re: stripped down script
 still has some confusing issues
In-Reply-To: <1353410405.32254.11.camel@blabla>
Message-ID: <1979603697.46601.1353423937443.JavaMail.root@zimbra.anl.gov>

This is looking good. Thanks everyone for pushing forward to resolve the problems.

Mihael, the improved error messages are looking great.

I'm cc'ing swift-devel here so that David can pick up the fixes for 0.94. Im thinking at this point its best to create a new 0.94 release candidate from trunk. Is that the way to go?

We should keep swift-support copied on future discussion.

- Mike

----- Original Message -----
> From: "Mihael Hategan" <hategan at mcs.anl.gov>
> To: "Karen L Schuchardt" <Karen.Schuchardt at pnnl.gov>
> Cc: "Michael Wilde" <wilde at mcs.anl.gov>, "Jared M Chase" <jared.chase at pnnl.gov>, "Khushbu Agarwal"
> <Khushbu.Agarwal at pnnl.gov>
> Sent: Tuesday, November 20, 2012 5:20:05 AM
> Subject: RE: Fwd: stripped down script still has some confusing issues
> On Mon, 2012-11-19 at 20:09 -0800, Mihael Hategan wrote:
> > On Mon, 2012-11-19 at 19:56 -0800, Schuchardt, Karen L wrote:
> > > Mihael,
> > >
> > > [...]
> >
> > >   And yet the script still dies in the same place. For me
> > >   iteration 32
> > > always and on either stomp.out or the stomp restart file. So
> > > something else is going on here.
> >
> > I'll give it a shot and see what's happening.
> 
> Runs fine with trunk.
> 
> Fails with 0.93, at iteration 40 for me, due to the deep linking
> issue.
> The symptom is "<some app> failed with an exit code of 1". A
> workaround
> is to specify a scratch tag in sites.xml (it forces swift to copy file
> to scratch instead of linking):
> <config>
> <pool handle="localhost">
> <filesystem provider="local"/>
> <execution provider="local" />
> <workdirectory >/home/mike/tmp/swift</workdirectory>
> <scratch>/home/mike/tmp/swift-scratch</scratch>
> </pool>
> </config>
> 
> Runs fine after that.
> 
> If the above fix doesn't work for you, you might be running into a
> different problem. Please send me the logs in that case.
> 
> [...]
> 
> > >
> > > Also Jared had trouble compiling the trunk. Can you send us a
> > > revised distribution?
> >
> > Sure, I can do that. The improved error messages might help.
> 
> www.mcs.anl.gov/~hategan/swift-trunk-r6065-cog-r3515.tar.gz
> 
> As usual, it's trunk, so it might break in various places.
> However, I added some improved error reporting, including a detector
> of
> mapping badness (it only issues warnings, but they will most likely
> result in errors later). Here's a sample output:
> 
> RunID: 20121120-0311-6sbzpc39
> Progress: time: Tue, 20 Nov 2012 03:12:03 -0800
> SwiftScript trace: 0, 500
> SwiftScript trace: Starting iteration, 0
> 
> Duplicate mapping found:
> h5part_files (line 272) is used to read from
> file://localhost/run-0/sph-0/sph.output.h5part
> sphOut (line 234) is used to write to
> file://localhost/run-0/sph-0/sph.output.h5part
> Execution failed:
> Exception in gpg:
> Arguments: [-m, run-0/writeData.out, -r, 0, -p, run-0/stomp.plot, -f,
> run-0/sph-0/sph.output.h5part]
> Host: localhost
> Directory: kls1-20121120-0311-6sbzpc39/jobs/v/gpg-vs5hh81l
> Caused by:
> File not found:
> /home/mike/tmp/swift-bugs/pnnl/subsurface/./run-0/sph-0/sph.output.h5part
> gpg, kls1.swift, line 276
> hybridModel, kls1.swift, line 303
> iterate, kls1.swift, line 297
> 
> Mihael

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From wilde at mcs.anl.gov  Tue Nov 20 12:36:59 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Tue, 20 Nov 2012 12:36:59 -0600 (CST)
Subject: [Swift-devel] Fix to run multiple local coaster services within
	same Swift JVM?
In-Reply-To: <20121118230528.A484F8D0007A@bridled.ci.uchicago.edu>
Message-ID: <565816333.47231.1353436619941.JavaMail.root@zimbra.anl.gov>

Mihael, does this commit address the problem I had running two local coaster services for two separate resource pools, within the same Swift JVM?

If so, I will re-test.

Thanks,

- <ike

----- Original Message -----
> From: swift at ci.uchicago.edu
> To: swift-commit at ci.uchicago.edu
> Sent: Sunday, November 18, 2012 5:05:28 PM
> Subject: [Swift-commit] cog r3515
> ------------------------------------------------------------------------
> r3515 | hategan | 2012-11-18 17:01:24 -0600 (Sun, 18 Nov 2012) | 1
> line
> 
> better channel names in logs; ensure unique ids for worker channels if
> two or more services are on the same jvm
> ------------------------------------------------------------------------
> Index:
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/RegistrationHandler.java
> ===================================================================
> ---
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/RegistrationHandler.java
> (revision 3514)
> +++
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/RegistrationHandler.java
> (working copy)
> @@ -48,7 +48,9 @@
> options = Collections.emptyMap();
> }
> 
> - logger.debug("registering: " + id + " " + url);
> + if (logger.isDebugEnabled()) {
> + logger.debug("registering: " + id + " " + url);
> + }
> 
> KarajanChannel channel = getChannel();
> ChannelContext context = channel.getChannelContext();
> Index:
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/LocalService.java
> ===================================================================
> ---
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/LocalService.java
> (revision 3514)
> +++
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/LocalService.java
> (working copy)
> @@ -18,9 +18,7 @@
> 
> import org.apache.log4j.Logger;
> import org.globus.cog.abstraction.coaster.service.Registering;
> -import org.globus.cog.abstraction.impl.common.AbstractionFactory;
> import org.globus.cog.abstraction.impl.common.execution.JobException;
> -import
> org.globus.cog.abstraction.impl.common.task.ServiceContactImpl;
> import
> org.globus.cog.abstraction.impl.common.task.TaskSubmissionException;
> import org.globus.cog.abstraction.interfaces.Service;
> import org.globus.cog.abstraction.interfaces.Status;
> @@ -71,7 +69,7 @@
> logger.info("Got connection");
> try {
> ConnectionHandler handler =
> - new ConnectionHandler(this, sock, LocalRequestManager.INSTANCE);
> + new ConnectionHandler("service-" + sock.getPort(), this, sock,
> LocalRequestManager.INSTANCE);
> logger.info("Initialized connection handler");
> handler.start();
> logger.info("Connection handler started");
> @@ -84,7 +82,7 @@
> public void handleConnection(InputStream is, OutputStream os) {
> try {
> ConnectionHandler handler =
> - new ConnectionHandler(this, is, os, LocalRequestManager.INSTANCE);
> + new ConnectionHandler("service-pipe", this, is, os,
> LocalRequestManager.INSTANCE);
> handler.start();
> }
> catch (Exception e) {
> @@ -93,7 +91,7 @@
> }
> 
> public PipedServerChannel newPipedServerChannel() {
> - return new PipedServerChannel(LocalRequestManager.INSTANCE, new
> ChannelContext(this));
> + return new PipedServerChannel(LocalRequestManager.INSTANCE, new
> ChannelContext("spipe", this));
> }
> 
> public String waitForRegistration(Task t, String id) throws
> InterruptedException,
> Index:
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/CoasterService.java
> ===================================================================
> ---
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/CoasterService.java
> (revision 3514)
> +++
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/CoasterService.java
> (working copy)
> @@ -128,7 +128,7 @@
> }
> else {
> try {
> - ConnectionHandler handler = new ConnectionHandler(this, sock,
> + ConnectionHandler handler = new ConnectionHandler("cps-" +
> sock.getPort(), this, sock,
> COASTER_REQUEST_MANAGER);
> handler.start();
> }
> @@ -194,7 +194,7 @@
> PipedServerChannel psc =
> ServiceManager.getDefault().getLocalService().newPipedServerChannel();
> PipedClientChannel pcc =
> - new PipedClientChannel(COASTER_REQUEST_MANAGER, new
> ChannelContext(), psc);
> + new PipedClientChannel(COASTER_REQUEST_MANAGER, new
> ChannelContext("cpipe"), psc);
> psc.setClientChannel(pcc);
> ChannelManager.getManager().registerChannel(pcc.getChannelContext().getChannelID(),
> pcc);
> ChannelManager.getManager().registerChannel(psc.getChannelContext().getChannelID(),
> psc);
> Index:
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/LocalTCPService.java
> ===================================================================
> ---
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/LocalTCPService.java
> (revision 3514)
> +++
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/LocalTCPService.java
> (working copy)
> @@ -102,10 +102,13 @@
> channel = ServerSocketChannel.open();
> channel.configureBlocking(true);
> if(port == 0) {
> - PortRange portRange = PortRange.getTcpInstance();
> - if(portRange != null && portRange.isEnabled()) {
> - port = portRange.getFreePort(port);
> - }
> + PortRange portRange = PortRange.getTcpInstance();
> + if(portRange != null && portRange.isEnabled()) {
> + synchronized(portRange) {
> + port = portRange.getFreePort(port);
> + portRange.setUsed(port);
> + }
> + }
> }
> channel.socket().bind(new InetSocketAddress(port));
> 
> @@ -189,12 +192,18 @@
> System.err.println("Irrecoverable channel exception: " +
> e.getMessage());
> System.exit(2);
> }
> +
> + private static int idSeq = 1;
> +
> + private synchronized static int nextId() {
> + return idSeq++;
> + }
> 
> private static class WorkerConnectionHandler extends ConnectionHandler
> {
> public WorkerConnectionHandler(Service service, Socket socket,
> RequestManager requestManager)
> throws IOException {
> super(socket, new WorkerChannel(socket, requestManager,
> - new ChannelContext(service)), requestManager);
> + new ChannelContext("worker-" + nextId(), service)), requestManager);
> }
> }
> 
> Index:
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Node.java
> ===================================================================
> ---
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Node.java
> (revision 3514)
> +++
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Node.java
> (working copy)
> @@ -85,6 +85,7 @@
> }
> try {
> KarajanChannel channel = getChannel();
> + channel.setLocalShutdown();
> ChannelManager.getManager().reserveLongTerm(channel);
> ShutdownCommand cmd = new ShutdownCommand();
> cmd.executeAsync(channel, this);
> Index:
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/BlockQueueProcessor.java
> ===================================================================
> ---
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/BlockQueueProcessor.java
> (revision 3514)
> +++
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/BlockQueueProcessor.java
> (working copy)
> @@ -98,6 +98,12 @@
> */
> private static final NumberFormat SECONDS_3 =
> new DecimalFormat("0.000");
> +
> + private static int sid;
> +
> + private synchronized static int nextSid() {
> + return sid++;
> + }
> 
> public BlockQueueProcessor(Settings settings) {
> super("Block Queue Processor");
> @@ -105,7 +111,7 @@
> holding = new SortedJobSet();
> blocks = new TreeMap<String, Block>();
> tl = new HashMap<Integer, List<Job>>();
> - id = DDF.format(new Date());
> + id = DDF.format(new Date()) + nextSid();
> incoming = new ArrayList<Job>();
> metric = new OverallocatedJobDurationMetric(settings);
> queued = new SortedJobSet(metric);
> Index:
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Block.java
> ===================================================================
> ---
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Block.java
> (revision 3514)
> +++
> modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Block.java
> (working copy)
> @@ -59,6 +59,10 @@
> private long lastUsed;
> 
> private static int sid;
> +
> + private synchronized static int nextSID() {
> + return sid++;
> + }
> 
> private static final NumberFormat IDF = new DecimalFormat("000000");
> 
> @@ -72,7 +76,7 @@
> }
> 
> public Block(int workers, TimeInterval walltime, BlockQueueProcessor
> ap) {
> - this(ap.getBQPId() + "-" + IDF.format(sid++), workers, walltime,
> ap);
> + this(ap.getBQPId() + "-" + IDF.format(nextSID()), workers, walltime,
> ap);
> }
> 
> public Block(String id, int workers, TimeInterval walltime,
> BlockQueueProcessor ap) {
> _______________________________________________
> Swift-commit mailing list
> Swift-commit at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-commit

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From hategan at mcs.anl.gov  Tue Nov 20 13:41:58 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Tue, 20 Nov 2012 11:41:58 -0800
Subject: [Swift-devel] Fix to run multiple local coaster services within
 same Swift JVM?
In-Reply-To: <565816333.47231.1353436619941.JavaMail.root@zimbra.anl.gov>
References: <565816333.47231.1353436619941.JavaMail.root@zimbra.anl.gov>
Message-ID: <1353440518.25469.1.camel@blabla>

Yes. I updated the bug with the relevant info. See
https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=869

Mihael

On Tue, 2012-11-20 at 12:36 -0600, Michael Wilde wrote:
> Mihael, does this commit address the problem I had running two local coaster services for two separate resource pools, within the same Swift JVM?
> 
> If so, I will re-test.
> 
> Thanks,
> 
> - <ike
> 
> ----- Original Message -----
> > From: swift at ci.uchicago.edu
> > To: swift-commit at ci.uchicago.edu
> > Sent: Sunday, November 18, 2012 5:05:28 PM
> > Subject: [Swift-commit] cog r3515
> > ------------------------------------------------------------------------
> > r3515 | hategan | 2012-11-18 17:01:24 -0600 (Sun, 18 Nov 2012) | 1
> > line
> > 
> > better channel names in logs; ensure unique ids for worker channels if
> > two or more services are on the same jvm
> > ------------------------------------------------------------------------
> > Index:
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/RegistrationHandler.java
> > ===================================================================
> > ---
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/RegistrationHandler.java
> > (revision 3514)
> > +++
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/RegistrationHandler.java
> > (working copy)
> > @@ -48,7 +48,9 @@
> > options = Collections.emptyMap();
> > }
> > 
> > - logger.debug("registering: " + id + " " + url);
> > + if (logger.isDebugEnabled()) {
> > + logger.debug("registering: " + id + " " + url);
> > + }
> > 
> > KarajanChannel channel = getChannel();
> > ChannelContext context = channel.getChannelContext();
> > Index:
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/LocalService.java
> > ===================================================================
> > ---
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/LocalService.java
> > (revision 3514)
> > +++
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/local/LocalService.java
> > (working copy)
> > @@ -18,9 +18,7 @@
> > 
> > import org.apache.log4j.Logger;
> > import org.globus.cog.abstraction.coaster.service.Registering;
> > -import org.globus.cog.abstraction.impl.common.AbstractionFactory;
> > import org.globus.cog.abstraction.impl.common.execution.JobException;
> > -import
> > org.globus.cog.abstraction.impl.common.task.ServiceContactImpl;
> > import
> > org.globus.cog.abstraction.impl.common.task.TaskSubmissionException;
> > import org.globus.cog.abstraction.interfaces.Service;
> > import org.globus.cog.abstraction.interfaces.Status;
> > @@ -71,7 +69,7 @@
> > logger.info("Got connection");
> > try {
> > ConnectionHandler handler =
> > - new ConnectionHandler(this, sock, LocalRequestManager.INSTANCE);
> > + new ConnectionHandler("service-" + sock.getPort(), this, sock,
> > LocalRequestManager.INSTANCE);
> > logger.info("Initialized connection handler");
> > handler.start();
> > logger.info("Connection handler started");
> > @@ -84,7 +82,7 @@
> > public void handleConnection(InputStream is, OutputStream os) {
> > try {
> > ConnectionHandler handler =
> > - new ConnectionHandler(this, is, os, LocalRequestManager.INSTANCE);
> > + new ConnectionHandler("service-pipe", this, is, os,
> > LocalRequestManager.INSTANCE);
> > handler.start();
> > }
> > catch (Exception e) {
> > @@ -93,7 +91,7 @@
> > }
> > 
> > public PipedServerChannel newPipedServerChannel() {
> > - return new PipedServerChannel(LocalRequestManager.INSTANCE, new
> > ChannelContext(this));
> > + return new PipedServerChannel(LocalRequestManager.INSTANCE, new
> > ChannelContext("spipe", this));
> > }
> > 
> > public String waitForRegistration(Task t, String id) throws
> > InterruptedException,
> > Index:
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/CoasterService.java
> > ===================================================================
> > ---
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/CoasterService.java
> > (revision 3514)
> > +++
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/CoasterService.java
> > (working copy)
> > @@ -128,7 +128,7 @@
> > }
> > else {
> > try {
> > - ConnectionHandler handler = new ConnectionHandler(this, sock,
> > + ConnectionHandler handler = new ConnectionHandler("cps-" +
> > sock.getPort(), this, sock,
> > COASTER_REQUEST_MANAGER);
> > handler.start();
> > }
> > @@ -194,7 +194,7 @@
> > PipedServerChannel psc =
> > ServiceManager.getDefault().getLocalService().newPipedServerChannel();
> > PipedClientChannel pcc =
> > - new PipedClientChannel(COASTER_REQUEST_MANAGER, new
> > ChannelContext(), psc);
> > + new PipedClientChannel(COASTER_REQUEST_MANAGER, new
> > ChannelContext("cpipe"), psc);
> > psc.setClientChannel(pcc);
> > ChannelManager.getManager().registerChannel(pcc.getChannelContext().getChannelID(),
> > pcc);
> > ChannelManager.getManager().registerChannel(psc.getChannelContext().getChannelID(),
> > psc);
> > Index:
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/LocalTCPService.java
> > ===================================================================
> > ---
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/LocalTCPService.java
> > (revision 3514)
> > +++
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/LocalTCPService.java
> > (working copy)
> > @@ -102,10 +102,13 @@
> > channel = ServerSocketChannel.open();
> > channel.configureBlocking(true);
> > if(port == 0) {
> > - PortRange portRange = PortRange.getTcpInstance();
> > - if(portRange != null && portRange.isEnabled()) {
> > - port = portRange.getFreePort(port);
> > - }
> > + PortRange portRange = PortRange.getTcpInstance();
> > + if(portRange != null && portRange.isEnabled()) {
> > + synchronized(portRange) {
> > + port = portRange.getFreePort(port);
> > + portRange.setUsed(port);
> > + }
> > + }
> > }
> > channel.socket().bind(new InetSocketAddress(port));
> > 
> > @@ -189,12 +192,18 @@
> > System.err.println("Irrecoverable channel exception: " +
> > e.getMessage());
> > System.exit(2);
> > }
> > +
> > + private static int idSeq = 1;
> > +
> > + private synchronized static int nextId() {
> > + return idSeq++;
> > + }
> > 
> > private static class WorkerConnectionHandler extends ConnectionHandler
> > {
> > public WorkerConnectionHandler(Service service, Socket socket,
> > RequestManager requestManager)
> > throws IOException {
> > super(socket, new WorkerChannel(socket, requestManager,
> > - new ChannelContext(service)), requestManager);
> > + new ChannelContext("worker-" + nextId(), service)), requestManager);
> > }
> > }
> > 
> > Index:
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Node.java
> > ===================================================================
> > ---
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Node.java
> > (revision 3514)
> > +++
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Node.java
> > (working copy)
> > @@ -85,6 +85,7 @@
> > }
> > try {
> > KarajanChannel channel = getChannel();
> > + channel.setLocalShutdown();
> > ChannelManager.getManager().reserveLongTerm(channel);
> > ShutdownCommand cmd = new ShutdownCommand();
> > cmd.executeAsync(channel, this);
> > Index:
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/BlockQueueProcessor.java
> > ===================================================================
> > ---
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/BlockQueueProcessor.java
> > (revision 3514)
> > +++
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/BlockQueueProcessor.java
> > (working copy)
> > @@ -98,6 +98,12 @@
> > */
> > private static final NumberFormat SECONDS_3 =
> > new DecimalFormat("0.000");
> > +
> > + private static int sid;
> > +
> > + private synchronized static int nextSid() {
> > + return sid++;
> > + }
> > 
> > public BlockQueueProcessor(Settings settings) {
> > super("Block Queue Processor");
> > @@ -105,7 +111,7 @@
> > holding = new SortedJobSet();
> > blocks = new TreeMap<String, Block>();
> > tl = new HashMap<Integer, List<Job>>();
> > - id = DDF.format(new Date());
> > + id = DDF.format(new Date()) + nextSid();
> > incoming = new ArrayList<Job>();
> > metric = new OverallocatedJobDurationMetric(settings);
> > queued = new SortedJobSet(metric);
> > Index:
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Block.java
> > ===================================================================
> > ---
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Block.java
> > (revision 3514)
> > +++
> > modules/provider-coaster/src/org/globus/cog/abstraction/coaster/service/job/manager/Block.java
> > (working copy)
> > @@ -59,6 +59,10 @@
> > private long lastUsed;
> > 
> > private static int sid;
> > +
> > + private synchronized static int nextSID() {
> > + return sid++;
> > + }
> > 
> > private static final NumberFormat IDF = new DecimalFormat("000000");
> > 
> > @@ -72,7 +76,7 @@
> > }
> > 
> > public Block(int workers, TimeInterval walltime, BlockQueueProcessor
> > ap) {
> > - this(ap.getBQPId() + "-" + IDF.format(sid++), workers, walltime,
> > ap);
> > + this(ap.getBQPId() + "-" + IDF.format(nextSID()), workers, walltime,
> > ap);
> > }
> > 
> > public Block(String id, int workers, TimeInterval walltime,
> > BlockQueueProcessor ap) {
> > _______________________________________________
> > Swift-commit mailing list
> > Swift-commit at ci.uchicago.edu
> > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-commit
> 




From hategan at mcs.anl.gov  Tue Nov 20 13:44:57 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Tue, 20 Nov 2012 11:44:57 -0800
Subject: [Swift-devel] STOMP script problems - Re: stripped down script
 still has some confusing issues
In-Reply-To: <1979603697.46601.1353423937443.JavaMail.root@zimbra.anl.gov>
References: <1979603697.46601.1353423937443.JavaMail.root@zimbra.anl.gov>
Message-ID: <1353440697.25469.4.camel@blabla>

On Tue, 2012-11-20 at 09:05 -0600, Michael Wilde wrote:
> This is looking good. Thanks everyone for pushing forward to resolve the problems.
> 
> Mihael, the improved error messages are looking great.
> 
> I'm cc'ing swift-devel here so that David can pick up the fixes for 0.94. Im thinking at this point its best to create a new 0.94 release candidate from trunk. Is that the way to go?

Well, some are fixes and some are fixes that involve changes deep into
swift. I give them moderate to high chance that they break something.

But maybe we should actually make RCs (or alphas) more often in order to
encourage users to test these things.

Mihael



From davidk at ci.uchicago.edu  Tue Nov 20 14:23:10 2012
From: davidk at ci.uchicago.edu (David Kelly)
Date: Tue, 20 Nov 2012 14:23:10 -0600 (CST)
Subject: [Swift-devel] STOMP script problems - Re: stripped down script
 still has some confusing issues
In-Reply-To: <1353440697.25469.4.camel@blabla>
Message-ID: <1855101894.89384.1353442990541.JavaMail.root@zimbra-mb2.anl.gov>

I just took a quick look at the nightly tests for trunk and noticed there are a few failures there. I created a ticket for this at https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=873. It seems to have started failing for the tests run early on November 11th.

I feel like 0.94RC1 is pretty stable at this point, but if these changes are important I can copy the changes from trunk and start testing more thoroughly.

David

----- Original Message -----
> From: "Mihael Hategan" <hategan at mcs.anl.gov>
> To: "Michael Wilde" <wilde at mcs.anl.gov>
> Cc: "swift-devel" <swift-devel at ci.uchicago.edu>
> Sent: Tuesday, November 20, 2012 1:44:57 PM
> Subject: Re: [Swift-devel] STOMP script problems - Re: stripped down script still has some confusing issues
> On Tue, 2012-11-20 at 09:05 -0600, Michael Wilde wrote:
> > This is looking good. Thanks everyone for pushing forward to resolve
> > the problems.
> >
> > Mihael, the improved error messages are looking great.
> >
> > I'm cc'ing swift-devel here so that David can pick up the fixes for
> > 0.94. Im thinking at this point its best to create a new 0.94
> > release candidate from trunk. Is that the way to go?
> 
> Well, some are fixes and some are fixes that involve changes deep into
> swift. I give them moderate to high chance that they break something.
> 
> But maybe we should actually make RCs (or alphas) more often in order
> to
> encourage users to test these things.
> 
> Mihael
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel


From wilde at mcs.anl.gov  Wed Nov 21 08:45:19 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Wed, 21 Nov 2012 08:45:19 -0600 (CST)
Subject: [Swift-devel] Creating 0.94 RC with fixes for STOMP
In-Reply-To: <920165785FF98D4DB045A7060072E86A0182ED2C48B3@EMAIL04.pnl.gov>
Message-ID: <1377396670.48643.1353509119821.JavaMail.root@zimbra.anl.gov>

was: Re: stripped down script still has some confusing issues

Karen, Mihael, all - thanks again for pushing through and solving these problems.

Its great to see confirmation here of the perhaps obvious thesis that if a system gives clear messages, users can far more readily resolve problems.

Mihael - David is planning to create a new 0.94 release candidate, and was deliberating how much of trunk to include. (My preference would be to start the RC with all of current trunk).  Can you two discuss what to include in the RC, and then David will create the release and start testing it?

Thanks,

- Mike

----- Original Message -----
> From: "Karen L Schuchardt" <Karen.Schuchardt at pnnl.gov>
> To: "Mihael Hategan" <hategan at mcs.anl.gov>
> Cc: "Michael Wilde" <wilde at mcs.anl.gov>, "Jared M Chase" <jared.chase at pnnl.gov>, "Khushbu Agarwal"
> <Khushbu.Agarwal at pnnl.gov>
> Sent: Wednesday, November 21, 2012 1:07:08 AM
> Subject: RE: Fwd: stripped down script still has some confusing issues
> Hey guys, I managed to get the script fully reconstructed and run it
> out quite a way in my test environment on my mac. The improved error
> messages really helped a lot. I had several errors due mainly to
> having to tweak things a bit for the test environment but they were
> easy to pinpoint. That is the good news. The bad news is that it looks
> like part of our work environment on hopper was cleaned out during the
> last disk purge so we will have to reconstruct it before I can truly
> test it. Awww, its always something. But if you want to do an RC off
> this version, that seems reasonable to me. Thanks for your efforts.
> 
> Karen
> ________________________________________
> From: Mihael Hategan [hategan at mcs.anl.gov]
> Sent: Tuesday, November 20, 2012 3:20 AM
> To: Schuchardt, Karen L
> Cc: Michael Wilde; Chase, Jared M; Agarwal, Khushbu
> Subject: RE: Fwd: stripped down script still has some confusing issues
> 
> On Mon, 2012-11-19 at 20:09 -0800, Mihael Hategan wrote:
> > On Mon, 2012-11-19 at 19:56 -0800, Schuchardt, Karen L wrote:
> > > Mihael,
> > >
> > > [...]
> >
> > >   And yet the script still dies in the same place. For me
> > >   iteration 32
> > > always and on either stomp.out or the stomp restart file. So
> > > something else is going on here.
> >
> > I'll give it a shot and see what's happening.
> 
> Runs fine with trunk.
> 
> Fails with 0.93, at iteration 40 for me, due to the deep linking
> issue.
> The symptom is "<some app> failed with an exit code of 1". A
> workaround
> is to specify a scratch tag in sites.xml (it forces swift to copy file
> to scratch instead of linking):
> <config>
> <pool handle="localhost">
> <filesystem provider="local"/>
> <execution provider="local" />
> <workdirectory >/home/mike/tmp/swift</workdirectory>
> <scratch>/home/mike/tmp/swift-scratch</scratch>
> </pool>
> </config>
> 
> Runs fine after that.
> 
> If the above fix doesn't work for you, you might be running into a
> different problem. Please send me the logs in that case.
> 
> [...]
> 
> > >
> > > Also Jared had trouble compiling the trunk. Can you send us a
> > > revised distribution?
> >
> > Sure, I can do that. The improved error messages might help.
> 
> www.mcs.anl.gov/~hategan/swift-trunk-r6065-cog-r3515.tar.gz
> 
> As usual, it's trunk, so it might break in various places.
> However, I added some improved error reporting, including a detector
> of
> mapping badness (it only issues warnings, but they will most likely
> result in errors later). Here's a sample output:
> 
> RunID: 20121120-0311-6sbzpc39
> Progress: time: Tue, 20 Nov 2012 03:12:03 -0800
> SwiftScript trace: 0, 500
> SwiftScript trace: Starting iteration, 0
> 
> Duplicate mapping found:
> h5part_files (line 272) is used to read from
> file://localhost/run-0/sph-0/sph.output.h5part
> sphOut (line 234) is used to write to
> file://localhost/run-0/sph-0/sph.output.h5part
> Execution failed:
> Exception in gpg:
> Arguments: [-m, run-0/writeData.out, -r, 0, -p, run-0/stomp.plot, -f,
> run-0/sph-0/sph.output.h5part]
> Host: localhost
> Directory: kls1-20121120-0311-6sbzpc39/jobs/v/gpg-vs5hh81l
> Caused by:
> File not found:
> /home/mike/tmp/swift-bugs/pnnl/subsurface/./run-0/sph-0/sph.output.h5part
> gpg, kls1.swift, line 276
> hybridModel, kls1.swift, line 303
> iterate, kls1.swift, line 297
> 
> Mihael

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From hategan at mcs.anl.gov  Wed Nov 21 11:40:15 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Wed, 21 Nov 2012 09:40:15 -0800
Subject: [Swift-devel] Creating 0.94 RC with fixes for STOMP
In-Reply-To: <1377396670.48643.1353509119821.JavaMail.root@zimbra.anl.gov>
References: <1377396670.48643.1353509119821.JavaMail.root@zimbra.anl.gov>
Message-ID: <1353519615.28698.15.camel@blabla>

On Wed, 2012-11-21 at 08:45 -0600, Michael Wilde wrote:
[...]
> 
> Mihael - David is planning to create a new 0.94 release candidate, and
> was deliberating how much of trunk to include. (My preference would be
> to start the RC with all of current trunk).  Can you two discuss what
> to include in the RC, and then David will create the release and start
> testing it?

Now that we're at it, I was working yesterday on "fixing" array closing
issues. In particular cases like 
int[] a;
scope1 {
   scope2 {
     a[i1] = v1;
     f(a);
   }
   scope3 {
     a[i2] = v2;
   }
}

and variations.

The idea is that:
- closing does not need to happen in the declaration scope, but can
happen in the place where a[] is last written to (in the cases where
"last written to" happens in multiple places, Ben's partial closing will
still apply, but, again, not necessarily in the declaration scope). This
make a lot of cases that would deadlock before work now.
- the compiler determines either that:
  1. closing can happen without a deadlock and issues appropriate
statements to do so
  2. there is no way to do it without a deadlock, in which case compiler
issues a clear error message stating so.

It's not trivial because I need to keep track of both read and write
access to variables, and also their respective locations within the
scope tree, as well as how iterations and if conditions may affect
things. That combined with the general crappiness of the exiting
compiler code. But with a bit of work, I think it's doable and it will
go miles towards reducing unexpected and perplexing behavior in complex
scripts.

So I have to teach the kids about magnetic induction right now, but it's
about the last thing I have to do for the week, so this might be a good
time to finally put this issue to rest.

As usual there are advantages and disadvantages to including this in the
upcoming release, so...

Mihael



From marialemos72 at gmail.com  Wed Nov 21 11:44:29 2012
From: marialemos72 at gmail.com (WorldCIST)
Date: Wed, 21 Nov 2012 17:44:29 +0000
Subject: [Swift-devel] WorldCIST'13: Indexed by ISI, SCOPUS,
 DBLP and EI-Compendex - Deadline: November 28
Message-ID: <20121121174345.B90887CC0C6@mailrelay.anl.gov>

Apologies if you are receiving this mail more than once...

Please disseminate by colleagues, researchers, students, etc. Thanks a lot!


**********************************************************************************
                             WorldCIST'13
The 2013 World Conference on Information Systems and Technologies
                   March 27 - 30, Algarve, Portugal
                   http://www.aisti.eu/worldcist13/
**********************************************************************************

SCOPE

The 2013 World Conference on Information Systems and Technologies (WorldCIST'13: http://www.aisti.eu/worldcist13/) is a global forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Information Systems and Technologies.

We are pleased to invite you to submit your papers to WorldCISTI'13. All submissions will be reviewed on the basis of relevance, originality, importance and clarity.


THEMES

Submitted papers should be related with one or more of the main themes proposed for the Conference:

A) Information and Knowledge Management (IKM);

B) Organizational Models and Information Systems (OMIS);

C) Intelligent and Decision Support Systems (IDSS);

D) Software Systems, Architectures, Applications and Tools (SSAAT);

E) Computer Networks, Mobility and Pervasive Systems (CNMPS);

F) Human-Computer Interaction (HCI).


TYPES OF SUBMISSIONS AND DECISIONS

Four types of papers can be submitted:

Full paper: Finished or consolidated R&D works, to be included in one of the Conference themes. These papers are assigned a 10-page limit.

Short paper: Ongoing works with relevant preliminary results, open to discussion. These papers are assigned a 7-page limit.

Poster paper: Initial work with relevant ideas, open to discussion. These papers are assigned to a 4-page limit.

Company paper: Companies' papers that show practical experience, R & D, tools, etc., focused on some topics of the conference. These papers are assigned to a 4-page limit.

Submitted papers must comply with the format of Advances in Intelligent Systems and Computing Series (see http://www.aisti.eu/worldcist13/springerformat.doc) be written in English, must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors? identification. Therefore, the authors? names, affiliations and bibliographic references should not be included in the version for evaluation by the Program Committee. This information should only be included in the camera-ready version.

All papers will be subjected to a ?double-blind review? by at least two members of the Program Committee.

Based on Program Committee evaluation, a paper can be rejected or accepted by the Conference Chairs. In the later case, it can be accepted as the type originally submitted or as another type. Thus, full papers can be accepted as short papers or poster papers only. Similarly, short papers can be accepted as poster papers only. In these cases, the authors will be allowed to maintain the original number of pages in the camera-ready version.

The authors of accepted poster papers must also build and print a poster to be exhibited during the Conference. This poster must follow an A1 or A2 vertical format. The Conference includes Work Sessions where these posters are presented and orally discussed, with a 5 minute limit per poster.

The authors of accepted full papers will have 15 minutes to present their work in a Conference Work Session; approximately 5 minutes of discussion will follow each presentation. The authors of accepted short papers and company papers will have 11 minutes to present their work in a Conference Work Session; approximately 4 minutes of discussion will follow each presentation.

PUBLICATION AND INDEXING

To ensure that a full paper, short paper, poster paper or company paper is published in the Proceedings, at least one of the authors must be fully registered by the 11th of January 2013, and the paper must comply with the suggested layout and page-limit. Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.

No more than one paper per registration will be published in the Conference Proceedings. An extra fee must be paid for publication of additional papers, with a maximum of two additional papers per registration.

Full and short papers will be published in Proceedings by Springer, in Advances in Intelligent Systems and Computing Series. Poster and company papers will be published in Proceedings by AISTI.

Published full and short papers will be indexed by ISI, EI-Compendex, SCOPUS, DBLP and EBSCO, among others, and will be available in the SpringerLink Digital Library. Published poster and company papers will be indexed in EI-Compendex and EBSCO.

The authors of the best selected papers will be invited to extend them for publication in edited books and in international journals indexed by ISI/JCR, SCOPUS and/or DBLP, among others, such as:

- ACM Transactions on Modeling and Computer Simulation (TOMACS)
- Online Information Review (OIR)
- Informatics for Health and Social Care (IHSC)
- Computer Science and Information Systems (ComSIS)
- Telecommunication Systems Journal (TSJ)
- INFORMATION - An International Interdisciplinary Journal
- Journal of Organizational and End User Computing (JOEUC)
- Information Researh (IR)
- International Journal of Internet Protocol Technology (IJIPT)
- Studies in Computational Intelligence (SCI)
- Journal of Advanced Computational Intelligence and Intelligent Informatics (JACIII)
- Journal of Electrical and Computer Engineering (JECE): Special Issue in Advances in Radar Technology
- WSEAS Transactions on Systems (TS)
- Library Review (LR)
- Education for Information (EI)
- International Journal of IT/Business Alignment and Governance (IJITBAG)
- International Journal of Systems and Service-Oriented Engineering (IJSSOE)
- International Journal of Interactive Multimedia and Artificial Intelligence (IJIMAI)


IMPORTANT DATES

Paper Submission: November 25, 2012

Notification of Acceptance: December 30, 2012

Camera-ready Submission: January 9, 2013

Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: January 11, 2013.

-

Kind regards,

Maria Lemos
WorldCIST'13
http://www.aisti.eu/worldcist13/




From wilde at mcs.anl.gov  Wed Nov 21 11:47:43 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Wed, 21 Nov 2012 11:47:43 -0600 (CST)
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <1353519615.28698.15.camel@blabla>
Message-ID: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>

was: Re: Creating 0.94 RC with fixes for STOMP

 
> Now that we're at it, I was working yesterday on "fixing" array
> closing
> issues. In particular cases like
> int[] a;
> scope1 {
> scope2 {
> a[i1] = v1;
> f(a);
> }
> scope3 {
> a[i2] = v2;
> }
> }
> 
> and variations.
> 
> The idea is that:
> - closing does not need to happen in the declaration scope, but can
> happen in the place where a[] is last written to (in the cases where
> "last written to" happens in multiple places, Ben's partial closing
> will
> still apply, but, again, not necessarily in the declaration scope).
> This
> make a lot of cases that would deadlock before work now.
> - the compiler determines either that:
> 1. closing can happen without a deadlock and issues appropriate
> statements to do so
> 2. there is no way to do it without a deadlock, in which case compiler
> issues a clear error message stating so.
> 
> It's not trivial because I need to keep track of both read and write
> access to variables, and also their respective locations within the
> scope tree, as well as how iterations and if conditions may affect
> things. That combined with the general crappiness of the exiting
> compiler code. But with a bit of work, I think it's doable and it will
> go miles towards reducing unexpected and perplexing behavior in
> complex
> scripts.
> 
>... this might be a
> good
> time to finally put this issue to rest.
> 
> As usual there are advantages and disadvantages to including this in
> the
> upcoming release, so...

This is something that we should carefully coordinate between Swift/K and Swift/T.

I dont fully understand this issues and differences, but I think that Swift/T has added some restrictions that make array closing simpler to define and implement.

I would like to see us either agree on carying the new semantics forward into Swift/T, or retrofitting Swift/T semantics to Swift/K, to start easing the eventual transition for users.

Thoughts, all?

- Mike


-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From wozniak at mcs.anl.gov  Wed Nov 21 13:12:35 2012
From: wozniak at mcs.anl.gov (Justin M Wozniak)
Date: Wed, 21 Nov 2012 12:12:35 -0700
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
Message-ID: <50AD27A3.6020102@mcs.anl.gov>

On 11/21/2012 10:47 AM, Michael Wilde wrote:
>> int[] a;
>> scope1 {
>> scope2 {
>> a[i1] = v1;
>> f(a);
>> }
>> scope3 {
>> a[i2] = v2;
>> }
>> }
>>
>> and variations.
>>
>>
>> It's not trivial because I need to keep track of both read and write
>> access to variables, and also their respective locations within the
>> scope tree, as well as how iterations and if conditions may affect
>> things. That combined with the general crappiness of the exiting
>> compiler code. But with a bit of work, I think it's doable and it will
>> go miles towards reducing unexpected and perplexing behavior in
>> complex
>> scripts.
>>
> This is something that we should carefully coordinate between Swift/K and Swift/T.
>
> I dont fully understand this issues and differences, but I think that Swift/T has added some restrictions that make array closing simpler to define and implement.
>
> I would like to see us either agree on carying the new semantics forward into Swift/T, or retrofitting Swift/T semantics to Swift/K, to start easing the eventual transition for users.
>
> Thoughts, all?
>
> - Mike
>

I don't think this is currently an issue in the Swift/T implementation 
but I can check.  In Swift/T, we have the restriction that you cannot 
assign to an array A=f() and also do piecemeal assignments A[i]=g() .  
We do track potential write accesses to arrays to keep them open until 
there are no more possible writes.

http://www.mcs.anl.gov/exm/local/guides/swift.html#_arrays

We are currently working on a feature to provide better reporting in 
user error cases.  For example, if a user tries to read from A[3][2] but 
that is never assigned the error output is not very clear but we are 
working on that- we will have to look back to find the original phrasing 
of the lookup.  (Swift/T sets tmp=A[3], looks up tmp[2], and fails- 
currently we can only say that entry [2] of an anonymous array was not 
found, which is not helpful enough.)

     Justin

-- 
Justin M Wozniak



From wozniak at mcs.anl.gov  Wed Nov 21 13:13:55 2012
From: wozniak at mcs.anl.gov (Justin M Wozniak)
Date: Wed, 21 Nov 2012 12:13:55 -0700
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <50AD27A3.6020102@mcs.anl.gov>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov>
Message-ID: <50AD27F3.8060106@mcs.anl.gov>

On 11/21/2012 12:12 PM, Justin M Wozniak wrote:
>
> We are currently working on a feature to provide better reporting in 
> user error cases.
>

This is being tracked here:

http://code.google.com/p/exm-issues/issues/detail?id=343&sort=-modified&colspec=ID%20Type%20Status%20Release%20Priority%20Owner%20Summary%20Blocking%20Modified

-- 
Justin M Wozniak

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20121121/d697c3c4/attachment.html>

From hategan at mcs.anl.gov  Wed Nov 21 15:51:55 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Wed, 21 Nov 2012 13:51:55 -0800
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <50AD27A3.6020102@mcs.anl.gov>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov>
Message-ID: <1353534715.7538.9.camel@blabla>

On Wed, 2012-11-21 at 12:12 -0700, Justin M Wozniak wrote:

> I don't think this is currently an issue in the Swift/T implementation 
> but I can check.  In Swift/T, we have the restriction that you cannot 
> assign to an array A=f() and also do piecemeal assignments A[i]=g() .  
> We do track potential write accesses to arrays to keep them open until 
> there are no more possible writes.
> 
> http://www.mcs.anl.gov/exm/local/guides/swift.html#_arrays

That restriction should also be in swift/k, and I don't think it is.

There is a problem with the current implementation. It fails to properly
execute the following code:

int[] a;

if (true) {
  if (true) {
    a[0] = 1;
  }
  else {
   a[0] = 2;
  }
  f(a);
}

This is because a is closed in the scope in which it's declared, but
that won't be done until f(a) completes, which it can't because a is not
closed. That needs fixing. An additional complexity is that the
following should also be allowed and function correctly:

int[] a;

if (true) {
  if (condition) {
    a[0] = 1;
  }
  f(a);
}


There's also the issue of:
int[] a;

foreach i in [0:10] {
  a[i] = 1;
  f(a);
}

That shouldn't be allowed. It is, and it leads to a deadlock.

There are some subtleties:

int[] a;
if (true) {
  foreach i in [0:10] {
    if (true) {
      a[i] = 0;
    }
    else {
      a[i] = 1;
    }
  }
  f(a);
}

Closing of a can only happen after the foreach is done.

All these cases need to be correctly handled by the compiler, and I
think none of them are.



From tim.g.armstrong at gmail.com  Wed Nov 21 18:50:56 2012
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Wed, 21 Nov 2012 18:50:56 -0600
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <1353534715.7538.9.camel@blabla>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
Message-ID: <CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>

I had a couple of comments.

I think the difference between Swift/K and Swift/T is mostly implementation
rather than to do with restrictions on semantics - there weren't really any
decisions I made where I was restricting something in order to avoid
potential deadlocks.   (There might be some differences where we're
better/worse at detecting deadlocks at compile time, but that's a separate
issue).

I don't see why this example necessarily deadlocks - it doesn't in Swift/T
since there isn't a true data dependence loop.

foreach i in [0:10] {
  a[i] = 1;
  f(a);
}

In Swift/T it does the same thing as:
foreach i in [0:10] {
  a[i] = 1;
}
foreach i in [0:10] {
  f(a);
}
I understand in Swift/K there is some sort of dependence loop ( scope
exiting <- f(a) executing <- a being closed <- scope exiting).  In Swift/T
the statements a[i] = 1 and f(a) are forked off separately, then the
writers count is decremented after each insertion succeeds.  There isn't an
explicit runtime event corresponding to all statements in a block finishing.

- Tim

On Wed, Nov 21, 2012 at 3:51 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> On Wed, 2012-11-21 at 12:12 -0700, Justin M Wozniak wrote:
>
> > I don't think this is currently an issue in the Swift/T implementation
> > but I can check.  In Swift/T, we have the restriction that you cannot
> > assign to an array A=f() and also do piecemeal assignments A[i]=g() .
> > We do track potential write accesses to arrays to keep them open until
> > there are no more possible writes.
> >
> > http://www.mcs.anl.gov/exm/local/guides/swift.html#_arrays
>
> That restriction should also be in swift/k, and I don't think it is.
>
> There is a problem with the current implementation. It fails to properly
> execute the following code:
>
> int[] a;
>
> if (true) {
>   if (true) {
>     a[0] = 1;
>   }
>   else {
>    a[0] = 2;
>   }
>   f(a);
> }
>
> This is because a is closed in the scope in which it's declared, but
> that won't be done until f(a) completes, which it can't because a is not
> closed. That needs fixing. An additional complexity is that the
> following should also be allowed and function correctly:
>
> int[] a;
>
> if (true) {
>   if (condition) {
>     a[0] = 1;
>   }
>   f(a);
> }
>
>
> There's also the issue of:
> int[] a;
>
> foreach i in [0:10] {
>   a[i] = 1;
>   f(a);
> }
>
> That shouldn't be allowed. It is, and it leads to a deadlock.
>
> There are some subtleties:
>
> int[] a;
> if (true) {
>   foreach i in [0:10] {
>     if (true) {
>       a[i] = 0;
>     }
>     else {
>       a[i] = 1;
>     }
>   }
>   f(a);
> }
>
> Closing of a can only happen after the foreach is done.
>
> All these cases need to be correctly handled by the compiler, and I
> think none of them are.
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20121121/75834964/attachment.html>

From tim.g.armstrong at gmail.com  Wed Nov 21 19:58:03 2012
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Wed, 21 Nov 2012 19:58:03 -0600
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
Message-ID: <CAC0jiV77DHkuSjmpT_dSvNtJ266GbKUQ5KxoYFrSsgpbALQsfg@mail.gmail.com>

Mihael and I had a brief exchange off-list.  I think it sounds that the
situation is that we agree almost entirely on the intended semantics, but
that the implementations differ in how close they are to the ideal
behaviour.  It seems like the main points of difference are:

   - There are differences in whether deadlocks/other errors are detected
   at compile time or run time, and the quality of the error messages/other
   diagnostics.  E.g. both eventually detect runtime deadlocks, but Swift/K
   prints more info about the cycle.  Swift/T I think detects more problems at
   compile time to do with partial/total assignment of arrays.
   - Swift/T's bookkeeping for array closing operates at the level of
   individual statements so can close arrays earlier.  This avoids the Swift/K
   deadlocks where there is a dependency loop involving a scope exit.  This
   means that Swift/K deadlocks in cases where Swift/T wouldn't, but otherwise
   the behaviour is the same.
   - Swift/T currently doesn't start a foreach loop executing until the
   array is closed.  This is a known limitation we intend to fix.  Swift/K has
   already got a fix for this.

- Tim

On Wed, Nov 21, 2012 at 6:50 PM, Tim Armstrong <tim.g.armstrong at gmail.com>wrote:

> I had a couple of comments.
>
> I think the difference between Swift/K and Swift/T is mostly
> implementation rather than to do with restrictions on semantics - there
> weren't really any decisions I made where I was restricting something in
> order to avoid potential deadlocks.   (There might be some differences
> where we're better/worse at detecting deadlocks at compile time, but that's
> a separate issue).
>
> I don't see why this example necessarily deadlocks - it doesn't in Swift/T
> since there isn't a true data dependence loop.
>
>
> foreach i in [0:10] {
>   a[i] = 1;
>   f(a);
> }
>
> In Swift/T it does the same thing as:
>
> foreach i in [0:10] {
>   a[i] = 1;
> }
> foreach i in [0:10] {
>   f(a);
> }
> I understand in Swift/K there is some sort of dependence loop ( scope
> exiting <- f(a) executing <- a being closed <- scope exiting).  In Swift/T
> the statements a[i] = 1 and f(a) are forked off separately, then the
> writers count is decremented after each insertion succeeds.  There isn't an
> explicit runtime event corresponding to all statements in a block finishing.
>
> - Tim
>
>
> On Wed, Nov 21, 2012 at 3:51 PM, Mihael Hategan <hategan at mcs.anl.gov>wrote:
>
>> On Wed, 2012-11-21 at 12:12 -0700, Justin M Wozniak wrote:
>>
>> > I don't think this is currently an issue in the Swift/T implementation
>> > but I can check.  In Swift/T, we have the restriction that you cannot
>> > assign to an array A=f() and also do piecemeal assignments A[i]=g() .
>> > We do track potential write accesses to arrays to keep them open until
>> > there are no more possible writes.
>> >
>> > http://www.mcs.anl.gov/exm/local/guides/swift.html#_arrays
>>
>> That restriction should also be in swift/k, and I don't think it is.
>>
>> There is a problem with the current implementation. It fails to properly
>> execute the following code:
>>
>> int[] a;
>>
>> if (true) {
>>   if (true) {
>>     a[0] = 1;
>>   }
>>   else {
>>    a[0] = 2;
>>   }
>>   f(a);
>> }
>>
>> This is because a is closed in the scope in which it's declared, but
>> that won't be done until f(a) completes, which it can't because a is not
>> closed. That needs fixing. An additional complexity is that the
>> following should also be allowed and function correctly:
>>
>> int[] a;
>>
>> if (true) {
>>   if (condition) {
>>     a[0] = 1;
>>   }
>>   f(a);
>> }
>>
>>
>> There's also the issue of:
>> int[] a;
>>
>> foreach i in [0:10] {
>>   a[i] = 1;
>>   f(a);
>> }
>>
>> That shouldn't be allowed. It is, and it leads to a deadlock.
>>
>> There are some subtleties:
>>
>> int[] a;
>> if (true) {
>>   foreach i in [0:10] {
>>     if (true) {
>>       a[i] = 0;
>>     }
>>     else {
>>       a[i] = 1;
>>     }
>>   }
>>   f(a);
>> }
>>
>> Closing of a can only happen after the foreach is done.
>>
>> All these cases need to be correctly handled by the compiler, and I
>> think none of them are.
>>
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20121121/5c691848/attachment.html>

From hategan at mcs.anl.gov  Wed Nov 21 20:36:04 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Wed, 21 Nov 2012 18:36:04 -0800
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
Message-ID: <1353551764.14127.11.camel@blabla>

On Wed, 2012-11-21 at 18:50 -0600, Tim Armstrong wrote:

> I don't see why this example necessarily deadlocks - it doesn't in
> Swift/T since there isn't a true data dependence loop.
> 
> foreach i in [0:10] {
>   a[i] = 1;
>   f(a);
> }

It shouldn't deadlock. Nothing should. It just does in the current
swift/k implementation.

> 
> In Swift/T it does the same thing as:
> foreach i in [0:10] {
>   a[i] = 1;
> }
> foreach i in [0:10] {
>   f(a);
> }

I don't know if I'd expect that if I wrote that code. Another
possibility is that I want f to be invoked successively with [1], [1,
1], [1, 1, 1], etc. So I don't think it's obvious what that code should
do, and I'd be inclined to have it forbidden. If the required behaviour
is f([10x1]) ten times, then the user can state that explicitly by
writing the equivalent code you mention.

> I understand in Swift/K there is some sort of dependence loop ( scope
> exiting <- f(a) executing <- a being closed <- scope exiting).  In
> Swift/T the statements a[i] = 1 and f(a) are forked off separately,
> then the writers count is decremented after each insertion succeeds.

I'm guessing the total writer count is determined at run-time by
incrementing every time an iteration starts?

Can I steal that? I mean we favored doing this analysis statically in
swift/k, but I don't see why that should necessarily be the case.

>   There isn't an explicit runtime event corresponding to all
> statements in a block finishing.

Right. But if there was, it would be equivalent to the event of all
writes to a[] having been completed, at least in the case above. Here's
where it wouldn't:

foreach i in [0:10] {
   a[i] = 1;
   f(a[i]);
}

Which is why dynamic tracking would be better.

Mihael



From hategan at mcs.anl.gov  Wed Nov 21 23:32:58 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Wed, 21 Nov 2012 21:32:58 -0800
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <1353551764.14127.11.camel@blabla>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
	<1353551764.14127.11.camel@blabla>
Message-ID: <1353562378.21180.2.camel@blabla>

On Wed, 2012-11-21 at 18:36 -0800, Mihael Hategan wrote:
[...]
> > 
> > foreach i in [0:10] {
> >   a[i] = 1;
> >   f(a);
> > }
> 
> It shouldn't deadlock. Nothing should. It just does in the current
> swift/k implementation.
> 
> > 
> > In Swift/T it does the same thing as:
> > foreach i in [0:10] {
> >   a[i] = 1;
> > }
> > foreach i in [0:10] {
> >   f(a);
> > }
> 
> I don't know if I'd expect that if I wrote that code. Another
> possibility is that I want f to be invoked successively with [1], [1,
> 1], [1, 1, 1], etc. So I don't think it's obvious what that code should
> do, and I'd be inclined to have it forbidden. If the required behaviour
> is f([10x1]) ten times, then the user can state that explicitly by
> writing the equivalent code you mention.

I would like to revise my statement. I agree with your proposed solution
from a dataflow perspective (which I lost there for a bit). When
invoking f(a) you are saying run f with some array as argument and the
issue of where that array is built is not relevant.

Mihael



From tim.g.armstrong at gmail.com  Thu Nov 22 10:37:42 2012
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Thu, 22 Nov 2012 10:37:42 -0600
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <1353562378.21180.2.camel@blabla>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
	<1353551764.14127.11.camel@blabla>
	<1353562378.21180.2.camel@blabla>
Message-ID: <CAC0jiV6yfDghp-_cMz-Df1GOWtUaQAKFBQQycJ1T9jscHnWRdw@mail.gmail.com>

It sounds like Mihael and I agree, but maybe I should explain the reasoning
for others' benefit.  I think that this example is one where the serial
imperative interpretation vs. dataflow interpretation actually are
completely different so people probably have different intuitions about
what it should do.  I think this has been a source of confusion since users
of Swift frequently understand their scripts by tracing the execution step
by step as you would an imperative language, which actually works 90% of
the time.

The functional/dataflow interpretation rests on the idea that A refers to a
single value, the complete contents of the array after closing.  So f(A)
always means f applied to the final value of A.

There are a couple of reasons that Swift/T goes with dataflow
interpretation over the serial interpretation:

   - It makes guaranteeing determinism much simpler
   - It means that there are no problems with executing the iterations of
   the loop in parallel independently (this is especially important for
   Swift/T)

I guess this is a bit confusing for some users but I think that the
behaviour is reasonable and consistent.  I'm not sure if there a way to
help users with potentially counter-intuitive behaviour, like a compiler
warning - aside from maybe documenting and explaining it better.

- Tim

On Wed, Nov 21, 2012 at 11:32 PM, Mihael Hategan <hategan at mcs.anl.gov>wrote:

> On Wed, 2012-11-21 at 18:36 -0800, Mihael Hategan wrote:
> [...]
> > >
> > > foreach i in [0:10] {
> > >   a[i] = 1;
> > >   f(a);
> > > }
> >
> > It shouldn't deadlock. Nothing should. It just does in the current
> > swift/k implementation.
> >
> > >
> > > In Swift/T it does the same thing as:
> > > foreach i in [0:10] {
> > >   a[i] = 1;
> > > }
> > > foreach i in [0:10] {
> > >   f(a);
> > > }
> >
> > I don't know if I'd expect that if I wrote that code. Another
> > possibility is that I want f to be invoked successively with [1], [1,
> > 1], [1, 1, 1], etc. So I don't think it's obvious what that code should
> > do, and I'd be inclined to have it forbidden. If the required behaviour
> > is f([10x1]) ten times, then the user can state that explicitly by
> > writing the equivalent code you mention.
>
> I would like to revise my statement. I agree with your proposed solution
> from a dataflow perspective (which I lost there for a bit). When
> invoking f(a) you are saying run f with some array as argument and the
> issue of where that array is built is not relevant.
>
> Mihael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20121122/9fc6bb07/attachment.html>

From tim.g.armstrong at gmail.com  Thu Nov 22 10:44:16 2012
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Thu, 22 Nov 2012 10:44:16 -0600
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <1353551764.14127.11.camel@blabla>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
	<1353551764.14127.11.camel@blabla>
Message-ID: <CAC0jiV4MNnnJQG07oc_=-oBYS3XsXn-Z7VXVWUSH0XFbkev-Vw@mail.gmail.com>

On Wed, Nov 21, 2012 at 8:36 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> On Wed, 2012-11-21 at 18:50 -0600, Tim Armstrong wrote:
>
> > I don't see why this example necessarily deadlocks - it doesn't in
> > Swift/T since there isn't a true data dependence loop.
> >
> > foreach i in [0:10] {
> >   a[i] = 1;
> >   f(a);
> > }
>
> It shouldn't deadlock. Nothing should. It just does in the current
> swift/k implementation.
>
> >
> > In Swift/T it does the same thing as:
> > foreach i in [0:10] {
> >   a[i] = 1;
> > }
> > foreach i in [0:10] {
> >   f(a);
> > }
>
> I don't know if I'd expect that if I wrote that code. Another
> possibility is that I want f to be invoked successively with [1], [1,
> 1], [1, 1, 1], etc. So I don't think it's obvious what that code should
> do, and I'd be inclined to have it forbidden. If the required behaviour
> is f([10x1]) ten times, then the user can state that explicitly by
> writing the equivalent code you mention.
>
> > I understand in Swift/K there is some sort of dependence loop ( scope
> > exiting <- f(a) executing <- a being closed <- scope exiting).  In
> > Swift/T the statements a[i] = 1 and f(a) are forked off separately,
> > then the writers count is decremented after each insertion succeeds.
>
> I'm guessing the total writer count is determined at run-time by
> incrementing every time an iteration starts?
>
> Can I steal that? I mean we favored doing this analysis statically in
> swift/k, but I don't see why that should necessarily be the case.
>

Of course.

Currently we do the dumb thing of incrementing once per loop iteration, but
I'm going to make a change soon where, if we know how many loop iterations
there are at the time the loop is started, we'll just increment the count
by that amount at the start and decrement as each iteration finishes (or
actually, since we chunk loops up and distribute them, as each chunk of the
loop finishes).  This works well enough.


>
> >   There isn't an explicit runtime event corresponding to all
> > statements in a block finishing.
>
> Right. But if there was, it would be equivalent to the event of all
> writes to a[] having been completed, at least in the case above. Here's
> where it wouldn't:
>
> foreach i in [0:10] {
>    a[i] = 1;
>    f(a[i]);
> }
>
> Which is why dynamic tracking would be better.
>
> Mihael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20121122/d7c09ea3/attachment.html>

From wozniak at mcs.anl.gov  Thu Nov 22 12:02:19 2012
From: wozniak at mcs.anl.gov (Justin M Wozniak)
Date: Thu, 22 Nov 2012 11:02:19 -0700
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <CAC0jiV4MNnnJQG07oc_=-oBYS3XsXn-Z7VXVWUSH0XFbkev-Vw@mail.gmail.com>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
	<1353551764.14127.11.camel@blabla>
	<CAC0jiV4MNnnJQG07oc_=-oBYS3XsXn-Z7VXVWUSH0XFbkev-Vw@mail.gmail.com>
Message-ID: <50AE68AB.7050209@mcs.anl.gov>

On 11/22/2012 09:44 AM, Tim Armstrong wrote:
>
> Currently we do the dumb thing of incrementing once per loop 
> iteration, but I'm going to make a change soon where, if we know how 
> many loop iterations there are at the time the loop is started, we'll 
> just increment the count by that amount at the start and decrement as 
> each iteration finishes (or actually, since we chunk loops up and 
> distribute them, as each chunk of the loop finishes).  This works well 
> enough.

Just for clarity:  In general, we support conditional insertion: if (c > 
0) { A[i] = c; }.  The conditional code block executes some time in the 
future when the condition is set (possibly somewhere else). We handle 
this by allocating array "slots" before entering subordinate code and 
dropping slots in all cases in the subordinate code.  When the array 
runs out of slots, it closes itself.

We plan to update this in Swift/T 0.2.0 with a framework that will allow 
for reader and writer reference counts- this will enable garbage 
collection when there are no possible read operations.

-- 
Justin M Wozniak



From benc at hawaga.org.uk  Thu Nov 22 11:49:15 2012
From: benc at hawaga.org.uk (Ben Clifford)
Date: Thu, 22 Nov 2012 17:49:15 +0000 (UTC)
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <CAC0jiV6yfDghp-_cMz-Df1GOWtUaQAKFBQQycJ1T9jscHnWRdw@mail.gmail.com>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
	<1353551764.14127.11.camel@blabla>
	<1353562378.21180.2.camel@blabla>
	<CAC0jiV6yfDghp-_cMz-Df1GOWtUaQAKFBQQycJ1T9jscHnWRdw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1211221742090.21846@dildano.hawaga.org.uk>


On Thu, 22 Nov 2012, Tim Armstrong wrote:

> I'm not sure if there a way to help users with potentially counter-intuitive behaviour, like a compiler
> warning - aside from maybe documenting and explaining it better.

My opinion (still) is that getting rid of piecewise assignment is the 
thing to do.

The notation is initially appealing because you can say to users "yeah, 
its just like in fortran/c/java".

But then you start loading on all this stuff about "oh mind you don't do 
this"; and on the implementation side you have to implement stuff to 
detect when these rules are broken; and its bandaid after bandaid, year 
after year.

I think that syntax is always going to allow you to write something 
surprising - get rid of it!

People pay me money to write haskell for them now, so I'm even more 
opinionated about it than before. In doing so I've also come to realise 
that using [] for reading is probably fine; its really the piecewise 
construction in this fashion that is the problem.

ps aren't you all meant to be eating turkey?

-- 



From tim.g.armstrong at gmail.com  Thu Nov 22 12:31:13 2012
From: tim.g.armstrong at gmail.com (Tim Armstrong)
Date: Thu, 22 Nov 2012 12:31:13 -0600
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <alpine.DEB.2.00.1211221742090.21846@dildano.hawaga.org.uk>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
	<1353551764.14127.11.camel@blabla>
	<1353562378.21180.2.camel@blabla>
	<CAC0jiV6yfDghp-_cMz-Df1GOWtUaQAKFBQQycJ1T9jscHnWRdw@mail.gmail.com>
	<alpine.DEB.2.00.1211221742090.21846@dildano.hawaga.org.uk>
Message-ID: <CAC0jiV6imOxixQf-Emq26Nna5p4Q2szTjpPnfnAGq-h1+4ZH3w@mail.gmail.com>

It'd be interesting to think about what Swift would look like if we did all
arrays construction with list comprehensions - could be an interesting
experiment.

Yes, I'm about to sign off and go eat massive amounts of food.  Happy
turkey day everyone.

On Thu, Nov 22, 2012 at 11:49 AM, Ben Clifford <benc at hawaga.org.uk> wrote:

>
> On Thu, 22 Nov 2012, Tim Armstrong wrote:
>
> > I'm not sure if there a way to help users with potentially
> counter-intuitive behaviour, like a compiler
> > warning - aside from maybe documenting and explaining it better.
>
> My opinion (still) is that getting rid of piecewise assignment is the
> thing to do.
>
> The notation is initially appealing because you can say to users "yeah,
> its just like in fortran/c/java".
>
> But then you start loading on all this stuff about "oh mind you don't do
> this"; and on the implementation side you have to implement stuff to
> detect when these rules are broken; and its bandaid after bandaid, year
> after year.
>
> I think that syntax is always going to allow you to write something
> surprising - get rid of it!
>
> People pay me money to write haskell for them now, so I'm even more
> opinionated about it than before. In doing so I've also come to realise
> that using [] for reading is probably fine; its really the piecewise
> construction in this fashion that is the problem.
>
> ps aren't you all meant to be eating turkey?
>
> --
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20121122/2c417e8b/attachment.html>

From hategan at mcs.anl.gov  Thu Nov 22 13:30:00 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Thu, 22 Nov 2012 11:30:00 -0800
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <CAC0jiV4MNnnJQG07oc_=-oBYS3XsXn-Z7VXVWUSH0XFbkev-Vw@mail.gmail.com>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
	<1353551764.14127.11.camel@blabla>
	<CAC0jiV4MNnnJQG07oc_=-oBYS3XsXn-Z7VXVWUSH0XFbkev-Vw@mail.gmail.com>
Message-ID: <1353612600.1287.4.camel@blabla>

On Thu, 2012-11-22 at 10:44 -0600, Tim Armstrong wrote:

>         I'm guessing the total writer count is determined at run-time
>         by
>         incrementing every time an iteration starts?
>         
>         Can I steal that? I mean we favored doing this analysis
>         statically in
>         swift/k, but I don't see why that should necessarily be the
>         case.
> 
> Of course.  
> 
> Currently we do the dumb thing of incrementing once per loop
> iteration, but I'm going to make a change soon where, if we know how
> many loop iterations there are at the time the loop is started, we'll
> just increment the count by that amount at the start and decrement as
> each iteration finishes (or actually, since we chunk loops up and
> distribute them, as each chunk of the loop finishes).  This works well
> enough.  

I'm also guessing you start with a non-zero count if you have a loop.
Otherwise, if all other statements that write to an array finish before
you start the loop, the array will incorrectly be considered closed.

Mihael



From hategan at mcs.anl.gov  Thu Nov 22 13:37:06 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Thu, 22 Nov 2012 11:37:06 -0800
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <50AE68AB.7050209@mcs.anl.gov>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
	<1353551764.14127.11.camel@blabla>
	<CAC0jiV4MNnnJQG07oc_=-oBYS3XsXn-Z7VXVWUSH0XFbkev-Vw@mail.gmail.com>
	<50AE68AB.7050209@mcs.anl.gov>
Message-ID: <1353613026.1287.10.camel@blabla>

On Thu, 2012-11-22 at 11:02 -0700, Justin M Wozniak wrote:
> On 11/22/2012 09:44 AM, Tim Armstrong wrote:
> >
> > Currently we do the dumb thing of incrementing once per loop 
> > iteration, but I'm going to make a change soon where, if we know how 
> > many loop iterations there are at the time the loop is started, we'll 
> > just increment the count by that amount at the start and decrement as 
> > each iteration finishes (or actually, since we chunk loops up and 
> > distribute them, as each chunk of the loop finishes).  This works well 
> > enough.
> 
> Just for clarity:  In general, we support conditional insertion: if (c > 
> 0) { A[i] = c; }.  The conditional code block executes some time in the 
> future when the condition is set (possibly somewhere else). We handle 
> this by allocating array "slots" before entering subordinate code and 
> dropping slots in all cases in the subordinate code.  When the array 
> runs out of slots, it closes itself.

I'm sticking that in using basic reference counting. Both branches of a
condition must have the same (writing) reference count, and if not, the
compiler inserts partial close statements to make them match. That's in
order to support things like:

if (c) {
  a[0]  = 1;
  a[1] = 1;
}
else {
  a[0] = 1;
}



From hategan at mcs.anl.gov  Thu Nov 22 13:47:24 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Thu, 22 Nov 2012 11:47:24 -0800
Subject: [Swift-devel] Changes to array closing semantics?
In-Reply-To: <alpine.DEB.2.00.1211221742090.21846@dildano.hawaga.org.uk>
References: <327933408.49206.1353520063624.JavaMail.root@zimbra.anl.gov>
	<50AD27A3.6020102@mcs.anl.gov> <1353534715.7538.9.camel@blabla>
	<CAC0jiV5PmiCzqnuy0MryqtdkEFA9NYquS=CR1YyaMBqME4KzhQ@mail.gmail.com>
	<1353551764.14127.11.camel@blabla> <1353562378.21180.2.camel@blabla>
	<CAC0jiV6yfDghp-_cMz-Df1GOWtUaQAKFBQQycJ1T9jscHnWRdw@mail.gmail.com>
	<alpine.DEB.2.00.1211221742090.21846@dildano.hawaga.org.uk>
Message-ID: <1353613644.1287.20.camel@blabla>

On Thu, 2012-11-22 at 17:49 +0000, Ben Clifford wrote:
> On Thu, 22 Nov 2012, Tim Armstrong wrote:
> 
> > I'm not sure if there a way to help users with potentially counter-intuitive behaviour, like a compiler
> > warning - aside from maybe documenting and explaining it better.
> 
> My opinion (still) is that getting rid of piecewise assignment is the 
> thing to do.
> 

I agree in principle, and I did so before in principle given that it
works that way in karajan: the main way of building lists is using
comprehensions.

But that makes it look very different from swift. The deep return values
is not something that I could see going into swift easily, because swift
isn't a "function-is-data" type of a language. I mean

header() {
  1, 2, 3
}

a = [
  header()
  for (i, range(10, 20)) {
    2 * i
  }
]

looks fundamentally different from everything swift, and something like
this would require serious changes to it I think. Maybe. Or maybe the
cost is lower in the long run.



From hategan at mcs.anl.gov  Fri Nov 23 03:25:39 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Fri, 23 Nov 2012 01:25:39 -0800
Subject: [Swift-devel] new variable closing code
Message-ID: <1353662739.5633.7.camel@blabla>

I committed code to deal with a lot of the nasty little problems related
to array closing.

The compiler now keeps better track of what variables are written and
read and where. It produces more detailed compilation errors, with
pointers to the swift source.

Closing can now happen in the scope that last writes to an array rather
than in the declaration scope. Each handle now has a write reference
count instead of the previous close ids. The reference count is set
initially when a variable is created, decreased when a partial close
occurs, and increased when an iteration that writes to that variable
stars.

Long story short, good stuff!

language/working/q7.swift fails. I think it should.

Now for some turkey. What do you mean all stores are closed? Hmm...



From marialemos72 at gmail.com  Sun Nov 25 18:19:52 2012
From: marialemos72 at gmail.com (WorldCIST)
Date: Mon, 26 Nov 2012 00:19:52 +0000
Subject: [Swift-devel] WorldCIST'13: Indexed by ISI, SCOPUS, DBLP, EI,
 etc. - Extended deadline: December 7
Message-ID: <20121126001908.5AECC7CC091@mailrelay.anl.gov>

Apologies if you are receiving this mail more than once...

Please disseminate by colleagues, researchers, students, etc. Thanks a lot!


**********************************************************************************
                             WorldCIST'13
The 2013 World Conference on Information Systems and Technologies
                   March 27 - 30, Algarve, Portugal
                   http://www.aisti.eu/worldcist13/
**********************************************************************************

SCOPE

The 2013 World Conference on Information Systems and Technologies (WorldCIST'13: http://www.aisti.eu/worldcist13/) is a global forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Information Systems and Technologies.

We are pleased to invite you to submit your papers to WorldCISTI'13. All submissions will be reviewed on the basis of relevance, originality, importance and clarity.


THEMES

Submitted papers should be related with one or more of the main themes proposed for the Conference:

A) Information and Knowledge Management (IKM);

B) Organizational Models and Information Systems (OMIS);

C) Intelligent and Decision Support Systems (IDSS);

D) Software Systems, Architectures, Applications and Tools (SSAAT);

E) Computer Networks, Mobility and Pervasive Systems (CNMPS);

F) Radar Technologies (RAT);

G) Human-Computer Interaction (HCI).


TYPES OF SUBMISSIONS AND DECISIONS

Four types of papers can be submitted:

Full paper: Finished or consolidated R&D works, to be included in one of the Conference themes. These papers are assigned a 10-page limit.

Short paper: Ongoing works with relevant preliminary results, open to discussion. These papers are assigned a 7-page limit.

Poster paper: Initial work with relevant ideas, open to discussion. These papers are assigned to a 4-page limit.

Company paper: Companies' papers that show practical experience, R & D, tools, etc., focused on some topics of the conference. These papers are assigned to a 4-page limit.

Submitted papers must comply with the format of Advances in Intelligent Systems and Computing Series (see http://www.aisti.eu/worldcist13/springerformat.doc) be written in English, must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors? identification. Therefore, the authors? names, affiliations and bibliographic references should not be included in the version for evaluation by the Program Committee. This information should only be included in the camera-ready version.

All papers will be subjected to a ?double-blind review? by at least two members of the Program Committee.

Based on Program Committee evaluation, a paper can be rejected or accepted by the Conference Chairs. In the later case, it can be accepted as the type originally submitted or as another type. Thus, full papers can be accepted as short papers or poster papers only. Similarly, short papers can be accepted as poster papers only. In these cases, the authors will be allowed to maintain the original number of pages in the camera-ready version.

The authors of accepted poster papers must also build and print a poster to be exhibited during the Conference. This poster must follow an A1 or A2 vertical format. The Conference includes Work Sessions where these posters are presented and orally discussed, with a 5 minute limit per poster.

The authors of accepted full papers will have 15 minutes to present their work in a Conference Work Session; approximately 5 minutes of discussion will follow each presentation. The authors of accepted short papers and company papers will have 11 minutes to present their work in a Conference Work Session; approximately 4 minutes of discussion will follow each presentation.

PUBLICATION AND INDEXING

To ensure that a full paper, short paper, poster paper or company paper is published in the Proceedings, at least one of the authors must be fully registered by the 11th of January 2013, and the paper must comply with the suggested layout and page-limit. Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.

No more than one paper per registration will be published in the Conference Proceedings. An extra fee must be paid for publication of additional papers, with a maximum of two additional papers per registration.

Full and short papers will be published in Proceedings by Springer, in Advances in Intelligent Systems and Computing Series. Poster and company papers will be published in Proceedings by AISTI.

Published full and short papers will be indexed by ISI, EI-Compendex, SCOPUS, DBLP and EBSCO, among others, and will be available in the SpringerLink Digital Library. Published poster and company papers will be indexed in EI-Compendex and EBSCO.

The authors of the best selected papers will be invited to extend them for publication in edited books and in international journals indexed by ISI/JCR, SCOPUS and/or DBLP, among others, such as:

- ACM Transactions on Modeling and Computer Simulation (TOMACS)
- Online Information Review (OIR)
- Informatics for Health and Social Care (IHSC)
- Computer Science and Information Systems (ComSIS)
- Telecommunication Systems Journal (TSJ)
- INFORMATION - An International Interdisciplinary Journal
- Journal of Organizational and End User Computing (JOEUC)
- Information Researh (IR)
- International Journal of Internet Protocol Technology (IJIPT)
- Studies in Computational Intelligence (SCI)
- Journal of Advanced Computational Intelligence and Intelligent Informatics (JACIII)
- Journal of Electrical and Computer Engineering (JECE): Special Issue in Advances in Radar Technology
- WSEAS Transactions on Systems (TS)
- Library Review (LR)
- Education for Information (EI)
- International Journal of IT/Business Alignment and Governance (IJITBAG)
- International Journal of Systems and Service-Oriented Engineering (IJSSOE)
- International Journal of Interactive Multimedia and Artificial Intelligence (IJIMAI)


IMPORTANT DATES

Paper Submission: December 7, 2012

Notification of Acceptance: December 30, 2012

Camera-ready Submission: January 9, 2013

Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: January 11, 2013.

-

Kind regards,

Maria Lemos
WorldCIST'13
http://www.aisti.eu/worldcist13/





From wilde at mcs.anl.gov  Mon Nov 26 10:20:22 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Mon, 26 Nov 2012 10:20:22 -0600 (CST)
Subject: [Swift-devel] Including app resource utilization in the info file
In-Reply-To: <751402963.53844.1353946394381.JavaMail.root@zimbra.anl.gov>
Message-ID: <1337667061.53868.1353946822411.JavaMail.root@zimbra.anl.gov>


Hi Luiz, All,

I'd like to incorporate the mod Luiz made in the provenance prototype to capture app() resource utilization. This is in svn at:

https://svn.ci.uchicago.edu/svn/vdl2/provenancedb/swift_mod/_swiftwrap_runtime_aggregate

Im testing a version of this on midway that unconditionally runs every app invocation under /usr/bin/time (if it exists), and captures all of the resource data in an info log line in a single string of the form:

APP_RESOURCES=maxrss:1837872,walltime:1027.64,systime:62.77,usertime:3217.07,cpu:319%,fsin:0,fsout:116232,timesswapped:0,socketrecv:0,socketsent:0,majorpagefaults:21,minorpagefaults:4232202,contextswitchesinv:4624,contextswitchesvol:78762

Luiz also has code which periodically samples the app invocation's resource utilization to build a profile of its behavior over time. I'd like to integrate that as an option at a later date (and make the style of resource capture selectable: aggregate on/off; polled on/off).

Luiz: note that I changed the name; I also changed the implementation so that the above line is captured in a file in the job dir called swift.resources instead of appended to the stderr file. (This way its less intrusive to the app).

I'd like to make a few changes to the format to closely track the names and order of the resource counters that are listed in the Linux man page.

Can we do this in a way that keeps the prototype provenance code in sync and functional with this change?

Also, on Midway, at the moment /usr/bin/time doesnt exist. If thats the case then _swiftwrap tries to see if there is a $HOME/swift.time command and runs that instead. I was able to just copy a /usr/bin/time executable from another similar Linux system, and it worked.

- Mike

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From lgadelha at lncc.br  Tue Nov 27 09:47:18 2012
From: lgadelha at lncc.br (Luiz Gadelha)
Date: Tue, 27 Nov 2012 13:47:18 -0200
Subject: [Swift-devel] Including app resource utilization in the info
	file
In-Reply-To: <1337667061.53868.1353946822411.JavaMail.root@zimbra.anl.gov>
References: <1337667061.53868.1353946822411.JavaMail.root@zimbra.anl.gov>
Message-ID: <8A356B0E-BDA5-402B-9036-9E48682DED37@lncc.br>

Hi Mike,

Can you commit _swiftwrap_runtime_aggregate when you finish changing it? I will make minor adjustments to the provenance extraction scripts to match the format you're using.

Regards,

Luiz

On Nov 26, 2012, at 2:20 PM, Michael Wilde wrote:

> 
> Hi Luiz, All,
> 
> I'd like to incorporate the mod Luiz made in the provenance prototype to capture app() resource utilization. This is in svn at:
> 
> https://svn.ci.uchicago.edu/svn/vdl2/provenancedb/swift_mod/_swiftwrap_runtime_aggregate
> 
> Im testing a version of this on midway that unconditionally runs every app invocation under /usr/bin/time (if it exists), and captures all of the resource data in an info log line in a single string of the form:
> 
> APP_RESOURCES=maxrss:1837872,walltime:1027.64,systime:62.77,usertime:3217.07,cpu:319%,fsin:0,fsout:116232,timesswapped:0,socketrecv:0,socketsent:0,majorpagefaults:21,minorpagefaults:4232202,contextswitchesinv:4624,contextswitchesvol:78762
> 
> Luiz also has code which periodically samples the app invocation's resource utilization to build a profile of its behavior over time. I'd like to integrate that as an option at a later date (and make the style of resource capture selectable: aggregate on/off; polled on/off).
> 
> Luiz: note that I changed the name; I also changed the implementation so that the above line is captured in a file in the job dir called swift.resources instead of appended to the stderr file. (This way its less intrusive to the app).
> 
> I'd like to make a few changes to the format to closely track the names and order of the resource counters that are listed in the Linux man page.
> 
> Can we do this in a way that keeps the prototype provenance code in sync and functional with this change?
> 
> Also, on Midway, at the moment /usr/bin/time doesnt exist. If thats the case then _swiftwrap tries to see if there is a $HOME/swift.time command and runs that instead. I was able to just copy a /usr/bin/time executable from another similar Linux system, and it worked.
> 
> - Mike
> 
> -- 
> Michael Wilde
> Computation Institute, University of Chicago
> Mathematics and Computer Science Division
> Argonne National Laboratory
> 

--
Luiz Gadelha
http://www.lncc.br/~lgadelha





From wilde at mcs.anl.gov  Thu Nov 29 11:54:33 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Thu, 29 Nov 2012 11:54:33 -0600 (CST)
Subject: [Swift-devel] Improvements to Swift tutorial
In-Reply-To: <97B8C98AF6CD2146ADC0FEB4066CD50602AB6148@xm-mbx-04-prod.ad.uchicago.edu>
Message-ID: <834064816.61260.1354211673350.JavaMail.root@zimbra.anl.gov>

Justin, David,

Below are good comments from Robin Weiss on the tutorial. If you have further suggestions for improvements, can you provide them on this thread?

Ones that I recall from user questions:

- explain semantics and flexibility of arrays in more detail: (dynamic, N-dimension, sparse, string-indexable)

- explain up front that Swift is locally developed.

And one that occurred to me:

- show that/how Swift can achieve high parallelism (in the example runs... We didnt go beyond 25 parallel jobs per run).

Thanks,

- Mike


On the slide where you show an example app function (if I recall, it was
some sort of chemistry thing) there were a couple of typos ("temp" should
have been "t", etc?).  It also may be good to make it a little more clear
that what swift does is make system calls to something on the command
line.  I.e., show some dummy command how it looks on the command line like
"./myScript -param1 val1 -param2 val2" and then show that the app function
does something like "runMyScript -param1" variable1 "-param2" variable2.

Also, in the example where you have the fMRI data, the usage of the word
"Run" was a little misleading.  I realize that a "Run" is a data object,
but "run" is also a verb so it could me misconstrued that "Run" is telling
swift to "Run" something.  See what I mean?

Finally, in the tutorial section, I think it would be good to actually
work through some example workflow to make the ideas of swift more
concrete.  There are good examples in the online documentation/tutorial
that I found really helpful when I was learning swift.  For example, do
something where you have a bunch of dummy input decks, they get mapped,
passed in parallel to some app function that outputs intermediate "data"
files, and then aggregate all of the results in some sort of dummy
"analyze" app function.

Anyway, just some thoughts?

Robin

-- 
Robin M. Weiss
Research Programmer
Research Computing Center
The University of Chicago
6030 S. Ellis Ave., Suite 289C
Chicago, IL 60637
robinweiss at uchicago.edu <mailto:labello at uchicago.edu>
773.702.9030






On 11/27/12 11:07 PM, "Michael Wilde" <wilde at mcs.anl.gov> wrote:

>Hi Robin, Nick,
>
>Thanks very much for you help in setting up and running the tutorial.
>
>Can we get an email list of attendees, and follow up with pointers to
>slides and material?
>
>We'll need to update the runswift script to remove the reservation
>linkage, which causes jobs to fail if the user is not part of the
>reservation.
>
>Lets think about scheduling another tutorial in January if RCC is
>interested; we certainly are!
>
>Thanks and regards,
>
>- Mike
>
>
>-- 
>Michael Wilde
>Computation Institute, University of Chicago
>Mathematics and Computer Science Division
>Argonne National Laboratory
>


-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From wilde at mcs.anl.gov  Thu Nov 29 12:09:08 2012
From: wilde at mcs.anl.gov (Michael Wilde)
Date: Thu, 29 Nov 2012 12:09:08 -0600 (CST)
Subject: [Swift-devel] 0.94 Blocker -- [Bug 883] DSSAT problem: Trying to
 bind invalid channel to MetaChannel
In-Reply-To: <20121128202150.CA12C5642C@wind.mcs.anl.gov>
Message-ID: <2114539330.61310.1354212548777.JavaMail.root@zimbra.anl.gov>

Hi Mihael,

Did you have a chance to look at this one yet? I just marked it as a blocker to 0.94 (which we hope to install on 3 local systems next week).

Can you move it to the top of your list and let us know when you can get to it, and what further details you need from David if any?

David suspects that he's seen another "hang" in an 0.94 test but is trying to reproduce it.

The 3 top-prio clusters for testing/install are midway, UC3, and Beagle.

The top 2 apps he's testing are DSSAT and (soon) the NCAR/ParVis climate model diagnostic scripts.

Thanks,

- Mike

----- Forwarded Message -----
From: bugzilla-daemon at mcs.anl.gov
To: swift-bugs at ci.uchicago.edu
Sent: Wednesday, November 28, 2012 2:21:50 PM
Subject: [swift-bugs] [Bug 883] DSSAT problem: Trying to bind invalid channel to MetaChannel

https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=883


David Kelly <davidk at ci.uchicago.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Severity|normal                      |major




-- 
Configure bugmail: https://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
swift-bugs mailing list
swift-bugs at ci.uchicago.edu
https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-bugs

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory



From hategan at mcs.anl.gov  Thu Nov 29 14:01:29 2012
From: hategan at mcs.anl.gov (Mihael Hategan)
Date: Thu, 29 Nov 2012 12:01:29 -0800
Subject: [Swift-devel] 0.94 Blocker -- [Bug 883] DSSAT problem: Trying
 to bind invalid channel to MetaChannel
In-Reply-To: <2114539330.61310.1354212548777.JavaMail.root@zimbra.anl.gov>
References: <2114539330.61310.1354212548777.JavaMail.root@zimbra.anl.gov>
Message-ID: <1354219289.31952.0.camel@blabla>

Sorry. Didn't get to it yet. I'll look either tonight, or, more likely,
tomorrow.

Mihael

On Thu, 2012-11-29 at 12:09 -0600, Michael Wilde wrote:
> Hi Mihael,
> 
> Did you have a chance to look at this one yet? I just marked it as a blocker to 0.94 (which we hope to install on 3 local systems next week).
> 
> Can you move it to the top of your list and let us know when you can get to it, and what further details you need from David if any?
> 
> David suspects that he's seen another "hang" in an 0.94 test but is trying to reproduce it.
> 
> The 3 top-prio clusters for testing/install are midway, UC3, and Beagle.
> 
> The top 2 apps he's testing are DSSAT and (soon) the NCAR/ParVis climate model diagnostic scripts.
> 
> Thanks,
> 
> - Mike
> 
> ----- Forwarded Message -----
> From: bugzilla-daemon at mcs.anl.gov
> To: swift-bugs at ci.uchicago.edu
> Sent: Wednesday, November 28, 2012 2:21:50 PM
> Subject: [swift-bugs] [Bug 883] DSSAT problem: Trying to bind invalid channel to MetaChannel
> 
> https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=883
> 
> 
> David Kelly <davidk at ci.uchicago.edu> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |ASSIGNED
>            Severity|normal                      |major
> 
> 
> 
> 
> -- 
> Configure bugmail: https://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are watching all bug changes.
> _______________________________________________
> swift-bugs mailing list
> swift-bugs at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-bugs
> 




From hockyg at uchicago.edu  Fri Nov 30 15:12:30 2012
From: hockyg at uchicago.edu (Glen Hocky)
Date: Fri, 30 Nov 2012 16:12:30 -0500
Subject: [Swift-devel] "solution" to coasters + condor problem (on uc3)
Message-ID: <CAGMfak=samKkm6p+NVY_Gkho_GZ1oEZak_4enKKne-XTpNQkZQ@mail.gmail.com>

Hey everyone,
This is in reference to a problem I just sent to swift-support earlier.

In order to get coasters to work on a condor system without a shared file
system, I suggested putting worker.pl as an input file to condor which is
then transferred.

The problem is that this needs to be translated through from the coasters
provider or via some environmental inputs that I don't know how to do

However, here is a hacked proof of concept that "solves" the problem in a
way specific to me.
What it does is rather than write the randomly generated cscript*.pl file
in the "arguments" string, the condor provider now skips that argument and
throws in the hard coded path to worker.pl

It would be nice for someone who actually knows what they're doing to make
a general version of this fix

Best
Glen

------------------------

 Index:
provider-localscheduler/src/org/globus/cog/abstraction/impl/scheduler/condor/CondorExecutor.java
===================================================================
---
provider-localscheduler/src/org/globus/cog/abstraction/impl/scheduler/condor/CondorExecutor.java
   (revision 3524)
+++
provider-localscheduler/src/org/globus/cog/abstraction/impl/scheduler/condor/CondorExecutor.java
   (working copy)
@@ -53,6 +53,16 @@
                if ("MPI".equals(type)) {
                        wr.write("universe = MPI\n");
                }
+               else if ("parallel".equals(type)) {
+                       wr.write("universe = parallel\n");
+               }
+                else if ("local-cloud".equals(type)){
+                       wr.write("universe = vanilla\n");
+                       wr.write("should_transfer_files = YES\n");
+                       wr.write("when_to_transfer_output =
ON_EXIT_OR_EVICT\n");
+                       wr.write("Transfer_Executable = true\n");
+                        wr.write("transfer_input_files =
/mnt/hadoop/hockyg/swiftwork/worker.pl\n");
+                }
                else if("grid".equals(type)) {
                        grid = true;
                        String gridResource = (String)
spec.getAttribute("gridResource");
@@ -69,10 +79,15 @@
                else {
                        wr.write("universe = vanilla\n");
                }
+
+                //set account group if specified
+               writeAttr("AccountingGroup", "+AccountingGroup = ", wr);
+
                if ("true".equals(spec.getAttribute("holdIsFailure"))) {
                        wr.write("periodic_remove = JobStatus == 5\n");
                }
                writeAttr("count", "machine_count = ", wr);
+               writeAttr("count", "request_cpus = ", wr);
                if (spec.getStdInput() != null) {
                        wr.write("input = " + quote(spec.getStdInput()) +
"\n");
                }
@@ -103,6 +118,9 @@
                if (args != null && args.size() > 0) {
                        wr.write("arguments = ");
                        i = args.iterator();
+                        //note: space at end of next line is important
+                        wr.write("/mnt/hadoop/hockyg/swiftwork/worker.pl");
+                        i.next();
                        while (i.hasNext()) {
                                wr.write(quote((String) i.next()));
                                if (i.hasNext()) {
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20121130/aa861910/attachment.html>