MPICH folks confirmed it's an MPICH problem and an issue is created at
https://github.com/pmodels/mpich/issues/6843
--Junchao Zhang
On Tue, Dec 12, 2023 at 7:53 PM Junchao Zhang
wrote:
> I was able to reproduce it. Let me ask MPICH developers.
>
> --Junchao Zhang
>
>
> On Tue, Dec 12, 2023 at
I was able to reproduce it. Let me ask MPICH developers.
--Junchao Zhang
On Tue, Dec 12, 2023 at 3:06 PM Randall Mackie
wrote:
> It now seems to me that petsc+mpich is no longer valgrind clean, or I am
> doing something wrong.
>
> A simple program:
>
>
> Program test
>
> #include "petsc/fincl
It now seems to me that petsc+mpich is no longer valgrind clean, or I am doing
something wrong.
A simple program:
Program test
#include "petsc/finclude/petscsys.h"
use petscsys
PetscInt :: ierr
call PetscInitialize(PETSC_NULL_CHARACTER,ierr)
call PetscFinalize(ierr)
end program
Thanks Matt,
I got it figured out. As with a lot of uninitialised value bugs it
started a long way away (in a scalar value) and propagated through.
What is slightly bizarre is that valgrind didn't pick it up where I
define and first use it, even with --track-origins=yes.
Thank you for your help
On Fri, Oct 26, 2018 at 9:54 AM Phil Tooley
wrote:
> Hi All,
>
> Running valgrind over my code reveals a huge number (it stops collecting
> after 1e6) of uninitialised value errors occuring the KSPSolve routine.
> These don't occur with the ksp example scripts but I can't figure out
> what I am d
Hi All,
Running valgrind over my code reveals a huge number (it stops collecting
after 1e6) of uninitialised value errors occuring the KSPSolve routine.
These don't occur with the ksp example scripts but I can't figure out
what I am doing wrong in my code. My code works as expected. The same
er
Randall,
I have resolved in the problem in branch barry/fortran-initialize-objects
(now in next for testing) which defaults to initializing the PETSc objects in
Fortran and removes the use of PetscObjects in Fortran common blocks to prevent
compile errors. Soon will be in master
Barry
Sorry this is actually in master already
> On Jan 18, 2018, at 5:00 PM, Smith, Barry F. wrote:
>
>
> This is a known issue without a perfect solution.
>
> The problem is that by default PETSc fortran types, like type(tKSP) are not
> initialized but we want to check if they are a s
This is a known issue without a perfect solution.
The problem is that by default PETSc fortran types, like type(tKSP) are not
initialized but we want to check if they are a special null character, for
example PETSC_NULL_KSP. So we could initialize them but then they cannot be
used in
The very simple attached program throws lots of valgrind errors.I am using pets 3.8.3, compiled with the following options: ./configure \ --with-debugging=1 \ --with-fortran=1 \ --download-mpich=../mpich-3.3a2.tar.gz \ The makefile, run file, and valgrind output are also attached.Randy M.
cmd_t
Ok I got it thanks. The vector sol_seq that I used in
VecScatterCreateToZero (see below) was also created before with a
VecCreate() but only destroyed once. I didn't realize that the vector
was automatically created in the context of VecScatterCreateToZero. I
modified the code and the bugs (e
riginal Message-
>>> From: Hong [mailto:hzh...@mcs.anl.gov]
>>> Sent: Friday, September 12, 2014 4:29 PM
>>> To: Dominic Meiser
>>> Cc: Barry Smith; James Balasalle; Zhang, Hong; petsc-users@mcs.anl.gov
>>> Subject: Re: [petsc-users] Valgrind Errors
-
>> From: Hong [mailto:hzh...@mcs.anl.gov]
>> Sent: Friday, September 12, 2014 4:29 PM
>> To: Dominic Meiser
>> Cc: Barry Smith; James Balasalle; Zhang, Hong; petsc-users@mcs.anl.gov
>> Subject: Re: [petsc-users] Valgrind Errors
>>
>> I'll check i
> From: Hong [mailto:hzh...@mcs.anl.gov]
> Sent: Friday, September 12, 2014 4:29 PM
> To: Dominic Meiser
> Cc: Barry Smith; James Balasalle; Zhang, Hong; petsc-users@mcs.anl.gov
> Subject: Re: [petsc-users] Valgrind Errors
>
> I'll check it.
> Hong
>
> On Fri,
I'll check it.
Hong
On Fri, Sep 12, 2014 at 3:40 PM, Dominic Meiser wrote:
> On 09/12/2014 02:11 PM, Barry Smith wrote:
>>
>> James (and Hong),
>>
>> Do you ever see this problem in parallel runs?
>>
>> You are not doing anything wrong.
>>
>> Here is what is happening.
>>
>> Ma
On 09/12/2014 02:11 PM, Barry Smith wrote:
James (and Hong),
Do you ever see this problem in parallel runs?
You are not doing anything wrong.
Here is what is happening.
MatGetBrowsOfAoCols_MPIAIJ() which is used by MatMatMult_MPIAIJ_MPIAIJ()
assumes that the VecScatters fo
James (and Hong),
Do you ever see this problem in parallel runs?
You are not doing anything wrong.
Here is what is happening.
MatGetBrowsOfAoCols_MPIAIJ() which is used by MatMatMult_MPIAIJ_MPIAIJ()
assumes that the VecScatters for the matrix-vector products are
gen_to =
Hello,
I'm getting some valgrind errors in my PETSc code that looks like it's related
to MatTranspose(). I just figured I was doing something wrong. But I ran one
of the examples (snes/ex70) which uses MatTranpose() through valgrind and see
the same errors there as well. It seems that when t
On Tue, 19 Jan 2010 13:57:06 -0500, "(Rebecca) Xuefei YUAN" wrote:
> Quoting Jed Brown :
> If I want to do it like your way, how could I handle the different dof
> in the call
> if (!eda) {
> // create eda based on the layout of da
This is where your
DACreate2D(...,sizeof(FieldO
On Tue, 19 Jan 2010 13:49:36 -0500, "(Rebecca) Xuefei YUAN" wrote:
> However, I do not think DAGetLocalVector()+DAVecGetArray() is a must
> in my case, I tried DAGetArray() to take over of the above two.
> However, I have the error message saying
These are just warnings, you can avoid them by
On Tue, 19 Jan 2010 13:27:14 -0500, "(Rebecca) Xuefei YUAN" wrote:
> Dear Jed,
>
> I switched the code as below and it is working now without valgrind errors.
Great!
> I am using multilevel, will the following approach be fine? I will
> modify the code a little more to get sth like yours.
It
On Tue, 19 Jan 2010 12:56:30 -0500, "(Rebecca) Xuefei YUAN" wrote:
> Dear Jed,
>
> I have one more question, what is the difference or how could I know
> whether I need DAGetArray() or DAGetLocalVector()+DAVecGetArray() to
> get my array?
You can use the former unless you need to use it when
On Tue, 19 Jan 2010 18:44:38 +0100, Jed Brown wrote:
> PetscMalloc(info.mx*info.my*sizeof(PetscReal),&fieldother);
Oops, I meant
PetscMalloc(info.mx*info.my*sizeof(FieldOther),&fieldother);
Jed
On Tue, 19 Jan 2010 12:24:07 -0500, "(Rebecca) Xuefei YUAN" wrote:
> Dear Jed,
>
> I found the source of these uninitialised values.
>
> In my FormFunction(), there is a user-defined structure called
> FieldOther and I will use this as a temp values to build up my
> residual function. The ma
Quoting Jed Brown :
> On Tue, 19 Jan 2010 13:27:14 -0500, "(Rebecca) Xuefei YUAN"
> wrote:
>> Dear Jed,
>>
>> I switched the code as below and it is working now without valgrind errors.
>
> Great!
>
>> I am using multilevel, will the following approach be fine? I will
>> modify the code a litt
Dear Barry,
I switched from using temp arrays via PetscMalloc() and PetscFree() to
creating a DA and using DAGetLocalVector()+DAVecGetArray() to get
fieldother as a temp array.
However, I do not think DAGetLocalVector()+DAVecGetArray() is a must
in my case, I tried DAGetArray() to take over
What if the dof of da is 4 and the dof of eda is 6?
Quoting Jed Brown :
> On Tue, 19 Jan 2010 12:56:30 -0500, "(Rebecca) Xuefei YUAN"
> wrote:
>> Dear Jed,
>>
>> I have one more question, what is the difference or how could I know
>> whether I need DAGetArray() or DAGetLocalVector()+DAVecGet
Dear Jed,
I switched the code as below and it is working now without valgrind errors.
I am using multilevel, will the following approach be fine? I will
modify the code a little more to get sth like yours.
typedef struct {
PetscReal x1,x2,x3,x4;
} FieldOther;
#undef __FUNCT__
#d
Dear Jed,
I have one more question, what is the difference or how could I know
whether I need DAGetArray() or DAGetLocalVector()+DAVecGetArray() to
get my array?
Thanks a ton!
Rebecca
Quoting Jed Brown :
> On Tue, 19 Jan 2010 12:24:07 -0500, "(Rebecca) Xuefei YUAN"
> wrote:
>> Dear Je
Dear Jed,
This makes a lot of sense!
I made the following change:
ierr = PetscMalloc((info.mx)*(info.my)*sizeof(FieldOther),
&fieldother);CHKERRQ(ierr);
and the values of iFirst, iLast, jFirst, jLast in one single processor is from
iFirst = info.xs; iLast = info.xs + i
Dear Jed,
I found the source of these uninitialised values.
In my FormFunction(), there is a user-defined structure called
FieldOther and I will use this as a temp values to build up my
residual function. The main loop is like:
typedef struct {
PetscReal x1,x2,x3,x4;
} FieldOt
> err =
> PetscMalloc
> (sizeof(PetscReal)*(info.mx)*(info.my)*sizeof(FieldOther),
> &fieldother);CHKERRQ(ierr);
This line is wrong, but is not the cause of the problem.
sizeof(FieldOther) takes into account the size of the real values
inside so you do not need the sizeof(PetscReal)
On Mon, 18 Jan 2010 16:32:22 -0500, "(Rebecca) Xuefei YUAN" wrote:
> Dear Jed,
>
> I got some origins, but I still do not understand what is going on here?
>
> Here is a piece of uninitialised value from
I think you have an indexing error while reading from this local vector
in your residual ev
On Mon, 18 Jan 2010 15:33:21 -0500, "(Rebecca) Xuefei YUAN" wrote:
> Dear Jed,
>
> Thanks for the reply.
>
> However, there was an error message for this option:
It was introduced in valgrind-3.4.0 (and it's worth upgrading just for
this feature).
Jed
Dear all,
Thanks very much for kind replies.
I get a better idea where to look into when debugging.
Cheers,
Rebecca
Quoting Barry Smith :
>
> When using valgrind it is best to use the additional PETSc option
> -malloc off this turns off PETSc's malloc tracking and usually makes
> the proble
On Mon, 18 Jan 2010 15:12:18 -0500, "(Rebecca) Xuefei YUAN" wrote:
> Hi,
>
> I got some errors from valgrind showing some errors from PETSc defined
> functions, but at the end of the valgrind report, it seems fine except
> the first two that valgrind always has for PETSc.
These don't look "f
When using valgrind it is best to use the additional PETSc option -
malloc off this turns off PETSc's malloc tracking and usually makes
the problem code clearer.
I am updating the troubleshooting.html guide to indicate this.
Barry
On Jan 18, 2010, at 3:32 PM, (Rebecca) Xuefei YUAN
Dear Jed,
I got some origins, but I still do not understand what is going on here?
Here is a piece of uninitialised value from
==9725== Conditional jump or move depends on uninitialised value(s)
==9725==at 0x86EFB20: dnrm2_ (dnrm2.f:46)
==9725==by 0x857ECB1: VecNorm_Seq (bvec2.c:60)
==9
On Mon, Jan 18, 2010 at 3:32 PM, (Rebecca) Xuefei YUAN
wrote:
> Dear Jed,
>
> I got some origins, but I still do not understand what is going on here?
>
> Here is a piece of uninitialised value from
>
> ==9725== Conditional jump or move depends on uninitialised value(s)
> ==9725==at 0x86EFB20:
Hi,
I got some errors from valgrind showing some errors from PETSc defined
functions, but at the end of the valgrind report, it seems fine except
the first two that valgrind always has for PETSc.
Is this really fine or not?
--
THERE
40 matches
Mail list logo
