You can subscribe to this list here.
2011 
_{Jan}

_{Feb}
(26) 
_{Mar}
(34) 
_{Apr}
(16) 
_{May}
(15) 
_{Jun}
(22) 
_{Jul}
(17) 
_{Aug}
(14) 
_{Sep}
(9) 
_{Oct}
(10) 
_{Nov}
(17) 
_{Dec}
(6) 

2012 
_{Jan}
(16) 
_{Feb}
(56) 
_{Mar}
(25) 
_{Apr}
(34) 
_{May}
(55) 
_{Jun}
(25) 
_{Jul}
(36) 
_{Aug}
(24) 
_{Sep}
(50) 
_{Oct}
(46) 
_{Nov}
(19) 
_{Dec}
(37) 
2013 
_{Jan}
(33) 
_{Feb}

_{Mar}
(48) 
_{Apr}
(10) 
_{May}
(40) 
_{Jun}
(67) 
_{Jul}
(34) 
_{Aug}
(29) 
_{Sep}
(29) 
_{Oct}
(39) 
_{Nov}
(17) 
_{Dec}
(6) 
2014 
_{Jan}
(36) 
_{Feb}
(14) 
_{Mar}
(63) 
_{Apr}
(16) 
_{May}
(16) 
_{Jun}

_{Jul}
(9) 
_{Aug}
(3) 
_{Sep}
(20) 
_{Oct}
(9) 
_{Nov}
(2) 
_{Dec}
(5) 
2015 
_{Jan}
(29) 
_{Feb}
(8) 
_{Mar}
(47) 
_{Apr}
(13) 
_{May}
(10) 
_{Jun}
(16) 
_{Jul}
(13) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1

2
(1) 
3
(3) 
4
(2) 
5

6

7

8
(2) 
9
(7) 
10
(1) 
11
(1) 
12

13

14

15

16

17
(1) 
18
(2) 
19

20
(2) 
21
(2) 
22
(1) 
23
(3) 
24
(4) 
25

26

27

28

29

30

31
(2) 


From: Andy Adler <adler@sc...>  20110303 16:43:27

> On Wed, Mar 2, 2011 at 4:34 PM, Andy Adler <adler@...> wrote: >>  interface to external solvers > > That is probably the best direction to go in. I haven't spent much > time looking at the issues with matlab integration... my main issues > have revolved around very different interfaces between solvers and > challenging installations. Only a couple have directly supported > matlab interfaces and those should just need the function to call for > a solve. Most take options to fine tune performance but should work > well outofthebox with a default configuration. I get the feeling this may be a lot to pack into this release. My main idea was to get it really stable so we can make more aggressive changes later. Maybe you can check this in later. So, it looks like the only main thing now left is to do extensive bug testing.  Andy 
From: Alistair Boyle <alistair.boyle@gm...>  20110303 16:35:47

On Thu, Mar 3, 2011 at 11:19 AM, Alistair Boyle <alistair.js.boyle@...> wrote: > Andy, > > On Wed, Mar 2, 2011 at 4:34 PM, Andy Adler <adler@...> wrote: >>  interface to external solvers I should also note that, looking at the MATLAB release notes http://www.mathworks.com/help/techdoc/rn/rn_intro.html MATLAB is using MKL or ACML (depending on processor, Intel or AMD) for BLAS and LAPACK. Presumably its now using the other features of these libraries too? Other than that, I see http://www.mathworks.com/help/techdoc/rn/bque19l.html MATLAB Version 7.3 (R2006b) MATLAB 7.3 supports new versions of the following libraries: Library Name Version Supported in MATLAB 7.3 AMD 2.0 COLAMD 2.5 CHOLMOD 1.1 UMFPACK 5.0 and latest references to ACML and MKL are http://www.mathworks.com/help/techdoc/rn/bryg9vd1.html MATLAB Version 7.8 (R2009a) AMD Core Math Library (ACML) is upgraded to version 4.1.0 http://www.mathworks.com/help/techdoc/rn/brqyzsl1.html MATLAB Version 7.7 (R2008b) MATLAB software supports the Intel Math Kernel Library (MKL) version 10.0.3. If it is using the sparse solvers from MKL then it is already using a somewhat dated version of Pardiso, as integrated into MKL. This is only speculation though since I haven't seen any statements about sparse solvers in the release notes except for mention of UMFPACK in R2006b. Alistair 
From: Alistair Boyle <alistair.boyle@gm...>  20110303 16:20:17

Andy, On Wed, Mar 2, 2011 at 4:34 PM, Andy Adler <adler@...> wrote: >  interface to external solvers > > For the last item, I think we should have a new function > fwd_model.solve = @external_solver > fwd_model.external_solver.name = ... > fwd_model.external_solver.params = ... > which would allow eidors to plug into faster sparse > and distributed solvers. > > Alistair, would this be the right way to go? Could you > offer suggestions on the way to write it? That is probably the best direction to go in. I haven't spent much time looking at the issues with matlab integration... my main issues have revolved around very different interfaces between solvers and challenging installations. Only a couple have directly supported matlab interfaces and those should just need the function to call for a solve. Most take options to fine tune performance but should work well outofthebox with a default configuration. Most solvers break the sequence into an "analyze", "factorize", "solve" (possibly with iterative refinement) sequence which allows you to: 1. factorize the pattern of nonzeros in the matrix  as long as the system pattern doesn't change (i.e. remeshing?) you can reuse the work repeatedly, more effort here means less later, so a trade off depending on how many times we're expecting to reuse the work 2. analyze the system matrix  again reusable as long as the actual values in the system matrix don't change 3. solve repeatedly for different righthandsides, maybe do iterative refinement if its warranted If we were to be complete it would be 1. permute: find an appropriate permutation (AMD, METIS, SCOTCH, etc) 2. analyze: symbolic analysis & factorization 3. factorize: numerical factorization 4. evaluate: evaluate solution 5. refine: iterative refinement A basic solve_this type function is a good enough starting place though. It would be worth leaving room for more fine grain control so we can optimize it later. Its certainly more invasive to try and use the solver in stages, avoiding the redoing of old work. (Maybe the EIDORS cache can be our friend there?) There are some comments in eidors/algorithms/n_polydorides/forward_solver.m about wanting to be able to do the iterative refinement but not having (re)implemented it yet in matlab. Also, not sure about the QR decomposition trick in forward_solver.m, and how that might be possible to recycle into some of the solver code? (Its a good trick...) The fortran solvers generally stash the old answers away and throw them out when they need more room. The C ones let you deal with the memory, so you can decide how many old (incomplete) solutions you want to keep around. Alistair 