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

2

3

4

5

6

7
(4) 
8
(1) 
9

10

11

12

13

14

15
(3) 
16
(1) 
17

18

19

20

21

22

23

24

25

26

27

28

29

30
(1) 



From: Benjamin S. Kirk <benkirk@cf...>  20051130 04:29:44

The new wiki is now online. Many thanks to John for grabbing all he could from our old site before it was lost during the mysql update. Also, I think I fixed the annoying problem of not being able to save changes while logged in. Seems there was an issue with PHP sessions on the Sourceforge web server farm. Anyway, seems to work now. Give it a shot and let the content roll in! Ben 
From: Min Xu <minxu@sc...>  20051116 01:41:40

Thanks Roy. I am afraid that the quick fix may not apply to my situation where the mesh the coefficient sits on is different from that of the solution. If I dig further, the line causing the error is line 227 of mesh_function.C 214 FEComputeData data (this>_eqn_systems, mapped_point); 215 216 FEInterface::compute_data (dim, fe_type, element, data); 217 218 // where the solution values for the varth variable are stored 219 std::vector<unsigned int> dof_indices; 220 this>_dof_map.dof_indices (element, dof_indices, var); 221 222 // interpolate the solution 223 { 224 Number value = 0.; 225 226 for (unsigned int i=0; i<dof_indices.size(); i++) 227 value += this>_vector(dof_indices[i]) * data.shape[i]; 228 229 output(index) = value; 230 } The reported error pointing to line 227 at dof_indices[i]. Anything wrong here in the code when it is executed in a parallel environment? It looks to me that MeshFunction should handle the parallel scenario well. The problem is that the way that _vector is distributed over the processors may be different from the solution vector. A quick fix, I think, is to use a serial version of the coefficient alpha. As the variable alpha points to the dummy solution vector of the AlphaEquationSystems. My question is then: Can one force an EquationSystem to use a serial vector for its solution in a parallel environment? Thanks again. Min believe that MeshFunction On Tuesday 15 November 2005 14:56, Roy Stogner wrote: > On Tue, 15 Nov 2005, Min Xu wrote: > > PetscVector<T>::operator()(unsigned int) const [with T = Real]: Assertion > > `((i >= this>first_local_index()) && (i < this>last_local_index()))' > > failed. > > > > The error traced back to the line marked (1) above when invoking > > alphaMeshFuncPtr. > > > > Any idea? > > On first glance, it appears possible to me that the only data vectors > being properly redistributed with the parallel mesh are the vectors > registered with add_vector(), and the data vector used internally by > MeshFunction is not one of these. > > However, MeshFunction does have access to the EquationSystems object > in its constructor, so if we were to add the restriction that > MeshFunctions had to be created at initialization time, we could make > it use a registered vector without much trouble. > > > I am stuck with this problem for while already. Any help will be greatly > > appreciated. > > I don't want to muck around with a fix for MeshFunction until I hear > from Ben, who understands the PETSc issues much better than I do. > > If you don't want to wait for an official fix, it's possible (and in > most cases more efficient, if you're just taking function values at > the usual quadrature points) to duplicate the MeshFunctionality > yourself, by doing an add_vector() manually and doing the sum of > coefficients times shape functions in your own code. >  > Roy Stogner > > >  > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Roy Stogner <roystgnr@ic...>  20051115 19:56:31

On Tue, 15 Nov 2005, Min Xu wrote: > PetscVector<T>::operator()(unsigned int) const [with T = Real]: Assertion > `((i >= this>first_local_index()) && (i < this>last_local_index()))' > failed. > > The error traced back to the line marked (1) above when invoking > alphaMeshFuncPtr. > > Any idea? On first glance, it appears possible to me that the only data vectors being properly redistributed with the parallel mesh are the vectors registered with add_vector(), and the data vector used internally by MeshFunction is not one of these. However, MeshFunction does have access to the EquationSystems object in its constructor, so if we were to add the restriction that MeshFunctions had to be created at initialization time, we could make it use a registered vector without much trouble. > I am stuck with this problem for while already. Any help will be greatly > appreciated. I don't want to muck around with a fix for MeshFunction until I hear from Ben, who understands the PETSc issues much better than I do. If you don't want to wait for an official fix, it's possible (and in most cases more efficient, if you're just taking function values at the usual quadrature points) to duplicate the MeshFunctionality yourself, by doing an add_vector() manually and doing the sum of coefficients times shape functions in your own code.  Roy Stogner 
From: Min Xu <minxu@sc...>  20051115 19:45:16

Note: I found out that portion of my message does not show up in the mailinglist web interface. So I resent the message. Dear developers and users of libmesh: I am solving a PDE with its coefficient defined on a mesh and I used MeshFunction to store the value of the coefficient. The relevant code are following where the coefficient is the variable alpha. In main(): // Map the solution data to MeshFunction MeshFunction alphaMeshFunc = MeshFunction(alpha_equation_systems, alpha_and_gradient, alpha_dof_map, 0 // var_id=0 for alpha ); // build the MeshFunction ready for use. alphaMeshFunc is valid even when // alpha is updated. alphaMeshFunc needs clear and init when the mesh changes. alphaMeshFunc.init(); // assign to the global variable alphaMeshFuncPtr = &alphaMeshFunc; In the assemble routine: for (unsigned int qp=0; qp<qrule.n_points(); qp++) { double alphav = (*alphaMeshFuncPtr)(q_points[qp]); (1) ... } The program works without any error in the serial mode. When I submit the program to a linux cluster, the following errors occurred: /home/m254/minxu/libmesh/include/numerics/petsc_vector.h:693: T PetscVector<T>::operator()(unsigned int) const [with T = Real]: Assertion `((i >= this>first_local_index()) && (i < this>last_local_index()))' failed. The error traced back to the line marked (1) above when invoking alphaMeshFuncPtr. Any idea? I am stuck with this problem for while already. Any help will be greatly appreciated. Thanks! Min 
From: Min Xu <minxu@sc...>  20051115 16:29:59

Dear developers and users of libmesh: I am solving a PDE with its coefficient defined on a mesh and I used MeshFunction to store the value of the coefficient. The relevant code are following where the coefficient is the variable alpha. In main(): // Map the solution data to MeshFunction MeshFunction alphaMeshFunc = MeshFunction(alpha_equation_systems, alpha_and_gradient, alpha_dof_map, 0 // var_id=0 for alpha ); // build the MeshFunction ready for use. alphaMeshFunc is valid even when // alpha is updated. alphaMeshFunc needs clear and init when the mesh changes. alphaMeshFunc.init(); // assign to the global variable alphaMeshFuncPtr = &alphaMeshFunc; In the assemble routine: for (unsigned int qp=0; qp<qrule.n_points(); qp++) { double alphav = (*alphaMeshFuncPtr)(q_points[qp]); .......(*) ... } The program works without any error in the serial mode. When I submit the program to a linux cluster, the following errors occurred: /home/m254/minxu/libmesh/include/numerics/petsc_vector.h:693: T PetscVector<T>::operator()(unsigned int) const [with T = Real]: Assertion `((i >= this>first_local_index()) && (i < this>last_local_index()))' failed. The error traced back to the line marked (*) above when invoking alphaMeshFuncPtr. Any idea? I am stuck with this problem for while already. Any help will be greatly appreciated. Thanks! Min 
From: <jcch@ma...>  20051108 14:45:42

I need to read/write the numerical solution for my transient Euler solver. I am using discontinuous finite elements and I would like to know how this is usually done in libmesh. Thanks in advance. Joao Henriques 
From: Roy Stogner <roystgnr@ic...>  20051107 18:48:02

On Mon, 7 Nov 2005, Guillaume ANCIAUX wrote: > why do you make the difference with the solution vector ? there is a > privileged communication process for it ? Ben Kirk really needs to jump in on this discussion. To the best of my knowledge there's no longer anything special about the solution vector with regards to projections and parallel computations, but Ben did the latter work and I haven't really looked into it. > nevertheless for that kind of operations (even for solution vector) do you > need to send the complete vector to your neighbors ? this would be pretty > much non scalable (my opinion). That depends on how often you need to do the vector send. It would be nonscalable for an explicit algorithm, but (assuming you only need to synchronize once or twice per timestep) not a big problem for an implicit code. Even if some of the primary developers were doing explicit calculations, I don't think this would be a high priority  shape function caching would make a much bigger improvement in our runtimes. > Interpolation is not a key operation in the FE programs ? (i'm kind > of newbie in that). It depends on what you mean by interpolation. Interpolation between different grids is important for adaptive (and vital for adaptive timedependent) problems. Interpolation between grid points is key for any FE code using better than discontinuous constant elements, but it's simply what we do by evaluating shape functions at quadrature points. > I need to compute a deformation gradient on quadrature points > (\sum_I \dphi_I(X) u_I) to compute a non linear behavior at each > explicit step. That's right. > i know i can compute dphi and phi shapes functions locally as long > as they are precomputed from reference element projection... but i > really need to get the nodes values (u_I) ... if it implies sending > the complete vector ... :( I don't think you want to get the nodes' values  what if you're using higher order elements whose shape functions are determined by more complicated bases? Let the shape function calculations do the work for you. > maybe i didn't get something... Take a look at example 13. I believe it does what you need to do; at each quadrature point there's this loop: for (unsigned int l=0; l<n_u_dofs; l++) { u_old += phi[l][qp]*stokes_system.old_solution (dof_indices_u[l]); v_old += phi[l][qp]*stokes_system.old_solution (dof_indices_v[l]); grad_u_old.add_scaled (dphi[l][qp],stokes_system.old_solution (dof_indices_u[l])); grad_v_old.add_scaled (dphi[l][qp],stokes_system.old_solution (dof_indices_v[l])); u += phi[l][qp]*stokes_system.current_solution (dof_indices_u[l]); v += phi[l][qp]*stokes_system.current_solution (dof_indices_v[l]); grad_u.add_scaled (dphi[l][qp],stokes_system.current_solution (dof_indices_u[l])); grad_v.add_scaled (dphi[l][qp],stokes_system.current_solution (dof_indices_v[l])); } This calculates both values and gradients of the last timestep's velocity and the current timestep's current velocity estimate. Presumably you can perform the same sort of calculation to get whatever function of your solution and its derivatives that you need.  Roy Stogner 
From: Guillaume ANCIAUX <anciaux@la...>  20051107 17:08:14

why do you make the difference with the solution vector ? there is a=20 privileged communication process for it ?=20 nevertheless for that kind of operations (even for solution vector) do you= =20 need to send the complete vector to your neighbors ? this would be pretty=20 much non scalable (my opinion). Interpolation is not a key operation in the FE programs ? (i'm kind of newb= ie=20 in that). I need to compute a deformation gradient on quadrature points=20 (\sum_I \dphi_I(X) u_I) to compute a non linear behavior at each explicit=20 step. i know i can compute dphi and phi shapes functions locally as long as they= =20 are precomputed from reference element projection... but i really need to g= et=20 the nodes values (u_I) ... if it implies sending the complete vector ... :( maybe i didn't get something... thanks for your advices. Le Lundi 7 Novembre 2005 15:56, vous avez =E9crit=A0: > Hi, > > If I understand correctly, you want to communicate a field variable > (other than the current solution) involving only the minimum amount > of data required (i.e. values at the ghost nodes). I think you will > obtain the desired effect for any vector which is added to the system > using the "System::add_vector()" routine. However, I believe this > involves communicating all the values in the vector, not just those > for the ghost nodes... > > J > > Guillaume ANCIAUX writes: > > I wonder if there is a way to get a field (described by a shared > > NumericVector) interpolated in a finest way that localizing the shared > > vector. I mean by doing only the necessary communication in order to g= et > > the ghosts values .... > > > > This method should be on a system fonctionality but i can't find it ..= =2E. > > > > Anyone could give me help ? > > > > Thx... 
From: John Peterson <peterson@cf...>  20051107 14:56:26

Hi, If I understand correctly, you want to communicate a field variable (other than the current solution) involving only the minimum amount of data required (i.e. values at the ghost nodes). I think you will obtain the desired effect for any vector which is added to the system using the "System::add_vector()" routine. However, I believe this involves communicating all the values in the vector, not just those for the ghost nodes... J Guillaume ANCIAUX writes: > I wonder if there is a way to get a field (described by a shared > NumericVector) interpolated in a finest way that localizing the shared > vector. I mean by doing only the necessary communication in order to get the > ghosts values .... > > This method should be on a system fonctionality but i can't find it .... > > Anyone could give me help ? > > Thx... 
From: Guillaume ANCIAUX <anciaux@la...>  20051107 11:46:05

I wonder if there is a way to get a field (described by a shared=20 NumericVector) interpolated in a finest way that localizing the shared=20 vector. I mean by doing only the necessary communication in order to get th= e=20 ghosts values .... This method should be on a system fonctionality but i can't find it .... Anyone could give me help ? Thx... =2D=20 Guillaume ANCIAUX Tel : 06 89 29 11 50=20 LaBRI, Universit=E9 Bordeaux I (+33)5 40 00 38 21 (bureau)=20 351, Cours de la Lib=E9ration anciaux@...=20 33405 TALENCE Cedex, FRANCE http://deptinfo.labri.fr/~anciaux 