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}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

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

10
(4) 
11
(1) 
12

13

14
(5) 
15
(1) 
16
(1) 
17
(1) 
18
(4) 
19
(1) 
20

21
(1) 
22

23

24

25
(1) 
26

27
(1) 
28
(1) 
29

30

31
(5) 





From: Pls check this new site <acro3451@ts...>  20071231 23:43:32

=50=6C=65=61=73=65 =73=65=65 =74=68=69=73 =73=69=74=65 =69=6E =53=75=62=6A= =65=63=74 
From: Pls check this new site <acro3451@ts...>  20071231 20:15:16

=50=6C=65=61=73=65 =73=65=65 =74=68=69=73 =73=69=74=65 =69=6E =53=75=62=6A= =65=63=74 
From: Pls check this new site <acro3451@ts...>  20071231 11:46:56

=50=6C=65=61=73=65 =73=65=65 =74=68=69=73 =73=69=74=65 =69=6E =53=75=62=6A= =65=63=74 
From: Pls check this new site <acro3451@ts...>  20071231 09:16:50

=50=6C=65=61=73=65 =73=65=65 =74=68=69=73 =73=69=74=65 =69=6E =53=75=62=6A= =65=63=74 
From: oilpaintingstudioB@163.com  20071231 03:15:29

V2VsY29tZSB0byB0aGUgT2lsIFBhaW50aW5nIFN0dWRpby4gIA0KV2UgaGF2ZSBiZWVuIHN1Y2Nl c3NmdWxseSB3b3JraW5nIHdpdGggZmluZSBhcnQgZ2FsbGVyaWVzIGFuZCBhcnRpc3RzIGludGVy bmF0aW9uYWxseSBmb3Igb3ZlciBhIGRlY2FkZS4gIE91ciBtdXNldW0gcXVhbGl0eSByZWFsaXNt IGlzIGNyZWF0ZWQgYnkgMjUgb2YgQ2hpbmVzZSBtb3N0IHNraWxsZWQgYXJ0aXN0cy4gIEVhY2gg YXJ0aXN0IGhhcyBiZWVuIGZvcm1hbGx5IHRyYWluZWQgYW5kIGhhcyByZWNlaXZlZCB0aGVpciBk ZWdyZWUgZnJvbSBtYW55IG9mIHRoZSBmaW5lc3QgYXJ0IHVuaXZlcnNpdGllcyBpbiBDaGluYSBh bmQgYWJyb2FkLiBPdXIgYXJ0aXN0cyBoYXZlIGFmZm9yZGVkIG91ciBudW1lcm91cyBjbGllbnRz LCBpbmNsdWRpbmcgYXJ0IGdhbGxlcmllcywgZXN0YWJsaXNoZWQgYXJ0aXN0cywgcHJpdmF0ZSBw YXJ0aWVzIGFuZCBvdGhlciBpbnRlcmVzdGVkIGluZGl2aWR1YWxzLCB0aGUgYWJpbGl0eSB0byBp bmNyZWFzZSB0aGVpciBjdXN0b21lciBiYXNlLCByZWFsaXplIGEgbXVjaCBoaWdoZXIgcHJvZml0 IG1hcmdpbiBhbmQgYWNxdWlyZSBwZXJmZWN0bHkgZXhlY3V0ZWQgZmluZSBhcnQgb2lsIHBhaW50 aW5ncy4NCldlIGFyZSBwcmVzZW50bHkgd29ya2luZyB3aXRoIGdhbGxlcmllcywgZmluZSBhcnRp c3RzLCBwaG90b2dyYXBoZXJzLCBkaWdpdGFsIGRlc2lnbmVycyBhbmQgcHJpdmF0ZSBwYXJ0aWVz IHdobyBhcmUgaW50ZXJlc3RlZCBpbiByZWFsaXppbmcgYSBmYXN0ZXIgd2F5IHRvIGNyZWF0ZSBh IGhpZ2hseSBsdWNyYXRpdmUgZW52aXJvbm1lbnQgYnkgb2ZmZXJpbmcgZXh0cmVtZWx5IGhpZ2gg cXVhbGl0eSBvaWwgcGFpbnRpbmdzIGF0IHRoZSBtb3N0IGNvbXBldGl0aXZlIHByaWNpbmcgaW4g dGhlIGluZHVzdHJ5LiAgV2UgaGF2ZSB3b3JrZWQgc3VjY2Vzc2Z1bGx5IHdpdGggbWFueSBub3Rl ZCBhcnRpc3RzIHdvcmxkLXdpZGUgYW5kIG9mZmVyIG91ciBjbGllbnRzIGFuIHVuY29uZGl0aW9u YWwgYmluZGluZyBjb250cmFjdCBpbiByZWdhcmQgdG8gdGhlaXIgcHJpdmFjeSBhbmQgc291cmNl IG9mIHRoZWlyIG9pbCBwYWludGluZ3MuIFdlIGhhdmUgYWx3YXlzIGFuZCB3aWxsIGNvbnRpbnVl IHRvIHJlc3BlY3QgaW50ZXJuYXRpb25hbCBjb3B5cmlnaHQgbGF3cy4gIFlvdXIgb3JkZXIgb2Yg b3JpZ2luYWwgYXJ0IHdoZXRoZXIgY3JlYXRlZCBmcm9tIGRpZ2l0YWwsIHBob3RvZ3JhcGhpYyBv ciBhbnkgb3RoZXIgZm9ybSB3aWxsIG5ldmVyIGJlIHJlY3JlYXRlZCBmb3IgYW5vdGhlciBjbGll bnQuIEVhY2ggb2Ygb3VyIGFydGlzdHMgd29ya3MgaW5zaWRlIHRoZSBmcmFtZXdvcmsgb2YgdGhl aXIgb3duIHNwZWNpYWx0eSB3aGV0aGVyIHBvcnRyYWl0dXJlLCBsYW5kc2NhcGUsIG1hcmluZSwg ZmxvcmFsLCBzdGlsbCBsaWZlIG9yIHdoYXQgZXZlciB5b3VyIHBlcnNvbmFsIG5lZWQgbWF5IGJl LiBPdXIgZXh0ZW5zaXZlIGNvbW11bml0eSBvZiBmaW5lIGFydGlzdHMgaXMgY2FwYWJsZSBvZiBj cmVhdGluZyBleGFjdGx5IHRoZSBmaW5lIGFydCBvaWwgcGFpbnRpbmcgdGhhdCB5b3Ugb3JkZXIu IFdlIG9mZmVyIGFuIHVuY29uZGl0aW9uYWwgbW9uZXkgYmFjayBndWFyYW50ZWUgdG8gYWxsIG9m IG91ciBjbGllbnRzIGlmIHlvdSBhcmUgZGlzc2F0aXNmaWVkIHdpdGggeW91ciBzaGlwbWVudC4g IA0KV2UgbG9vayBmb3J3YXJkIHRvIGEgbXV0dWFsbHkgYmVuZWZpY2lhbCByZWxhdGlvbnNoaXAu ICBQbGVhc2UgY29udGFjdCB1cyBieSBlLW1haWwgd2l0aCB5b3VyIHJlcXVpcmVtZW50cy4gSW5k aXZpZHVhbCBvcmRlcnMgYnkgcHJpdmF0ZSBwYXJ0aWVzIGFyZSBnbGFkbHkgYWNjZXB0ZWQuIERl ZXBlciBkaXNjb3VudHMgYXJlIGF2YWlsYWJsZSBvbiBsYXJnZXIgb3JkZXJzLiBQbGVhc2UgY29u dGFjdCB1cyBmb3IgZGV0YWlscy4NClNpbmNlcmVseSwNClRoZSBPaWwgUGFpbnRpbmcgU3R1ZGlv Lg0KRW1haWw6b2lscGFpbnRpbmdzdHVkaW9CQDE2My5jb20gCQ0KSWYgdGhpcyBlLW1haWwgaGFz IHJlYWNoZWQgeW91IGluIGVycm9yLCB3ZSBhcG9sb2dpemUgZm9yIHRoZSBpbmNvbnZlbmllbmNl LiAgWW91IG1heSBiZSByZW1vdmVkIGZyb20gb3VyIGNsaWVudCBsaXN0IGJ5IGNvbnRhY3Rpbmcg dXMgd2l0aCB5b3VyIHJlcXVlc3QuICANCg0K 
From: chanelle camper <chanelle.camper@sk...>  20071228 20:54:34

You can screw Pamela Anderson too, with your 9 inch dick. http://www.mthuvoom.com/ 
From: Wilfred Erickson <W<ilfred@in...>  20071227 12:17:23

Tuesday, the worst singleday decline since the BosniaHerzegovina=2E civilians=2E Two Iraqi civilians and six U=2ES=2E troops were data of oth= er peers within one school=2E Doesn't it sound humiliating, when they call your dic'k a "weewee"? Don't let them mock you anymore! Use VPXL to increase your trouser mouse = in length and girth!=20 http://weiouyt=2Ecom/ Give it a try and teach them all a more fitting definition of your new ma= ssive rod! and then the Department of Conservation=2E prayers asking God to bless th= e nation and guide the Google, which is based in Mountain View, Californi= a, employee reduction would be about 5,000, or 9% of the showed a good pace = and for the dying laps of the race The 2007 Formula1 season from now app= ears to be a 
From: mirza Drozdowicz <D<rozdowiczagk@fi...>  20071225 19:28:26

Give your loved one a boost! http://zwpocrt.com/ 
From: Ingo Schmidt <ingo.schmidt@tu...>  20071221 10:00:59

Sorry for the delayed reply. > > I've added to the SVN head something compatible with your set_data > method (with several changes like inlining it, making the parameters > const, making the vector parameter a reference, and removing the error > cases), as well as the equivalent method for setting elem data. > Thanks for that. > Well, double check the new mesh_data.h in the SVN head, and make sure > the new methods there are compatible with your code. The only > functionality changes I made were that the method in SVN will happily > write a data vector even to an object that has no data or has a data > vector of a different length. If you do need to error() out when that > happens you'll have to do it in application code; we might as well > support more lenient data changes in case other codes need them in the > future. OK. It works. Moving the error handling to the application code will be no problem. > And speaking of the future: like I said, we've basically got nobody > maintaining this code right now. Unless anyone else objects, I think > any functionality you want to add or changes you want to make will be > fine as long as you don't break backwards compatibility. For that > matter, there are some things that are worth breaking backwards > compatibility slightly; if you were motivated enough to figure out > what's going wrong with MeshData in parallel I think you'd be given a > lot of leeway in deciding how best to fix it. Thanks for the offer but up to now I neglected the parallel functionality (like most of the other nice features of libMesh, too) of my application code. So due to the lack of experience with parallel programming that mission would be to extensiv for me at the moment. Best regards, nice xmas hollydays and a happy new year. Ingo  Dipl.Ing. Ingo Schmidt Institute of Modelling and Computation Hamburg University of Technology tel: +49/(0)40/428784483 Denickestr.17 fax: +49/(0)40/428784353 Building L/ room: 3032 21075 Hamburg http://www.mub.TUHarburg.de 
From: dd <nnvbvbvfjf@12...>  20071219 10:24:56

贵公司负责人收: 本公司可提供发(票)代理,电话13710988004 刘生 
From: Roy Stogner <roystgnr@ic...>  20071218 20:00:06

On Tue, 18 Dec 2007, John Peterson wrote: > Yujie writes: > > Hi, everyone > > > > Supposed that I have three variables (U, V, W) in three coupled PDEs (Eq1, > > Eq2, Eq3). In the final matrix and RHS, their numbering > > is UEq1, UEq2, UEq3, VEq1, VEq2, VEq3, WEq1, WEq2, WEq3? > > Probably something like: > > [K_UU K_UV K_UW] [U] > [K_VU K_VV K_VW] [V] > [K_WU K_WV K_WW] [W] This is the default behavior. If you want Dofs to be sorted by node instead (giving a vector like [U1 V1 W1 U2 V2 W2 U3 V3 W3...]) there's a little used command line option "node_major_dofs" to do so.  Roy 
From: John Peterson <peterson@cf...>  20071218 19:13:50

Yujie writes: > Hi, everyone > > Supposed that I have three variables (U, V, W) in three coupled PDEs (Eq1, > Eq2, Eq3). In the final matrix and RHS, their numbering > is UEq1, UEq2, UEq3, VEq1, VEq2, VEq3, WEq1, WEq2, WEq3? Probably something like: [K_UU K_UV K_UW] [U] [K_VU K_VV K_VW] [V] [K_WU K_WV K_WW] [W] but it sounds like you are getting ready to do something illadvised, such as indexing directly into the solution vector based on and assumed variable ordering. Use the DofMap for this... J > Thanks a lot. > > Regards, > Yujie 
From: Yujie <recrusader@gm...>  20071218 18:57:44

Hi, everyone Supposed that I have three variables (U, V, W) in three coupled PDEs (Eq1, Eq2, Eq3). In the final matrix and RHS, their numbering is UEq1, UEq2, UEq3, VEq1, VEq2, VEq3, WEq1, WEq2, WEq3? Thanks a lot. Regards, Yujie 
From: Reker Espejel <offscouring@br...>  20071218 06:58:08

Heyello, =20 =20 Downlooadable Softwaree=20 http://www.geocities.com/b40jc8g6zceds/ =09My way. If wind and tide's ag'in' me, i can wait have been prevented. It was late in the summer she resumed her work with a stifled chuckle, and to go=97just to help poor miss blacklock out. I'm it's not, even, as though you were his sister's had earned opportunities for contemplative repose. you are, don't it? Undershaft accepting the chair modern greek, and in the second place they were blankets. And what was this, in such cold as penetrated the weight of which it is impossible to deny,. 
From: Roy Stogner <roystgnr@ic...>  20071217 03:35:53

On Wed, 5 Dec 2007, Ingo Schmidt wrote: > Since no one responded to my proposal concerning the MeshData class Yeah, I've been letting this thread sit in my outbox for a week or two myself. I think the reason you've seen no response (other than that note from John) is that there's essentially nobody maintaining the MeshData class right now. Its original author isn't an active libMesh developer right now, none of the other developers use it and so nobody has kept it properly up to date. I think it may be buggy in parallel, and it certainly won't work with the new ParallelMesh. Yet we can't be sure how many users are actively using it in serial, so we're reluctant to make any changes to the class! > I send a code part requesting you to add this member function to the > MeshData class. I've added to the SVN head something compatible with your set_data method (with several changes like inlining it, making the parameters const, making the vector parameter a reference, and removing the error cases), as well as the equivalent method for setting elem data. > I don't know if that function will give a conflict to the all over > ideology of that class. Please let me know if so. It won't break any existing code, which is all I'm concerned about. It may be more "low level" than is healthy in a class which has "_*_data_closed" flags floating about, but after reading through the whole code I don't see the point of those flags to begin with. > For progress of my programming that functionality of the meshdata > class is essential. Well, double check the new mesh_data.h in the SVN head, and make sure the new methods there are compatible with your code. The only functionality changes I made were that the method in SVN will happily write a data vector even to an object that has no data or has a data vector of a different length. If you do need to error() out when that happens you'll have to do it in application code; we might as well support more lenient data changes in case other codes need them in the future. And speaking of the future: like I said, we've basically got nobody maintaining this code right now. Unless anyone else objects, I think any functionality you want to add or changes you want to make will be fine as long as you don't break backwards compatibility. For that matter, there are some things that are worth breaking backwards compatibility slightly; if you were motivated enough to figure out what's going wrong with MeshData in parallel I think you'd be given a lot of leeway in deciding how best to fix it.  Roy 
From: Wilfred Kolowitz <WilfredK<olowitz@te...>  20071216 22:37:48

make the most out of sex and have multiple orgasms everytime http://www.pvlds.com/ 
From: Benjamin Kirk <benjamin.kirk@na...>  20071215 01:05:23

>> In libMesh this is as simple as providing a residual function and then >> using the ksp_matrix_free or ksp_mf_operator (I think) options to PETSc. > > I understand this. But my concern is how would you compute the local > contributions to the matvec product ? Since I do not want to store the > global stiffness or mass matrices, the question then becomes, what is the > "overhead" in writing a user routine to perform local assemblies with local > mass, stiffness for each DOF to get the nonlinear residual functional ? And > how does this operation scale in parallel ? Oh... That part is easy. In all the examples we show, we compute an element stiffness matrix and then assemble the global stffness matrix: K = Am(K_e) & f = Av(f_e) where Am(), Av() are notional matrix and vector assembly operators. Similarly, let the element residual be r_e = K_e u_e  f_e and the global residual is r = Av(r_e). So in the matrix free approach we just calculate the global residual from local contributions, and never form a global matrix. Now, of course global matrix assembly is expensive in terms of storage, but the vector assembly is not. For a vector of length N on P processors, each processor stores ~O(N/P) entries. And very few elements actually need to be communicated. In 2D the parallel vector summation is often driven by network latency instead of bandwidth because the data transfers are small. > I pose this question since the matrixfree algorithm will not involve any > kind of assembling routine at all. All it would need is to know the local h, > p, and basis type to compute local mass, stiffness matrices to compute the > local residual (a value in the global residual vector corresponding to the > unknown). Agreed. > Also, I perfectly understand your concern about creating a global > preconditioner matrix for this method to be successful but I believe that a > framework can be written well to handle the matrixfree algorithm in a > purely recursive fashion thereby eliminating any need for a preconditioner > matrix. Just my 2 cents. > Any pointers to benchmark studies that you have done in the past regarding > the speed and scalability for different kinds of problems (diffusion, > convection dominated) would also be very useful to me. I'll see what I can pull up. PETSc's interface to hypre for diffusion problems allows for algebraic multigrid directly, which is hard to beat. > I would be happy to contribute to a sample code regarding a matrixfree > scheme with LibMesh and PETSc which will give me an opportunity to test out > different techniques I have in mind. I was thinking about using the LaplaceYoung free surface model to put together an example problem using this functionality. The LY model is particularly wellsuited since it is 2D, scalar, steady, and nonlinear, and wellsuited to adaptivity. I hope to get started on it Monday  I'll be on travel and that's always a good time for me to code without the daily distractions. ;) I should have something by the end of the week. Ben 
From: Vijay M <unknownreference@gm...>  20071214 20:18:21

Ben, Thanks for the prompt reply ! > I assume you would like to compute the action of the matrixvector product > in some Krylov subspace method? Yes. > In libMesh this is as simple as providing a residual function and then > using the ksp_matrix_free or ksp_mf_operator (I think) options to PETSc. I understand this. But my concern is how would you compute the local contributions to the matvec product ? Since I do not want to store the global stiffness or mass matrices, the question then becomes, what is the "overhead" in writing a user routine to perform local assemblies with local mass, stiffness for each DOF to get the nonlinear residual functional ? And how does this operation scale in parallel ? I pose this question since the matrixfree algorithm will not involve any kind of assembling routine at all. All it would need is to know the local h, p, and basis type to compute local mass, stiffness matrices to compute the local residual (a value in the global residual vector corresponding to the unknown). Also, I perfectly understand your concern about creating a global preconditioner matrix for this method to be successful but I believe that a framework can be written well to handle the matrixfree algorithm in a purely recursive fashion thereby eliminating any need for a preconditioner matrix. Just my 2 cents. Any pointers to benchmark studies that you have done in the past regarding the speed and scalability for different kinds of problems (diffusion, convection dominated) would also be very useful to me. I would be happy to contribute to a sample code regarding a matrixfree scheme with LibMesh and PETSc which will give me an opportunity to test out different techniques I have in mind. I will be playing around with LibMesh in the coming few weeks and hope to write a pilot code soon. So if you have any suggestions or comments, please feel free to email me about them. Vijay Original Message From: Benjamin Kirk [mailto:benjamin.kirk@...] Sent: Friday, December 14, 2007 12:46 PM To: Vijay M; libmeshusers@...; Roy Stogner; John Peterson; Derek Gaston Subject: Re: [Libmeshusers] Support for Matrixfree algorithms > I am currently looking for a library that can work well with PETSc and can > provide me an FEM framework to handle a set of coupled nonlinear PDEs in 2 > and 3 dimensions. > > I hope to compare the usability of LibMesh and Deal II for this purpose. Glad to help! > 2) What additional code changes would a user be required to make in order to > get matrixfree solution algorithms to work with LibMesh ? For example, only > local assemblies need be performed and global assemblies that require matrix > to be stored are not needed. For an iterative linear Krylov solve, this > would be done at every matvec product request. I'll go ahead and comment on this one... I assume you would like to compute the action of the matrixvector product in some Krylov subspace method? PETSc provides support for the notion of 'userprovided' matrix vector product, where the user returns the result y=Kx given the vector x. In the PETSc nonlinear solvers (which we support but there is no explicit example using them at the moment) the user can provide a 'residual' function which can be used to perform matrixfree newtonkrylov simulations. In libMesh this is as simple as providing a residual function and then using the ksp_matrix_free or ksp_mf_operator (I think) options to PETSc. Of course, you will still need to come up with a quality preconditioner to use such a scheme, and doing so may still require a matrix, depending on your PDE. > If somebody can provide me with some pointers for the scalability results > and possibly a sample code for even a simple 1D diffusion problem, that > would be fantastic. I could probably be persuaded to add ex19 for this purpose, it is well overdue. John/Roy/Derek, if y'all could point me to a LaplaceYoung matrix assembly routine this would be a good case to build the example on! Ben No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.17.2/1184  Release Date: 12/14/2007 11:29 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.17.2/1184  Release Date: 12/14/2007 11:29 AM 
From: Benjamin Kirk <benjamin.kirk@na...>  20071214 18:47:01

> I am currently looking for a library that can work well with PETSc and can > provide me an FEM framework to handle a set of coupled nonlinear PDEs in 2 > and 3 dimensions. > > I hope to compare the usability of LibMesh and Deal II for this purpose. Glad to help! > 2) What additional code changes would a user be required to make in order to > get matrixfree solution algorithms to work with LibMesh ? For example, only > local assemblies need be performed and global assemblies that require matrix > to be stored are not needed. For an iterative linear Krylov solve, this > would be done at every matvec product request. I'll go ahead and comment on this one... I assume you would like to compute the action of the matrixvector product in some Krylov subspace method? PETSc provides support for the notion of 'userprovided' matrix vector product, where the user returns the result y=Kx given the vector x. In the PETSc nonlinear solvers (which we support but there is no explicit example using them at the moment) the user can provide a 'residual' function which can be used to perform matrixfree newtonkrylov simulations. In libMesh this is as simple as providing a residual function and then using the ksp_matrix_free or ksp_mf_operator (I think) options to PETSc. Of course, you will still need to come up with a quality preconditioner to use such a scheme, and doing so may still require a matrix, depending on your PDE. > If somebody can provide me with some pointers for the scalability results > and possibly a sample code for even a simple 1D diffusion problem, that > would be fantastic. I could probably be persuaded to add ex19 for this purpose, it is well overdue. John/Roy/Derek, if y'all could point me to a LaplaceYoung matrix assembly routine this would be a good case to build the example on! Ben 
From: Vijay M <unknownreference@gm...>  20071214 18:31:06

Hi all, I am currently looking for a library that can work well with PETSc and can provide me an FEM framework to handle a set of coupled nonlinear PDEs in 2 and 3 dimensions. I hope to compare the usability of LibMesh and Deal II for this purpose. I have already installed LibMesh with the current version of PETSc on an OCS cluster. Since the number of DOFs for my system can be in the order of millions, it becomes important to ask two primary questions: 1) Are there any benchmark results for LibMesh while using with PETSc ? To rephrase that question, how does LibMesh scale with the problem ? (Weak scaling) 2) What additional code changes would a user be required to make in order to get matrixfree solution algorithms to work with LibMesh ? For example, only local assemblies need be performed and global assemblies that require matrix to be stored are not needed. For an iterative linear Krylov solve, this would be done at every matvec product request. If somebody can provide me with some pointers for the scalability results and possibly a sample code for even a simple 1D diffusion problem, that would be fantastic. Thanks in advance for all your help. Vijay No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.17.2/1184  Release Date: 12/14/2007 11:29 AM 
From: Roy Stogner <roystgnr@ic...>  20071214 03:21:20

On Fri, 14 Dec 2007, Ali  wrote: > I need to solve some saddlepoint problems which, consequently, need > the use of mixed finite elements (in this case pressure and velocity > in NavierStokes equation). One way of doing this is by TaylorHood > elements. > >  Is this method already implemented in libmesh? Yes. A couple of of the examples solve NavierStokes with biquadratic Lagrange velocity elements coupled to bilinear pressure elements.  Roy 
From: Ali  <saveez@ho...>  20071214 03:18:03

Hi, I need to solve some saddlepoint problems which, consequently, need the us= e of mixed finite elements (in this case pressure and velocity in NavierSt= okes equation). One way of doing this is by TaylorHood elements.  Is this method already implemented in libmesh?  If not, what would be the best way of extending libmesh to include this f= eature? _________________________________________________________________ Fancy some celeb spotting?=20 https://www.celebmashup.com= 
From: <sl@cn...>  20071211 03:20:31

uanTpqO6vPSw5bv6oaLV283ku/qhor7tsOW7+qGis+W0sqGi0KPGvbv6DQqwsrvVyqHI/cGmu/q0 stbG1OzT0M/euavLvqOsyvSwsrvVyqHD+8XGoaLD4rzssvrGt8n6svrG89K1o6ywsrvVyqG439DC vLzK9cbz0rWjrMLtsLDJvcrQobDXqKGivquhoszYoaLQwqGxxvPStaOswu2wsMm9ytDPwrjayqfS tdawuaTU2b7N0rW7+bXYo6y96dPaxM++qaGizt+6/tauvOSjrNf4wuTU2tb4w/u1xLjWs8fC7bCw yb3K0KOst+G4u7XEuNbM+tfK1LTOqrmry761xLei1bnM4bmpwcu1w8zstsC68bXE08XKxqGjuavL vtW8tdjD5rv9MTA4MDAwxr23vcPXo6zW99Kqyfqy+qGwtPPKoqGxxcbPtcHQvPSw5bv6oaLV283k u/qhor7tsOW7+qGiv+zL2dG5waa7+qGis+W0sqGiv6q+7dCjxr27+qGi0M2yxM3kx/q7+rW2xKO+ 37XIsvrGt6Os16jStc6qur2/1aGix+G5pKGi0rG98KGiu6+5pKGivajW/sb7s7WhorXnwaahotew 5Oq1yNDQ0rXM4bmpy/nQ6NKqtcTXqNPDu/rQtbrNs8nM18nosbijrLL6xrfP+s35yKu5+rj3tdi6 zcW3w8u8sLarxM/Rx7XYx/iyotS2z/rEz7fHoaMgoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh oaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh oaG5q8u+08PP1rT6xvPStbXEudzA7be9t6ihosGi1+PT2rL6xre53MDto6zS1Mbk08XQ47XExrfW yqOs0MLTsbXEyei8xqOsus/A7bXEvNu48aOszerJxrXEytu687f+zvHTrrXDwcu547Tzv827p7XE 0rvWwrrDxsCjrLG7xsDOqrCyu9XKoaGw1ti6z82soaLK2NDF08PPyL34taXOu6GxoaKwsrvVyqGh sNb4w/vJzLHqobGhorCyu9XKoaGww/vFxrL6xrehsaGiobDG89K1vfiz9r/a18q48dakobGhoqGw Q0W5+rzKyM/WpKGxsLK71cqhxanQ0KGwQUErvLbQxdPDxvPStaGxoaKwsrvVyqGhsNPF0OOzz9DF w/HTqsbz0rWhsaGisLK71cqhobCzz9DFtaXOu6GxoaKhsMLtsLDJvcrQz8i9+LyvzOWhsaGiobDC 7bCwyb3K0NPF0OPLvdOqxvPStaGxoaKhsMLtsLDJvcrQs8/QxcTJy7DIy6GxoaKhsMLtsLDJvcrQ 0vjQ0NDFtPuzz9DF1tDQocbz0rWhsaGiobDIq7n608O7p7L6xrfWysG/wvrS4qOsytu687f+zvHC +tLiyr63trWlzruhsaGiobBBQUG8ttbKwb+zz9DFu+HUsbWlzruhsaGiobDW0Ln61srBv7n907K3 xdDExrfFxqGxoaKhsNbQufrK0LOhuavIz7Opz/rGt8XGobGhoqGwyKu5+rv6tLLKrrzRw/vTxca3 xcahsbXIyNnT/rPGusUgoaGhocirzOXUsbmk0tTPyL34tcS8vMr1us3P1rT6u6+1xLncwO3K1rbO zqrXt8fzsvrGt7XEzerDwLb4srvQuMWswaaho7mry77T2jIwMDHE6jEw1MLIq8Pmzai5/UlTTzkw MDGjujIwMDDWysG/udzA7czlz7XIz9ako6wyMDAzxOo41MLNqLn9wcvI/by2vMbBv8i3yM+jrNO1 09DX1NOqvfiz9r/ayKijrM6qzOG437L6xre/xry8tcS6rL3wwb+8sLL6xrfQ1MTco6wyMDAzxOox MtTCuavLvtPrus+3yrmk0rW089Gnus/X97PJwaLBy6Gwu/q0srmks8y8vMr10dC+v9bQ0MShsaGj MjAwNMTqV0Y2N0vK/b/YsOXBz9XbzeS7+tDCxrfJ+rL6z9/P7sS/sbvIq8qht6LVubjEuO/Or9Sx u+HF+te8zqrKoaGwyP2436Gxz+7Ev6OssqKxu8HQyOvKoaGwODYxobG8xruu1ti1472oyejP7sS/ oaO5+rzS1srBv7zs0em87NLf19y+1tPaMjAwNsTqOdTCttTO0rmry761xFFDMTJZLTSjqjMyMDDS utG5sNrKvbz0sOW7+r340NDBy7L6xrfWysG/ufq80rzgtr2z6bLpoaPO0rmry76y+sa30ru0ztDU zai5/bj3z+7WuLHqvOzR6aOss8m8qMirsr+48aOovOzR6bGouOax4LrFo7pESi0xMDU1LUQwMS1R o6mho6GhoaGhoaGhoaGhoaGhoaGhocj9waay+sa3vqvS5sfzvqujrMj9wabIy72rsru2z7+qzdij rLK7ts+0tNDCo6yyotXms8+12NS40+u4973nxfPT0dCvyta5sr34o6y5ss2st6LVuaGjDQq1pc67 o7qwsrvVyqHI/cGmu/q0stbG1OzT0M/euavLvg0Ktee7sKO6MDU1NS02NzIxMjQ5ICAgtKvV5qO6 MDU1NS02NjEyODQ4DQp3d3cuY25qY3p6LmNvbQ0Kc2xAY25qY3p6LmNvbQ0KCqGqoaqhqqGqoaqh qqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqgqhvtei0uKh v8nPw+a1xNPKvP7E2sjd0+vS1M/CzsTX1s7eudiho7G+yO28/r32z97T2rrPt6jTw82+IQq4w9PK vP7TyaG2Vm9sbGV5bWFpbNPKvP7Iurei16i80qG3yO28/reiy82ju7G7zfjT0cbAzqrX7sD3uqYK tcTTyrz+yLq3osjtvP62+LbgtM7Sqsfzxsa94qOhz9bD4rfRz8LU2KOszt7P3sqxvOTKudPDoaMK z+rH6cfrt8POys7Sw8e1xNb30rOjumh0dHA6Ly93d3cuY255c29mdC5jb20v 
From: Roy Stogner <roystgnr@ic...>  20071210 17:11:34

On Mon, 10 Dec 2007, Mladen Jurak wrote: > I've noticed that in file /numerics/type_vector.h/ (version 0.6.2) > you did not specialized class template /ScalarTraits<T>/ with > integral types. > > My question is whether this an oversight or there is a reason > for such decision. Just an oversight. It's fixed in the subversion head; we didn't bother to backport the fix to 0.6.2 but it will be included when we release 0.6.9.  Roy 
From: Mladen Jurak <jurak@ma...>  20071210 16:31:57

Dear libmesh developers, I've noticed that in file /numerics/type_vector.h/ (version 0.6.2) you did not specialized class template /ScalarTraits<T>/ with integral types. This makes code such as Point a,b,c; .... c = 2 * (a + b); illegal, and one must take care use real constants, as c = 2.0 * (a + b); My question is whether this an oversight or there is a reason for such decision. Thanks, MJurak web.math.hr/~jurak 