Re: [Libmesh-devel] [Libmesh-users] -snes_view

On Wed, Apr 26, 2017 at 2:58 PM, John Peterson wrote: > > > On Wed, Apr 26, 2017 at 12:54 PM, Fabio Canesin > wrote: > >> Dear users/developers, >> >> I noticed that -snes_view does not print the data it should on solvers. >> -ksp_view works as expected. >> > > Are you definitely using a SNES ob

[Libmesh-devel] "called_recursively" in dof_map_constraints.C

If I understand correctly, the "called_recursively" stuff in dof_map_constraints.C is not used anymore because we expand out all recursive constraints beforehand. If that is correct, then I'd be in favor of removing the "called_recursively" code (i.e. in build_constraint_matrix and build_constrain

Re: [Libmesh-devel] NodeElems with ExodusII_IO::write_discontinuous_exodusII

On Fri, Oct 21, 2016 at 5:22 PM, John Peterson wrote: > > > On Fri, Oct 21, 2016 at 2:57 PM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> It seems that ExodusII_IO::write_discontinuous_exodusII doesn't handle >> NodeElems correctly. NodeElems g

[Libmesh-devel] NodeElems with ExodusII_IO::write_discontinuous_exodusII

Systems Example 6 - 3D Linear Elastic Cantilever // \author David Knezevic // \date 2012 // // This is a 3D version of systems_of_equations_ex4. The weak form PDE for // equilibrium elasticity is: // // \int_\Omega Sigma_ij v_i,j = \int_\Omega f_i v_i + \int_\Gamma g_i v_i ds, // // for a

Re: [Libmesh-devel] Dof constraints and GhostingFunctor

On Thu, Oct 13, 2016 at 12:12 PM, David Knezevic wrote: > On Wed, Oct 12, 2016 at 9:07 PM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> On Wed, Oct 12, 2016 at 5:04 PM, Roy Stogner >> wrote: >> >>> >>> On Sun, 9 Oct 2016, Dav

Re: [Libmesh-devel] Dof constraints and GhostingFunctor

On Wed, Oct 12, 2016 at 9:07 PM, David Knezevic wrote: > On Wed, Oct 12, 2016 at 5:04 PM, Roy Stogner > wrote: > >> >> On Sun, 9 Oct 2016, David Knezevic wrote: >> >> I've attached a modified version of misc_ex9 that attaches >>> constraints o

Re: [Libmesh-devel] Dof constraints and GhostingFunctor

On Wed, Oct 12, 2016 at 5:04 PM, Roy Stogner wrote: > > On Sun, 9 Oct 2016, David Knezevic wrote: > > I've attached a modified version of misc_ex9 that attaches >> constraints on one side of the "crack" and checks if the dof >> constraints are present dur

Re: [Libmesh-devel] Dof constraints and GhostingFunctor

On Tue, Oct 11, 2016 at 4:10 PM, Roy Stogner wrote: > > > On Sun, 9 Oct 2016, David Knezevic wrote: > > On Thu, Oct 6, 2016 at 10:34 PM, Roy Stogner >> wrote: >> >> I think the proper fix is to call the coupling functors in >> scatter_constrain

Re: [Libmesh-devel] Dof constraints and GhostingFunctor

On Thu, Oct 6, 2016 at 10:44 PM, David Knezevic wrote: > On Thu, Oct 6, 2016 at 10:34 PM, Roy Stogner > wrote: > >> >> >> On Thu, 6 Oct 2016, David Knezevic wrote: >> >> I'm using GhostingFunctor for a contact solve, in which I consider a 1/

Re: [Libmesh-devel] Dof constraints and GhostingFunctor

On Thu, Oct 6, 2016 at 10:34 PM, Roy Stogner wrote: > > > On Thu, 6 Oct 2016, David Knezevic wrote: > > I'm using GhostingFunctor for a contact solve, in which I consider a 1/4 >> domain with partial Dirichlet boundary conditions that impose a symmetry >> condit

[Libmesh-devel] Dof constraints and GhostingFunctor

I'm using GhostingFunctor for a contact solve, in which I consider a 1/4 domain with partial Dirichlet boundary conditions that impose a symmetry condition (i.e. displacement normal to the symmetry boundary is clamped to zero, and tangential displacement is unconstrained). This means that I have Di

Re: [Libmesh-devel] svd segfault

On Fri, Jul 29, 2016 at 3:48 PM, John Peterson wrote: > > > On Fri, Jul 29, 2016 at 12:54 PM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> Below is a short test case that causes a segfault with DenseMatrix::svd >> with --enable-complex. I think that

[Libmesh-devel] svd segfault

Below is a short test case that causes a segfault with DenseMatrix::svd with --enable-complex. I think that the issue is related to the fact that LAPACK clears the "number_val" array, and then it gets cleared again when it goes out of scope. I wasn't able to fix it so far, though (seems like alloca

Re: [Libmesh-devel] DenseMatrix::svd with --enable-complex

On Fri, Jul 8, 2016 at 12:10 PM, John Peterson wrote: > > > On Fri, Jul 8, 2016 at 9:28 AM, David Knezevic > wrote: > >> _svd_helper (and a few other functions) in dense_matrix_blas_lapack.C are >> only available with LIBMESH_USE_REAL_NUMBERS. I'd like to use

[Libmesh-devel] DenseMatrix::svd with --enable-complex

_svd_helper (and a few other functions) in dense_matrix_blas_lapack.C are only available with LIBMESH_USE_REAL_NUMBERS. I'd like to use the SVD in the complex-valued case. Any idea if there is a good reason for restricting to the real case, or was it just that no one has needed the complex-valued

Re: [Libmesh-devel] Why use relative_fuzzy_equals?

On Mon, Jun 20, 2016 at 8:31 AM, Roy Stogner wrote: > > On Fri, 17 Jun 2016, David Knezevic wrote: > > > I guess you are saying that this reference length is rarely the >> appropriate choice? >> >> Yeah, that's a bad choice. If both points (x and y) are n

Re: [Libmesh-devel] Why use relative_fuzzy_equals?

On Fri, Jun 17, 2016 at 10:51 AM, John Peterson wrote: > > > On Fri, Jun 17, 2016 at 8:41 AM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> On Fri, Jun 17, 2016 at 10:33 AM, John Peterson >> wrote: >> >>> >>> >>>

Re: [Libmesh-devel] Why use relative_fuzzy_equals?

On Fri, Jun 17, 2016 at 10:33 AM, John Peterson wrote: > > > On Fri, Jun 17, 2016 at 8:16 AM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> We use TypeVector::relative_fuzzy_equals in a number of places in the >> library. I'm not convinced tha

[Libmesh-devel] Why use relative_fuzzy_equals?

We use TypeVector::relative_fuzzy_equals in a number of places in the library. I'm not convinced that this function makes sense, since the tolerance effectively depends on where the points happen to be located. I can't think of any situation where this behavior is desirable. My preferred approach

Re: [Libmesh-devel] Assertion failure when doing System::project_solution with a MeshFunction

On Thu, May 26, 2016 at 1:55 PM, Roy Stogner wrote: > > > On Thu, 26 May 2016, David Knezevic wrote: > > P.S. I meant to say that I'd be happy to make a PR with that fix, >> but I wasn't sure what the best way to fix this is. >> > > Neither am I. Sinc

Re: [Libmesh-devel] Assertion failure when doing System::project_solution with a MeshFunction

ed, May 25, 2016 at 11:20 PM, David Knezevic wrote: > I tried to do System::project_solution based on a MeshFunction, and I hit > an assertion failure indicating that the MeshFunction was not initialized. > I believe the issue is that project_solution creates a WrappedFunctor based >

[Libmesh-devel] Assertion failure when doing System::project_solution with a MeshFunction

I tried to do System::project_solution based on a MeshFunction, and I hit an assertion failure indicating that the MeshFunction was not initialized. I believe the issue is that project_solution creates a WrappedFunctor based on the *clone* of the MeshFunction, and the clone is not initialized. I v

Re: [Libmesh-devel] Adding Exodus SHELL elements

On Thu, May 19, 2016 at 1:13 PM, Paul T. Bauman wrote: > This all sounds fine, but I admit I'm curious about where you need this as > opposed to just using the element normal (not elem.normal()) to use in > applying the loads. I don't doubt that you do, but I haven't run into a > case yet where I

Re: [Libmesh-devel] Adding Exodus SHELL elements

On Thu, May 19, 2016 at 1:04 PM, John Peterson wrote: > > > On Thu, May 19, 2016 at 10:55 AM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> On Thu, May 19, 2016 at 12:43 PM, John Peterson >> wrote: >> >>> >>> >>>

Re: [Libmesh-devel] Adding Exodus SHELL elements

On Thu, May 19, 2016 at 12:43 PM, John Peterson wrote: > > > On Thu, May 19, 2016 at 10:19 AM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> I would like to add support for Exodus's SHELL elements to libMesh, e.g. >> TRISHELL3 and SHELL4. S

[Libmesh-devel] Adding Exodus SHELL elements

I would like to add support for Exodus's SHELL elements to libMesh, e.g. TRISHELL3 and SHELL4. See the attached figure from the Exodus standard for a picture of a SHELL4 element. As you can see from the figure, the only difference here is that this element has sidesets associated with the 2D faces

Re: [Libmesh-devel] Rayfire

On Wed, Apr 6, 2016 at 9:22 AM, Paul T. Bauman wrote: > On Wed, Apr 6, 2016 at 9:18 AM, David Knezevic > wrote: > >> Forgive my ignorance on this, but I'm not familiar with rayfire, I was >> hoping someone could enlighten me. Does this refer to raytracing? >>

Re: [Libmesh-devel] Rayfire

Forgive my ignorance on this, but I'm not familiar with rayfire, I was hoping someone could enlighten me. Does this refer to raytracing? What are the applications of that in the context of FEA/CFD? Is there a good reference someone can point me to? David On Wed, Apr 6, 2016 at 9:15 AM, Derek Gas

Re: [Libmesh-devel] Rename Mesh Classes

On Thu, Mar 10, 2016 at 12:12 PM, Paul T. Bauman wrote: > > > On Thu, Mar 10, 2016 at 12:10 PM, Roy Stogner > wrote: > >> >> I like DistributedMesh and ReplicatedMesh. > > > +1 > +1 -- Transform Data into Opportunity. A

Re: [Libmesh-devel] Intree Broken?

On Tue, Feb 23, 2016 at 10:01 PM, Derek Gaston wrote: > I'm guessing that the latest rounds of updating automake related tools > killed intree compiling. This is what I'm seeing: > > CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh > /Users/gastdr/projects/libmesh/build-aux/missing aclocal-1.15 -I

Re: [Libmesh-devel] Increasing the available order for SCALAR variables?

On Thu, Feb 4, 2016 at 9:35 PM, Roy Stogner wrote: > > On Thu, 4 Feb 2016, David Knezevic wrote: > > The order member in FEType is public, and it's used in many places, >> so changing the order member necessitates lots of other changes in >> the library (for example

Re: [Libmesh-devel] Increasing the available order for SCALAR variables?

On Mon, Feb 1, 2016 at 12:13 PM, Roy Stogner wrote: > > We ought to just store order internally as an int, change the existing > constructors to convert, and add new constructors that take int. > --- > Roy > I just wanted to check in about this. The order member in FEType is public, and it's u

Re: [Libmesh-devel] Increasing the available order for SCALAR variables?

On Mon, Feb 1, 2016 at 12:53 PM, John Peterson wrote: > > > On Mon, Feb 1, 2016 at 10:27 AM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> On Mon, Feb 1, 2016 at 12:21 PM, John Peterson >> wrote: >> >>> >>> >>>

Re: [Libmesh-devel] Increasing the available order for SCALAR variables?

On Mon, Feb 1, 2016 at 12:21 PM, John Peterson wrote: > > > On Mon, Feb 1, 2016 at 10:16 AM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> On Mon, Feb 1, 2016 at 12:13 PM, Roy Stogner >> wrote: >> >>> >>> We ought to j

Re: [Libmesh-devel] Increasing the available order for SCALAR variables?

On Mon, Feb 1, 2016 at 12:13 PM, Roy Stogner wrote: > > We ought to just store order internally as an int, change the existing > constructors to convert, and add new constructors that take int. > --- > Roy > Sounds good to me. The enum Order seems unnecessarily restrictive, so it'd be good to s

[Libmesh-devel] Increasing the available order for SCALAR variables?

I'd like to couple some extra equations to a system using SCALAR variables (the extra equations are not based on the mesh). It would be convenient if I could do this by adding a SCALAR variable of arbitrary "order" to the system. At the moment order is capped at 43, according to the Order enum, but

Re: [Libmesh-devel] Recovering from solver failure

On Tue, Sep 22, 2015 at 12:31 PM, John Peterson wrote: > > > > On Sep 21, 2015, at 7:30 PM, Roy Stogner > wrote: > > > > > >> On Tue, 22 Sep 2015, David Knezevic wrote: > >> > >> I think it'd be good to make this easier to recover from,

Re: [Libmesh-devel] Recovering from solver failure

On Tue, Sep 22, 2015 at 12:10 PM, Barry Smith wrote: > > > On Sep 21, 2015, at 11:03 PM, David Knezevic > wrote: > > > > On Tue, Sep 22, 2015 at 9:45 AM, Barry Smith wrote: > > > > > https://bitbucket.org/petsc/petsc/issues/107/allow-recovery-from-certain

Re: [Libmesh-devel] Recovering from solver failure

a release version of PETSc, then I'll still go ahead with Roy's suggestion of changing LIBMESH_CHKERRABORT, I think. David > > > On Sep 21, 2015, at 8:31 PM, David Knezevic > wrote: > > > > On Tue, Sep 22, 2015 at 9:30 AM, Roy Stogner > wrote: > >

Re: [Libmesh-devel] Recovering from solver failure

On Tue, Sep 22, 2015 at 9:30 AM, Roy Stogner wrote: > > On Tue, 22 Sep 2015, David Knezevic wrote: > > I think it'd be good to make this easier to recover from, e.g. we could >> throw an >> exception instead of calling LIBMESH_CHKERRABORT(ierr)? >> >

[Libmesh-devel] Recovering from solver failure

I use the solver library MUMPS via PETSc. Sometimes MUMPS fails due to "error -9", which means that MUMPS allocated a workspace that wasn't big enough. If you have MUMPS enabled, then you can reproduce this with introduction_ex4 in libMesh as follows: mpirun -np 4 ./example-opt -ksp_type preonly -

Re: [Libmesh-devel] Two questions about dof constraints

On Thu, Aug 20, 2015 at 10:05 AM, Roy Stogner wrote: > > On Sun, 5 Jul 2015, David Knezevic wrote: > > 1. In the last part of DofMap::build_constraint_matrix_and_vector() we >> have: >> >> if ((C.n() == Cnew.m()) && // If the

Re: [Libmesh-devel] Compilation error with --enable-complex

On Wed, Aug 12, 2015 at 11:19 AM, Roy Stogner wrote: > > On Wed, 12 Aug 2015, David Knezevic wrote: > > The patch below fixes the compilation errors for me. >> > > Thanks! Put it in a branch + PR? > Will do. > I'm pulling my hair out trying to figur

Re: [Libmesh-devel] Compilation error with --enable-complex

On Wed, Aug 12, 2015 at 10:23 AM, David Knezevic wrote: > On Wed, Aug 12, 2015 at 10:08 AM, Roy Stogner > wrote: > >> >> On Wed, 12 Aug 2015, David Knezevic wrote: >> >> /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C:827:42: >>> error

Re: [Libmesh-devel] Compilation error with --enable-complex

On Wed, Aug 12, 2015 at 10:08 AM, Roy Stogner wrote: > > On Wed, 12 Aug 2015, David Knezevic wrote: > > /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C:827:42: >> error: conversion from 'int' to non-scalar type 'OutputNumber {aka >

[Libmesh-devel] Compilation error with --enable-complex

There are some compilation errors on the git HEAD when I build with --enable-complex, e.g.: --- /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C: In instantiation of 'void {anonymous}::ConstrainDiri

[Libmesh-devel] Two questions about dof constraints

Hi all, I was reading through the dof constraints code recently, and two questions occurred to me that I was hoping to get some input on: 1. In the last part of DofMap::build_constraint_matrix_and_vector() we have: if ((C.n() == Cnew.m()) && // If the constraint matrix

Re: [Libmesh-devel] Using Cap'n Proto to write out reduced basis data

> > On Sun, Jun 14, 2015 at 4:40 PM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> In RBEvaluation::read_offline_data_from_files and >> RBEvaluation::write_offline_data_to_files), we read/write from/to a bunch >> of small Xdr files. I've alw

[Libmesh-devel] Using Cap'n Proto to write out reduced basis data

In RBEvaluation::read_offline_data_from_files and RBEvaluation::write_offline_data_to_files), we read/write from/to a bunch of small Xdr files. I've always thought this is pretty messy and I've wanted to find a better approach. I think a better approach would be to use the Cap'n Proto

Re: [Libmesh-devel] Issue with negative jacobian

On Tue, May 5, 2015 at 6:34 PM, John Peterson wrote: > > > On Tue, May 5, 2015 at 4:08 PM, David Knezevic > wrote: > >> On Tue, May 5, 2015 at 5:48 PM, John Peterson >> wrote: >> >>> >>> >>> On Tue, May 5, 2015 at 2:0

Re: [Libmesh-devel] Issue with negative jacobian

On Tue, May 5, 2015 at 5:48 PM, John Peterson wrote: > > > On Tue, May 5, 2015 at 2:04 PM, David Knezevic > wrote: > >> >> Also, going back to my negative jacobian issue: I realized that this >> element is actually not affine. So it seems like John's co

Re: [Libmesh-devel] Issue with negative jacobian

On Tue, May 5, 2015 at 4:24 PM, Roy Stogner wrote: > > On Tue, 5 May 2015, John Peterson wrote: > > static_bool is a reasonable fix, but I'd also be OK with just >> removing the call to elem->volume() from Elem::print_info(). In >> theory, you can always estimate that by knowing the node >> loc

Re: [Libmesh-devel] Issue with negative jacobian

On Tue, May 5, 2015 at 3:50 PM, Roy Stogner wrote: > > On Tue, 5 May 2015, David Knezevic wrote: > > I think the problem is that calling "elem->print_info()" then calls >> "elem->volume()", which reinits an FE object, which triggers >> negati

Re: [Libmesh-devel] Issue with negative jacobian

On Tue, May 5, 2015 at 3:07 PM, David Knezevic wrote: > On Tue, May 5, 2015 at 2:30 PM, John Peterson > wrote: > >> >> >> On Tue, May 5, 2015 at 12:20 PM, David Knezevic < >> david.kneze...@akselos.com> wrote: >> >>> On

Re: [Libmesh-devel] Issue with negative jacobian

On Tue, May 5, 2015 at 2:30 PM, John Peterson wrote: > > > On Tue, May 5, 2015 at 12:20 PM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> On Tue, May 5, 2015 at 10:27 AM, John Peterson >> wrote: >> >>> >>> >>>

Re: [Libmesh-devel] Issue with negative jacobian

On Tue, May 5, 2015 at 10:27 AM, John Peterson wrote: > > > On Tue, May 5, 2015 at 7:10 AM, David Knezevic > wrote: > >> [0] /home/dknez/software/libmesh-src/src/fe/fe_map.C, line 618, compiled >> May 5 2015 at 08:08:28 >> ERROR: negative Jacobian: -1.79627e-

Re: [Libmesh-devel] Issue with negative jacobian

On Tue, May 5, 2015 at 10:10 AM, John Peterson wrote: > > > On Tue, May 5, 2015 at 7:10 AM, David Knezevic > wrote: > >> I'm getting a negative jacobian error for a mesh created in CUBIT. CUBIT >> says that the smallest jacobian in the mesh is around 1.e-4,

[Libmesh-devel] Issue with negative jacobian

I'm getting a negative jacobian error for a mesh created in CUBIT. CUBIT says that the smallest jacobian in the mesh is around 1.e-4, but when I load the mesh into libMesh and call fe->reinit(elem) on each element, I get the error below. The mesh looks fine to me (it's 1.3MB so I can't attach it h

Re: [Libmesh-devel] Interface to optimization (e.g. TAO)

On Wed, Apr 15, 2015 at 9:10 PM, John Peterson wrote: > > > On Wed, Apr 15, 2015 at 6:53 PM, David Knezevic < > david.kneze...@akselos.com> wrote: >> >> >> I've pushed the code to here: >> https://github.com/dknez/libmesh/tree/opt_interface >&

Re: [Libmesh-devel] Interface to optimization (e.g. TAO)

On Wed, Apr 15, 2015 at 3:04 PM, John Peterson wrote: > > > On Wed, Apr 15, 2015 at 12:42 PM, David Knezevic < > david.kneze...@akselos.com> wrote: > >> I'm interested in having an interface to optimization software from >> libMesh. >> >> I&#

Re: [Libmesh-devel] Interface to optimization (e.g. TAO)

Oops, "min 0.5 * U^T A U - U^T" should of course be "min 0.5 * U^T A U - U^T F". David On Wed, Apr 15, 2015 at 2:42 PM, David Knezevic wrote: > I'm interested in having an interface to optimization software from > libMesh. > > I've attached some code

[Libmesh-devel] Interface to optimization (e.g. TAO)

nclude namespace libMesh { // forward declarations template class SparseMatrix; template class NumericVector; template class Preconditioner; /** * This class provides a uniform interface for optimization solvers. This base * class is overloaded to provide nonlinear solvers from different packages * l

[Libmesh-devel] ParMETIS license

The ParMETIS license is listed here: http://glaros.dtc.umn.edu/gkhome/metis/parmetis/download IANAL but that license seems incompatible with LGPL to me. Do we need to update the strict-lgpl configure option to take this into account? Interestingly METIS is licensed with Apache License Version 2.0

Re: [Libmesh-devel] solve_with_same_matrix?

On Mon, Apr 6, 2015 at 11:10 AM, Roy Stogner wrote: > > On Mon, 6 Apr 2015, David Knezevic wrote: > > PETSc will automatically avoid recomputing preconditioners if you call >> solve multiple times with the same matrix and different right-hand-sides, >> but we don'

[Libmesh-devel] solve_with_same_matrix?

PETSc will automatically avoid recomputing preconditioners if you call solve multiple times with the same matrix and different right-hand-sides, but we don't currently get this benefit because in PetscLinearSolver we re-initialize the solver's matrix on each call to solve. I tested out adding solv

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, Mar 11, 2015 at 12:29 PM, Roy Stogner wrote: > > > On Wed, 11 Mar 2015, Roy Stogner wrote: > > My idea for a fix. After we do the cheap bounding box test: >> Let's also do a contains_point test? >> > > Gah. This is a stupid idea. Do a contains_point test *with what > point*? If we ju

[Libmesh-devel] Failure on call to mesh.sub_point_locator()

I've attached a test code that freezes on the call to mesh.sub_point_locator(). You can get the mesh from here (I figured the list would strip the mesh attachment). The mesh is pretty messy (I didn't make it!) but still this seems like a

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, Mar 11, 2015 at 1:31 PM, Roy Stogner wrote: > > On Wed, 11 Mar 2015, David Knezevic wrote: > > Changing "200" to "250" in: >> >> if (!is_planar_xy) >> _tree = new Trees::OctTree (this->_mesh, 250, _build_type); >> >> wor

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, Mar 11, 2015 at 1:20 PM, Roy Stogner wrote: > > On Wed, 11 Mar 2015, Roy Stogner wrote: > > On Wed, 11 Mar 2015, David Knezevic wrote: >> >> On Wed, Mar 11, 2015 at 12:29 PM, Roy Stogner >>> wrote: >>> >>> We need some ki

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, Mar 11, 2015 at 11:34 AM, Roy Stogner wrote: > > On Wed, 11 Mar 2015, David Knezevic wrote: > > The issue seems to be in TreeNode::insert(). >> >> In particular, it seems that the call to this->refine(); >> inside TreeNode::insert is causing an infini

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

> > > On Wed, Mar 11, 2015 at 10:55 AM, Roy Stogner > wrote: > >> >> On Wed, 11 Mar 2015, David Knezevic wrote: >> >> Let me know if anyone else can reproduce this? >>> >> >> How many processors are you running on? SerialMesh or Parall

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

One processor. SerialMesh. The issue seems to be in TreeNode::insert(). On Wed, Mar 11, 2015 at 10:55 AM, Roy Stogner wrote: > > On Wed, 11 Mar 2015, David Knezevic wrote: > > Let me know if anyone else can reproduce this? >> > > How many processors are you ru

Re: [Libmesh-devel] SAME_PRECONDITIONER for PETSc 3.5?

can simply call > KSPSetReusePreconditioner() appropriate in the #else case below > > Barry > > > On Jan 7, 2015, at 10:16 PM, David Knezevic > wrote: > > > > I notice that in PetscLinearSolver::solve we have: > > > > -- > > > > #if PE

[Libmesh-devel] SAME_PRECONDITIONER for PETSc 3.5?

I notice that in PetscLinearSolver::solve we have: -- #if PETSC_RELEASE_LESS_THAN(3,5,0) ierr = KSPSetOperators(_ksp, submat, subprecond, this->same_preconditioner ? SAME_PRECONDITIONER : DIFFERENT_NONZERO_PATTERN); #else ierr = KSPSet

Re: [Libmesh-devel] Candidate for systems_of_equations_ex7: nonlinear elasticity

OK, done. On Tue, Dec 9, 2014 at 5:01 PM, John Peterson wrote: > On Tue, Dec 9, 2014 at 1:50 PM, David Knezevic > wrote: > > On Mon, Dec 8, 2014 at 5:10 PM, David Knezevic < > david.kneze...@akselos.com> > > wrote: > > > > I believe there was

Re: [Libmesh-devel] Candidate for systems_of_equations_ex7: nonlinear elasticity

On Mon, Dec 8, 2014 at 5:10 PM, David Knezevic wrote: > > John suggested that I put this code into my fork on github so that it's >> easier for others to view and comment on. I'll take care of that shortly. >> > > > OK, it's up on my fork on github, se

Re: [Libmesh-devel] Candidate for systems_of_equations_ex7: nonlinear elasticity

> John suggested that I put this code into my fork on github so that it's > easier for others to view and comment on. I'll take care of that shortly. > OK, it's up on my fork on github, see here

Re: [Libmesh-devel] Candidate for systems_of_equations_ex7: nonlinear elasticity

Hi Paul, > The code converges and seems to give reasonable results, but I was hoping >> to get a second (or more!) set of eyes on this to check that it's >> reasonable. >> > > I'll try and have a quick look later this week. > Much appreciated, thanks! John suggested that I put this code into

[Libmesh-devel] Candidate for systems_of_equations_ex7: nonlinear elasticity

Hi all, There have been several questions on the mailing list about nonlinear elasticity, so I wanted to provide a new example (systems_of_equations_ex7) that addresses this. Note that fem_system_ex2 is a neo-Hookean model, but I think it's quite complicated, so I think a simpler nonlinear elastic

[Libmesh-devel] Fwd: Candidate for systems_of_equations_ex7: nonlinear elasticity

It seems like the post below didn't go through, so I'm trying again. Apologies if it's a duplicate. David -- Forwarded message ------ From: David Knezevic Date: Mon, Dec 8, 2014 at 2:46 PM Subject: Candidate for systems_of_equations_ex7: nonlinear elasticity To

Re: [Libmesh-devel] Small question re sparsity pattern

> > >> On Oct 13, 2014, at 5:17 PM, David Knezevic >> wrote: >> >> I was looking into the sparsity pattern code a bit, and I was wondering if >> the !need_full_sparsity_pattern branch in >> SparsityPattern::Build::parallel_sync() over-estimates n_nz and

[Libmesh-devel] Small question re sparsity pattern

I was looking into the sparsity pattern code a bit, and I was wondering if the !need_full_sparsity_pattern branch in SparsityPattern::Build::parallel_sync() over-estimates n_nz and n_oz? It doesn't do the equivalent of the my_row.erase operation that we have in the need_full_sparsity_pattern br

Re: [Libmesh-devel] Incorrect boundary IDs from 2D ExodusII mesh created in CUBIT

>> It looks like the issue is that the element type in Cubit is TRISHELL3, >> which I guess is what Cubit gives you by default if you have TRI3 >> elements in 3D. Also, that's presumably explains why it had a side ID of 5. >> >> Can we detect if the element type in the exo file is TRI3 vs TRISHELL3

Re: [Libmesh-devel] Incorrect boundary IDs from 2D ExodusII mesh created in CUBIT

>> So it seems here that the problem is with the mesh that CUBIT is generating, >> do you agree? I agree that "side_ss1 = 5, 5, 5" doesn't make any sense, so >> I'm not sure what's going on there. > Definitely agree. > > We could possibly put in some kind of workaround if you can figure out > the

[Libmesh-devel] Incorrect boundary IDs from 2D ExodusII mesh created in CUBIT

Hi All, I've attached a simple 2D mesh with TRI3 elements that was made in CUBIT. It has four sidesets (one for each boundary), and when I view the mesh in CUBIT the sidesets look fine. But when I read this mesh into libMesh, it mixes up the sidesets so that the boundary IDs are on internal

Re: [Libmesh-devel] DirichletBoundary for constraining variables in terms of each other?

>>> The first nasty case I can think of is the combination of a simple >>> constraint on a vertical or horizontal wall (deltax = 0 or deltay = 0, >>> obviously gets applied to the deltax dof or the deltay dof >>> respectively) with a previously applied compound constraint on a >>> neighboring diag

Re: [Libmesh-devel] DirichletBoundary for constraining variables in terms of each other?

>> >> I would hope that the solver can handle the case of multiple constraints >> on a dof. > > Nope. The solver should easily handle multiple constraints > *affecting* a dof, but since we write each constraint row into the > matrix in place of the row corresponding to some dof's test function, >

Re: [Libmesh-devel] DirichletBoundary for constraining variables in terms of each other?

On 04/06/2014 11:50 PM, Roy Stogner wrote: > > On Sun, 6 Apr 2014, David Knezevic wrote: > >> Is it possible to impose a linear constraint on the variables in a >> system using a DirichletBoundary object? > > Currently, no. > >> The case I'm thinking of

[Libmesh-devel] DirichletBoundary for constraining variables in terms of each other?

Is it possible to impose a linear constraint on the variables in a system using a DirichletBoundary object? The case I'm thinking of is in elasticity, where you want set the displacement in the normal (or tangential) direction on a surface. In that case we want "n \dot (u,v,w) = normal_displace

Re: [Libmesh-devel] How to use ExodusII_IO::write_element_data ?

> Can you call ExodusII_IO::write_timestep() followed by > ExodusII_IO::write_element_data()? Just to close the loop on this, John's suggestion of calling write_element_data on an existing ExodusII_IO object does exactly what I was looking for. I just updated the Exodus plotting in systems_of

Re: [Libmesh-devel] How to use ExodusII_IO::write_element_data ?

I put this at the end of the main function in systems_of_equations_ex6: ExodusII_IO exo_io(mesh); exo_io.write_timestep("test.exo", equation_systems, 0, 0.); exo_io.write_element_data(equation_systems); and I got this error: Error writing nodal values.

Re: [Libmesh-devel] How to use ExodusII_IO::write_element_data ?

On 03/06/2014 11:40 PM, John Peterson wrote: On Thu, Mar 6, 2014 at 9:35 PM, David Knezevic mailto:dkneze...@seas.harvard.edu>> wrote: On 03/06/2014 11:30 PM, John Peterson wrote: On Thu, Mar 6, 2014 at 9:12 PM, David Knezevic mailto:dkneze...@seas.harvard.edu>&g

Re: [Libmesh-devel] How to use ExodusII_IO::write_element_data ?

On 03/06/2014 11:30 PM, John Peterson wrote: On Thu, Mar 6, 2014 at 9:12 PM, David Knezevic mailto:dkneze...@seas.harvard.edu>> wrote: I'd like to write out element-based data to an exodus file (again related to discontinuous visualization). There is a function

[Libmesh-devel] How to use ExodusII_IO::write_element_data ?

I'd like to write out element-based data to an exodus file (again related to discontinuous visualization). There is a function ExodusII_IO::write_element_data in ExodusII_IO, but it's not clear to me how to use it? I'd like to use it in the same way as ExodusII_IO::write_nodal_data, but it doe

Re: [Libmesh-devel] Weird bug in plotting discontinuous solutions with exodus

On 03/06/2014 06:44 AM, David Knezevic wrote: Hi Martin, On 03/06/2014 02:08 AM, Martin Luethi wrote: Hi David David Knezevic writes: I've found a case where ExodusII_IO::write_discontinuous_exodusII has a weird bug. The example is here (on dropbox): visit shows the same problem (mi

Re: [Libmesh-devel] Weird bug in plotting discontinuous solutions with exodus

Hi Martin, On 03/06/2014 02:08 AM, Martin Luethi wrote: > Hi David > > David Knezevic writes: >> I've found a case where ExodusII_IO::write_discontinuous_exodusII has a >> weird bug. The example is here (on dropbox): > visit shows the same problem

[Libmesh-devel] Weird bug in plotting discontinuous solutions with exodus

I've found a case where ExodusII_IO::write_discontinuous_exodusII has a weird bug. The example is here (on dropbox): https://dl.dropboxusercontent.com/u/10916994/discontinuous_plot_test.zip The example is basically just systems_of_equations_ex6 with a different mesh. (The reason I am interested

Re: [Libmesh-devel] Loop subdivision surface elements

I'd definitely be enthusiastic about getting support for shells in libMesh as well. David On 02/21/2014 11:20 AM, Paul T. Bauman wrote: Others may also be interested in this, but I have a keen interest. I'd be happy to look at the patch, but, even better, would be for you to open a pull requ

Re: [Libmesh-devel] problem reading in mesh with init.comm() ?

On 02/14/2014 11:56 AM, Roy Stogner wrote: > > On Fri, 14 Feb 2014, David Knezevic wrote: > >> I'm on 7842167a275cb39383caa200c15a3cfafbcd61f9, and I'm having a >> problem with this code: >> >> LibMeshInit init (argc, argv); >> Mesh mesh(init.co

[Libmesh-devel] problem reading in mesh with init.comm() ?

Hi all, I'm on 7842167a275cb39383caa200c15a3cfafbcd61f9, and I'm having a problem with this code: LibMeshInit init (argc, argv); Mesh mesh(init.comm())); mesh.read(path_to_mesh_file); It stalls on the read call when I run on multiple MPI processes...? Am I doing something wrong with the commun

  1   2   3   4   >