I thought I fixed it by using VecDuplicate instead of setting up x2 & copying but I got more confused as to why the VecWrite had different dimensions in each case.
Does blocking take a Nx1 vector and convert it to N/BLOCK_SIZE x BLOCK_SIZE vector (that's how it looked it in the output hdf5 files) ? Since I didn't find TimeStep to be a feature of HDF5, am I right in assuming that it's a PETSc feature that creates an extra dimension to store multiple vectors (with the new dimension being indexed by PetscViewerHDF5SetTimeStep) ? On Fri, Nov 30, 2018 at 5:17 PM Smith, Barry F. <[email protected]> wrote: > > > > On Nov 30, 2018, at 1:30 PM, Sajid Ali via petsc-users < > [email protected]> wrote: > > > > Hi, > > > > I tried running ex19.c and I get the following error (I added a small > snippet to print the local size on rank0 as well) : > > > > [sajid@xrm temp]$ mpirun -np 2 ./ex19 > > local_sizes : 3 4 > > [1]PETSC ERROR: --------------------- Error Message > -------------------------------------------------------------- > > [1]PETSC ERROR: Arguments are incompatible > > [1]PETSC ERROR: Incompatible vector local lengths parameter # 1 local > size 3 != parameter # 2 local size 2 > > [1]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html > for trouble shooting. > > [1]PETSC ERROR: Petsc Release Version 3.10.2, unknown > > [1]PETSC ERROR: ./ex19 on a named xrm by sajid Fri Nov 30 13:28:36 2018 > > [1]PETSC ERROR: [0]PETSC ERROR: --------------------- Error Message > -------------------------------------------------------------- > > [0]PETSC ERROR: Arguments are incompatible > > [0]PETSC ERROR: Incompatible vector local lengths parameter # 1 local > size 3 != parameter # 2 local size 4 > > [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html > for trouble shooting. > > [0]PETSC ERROR: Petsc Release Version 3.10.2, unknown > > [0]PETSC ERROR: ./ex19 on a named xrm by sajid Fri Nov 30 13:28:36 2018 > > > > Does this mean that PETSC_DECIDE is inconsistent between two calls in > the same file ? > > No. The reason for the error is a bug in the code. The x1 vector has a > block size of 1 hence when it is divided among two processes it gets 3 > entries on each process. The x2 vector has a block size of 2 so when it is > divided among two processes it gets 4 entries on the first process and 2 on > the second. The call to VecCopy() does not work because the two vectors > have different layouts. > > I have attached a fixed version of the code (that does not copy from x1 > to x2). > > Barry > > > > > > > Thank You, > > Sajid Ali > > Applied Physics > > Northwestern University > > -- Sajid Ali Applied Physics Northwestern University
