Re: [petsc-dev] VecScatter problem

Just an update for the list, Steve seems to have narrowed it down to a compiler bug in the array assignment as Matt suggested. Mark Quick update: just checking ierr isn’t enough to avoid the compiler bug, but adding zero to n1 is. Compiling the code as sent: 145, Loop not fused: function c

Re: [petsc-dev] VecScatter problem

On Thu, Aug 25, 2016 at 5:47 PM, Mark Adams wrote: > >> >> Yes, it does. However, I think its more likely that the compiler plays >> with those array copies. >> >> > Matt's first girlfriend dumped him for a Fortran programmer. Sad. > Plausible if I had a girlfriend in the 70s. Now the only thin

Re: [petsc-dev] VecScatter problem

> > > > Yes, it does. However, I think its more likely that the compiler plays > with those array copies. > > Matt's first girlfriend dumped him for a Fortran programmer. Sad.

Re: [petsc-dev] VecScatter problem

> > > > > I agree completely, they should be there. I would be much more comfortable > if just putting them in didn’t solve the error I put them in to look for.. > > > Yes, we have to figure this out, if for no other reason this is a silent error.

Re: [petsc-dev] VecScatter problem

On Thu, Aug 25, 2016 at 5:01 PM, Abbott, Stephen R. wrote: > >> If there was an error then you should have seen PETSc output to that > effect. Could you have missed that? > > > > I don’t see any error show up in the output, and the run continues happily > even with the error checks in place, so

Re: [petsc-dev] VecScatter problem

>> If there was an error then you should have seen PETSc output to that effect. >> Could you have missed that? I don’t see any error show up in the output, and the run continues happily even with the error checks in place, so I don’t think that’s it. >> You should definitely add these error ch

Re: [petsc-dev] VecScatter problem

> > > > > The troubling bit about this, which caused me to suggest that it was a > race condition, was that if I modify the code a little bit I can get the > correct result from the scatter. For example, we weren’t always checking > the returned error flag. > If there was an error then you should

Re: [petsc-dev] VecScatter problem

“Steve: are you using the debug version of PETSc that I built?” I am. “Steve: perhaps you could try setting apar = -1.d0, or something and look at your plots to verify that it is not getting updated. Perhaps it is getting updated with 0.0. And now that I think about it, this assignment should

Re: [petsc-dev] VecScatter problem

Valgrind > On Aug 25, 2016, at 4:18 PM, Mark Adams wrote: > > So, this code works on lots of machines and the first scatter does work. > > And it sounds like there is nothing wrong with this syntax, there is no known > race condition here. > > Steve: are you using the debug version of PETSc

Re: [petsc-dev] VecScatter problem

So, this code works on lots of machines and the first scatter does work. And it sounds like there is nothing wrong with this syntax, there is no known race condition here. Steve: are you using the debug version of PETSc that I built? Note, this assignment: ! scatter solution back - apar apa

Re: [petsc-dev] VecScatter problem

Matt is getting confused with Fortran, I just talked with him and he gets it now, On Thu, Aug 25, 2016 at 4:58 PM, Robert Hager wrote: > Now I am confused. n1, which is a local variable in this subroutine, is > not declared as a pointer or as allocatable here, so there is memory > connected to

Re: [petsc-dev] VecScatter problem

Now I am confused. n1, which is a local variable in this subroutine, is not declared as a pointer or as allocatable here, so there is memory connected to n1. And in my understanding whatever values we get out of XX with the VecScatter are written to this memory. After the scatter has finished,

Re: [petsc-dev] VecScatter problem

On Thu, Aug 25, 2016 at 2:38 PM, Robert Hager wrote: > Isn’t xxvec(0) basically a pointer to n1 after the call to > VecCreateSeqWithArray? If so, the VecScatter should update the values in n1 > and setting a_n1=n1 in the end makes sense. > xxvec(0) holds a pointer (n1) to the data. That pointer

Re: [petsc-dev] VecScatter problem

Isn’t xxvec(0) basically a pointer to n1 after the call to VecCreateSeqWithArray? If so, the VecScatter should update the values in n1 and setting a_n1=n1 in the end makes sense. Robert > On Aug 25, 2016, at 3:16 PM, Matthew Knepley wrote: > > On Thu, Aug 25, 2016 at 1:59 PM, Mark Adams

Re: [petsc-dev] VecScatter problem

On Thu, Aug 25, 2016 at 1:59 PM, Mark Adams wrote: > We have the subroutine below that scatters three vectors. We have used > this code on many machines and it works fine but on one machine data does > not get scattered correctly. The first scatter looks OK, but it looks like > the other two are

Re: [petsc-dev] VecScatter problem

> > >> ! end >> call VecScatterEnd( a_ts%from_petsc(0),a_XX,xxvec >> (0),INSERT_VALUES,SCATTER_FORWARD,ierr) >> a_n1 = n1 >> > > Why is the line above in here? > a_n1 is the return value of the subroutine. I just did this to keep the types clear, real kind=8 vs PetscScalar.

Re: [petsc-dev] VecScatter problem

On Thu, Aug 25, 2016 at 1:59 PM, Mark Adams wrote: > We have the subroutine below that scatters three vectors. We have used > this code on many machines and it works fine but on one machine data does > not get scattered correctly. The first scatter looks OK, but it looks like > the other two are

[petsc-dev] VecScatter problem

We have the subroutine below that scatters three vectors. We have used this code on many machines and it works fine but on one machine data does not get scattered correctly. The first scatter looks OK, but it looks like the other two are missing data. Am I using this correctly? Should we use Vec