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}
(12) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2

3

4

5
(10) 
6
(6) 
7
(6) 
8
(3) 
9

10

11
(19) 
12
(6) 
13
(21) 
14
(1) 
15

16

17
(6) 
18
(7) 
19
(5) 
20
(3) 
21
(2) 
22

23
(2) 
24
(5) 
25
(1) 
26

27
(2) 
28
(2) 
29
(11) 
30
(1) 






From: Benjamin Kirk <benjamin.kirk@na...>  20081107 17:31:17

> I'm not sure if this is a stupid question but I'm not entirely sure as > to how you would find the nonzeros per row in a DG discretization. > This is not obvious to me since in say an advection system, the flux > at the boundaries couple the dofs in one cell to the next. And hence, > the dof_map does not have any idea about this discretization or > coupling of variables. In the continuous FEM case, the dof_map does > provide the connectivity correctly since the mesh_nodes are the dofs > in the discretization. In DG discretizations the degrees of freedom in any given element are typically coupled to all the degrees of freedom in its faceneighbors. > Any ideas as to how I can possibly access the location of nonzeros per > row by just looking at the final assembled matrix ? I saw that there > is a update_sparsity_pattern routine in SparseMatrix but this is not > overloaded in PetscMatrix. I guess I am looking for something like the > sparsity_pattern object, or am I way off on my interpretation of what > this means ? The DofMap will add all face neighbor degrees of freedom to an element's coupled dofs if (1) all the variables in the system are discontinuous, or (2) the command line option 'implicit_neighbor_dofs' is specified. The role of the sparsity pattern is to define the graph structure of the system matrix. So, the DofMap builds this graph, and then passess it off to any associated matrices. It is then destroyed because it takes a fair bit of memory and, in theory, should not be needed after the matrices are reinitialized with the proper structure. In the case of PETSc it does not actually need the graph of the matrix  the number of on and offprocessor nonzeros per row will suffice. Of course, internal to the DofMap the sparsity pattern is computed anyway to get this information. If you look in the laspack and trilinos matrix implementations you will see where the sparsity pattern is actually used. Hope this helps, Ben 
From: Vijay S. Mahadevan <vijay.m@gm...>  20081107 16:35:59

Hi, I'm not sure if this is a stupid question but I'm not entirely sure as to how you would find the nonzeros per row in a DG discretization. This is not obvious to me since in say an advection system, the flux at the boundaries couple the dofs in one cell to the next. And hence, the dof_map does not have any idea about this discretization or coupling of variables. In the continuous FEM case, the dof_map does provide the connectivity correctly since the mesh_nodes are the dofs in the discretization. Any ideas as to how I can possibly access the location of nonzeros per row by just looking at the final assembled matrix ? I saw that there is a update_sparsity_pattern routine in SparseMatrix but this is not overloaded in PetscMatrix. I guess I am looking for something like the sparsity_pattern object, or am I way off on my interpretation of what this means ? Thank you very much for any help in advance. Vijay 
From: Vijay S. Mahadevan <vijay.m@gm...>  20081107 15:51:10

Hi there, Before I even start, I know this is probably going to be a loaded question, but nevertheless, any help would be appreciated. Background: I'm working on solution to large scale PDE systems based on libmesh for discretization and petsc for solution procedures. My physics objects are derived from EquationSystems in libmesh datastructure and can contain one or more implicitsystems in it. I use the JacobianFree Krylov scheme for my nonlinear solve and hence the efficiency of the method is achieved from good preconditioning. I've tried using ILU to precondition my preconditioner (linearized version) of the original nonlinear system and this works well for serial runs. But this does not scale when I run in parallel. So my questions are 1) Is it is possible to use libmesh objects to perform geometric multigrid preconditioning and completely avoid the matrix creation except in the coarsest case ?! I've seen some of Ben's presentation that mentions using multigrid for stokes problems etc. and so am curious as to what this would entail ... For example, would I have to create multiple equationsystems object since the mesh is not associated with just the system. Hence for every multigrid level, I would have a new instance of the physics system but on a coarser mesh level. Is this how you would possibly implement this ?! 2) If I can afford to create the matrix in the finest level, can we use algebraic multigrid procedures to precondition this system in parallel ? Anyone know how this scales ? 3) Also, I was reading about Prometheus (http://www.columbia.edu/~ma2325/prom_intro.html) and it looks promising as both a blackbox solver and preconditioner when the matrix is available and geometric multigrid in 2D (not sure about 3D). Has anyone in this list used this package with Petsc and/or libMesh ?! Again, like I said before, there is a lot of things here you can comment on. Feel free to write your thoughts because I want to get as much input as possible before choosing anything specific. Thanks, Vijay 
From: Roy Stogner <roystgnr@ic...>  20081106 01:29:02

On Wed, 5 Nov 2008, Kirk, Benjamin (JSCEG) wrote: > If both PETSc and Trilinos allow the user to manage the local element > storage, that could certainly be exploited for performance. operator(i) > would be inline Good. > with some error checking (in debug/devel mode only) > and then return _val[iifirst] or something like that... no > embedded function call. We would still let > PETSc do summation to remote values and that sort of thing. > > Can you see if trilinos would allow something like this? If so, I'd like > to do it. So your proposal is "Let's implement this performance improvement that we should have done years ago, and I'll do all the work"? I can see how that last clause might qualify as "batshit crazy" from your perspective, but it sounds great to me!  Roy 
From: Roy Stogner <roystgnr@ic...>  20081106 00:56:12

On Wed, 5 Nov 2008, Kirk, Benjamin (JSCEG) wrote: > Yeah, of course you're right... For only a tiny bit of library code > we can put together something that might be quite useful. So, what > do you think about something like > > std:pair<unsigned int, unsigned int> local_dof_index_range = > DofMap::local_dof_index_range (unsigned int var_num = 1); > > (where I have obviously taken some liberty combining a function call with its prototype)? > > When called without a var_num argument we just return > > std::make_pair(first_local_index, last_local_index); > > otherwise the relevant bounds for var_num? Assuming relevant bounds exist. Return (1, 1) when they don't? Sounds good, anyway.  Roy 
From: Kirk, Benjamin (JSCEG) <Benjamin.K<irk1@na...>  20081106 00:52:46

I see your nutty and raise you batshit crazy: PETSc allows you to provide your own buffer for storing the local elements when you create a vector... Does Trilinos have something similar? If so, I propose we take the implementation in DistributedVector, push it down into NumericVector, and beef it up. If both PETSc and Trilinos allow the user to manage the local element storage, that could certainly be exploited for performance. operator(i) would be inline with some error checking and then return _val[iifirst] or something like that... no embedded function call. We would still let PETSc do summation to remote values and that sort of thing. Can you see if trilinos would allow something like this? If so, I'd like to do it. I've resisted implementing a sparse parallel matrix, not so much because it is hard but more because that seems like a slippery slope to writing Krylov solvers and, ultimately parallel preconditioners... All of which are wheels we need not reinvent. But this? Why not... Ben Original Message From: Derek Gaston [mailto:friedmud@...] Sent: Wed 11/5/2008 6:27 PM To: Roy Stogner Cc: Kirk, Benjamin (JSCEG); libmeshusers@... Subject: Re: [Libmeshusers] Norm of a NumericVector for specific variable... So... after hashing this out with some people around here... I'm now thinking that the vector multiply and call linear algebra package norm is a bad idea. Firstly, we have some systems where we're solving up to 9 variables! That means we'd have to do all of that stuff every time.... not too mention wasting memory with all of the zeroes hanging around in that vector.... I'm thinking now of a NumericVector::subset_norm() that takes a std::set of the local dof indices to perform the norm on and a norm type (or we could make separate norm functions... either way). The std::set could easily be created in System::calculate_norm() for each variable that you want the discrete norm for and then call subset_norm() the appropriate number of times. And here's where it gets nutty: we just do our own damn norm calculation. It's not like it's rocket science. We do it right in NumericVector using the interface functions (like operator() ) so that every NumericVector gets this capability. What do you think? Derek On Nov 5, 2008, at 5:03 PM, Roy Stogner wrote: > > > On Wed, 5 Nov 2008, Kirk, Benjamin (JSCEG) wrote: > >> Could the api allow you to specify the indices from userspace? The >> reason I ask is because if all your variables are the same type it >> is pretty easy to figure out the range from the first_local_index, >> last_local_index, n_vars, and var_num. >> >> That's a little hackish to do inside the library... > > A *little* hackish? No, requiring the command line option > "node_major_dofs" to use that coefficient numbering, that was a > little hackish. *Breaking* that option (as well as TaylorHood > elements, etc.) would be a *lot* hackish. ;) > > But as an optimization which could fall back on my more general code, > it's a very good idea. Use NumericVector::subrange_norm() only if > we're using varmajor numbering, and have the DofMap cache the > first_local_index_var[n] for each variable so we get the range limits > right even if there's differing FE types in use. >  > Roy 
From: Derek Gaston <friedmud@gm...>  20081106 00:29:14

So... after hashing this out with some people around here... I'm now thinking that the vector multiply and call linear algebra package norm is a bad idea. Firstly, we have some systems where we're solving up to 9 variables! That means we'd have to do all of that stuff every time.... not too mention wasting memory with all of the zeroes hanging around in that vector.... I'm thinking now of a NumericVector::subset_norm() that takes a std::set of the local dof indices to perform the norm on and a norm type (or we could make separate norm functions... either way). The std::set could easily be created in System::calculate_norm() for each variable that you want the discrete norm for and then call subset_norm() the appropriate number of times. And here's where it gets nutty: we just do our own damn norm calculation. It's not like it's rocket science. We do it right in NumericVector using the interface functions (like operator() ) so that every NumericVector gets this capability. What do you think? Derek On Nov 5, 2008, at 5:03 PM, Roy Stogner wrote: > > > On Wed, 5 Nov 2008, Kirk, Benjamin (JSCEG) wrote: > >> Could the api allow you to specify the indices from userspace? The >> reason I ask is because if all your variables are the same type it >> is pretty easy to figure out the range from the first_local_index, >> last_local_index, n_vars, and var_num. >> >> That's a little hackish to do inside the library... > > A *little* hackish? No, requiring the command line option > "node_major_dofs" to use that coefficient numbering, that was a > little hackish. *Breaking* that option (as well as TaylorHood > elements, etc.) would be a *lot* hackish. ;) > > But as an optimization which could fall back on my more general code, > it's a very good idea. Use NumericVector::subrange_norm() only if > we're using varmajor numbering, and have the DofMap cache the > first_local_index_var[n] for each variable so we get the range limits > right even if there's differing FE types in use. >  > Roy 
From: Kirk, Benjamin (JSCEG) <Benjamin.K<irk1@na...>  20081106 00:22:45

>> Could the api allow you to specify the indices from userspace? The >> reason I ask is because if all your variables are the same type it >> is pretty easy to figure out the range from the first_local_index, >> last_local_index, n_vars, and var_num. >> >> That's a little hackish to do inside the library... > > A *little* hackish? No, requiring the command line option > "node_major_dofs" to use that coefficient numbering, that was a > little hackish. *Breaking* that option (as well as TaylorHood > elements, etc.) would be a *lot* hackish. ;) > But as an optimization which could fall back on my more general code, > it's a very good idea. Use NumericVector::subrange_norm() only if > we're using varmajor numbering, and have the DofMap cache the > first_local_index_var[n] for each variable so we get the range limits > right even if there's differing FE types in use. Yeah, of course you're right... For only a tiny bit of library code we can put together something that might be quite useful. So, what do you think about something like std:pair<unsigned int, unsigned int> local_dof_index_range = DofMap::local_dof_index_range (unsigned int var_num = 1); (where I have obviously taken some liberty combining a function call with its prototype)? When called without a var_num argument we just return std::make_pair(first_local_index, last_local_index); otherwise the relevant bounds for var_num? Ben 
From: Roy Stogner <roystgnr@ic...>  20081106 00:04:12

On Wed, 5 Nov 2008, Kirk, Benjamin (JSCEG) wrote: > Could the api allow you to specify the indices from userspace? The > reason I ask is because if all your variables are the same type it > is pretty easy to figure out the range from the first_local_index, > last_local_index, n_vars, and var_num. > > That's a little hackish to do inside the library... A *little* hackish? No, requiring the command line option "node_major_dofs" to use that coefficient numbering, that was a little hackish. *Breaking* that option (as well as TaylorHood elements, etc.) would be a *lot* hackish. ;) But as an optimization which could fall back on my more general code, it's a very good idea. Use NumericVector::subrange_norm() only if we're using varmajor numbering, and have the DofMap cache the first_local_index_var[n] for each variable so we get the range limits right even if there's differing FE types in use.  Roy 
From: Kirk, Benjamin (JSCEG) <Benjamin.K<irk1@na...>  20081105 23:47:29

Unfortunately there is nothing in the library that is generic to find all local dof indices for a specific variable. Could the api allow you to specify the indices from userspace? The reason I ask is because if all your variables are the same type it is pretty easy to figure out the range from the first_local_index, last_local_index, n_vars, and var_num. That's a little hackish to do inside the library... What if NumericVector allowed a subrange_norm()? Seems like we should eventually implement the block sparse matrix and vector variants  that would make it really easy. I've often wondered if there would be much of a performance gain on the linear algebra side.  Original Message  From: Derek Gaston <friedmud@...> To: Roy Stogner <roy@...> Cc: libmeshusers@... <libmeshusers@...> Sent: Wed Nov 05 17:27:57 2008 Subject: Re: [Libmeshusers] Norm of a NumericVector for specific variable... On Nov 5, 2008, at 4:09 PM, Roy Stogner wrote: > In fact, I think we'll want to hand this norm off to NumericVector in > the end too, providing it with a cloned NumericVector whose > coefficients are set to the proper weights given in the SystemNorm, so > it just has to call the linear algebra package to pointwise multiply > and then take a norm. This makes sense to me. >> So... now my question is... is there a way to get a list of all of >> the DofIndices for a variable on a processor? Or am I going to >> have to loop over each element calling dof_map>dof_indices() and >> passing in the variable to build up this list? > > I don't see any way, no. Maybe Ben knows of something I'm forgetting. Hopefully. > But at least you won't have to loop over *every* element  you just > need to know which local DoFs belong to your variable. Right... just loop over local elements. Well... I guess I'll start writing something... Derek  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...>  20081105 23:35:55

I hope nobody minds if I risk breaking them. I'm committing a bugfix to svn (PetscMatrix::operator() leaks when called on entries outside of the sparsity pattern), but I've made some other changes: I've added parallel_only() (and semiparallel_only(), which acts like parallel_only() on distributed sparse matrices but not on serial ones) assertion calls to those operations which (I believe) need to be called on every processor at once for a nonSeq matrix. In other words: close() add(T,SparseMatrix&) init (when called with differing global and local sizes) zero() clear() (when MatDestroy is needed) l1_norm() linfty_norm() print_matlab() close() was what prompted the additions; I was (via operator()) calling it from only one processor at a time, which can break your code in interesting ways and which is the sort of thing that parallel_only() was intended to help debug. But if I've misinterpreted the PETSc docs about which functions can be safely called from only one processor, some of those assertions are going to be overzealous. My other potentially codebreaking change: making operator() semiparallelonly doesn't make sense, so instead of calling close() it now asserts that the mesh is already closed. That's probably fine  nobody uses operator() in a nondebugging sense anyway. But I spotted the same helpful "we'll close it for you" code in add(T,SparseMatrix&) and replaced that with an assert too. I figure either the user has already closed the matrix (in which case we're just wasting communication time reaffirming that) or they can add their own close() call. But that could break existing code, so someone tell me if I've gone too far and I'll revert the change.  Roy 
From: Derek Gaston <friedmud@gm...>  20081105 23:29:25

On Nov 5, 2008, at 4:09 PM, Roy Stogner wrote: > In fact, I think we'll want to hand this norm off to NumericVector in > the end too, providing it with a cloned NumericVector whose > coefficients are set to the proper weights given in the SystemNorm, so > it just has to call the linear algebra package to pointwise multiply > and then take a norm. This makes sense to me. >> So... now my question is... is there a way to get a list of all of >> the DofIndices for a variable on a processor? Or am I going to >> have to loop over each element calling dof_map>dof_indices() and >> passing in the variable to build up this list? > > I don't see any way, no. Maybe Ben knows of something I'm forgetting. Hopefully. > But at least you won't have to loop over *every* element  you just > need to know which local DoFs belong to your variable. Right... just loop over local elements. Well... I guess I'll start writing something... Derek 
From: Roy Stogner <roystgnr@ic...>  20081105 23:09:20

On Wed, 5 Nov 2008, Derek Gaston wrote: > Hmmm... I didn't even know that SystemNorm existed. After poking around to > where it was used... it looks like a method already exists for what I want: > > System::calculate_norm(NumericVector<Number>& v, unsigned int var = 0, > FEMNormType norm_type = L2) Right. System has its hands on the DofMap, so it can do exactly what you want without any change in the classes' interdependence. > But like you say, that function assumes that if you want a discrete norm of > the vector... that you want it of the entire vector. In fact... > ultimately... NumericVector::norm_type() gets called. Hey, what did you want me to do, reinvent the wheel? ;) In fact, I think we'll want to hand this norm off to NumericVector in the end too, providing it with a cloned NumericVector whose coefficients are set to the proper weights given in the SystemNorm, so it just has to call the linear algebra package to pointwise multiply and then take a norm. > So... now my question is... is there a way to get a list of all of the > DofIndices for a variable on a processor? Or am I going to have to loop over > each element calling dof_map>dof_indices() and passing in the variable to > build up this list? I don't see any way, no. Maybe Ben knows of something I'm forgetting. But at least you won't have to loop over *every* element  you just need to know which local DoFs belong to your variable.  Roy 
From: Derek Gaston <friedmud@gm...>  20081105 22:57:07

Hmmm... I didn't even know that SystemNorm existed. After poking around to where it was used... it looks like a method already exists for what I want: System::calculate_norm(NumericVector<Number>& v, unsigned int var = 0, FEMNormType norm_type = L2) But like you say, that function assumes that if you want a discrete norm of the vector... that you want it of the entire vector. In fact... ultimately... NumericVector::norm_type() gets called. So... it looks like the function that should get modified is: System::calculate_norm(NumericVector<Number>& v, const SystemNorm &norm) Which is what the above one calls (which calls NumericVector::norm_type() ). So... now my question is... is there a way to get a list of all of the DofIndices for a variable on a processor? Or am I going to have to loop over each element calling dof_map>dof_indices() and passing in the variable to build up this list? Derek On Nov 5, 2008, at 3:17 PM, Roy Stogner wrote: > > > On Wed, 5 Nov 2008, Derek Gaston wrote: > >> Anyone have a good piece of code for computing a norm of just the >> piece of a NumericVector that corresponds to a specific variable >> number? My problem is that I have multiple >> variables in my system... but I need to get the norm of the residual >> for each one individually. >> >> Should we maybe extend the l2_norm(), l1_norm(), linfty_norm() >> functions to take an option variable number? > > Does the NumericVector class even have enough information to know > which variable a coefficient belongs to? I'd hope it doesn't; I like > modular code. > > I think what you want to modify is the SystemNorm class. Currently it > assumes that you either want a weighted combination of Sobolev norms > of different variables or a discrete norm of the entire vector. > Extending it (and the classes that use it) to provide weighted > discrete norms of particular combinations of variables within a vector > should be straightforward. >  > Roy 
From: Roy Stogner <roystgnr@ic...>  20081105 22:18:09

On Wed, 5 Nov 2008, Derek Gaston wrote: > Anyone have a good piece of code for computing a norm of just the > piece of a NumericVector that corresponds to a specific variable > number? My problem is that I have multiple > variables in my system... but I need to get the norm of the residual > for each one individually. > > Should we maybe extend the l2_norm(), l1_norm(), linfty_norm() > functions to take an option variable number? Does the NumericVector class even have enough information to know which variable a coefficient belongs to? I'd hope it doesn't; I like modular code. I think what you want to modify is the SystemNorm class. Currently it assumes that you either want a weighted combination of Sobolev norms of different variables or a discrete norm of the entire vector. Extending it (and the classes that use it) to provide weighted discrete norms of particular combinations of variables within a vector should be straightforward.  Roy 
From: Kirk, Benjamin (JSCEG) <Benjamin.K<irk1@na...>  20081105 22:14:41

What about a scaled_norm of sorts where you can weight each variable by a constant? Yours is then just a special case with a one and some zeros?  Original Message  From: Derek Gaston <friedmud@...> To: libmeshusers@... <libmeshusers@...> Sent: Wed Nov 05 16:08:09 2008 Subject: [Libmeshusers] Norm of a NumericVector for specific variable... Anyone have a good piece of code for computing a norm of just the piece of a NumericVector that corresponds to a specific variable number? My problem is that I have multiple variables in my system... but I need to get the norm of the residual for each one individually. Should we maybe extend the l2_norm(), l1_norm(), linfty_norm() functions to take an option variable number? Derek  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: Derek Gaston <friedmud@gm...>  20081105 22:09:41

Anyone have a good piece of code for computing a norm of just the piece of a NumericVector that corresponds to a specific variable number? My problem is that I have multiple variables in my system... but I need to get the norm of the residual for each one individually. Should we maybe extend the l2_norm(), l1_norm(), linfty_norm() functions to take an option variable number? Derek 
From: John Peterson <jwpeterson@gm...>  20081105 13:46:51

On Wed, Nov 5, 2008 at 12:41 AM, Petry Stefan <petryste@...> wrote: > Good morning to everyone, > > I´ve a question about the file "mesh_triangle_support": > > In function Triangle::init() you´re declaring "t" as t.regionlist and t.numberofregions but you don´t use it anywhere! > > Is there something planned to use this two structurevariables in e.g TriangleInterface::triangulate() or other function? Hi, They're being initialized for completeness, even though they might not be used directly in LibMesh, they may be used internally by the Triangle library. The triangulateio object is a C struct coming from the Triangle library itself, and I wrote the init and destroy functions to act like constructors for this object.  John 
From: Petry Stefan <petryste@hs...>  20081105 06:41:34

Good morning to everyone, I´ve a question about the file "mesh_triangle_support": In function Triangle::init() you´re declaring "t" as t.regionlist and t.numberofregions but you don´t use it anywhere! Is there something planned to use this two structurevariables in e.g TriangleInterface::triangulate() or other function? Best reagrds! Steve 