You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}
(2) 
_{Nov}
(27) 
_{Dec}
(31) 

2004 
_{Jan}
(6) 
_{Feb}
(15) 
_{Mar}
(33) 
_{Apr}
(10) 
_{May}
(46) 
_{Jun}
(11) 
_{Jul}
(21) 
_{Aug}
(15) 
_{Sep}
(13) 
_{Oct}
(23) 
_{Nov}
(1) 
_{Dec}
(8) 
2005 
_{Jan}
(27) 
_{Feb}
(57) 
_{Mar}
(86) 
_{Apr}
(23) 
_{May}
(37) 
_{Jun}
(34) 
_{Jul}
(24) 
_{Aug}
(17) 
_{Sep}
(50) 
_{Oct}
(24) 
_{Nov}
(10) 
_{Dec}
(60) 
2006 
_{Jan}
(47) 
_{Feb}
(46) 
_{Mar}
(127) 
_{Apr}
(19) 
_{May}
(26) 
_{Jun}
(62) 
_{Jul}
(47) 
_{Aug}
(51) 
_{Sep}
(61) 
_{Oct}
(42) 
_{Nov}
(50) 
_{Dec}
(33) 
2007 
_{Jan}
(60) 
_{Feb}
(55) 
_{Mar}
(77) 
_{Apr}
(102) 
_{May}
(82) 
_{Jun}
(102) 
_{Jul}
(169) 
_{Aug}
(117) 
_{Sep}
(80) 
_{Oct}
(37) 
_{Nov}
(51) 
_{Dec}
(43) 
2008 
_{Jan}
(71) 
_{Feb}
(94) 
_{Mar}
(98) 
_{Apr}
(125) 
_{May}
(54) 
_{Jun}
(119) 
_{Jul}
(60) 
_{Aug}
(111) 
_{Sep}
(118) 
_{Oct}
(125) 
_{Nov}
(119) 
_{Dec}
(94) 
2009 
_{Jan}
(109) 
_{Feb}
(38) 
_{Mar}
(93) 
_{Apr}
(88) 
_{May}
(29) 
_{Jun}
(57) 
_{Jul}
(53) 
_{Aug}
(48) 
_{Sep}
(68) 
_{Oct}
(151) 
_{Nov}
(23) 
_{Dec}
(35) 
2010 
_{Jan}
(84) 
_{Feb}
(60) 
_{Mar}
(184) 
_{Apr}
(112) 
_{May}
(60) 
_{Jun}
(90) 
_{Jul}
(23) 
_{Aug}
(70) 
_{Sep}
(119) 
_{Oct}
(27) 
_{Nov}
(47) 
_{Dec}
(54) 
2011 
_{Jan}
(22) 
_{Feb}
(19) 
_{Mar}
(92) 
_{Apr}
(93) 
_{May}
(35) 
_{Jun}
(91) 
_{Jul}
(32) 
_{Aug}
(61) 
_{Sep}
(7) 
_{Oct}
(69) 
_{Nov}
(81) 
_{Dec}
(23) 
2012 
_{Jan}
(64) 
_{Feb}
(95) 
_{Mar}
(35) 
_{Apr}
(36) 
_{May}
(63) 
_{Jun}
(98) 
_{Jul}
(70) 
_{Aug}
(171) 
_{Sep}
(149) 
_{Oct}
(64) 
_{Nov}
(67) 
_{Dec}
(126) 
2013 
_{Jan}
(108) 
_{Feb}
(104) 
_{Mar}
(171) 
_{Apr}
(133) 
_{May}
(108) 
_{Jun}
(100) 
_{Jul}
(93) 
_{Aug}
(126) 
_{Sep}
(74) 
_{Oct}
(59) 
_{Nov}
(145) 
_{Dec}
(93) 
2014 
_{Jan}
(38) 
_{Feb}
(45) 
_{Mar}
(26) 
_{Apr}
(41) 
_{May}
(125) 
_{Jun}
(70) 
_{Jul}
(61) 
_{Aug}
(66) 
_{Sep}
(60) 
_{Oct}
(110) 
_{Nov}
(27) 
_{Dec}
(30) 
2015 
_{Jan}
(43) 
_{Feb}
(67) 
_{Mar}
(71) 
_{Apr}
(92) 
_{May}
(39) 
_{Jun}
(15) 
_{Jul}
(46) 
_{Aug}
(63) 
_{Sep}
(84) 
_{Oct}
(82) 
_{Nov}
(69) 
_{Dec}
(45) 
2016 
_{Jan}
(92) 
_{Feb}
(91) 
_{Mar}
(148) 
_{Apr}
(43) 
_{May}
(58) 
_{Jun}
(117) 
_{Jul}
(92) 
_{Aug}
(140) 
_{Sep}
(49) 
_{Oct}
(33) 
_{Nov}
(85) 
_{Dec}
(40) 
2017 
_{Jan}
(41) 
_{Feb}
(28) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(2) 
2
(1) 
3

4

5
(1) 
6

7
(9) 
8
(1) 
9
(2) 
10
(1) 
11
(2) 
12
(8) 
13
(18) 
14
(8) 
15
(3) 
16

17

18
(2) 
19
(5) 
20
(7) 
21
(13) 
22
(3) 
23
(9) 
24

25
(2) 
26
(13) 
27
(6) 
28
(24) 
29
(6) 
30
(5) 
31

From: Roy Stogner <roystgnr@ic...>  20091013 22:23:18

On Tue, 13 Oct 2009, Roy Stogner wrote: > Anyway, the solution is probably to, after you've looped over all > nodes, loop over all constraint equations in the dof map and apply > them to nodes' xyz coordinates. Thinking about it again, this is an oversimplification. For it to work, you'd need to have a variable (either in your system, or better in an ExplicitSystem created for the purpose) which is of type LAGRANGE and which is of the same FE order as your geometric Elem order. You'd also need to have some lookup between that variable's dof indices and your node ids; they won't be the same thing. This is still the right solution, it's just easier said than done.  Roy 
From: Roy Stogner <roystgnr@ic...>  20091013 22:09:19

On Tue, 13 Oct 2009, Joa Ljungvall wrote: > #5 0x00007fff81116bfc in __cxa_throw () > #6 0x000000010512afa4 in RemoteElem::n_nodes () > #7 0x000000010510acf4 in DofMap::dof_indices () > #8 0x000000010510e2d9 in DofMap::add_neighbors_to_send_list () > > This I don't understand at all... Hmm... there was a bug last year that looked like this, but it was fixed before 0.6.3 was released. It may be that you've inadvertently triggered the same problem that the bug did, though: When we refine an element, we need to create any new nodes its children will have, or we need to point them to the appropriate existing node in the mesh. We look for that existing node by location: calculate the point where we'd build a new node, see if any node exists at that point yet, if so attach to it and if not then build a new one. But what happens if you refine one element, create a hanging node, then *move the hanging node*? When you refine the element's neighbor, it will look to see if a node exists yet on that edge or face, the answer will be "no", and a new node will be created. This tears the topology of the mesh, which is a nasty bug that can manifest as the incorrect creation of a RemoteElem in our find_neighbors() algorithm. (but which should have triggered a libmesh_assert() earlier  did you run in devel or dbg mode?) Anyway, the solution is probably to, after you've looped over all nodes, loop over all constraint equations in the dof map and apply them to nodes' xyz coordinates.  Roy 
From: Joa Ljungvall <libmesh@jo...>  20091013 21:49:47

The problem with a negative jacobian seems solved. It was indeed a node that was moved in the wrong way by my code. Now the program iterates two times but then I get (running in gdb) EquationSystems n_systems()=1 System "Laplace" Type "LinearImplicit" Variables="u" Finite Element Types="LAGRANGE" Approximation Orders="FIRST" n_dofs()=715 n_local_dofs()=715 n_constrained_dofs()=0 n_vectors()=1 Beginning Solve 0 System has: 715 degrees of freedom. Linear solver converged at step: 5000, final residual: 1.1091e16 Refining the mesh... Beginning Solve 1 System has: 1043 degrees of freedom. Linear solver converged at step: 5000, final residual: 9.00376e17 Refining the mesh... [0] /usr/local/libmesh/include/geom/remote_elem.h, line 91, compiled Oct 11 2009 at 15:02:42 terminate called after throwing an instance of 'libMesh::LogicError' what(): Error in libMesh internal logic Program received signal SIGABRT, Aborted. 0x00007fff80dcdff6 in __kill () (gdb) bt #0 0x00007fff80dcdff6 in __kill () #1 0x00007fff80e6f072 in abort () #2 0x00007fff811185d2 in __gnu_cxx::__verbose_terminate_handler () #3 0x00007fff81116ae1 in __cxxabiv1::__terminate () #4 0x00007fff81116b16 in std::terminate () #5 0x00007fff81116bfc in __cxa_throw () #6 0x000000010512afa4 in RemoteElem::n_nodes () #7 0x000000010510acf4 in DofMap::dof_indices () #8 0x000000010510e2d9 in DofMap::add_neighbors_to_send_list () #9 0x000000010511122f in DofMap::distribute_dofs () #10 0x000000010548509d in EquationSystems::reinit () #11 0x0000000101d65d5a in AGATAGeFEM::libMESH::LaplaceProblem::run (this=0x1019061a0) at ../../libs/libmesh/LaplaceProblem.cc:554 #12 0x0000000100004e67 in DoFields (deffile=<value temporarily unavailable, due to optimizations>, solidfile=<value temporarily unavailable, due to optimizations>, OutputBase=0x7fff5fbff6ad "test", gnuplot=false, refine=0.90000000000000002, course=0.10000000000000001) at main.cc:454 #13 0x0000000100008afd in operator==<char, std::char_traits<char>, std::allocator<char> > [inlined] () at /usr/include/c++/4.2.1/bits/basic_string.h:1247 #14 0x0000000100008afd in main (argc=5, argv=0x7fff5fbff510) at main.cc:1249 This I don't understand at all... Joa On Tue, Oct 13, 2009 at 01:18:49PM 0500, Roy Stogner wrote: > > > On Tue, 13 Oct 2009, Joa Ljungvall wrote: > > >As for getting inverted element, this means I've moved a node to the other > >side of the opposite face of my tet? This could very well be a bug in my > >code. I can, and will, check that I don't move nodes in an unreasnoble way. > > If you're sticking to first order shape functions, make sure you use > first order geometric elements as well. Moving a node past the > opposite face is the only way to invert a firstorder tet, but things > get more complicated when the mapping function is quadratic. >  > Roy 
From: Roy Stogner <roystgnr@ic...>  20091013 18:19:11

On Tue, 13 Oct 2009, Joa Ljungvall wrote: > As for getting inverted element, this means I've moved a node to the other > side of the opposite face of my tet? This could very well be a bug in my > code. I can, and will, check that I don't move nodes in an unreasnoble way. If you're sticking to first order shape functions, make sure you use first order geometric elements as well. Moving a node past the opposite face is the only way to invert a firstorder tet, but things get more complicated when the mapping function is quadratic.  Roy 
From: Joa Ljungvall <libmesh@jo...>  20091013 18:15:22

Hi again, Ok. Seems sensible to me. Now, I'm a nuclear physicist so FEM is not quite what I do for a living, but presently I'm giving it a try to see if it can improve some detector simulations we are doing, presently done with finite difference solvers, so bare with me even if I'm not 100% on target all the time. I`ve already tried with dealII and that worked ok, but for good or bad reasons (I'm not sure;) I want simple tets with first order shape functions, hence libmesh. As for getting inverted element, this means I've moved a node to the other side of the opposite face of my tet? This could very well be a bug in my code. I can, and will, check that I don't move nodes in an unreasnoble way. Also, I'll get back with a stack/call trace and the nodes of the failing element etc. But Paris time is 20:13 and I got other duties calling for me so I guess that will be tomorrows project. cheers Joa On Tue, Oct 13, 2009 at 12:47:26PM 0500, Roy Stogner wrote: > > On Tue, 13 Oct 2009, Joa Ljungvall wrote: > > >If I change the locations of the new nodes when they are made, i.e. somewhere > >deep down in the MeshRefinement class, can I do what I would like to do? > > I don't think that would make any difference. If moving nodes > eventually gives you an inverted element, it probably won't matter > exactly when the nodes are moved. > > I do think it would be a big mistake to start planning major lowlevel > changes before we fully understand why the less intrusive algorithm is > failing. Maybe get at that negative Jacobian failure in the debugger: > is the inverted element active? A parent? If the latter, what code > is calculating the Jacobian, and can it be worked around somehow? >  > Roy 
From: Roy Stogner <roystgnr@ic...>  20091013 17:47:41

On Tue, 13 Oct 2009, Joa Ljungvall wrote: > If I change the locations of the new nodes when they are made, i.e. somewhere > deep down in the MeshRefinement class, can I do what I would like to do? I don't think that would make any difference. If moving nodes eventually gives you an inverted element, it probably won't matter exactly when the nodes are moved. I do think it would be a big mistake to start planning major lowlevel changes before we fully understand why the less intrusive algorithm is failing. Maybe get at that negative Jacobian failure in the debugger: is the inverted element active? A parent? If the latter, what code is calculating the Jacobian, and can it be worked around somehow?  Roy 
From: Joa Ljungvall <libmesh@jo...>  20091013 17:36:21

Hmmm... If I change the locations of the new nodes when they are made, i.e. somewhere deep down in the MeshRefinement class, can I do what I would like to do? If I've understood everything correct a tet is subdivided by adding vertices halfway between the old ones. But there is nothing magic about that, or? One could choose to put the vertices somewhere else, as long as the element remains valid. Coarsening is of course much simpler and can remain the way it is. If this could work in princple, I'm willing to give it a try. A problem would be to define an interface with a geometry, but if I get to that... cheers Joa On Tue, Oct 13, 2009 at 12:17:03PM 0500, Roy Stogner wrote: > > >3) Copies all active elements to a new mesh, i.e. my new mesh have the right > > nodes locations etc. but no "refinement" (is this true if I do it right?) > > This won't work if there's any adaptive refinement in the original > mesh  libMesh relies on the parent element hierarchy to figure out > hanging node constraints. >  > Roy 
From: Roy Stogner <roystgnr@ic...>  20091013 17:17:13

> 3) Copies all active elements to a new mesh, i.e. my new mesh have the right > nodes locations etc. but no "refinement" (is this true if I do it right?) This won't work if there's any adaptive refinement in the original mesh  libMesh relies on the parent element hierarchy to figure out hanging node constraints.  Roy 
From: Joa Ljungvall <libmesh@jo...>  20091013 17:14:18

Hi again, If I: 0) Solve the equations one time... 1) Refine my mesh 2) Move my nodes 3) Copies all active elements to a new mesh, i.e. my new mesh have the right nodes locations etc. but no "refinement" (is this true if I do it right?) 4) I change mesh in my equation system 5) build my matrix and RHS, solves 6) > 1 until pleased It is clearly time consuming (alloc free system calls) and it will require almost twice the memory... apart from that, could it work? cheers Joa On Tue, Oct 13, 2009 at 11:58:30AM 0500, John Peterson wrote: > On Tue, Oct 13, 2009 at 11:40 AM, Joa Ljungvall <libmesh@...> wrote: > > It is quite possible that I move the wrong nodes the wrong way, but is my > > problem ;). The general question is, is this a possible route to take? I call > > this routine after refinement and coursening, before equation_systems.reinit(). > > I seem to remember there being some restriction when doing > refinement/coarsening and mesh redistribution, i.e. all mesh movement > had to be performed before any refinement/coarsening. I think it had > to do with the coarsening step, but the way we handle constraints also > assumes some level of parent is conforming with the neighbor... and I > don't think this is the case with mesh movement. > >  > John 
From: Roy Stogner <roystgnr@ic...>  20091013 17:06:06

On Tue, 13 Oct 2009, John Peterson wrote: > On Tue, Oct 13, 2009 at 11:40 AM, Joa Ljungvall <libmesh@...> wrote: >> It is quite possible that I move the wrong nodes the wrong way, but is my >> problem ;). The general question is, is this a possible route to take? I call >> this routine after refinement and coursening, before equation_systems.reinit(). > > I seem to remember there being some restriction when doing > refinement/coarsening and mesh redistribution, i.e. all mesh movement > had to be performed before any refinement/coarsening. I think it had > to do with the coarsening step, but the way we handle constraints also > assumes some level of parent is conforming with the neighbor... and I > don't think this is the case with mesh movement. The parent can always be made conforming with the neighbor in the case of a hanging node constraint  you just need to note that the hanging node's location is constrained as well, and keep that constraint satisfied. But failure to do that would just lead to potentially inaccurate projections and constraint equations. I'm not sure how someone would run into an inverted Jacobian... unless the coarse mesh was so far from the real boundary that snapping nodes to the boundary resulted in a completely twistedaround element.  Roy 
From: John Peterson <peterson@cf...>  20091013 16:59:06

On Tue, Oct 13, 2009 at 11:40 AM, Joa Ljungvall <libmesh@...> wrote: > It is quite possible that I move the wrong nodes the wrong way, but is my > problem ;). The general question is, is this a possible route to take? I call > this routine after refinement and coursening, before equation_systems.reinit(). I seem to remember there being some restriction when doing refinement/coarsening and mesh redistribution, i.e. all mesh movement had to be performed before any refinement/coarsening. I think it had to do with the coarsening step, but the way we handle constraints also assumes some level of parent is conforming with the neighbor... and I don't think this is the case with mesh movement.  John 
From: Joa Ljungvall <libmesh@jo...>  20091013 16:41:07

Hi again, during the day I been working a bit on the problem: Currently I have the exact geometry inside my program (implemented via CGS and GEANT4). What I have tried is to, after the refinement move the new boundary points using a code like this one (it tries to move all nodes on a boundary to the correct "radius" along the rhat vector void libMESH::AdjustMesh(Mesh &mesh,BaseBoundary *BC) { MeshBase::element_iterator el = mesh.active_elements_begin(); const MeshBase::element_iterator end_el = mesh.active_elements_end(); for ( ; el != end_el; ++el) { for (unsigned int s=0; s<(*el)>n_sides(); s++) if ((*el)>neighbor(s) == NULL) { AutoPtr<DofObject> face = (*el)>side(s); for(int atnode=0; atnode<3; ++atnode){ Node *node = (dynamic_cast<Elem*>(face.get())>set_node(atnode)); //if z==0 its ok if(fabs((*node)(2))>1e6){ if((*node)(2)<BC>CylLength()){//Simple case //Check which boundary is the closest double Router = BC>RAtZ(MakeHepVector((*node))); double Rinner = BC>RadiusOnCentralContact(MakeHepVector((*node))); double Rnode = sqrt((*node)(0)*(*node)(0)+(*node)(1)*(*node)(1)); if(fabs(RouterRnode)<fabs(RinnerRnode)){ (*node)(0)*=Router/Rnode; (*node)(1)*=Router/Rnode; } else { (*node)(0)*=Rinner/Rnode; (*node)(1)*=Rinner/Rnode; } } else {//Difficult, we have to check if the node should be on //one of the "circles" } } } } } } where BaseBoundary is a class to take care of the geometry. Trying with this I get EquationSystems n_systems()=1 System "Laplace" Type "LinearImplicit" Variables="u" Finite Element Types="LAGRANGE" Approximation Orders="FIRST" n_dofs()=715 n_local_dofs()=715 n_constrained_dofs()=0 n_vectors()=1 Beginning Solve 0 System has: 715 degrees of freedom. Linear solver converged at step: 5000, final residual: 1.1091e16 Refining the mesh... Beginning Solve 1 ERROR: negative Jacobian: 83.5253 in element 7069 [0] src/fe/fe_map.C, line 341, compiled Oct 11 2009 at 15:03:39 terminate called after throwing an instance of 'libMesh::LogicError' what(): Error in libMesh internal logic Abort trap It is quite possible that I move the wrong nodes the wrong way, but is my problem ;). The general question is, is this a possible route to take? I call this routine after refinement and coursening, before equation_systems.reinit(). cheers Joa On Tue, Oct 13, 2009 at 10:54:57AM 0500, John Peterson wrote: > On Tue, Oct 13, 2009 at 10:36 AM, Joa Ljungvall <libmesh@...> wrote: > > Hi, > > > > The problem is that I have to solve my equation on the same domain with > > very different boundary conditions, making a uniform refinement very > > inefficient and a waste of time, and worse in my case, RAM. So I do need > > to start with a very course mesh and refine. > > As David explained, there is unfortunately currently no "feedback" > mechanism between the mesh refinement procedure and an underlying > geometric description. > > One approach might be to maintain a suitably fine, lowerdimensional > (and hence, low memory) discretization of the boundary as a secondary > Mesh object in LibMesh, and then somehow use this fine discretization > when placing new points, but again, there is no existing mechanism for > doing this currently in the library. > >  > John 
From: John Peterson <peterson@cf...>  20091013 15:55:32

On Tue, Oct 13, 2009 at 10:36 AM, Joa Ljungvall <libmesh@...> wrote: > Hi, > > The problem is that I have to solve my equation on the same domain with > very different boundary conditions, making a uniform refinement very > inefficient and a waste of time, and worse in my case, RAM. So I do need > to start with a very course mesh and refine. As David explained, there is unfortunately currently no "feedback" mechanism between the mesh refinement procedure and an underlying geometric description. One approach might be to maintain a suitably fine, lowerdimensional (and hence, low memory) discretization of the boundary as a secondary Mesh object in LibMesh, and then somehow use this fine discretization when placing new points, but again, there is no existing mechanism for doing this currently in the library.  John 
From: Joa Ljungvall <libmesh@jo...>  20091013 15:36:28

Hi, The problem is that I have to solve my equation on the same domain with very different boundary conditions, making a uniform refinement very inefficient and a waste of time, and worse in my case, RAM. So I do need to start with a very course mesh and refine. cheers Joa On Tue, Oct 13, 2009 at 09:55:54AM 0400, David Knezevic wrote: > If you generate a mesh in gmsh that is sufficiently fine that a mesh > of second order elements captures the geometry well enough, then you > can read that mesh into libMesh, and just use libMesh's adaptive > refinement as in the examples. In that situation, libMesh's adaptive > refinement will interpolate the quadratic boundaries when you refine > the boundary elements... > > But if you want to start with a very coarse mesh, then you might > have to move boundary nodes around etc. I've never had to do that > myself, so perhaps someone else on the list can offer you some > choice advice. > >  Dave > > > Joa Ljungvall wrote: > >Hi, > > > >I'm not sure I understood the answer. I want to start with a very > >course mesh, and refine it based on the solution on the course(r) > >mesh, i.e. adaptive > >refinment. So using gmsh I would have to communicate the solution > >in each step and tell gmsh which regions to refine, or? And if so, > >how? Further more, my domain have some regions where a cylinder it > >cut by a hexagonal, so a quadratic approximation would not do so > >well, would it? > > > > > >cheers > > > > > >Joa > > > >On Tue, Oct 13, 2009 at 09:24:53AM 0400, David Knezevic wrote: > >>I think the simplest thing to do is use second order elements in gmsh. Then > >>when you refine the new nodes will interpolate the quadratic > >>approximation to > >>the boundary of your domain. > >> > >> Dave > >> > >> > >> > >>Joa Ljungvall wrote: > >>>Hi all, > >>> > >>>I would like to use libmesh to solve a rather simple equation (Laplace/poisson) > >>>but in a domain with a somewhat funny shape of the boundary. To do > >>>this I created a mesh using gmsh, modified example 14 a bit so it > >>>reads my mesh > >>>instead of the lshaped domain. My problem is that when I refine I get "flat" > >>>surfaces that does not follow my boundary (which is not flat;). How do I go > >>>about and move the new boundary vertices of my tets (I use tets) to the real > >>>boundary? As for the geometry etc. I now how to do it, I`m just not so familiar > >>>with libmesh. > >>> > >>> > >>>kind regards > >>> > >>>Joa Ljungvall > >>> > >>> > >>> > >>>Come build with us! The BlackBerry(R) Developer Conference in SF, CA > >>>is the only developer event you need to attend this year. Jumpstart your > >>>developing skills, take BlackBerry mobile applications to market > >>>and stay ahead of the curve. Join us from November 9  12, 2009. > >>>Register now! > >>>http://p.sf.net/sfu/devconference > >>>_______________________________________________ > >>>Libmeshusers mailing list > >>>Libmeshusers@... > >>>https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Joa Ljungvall <libmesh@jo...>  20091013 14:02:00

Hi, I'm not sure I understood the answer. I want to start with a very course mesh, and refine it based on the solution on the course(r) mesh, i.e. adaptive refinment. So using gmsh I would have to communicate the solution in each step and tell gmsh which regions to refine, or? And if so, how? Further more, my domain have some regions where a cylinder it cut by a hexagonal, so a quadratic approximation would not do so well, would it? cheers Joa On Tue, Oct 13, 2009 at 09:24:53AM 0400, David Knezevic wrote: > I think the simplest thing to do is use second order elements in gmsh. Then > when you refine the new nodes will interpolate the quadratic > approximation to > the boundary of your domain. > >  Dave > > > > Joa Ljungvall wrote: > >Hi all, > > > >I would like to use libmesh to solve a rather simple equation (Laplace/poisson) > >but in a domain with a somewhat funny shape of the boundary. To do > >this I created a mesh using gmsh, modified example 14 a bit so it > >reads my mesh > >instead of the lshaped domain. My problem is that when I refine I get "flat" > >surfaces that does not follow my boundary (which is not flat;). How do I go > >about and move the new boundary vertices of my tets (I use tets) to the real > >boundary? As for the geometry etc. I now how to do it, I`m just not so familiar > >with libmesh. > > > > > >kind regards > > > >Joa Ljungvall > > > > > > > >Come build with us! The BlackBerry(R) Developer Conference in SF, CA > >is the only developer event you need to attend this year. Jumpstart your > >developing skills, take BlackBerry mobile applications to market > >and stay ahead of the curve. Join us from November 9  12, 2009. > >Register now! > >http://p.sf.net/sfu/devconference > >_______________________________________________ > >Libmeshusers mailing list > >Libmeshusers@... > >https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: David Knezevic <dknez@MIT.EDU>  20091013 13:59:35

If you generate a mesh in gmsh that is sufficiently fine that a mesh of second order elements captures the geometry well enough, then you can read that mesh into libMesh, and just use libMesh's adaptive refinement as in the examples. In that situation, libMesh's adaptive refinement will interpolate the quadratic boundaries when you refine the boundary elements... But if you want to start with a very coarse mesh, then you might have to move boundary nodes around etc. I've never had to do that myself, so perhaps someone else on the list can offer you some choice advice.  Dave Joa Ljungvall wrote: > Hi, > > I'm not sure I understood the answer. I want to start with a very course mesh, > and refine it based on the solution on the course(r) mesh, i.e. adaptive > refinment. So using gmsh I would have to communicate the solution in each step > and tell gmsh which regions to refine, or? And if so, how? Further more, my > domain have some regions where a cylinder it cut by a hexagonal, so a > quadratic approximation would not do so well, would it? > > > cheers > > > Joa > > On Tue, Oct 13, 2009 at 09:24:53AM 0400, David Knezevic wrote: > >> I think the simplest thing to do is use second order elements in gmsh. Then >> when you refine the new nodes will interpolate the quadratic >> approximation to >> the boundary of your domain. >> >>  Dave >> >> >> >> Joa Ljungvall wrote: >> >>> Hi all, >>> >>> I would like to use libmesh to solve a rather simple equation (Laplace/poisson) >>> but in a domain with a somewhat funny shape of the boundary. To do >>> this I created a mesh using gmsh, modified example 14 a bit so it >>> reads my mesh >>> instead of the lshaped domain. My problem is that when I refine I get "flat" >>> surfaces that does not follow my boundary (which is not flat;). How do I go >>> about and move the new boundary vertices of my tets (I use tets) to the real >>> boundary? As for the geometry etc. I now how to do it, I`m just not so familiar >>> with libmesh. >>> >>> >>> kind regards >>> >>> Joa Ljungvall >>> >>> >>>  >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market >>> and stay ahead of the curve. Join us from November 9  12, 2009. >>> Register now! >>> http://p.sf.net/sfu/devconference >>> _______________________________________________ >>> Libmeshusers mailing list >>> Libmeshusers@... >>> https://lists.sourceforge.net/lists/listinfo/libmeshusers >>> 
From: David Knezevic <dknez@MIT.EDU>  20091013 13:25:40

I think the simplest thing to do is use second order elements in gmsh. Then when you refine the new nodes will interpolate the quadratic approximation to the boundary of your domain.  Dave Joa Ljungvall wrote: > Hi all, > > I would like to use libmesh to solve a rather simple equation (Laplace/poisson) > but in a domain with a somewhat funny shape of the boundary. To do this I > created a mesh using gmsh, modified example 14 a bit so it reads my mesh > instead of the lshaped domain. My problem is that when I refine I get "flat" > surfaces that does not follow my boundary (which is not flat;). How do I go > about and move the new boundary vertices of my tets (I use tets) to the real > boundary? As for the geometry etc. I now how to do it, I`m just not so familiar > with libmesh. > > > kind regards > > Joa Ljungvall > > >  > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9  12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Joa Ljungvall <libmesh@jo...>  20091013 13:17:26

Hi all, I would like to use libmesh to solve a rather simple equation (Laplace/poisson) but in a domain with a somewhat funny shape of the boundary. To do this I created a mesh using gmsh, modified example 14 a bit so it reads my mesh instead of the lshaped domain. My problem is that when I refine I get "flat" surfaces that does not follow my boundary (which is not flat;). How do I go about and move the new boundary vertices of my tets (I use tets) to the real boundary? As for the geometry etc. I now how to do it, I`m just not so familiar with libmesh. kind regards Joa Ljungvall 