Jed, I have tested two different sets: petsc-3.1/slpec-3.1 and
petsc-3.2/slepc-3.2 --- both cases ex17 failed generating the same error
log.
On Wed, Nov 2, 2011 at 3:48 AM, Jed Brown wrote:
> Kyunghoon, the error messages say petsc-3.1p8, but the configure line
> makes it look like you are tryin
On Tue, 1 Nov 2011, David Knezevic wrote:
> Roy, I've attached a version of ex17 with dirichlet boundary conditions, if
> you're interested in testing that out in complex mode. (Note: it uses
> CondensedEigenSystem, which I use in rbOOmit in order to compute eigenvalues
> without introducing s
On 11/01/2011 04:31 PM, Roy Stogner wrote:
On Tue, 1 Nov 2011, Jed Brown wrote:
The error "IPNorm: The inner product is not well defined!" is
usually due to the fact that the B matrix of the eigenproblem is not
positive (semi) definite. Are you sure your eigenproblem is
definite?
It's defini
On 11/01/2011 04:31 PM, Roy Stogner wrote:
> On Tue, 1 Nov 2011, Jed Brown wrote:
>
>> The error "IPNorm: The inner product is not well defined!" is
>> usually due to the fact that the B matrix of the eigenproblem is not
>> positive (semi) definite. Are you sure your eigenproblem is
>> definite?
>
On Tue, 1 Nov 2011, Jed Brown wrote:
> The error "IPNorm: The inner product is not well defined!" is
> usually due to the fact that the B matrix of the eigenproblem is not
> positive (semi) definite. Are you sure your eigenproblem is
> definite?
It's definitely *supposed* to be; this is just the
On Tue, Nov 1, 2011 at 2:13 PM, Jed Brown wrote:
> On Tue, Nov 1, 2011 at 14:06, Jose E. Roman wrote:
>
>>
>> El 01/11/2011, a las 20:55, Roy Stogner escribió:
>>
>> >
>> > On Tue, 1 Nov 2011, Jed Brown wrote:
>> >
>> >> Kyunghoon, the error messages say petsc-3.1p8, but the configure line
>> mak
On 11/01/2011 04:10 PM, Roy Stogner wrote:
>
> On Tue, 1 Nov 2011, David Knezevic wrote:
>
>> One thought is that I've always thought that ex17 was a bit strange
>> since we're looking for
>>
>> sup_v a(v,v) / m(v,v)
>>
>> which is unbounded as h --> 0. Perhaps things are more fragile
>> because
On Tue, Nov 1, 2011 at 14:06, Jose E. Roman wrote:
>
> El 01/11/2011, a las 20:55, Roy Stogner escribió:
>
> >
> > On Tue, 1 Nov 2011, Jed Brown wrote:
> >
> >> Kyunghoon, the error messages say petsc-3.1p8, but the configure line
> makes it look like you are trying to use petsc-3.2. Which
> >> i
On Tue, 1 Nov 2011, David Knezevic wrote:
> One thought is that I've always thought that ex17 was a bit strange since
> we're looking for
>
> sup_v a(v,v) / m(v,v)
>
> which is unbounded as h --> 0. Perhaps things are more fragile because of
> this high-frequency mode? Does ex17 work with compl
On Tue, 1 Nov 2011, Jed Brown wrote:
> Kyunghoon, the error messages say petsc-3.1p8, but the configure line makes
> it look like you are trying to use petsc-3.2. Which
> is it? I assume that Roy reproduced with a clean petsc-3.2/slepc-3.2
> configuration.
Actually, no - I just built against t
I apologize for not responding to these emails earlier….
Here is a basic algorithm for using NEMESIS when starting with a file format
that _isn't_ already EXODUS _and_ your mesh is so large that you can't read it
on "n" number of processors.
1. Read file into libMesh
2. Write out Exodus file
On 11/01/2011 03:41 PM, Roy Stogner wrote:
>
> On Tue, 1 Nov 2011, David Knezevic wrote:
>
>> On 11/01/2011 03:28 PM, Roy Stogner wrote:
>
>>> The problem seems to be some issue with the default iterative solvers
>>> we tell SLEPc to use; it looks like for some reason they're getting a
>>> "norm" o
Kyunghoon, the error messages say petsc-3.1p8, but the configure line makes
it look like you are trying to use petsc-3.2. Which is it? I assume that
Roy reproduced with a clean petsc-3.2/slepc-3.2 configuration.
Jose, do you know what is causing this error?
On Tue, Nov 1, 2011 at 13:28, Roy Stogn
On Tue, 1 Nov 2011, David Knezevic wrote:
> On 11/01/2011 03:28 PM, Roy Stogner wrote:
>> The problem seems to be some issue with the default iterative solvers
>> we tell SLEPc to use; it looks like for some reason they're getting a
>> "norm" of their initial random starting vector that isn't a
On Mon, 31 Oct 2011, robert.bod...@unil.ch wrote:
> I never succeeded to write the nemesis files for the different
> processors. I only get one file which, I can't read in i parallel
> because the program searches the files mesh.8.0, mesh.8.1, mesh.8.2,
> ... . How can I get these files when read
On 11/01/2011 03:28 PM, Roy Stogner wrote:
> We're testing SLEPc + complex now, and seeing the same IPNorm error.
>
> The problem seems to be some issue with the default iterative solvers
> we tell SLEPc to use; it looks like for some reason they're getting a
> "norm" of their initial random starti
We're testing SLEPc + complex now, and seeing the same IPNorm error.
The problem seems to be some issue with the default iterative solvers
we tell SLEPc to use; it looks like for some reason they're getting a
"norm" of their initial random starting vector that isn't a
non-negative real number. I
fixes it, thanks!
On 11/01/2011 03:25 PM, John Peterson wrote:
> On Tue, Nov 1, 2011 at 1:20 PM, David Knezevic
> wrote:
>> I just svn up'd and ./configure'd and I'm getting the compilation error:
>>
>> Compiling C++ (in debug mode) src/base/dof_map.C...
>> In file included from
>> /home/dkne
On Tue, Nov 1, 2011 at 1:20 PM, David Knezevic
wrote:
> I just svn up'd and ./configure'd and I'm getting the compilation error:
>
> Compiling C++ (in debug mode) src/base/dof_map.C...
> In file included from
> /home/dknez/software/libmesh/include/base/dof_map.h:39:0,
> from src/base/dof_map.C:30:
I just svn up'd and ./configure'd and I'm getting the compilation error:
Compiling C++ (in debug mode) src/base/dof_map.C...
In file included from
/home/dknez/software/libmesh/include/base/dof_map.h:39:0,
from src/base/dof_map.C:30:
/home/dknez/software/libmesh/include/parallel/threads_allocators
20 matches
Mail list logo
