headers
George Shapovalov | 18 Aug 2005 11:52
X-Face
Picon
Favicon

Re: Scientific herd leadership

Hi guys.

Sorry that I did not reply yesterday, I had a presentation to prepare for 
today :).

I actually moved to a new place already. I am in Switzerland at the moment 
(Geneva/Lausanne, anybody around?), starting a new postdoc position (somebody 
might remember my email to -core or -dev some time ago). I am getting back up 
to speed, however I am still in much flux and everything official takes soo 
long in Swiss :(. Pluss the stress of starting new work (and getting all the 
equipment together :))...

There are a few points to address, so I'll structure my reply:

1. 
Anyway, as far as the leadership goes, I have been a lead of the sci herd ever 
since I created it (few eyars already, was that really that long ago? :)). 
Unfortunately things were rather quiet lately and, as I am not completely 
"on" yet, I am willing to give the leadership off to somebody who will have 
enough time on his hands. That, or at least I think we should have an active 
co-lead or may be even some more involved structure. Well, lets start with a 
co-lead first, so that we get at least somehting done :).

2. 
It would be good to have more devs involved in Scientific Gentoo. I can 
honestly say, that it surpassed my original expectations (it started out as a 
single category with a herd attached) and seems to have attained a status of 
an important project at the intersection of science and Linux. Looks like we 
have people recommending others to run Gentoo because of science apps we 
carry. Well, at least I saw few reports to that effect some time ago :).
(Continue reading)

Permalink | Reply | 12 comments |
headers
Olivier Fisette | 18 Aug 2005 17:03
Picon
Favicon

Re: Re: Scientific herd leadership

On Thursday, 18 August 2005 05:52 am, George Shapovalov wrote:
> I used to put out calls for new/interested devs to help
> Scientific Gentoo, when I was more active, and the responce
> was rather positive. However recently I did not have enough
> time to devote to training of new devs, so that slipped by. I
> think it would be usefull to reinstate that initiative, but
> first we need to get a head-count of who feels like doing the
> training. Should we have a 1 year as a dev  requirement for
> the trainers? (not the trainees of course! They are even
> better picked up from science than from Linux althogether :))
> I would think so, given complexity of Gentoo nowadays and that
> last thing we want to do is to screw our comprehension by
> scientific community :).

Unless I am mistaken, any Gentoo developer is free to open a "New 
developer" bug for consideration by our recruiters team, as long 
as he is willing to mentor the recruit. I see no reason for the 
sci team to impose additional restrictions upon its members. I 
think we can trust the judgement of the mentoring dev on this.

I am ready to mentor a candidate. I have the necessary free time 
right now and will have it for a few months. I have already 
mentored someone once and found it a very rewarding experience.

Since everybody agrees that we need more hands, I asked 
recruiters to update the Staffing Needs on the gentoo.org Web 
site to reflect this.

Kind regards,
(Continue reading)

Permalink | Reply | 10 comments |
headers
Donnie Berkholz | 18 Aug 2005 18:03
Picon
Favicon

Re: Re: Scientific herd leadership


Olivier Fisette wrote:
| Unless I am mistaken, any Gentoo developer is free to open a "New
| developer" bug for consideration by our recruiters team, as long
| as he is willing to mentor the recruit. I see no reason for the
| sci team to impose additional restrictions upon its members. I
| think we can trust the judgement of the mentoring dev on this.

I wrote up a new mentoring guide recently [1]. The relevant part here is
that you need to be a dev for six months or be a project lead.

1. http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml

Thanks,
Donnie
Permalink | Reply | 0 comments |
headers
Jordan Dawe | 18 Aug 2005 22:35

Re: Re: Scientific herd leadership

Olivier Fisette wrote:

>On Thursday, 18 August 2005 05:52 am, George Shapovalov wrote:
>  
>
>>I used to put out calls for new/interested devs to help
>>Scientific Gentoo, when I was more active, and the responce
>>was rather positive. However recently I did not have enough
>>time to devote to training of new devs, so that slipped by. I
>>think it would be usefull to reinstate that initiative, but
>>first we need to get a head-count of who feels like doing the
>>training. Should we have a 1 year as a dev  requirement for
>>the trainers? (not the trainees of course! They are even
>>better picked up from science than from Linux althogether :))
>>I would think so, given complexity of Gentoo nowadays and that
>>last thing we want to do is to screw our comprehension by
>>scientific community :).
>>    
>>
>
>Unless I am mistaken, any Gentoo developer is free to open a "New 
>developer" bug for consideration by our recruiters team, as long 
>as he is willing to mentor the recruit. I see no reason for the 
>sci team to impose additional restrictions upon its members. I 
>think we can trust the judgement of the mentoring dev on this.
>
>I am ready to mentor a candidate. I have the necessary free time 
>right now and will have it for a few months. I have already 
>mentored someone once and found it a very rewarding experience.
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Peter Bienstman | 21 Aug 2005 13:43
Picon
Favicon

lapack transition

Hi,

I've been looking through the tree to see which packages use lapack/blas, and 
which of them are prepared for the new infrastructure. There are actually far 
less packages than I anticipated:

Still depends on old infrastructure:

   sys-cluster/hpl

Already uses virtual/blas or virtual/lapack in unstable branch:

   dev-lang/R
   sci-geosciences/grass
   sci-misc/camfr
   sci-chemistry/mpqc
   sci-mathematics/octave
   sci-misc/xfoil

Uses own code, but could benefit from transition:

   dev-python/numeric (see http://bugs.gentoo.org/show_bug.cgi?id=81520)

Peter
Permalink | Reply | 14 comments |
headers
Darren Dale | 21 Aug 2005 15:22
Picon
Favicon

Re: lapack transition

On Sunday 21 August 2005 7:43 am, Peter Bienstman wrote:
> Hi,
>
> I've been looking through the tree to see which packages use lapack/blas,
> and which of them are prepared for the new infrastructure. There are
> actually far less packages than I anticipated:
>
> Still depends on old infrastructure:
>
>    sys-cluster/hpl
>
> Already uses virtual/blas or virtual/lapack in unstable branch:
>
>    dev-lang/R
>    sci-geosciences/grass
>    sci-misc/camfr
>    sci-chemistry/mpqc
>    sci-mathematics/octave
>    sci-misc/xfoil
>
> Uses own code, but could benefit from transition:
>
>    dev-python/numeric (see http://bugs.gentoo.org/show_bug.cgi?id=81520)

I use numeric and scipy, and have been trying for a long time to improve the 
ebuilds to use blas/lapack/atlas. I submitted an ebuild for numeric six 
months ago (http://bugs.gentoo.org/show_bug.cgi?id=81520), but it has 
languished in buzilla because it is not clear how to deal with ATLAS (my 
atlas USE flag was rejected). How should ATLAS dependencies be handled in the 
new infrastructure?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Marcus D. Hanwell | 21 Aug 2005 15:47
Picon
Favicon
Gravatar

Re: Re: Scientific herd leadership

On Thursday 18 August 2005 10:52, George Shapovalov wrote:
> Hi guys.
>
> Sorry that I did not reply yesterday, I had a presentation to prepare for
> today :).
>
> I actually moved to a new place already. I am in Switzerland at the moment
> (Geneva/Lausanne, anybody around?), starting a new postdoc position
> (somebody might remember my email to -core or -dev some time ago). I am
> getting back up to speed, however I am still in much flux and everything
> official takes soo long in Swiss :(. Pluss the stress of starting new work
> (and getting all the equipment together :))...

It is great to hear that from you, and that you are still active. I heard you 
were moving around and we figured that may be you didn't have time right now. 
I hope the new position goes well.
>
> There are a few points to address, so I'll structure my reply:
>
> 1.
> Anyway, as far as the leadership goes, I have been a lead of the sci herd
> ever since I created it (few eyars already, was that really that long ago?
> :)). Unfortunately things were rather quiet lately and, as I am not
> completely "on" yet, I am willing to give the leadership off to somebody
> who will have enough time on his hands. That, or at least I think we should
> have an active co-lead or may be even some more involved structure. Well,
> lets start with a co-lead first, so that we get at least somehting done :).

If you are still around and still want to be involved with the scientific herd 
then I for one think you should maintain leadership of the herd, but I would
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Bienstman | 21 Aug 2005 16:25
Picon
Favicon

Re: lapack transition

On Sunday 21 August 2005 15:22, Darren Dale wrote:

> I use numeric and scipy, and have been trying for a long time to improve
> the ebuilds to use blas/lapack/atlas. I submitted an ebuild for numeric six
> months ago (http://bugs.gentoo.org/show_bug.cgi?id=81520), but it has
> languished in buzilla because it is not clear how to deal with ATLAS (my
> atlas USE flag was rejected). How should ATLAS dependencies be handled in
> the new infrastructure?

In theory it's as simple as depending on virtual/blas and virtual/lapack. The 
user can then switch between different lapack and blas implementations at 
runtime with blas-config and lapack-config.

Cheers,

Peter
Permalink | Reply | 6 comments |
headers
Darren Dale | 21 Aug 2005 16:33
Picon
Favicon

Re: lapack transition

On Sunday 21 August 2005 10:25 am, Peter Bienstman wrote:
> On Sunday 21 August 2005 15:22, Darren Dale wrote:
> > I use numeric and scipy, and have been trying for a long time to improve
> > the ebuilds to use blas/lapack/atlas. I submitted an ebuild for numeric
> > six months ago (http://bugs.gentoo.org/show_bug.cgi?id=81520), but it has
> > languished in buzilla because it is not clear how to deal with ATLAS (my
> > atlas USE flag was rejected). How should ATLAS dependencies be handled in
> > the new infrastructure?
>
> In theory it's as simple as depending on virtual/blas and virtual/lapack.
> The user can then switch between different lapack and blas implementations
> at runtime with blas-config and lapack-config.

It is not that simple. If numeric and scipy are to make use of atlas, atlas 
has to be in their external library list at compile time. If atlas is in the 
list, but not installed on the system, compilation will fail.

-- 
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd55 <at> cornell.edu
http://people.ccmr.cornell.edu/~dd55/
--

-- 
gentoo-science <at> gentoo.org mailing list
(Continue reading)

Permalink | Reply | 5 comments |
headers
Peter Bienstman | 21 Aug 2005 16:56
Picon
Favicon

Re: lapack transition

On Sunday 21 August 2005 16:33, Darren Dale wrote:
> On Sunday 21 August 2005 10:25 am, Peter Bienstman wrote:
> > On Sunday 21 August 2005 15:22, Darren Dale wrote:
> > > I use numeric and scipy, and have been trying for a long time to
> > > improve the ebuilds to use blas/lapack/atlas. I submitted an ebuild for
> > > numeric six months ago (http://bugs.gentoo.org/show_bug.cgi?id=81520),
> > > but it has languished in buzilla because it is not clear how to deal
> > > with ATLAS (my atlas USE flag was rejected). How should ATLAS
> > > dependencies be handled in the new infrastructure?
> >
> > In theory it's as simple as depending on virtual/blas and virtual/lapack.
> > The user can then switch between different lapack and blas
> > implementations at runtime with blas-config and lapack-config.
>
> It is not that simple. If numeric and scipy are to make use of atlas, atlas
> has to be in their external library list at compile time. If atlas is in
> the list, but not installed on the system, compilation will fail.

That's why I said 'in theory' ;-)

I'm currently working on a patch which just ignores any explicit atlas stuff 
at build time of SciPy. The idea is to build a library which simply links 
to /usr/lib/liblapack.so. SciPy doesn't need to know this is a symlink 
to /usr/lib/lapack/atlas/liblapack.so or any other implementation.

Peter
Permalink | Reply | 4 comments |

Gmane