On Tue, 1 Jun 2010, Vijay S. Mahadevan wrote:
>> This would be an underlying bug.
>
> What specifically is a bug there ?
node->n_comp(sys, var) shouldn't be 0 if there is a degree of
freedom which is topologically associated with Node node.
> I am solving a problem with 1 variable defined in a
Copying this to libmesh-devel; there's a non-trivial chance that
others there might disagree with me.
On Wed, 2 Jun 2010, Boyce Griffith wrote:
> On 6/2/10 3:52 PM, Boyce Griffith wrote:
>
>> OK, then I have mis-understood what close() does --- I think I thought
>> it was equivalent to VecAssem
On Thu, 3 Jun 2010, Vijay S. Mahadevan wrote:
> I have encountered segfaults while using projection of exact solution
> when using variables that are defined in specific subdomains. I traced
> the problem to system_projection.C and found that the fix is to check
> whether the variable is defined
On Thu, 3 Jun 2010, Vijay S. Mahadevan wrote:
> I think this should be done for the project_vector method too.
It should.
> I did not do this before but if you think this is required, you can
> add that also.
Done.
The fix I committed to SVN is slightly simpler than your patch. It
works on
On Thu, 3 Jun 2010, Vijay S. Mahadevan wrote:
> Also, looking at your changes, I'm just curious on why you removed the
> implicitly_active() check.
Given two options for code, each of which might be faster:
> That could save a lot of "variable.active_on_subdomain()" calls
> since the variable a
On Fri, 18 Jun 2010, Tim Kroeger wrote:
> 2. Talking about the non-discrete norms, no other norms than L2, H1, H2, and
> H1_SEMINORM are implemented, and the others (for instance L1 and L_INF) just
> silently return 0. I added a call to libmesh_not_implemented() for this
> case.
I think I pu
On Mon, 21 Jun 2010, John Peterson wrote:
In file included from src/numerics/petsc_matrix.C:28:
.../workspace/libmesh/include/base/dof_map.h:49: error:
using typedef-name ‘Mesh’ after ‘class’
.../workspace/petsc-dev/include/petscmesh.h:26: error:
‘Mesh’ has a previous declaration here
make: ***
On Mon, 21 Jun 2010, Derek Gaston wrote:
> I'm not sold on either direction... but I do enjoy not having to
> deal with a libmesh namespace now. But laziness doesn't justify
> anything.
How about we decide not to decide?
"using namespace libMesh;" in libmesh_common.h, wrapped in
something like
On Mon, 21 Jun 2010, John Peterson wrote:
>> "using namespace libMesh;" in libmesh_common.h, wrapped in
>> something like
>> #ifndef LIBMESH_USE_NAMESPACE
>> which gets defined by something like
>> ./configure --disable-separate-namespace
>
> Would it really be that simple? That doesn't put thin
On Mon, 21 Jun 2010, Kirk, Benjamin (JSC-EG311) wrote:
> How about renaming the offending class 'TheClassFormerlyKnownAsMesh'
>
> and rely on the old C-style namespace-through-obfuscation?
No way. With "libMesh::Mesh" we can use the namespace features and
probably get away with a few lines of c
On Thu, 24 Jun 2010, Jed Brown wrote:
> On Thu, 24 Jun 2010 15:59:22 +0200 (CEST), Tim Kroeger
> wrote:
>
>> In my application, I am doing quite a lot of assignments between
>> NumericVector instances (which always are PetscVector instances in my
>> case), and since I am lazily most of the time
On Fri, 25 Jun 2010, Tim Kroeger wrote:
> I've meanwhile implemented "parallel=ghosted", see attached patch. It solves
> the problem for me. (BTW, it's amazing what mistakes one can do even in such
> a trivial change; I had to correct my patch two times before it did what I
> wanted...) I'll
On Mon, 21 Jun 2010, Roy Stogner wrote:
> No way. With "libMesh::Mesh" we can use the namespace features and
> probably get away with a few lines of code in every file (deep breath
> in, Derek, deep breath out...); with "libMesh_Mesh" there really
> wouldn'
On Tue, 29 Jun 2010, Derek Gaston wrote:
Doh - are there not any Parameters on a System? I was planning on
stuffing stuff into my NonlinearImplicitSystem so that I can get it
back out when the NonlinearImplicitSystem get's passed into
compute_residual / jacobian. Sigh.
No, the Parameters ob
On Tue, 29 Jun 2010, Derek Gaston wrote:
> Actually... this would be a good reason to use Roy's suggestion of
> "fall-through" parameters it would allow you to _optionally_
> override the values at the System level. Of course that would mean
> changes to all of the solvers to look at the Sys
On Tue, 29 Jun 2010, Roy Stogner wrote:
> Yeah; I'd have done that long ago if it wasn't for the backwards
> compatibility issue. For flexibility there's no better solution than
> Parameters, but for things we know we need we might as well avoid the
> string looku
On Sat, 3 Jul 2010, John Peterson wrote:
On Sat, Jul 3, 2010 at 10:00 AM, Paul T. Bauman wrote:
If there are no plans to change to autotools (or better, modern
build system *cough* SCons *cough*) then consider this a feature
request for "make install" behavior for the reasons
On Tue, 13 Jul 2010, John Peterson wrote:
> On Tue, Jul 13, 2010 at 12:16 PM, Derek Gaston wrote:
>> Hmmm... it appears that the Elem class is missing in the libMesh doxygen
>> currently on the website.
>>
>> I can't come up with any reason why it's missing other than a botched
>> doxygen run.
Our latest ReferenceCountedObject class queried the command line via
GetPot to check if we should print out refcount info, and that query
wasn't cached.
The latest GetPot by default stuck every single query at the end of a
GetPot::_requested_* vector, as a simple but grossly
inefficient way of en
On Tue, 10 Aug 2010, Derek Gaston wrote:
> I can't think of a time when you would have discontinuous
> variables that you are solving for and you wouldn't want implicit
> neighbor dofs on.
Discontinuous pressure variables are a common situation, and IMHO
they're reason enough alone not to turn o
On Tue, 10 Aug 2010, Derek Gaston wrote:
> Ok - we will probably check into this soon. The one issue is the
> above case where you have the discontinuous pressure variable.
> Is it ok to generate a sparsity pattern for that variable that is a
> bit large? Or is that too much of a waste for
On Fri, 13 Aug 2010, Sebastian Steiger wrote:
> While trying to statically link my application which uses libmesh I
> discovered that there is an int main() in libtetgen.a:
>
> stei...@sebuntu:~/src/app-nemo/NEMO$ nm
> libs/libmesh-0.6.4/libmesh/contrib/lib/x86_64-unknown-linux-gnu_opt/libtetgen
On Thu, 19 Aug 2010, Sebastian Steiger wrote:
> Thanks for looking into this. Actually there is another int main() in
> libnemesis, but I don't know how to fix it.
It looks like the only thing in ne_test.c is that main() and some
test-utility-specific supporting routines. I'll just change our
h::initialized() function.
---
Roy
On Mon, 28 Jun 2010, Roy Stogner wrote:
> There's a "using namespace libMesh;" in the library itself, which is
> enough that nearly all code works unchanged.
>
> There are at least a couple exceptions, which require ugly workarounds
> if
On Tue, 24 Aug 2010, Sebastian Steiger wrote:
> While valgrinding our software I discovered the following error (running on a
> single machine):
>
> ==3358== Invalid write of size 4
> ==3358==at 0x586E8BA: libMesh::MeshBase::n_subdomains() const
> (parallel.h:2629)
> ==3358==by 0x586F84
without
it, but that's not worth trying to rely on.
---
Roy
-- Forwarded message --
Date: Wed, 25 Aug 2010 14:55:25 -0400
From: Sebastian Steiger
To: Roy Stogner
Subject: Re: problem in allgather (parallel.h)?
Victory!
Indeed the LibMeshInit object was constructed at a later sta
On Fri, 27 Aug 2010, Johannes A Huber wrote:
> I was wondering, is it might be possible petsc_matric.C on line 72 (and
> perhaps in other lines as well, like 139, 142, ...)
> The matrix that is created in these lines is always quadratic
> (n_global*n_global). I guess, the second argument to Mat
On Fri, 27 Aug 2010, John Peterson wrote:
On Fri, Aug 27, 2010 at 11:36 AM, John Peterson
wrote:
On Fri, Aug 27, 2010 at 11:30 AM, Roy Stogner wrote:
On Fri, 27 Aug 2010, Johannes A Huber wrote:
I was wondering, is it might be possible petsc_matric.C on line 72 (and perhaps
in other
On Tue, 31 Aug 2010, Derek Gaston wrote:
> So... up until now I've only ever needed one "ghosted" vector... for
> the solution vector. And, just as we do in petsc_nonlinear_solver.C
> I've just been bastardizing System::update() and
> current_local_solution to "ghostize" a vector.
>
> But now t
On Tue, 31 Aug 2010, Derek Gaston wrote:
> Well, that is odd then. Because I'm sure that libMesh is passing in
> ghosted vectors (hmmm... maybe the residual (rhs) isn't ghosted by
> default?).
Actually, the only vectors which currently default to ghosted are
old_local_solution, older_local_sol
On Tue, 31 Aug 2010, Derek Gaston wrote:
>
> On Aug 31, 2010, at 1:44 PM, Roy Stogner wrote:
>
>> Actually, the only vectors which currently default to ghosted are
>> old_local_solution, older_local_solution in TransientSystems,
>> old_local_nonlinear_solution i
On Tue, 31 Aug 2010, Derek Gaston wrote:
> On Aug 31, 2010, at 1:51 PM, Roy Stogner wrote:
>
>> Otherwise the only thing to do is add a non-default code path, where
>> instead of letting PETSc work on solution while we work to keep
>> current_local_solution sync&
On Tue, 31 Aug 2010, Jed Brown wrote:
>> But it would be sufficient for your case to just create ghosted
>> instead of parallel vectors. We can't do that in general in
>> NumericVector::build() because that doesn't have access to DofMap's
>> send_list. But we could do that as an option (run-tim
On Tue, 31 Aug 2010, Derek Gaston wrote:
> On Aug 31, 2010, at 2:24 PM, Roy Stogner wrote:
>
>> However when we're just building a parallel vector, we only call
>> NumericVector::build() with the global and local sizes, not with the
>> entire context that ex
On Wed, 1 Sep 2010, Derek Gaston wrote:
> On Aug 31, 2010, at 2:36 PM, Roy Stogner wrote:
>
>> The effect you want should be to add a get_send_list() argument and
>> change PARALLEL to GHOSTED in system.C lines 230, 246, 262, 310, 593.
>> Try that first and see if it wo
On Wed, 1 Sep 2010, Derek Gaston wrote:
> Essentially, you're suggesting a std::map between vector name and
> ParallelType?
No need - just check NumericVector::type() for each.
> Then you can pass ParallelType into add_vector()?
Right.
> And like you mention you'll need member variables for t
On Wed, 1 Sep 2010, Derek Gaston wrote:
> add a member variable to system called
> "default_parallel_vector_type" that defaults to PARALLEL.
>
> add_vector will get an optional argument for the ParallelType
> (defaulting to PARALLEL).
>
> add_vector will also store off the ParallelType for each v
On Wed, 1 Sep 2010, Derek Gaston wrote:
> On Sep 1, 2010, at 4:22 PM, Roy Stogner wrote:
>
>> This all sounds good except for the map - what would
>> paralleltype_map["vector_name"] get you that
>> get_vector("vector_name").type() doesn't?
>
On Wed, 1 Sep 2010, Roy Stogner wrote:
> On Wed, 1 Sep 2010, Derek Gaston wrote:
>
>> On Sep 1, 2010, at 4:22 PM, Roy Stogner wrote:
>>
>>> This all sounds good except for the map - what would
>>> paralleltype_map["vector_name"] get you tha
On Wed, 1 Sep 2010, Jed Brown wrote:
> On Wed, 1 Sep 2010 12:58:11 -0500 (CDT), Roy Stogner
> wrote:
>> I'm not sure I understood Jed's suggestion - eliminate parallel
>> non-ghosted vectors entirely, then write our own ghosting support to
>> handle the non-
On Wed, 1 Sep 2010, Derek Gaston wrote:
> On Sep 1, 2010, at 4:36 PM, Roy Stogner wrote:
>
>> Initialize the vector e.g. as GHOSTED with size 0 and an empty ghost
>> index set?
>
> Really? You would really prefer that? Seems like a hack to me. We
> store other i
On Wed, 18 Aug 2010, Alberto Chapchap wrote:
> I am particular interested in generating a cube (box) meshed with
> quadrilaterals
See the MeshGeneration::build_square function that's used in some of
the libMesh examples.
> and then manipulate it (translate the nodes preserving the
> conectivi
On Thu, 16 Sep 2010, Tim Kroeger wrote:
> This keep annoying me continuously, so I tracked it back and found that the
> attached patch solves the problem, although I don't know why. I'll check that
> in if nobody objects.
I wonder if doxygen is getting confused by my spartan ifdefs there?
Unle
On Thu, 16 Sep 2010, Tim Kroeger wrote:
> That does not solve the problem. However, the attached method does and is
> certainly cleaner than my first solution. I'll check that in if you agree
> (or you can check it in yourself if you like).
It works for me and looks nicer than the original m
On Fri, 17 Sep 2010, Ming Q wrote:
> I saw the same problem of dynamic casting. I have to work around by using GNU
> compiler instead.
One stupid question and one serious one, for everybody:
Is there any place in XCode where they're turning on -fno-rtti by
default, and if so can that be user-
On Fri, 17 Sep 2010, John Peterson wrote:
> On Fri, Sep 17, 2010 at 9:58 AM, Roy Stogner wrote:
>>
>>
>> On Fri, 17 Sep 2010, Ming Q wrote:
>>
>>> I saw the same problem of dynamic casting. I have to work around by using
>>> GNU compiler instead.
On Fri, 17 Sep 2010, Derek Gaston wrote:
"Fixing" libmesh shouldn't be our concern here. We HAVE to be able
to reliably dynamic cast. If the compiler isn't going to give that
to us that's a non-starter.
Okay - if this isn't a sufficient workaround for you then I won't
bother changing it in
On Sun, 19 Sep 2010, David Knezevic wrote:
> Speaking of enrich_RB_space, lines 364 to 386 find which proc had the max
> value, do you know of an easier way to do that? Perhaps a Parallel::max()
> operation that also returns a proc ID would be a good addition?
Agreed. I just added Parallel::m
The SVN head's currently pretty stable from my perspective, with the
exception of rbOOmit stuff, which David tells me is now in shape for
an immediate release.
Does anyone else have anything they want to get added/fixed before we
put out a tarball?
I'll try to skim over the svn log to put togeth
On Tue, 28 Sep 2010, John Peterson wrote:
> I have a local change fixing the setting of the time variable in the
> FEM/DiffContext.
>
> In order to do that, I needed access to the "deltat" variable from the
> System which created the FEMContext.
>
> The approach I'm currently using requires the c
On Tue, 28 Sep 2010, Derek Gaston wrote:
> We're working on a small patch to System::add_vector() to allow adding
> ghosted vectors. It might be nice if that made it in the release but
> it isn't critical. I'll check and see if we have other outstanding
> libmesh patches lying around and try to
On Tue, 28 Sep 2010, Cody Permann wrote:
> First we found that some of the flags in the "gcc debug" sections do
> not work with the Apple compilers. Specifically -D_GLIBCXX_DEBUG
> and -D_GLIBCXX_DEBUG_PEDANTIC. These flags cause memory
> corruption/seg fault issues in _some_ of the libMesh exa
On Wed, 29 Sep 2010, David Andrs wrote:
> Cody and I prepared a patch for compiler.m4 file which should address the
> build issues with native Apple compilers. It should not interfere
> with other build systems (see the attachment).
This looks good and works fine for me; go ahead and commit.
--
On Thu, 30 Sep 2010, David Andrs wrote:
> Roy Stogner wrote on 09/30/2010 11:27:03 AM:
>
> >
> > On Wed, 29 Sep 2010, David Andrs wrote:
> >
> > > Cody and I prepared a patch for compiler.m4 file which should
> > address the build issues wit
On Mon, 11 Oct 2010, Derek Gaston wrote:
> I just committed our changes to System::add_vector() which as
> far as I know was the last remaining thing I wanted to see in this
> release...
I've fixed some bugs in the GetPot UFO detection and in the
NonlinearImplicitSystem adjoints integration.
libmesh-0.7.0-rc1 is available in .tar.bz2 (and soon in .tar.gz) files
on the SourceForge file download site (as well as a tag in the SVN
repository).
A full changelog will be forthcoming along with the final release.
0.6.4 users are encouraged to try 0.7.0 with their application codes
to test fo
I'm jumping into this very late; a couple comments:
On Mon, 4 Oct 2010, Vijay S. Mahadevan wrote:
>> For higher-order elements the embedding matrices will be enormous, not
>> sure we want to mess with these if we don't have to...
> Are you saying that higher order elements dont need the embeddin
I committed the first patch without changes; thank you very much!
Would you mind if I futzed with the names on this one? E.g.
# if PETSC_VERSION_LESS_THAN(2,2,1) // Cannot avoid a copy
#define LibMeshISCreate(comm,n,idx,is)
ISCreateGeneral((comm),(n),(idx),(is))
# else
#defin
On Thu, 14 Oct 2010, Jed Brown wrote:
> My intent was to make the source look like what will be in the next
> release of PETSc (because chances are that next time people look at
> those calls, in a year or two, that they will be using 3.2 or later),
> with the macro to make it work with older ve
On Thu, 14 Oct 2010, Roy Stogner wrote:
> On Thu, 14 Oct 2010, Jed Brown wrote:
>
>> My intent was to make the source look like what will be in the next
>> release of PETSc (because chances are that next time people look at
>> those calls, in a year or two, that they wi
On Thu, 14 Oct 2010, Jed Brown wrote:
Are you including petsc headers after petsc_macro.h? Looks like I
made a wrong assumption about when it was included.
We are, and while that could be changed around in the library, there's
no way to be sure that none of our users are doing the same.
I
On Fri, 15 Oct 2010, Tim Kroeger wrote:
> It really seems easier to me now not to put that into the library.
> I'll wait whether Roy says something about this
I'm afraid I just skimmed the discussion after seeing what looked like
a Lagrange-only algorithm. I generally use the DiscontinuityMeasu
On Wed, 20 Oct 2010, John Peterson wrote:
On Wed, Oct 20, 2010 at 4:19 PM, Derek Gaston wrote:
To "fix" this I propose using relative_fuzzy_equals() like so:
if (!(elem->point(n) - elem->point(0)).relative_fuzzy_equals((cached_nodes[n] -
cached_nodes[0])))
But of course this could have th
On Wed, 20 Oct 2010, Kirk, Benjamin (JSC-EG311) wrote:
> I would be fine with 1e-13 still though - that is a pretty tight tolerance!
For a relative-to-edge-size tolerance 1e-13 should be fine, yeah.
---
Roy
--
Nokia and
On Mon, 25 Oct 2010, David Andrs wrote:
> I think I found a bug when I was working on the periodic-boundary patch
> (submitted earlier today). If I compiled libmesh in debug mode and ran my
> application, it locked up. I figured out that point_locator() is called
> (mesh_base.C line 287), it al
On Mon, 25 Oct 2010, David Andrs wrote:
> Attached is a patch that improves periodic boundaries in the
> following way. The calculation of translation goes through Point
> get_translation(const Point &pt) virtual method, so that people can
> do their own translations if it depends on the point pt
On Wed, 27 Oct 2010, David Andrs wrote:
> Roy Stogner wrote on 10/27/2010 01:19:07 PM:
>
> > What kind of translations are they doing?
>
> Currently they do two types:
>
> 1) A wedge-shaped domain (see per1.png) (origin is at the bottom
> corner). The translation
The final release of libMesh 0.7.0 is now available in gzipped or
bzip2'ed tarball form from https://sourceforge.net/projects/libmesh/
Changes from 0.6.4 to 0.7.0 include:
* Certified Reduced Basis model creation/evaluation
* Adjoint-based sensitivity calculations and error indicators
*
On Tue, 2 Nov 2010, Boyce Griffith wrote:
> I haven't gone digging around in the headers; however, I just had to update
> some code to account for the change of PeriodicBoundary::translation_vector
> from public to protected, and the following:
>
> VectorValue boundary_translation(2.0*M_PI*R,
On Mon, 8 Nov 2010, Roy Stogner wrote:
> Indeed it does! I can replicate that (seeing an exception in the
> ghosted vector support) just by switching ex14 to cubic hierarchics.
>
> I'll look into this ASAP.
I rooted out the problem I found, and the bug fix for that is in
On Wed, 10 Nov 2010, Cody Permann wrote:
> Sorry I don't mean to spam but I thought of one other issue to consider with
> changing
> around the API for the Periodic BC AMR level one constraint issue. Right now
> the
> PeriodicBoundaries object is held inside of DofMap but for topological
> p
On Mon, 15 Nov 2010, Vijay S. Mahadevan wrote:
> I'm terribly sorry for not keeping you updated on this effort. I got
> side tracked with other things and haven't been able to get back to it
> until now. I will focus on getting the embedding matrices written out
> so that the patch will be almost
On Mon, 8 Nov 2010, Roy Stogner wrote:
> The DofMap bug fix is in there now, but I'm going to wait for
> Saurabh's reply before putting out a libMesh 0.7.0.3.
0.7.0.3 is up on https://sourceforge.net/projects/libmesh/ now.
Anyone using parallel AMR with Hierarchic, Clough-Toche
On Mon, 15 Nov 2010, Derek Gaston wrote:
> Would anyone be opposed to me adding a
> qrule->has_constant_positions() (that would return true for all of
> our current rules and false for the new one I'm making)... or
> something like it (I'm open to suggestions!)
Does the number of quadrature poi
On Mon, 15 Nov 2010, Derek Gaston wrote:
> On Nov 15, 2010, at 1:21 PM, Roy Stogner wrote:
>
>> Does the number of quadrature points change, or just their locations?
>> If it's just their locations then I think you've probably hit on the
>> best solutio
On Mon, 15 Nov 2010, John Peterson wrote:
> On Mon, Nov 15, 2010 at 2:49 PM, Roy Stogner wrote:
>>
>>
>> On Mon, 15 Nov 2010, Derek Gaston wrote:
>>
>>> On Nov 15, 2010, at 1:21 PM, Roy Stogner wrote:
>>>
>>>> Does the number of quadra
On Tue, 16 Nov 2010, Cody Permann wrote:
> As promised, I have mocked up an example in libMesh to test out the
> periodic level 1 rule patch.
Thanks!
Looking over that patch: I don't like the swath of ifdef-else macros
required around the uses of topological neighbor. There's no great
solution
On Tue, 16 Nov 2010, Derek Gaston wrote:
> On Nov 16, 2010, at 9:35 AM, Roy Stogner wrote:
>
>> Fair enough. One of these days we need to finally implement hybrid
>> mesh output with Exodus, though.
>
> Note: Hybrid mesh output does work now the two different types
On Tue, 16 Nov 2010, Cody Permann wrote:
>>> Everything seems to be working just fine. There is one more mystery
>>> which I cannot figure out. I am forced to clear the point locator
>>> class manually in each adaptivity step before I use it or I end up
>>> with data corruption and a seg fault
On Wed, 17 Nov 2010, Roy Stogner wrote:
> I'm actually not sure how this is causing your bug, though - you're
> just using the point_locator in the flagging stage, right? Where the
> elements haven't actually been created or deleted yet?
Worse still: it's a Heise
On Wed, 17 Nov 2010, Cody Permann wrote:
> Yes, I am using the point_locator in the flagging stage. However,
> the elements are refined and coarsened right after the flagging is
> complete but if you are in the middle a refinement loop, you enter
> the flagging stage again. This is exactly wha
On Wed, 17 Nov 2010, Cody Permann wrote:
> Found it! There is a call to MeshBase::contract() inside of
> EquationSystems::reinit() which certainly changes the Mesh. I
> commented out that line of code and my example ran without seg
> faulting.
That's just a workaround - if we never delete coar
On Wed, 17 Nov 2010, Cody Permann wrote:
> On Nov 17, 2010, at 2:24 PM, Roy Stogner wrote:
>
>> And because
>> PointLocatorTree only operates on active elements, it shouldn't care
>> whether or not we delete subactive elements after it's constructed.
>
>
On Mon, 22 Nov 2010, John Peterson wrote:
> So... I'm wondering if we should do something similar (disable op= and
> copy ctor unless needed and explicitly provided, possibly with a
> macro) in all of our library classes?
So a bunch of potential nasty run-time errors turn into compile-time
error
On Mon, 22 Nov 2010, Boyce Griffith wrote:
> FWIW --- the g++ compiler option -Weffc++ can be helpful for tracking
> down this kind of stuff --- it will emit warnings about classes that
> violate some of the coding guidelines from Myers' book Effective C++,
> including one regarding copy construc
The boost suggestion reminds me of something I meant to bring up on
Friday (before work and vacation packing distracted me): we need to
use some shared_ptr classes. Vikram's doing some work with the
ErrorMap, and looking at that again reminds me how horrible it is to
force manual memory managemen
On Wed, 1 Dec 2010, Boyce Griffith wrote:
> I noticed that adding multiple boundary IDs to the boundary_info object
> caused an assertion to fail in xdr_io::write_serialized_bcs() at line
> 740 of xdr_io.C, which asserts that n_bcs == n_bcs_out.
>
> Looking at the code that packs up the IDs, it a
Thanks very much, and sorry I let this get buried in my outbox - it's
in the svn head now.
---
Roy
On Tue, 9 Nov 2010, Erik Zeek wrote:
> When PETSc is installed into a prefix directory it no longer has a directory
> component for $PETSC_ARCH. The test for PETSc MPI support didn't allow for
> t
On Thu, 2 Dec 2010, Boyce Griffith wrote:
> Looking around, there are some other places in libMesh that appear not to
> handle multiple boundary IDs per side. In particular:
>
> fe_base.C~ around line 2018
> mesh_communication.C ~ around lines 364 and 1080
> mesh_modification.C
On Thu, 2 Dec 2010, Boyce Griffith wrote:
> OK --- attached is a patch. Most of it is just re-indenting. (I wasn't
> always careful about using tabs instead of spaces --- is there a convention
> that you all prefer to use?)
The ideal thing to do is tabs for indentation, spaces for alignment.
Anyone who'd be able to quickly add support for 1D elements,
specifically? Our code's support for plotting postprocessed boundary
data drops dead when the boundary is of a 2D simulation and the
plotting format is ExodusII. I've mostly managed to avoid digging
through that code or that file forma
On Thu, 2 Dec 2010, Boyce Griffith wrote:
> It looks like Artistic Style's GNU setting more-or-less conforms to the
> libMesh style --- you can invoke it via:
>
> astyle --style=gnu -r $PWD/*.C $PWD/*.h
>
> or possibly:
>
> astyle --style=gnu --max-instatement-indent=79 \
> --min-co
On Thu, 2 Dec 2010, Derek Gaston wrote:
> We will do this.
Thanks!
> Can you give me a simple test case?
Comment out the Gnuplot case in ex4, so that it falls through to
Exodus even with dimension 1, then the first execution in "make run"
will hit the same error we do.
---
Roy
---
On Fri, 3 Dec 2010, codyperm...@gmail.com wrote:
> My vote would be to add it in the commit hook. There should be no
> disadvantages that way and formatting will get better over time.
> Heavily worked sections of code will come up to date quickly while
> less busy sections of code (in terms of c
On Fri, 17 Dec 2010, John Peterson wrote:
> We would most likely wait to check-in until Roy has returned from
> holiday vacation and has had a chance to look over/comment on the
> patch, so there is no hurry.
Thanks. :-) I'm barely keeping up on my email at the moment; won't
have time to chec
On Sat, 18 Dec 2010, Jed Brown wrote:
On Fri, Dec 17, 2010 at 10:49, Jan Biermann wrote:
I just implemented two new solvers in Petsc that make use of
Krylov subspace recycling, which means that if you have to solve
a sequence of linear systems, the overall cost can be reduce
Under what conditions does this occur? I'm surprised if you're seeing
it for 2D meshes (where IIRC we build quadtrees instead of octrees)
and I'm surprised that I've never seen it for 1D meshes...
Sounds like a straightforward solution, though; someone want to glance
over and commit it?
---
Roy
On Mon, 10 Jan 2011, Cody Permann wrote:
> So I've been looking into making some of the error handling stuff
> more robust on the Mac Platform, i.e. catching NaNs better and
> better stack traces. I was just looking through the print_trace.C
> file and noticed that somebody has written wrappers
On Tue, 11 Jan 2011, Aleksej Saushev wrote:
> I see this error message on NetBSD when building libmesh-0.7.0.3:
>
> "test: ==: unexpected operator"
>
> Fix:
>
> "==" is non-standard and isn't portable, use "="
It's fixed in SVN now; thank you very much!
---
Roy
-
While regression testing some recent changes I hit on what seems to be
a long-standing bug: ex24 fails in debug mode on my systems when run
on 4 processors. It's been passing continuous integration checks on 1
proc and it passes 2 proc checks, and the bug seems to have existed
but gone unnoticed
1 - 100 of 1694 matches
Mail list logo
