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
>
>