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}
(88) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(1) 
2
(5) 
3

4
(1) 
5
(2) 
6

7
(1) 
8
(3) 
9

10
(1) 
11
(5) 
12

13

14

15
(4) 
16
(4) 
17
(5) 
18
(9) 
19
(3) 
20
(1) 
21
(11) 
22
(2) 
23
(7) 
24
(4) 
25
(9) 
26
(2) 
27

28
(1) 
29
(4) 
30
(1) 
31



From: nelson  <nelson1977@gm...>  20050330 16:25:10

Hi list! I saw in a message about how to compute the basis value function at some point different from quadrature points the forllowing text " these are points on the master element, not points in physical space" I want to compute the value of the basis function and their gradient at the node of a tet4. I have to use the FEInterface::inverse_map or not? How to use it? What vector of point i have to pass to FE::reinit (const Elem *elem, const std::vector< Point > *const pts) thanks, nelson 
From:
<DRNSAC1SA@DRNCAD.CEA.FR>  20050329 13:54:45

ScanMail for Microsoft Exchange took action on the message. The message details were: Sender = MAILERDAEMON@...(MailDeliverySystem) Recipient(s) = libmeshusers@...; Subject = [Libmeshusers] Undelivered Mail Returned to Sender Scanning time = 03/29/2005 15:54:27 Engine/Pattern = 7.5101002/2.522.00 Action taken on message: The message body contained HTML_Netsky.P virus. ScanMail deleted the message body. Warning to recipient. ScanMail has detected a virus. 
From: MAILERDAEMON@mail.atlantisscientific.com (Mail Delivery System)  20050329 13:54:20

This is the Postfix program at host mail.atlantisscientific.com. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to <postmaster> If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program <".4070508"@atlantisscientific.com>: unknown user: ".4070508" 
From: Mark Blome <mblome@au...>  20050329 13:47:18

Hi Rolf, > > > > So it seems that  away from the singularity  the accuracy > > of the solution is pretty good, but it deteriorates at the > > node which is shared with the infinite element (at x=3D1).  Is > > that a necessity, BTW? > I noticed the same in my calculations. It seems like the solution becomes=20 inaccurate close to the nodes that are shared with the infinite elements bu= t=20 =2D astonishingly becomes accurate again at some distance to these nodes. = I=20 tried different settings for the infinite elements radial order (and=20 different polynomials), but that doesnt improve things. Also I tried, as=20 Steffen suggested, a spherical mesh (please see the two pictures attached,= =20 they show scalar cut planes through 3D calculations, the border of the mesh= =20 is where the distortions occur, in this case there are no infinite elements= =20 attached at the upper surface ), but the problem remains.=20 I'll let you know if I find out more about whats going wrong, Mark Am Dienstag, 29. M=E4rz 2005 12.02 schrieb Steffen Petersen: > > OK, what an irony: I had chosen laspack, because I had  > > wrongly  assumed that it would be the least errorprone. Now > > I am using PETSc (configuration "enablepetsc > > enablecomplex enablempi") and I think it works: The > > spherical symmetry of the solution looks very good in general > > and was perfect where I tested it (along the xaxis). > > > > Here are some example results for the real part of the > > solution along the xaxis: > > > > x ex6 cos(x)/(4*pi*x) > > 0 6.5665 Inf > > 0.0667 0.6505 1.1910 > > 0.1333 0.6000 0.5915 > > 0.2000 0.3743 0.3900 > > 0.2667 0.2840 0.2879 > > 0.3333 0.2231 0.2256 > > 0.4000 0.1818 0.1832 > > 0.4667 0.1514 0.1523 > > 0.5333 0.1278 0.1285 > > 0.6000 0.1090 0.1095 > > 0.6667 0.0934 0.0938 > > 0.7333 0.0803 0.0806 > > 0.8000 0.0691 0.0693 > > 0.8667 0.0592 0.0594 > > 0.9333 0.0506 0.0507 > > 1.0000 0.0214 0.0430 > > > > So it seems that  away from the singularity  the accuracy > > of the solution is pretty good, but it deteriorates at the > > node which is shared with the infinite element (at x=3D1).  Is > > that a necessity, BTW? > > The main reason for these inaccuracies is probably the > box shaped infinite element interface (envelope). > A spherical envelope should lead to more accurate results. > Note that you can also increase the radial order of the > infinite elements to increase the accuracy of your computations. > Regarding example 6, this can be done changing line 163 > FEType fe_type(FIRST); to FEType fe_type(FIRST, LAGRANGE, > requested_ifem_order); > The default radial order is THIRD. The infinite elements are > implemented up to order EIGHTTEENTH, which is perhaps > solely of academic use. > > Steffen > > > >  > SF email is sponsored by  The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Steffen Petersen <steffen.petersen@tu...>  20050329 10:02:43

> > OK, what an irony: I had chosen laspack, because I had  > wrongly  assumed that it would be the least errorprone. Now > I am using PETSc (configuration "enablepetsc > enablecomplex enablempi") and I think it works: The > spherical symmetry of the solution looks very good in general > and was perfect where I tested it (along the xaxis). > > Here are some example results for the real part of the > solution along the xaxis: > > x ex6 cos(x)/(4*pi*x) > 0 6.5665 Inf > 0.0667 0.6505 1.1910 > 0.1333 0.6000 0.5915 > 0.2000 0.3743 0.3900 > 0.2667 0.2840 0.2879 > 0.3333 0.2231 0.2256 > 0.4000 0.1818 0.1832 > 0.4667 0.1514 0.1523 > 0.5333 0.1278 0.1285 > 0.6000 0.1090 0.1095 > 0.6667 0.0934 0.0938 > 0.7333 0.0803 0.0806 > 0.8000 0.0691 0.0693 > 0.8667 0.0592 0.0594 > 0.9333 0.0506 0.0507 > 1.0000 0.0214 0.0430 > > So it seems that  away from the singularity  the accuracy > of the solution is pretty good, but it deteriorates at the > node which is shared with the infinite element (at x=1).  Is > that a necessity, BTW? The main reason for these inaccuracies is probably the box shaped infinite element interface (envelope). A spherical envelope should lead to more accurate results. Note that you can also increase the radial order of the infinite elements to increase the accuracy of your computations. Regarding example 6, this can be done changing line 163 FEType fe_type(FIRST); to FEType fe_type(FIRST, LAGRANGE, requested_ifem_order); The default radial order is THIRD. The infinite elements are implemented up to order EIGHTTEENTH, which is perhaps solely of academic use. Steffen 
From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20050328 15:03:09

While configuring PETSc and all its dependencies it not exactly straightforward, once it is functional it should be trivial to use libMesh with it. Laspack, at least for real numbers, should be pretty safe too, but it does not do as much errorchecking as PETSc. The complex support in laspack was added by Daniel a couple of years ago and hasn't received as much testing. Ben Original Message From: libmeshusersadmin@... [mailto:libmeshusersadmin@...] On Behalf Of Rolf Mueller Sent: Saturday, March 26, 2005 2:17 PM To: Steffen Petersen; libmeshusers@... Subject: Re: [Libmeshusers] infinite elements & complex fields Dear Steffen, thank you so much again for your kind help. On Thu, Mar 24, 2005 at 06:46:39PM +0100, Steffen Petersen wrote: > The problem is somehow related to laspack. When using PETSc everything > works fine and I get reasonable results. OK, what an irony: I had chosen laspack, because I had  wrongly  assumed that it would be the least errorprone. Now I am using PETSc (configuration "enablepetsc enablecomplex enablempi") and I think it works: The spherical symmetry of the solution looks very good in general and was perfect where I tested it (along the xaxis). Here are some example results for the real part of the solution along the xaxis: x ex6 cos(x)/(4*pi*x) 0 6.5665 Inf 0.0667 0.6505 1.1910 0.1333 0.6000 0.5915 0.2000 0.3743 0.3900 0.2667 0.2840 0.2879 0.3333 0.2231 0.2256 0.4000 0.1818 0.1832 0.4667 0.1514 0.1523 0.5333 0.1278 0.1285 0.6000 0.1090 0.1095 0.6667 0.0934 0.0938 0.7333 0.0803 0.0806 0.8000 0.0691 0.0693 0.8667 0.0592 0.0594 0.9333 0.0506 0.0507 1.0000 0.0214 0.0430 So it seems that  away from the singularity  the accuracy of the solution is pretty good, but it deteriorates at the node which is shared with the infinite element (at x=1).  Is that a necessity, BTW? Thank you once more. Happy Easter, Rolf  SF email is sponsored by  The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Libmeshusers mailing list Libmeshusers@... https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Rolf Mueller <rolfm@mi...>  20050326 20:16:54

Dear Steffen, thank you so much again for your kind help. On Thu, Mar 24, 2005 at 06:46:39PM +0100, Steffen Petersen wrote: > The problem is somehow related to laspack. When using PETSc > everything works fine and I get reasonable results. OK, what an irony: I had chosen laspack, because I had  wrongly  assumed that it would be the least errorprone. Now I am using PETSc (configuration "enablepetsc enablecomplex enablempi") and I think it works: The spherical symmetry of the solution looks very good in general and was perfect where I tested it (along the xaxis). Here are some example results for the real part of the solution along the xaxis: x ex6 cos(x)/(4*pi*x) 0 6.5665 Inf 0.0667 0.6505 1.1910 0.1333 0.6000 0.5915 0.2000 0.3743 0.3900 0.2667 0.2840 0.2879 0.3333 0.2231 0.2256 0.4000 0.1818 0.1832 0.4667 0.1514 0.1523 0.5333 0.1278 0.1285 0.6000 0.1090 0.1095 0.6667 0.0934 0.0938 0.7333 0.0803 0.0806 0.8000 0.0691 0.0693 0.8667 0.0592 0.0594 0.9333 0.0506 0.0507 1.0000 0.0214 0.0430 So it seems that  away from the singularity  the accuracy of the solution is pretty good, but it deteriorates at the node which is shared with the infinite element (at x=1).  Is that a necessity, BTW? Thank you once more. Happy Easter, Rolf 
From: Steffen Petersen <steffen.petersen@tu...>  20050326 17:19:39

You can pass the EquationSystem a MeshData pointer, e.g. EquationSystems equation_systems(mesh, &mesh_data) Afterwards it is possible to access the MeshData with e.g. MeshData& mesh_data = *(equation_systems._mesh_data) within the assemble routine. Steffen 
From: <luthi@gi...>  20050325 18:59:22

Michael Michael Povolotskyi writes: > Thank you for the unswer.<br> > That's strange that I have a rod. Probaly, the mesh generator has > errors.<br> Looking at your input file again it looks like you have two element types: 11 (1D) and 44 (2D). It might be that you constructed 1D elements first, and then joined them to a 2D element. Just deleting the blocks with element 11 (three line blocks) 1 **11** 2 1 7 2 0 0 0 1 5 and leaving the 2Delement blocks intact 13 **44** 2 1 7 4 2 6 13 7 should do the job. HTH Martin 
From: <luthi@gi...>  20050325 18:43:27

Michael Michael Povolotskyi writes: > I've got an error message when I tried to read a mesh from an *.unv file. > The mesh was generated by the program SALOME. > > The error message reads: > ERROR: UNVelement type 11 not supported. > [0] src/mesh/unv_io.C, line 887, compiled Mar 23 2005 at 09:40:48 > Abort Element 11 is a rod (from the unv documentation). In the current unv_io implementation there are only 2D and 3D elements, so this error message is not too surprising. It should be easy to add element type 11 in src/mesh/unv_io.C. Best, Martin 
From: Michael Povolotskyi <povolotskyi@in...>  20050325 18:19:34

Hello everybody, I've got an error message when I tried to read a mesh from an *.unv file. The mesh was generated by the program SALOME. The error message reads: ERROR: UNVelement type 11 not supported. [0] src/mesh/unv_io.C, line 887, compiled Mar 23 2005 at 09:40:48 Abort Thank you, Michael. ps. The mesh file reads: 1 2411 1 0 0 0 0.0000000000000000E+00 0.0000000000000000E+00 0.0000000000000000E+00 2 0 0 0 1.0000000000000000E+01 0.0000000000000000E+00 0.0000000000000000E+00 3 0 0 0 1.0000000000000000E+01 1.0000000000000000E+01 0.0000000000000000E+00 4 0 0 0 0.0000000000000000E+00 1.0000000000000000E+01 0.0000000000000000E+00 5 0 0 0 3.3333333333333335E+00 0.0000000000000000E+00 0.0000000000000000E+00 6 0 0 0 6.6666666666666670E+00 0.0000000000000000E+00 0.0000000000000000E+00 7 0 0 0 1.0000000000000000E+01 3.3333333333333335E+00 0.0000000000000000E+00 8 0 0 0 1.0000000000000000E+01 6.6666666666666670E+00 0.0000000000000000E+00 9 0 0 0 6.6666666666666661E+00 1.0000000000000000E+01 0.0000000000000000E+00 10 0 0 0 3.3333333333333330E+00 1.0000000000000000E+01 0.0000000000000000E+00 11 0 0 0 0.0000000000000000E+00 6.6666666666666661E+00 0.0000000000000000E+00 12 0 0 0 0.0000000000000000E+00 3.3333333333333330E+00 0.0000000000000000E+00 13 0 0 0 6.6666666666666670E+00 3.3333333333333339E+00 0.0000000000000000E+00 14 0 0 0 6.6666666666666661E+00 6.6666666666666679E+00 0.0000000000000000E+00 15 0 0 0 3.3333333333333339E+00 3.3333333333333330E+00 0.0000000000000000E+00 16 0 0 0 3.3333333333333321E+00 6.6666666666666661E+00 0.0000000000000000E+00 1 1 2412 1 11 2 1 7 2 0 0 0 1 5 2 11 2 1 7 2 0 0 0 5 6 3 11 2 1 7 2 0 0 0 6 2 4 11 2 1 7 2 0 0 0 2 7 5 11 2 1 7 2 0 0 0 7 8 6 11 2 1 7 2 0 0 0 8 3 7 11 2 1 7 2 0 0 0 3 9 8 11 2 1 7 2 0 0 0 9 10 9 11 2 1 7 2 0 0 0 10 4 10 11 2 1 7 2 0 0 0 4 11 11 11 2 1 7 2 0 0 0 11 12 12 11 2 1 7 2 0 0 0 12 1 13 44 2 1 7 4 2 6 13 7 14 44 2 1 7 4 7 13 14 8 15 44 2 1 7 4 8 14 9 3 16 44 2 1 7 4 6 5 15 13 17 44 2 1 7 4 13 15 16 14 18 44 2 1 7 4 14 16 10 9 19 44 2 1 7 4 5 1 12 15 20 44 2 1 7 4 15 12 11 16 21 44 2 1 7 4 16 11 4 10 1 
From: John Peterson <peterson@cf...>  20050325 14:46:04

Benjamin S. Kirk writes: > > For example, consider > > PetscMatrix<> pmat = dynamic_cast<PetscMatrix<> >(mat); > > pmat>get_mat(); > > allows you to access the PETSc Mat object directly. You can then use > the PETScGetSubMatrix commands. Actually, you can now use the SparseMatrix::create_submatrix() routine, which does that cast for you. (Still only works with PETSc, though.) John 
From: <antiga@ma...>  20050325 14:36:23

Thanks for the hint, this is exaclty what I was looking for. I'll let you know! Luca On Fri, Mar 25, 2005 at 06:33:30AM 0600, Benjamin S. Kirk wrote: > A fairly arbitrary sparsity pattern can be computed if you use the > DofMap::dof_coupling array. By default, all DOFs are considered coupled > to each other, but it sounds like for your case (in 2D) you probably > want something like this: > > u v P > 0 0 1 > 0 0 1 > 1 1 0 > > to store L & L^T in the same matrix, or just the last row for L^T? > > You should be able to modify the dof_coupling array, call > compute_sparsity, and build an appropriate matrix. > > > Note that there are more options if you know you are working with PETSc > behind the scenes. > > For example, consider > > PetscMatrix<> pmat = dynamic_cast<PetscMatrix<> >(mat); > > pmat>get_mat(); > > allows you to access the PETSc Mat object directly. You can then use > the PETScGetSubMatrix commands. > > In fact, this might be the most straightforward thing to do. You could > build a full matrix for a coupled system and then extract whatever > components you need. You then might even be able to reassemble the > full system if you want a fully coupled solver some time. > > Anyway, these are my thoughts. I know John has done some work on > special preconditioners for the Stokes system and has had to extract the > matrices you are interested in, so he could probably offer some more > suggestions. > > You might need to add some code to make your job easier, if so I'll be > happy to help any way possible. > > Ben > > > > lantiga@... wrote: > >Dear libmeshers, > > I've got an issue on how to organize my code. > > For a start, I'm implementing a pressure correction solver for the > >generalized Stokes problem. The code is now working great, the > >solution is the right one, except that it could run way faster if it > >didn't have to reassemble matrices and rhs's from scratch at each time > >step. Since I'm planning to ultimately implement a semiimplicit > >NavierStokes solver, I'll have to use a large number of time steps > >and this issue is crucial. > > The problem could be reassembled at each time step by storing the > >single matrices (mass, diffusion) and adding them to form the system > >matrix or multiplying them by a vector to form rhs terms. This would > >solve performance issues, but there's a problem. Matrices in the Stokes > >system are M, the mass matrix, S, the diffusion (laplacian) matrix, and > >L the divergence matrix (whose transpose is the gradient matrix for the > >pressure). The problem resides in L: how can I store it? It's a > >rectangular matrix, because it basically couples the velocity dofs > >with the pressure dofs. Notice that I need it even in a > >pressurecorrection scheme in order to assemble the rhs without looping > >over the elements > >constructing the pressure gradients at hand. > > Is there a way in which I can store the L matrix with the right > >sparsity pattern, or is there an easy extension to limbesh I could > >contribute? (Mind that this problem is potentially common to a lot of > >splitting schemes) > > I hope I've been clear enough, and thanks in advance for your help! > > > >Luca > > > > > > >  > SF email is sponsored by  The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers  Luca Antiga, PhD  Biomedical Technologies Laboratory Bioengineering Department, Mario Negri Institute Villa Camozzi, 24020, Ranica (BG), Italy  phone: +39 035 4535381 email: antiga@... web: http://villacamozzi.marionegri.it/~luca  
From: Michael Schindler <mschindler@us...>  20050325 13:12:08

Hello list, for an implementation of free surfaces with tension I need to move the nodes of a mesh explicitly. Once in a while the numerics gets instable due to very thin/small elements. Is there someone having written libmeshcode that takes out single elements that are too bad or inserts elements where necessary? Best greetings, Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Michael Schindler <mschindler@us...>  20050325 13:07:45

On 25.03.05, Benjamin S. Kirk wrote: > A fairly arbitrary sparsity pattern can be computed if you use the > DofMap::dof_coupling array. By default, all DOFs are considered coupled > to each other, but it sounds like for your case (in 2D) you probably > want something like this: > > u v P > 0 0 1 > 0 0 1 > 1 1 0 I needed something like this for testing purposes some time ago. Because I was not interested in a very efficient program I let Petsc compute the sparsity pattern for me which is suboptimal. I think, a framework for this is of broader interest. Best greetings, Michael  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Benjamin S. Kirk <benkirk@cf...>  20050325 12:33:42

A fairly arbitrary sparsity pattern can be computed if you use the DofMap::dof_coupling array. By default, all DOFs are considered coupled to each other, but it sounds like for your case (in 2D) you probably want something like this: u v P 0 0 1 0 0 1 1 1 0 to store L & L^T in the same matrix, or just the last row for L^T? You should be able to modify the dof_coupling array, call compute_sparsity, and build an appropriate matrix. Note that there are more options if you know you are working with PETSc behind the scenes. For example, consider PetscMatrix<> pmat = dynamic_cast<PetscMatrix<> >(mat); pmat>get_mat(); allows you to access the PETSc Mat object directly. You can then use the PETScGetSubMatrix commands. In fact, this might be the most straightforward thing to do. You could build a full matrix for a coupled system and then extract whatever components you need. You then might even be able to reassemble the full system if you want a fully coupled solver some time. Anyway, these are my thoughts. I know John has done some work on special preconditioners for the Stokes system and has had to extract the matrices you are interested in, so he could probably offer some more suggestions. You might need to add some code to make your job easier, if so I'll be happy to help any way possible. Ben lantiga@... wrote: > Dear libmeshers, > I've got an issue on how to organize my code. > For a start, I'm implementing a pressure correction solver for the > generalized Stokes problem. The code is now working great, the > solution is the right one, except that it could run way faster if it > didn't have to reassemble matrices and rhs's from scratch at each time > step. Since I'm planning to ultimately implement a semiimplicit > NavierStokes solver, I'll have to use a large number of time steps > and this issue is crucial. > The problem could be reassembled at each time step by storing the > single matrices (mass, diffusion) and adding them to form the system > matrix or multiplying them by a vector to form rhs terms. This would > solve performance issues, but there's a problem. Matrices in the Stokes > system are M, the mass matrix, S, the diffusion (laplacian) matrix, and > L the divergence matrix (whose transpose is the gradient matrix for the > pressure). The problem resides in L: how can I store it? It's a > rectangular matrix, because it basically couples the velocity dofs > with the pressure dofs. Notice that I need it even in a pressurecorrection > scheme in order to assemble the rhs without looping over the elements > constructing the pressure gradients at hand. > Is there a way in which I can store the L matrix with the right > sparsity pattern, or is there an easy extension to limbesh I could > contribute? (Mind that this problem is potentially common to a lot of > splitting schemes) > I hope I've been clear enough, and thanks in advance for your help! > > Luca > > 
From: Benjamin S. Kirk <benkirk@cf...>  20050325 12:09:39

Actually, I don't really see the utility of the MeshData class either. Daniel? I've never used it. It seems like it would be more useful to incorporate its functionality into a System or the EquationSystems class. I know one of the issues the class addresses is the possibility of different node numbering schemes between the UNV file and libMesh, but beyond that I don't really know what it is used for. Also, does it work in the case of AMR? Perhaps someone can shed some light on the situation. If not, we should question why we maintain the class. Ben Martin Lüthi wrote: > Hi > > Example 12 nicely explains how to read data from a unv file. But how > is data data actually used? If I want to access the mesh_data, I > currently see only two ways: > > a) create a MeshData object in the assemble method, and read the data > on every call to system.solve() > > b) create a MeshData object in the main method, use > MeshData.translate(), and stuff it into a vector that is attached > to the system to solve. In the assemble method this vector is > accessed. > > Method a) seems a bit unelegant, and a waste of resources for > nonlinear problems (where the solve() method is called repeadetly). > Also it is not immediately obvious how to access the data in the > element loop. > > Method b) seems more effiecient, but here I fail to see the utility of > a separate MeshData object. > > Maybe I am missing something obvious, and if so, I would appreciate > any hints. > > Thanks, Martin > > >  > SF email is sponsored by  The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: <luthi@gi...>  20050324 21:27:15

Hi Example 12 nicely explains how to read data from a unv file. But how is data data actually used? If I want to access the mesh_data, I currently see only two ways: a) create a MeshData object in the assemble method, and read the data on every call to system.solve() b) create a MeshData object in the main method, use MeshData.translate(), and stuff it into a vector that is attached to the system to solve. In the assemble method this vector is accessed. Method a) seems a bit unelegant, and a waste of resources for nonlinear problems (where the solve() method is called repeadetly). Also it is not immediately obvious how to access the data in the element loop. Method b) seems more effiecient, but here I fail to see the utility of a separate MeshData object. Maybe I am missing something obvious, and if so, I would appreciate any hints. Thanks, Martin 
From: Steffen Petersen <steffen.petersen@tu...>  20050324 17:47:01

> That's good to know. However, I am still not sure if I > interpret the results correctly: In ex6, "a unit load" is > applied "at the node located at (0,0,0)". This seems to be > done by adding 1 to the rhs vector at the position of this > node. I have looked at the results as written out by > "GMVIO(mesh).write_equation_systems". Shouldn't I see > something like 1/(4*pi*r)*exp(j*k*r), were > r=sqrt(x.^2+y.^2+z.^2) and k is the wavenumber? I have chosen > k=1 and 10 or 20 elements along each dimension in the cube > [1 1][1 1][1 1]. What I get are positive and negative > numbers in the order of magnitude of 10^42 to 10^45 or so for > both the real and imaginary parts when using 10 elements > along each dimension. For 20 elements, the magnitude of the > numbers appears to be much smaller (10^31  10^36). Besides > the values, the geometry of the solution is also different > from what I would have expected (spherical symmetry). There > is only a smear from near the center into the direction of > one cube corner.  Do you happen to see where the confusion now lies? The problem is somehow related to laspack. When using PETSc everything works fine and I get reasonable results. With disablepetsc I also obtain the (definitely) wrong results you report. I have to admit that I have not used laspack with complex numbers for quite some time. Hm, I will see if I can find the problem with the interface. Steffen > Thank you so much once again. > Rolf > >  > Rolf Mueller http://www.mip.sdu.dk/~rolfm > Maersk Institute, University of Southern Denmark > Campusvej 55, DK5230 Odense M, Denmark > Phone ++45 6550 3655 Fax. ++45 6615 7697 > > >  > This SF.net email is sponsored by: 2005 Windows Mobile > Application Contest Submit applications for Windows > Mobile(tm)based Pocket PCs or Smartphones for the chance to > win $25,000 and application distribution. Enter today at > http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: <lantiga@im...>  20050324 14:40:03

Dear libmeshers, I've got an issue on how to organize my code. For a start, I'm implementing a pressure correction solver for the generalized Stokes problem. The code is now working great, the solution is the right one, except that it could run way faster if it didn't have to reassemble matrices and rhs's from scratch at each time step. Since I'm planning to ultimately implement a semiimplicit NavierStokes solver, I'll have to use a large number of time steps and this issue is crucial. The problem could be reassembled at each time step by storing the single matrices (mass, diffusion) and adding them to form the system matrix or multiplying them by a vector to form rhs terms. This would solve performance issues, but there's a problem. Matrices in the Stokes system are M, the mass matrix, S, the diffusion (laplacian) matrix, and L the divergence matrix (whose transpose is the gradient matrix for the pressure). The problem resides in L: how can I store it? It's a rectangular matrix, because it basically couples the velocity dofs with the pressure dofs. Notice that I need it even in a pressurecorrection scheme in order to assemble the rhs without looping over the elements constructing the pressure gradients at hand. Is there a way in which I can store the L matrix with the right sparsity pattern, or is there an easy extension to limbesh I could contribute? (Mind that this problem is potentially common to a lot of splitting schemes) I hope I've been clear enough, and thanks in advance for your help! Luca  Luca Antiga, PhD  Biomedical Technologies Laboratory Bioengineering Department, Mario Negri Institute Villa Camozzi, 24020, Ranica (BG), Italy  phone: +39 035 4535381 email: antiga@... web: http://villacamozzi.marionegri.it/~luca  
From: Michael Povolotskyi <povolotskyi@in...>  20050324 14:28:54

Hello everybody, I have to solve a variational problem: to minimize a functional \int L(y,y',x,a) dx that depends on function y(x) and a parameter a (real number). In this case the problem is reduced to a Lagrange equation for y(x) and to the equation \int \frac{dL(y,y,x.a)}{da} dx = 0. In this case I should have one more degree of freedom that in not related to mesh. My question: is it possible in Libmesh to add a new degree of freedom? Thank you, Michael. 
From: John Peterson <peterson@cf...>  20050323 16:39:29

Thanks! Open source strikes again. I wish we could start offering bounties for bugs like Gnome does... :) John lantiga@... writes: > Dear libmesh people, > I found what seems to be a bug in 4th and 5th order Gauss > quadrature rules for Tet10 elements. I don't have the Zienkiewicz > book, so I can't check on the reference given in the code, however > I'm referring to P. Keast, "Moderatedegree tetrahedral quadrature > formulas", Comp Meth Appl Mech and Eng, vol 55:339348 (1986). I > found this while implementing a Stokes solver and running it with > TaylorHood Tet10 elements. I was getting weird errors with a > FOURTH and FIFTH Gauss quadrature order, which disappeared when I > used the SIXTH order one (tensorproduct rule). The errors finally > vanished when I introduced the corrections below. 
From: John Peterson <peterson@cf...>  20050323 16:08:17

Michael Povolotskyi writes: > > > This code can not be compiled. > I had to change to > > MeshBase::const_element_iterator el3 = mesh.level_elements_begin(0); > MeshBase::const_element_iterator end_el3 = mesh.level_elements_end(0); > > > Is this a correct solution? If "mesh" is a constant reference in this case, then I believe that is correct. Consider #include <vector> void f(const std::vector<int>& v) { // std::vector<int>::iterator it = v.begin(); // error! std::vector<int>::const_iterator cit = v.begin(); // ok. } int main() { std::vector<int> v(10); f(v); return 0; } John 
From: Benjamin S. Kirk <benkirk@cf...>  20050323 13:21:58

Thank you very much! I either caused the error in the original implementation or the book has an error. Either way, good catch. Let me apologize for wasting your time, this is a bug you shouldn't have had to find. If I was rigorous about writing unit tests I'd put together some code assuring that all our quadrature rules can integrate polynomials of the required degrees accurately, but that would leave no time to implement new features! Does the paper you reference happen to have any rules that aren't implemented in the library? I'm not on campus right now, otherwise I'd head over to the library and check. Ben lantiga@... wrote: > Dear libmesh people, > I found what seems to be a bug in 4th and 5th order Gauss quadrature rules for Tet10 elements. > I don't have the Zienkiewicz book, so I can't check on the reference given in the code, however I'm referring to P. Keast, "Moderatedegree tetrahedral quadrature formulas", Comp Meth Appl Mech and Eng, vol 55:339348 (1986). > I found this while implementing a Stokes solver and running it with TaylorHood Tet10 elements. > I was getting weird errors with a FOURTH and FIFTH Gauss quadrature order, which disappeared when I used the SIXTH order one (tensorproduct rule). The errors finally vanished when I introduced the corrections below. > > In particular, in file src/quadrature/quadrature_3D.C, > > case FOURTH: > { > ... > points[5](0) = a; > points[5](1) = a; > points[5](2) = a; > ... > points[10](0) = b; > points[10](1) = b; > points[10](2) = b; > ... > } > > should be instead > > case FOURTH: > { > ... > points[5](0) = b; > points[5](1) = a; > points[5](2) = a; > ... > points[10](0) = a; > points[10](1) = b; > points[10](2) = a; > ... > } > > Similarly, > > case FIFTH: > { > ... > points[9](0) = a; > points[9](1) = a; > points[9](2) = a; > ... > points[14](0) = b; > points[14](1) = b; > points[14](2) = b; > ... > } > > should be instead > > case FIFTH: > { > ... > points[9](0) = b; > points[9](1) = a; > points[9](2) = a; > ... > points[14](0) = a; > points[14](1) = b; > points[14](2) = a; > ... > } > > > Luca > > 
From: Benjamin S. Kirk <benkirk@cf...>  20050323 13:16:54

That is perfectly acceptable. I'm guessing in this case you have a const Mesh& and it won't let you access the nonconst build member. Ben Michael Povolotskyi wrote: > > > > KIRK, BENJAMIN (JSCEG) (NASA) wrote: > >> It does now: >> >> MeshBase::element_iterator it = mesh.level_elements_begin(0); >> MeshBase::element_iterator end = mesh.level_elements_end(0); >> >> Ben >> >> > This code can not be compiled. > I had to change to > > MeshBase::const_element_iterator el3 = mesh.level_elements_begin(0); > MeshBase::const_element_iterator end_el3 = mesh.level_elements_end(0); > > > Is this a correct solution? > Michael. > > > >  > This SF.net email is sponsored by: 2005 Windows Mobile Application Contest > Submit applications for Windows Mobile(tm)based Pocket PCs or Smartphones > for the chance to win $25,000 and application distribution. Enter today at > http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 