No real preference. I do want to play with some of the new features in CUDA
6 this summer. Aside from that, the SpMM is of interest to the other groups
I work with. I think Petsc bindings would be a good project. I met with a
CFD group on Friday to discuss optimization and scaling improvements in
their petsc code. Seems to be a big item of interest for many.
-E
On Saturday, February 15, 2014, Karl Rupp <r...@iue.tuwien.ac.at> wrote:
> Hi Evan,
>
> > Fyi, I'm willing to contribute to the GSoC effort as well. I can sponsor
>
>> access to the variety of hardware we have at the Minnesota
>> Supercomputing Institute. Including single and multi-GPU nodes and
>> workstations (m2070s, k20s, k2s, and quadro variants), single and multi
>> Xeon phi 5110p nodes, and nehalem and sandy bridge nodes.
>>
>> Let me know if the need arises. I'm also open to mentor if needed.
>>
>
> awesome, Evan, that would be absolutely great. Do you have any particular
> project you'd like to see addressed? With multiple nodes available it would
> also be interesting to work on the PETSc<->ViennaCL bindings. (This would
> certainly require a fairly experienced student)
>
> Best regards,
> Karli
>
>
>
>
>>
>> On Saturday, February 15, 2014, Karl Rupp <r...@iue.tuwien.ac.at
>> <mailto:r...@iue.tuwien.ac.at>> wrote:
>>
>> Hi Philippe,
>>
>> > I completely agree, concerning matrix-free implementations of
>> the linear
>> > solver.
>> >
>> > Their absence is the very reason why I had to reimplement solvers
>> for
>> > UMinTL.
>>
>> I assume you are aware that you can overload viennacl::linalg::prod()
>> for whatever custom 'matrix' type you pass to solve()?
>>
>>
>> > Furthermore, some other fancy stopping criterions may be
>> > provided. For example, some algorithms in unconstrained
>> optimization use
>> > CG on an indefinite matrix, and abort the solver once p^TAp < 0.
>> There
>> > are also some probabilistic stopping criterions for CG when the
>> > matrix-free implementation is an estimator of the true
>> matrix-vector
>> > product. In the end, the CG I ended up with for UMinTL is pretty
>> big and
>> > flexible, and I think it would be a good thing to have the same
>> thing
>> > within ViennaCL.
>>
>> The monitoring capabilities for the iterative solvers in ViennaCL are
>> indeed poor, not providing any feedback to the outside about the
>> current
>> residual and/or custom stopping criteria, convergence reasons, etc.
>> Improving this is desirable, among many other things to do as well.
>> Again a matter of priorities... ;-)
>>
>> Best regards,
>> Karli
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience. Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&;
>> iu=/4140/ostg.clktrk
>> _______________________________________________
>> ViennaCL-devel mailing list
>> ViennaCL-devel@lists.sourceforge.net <javascript:;>
>> https://lists.sourceforge.net/lists/listinfo/viennacl-devel
>>
>>
>>
>> --
>> -Evan Bollig
>> bol...@gmail.com <mailto:bol...@gmail.com>
>> bol...@scs.fsu.edu <mailto:bol...@scs.fsu.edu>
>>
>
>
--
-Evan Bollig
bol...@gmail.com
bol...@scs.fsu.edu
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
