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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1

2

3
(1) 
4

5

6

7

8
(2) 
9
(6) 
10
(2) 
11
(10) 
12
(5) 
13
(3) 
14

15

16
(7) 
17

18
(2) 
19
(5) 
20
(2) 
21

22

23
(3) 
24
(11) 
25

26
(1) 
27

28







From: Roy Stogner <roystgnr@ic...>  20100226 23:20:06

On Fri, 26 Feb 2010, Andre Luis Rossa wrote: >> You'll want to reinitialize that vector as GHOSTED or >> SERIAL if you need each processor to be able to directly access ghost >> DoF values or all values, respectively. > > Roy, > I haven't found a method to reinitialize the additional vector as you have > said me to do. > I've tried NumericVector::init(const unsigned int, const unsigned int, > const bool) or tried NumericVector::init(const unsigned int, const bool) > passing the global mesh numbers but it haven't worked. That should have worked to give you a SERIAL vector. But bear in mind that no matter what kind of vector you build, you'll have to handle synchronizing it across processors yourself. Which is currently a bit of a hack in libMesh  see the "temporary parallel vector" code in system_projection.C for an example.  Roy 
From: Andrea Hawkins <andjhawkins@gm...>  20100224 18:34:58

> There are some nice options in there to plot the linear solver convergence and nonlinear solution update  it can be informative. Thanks for these! I did not realize they were there. (PETSc is so useful when you know what you're looking for!) Using these I was able to find my problem. This generalized alpha is a predictorcorrector method. At the predictor stage I had been updating "local" (ghosted solution values) without updating the normal solution, thus when I entered the newton update and was using the normal solution, it clearly was not doing what it needed to. Thank you both, Jed and Ben, for you thoughts! On to the next bug! =) Andrea > > Ben > > >  Original Message  > From: Andrea Hawkins <andjhawkins@...> > To: Kirk, Benjamin (JSCEG311); libmeshusers <libmeshusers@...> > Sent: Wed Feb 24 10:18:46 2010 > Subject: Re: [Libmeshusers] Time Stepping > > That wouldn't explain it working after restarts though, would it? > Because with a restart, I'm seeding the initial condition with the > previous solution. So, the linear solver should be using this as an > initial guess, correct? > > Thanks, > Andrea > > > > On Wed, Feb 24, 2010 at 10:14 AM, Kirk, Benjamin (JSCEG311) > <benjamin.kirk1@...> wrote: >> Since you are rolling your own newton you might need to set the linear solver initial guess to 0 (the newton delta)  by default the linear implicit system uses the current solution as the krylov initial guess. >> >> Obviously this could be horribly wrong as you converge nonlinearly... >> >> Ben >> >> >> >>  Original Message  >> From: Andrea Hawkins <andjhawkins@...> >> To: libmeshusers <libmeshusers@...> >> Sent: Wed Feb 24 09:59:14 2010 >> Subject: [Libmeshusers] Time Stepping >> >> Hello >> >> I am running a nonlinear timedependent simulation and am currently >> attempting to implement the generalized alpha time stepping algorithm. >> As default I use PETSc for my linear solves and updates, but this >> method requires I write my own newton update. >> >> I had been setting those options outside of the time loop, but found >> out that the PetscNonlinearSolver was getting cleared after every time >> step so moving that into the time loop solved that problem. However, >> I'm now seeing some very peculiar behavior... The first time step >> things go fine. The second time step, things also seem to go fine, >> however the newton solver actually ends up converging back to the same >> solution it started with so that the third time step starts with the >> same values as the second. I have actually gone into the newton solver >> and seen that the first newton steps leave the initial values but >> converge back. >> >> While this issue could be many things, I have double checked (at >> length) with people familiar with this algorithm that I'm at least >> attempting to implement the correct thing. >> >> Is there something else I should be concerned about getting reset >> every time step? Because when I run it for only one time step and then >> restart and repeat, I do not see this behavior. >> >> Thanks! >> Andrea >> >>  >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and finetune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intelswdev >> _______________________________________________ >> Libmeshusers mailing list >> Libmeshusers@... >> https://lists.sourceforge.net/lists/listinfo/libmeshusers >> > 
From: Jed Brown <jed@59...>  20100224 18:13:13

On Wed, 24 Feb 2010 10:15:21 0600, Andrea Hawkins <andjhawkins@...> wrote: > I am using the SNES, I just utilized the SNESLineSearchSet to set my own update. Okay, is this better than the standard one for your problem? > So, if I do a diff between the output after the final newton step in > the zeroth time step with the the output after the first newton step > of the 1st time step I get > > broglie $ diff step0 step1 > 19c19 > < total: nonzeros=32153, allocated nonzeros=33489 >  > > total: nonzeros=32153, allocated nonzeros=40509 > 24c24 > < total: nonzeros=32153, allocated nonzeros=38169 >  > > total: nonzeros=32153, allocated nonzeros=40509 > 27d26 > < This is odd. Do you intend for the sparsity pattern of the matrix to change? If it really shouldn't change, then try setting MAT_NEW_NONZERO_ALLOCATION_ERR and see what triggers the error. > That wouldn't explain it working after restarts though, would it? > Because with a restart, I'm seeding the initial condition with the > previous solution. So, the linear solver should be using this as an > initial guess, correct? Do you mean that you're calling SNESSolve with the current solution in X? That just specifies the first Newton iterate, the Krylov solve will still start with a zero initial guess. (As a general rule with Newton, if you know a better initial guess than 0 for the linear solve, then you should have evaluated the function there.) PETSc solvers should be completely configured before the first XXXSolve. Modification after this should only be done if your code is taking active control (i.e. checking how convergence is proceeding and changing tolerances/preconditioners/etc in some problemspecific way). Maybe if you describe all the ways you modify the SNES/KSP/PC after the first call to SNESSolve, I can guess what is going on. Jed 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20100224 16:23:06

Yeah, and also I didn't realize you were using snes. cat ~benkirk/codes/fins/trunk/examples/Make.common There are some nice options in there to plot the linear solver convergence and nonlinear solution update  it can be informative. Ben  Original Message  From: Andrea Hawkins <andjhawkins@...> To: Kirk, Benjamin (JSCEG311); libmeshusers <libmeshusers@...> Sent: Wed Feb 24 10:18:46 2010 Subject: Re: [Libmeshusers] Time Stepping That wouldn't explain it working after restarts though, would it? Because with a restart, I'm seeding the initial condition with the previous solution. So, the linear solver should be using this as an initial guess, correct? Thanks, Andrea On Wed, Feb 24, 2010 at 10:14 AM, Kirk, Benjamin (JSCEG311) <benjamin.kirk1@...> wrote: > Since you are rolling your own newton you might need to set the linear solver initial guess to 0 (the newton delta)  by default the linear implicit system uses the current solution as the krylov initial guess. > > Obviously this could be horribly wrong as you converge nonlinearly... > > Ben > > > >  Original Message  > From: Andrea Hawkins <andjhawkins@...> > To: libmeshusers <libmeshusers@...> > Sent: Wed Feb 24 09:59:14 2010 > Subject: [Libmeshusers] Time Stepping > > Hello > > I am running a nonlinear timedependent simulation and am currently > attempting to implement the generalized alpha time stepping algorithm. > As default I use PETSc for my linear solves and updates, but this > method requires I write my own newton update. > > I had been setting those options outside of the time loop, but found > out that the PetscNonlinearSolver was getting cleared after every time > step so moving that into the time loop solved that problem. However, > I'm now seeing some very peculiar behavior... The first time step > things go fine. The second time step, things also seem to go fine, > however the newton solver actually ends up converging back to the same > solution it started with so that the third time step starts with the > same values as the second. I have actually gone into the newton solver > and seen that the first newton steps leave the initial values but > converge back. > > While this issue could be many things, I have double checked (at > length) with people familiar with this algorithm that I'm at least > attempting to implement the correct thing. > > Is there something else I should be concerned about getting reset > every time step? Because when I run it for only one time step and then > restart and repeat, I do not see this behavior. > > Thanks! > Andrea > >  > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and finetune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intelswdev > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Andrea Hawkins <andjhawkins@gm...>  20100224 16:18:56

That wouldn't explain it working after restarts though, would it? Because with a restart, I'm seeding the initial condition with the previous solution. So, the linear solver should be using this as an initial guess, correct? Thanks, Andrea On Wed, Feb 24, 2010 at 10:14 AM, Kirk, Benjamin (JSCEG311) <benjamin.kirk1@...> wrote: > Since you are rolling your own newton you might need to set the linear solver initial guess to 0 (the newton delta)  by default the linear implicit system uses the current solution as the krylov initial guess. > > Obviously this could be horribly wrong as you converge nonlinearly... > > Ben > > > >  Original Message  > From: Andrea Hawkins <andjhawkins@...> > To: libmeshusers <libmeshusers@...> > Sent: Wed Feb 24 09:59:14 2010 > Subject: [Libmeshusers] Time Stepping > > Hello > > I am running a nonlinear timedependent simulation and am currently > attempting to implement the generalized alpha time stepping algorithm. > As default I use PETSc for my linear solves and updates, but this > method requires I write my own newton update. > > I had been setting those options outside of the time loop, but found > out that the PetscNonlinearSolver was getting cleared after every time > step so moving that into the time loop solved that problem. However, > I'm now seeing some very peculiar behavior... The first time step > things go fine. The second time step, things also seem to go fine, > however the newton solver actually ends up converging back to the same > solution it started with so that the third time step starts with the > same values as the second. I have actually gone into the newton solver > and seen that the first newton steps leave the initial values but > converge back. > > While this issue could be many things, I have double checked (at > length) with people familiar with this algorithm that I'm at least > attempting to implement the correct thing. > > Is there something else I should be concerned about getting reset > every time step? Because when I run it for only one time step and then > restart and repeat, I do not see this behavior. > > Thanks! > Andrea > >  > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and finetune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intelswdev > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20100224 16:15:43

Since you are rolling your own newton you might need to set the linear solver initial guess to 0 (the newton delta)  by default the linear implicit system uses the current solution as the krylov initial guess. Obviously this could be horribly wrong as you converge nonlinearly... Ben  Original Message  From: Andrea Hawkins <andjhawkins@...> To: libmeshusers <libmeshusers@...> Sent: Wed Feb 24 09:59:14 2010 Subject: [Libmeshusers] Time Stepping Hello I am running a nonlinear timedependent simulation and am currently attempting to implement the generalized alpha time stepping algorithm. As default I use PETSc for my linear solves and updates, but this method requires I write my own newton update. I had been setting those options outside of the time loop, but found out that the PetscNonlinearSolver was getting cleared after every time step so moving that into the time loop solved that problem. However, I'm now seeing some very peculiar behavior... The first time step things go fine. The second time step, things also seem to go fine, however the newton solver actually ends up converging back to the same solution it started with so that the third time step starts with the same values as the second. I have actually gone into the newton solver and seen that the first newton steps leave the initial values but converge back. While this issue could be many things, I have double checked (at length) with people familiar with this algorithm that I'm at least attempting to implement the correct thing. Is there something else I should be concerned about getting reset every time step? Because when I run it for only one time step and then restart and repeat, I do not see this behavior. Thanks! Andrea  Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and finetune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intelswdev _______________________________________________ Libmeshusers mailing list Libmeshusers@... https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Andrea Hawkins <andjhawkins@gm...>  20100224 16:15:33

I am using the SNES, I just utilized the SNESLineSearchSet to set my own update. So, if I do a diff between the output after the final newton step in the zeroth time step with the the output after the first newton step of the 1st time step I get broglie $ diff step0 step1 19c19 < total: nonzeros=32153, allocated nonzeros=33489  > total: nonzeros=32153, allocated nonzeros=40509 24c24 < total: nonzeros=32153, allocated nonzeros=38169  > total: nonzeros=32153, allocated nonzeros=40509 27d26 < This wouldn't be causing the behavior would it? Thanks, Andrea On Wed, Feb 24, 2010 at 10:08 AM, Jed Brown <jed@...> wrote: > On Wed, 24 Feb 2010 09:59:14 0600, Andrea Hawkins <andjhawkins@...> wrote: >> Is there something else I should be concerned about getting reset >> every time step? > > Does anything change if you run with ksp_view (this will dump solver > details at the end of each solve). If you are using Newtonlike > algorithms, there is significant benefit to using SNES (through > libmesh's wrapper if you like) since this will give you significant > algorithmic flexibility and robustness improvements over rolling your > own Newton. > > Jed > 
From: Jed Brown <jed@59...>  20100224 16:05:39

On Wed, 24 Feb 2010 09:59:14 0600, Andrea Hawkins <andjhawkins@...> wrote: > Is there something else I should be concerned about getting reset > every time step? Does anything change if you run with ksp_view (this will dump solver details at the end of each solve). If you are using Newtonlike algorithms, there is significant benefit to using SNES (through libmesh's wrapper if you like) since this will give you significant algorithmic flexibility and robustness improvements over rolling your own Newton. Jed 
From: Andrea Hawkins <andjhawkins@gm...>  20100224 15:59:23

Hello I am running a nonlinear timedependent simulation and am currently attempting to implement the generalized alpha time stepping algorithm. As default I use PETSc for my linear solves and updates, but this method requires I write my own newton update. I had been setting those options outside of the time loop, but found out that the PetscNonlinearSolver was getting cleared after every time step so moving that into the time loop solved that problem. However, I'm now seeing some very peculiar behavior... The first time step things go fine. The second time step, things also seem to go fine, however the newton solver actually ends up converging back to the same solution it started with so that the third time step starts with the same values as the second. I have actually gone into the newton solver and seen that the first newton steps leave the initial values but converge back. While this issue could be many things, I have double checked (at length) with people familiar with this algorithm that I'm at least attempting to implement the correct thing. Is there something else I should be concerned about getting reset every time step? Because when I run it for only one time step and then restart and repeat, I do not see this behavior. Thanks! Andrea 
From: Roy Stogner <roystgnr@ic...>  20100224 02:20:21

On Tue, 23 Feb 2010, Yujie wrote: > Without mesh refinement, how to solve the linear equation with multiple > rhses. In current libmesh framework, > > one can use "equation_systems.get_system("system").solve()" to get the > solution with one rhs. > > In .solve(), there are assemble() and solver() functions. rhs can be > replaced in assemble(). However, which parameters need to be reinitialized > after finishing one rhs? Whether it is ok to call equation_systems.reinit() > to reinitialize necessary parameters for multiple rhses? Thanks a lot. Depends on how complicated your system is, but in general you shouldn't need to reset anything except (perhaps) the solution (which gets used as a starting guess in iterative solvers) before solving with a new right hand side. Take a look at the parameter sensitivity methods in implicit_system.C for some examples; since we use multiple solution and rhs vectors there we don't have to reinitialize anything at all.  Roy 
From: Yujie <recrusader@gm...>  20100224 02:19:16

Thanks, Roy. According to your advice. Maybe, it should be better to clear the solution vector after finishing the rhs. Regards, Yujie On Tue, Feb 23, 2010 at 7:48 PM, Roy Stogner <roystgnr@...>wrote: > > On Tue, 23 Feb 2010, Yujie wrote: > > Without mesh refinement, how to solve the linear equation with multiple >> rhses. In current libmesh framework, >> >> one can use "equation_systems.get_system("system").solve()" to get the >> solution with one rhs. >> >> In .solve(), there are assemble() and solver() functions. rhs can be >> replaced in assemble(). However, which parameters need to be reinitialized >> after finishing one rhs? Whether it is ok to call >> equation_systems.reinit() >> to reinitialize necessary parameters for multiple rhses? Thanks a lot. >> > > Depends on how complicated your system is, but in general you > shouldn't need to reset anything except (perhaps) the solution (which > gets used as a starting guess in iterative solvers) before solving > with a new right hand side. Take a look at the parameter sensitivity > methods in implicit_system.C for some examples; since we use multiple > solution and rhs vectors there we don't have to reinitialize anything > at all. >  > Roy > 
From: Yujie <recrusader@gm...>  20100224 01:14:23

Dear Libmesh Developers, Without mesh refinement, how to solve the linear equation with multiple rhses. In current libmesh framework, one can use "equation_systems.get_system("system").solve()" to get the solution with one rhs. In .solve(), there are assemble() and solver() functions. rhs can be replaced in assemble(). However, which parameters need to be reinitialized after finishing one rhs? Whether it is ok to call equation_systems.reinit() to reinitialize necessary parameters for multiple rhses? Thanks a lot. Regards, Yujie 
From: Roy Stogner <roystgnr@ic...>  20100223 22:00:28

On Tue, 23 Feb 2010, Andre Luis Rossa wrote: > I've run libMesh with METHOD=dbg and I've found out what's wrong when the > program tries to access the system's additional vector using more than one > processor (unfortunetly I'm not sure how to fix it, yet). > > The out of range error occurs because, apparently, the additional vector is > dimentioned only for the local (processor domain) nodes. > > I've generated a very small simple mesh (2x2x1 hexa 8). I've executed it with > only 2 processors. > > The error occurs when processor 1 try to compute something for a element > which nodes are over the interface of the two processors domain (i.e., a node > that belongs to both domains). The dof map returns a global index number that > belongs to the processor one's index range. > > As I've verified, the system's "current_solution" is dimentioned for the > global number nodes so it doesn't present this problem. > > So, is there a way to avoid this index error? > Is there something like a "update()" (as the solution vector) method for this > case? > Or maybe should it be realocated for the global number of nodes before using > it? That's right. System::add_vector() by default creates a vector of type PARALLEL. You'll want to reinitialize that vector as GHOSTED or SERIAL if you need each processor to be able to directly access ghost DoF values or all values, respectively.  Roy 
From: Roy Stogner <roystgnr@ic...>  20100223 04:12:57

On Mon, 22 Feb 2010, Rahul Sampath wrote: > I would like to know if it is possible for a processor to own a node > but not own any elements that touch that node. I know that this > situation is sometimes possible if a spacefilling curve partition is > used, but I am not sure if LibMesh allows this or does something to > prevent this from happening. We partition elements first, then assign nodes to one of their owning elements' processors. The only catch I can think of is that users can use a linear FE on a quadratic Elem, in which case a hanging node can be owned by a processor that doesn't own any of the elements on which its shape functions are directly supported.  Roy 
From: Rahul Sampath <rahul.sampath@gm...>  20100223 03:53:04

Hi: I would like to know if it is possible for a processor to own a node but not own any elements that touch that node. I know that this situation is sometimes possible if a spacefilling curve partition is used, but I am not sure if LibMesh allows this or does something to prevent this from happening. Thank you. Regards, Rahul 
From: Rahul Sampath <rahul.sampath@gm...>  20100220 16:28:17

Hi: I want to set different boundary conditions on each of the dof at a particular node. In CUBIT I can create different BC sets with different boundary ids for this. For example, X displacement at nodes on Z = 0 surface could have boundary id = 1 and Y displacements at the same nodes could have a different boundary id. I looked at the read function in LibMesh, which reads the mesh. It only seems to be adding the pair (node, boundary_id) but not the corresponding values or dof_id. Is there a way to read this from the mesh as well or does it have to specified externally by my program. Thank you. Rahul 
From: Karen Lee <kylkaren@gm...>  20100220 05:07:36

Thanks for your response! On Fri, Feb 19, 2010 at 6:01 PM, Roy Stogner <roystgnr@...>wrote: > > On Fri, 19 Feb 2010, Karen Lee wrote: > > const Real value = exact_solution(xf, yf); >> >> is the line that gives the value, so if I wanted to impose that the >> values at the boundary are 0, I just put 0 instead right? >> > > Right. In fact, in a linear system like ex3 the whole residual drops > out in this case, and homogeneous Dirichlet boundaries only end up > affecting your matrix. For nonlinear systems things are trickier > depending on your solver; see ex18 for an example. > > > My system is linear, so I'll just set things to 0. > The other thing is, I'm not sure whether BoundaryMesh can just locate >> the boundary. I use tetgen .node and .ele files, and it >> doesn't seem that the .face files are read by libmesh, and so I'm >> wondering how it's able to locate the boundary... Or do I add >> some tags and say that certain nodes and elements are on the boundary? >> > > The boundary is currently implicitly defined: if an element doesn't > have a neighbor on one side, that side is a boundary side. If a node > is on a boundary side, that node is a boundary node. > > That works fine for most domains, which are the interior of their own > closure. If you've got something more complicated, let us know, but > don't be too optimistic. We currently break when refining domains > with infinitely thin slits, for one embarrassing example. > My domain has no holes. Should be ok I guess =) Thanks, Karen 
From: Roy Stogner <roystgnr@ic...>  20100219 23:06:02

On Fri, 19 Feb 2010, Karen Lee wrote: > const Real value = exact_solution(xf, yf); > > is the line that gives the value, so if I wanted to impose that the > values at the boundary are 0, I just put 0 instead right? Right. In fact, in a linear system like ex3 the whole residual drops out in this case, and homogeneous Dirichlet boundaries only end up affecting your matrix. For nonlinear systems things are trickier depending on your solver; see ex18 for an example. > The other thing is, I'm not sure whether BoundaryMesh can just locate > the boundary. I use tetgen .node and .ele files, and it > doesn't seem that the .face files are read by libmesh, and so I'm > wondering how it's able to locate the boundary... Or do I add > some tags and say that certain nodes and elements are on the boundary? The boundary is currently implicitly defined: if an element doesn't have a neighbor on one side, that side is a boundary side. If a node is on a boundary side, that node is a boundary node. That works fine for most domains, which are the interior of their own closure. If you've got something more complicated, let us know, but don't be too optimistic. We currently break when refining domains with infinitely thin slits, for one embarrassing example.  Roy 
From: John Peterson <peterson@cf...>  20100219 23:05:40

On Fri, Feb 19, 2010 at 4:40 PM, Karen Lee <kylkaren@...> wrote: > Dear Libmesh users, > > I'm wondering how we can impose boundary conditions. I'm looking at example > 3, and it says that it handles the Dirichlet BC by a penalty function. I > wanted to check that: > > const Real value = exact_solution(xf, yf); > > is the line that gives the value, so if I wanted to impose that the > values at the boundary are 0, I just put 0 instead right? That's right. > The other thing is, I'm not sure whether BoundaryMesh can just locate > the boundary. I use tetgen .node and .ele files, and it > doesn't seem that the .face files are read by libmesh, and so I'm > wondering how it's able to locate the boundary... Or do I add > some tags and say that certain nodes and elements are on the boundary? Libmesh determines elements which are on the boundary automatically. After the Mesh::find_neighbors routine, which is usually called from the Mesh::prepare_for_use function, elements with NULL neighbors are boundary elements. We do not maintain a separate list of such elements, though, as far as I know.  John 
From: Karen Lee <kylkaren@gm...>  20100219 22:40:44

Dear Libmesh users, I'm wondering how we can impose boundary conditions. I'm looking at example 3, and it says that it handles the Dirichlet BC by a penalty function. I wanted to check that: const Real value = exact_solution(xf, yf); is the line that gives the value, so if I wanted to impose that the values at the boundary are 0, I just put 0 instead right? The other thing is, I'm not sure whether BoundaryMesh can just locate the boundary. I use tetgen .node and .ele files, and it doesn't seem that the .face files are read by libmesh, and so I'm wondering how it's able to locate the boundary... Or do I add some tags and say that certain nodes and elements are on the boundary? Thank you so much, Karen 
From: Roy Stogner <roystgnr@ic...>  20100219 01:07:37

Actually, after looking at the amount of work required for a change nobody is going to use, I'm just going to skip it. PointLocatorList already breaks unless your mesh is the Voronoi diagram of the elements' centroids and you have a fetish for using O(N) instead of O(NlogN) algorithms; if any such user exists, asking that the mesh be serial as well probably isn't going to be the straw that breaks the camel's back. Never mind...  Roy On Thu, 18 Feb 2010, Roy Stogner wrote: > From now on, operator(Point &p) will search for an active element > containing p, not just the element nearest p, and if it doesn't find a > containing active element it will just return NULL. This is to make > it more consistent with PointLocatorTree, and to make it useful on > ParallelMesh. > > This is a major behavior change, so I feel compelled to mention it on > the lists, but it's also a behavior change in code nobody uses or > should use, so I won't have trouble sleeping tonight. >  > Roy > >  > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and finetune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intelswdev > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel > 
From: Roy Stogner <roystgnr@ic...>  20100219 01:01:58

>From now on, operator(Point &p) will search for an active element containing p, not just the element nearest p, and if it doesn't find a containing active element it will just return NULL. This is to make it more consistent with PointLocatorTree, and to make it useful on ParallelMesh. This is a major behavior change, so I feel compelled to mention it on the lists, but it's also a behavior change in code nobody uses or should use, so I won't have trouble sleeping tonight.  Roy 
From: Roy Stogner <roystgnr@ic...>  20100218 19:34:28

We're doing some UQ work with libMesh now that involves more complicated MPI setups. One of those (letting libMesh's COMM_WORLD be a subset of the real COMM_WORLD) worked beautifully out of the box, but another (doing parallel activity over yetathird communicator) wasn't nicely encapsulated in our Parallel:: utilities. So, I've fixed that. But that required large changes to parallel.h, which are large tricky changes thanks to C++'s "function templates can only be overloaded, not partially specialized" rules. No problems in my regression tests here, but anyone else updating past r3674 might want to do a quick mpirun test themselves afterward.  Roy 
From: Derek Gaston <derek.gaston@in...>  20100218 19:08:44

Hello all, I thought most people on these lists would be interested in job postings in my group at Idaho National Laboratory. We are looking for good computational scientists of all levels... and particularly those with experience working with libMesh! If you are interested please go to the INL career website ( http://inlrecruiting.inel.gov/psp/hrdex89/EMPLOYEE/HRMS/c/HRS_HRAM.HRS_CE.GBL?FolderPath=PORTAL_ROOT_OBJECT.HC_HRS_CE_GBL2&IsFolder=false&IgnoreParamTempl=FolderPath%2cIsFolder ). If you do a search for "computational". The three job adds will come up at the top. They have ID #'s of: 5337, 5385 and 5386. 5385 is an entry level position. Pretty much a fresh PhD or Masters Degree graduate. 5386 is for someone with a little more experience, with a preference towards having some knowledge in a particular physical field (like solid mechanics or fluid flow etc.). 5337 is a senior level position. Here we're looking for someone with 20+ years of experience in computational materials science. Also on that career website are several internship opportunities. These are summer positions within the laboratory. If you're still a student and are looking for some work experience in computational areas feel free to apply to our internship posting which is # 5296. It will be on the same page when you search for "computational" but will be a bit further down the page. If you feel you fit in more than one position... by all means apply for more than one! The descriptions above (and in the actual postings) are just loose guidelines. If we think you're good we'll make it work. Also, even though there are only 4 postings... we might hire more than 4 people... If there are others who aren't on these mailing lists that you think would be interested in these positions... please forward this email! Also, please use my name ( Derek Gaston ) as a referral if you do actually apply. If you have any questions at all... don't hesitate to hit me with an email. Derek 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20100216 21:09:05

You can infer this from the 2d numbering. For example, for the HEX8, the base is oriented wrt (xi,eta) according to the QUAD4, and zeta is the vertical direction. On 2/16/10 3:04 PM, "Roy Stogner" <roystgnr@...> wrote: > > > On Tue, 16 Feb 2010, Rahul Sampath wrote: > >> HEX8: 7 6 >> oo >> /: / >> / : /  >> 4 / : 5 /  >> oo  >>  o.......o 2 >>  .3  / >>  .  / >> . / >> oo >> 0 1 >> >> TET4: >> 3 >> o >> /\ >> /  \ >> /  \ >> 0 o......o 2 >> \  / >> \  / >> \/ >> o >> 1 >> >> However, you have not shown the coordinate axes. I need to know the >> following: >> 1) The relationship between the local coordinate system and the local >> node numbering scheme. For example, In Hex8 whether the edge 01 is >> parallel to the local xi or eta axes. >> >> 2) The relationship between the physical global coordinate system and >> the local coordinate system. >> >> I believe you must already be using some convention for both to be >> able to compute the Jacobian of the transformation. It would be very >> helpful if you could tell me where I can find this information. > > To the best of my recollection: > > For triangles and tets, the nodes are at (0,0,0), (1,0,0), (0,1,0), > (0,0,1) in master coordinates > > For tensor product elements, the geometry is [1,1]^d and the edges > are 01:xi, 03:eta, 04:zeta > > For pyramids, the peak is at (0,0,1) and the base is the same as a > quad. > > Prisms are the tensor product of a triangle and an edge, with the > triangle at zeta=1 given the lower local node numbers. > > I'm afraid that the only place where you can find this information > solidly may be implicitly in the fe_lagrange*.C code, though; I'm not > sure we've got it cleanly documented. If you'd like to add such > documentation, a patch (in ASCII so we can put it in the headers) > would be appreciated. >  > Roy > >  > SOLARIS 10 is the OS for Data Centers  provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solarisdev2dev > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 