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

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}
(2) 
_{Nov}
(27) 
_{Dec}
(31) 

2004 
_{Jan}
(6) 
_{Feb}
(15) 
_{Mar}
(33) 
_{Apr}
(10) 
_{May}
(46) 
_{Jun}
(11) 
_{Jul}
(21) 
_{Aug}
(15) 
_{Sep}
(13) 
_{Oct}
(23) 
_{Nov}
(1) 
_{Dec}
(8) 
2005 
_{Jan}
(27) 
_{Feb}
(57) 
_{Mar}
(86) 
_{Apr}
(23) 
_{May}
(37) 
_{Jun}
(34) 
_{Jul}
(24) 
_{Aug}
(17) 
_{Sep}
(50) 
_{Oct}
(24) 
_{Nov}
(10) 
_{Dec}
(60) 
2006 
_{Jan}
(47) 
_{Feb}
(46) 
_{Mar}
(127) 
_{Apr}
(19) 
_{May}
(26) 
_{Jun}
(62) 
_{Jul}
(47) 
_{Aug}
(51) 
_{Sep}
(61) 
_{Oct}
(42) 
_{Nov}
(50) 
_{Dec}
(33) 
2007 
_{Jan}
(60) 
_{Feb}
(55) 
_{Mar}
(77) 
_{Apr}
(102) 
_{May}
(82) 
_{Jun}
(102) 
_{Jul}
(169) 
_{Aug}
(117) 
_{Sep}
(80) 
_{Oct}
(37) 
_{Nov}
(51) 
_{Dec}
(43) 
2008 
_{Jan}
(71) 
_{Feb}
(94) 
_{Mar}
(98) 
_{Apr}
(125) 
_{May}
(54) 
_{Jun}
(119) 
_{Jul}
(60) 
_{Aug}
(111) 
_{Sep}
(118) 
_{Oct}
(125) 
_{Nov}
(119) 
_{Dec}
(94) 
2009 
_{Jan}
(109) 
_{Feb}
(38) 
_{Mar}
(93) 
_{Apr}
(88) 
_{May}
(29) 
_{Jun}
(57) 
_{Jul}
(53) 
_{Aug}
(48) 
_{Sep}
(68) 
_{Oct}
(151) 
_{Nov}
(23) 
_{Dec}
(35) 
2010 
_{Jan}
(84) 
_{Feb}
(60) 
_{Mar}
(184) 
_{Apr}
(112) 
_{May}
(60) 
_{Jun}
(90) 
_{Jul}
(23) 
_{Aug}
(70) 
_{Sep}
(119) 
_{Oct}
(27) 
_{Nov}
(47) 
_{Dec}
(54) 
2011 
_{Jan}
(22) 
_{Feb}
(19) 
_{Mar}
(92) 
_{Apr}
(93) 
_{May}
(35) 
_{Jun}
(91) 
_{Jul}
(32) 
_{Aug}
(61) 
_{Sep}
(7) 
_{Oct}
(69) 
_{Nov}
(81) 
_{Dec}
(23) 
2012 
_{Jan}
(64) 
_{Feb}
(95) 
_{Mar}
(35) 
_{Apr}
(36) 
_{May}
(63) 
_{Jun}
(98) 
_{Jul}
(70) 
_{Aug}
(171) 
_{Sep}
(149) 
_{Oct}
(64) 
_{Nov}
(67) 
_{Dec}
(126) 
2013 
_{Jan}
(108) 
_{Feb}
(104) 
_{Mar}
(171) 
_{Apr}
(133) 
_{May}
(108) 
_{Jun}
(100) 
_{Jul}
(93) 
_{Aug}
(126) 
_{Sep}
(74) 
_{Oct}
(59) 
_{Nov}
(145) 
_{Dec}
(93) 
2014 
_{Jan}
(38) 
_{Feb}
(45) 
_{Mar}
(26) 
_{Apr}
(41) 
_{May}
(125) 
_{Jun}
(70) 
_{Jul}
(61) 
_{Aug}
(66) 
_{Sep}
(60) 
_{Oct}
(110) 
_{Nov}
(27) 
_{Dec}
(30) 
2015 
_{Jan}
(43) 
_{Feb}
(67) 
_{Mar}
(71) 
_{Apr}
(92) 
_{May}
(39) 
_{Jun}
(15) 
_{Jul}
(46) 
_{Aug}
(63) 
_{Sep}
(84) 
_{Oct}
(82) 
_{Nov}
(69) 
_{Dec}
(45) 
2016 
_{Jan}
(92) 
_{Feb}
(91) 
_{Mar}
(148) 
_{Apr}
(43) 
_{May}
(58) 
_{Jun}
(117) 
_{Jul}
(92) 
_{Aug}
(140) 
_{Sep}
(49) 
_{Oct}
(33) 
_{Nov}
(85) 
_{Dec}
(40) 
2017 
_{Jan}
(41) 
_{Feb}
(36) 
_{Mar}
(44) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1
(8) 
2
(2) 
3

4
(2) 
5
(1) 
6
(5) 
7
(4) 
8
(11) 
9
(5) 
10
(3) 
11

12

13
(18) 
14
(5) 
15
(5) 
16
(12) 
17
(2) 
18
(9) 
19
(2) 
20
(6) 
21
(4) 
22
(1) 
23
(3) 
24
(3) 
25

26

27

28

29
(13) 
30
(1) 
31


From: Derek Gaston <friedmud@gm...>  20081007 16:23:26

There is a way to do matrix free solving with libMesh and Petsc. Take a look at the PetscNonlinearSolver (which you can get by using a NonlinearImplicitSystem). If you just set the residual() function and not the jacobian() then you are solving matrix free using Petsc SNES. Note that there is a "matvec" function on PetscNonlinearSolver (inherited from NonlinearSolver). I'm not quite sure how to use it though... it's something Ben put in I believe. If you want to turn on that "matvec" function in PetscNonlinearSolver and make it into a MatShell or PCShell that might be a good way to go. Derek On Oct 7, 2008, at 9:32 AM, Tim Kroeger wrote: > Dear libMesh team, > > As far as I see, there seems not to be any interface in libMesh to > solve a system in a matrix free way. > > I have to solve a linear system whose matrix basically has the > following structure: > > A = B + v*w^T > > where B is a sparse matrix and v and w are vectors, so that v*w^T is a > full matrix. Obviously, it is not advisable to store the full matrix. > Instead, I would like to store B, v, and w, and then supply a method > to multiply the matrix with a given vector (which is obviously quite > easy, even in parallel). > > What whould be the things to do? I guess, first I have to find out > PETSc's API for matrix free solving (provided that such a thing > exists, but I think it does). Then, I can either use PETSc directly > or  presumably better  extend the API of your LinearSolver class > towards matrix free solving. Of course, the latter would require to > do something for the other solver packages as well (Laspack etc.), but > I would just call libmesh_not_implemented() there. > > Would such an API extension be welcome? Do you have any different > ideas or suggestions? > > Best Regards, > > Tim > >  > Dr. Tim Kroeger Phone > +494212187710 > tim.kroeger@..., tim.kroeger@... Fax > +494212184236 > > MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany > > Amtsgericht Bremen HRB 16222 > Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen > >  > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblincontest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Roy Stogner <roystgnr@ic...>  20081007 16:07:30

On Tue, 7 Oct 2008, John Peterson wrote: > On Tue, Oct 7, 2008 at 10:32 AM, Tim Kroeger > <tim.kroeger@...> wrote: >> As far as I see, there seems not to be any interface in libMesh to >> solve a system in a matrix free way. >> >> I have to solve a linear system whose matrix basically has the >> following structure: >> >> A = B + v*w^T >> >> where B is a sparse matrix and v and w are vectors, so that v*w^T is a >> full matrix. Obviously, it is not advisable to store the full matrix. >> Instead, I would like to store B, v, and w, and then supply a method >> to multiply the matrix with a given vector (which is obviously quite >> easy, even in parallel). >> >> What whould be the things to do? I guess, first I have to find out >> PETSc's API for matrix free solving (provided that such a thing >> exists, but I think it does). You can basically do a MatCreateShell and then hand it to any of their existing APIs, right? Just because PETSc isn't C++ doesn't mean it isn't object oriented. But I've never tried it myself, and I'll bet your preconditioning options get tricky. >> Then, I can either use PETSc directly >> or  presumably better  extend the API of your LinearSolver class >> towards matrix free solving. Of course, the latter would require to >> do something for the other solver packages as well (Laspack etc.), but >> I would just call libmesh_not_implemented() there. >> >> Would such an API extension be welcome? Do you have any different >> ideas or suggestions? > > Definitely. I agree. > I'm not sure if we should call this "matrix free" since I think that > has other connotations for our developers in the context of Jacobian > free solutions of nonlinear systems. This is also true. I'm not sure if "shell matrix" is a standard term or a PETScism, but I'd be happy to adopt it. > One way to implement the desired functionality in PETSc is to define a > custom matrixvector product operation. See, for example, > MatShellSetOperation. If at first you can only get this working for > PETSc, that's fine. I'm not sure what the best way of abstracting > this concept is. Me neither. My first gut reaction is to create a ShellMatrix subclass of SparseMatrix.  Roy 
From: John Peterson <jwpeterson@gm...>  20081007 15:42:38

On Tue, Oct 7, 2008 at 10:32 AM, Tim Kroeger <tim.kroeger@...> wrote: > Dear libMesh team, > > As far as I see, there seems not to be any interface in libMesh to > solve a system in a matrix free way. > > I have to solve a linear system whose matrix basically has the > following structure: > > A = B + v*w^T > > where B is a sparse matrix and v and w are vectors, so that v*w^T is a > full matrix. Obviously, it is not advisable to store the full matrix. > Instead, I would like to store B, v, and w, and then supply a method > to multiply the matrix with a given vector (which is obviously quite > easy, even in parallel). > > What whould be the things to do? I guess, first I have to find out > PETSc's API for matrix free solving (provided that such a thing > exists, but I think it does). Then, I can either use PETSc directly > or  presumably better  extend the API of your LinearSolver class > towards matrix free solving. Of course, the latter would require to > do something for the other solver packages as well (Laspack etc.), but > I would just call libmesh_not_implemented() there. > > Would such an API extension be welcome? Do you have any different > ideas or suggestions? Definitely. I'm not sure what your intended use of this functionality will be, but solving "bordered systems" efficiently is one possible application. I'm not sure if we should call this "matrix free" since I think that has other connotations for our developers in the context of Jacobian free solutions of nonlinear systems. One way to implement the desired functionality in PETSc is to define a custom matrixvector product operation. See, for example, MatShellSetOperation. If at first you can only get this working for PETSc, that's fine. I'm not sure what the best way of abstracting this concept is.  John 
From: Tim Kroeger <tim.kroeger@ce...>  20081007 15:33:02

Dear libMesh team, As far as I see, there seems not to be any interface in libMesh to solve a system in a matrix free way. I have to solve a linear system whose matrix basically has the following structure: A = B + v*w^T where B is a sparse matrix and v and w are vectors, so that v*w^T is a full matrix. Obviously, it is not advisable to store the full matrix. Instead, I would like to store B, v, and w, and then supply a method to multiply the matrix with a given vector (which is obviously quite easy, even in parallel). What whould be the things to do? I guess, first I have to find out PETSc's API for matrix free solving (provided that such a thing exists, but I think it does). Then, I can either use PETSc directly or  presumably better  extend the API of your LinearSolver class towards matrix free solving. Of course, the latter would require to do something for the other solver packages as well (Laspack etc.), but I would just call libmesh_not_implemented() there. Would such an API extension be welcome? Do you have any different ideas or suggestions? Best Regards, Tim  Dr. Tim Kroeger Phone +494212187710 tim.kroeger@..., tim.kroeger@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 