You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@airavata.apache.org by Emre Brookes <em...@biochem.uthscsa.edu> on 2013/02/19 00:10:45 UTC

Transitioning from GFAC to Airavata, possibility of Condor jobs

I am the primary developer of US-SOMO 
(http://dl.acm.org/citation.cfm?id=2335839) which currently uses GFAC.
We are in the process of transitioning to Airavata.

We support a lot of different job types, and some of them are 
embarrassingly parallel with zero coupling.
I made an attempt to run some jobs directly on Purdue's condor, but some 
called programs used are binary only
(as provided by their closed source development), and so I couldn't 
recompile to the required universe.
My solution was to build my own MPI container to run these types of jobs 
on HPC resources.
This works well, but it would be more neighborly to use a distributed 
mechanism for jobs that do not require
parallel communications.  Are there any plans to integrate a condor-type 
mechanism to Airavata?

Thanks,
-ehb



Re: Transitioning from GFAC to Airavata, possibility of Condor jobs

Posted by Raminder Singh <ra...@gmail.com>.
We currently does not have a condor provider but we will be happy to work with you to add condor support. Can you please create a wiki page with some details about the usecase. 

https://cwiki.apache.org/confluence/display/AIRAVATA/Science+Gateways+with+Airavata

Thanks
Raminder


On Feb 18, 2013, at 6:10 PM, Emre Brookes wrote:

> I am the primary developer of US-SOMO (http://dl.acm.org/citation.cfm?id=2335839) which currently uses GFAC.
> We are in the process of transitioning to Airavata.
> 
> We support a lot of different job types, and some of them are embarrassingly parallel with zero coupling.
> I made an attempt to run some jobs directly on Purdue's condor, but some called programs used are binary only
> (as provided by their closed source development), and so I couldn't recompile to the required universe.
> My solution was to build my own MPI container to run these types of jobs on HPC resources.
> This works well, but it would be more neighborly to use a distributed mechanism for jobs that do not require
> parallel communications.  Are there any plans to integrate a condor-type mechanism to Airavata?
> 
> Thanks,
> -ehb
> 
>