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}
(79) 
_{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: Yujie <recrusader@gm...>  20081121 00:47:02

Dear Libmesh developers: I notice that if i need to add vectors in LinearImplicitSystem using System::add_vector() it must be done before System::init(). However, I can't confirm the vector number at the beginning. How to dynamically add vectors? In addition, In the same LinearImplicitSystem, the vectors added by add_vector() have similar characteristics with the variable added by add_variable(), such as parallel distribution, same Dofs? thanks a lot. Regards, Yujie 
From: John Peterson <jwpeterson@gm...>  20081120 17:27:48

On Thu, Nov 20, 2008 at 11:08 AM, John Peterson <jwpeterson@...> wrote: > On Thu, Nov 20, 2008 at 8:18 AM, jurak <jurak@...> wrote: >> Hi, >> >> ther is a small bug in function >> >> VTKIO::solution_to_vtk(const EquationSystems& es, vtkUnstructuredGrid*& >> grid) >> >> in vtk_io.C. On line 320 >> >> data>SetNumberOfValues(sys.solution>size()); >> >> sets the number of values too high when there is more than one variable >> in sys. >> (Corresponding vtufile is then filled with some garbage values.) It >> should be replaced by >> >> data>SetNumberOfValues(n_nodes); > > Hmm... I think that's pretty close, but what we really want is the > number of degrees of freedom for variable "j" when we are in the > jloop. For Lagrange FEs there is one DoF per node per variable, but > this is not the case for other finite element types. Unfortunately, I > can't remember off the top of my head how to find the total number of > DoFs for a particular variable. > > It looks like DofMap::variable_{first,last}_local_dof () gives the > first (resp. last) local degree of freedom index for a particular > variable. This could probably be used to obtain the total number of > dofs for a given variable, by summing the result across processors. > This should really be in the library somewhere, so hopefully Ben or > someone more knowledgeable will comment on the right way to do it. Aha, you'll probably want to do something like EquationSystems::build_solution_vector() to get this right.  John 
From: John Peterson <jwpeterson@gm...>  20081120 17:08:28

On Thu, Nov 20, 2008 at 8:18 AM, jurak <jurak@...> wrote: > Hi, > > ther is a small bug in function > > VTKIO::solution_to_vtk(const EquationSystems& es, vtkUnstructuredGrid*& > grid) > > in vtk_io.C. On line 320 > > data>SetNumberOfValues(sys.solution>size()); > > sets the number of values too high when there is more than one variable > in sys. > (Corresponding vtufile is then filled with some garbage values.) It > should be replaced by > > data>SetNumberOfValues(n_nodes); Hmm... I think that's pretty close, but what we really want is the number of degrees of freedom for variable "j" when we are in the jloop. For Lagrange FEs there is one DoF per node per variable, but this is not the case for other finite element types. Unfortunately, I can't remember off the top of my head how to find the total number of DoFs for a particular variable. It looks like DofMap::variable_{first,last}_local_dof () gives the first (resp. last) local degree of freedom index for a particular variable. This could probably be used to obtain the total number of dofs for a given variable, by summing the result across processors. This should really be in the library somewhere, so hopefully Ben or someone more knowledgeable will comment on the right way to do it. FYI, I don't think VTKIO::solution_to_vtk() is going to work right in parallel, anyway, since it will try to access nonlocal indices of the System::current_local_solution vector.  John 
From: jurak <jurak@ma...>  20081120 14:35:38

Hi, ther is a small bug in function VTKIO::solution_to_vtk(const EquationSystems& es, vtkUnstructuredGrid*& grid) in vtk_io.C. On line 320 data>SetNumberOfValues(sys.solution>size()); sets the number of values too high when there is more than one variable in sys. (Corresponding vtufile is then filled with some garbage values.) It should be replaced by data>SetNumberOfValues(n_nodes); Regards, Mladen Jurak <http://web.math.hr/%7Ejurak>; 
From: Vijay S. Mahadevan <vijay.m@gm...>  20081119 18:42:32

Thanks Ben. I could use that code but it might need a small variation. I only need one specific side or edge of the 2D domain and the code gives me the whole of the boundary mesh. While this is useful for other purposes, this is very confusing when I try to read it back in as a 1Dimensional mesh. Now that I think about it, I guess I could have just looped through the 2D mesh and then extracted nodes that fall on a certain side. This could be done now a lot easily once I have obtained the boundary mesh using meshtool.cc also. Well, thanks for pointing out the meshtool app to help me out ! ~Vijay On Wed, Nov 19, 2008 at 11:33 AM, Benjamin Kirk <benjamin.kirk@...> wrote: > > Take a look at 'src/apps/mesh_tool.cc'  > > The 'b' commandline option should do exactly what you want. > > You can either try using meshtool or extract the relevant code for yourself. > > Ben > > > On 11/19/08 9:17 AM, "Vijay S. Mahadevan" <vijay.m@...> wrote: > >> Hi guys, >> >> I need to extract a 1dimensional mesh from a 2dimensional mesh; >> Basically, extract one side of the 2D mesh and create a 1D mesh out >> of that. I was wondering what would be the elegant way to do this ? I >> saw that there is a BoundaryInfo object in MeshBase and am curious >> whether this would do the trick ? Also, a slight complication might >> arise (possibly) here since the 2D mesh uses continuous Lagrangian >> basis while I need to use discontinuous basis for the 1D mesh. >> >> I want this to work for arbitrary 2D meshes that can be read from >> files and not just using build_cube call. Any ideas on how to proceed >> on this would be greatly helpful. >> >> Thanks a lot in advance. >> >> Vijay > > 
From: Benjamin Kirk <benjamin.kirk@na...>  20081119 17:33:20

Take a look at 'src/apps/mesh_tool.cc'  The 'b' commandline option should do exactly what you want. You can either try using meshtool or extract the relevant code for yourself. Ben On 11/19/08 9:17 AM, "Vijay S. Mahadevan" <vijay.m@...> wrote: > Hi guys, > > I need to extract a 1dimensional mesh from a 2dimensional mesh; > Basically, extract one side of the 2D mesh and create a 1D mesh out > of that. I was wondering what would be the elegant way to do this ? I > saw that there is a BoundaryInfo object in MeshBase and am curious > whether this would do the trick ? Also, a slight complication might > arise (possibly) here since the 2D mesh uses continuous Lagrangian > basis while I need to use discontinuous basis for the 1D mesh. > > I want this to work for arbitrary 2D meshes that can be read from > files and not just using build_cube call. Any ideas on how to proceed > on this would be greatly helpful. > > Thanks a lot in advance. > > Vijay 
From: Vijay S. Mahadevan <vijay.m@gm...>  20081119 15:17:11

Hi guys, I need to extract a 1dimensional mesh from a 2dimensional mesh; Basically, extract one side of the 2D mesh and create a 1D mesh out of that. I was wondering what would be the elegant way to do this ? I saw that there is a BoundaryInfo object in MeshBase and am curious whether this would do the trick ? Also, a slight complication might arise (possibly) here since the 2D mesh uses continuous Lagrangian basis while I need to use discontinuous basis for the 1D mesh. I want this to work for arbitrary 2D meshes that can be read from files and not just using build_cube call. Any ideas on how to proceed on this would be greatly helpful. Thanks a lot in advance. Vijay 
From: Benjamin Kirk <benjamin.kirk@na...>  20081119 14:10:35

(I'm copying this to the devel list, feel free to take users off any reply to keep its traffic down) > Okay, so dxyz seems to be appropriate for storing the metric  that > problem is solved then. Now, one last thing: All DOFs are at the > vertices (and we have only one DOF per vertex). Ie the global vector and > matrices have dimension M or MxM if M is the number of mesh vertices. > However, each DOF is not only shared with all the triangles incident to > that vertex, but also with all elements which have this vertex in their > patch (ie in their 1neighborhood). E.g., for the element e shown below, > the element matrix contribution Ke(i,j) is a (N+6)x(N+6) matrix, where > only the local indices 0,1 and N directly belong to element e, while the > other DOFs belong to the elements around e. I don't think that dof_map > can provide such a map out of the box, or am I wrong? Correct  it won't do that by default... > I was therefore thinking of the following: Create a custom > subdiv_dof_map, which collects the dof indices of all vertices in the > patch of e and then (in the correct order) combines them into one > dof_indices vector. This one can then be used as before. I guess it > would be minimally invasive and only need small changes in the > application code. I just hope there's no hidden catch... You're right. There may be bizarre AMR constraint implications I haven't thought through, but since you said you're presently not worried about AMR that is a nonissue. All that should be needed is a different method to compute the graph of the sparse matrix. (I think even the current dof distribution stuff will work just fine.) For some time I've wanted 'specialized' dof maps to handle cases where you ether (i) have special needs (like this) or (ii) know something special about your application that allows you to exploit an efficiency. My compressible navierstokes application is an example of (ii) since there are a lot of variables in a system which are all the same type. The System base class holds an AutoPtr<DofMap> object, so I'm thinking it would be *really* easy to modify the DofMap class definition a little so that users can derive their own implementation and supply it to the System for use. Then we just add a System::replace_dof_map() member or something like that. Anyone have a different idea? Ben >>> N+4  N+1  N+2 >>> / \ / \ / \ >>> / \ / \ / \ >>> N+5  N  1  N+3 >>> \ / \ e / \ / >>> \ / \ / \ / >>> N1 0  2 >>> \ /\ / >>> \ /  \ / >>> 5 4 3 >>> 
From: Norbert Stoop <norbert@st...>  20081119 12:58:32

Okay, so dxyz seems to be appropriate for storing the metric  that problem is solved then. Now, one last thing: All DOFs are at the vertices (and we have only one DOF per vertex). Ie the global vector and matrices have dimension M or MxM if M is the number of mesh vertices. However, each DOF is not only shared with all the triangles incident to that vertex, but also with all elements which have this vertex in their patch (ie in their 1neighborhood). E.g., for the element e shown below, the element matrix contribution Ke(i,j) is a (N+6)x(N+6) matrix, where only the local indices 0,1 and N directly belong to element e, while the other DOFs belong to the elements around e. I don't think that dof_map can provide such a map out of the box, or am I wrong? I was therefore thinking of the following: Create a custom subdiv_dof_map, which collects the dof indices of all vertices in the patch of e and then (in the correct order) combines them into one dof_indices vector. This one can then be used as before. I guess it would be minimally invasive and only need small changes in the application code. I just hope there's no hidden catch... Norbert >> >> N+4  N+1  N+2 >> / \ / \ / \ >> / \ / \ / \ >> N+5  N  1  N+3 >> \ / \ e / \ / >> \ / \ / \ / >> N1 0  2 >> \ /\ / >> \ /  \ / >> 5 4 3 >> 
From: Norbert Stoop <norbert@st...>  20081118 22:28:53

This is from my phone, sorry for any typos.  Norbert Stoop http://tsonny.ch/ On 18.11.2008, at 19:06, Roy Stogner <roystgnr@...> wrote: > > > On Tue, 18 Nov 2008, Norbert Stoop wrote: > >> Roy Stogner wrote: >> >>> Does this have to be stored as a vector? Or stored at all? >>> Patch::add_point_neighbors() should do what you want on the fly. If >>> it's worthwhile a caching version of that could be created. >> >> Hm, the patch needs a special numbering scheme, which should look >> like this >> >> N+4  N+1  N+2 >> / \ / \ / \ >> / \ / \ / \ >> N+5  N  1  N+3 >> \ / \ e / \ / >> \ / \ / \ / >> N1 0  2 >> \ /\ / >> \ /  \ / >> 5 4 3 >> >> where e is the element we consider and N is the valence of vertex 0 >> (which is irregular in this example). > > Ah  then I was completely misunderstanding what you had said before > about irregular vertices; I had hanging nodes in mind. > > What do you do about nonconforming adaptivity? You can probably > ignore more refined neighbors, but what about coarser neighbors? I recently found a Paper which deals with adaptive refinement. I can send you the ref when i'm back at my computer. Instead of the mesh the basis function space is somehow enlarged. They claim it is way easier than traditional amr.. In other words, i dont care about amr at the moment. > You couldn't get this scheme out of a Patch set very easily. But > because you've got more of a special case problem (all triangles at > the same level) you could get this kind of patch more efficiently: > find the neighbor at a side, find which side of his you are, decrement > modulo 3 to get the new side, and repeat until you get back to the > original element. Do that for all three original sides. Yep, thats what i do right now in reinit() >>> Could you describe this in more detail? Do you just need the FE >>> object to be able to fill in xyz/dxyz/d2xyz properly, or is it more >>> than that? >> >> What I need in particular, and probably all people solving stuff on a >> manifold, is the local surface metric at the quadrature points. >> To get this, one needs the C1 parametrization x(eta,xi). The >> derivatives >> wrt xi and eta give two tangents, from which the normal can be >> constructed. Together they basically define the metric. > > That sounds like what xyz and dxyz äre. Ah, lacking a proper browser i cannot find the precise Definition for xyz, but if it is meant as the map from xi,eta to xyz then this is definitely the right place to store it... >> The problem is, x(xi,eta) is given as a sum of >> phi(i)*nodal_xyz_position(i) where i goes over all vertices of the >> above >> patch. >> >> Now, either the finite element class exposes an interface to the >> parametrization x(xi,eta) (and its derivatives) > > Already done at the quadrature points. > >> and the metric, > > This we'd probably want the user code to calculate from dxyz. > >> or the node patch is exposed and the user constructs what actually >> is needed (since the phi's are already at hand). > > That may be what you fall back on, but if it could be put into the > library cleanly that would be nice. Provided i can put the metric into xyz, i could derive from fe<> and cache the current element patch, valences etc. in global scope like is done for the clough element coefficients. Is my understanding correct and would this be acceptable? Thanks for your help! norbert 
From: Roy Stogner <roystgnr@ic...>  20081118 18:06:21

On Tue, 18 Nov 2008, Norbert Stoop wrote: > Roy Stogner wrote: > >> Does this have to be stored as a vector? Or stored at all? >> Patch::add_point_neighbors() should do what you want on the fly. If >> it's worthwhile a caching version of that could be created. > > Hm, the patch needs a special numbering scheme, which should look like this > > N+4  N+1  N+2 > / \ / \ / \ > / \ / \ / \ > N+5  N  1  N+3 > \ / \ e / \ / > \ / \ / \ / > N1 0  2 > \ /\ / > \ /  \ / > 5 4 3 > > where e is the element we consider and N is the valence of vertex 0 > (which is irregular in this example). Ah  then I was completely misunderstanding what you had said before about irregular vertices; I had hanging nodes in mind. What do you do about nonconforming adaptivity? You can probably ignore more refined neighbors, but what about coarser neighbors? You couldn't get this scheme out of a Patch set very easily. But because you've got more of a special case problem (all triangles at the same level) you could get this kind of patch more efficiently: find the neighbor at a side, find which side of his you are, decrement modulo 3 to get the new side, and repeat until you get back to the original element. Do that for all three original sides. >> Could you describe this in more detail? Do you just need the FE >> object to be able to fill in xyz/dxyz/d2xyz properly, or is it more >> than that? > > What I need in particular, and probably all people solving stuff on a > manifold, is the local surface metric at the quadrature points. > To get this, one needs the C1 parametrization x(eta,xi). The derivatives > wrt xi and eta give two tangents, from which the normal can be > constructed. Together they basically define the metric. That sounds like what xyz and dxyz are. > The problem is, x(xi,eta) is given as a sum of > phi(i)*nodal_xyz_position(i) where i goes over all vertices of the above > patch. > > Now, either the finite element class exposes an interface to the > parametrization x(xi,eta) (and its derivatives) Already done at the quadrature points. > and the metric, This we'd probably want the user code to calculate from dxyz. > or the node patch is exposed and the user constructs what actually > is needed (since the phi's are already at hand). That may be what you fall back on, but if it could be put into the library cleanly that would be nice.  Roy 
From: Norbert Stoop <norbert@st...>  20081118 17:41:49

Roy Stogner wrote: > > On Tue, 18 Nov 2008, Norbert Stoop wrote: > >> Okay, the basic functionality for subdivision surface FEM should be >> implemented now, but I have a question regarding proper integration into >> libmesh: > >> These elements need some additional variables to store >> subdivision surface properties. For example, a vector of the 1ring of >> neighbors is needed. > > Does this have to be stored as a vector? Or stored at all? > Patch::add_point_neighbors() should do what you want on the fly. If > it's worthwhile a caching version of that could be created. Hm, the patch needs a special numbering scheme, which should look like this N+4  N+1  N+2 / \ / \ / \ / \ / \ / \ N+5  N  1  N+3 \ / \ e / \ / \ / \ / \ / N1 0  2 \ /\ / \ /  \ / 5 4 3 where e is the element we consider and N is the valence of vertex 0 (which is irregular in this example). >> Some of these properties also need to be accessible from the >> application code, for example to create a local coordinate system >> from the surface tangents. > > Could you describe this in more detail? Do you just need the FE > object to be able to fill in xyz/dxyz/d2xyz properly, or is it more > than that? What I need in particular, and probably all people solving stuff on a manifold, is the local surface metric at the quadrature points. To get this, one needs the C1 parametrization x(eta,xi). The derivatives wrt xi and eta give two tangents, from which the normal can be constructed. Together they basically define the metric. The problem is, x(xi,eta) is given as a sum of phi(i)*nodal_xyz_position(i) where i goes over all vertices of the above patch. Now, either the finite element class exposes an interface to the parametrization x(xi,eta) (and its derivatives) and the metric, or the node patch is exposed and the user constructs what actually is needed (since the phi's are already at hand). Norbert 
From: Roy Stogner <roystgnr@ic...>  20081118 16:52:34

On Tue, 18 Nov 2008, Norbert Stoop wrote: > Okay, the basic functionality for subdivision surface FEM should be > implemented now, but I have a question regarding proper integration into > libmesh: > These elements need some additional variables to store > subdivision surface properties. For example, a vector of the 1ring of > neighbors is needed. Does this have to be stored as a vector? Or stored at all? Patch::add_point_neighbors() should do what you want on the fly. If it's worthwhile a caching version of that could be created. > Some of these properties also need to be accessible from the > application code, for example to create a local coordinate system > from the surface tangents. Could you describe this in more detail? Do you just need the FE object to be able to fill in xyz/dxyz/d2xyz properly, or is it more than that? > Now, which class should I derive the elements from? Somehow, I feel that > FE<2,SUBDIV> does not make too much sense since it has no containers for > the extra variables. I agree, but for a different reason  It would be nice to be able to mix and match subdivision surfaces with different FE types, right? If we can factor out the "all mappings are Lagrange" assumption properly, that would be possible. > On the other hand, all other libmesh machinery > relies on fe.h only and it's probably not the idea to change that. I think we could make the change sufficiently "hidden" if we just knew how to best represent it.  Roy 
From: Norbert Stoop <norbert@st...>  20081118 16:27:40

Hi again, Okay, the basic functionality for subdivision surface FEM should be implemented now, but I have a question regarding proper integration into libmesh: These elements need some additional variables to store subdivision surface properties. For example, a vector of the 1ring of neighbors is needed. Some of these properties also need to be accessible from the application code, for example to create a local coordinate system from the surface tangents. Now, which class should I derive the elements from? Somehow, I feel that FE<2,SUBDIV> does not make too much sense since it has no containers for the extra variables. On the other hand, all other libmesh machinery relies on fe.h only and it's probably not the idea to change that. Thanks in advance, Norbert Norbert Stoop wrote: > Hi, > > Recently, subdivision surfaces were suggested as an alternative way to > construct C1 (and higher) conforming surface meshes for finite element > simulations. Now, I'm wondering how hard it would be to implement such > elements in libmesh: > Assuming triangular elements, the subdivision surface approach results > in 12 bspline shape functions per element. The isoparametric map to > real space is a combination of them multiplied with the real space > position of the triangle's nodes *and* its next neighbor nodes (the > 1ring of triangles around the element). > Looking at existing libmesh elements (lagrange, clough), I see that only > the ::shape, ::shape_deriv and ::shape_second_deriv are typically > overwritten, and the mapping to real space is done by libmesh > (fe_base.C, I think). > As pointed out above, the subdivision elements have a special mapping to > real space, which needs to take the neighboring nodes' position into > account. Is there a way to accomplish this in the current code or would > it be possible to extend it in that way? > > Thanks in advance, > Norbert > >  > 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: Benjamin Kirk <benjamin.kirk@na...>  20081118 14:53:38

>> Compiling C++ (in optimized mode) src/mesh/nemesis_io.C... >> src/mesh/nemesis_io.C: In member function virtual void >> Nemesis_IO::read(const std::string&)¹: >> src/mesh/nemesis_io.C:254: error: reference to uint¹ is ambiguous >> /usr/include/sys/types.h:153: error: candidates are: typedef unsigned int >> uint >> src/mesh/nemesis_io.C:56: error: template<class T> unsigned >> int<unnamed>::uint(const T&) > > The problem does not appear any more. I don't know why, but the > problem is solved. Thanks. The issue was some syntax which gcc4.3 on my laptop accepted, but gcc4.2 (at least) did not. Specifically, I tried to implement the "vector swap trick" from memory as vec.swap(std::vector<>()); Which does not always work because swap expects a reference, and depending on compiler the above code may produce a copied value. The proper implementation is in there now  std::vector<>().swap(vec); Which does the right thing. Ben 
From: Tim Kroeger <tim.kroeger@ce...>  20081118 10:32:23

Dear libMesh team, On Mon, 17 Nov 2008, Tim Kroeger wrote: > Compiling C++ (in optimized mode) src/mesh/nemesis_io.C... > src/mesh/nemesis_io.C: In member function ‘virtual void > Nemesis_IO::read(const std::string&)’: > src/mesh/nemesis_io.C:254: error: reference to ‘uint’ is ambiguous > /usr/include/sys/types.h:153: error: candidates are: typedef unsigned int > uint > src/mesh/nemesis_io.C:56: error: template<class T> unsigned > int<unnamed>::uint(const T&) The problem does not appear any more. I don't know why, but the problem is solved. Best Regards, Tim  Dr. Tim Kroeger Phone +494212187710 tim.kroeger@..., tim.kroeger@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 
From: Derek Gaston <friedmud@gm...>  20081117 16:59:37

My favorite way is to add an ExplicitSystem named "auxiliary" or "post" to my EquationsSystem... then add all of the variables I want to calculate through postprocessing to that system. Then, when I'm postprocessing, I fill up the values in that auxiliary system. Finally, when you use GTKIO or whatever to write out the EquationsSystem those variables will automagically come out! This keeps those variables separate from the linear system I'm solving (keeps them out of the matrix / solution / rhs vectors). Derek On Nov 17, 2008, at 9:54 AM, vasvav@... wrote: > many thnx for the prompt reply, i'll have a look, but there is another > question...on the same issue... > > Fancy that all post process is done (i.e. stresses are evaluated). > How can > i "store" these nodal values in the mesh so as that i'll retrieve them > through GMVIO, VTKIO, ExodusII_IO classes for visualization purposes? > > > many thanks in advance :) > > > > > > On Mon, November 17, 2008 16:35, Roy Stogner wrote: >> > >> On Mon, 17 Nov 2008, vasvav@... wrote: >> >> >>> My question is: is there any simple formula so as to evaluate nodal >>> stresses or/and strains in the same mesh? None of the thourough >>> examples >>> of libmesh perform any kind of postprocess! >> >> See some suggestions in this thread: >> >> >> http://sourceforge.net/mailarchive/forum.php?thread_name=48DE6B62.9060306 >> %40mcgill.ca&forum_name=libmeshusers >>  >> Roy >> >> > > > >  > 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: <vasvav@me...>  20081117 16:54:54

many thnx for the prompt reply, i'll have a look, but there is another question...on the same issue... Fancy that all post process is done (i.e. stresses are evaluated). How can i "store" these nodal values in the mesh so as that i'll retrieve them through GMVIO, VTKIO, ExodusII_IO classes for visualization purposes? many thanks in advance :) On Mon, November 17, 2008 16:35, Roy Stogner wrote: > > On Mon, 17 Nov 2008, vasvav@... wrote: > > >> My question is: is there any simple formula so as to evaluate nodal >> stresses or/and strains in the same mesh? None of the thourough examples >> of libmesh perform any kind of postprocess! > > See some suggestions in this thread: > > > http://sourceforge.net/mailarchive/forum.php?thread_name=48DE6B62.9060306 > %40mcgill.ca&forum_name=libmeshusers >  > Roy > > 
From: Roy Stogner <roystgnr@ic...>  20081117 14:35:09

On Mon, 17 Nov 2008, vasvav@... wrote: > My question is: is there any simple formula so as to evaluate nodal > stresses or/and strains in the same mesh? None of the thourough examples > of libmesh perform any kind of postprocess! See some suggestions in this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=48DE6B62.9060306%40mcgill.ca&forum_name=libmeshusers  Roy 
From: Tim Kroeger <tim.kroeger@ce...>  20081117 13:46:08

Dear myself, On Thu, 13 Nov 2008, Tim Kroeger wrote: > *system.solution += *system.old_local_solution; > system.update(); > > Unfortunately, this doesn't work in parallel since solution is a > parallel vector and old_local_solution is a serial vector. I have now found the following solution that seems to work fine for me: for(unsigned int i=system.solution>first_local_index(); i<system.solution>last_local_index(); i++) { system.solution>add(i,(*system.old_local_solution)(i)); } system.solution>close(); system.update(); I'm not quite sure whether this is efficient, but it doesn't seem to be a bottleneck at the moment. Best Regards, Tim  Dr. Tim Kroeger Phone +494212187710 tim.kroeger@..., tim.kroeger@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 
From: <vasvav@me...>  20081117 13:40:49

HI to all :) I'd like to make a simple question (not knowing though whether there is already an answer, since i'm completely NEW to libmesh) ... I tried to implement libmesh into solving a simple 2D problem in elastostatics. I successfully solved the problem and i evaluated nodal displacements in the mesh. My question is: is there any simple formula so as to evaluate nodal stresses or/and strains in the same mesh? None of the thourough examples of libmesh perform any kind of postprocess! kindest regards :) Vasilis 
From: Tim Kroeger <tim.kroeger@ce...>  20081117 12:39:43

Dear libMesh team, Life is not easy... Last week, I was told that the cluster I'm currently working with will be shut down completely next Friday. I have access to a different cluster, but this means I will have to install a lot of software (including libMesh) once more again. (It seems to me that I spend most of my time installing software, and I wonder whether I am a mathematician or a system administrator...) When compiling libMesh on that cluster, I get an error message that I cannot remember to have seen before: Compiling C++ (in optimized mode) src/mesh/nemesis_io.C... src/mesh/nemesis_io.C: In member function ‘virtual void Nemesis_IO::read(const std::string&)’: src/mesh/nemesis_io.C:254: error: reference to ‘uint’ is ambiguous /usr/include/sys/types.h:153: error: candidates are: typedef unsigned int uint src/mesh/nemesis_io.C:56: error: template<class T> unsigned int<unnamed>::uint(const T&) Can someone tell me what went wrong? Best Regards, Tim  Dr. Tim Kroeger Phone +494212187710 tim.kroeger@..., tim.kroeger@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 
From: Norbert Stoop <norbert@st...>  20081114 14:18:38

Derek Gaston wrote: > On Nov 11, 2008, at 10:02 AM, Roy Stogner wrote: > >> On Tue, 11 Nov 2008, Norbert Stoop wrote: >> >>> To summarize, we abuse the traditional mesh as a control mesh. We define >>> a parametrization of the limit surface which naturally gives us the >>> needed mathematical objects such as derivatives, surface patches etc. >>> Since we *know* where each control point converges to in the limit, we >>> can assign back calculated nodal values to the control points and >>> assemble the system as usual. >>> >>> Hope this helps to clarify... > > It seems like if you could use Clough Touchers (or hermites) as the map > then that would solve this problem... but as you mentioned earlier > that's probably not doable with our current architecture. >From an implementation point of view, the subdivision approach does not require this map, since you directly construct the element in the global system (as C1). The only map you have and need is the parametrization X(xi,eta) where X maps to the C1 surface in physical space. The jacobian at some point P(xi,eta) on the (C1!) element is then calculated from two basis vectors a_xi and a_eta of the tangent space at P, according to differential geometry: jac =  a_xi crossprod a_eta  Since you have X(xi,eta), the a_xi and a_eta follow by just differentiating X by xi or eta respectively. To put it in a sloppy way: Instead of defining everything on the master element, then find a transformation into global space, we do *define* the C1 element in global space and *there* construct the jacobian and all the other properties. We sort of go the other way around than how one typically does for FE. Norbert 
From: Vijay S. Mahadevan <vijay.m@gm...>  20081113 22:19:10

Sorry about the late reply. I just wrote a small toy code to see if the coarsening and refining produces the same distribution using ParMetis and it does !! I've attached the code with the mail and feel free to test it with some of your own mesh files to confirm. Ben, thanks for the update on the graph distribution and all I can say is that is just good forward thinking ! I guess this hopefully brings me one step closer to doing geometric multigrid now... On Thu, Nov 13, 2008 at 10:17 AM, Benjamin Kirk <benjamin.kirk@...> wrote: >>> If this makes sense, I think I have a nice place to start working on >>> this. >>> And as long as coarsen and refine are pseudoinverse operations, >> >> Hmm... they still may not be. If you do a System::reinit() after >> coarsen/refine, the Mesh will also be repartitioned, and I don't know >> that our partitioners (the default, METIS/ParMETIS, in particular) are >> guaranteed to give you the same partitioning every time you give them >> the same mesh  I suspect their results will depend on the previous >> partitioning/ordering, which will be scrambled by the coarsen/refine. >> The different partitioning will then give you different DoF indexing. > > So this all rang a bell... > > http://sourceforge.net/mailarchive/forum.php?thread_name=C3E2413C.496F%25benjamin.kirk%40nasa.gov&forum_name=libmeshdevel > > Parmetis can either compute the partition of a graph independent of its > distribution, or repartition with some heuristic to minimize the amount of > redistribution required while still creating a quality partition. Obviously > the latter will create a distribution which is dependent on the initial > partitioning, but what about the former? > > The problem we ran in to is that while the partitioning depends only on the > input graph, in our case the input graph was dependent on the mesh > distribution because the element global indicies were tied to the > partitioning. > > See the thread, there was some debate as to whether repeated calls to the > partitioner on the same mesh with the same number of processors should > return the same partitioning... Apparently I thought it was important > enough to implement a fix in the parmetis partitioner. > > What we do now is compute a unique, global ordering of the elements based on > their hilbert key ordering. This ordering is independent of the actual > element parallel distribution. The graph is then built in terms of this > ordering, and as far as I can tell the same partitioning of the graph will > always result, independent of the graph distribution. > > Ben 
From: Tim Kroeger <tim.kroeger@ce...>  20081113 16:46:03

Dear all, For a transient linear system in my application, the equation is quite complicted, and it seemed easier to me to solve for (u_{n+1}u_n) than for u_{n+1} (that is, I solve for the update rather than for the solution). To get the new solution, I then do: *system.solution += *system.old_local_solution; system.update(); Unfortunately, this doesn't work in parallel since solution is a parallel vector and old_local_solution is a serial vector. Of course, *system.local_solution += *system.old_local_solution; system.update(); would run, but do the wrong thing since update() copies things in the wrong direction. Is there any nice solution to this problem? Best Regards, Tim  Dr. Tim Kroeger Phone +494212187710 tim.kroeger@..., tim.kroeger@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 