Re: [Libmesh-users] Best way to disable repartitioning

2012-12-06 Thread Roy Stogner
On Thu, 6 Dec 2012, Derek Gaston wrote: > So, I need to disable REpartitioning for one specific problem... what's the > best way to go about that? > > Basically, I need to read a mesh, do an initial partitioning and then never > change it again Didn't we add MeshBase::skip_partitioning() or

[Libmesh-users] Best way to disable repartitioning

2012-12-06 Thread Derek Gaston
So, I need to disable REpartitioning for one specific problem... what's the best way to go about that? Basically, I need to read a mesh, do an initial partitioning and then never change it again What do you guys think? Derek ---

Re: [Libmesh-users] write_equation_systems() with several Systems and EquationSystems

2012-12-06 Thread Roy Stogner
On Thu, 6 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote: On Dec 6, 2012, at 3:44 PM, Derek Gaston wrote: We're a bit closer to "code users" (ie, non-code developers) than you guys are though... so that policy might make more sense for us. Really what we should probably be doing is make 'devel

Re: [Libmesh-users] write_equation_systems() with several Systems and EquationSystems

2012-12-06 Thread Kirk, Benjamin (JSC-EG311)
On Dec 6, 2012, at 3:44 PM, Derek Gaston wrote: > We're a bit closer to "code users" (ie, non-code developers) than you guys > are though... so that policy might make more sense for us. Really what we should probably be doing is make 'devel' mode the default - kinda like PETSc, you can turn of

Re: [Libmesh-users] write_equation_systems() with several Systems and EquationSystems

2012-12-06 Thread Derek Gaston
On Thu, Dec 6, 2012 at 2:22 PM, Roy Stogner wrote: > My general rule is not to do self-testing in opt mode when that > testing has any time or memory cost. > > Now that you got me to think about it: in this case the costs are "a > handful of operations and one word of memory per EquationSystems >

Re: [Libmesh-users] write_equation_systems() with several Systems and EquationSystems

2012-12-06 Thread Roy Stogner
On Thu, 6 Dec 2012, Derek Gaston wrote: This is what I was thinking as well... although why wrap it in NDEBUG?  This isn't time sensitive... so we should probably just always do this check. My general rule is not to do self-testing in opt mode when that testing has any time or memory cost. N

[Libmesh-users] Fwd: write_equation_systems() with several Systems and EquationSystems

2012-12-06 Thread Derek Gaston
Didn't send to the list... -- Forwarded message -- From: Derek Gaston Date: Thu, Dec 6, 2012 at 2:14 PM Subject: Re: [Libmesh-users] write_equation_systems() with several Systems and EquationSystems To: Roy Stogner On Thu, Dec 6, 2012 at 2:13 PM, Roy Stogner wrote: > MeshBase

Re: [Libmesh-users] write_equation_systems() with several Systems and EquationSystems

2012-12-06 Thread Roy Stogner
On Thu, 6 Dec 2012, John Peterson wrote: >> It's a bug we should probably be trying to detect and assert against >> in library code, though... I'm not sure how to do easily without also >> accidentally asserting against valid usage patterns, though. > > And how would you do it in a complicated wa

Re: [Libmesh-users] write_equation_systems() with several Systems and EquationSystems

2012-12-06 Thread John Peterson
On Thu, Dec 6, 2012 at 1:59 PM, Roy Stogner wrote: > > On Thu, 6 Dec 2012, Jens Lohne Eftang wrote: > >> I'm having several EquationSystems, > > More importantly, you're attaching several EquationSystems to the same > mesh. This is a bug; you'll need to instead get a mesh.clone() if you > want a

Re: [Libmesh-users] write_equation_systems() with several Systems and EquationSystems

2012-12-06 Thread Roy Stogner
On Thu, 6 Dec 2012, Jens Lohne Eftang wrote: > I'm having several EquationSystems, More importantly, you're attaching several EquationSystems to the same mesh. This is a bug; you'll need to instead get a mesh.clone() if you want a new EquationSystems attached to an identical mesh. It's a bug w

[Libmesh-users] write_equation_systems() with several Systems and EquationSystems

2012-12-06 Thread Jens Lohne Eftang
Hi all, I'm having several EquationSystems, and also several Systems within each EquationSystems, and I'm using ExodusII_IO().write_equation_systems() for plotting. In optimized mode I do get correct results, but in devel or debug mode I get an error when plotting. I've cooked up a minimalisti

Re: [Libmesh-users] Meshfunction::gradient()

2012-12-06 Thread Roy Stogner
On Thu, 6 Dec 2012, Ataollah Mesgarnejad wrote: > I was wondering if there is any reasons for MeshFunction::gradient not to > work with C1 (Clough) elements? In theory, it should work fine. If anything I'd expect it to work *better* for C1 elements, since the results would always be well-defin

[Libmesh-users] Meshfunction::gradient()

2012-12-06 Thread Ataollah Mesgarnejad
Dear all, I was wondering if there is any reasons for MeshFunction::gradient not to work with C1 (Clough) elements? Thanks, Ata -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs a

Re: [Libmesh-users] [Libmesh-devel] Mixed vs Homogeneous multivariable finite element types

2012-12-06 Thread Roy Stogner
On Wed, 5 Dec 2012, Derek Gaston wrote: > In his case he is solving with over 2,000 variables > > We also have other users solving with 20-200 variables of the same It would be interesting to know of other places where users are greatly exceeding our original estimates of what "N" might be in ca

Re: [Libmesh-users] Gradient of C1 error

2012-12-06 Thread Ataollah Mesgarnejad
Ok done. You are right, when I write the output in Nemesis format it messes up the gradient. You can get my tweaked adaptivity_ex4 from: http://cl.ly/02131w2o2715 . So does this mean that this is a VisIt bug?! PS: I had to make it so it reads a mesh file otherwise Nemesis_IO wouldn't work and I