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
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 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
What options did you use to configure libMesh?
I'll see if I can reproduce this. We currently have --enable-complex
BuildBot tests and --enable-slepc tests but I don't think we're
testing the combination of the two...
---
Roy
On Fri, 28 Oct 2011, Kyunghoon Lee wrote:
> Hi all,
>
> I compiled p
Hi all,
I compiled petsc with complex variable support using the following options:
./configure --prefix=/Users/aeronova/
Development/local/lib64/petsc/petsc-3.2-p4 --download-mpich=1
--download-blacs=1 --download-parmetis=1 --download-scalapack=1
--download-mumps=1 --with-scalar-type=complex --w
17 matches
Mail list logo
