April 2013 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Matlab interface
by Jose E. Roman 06 Apr '13

06 Apr '13

El 06/04/2013, a las 02:25, Barry Smith escribió: > > I have fixed the bug, it was introduced by me when changing MPIUni to have different MPI_COMM_SELF and WORLD. The fix is in next and in barry/fix-matlab > > Note I did not update the MATLAB scripts that are out of date. > > This fix needs to get into Master before the release. > > Thanks for reporting the problem, > > Barry > Thanks. I pushed one change to barry/fix-matlab. I only had a look at the 6 examples listed in demo.m. Still two of them do not work: - exKSPDM: uses DMSetFunction that does not exist anymore. - exSNES_DVI: I got a segmentation fault. Jose

1 0

Re: [petsc-dev] XXXRegisterDestroy() are not called
by Jed Brown 05 Apr '13

05 Apr '13

On Fri, Apr 5, 2013 at 9:38 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > I'm learn towards not having a master "destroy all lists" approach (the > current model) and just having each XXXFinalizePackage() call > PetscFunctionListDestroy(&appropriate) so the XRegisterDestroy() are gone. > Does anyone have a reason to call XRegisterDestroy() independent of XFinalizePackage()? PetscFunctionListDestroy(&XList) is enough even in this case, but I'd like to understand the use case if it exists.

1 0

Re: [petsc-dev] XXXRegisterDestroy() are not called
by Barry Smith 05 Apr '13

05 Apr '13

On Apr 5, 2013, at 8:28 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > [Cc'ing Lisandro because petsc4py seems to be most sensitive to changes like this, though I don't think this affects him.] > > > On Fri, Apr 5, 2013 at 8:01 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Currently PetscFunctionListAdd() maintains a list of all function lists in existence and in PetscFinalize() PetscFunctionListDestroyAll() loops over all the list of lists destroying each list. Thus all of these lists are destroyed without the XXXRegisterDestroy() needing to be called. A drawback is that PetscFunctionListDestroyAll() is called before some of the XXXFinalizePackage() are called thus leaving XXXList global variables pointing to freed memory (this is why for example VecFinalizePackage() has VecList = NULL; in it.) > > I propose the following change; each appropriate XXXFinalizePackage() call the appropriate XXXRegisterDestroy() (this would replace the VecList = NULL; lines) and PetscFunctionListDestroyAll() be renamed to just generate a dump of any lists that don't get properly freed. > > Okay, note that PetscFunctionListAdd could store the address of the FunctionList (which it is passed) rather than just the list, in which case PetscFunctionListDestroyAll() would be able to zero VecList itself, getting rid of the problem of dangling lists. > > I think we should either do what you propose and consistently make VecList/MatList/etc static or we should consistently make them visible, get rid of VecRegisterAllCalled (which is redundant if PetscFunctionListDestroyAll can zero VecList by storing the pointer), and do away with all the XRegisterDestroy functions. > > I may be wrong, but I think it's rare that a user really wants to selectively clear a FunctionList, and in the rare case that they need it, PetscFunctionListDestroy(&VecList) would do the trick. I'm learn towards not having a master "destroy all lists" approach (the current model) and just having each XXXFinalizePackage() call PetscFunctionListDestroy(&appropriate) so the XRegisterDestroy() are gone.

1 0

Re: [petsc-dev] macro wrappers around functions to caste suck
by Jed Brown 05 Apr '13

05 Apr '13

On Fri, Apr 5, 2013 at 9:28 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > The biggest mistake of C was CPP > > Hey, we can eliminate the currently needed (PetscObject) cast in a > bunch of places with this horrible trick. > I thought you liked the explicitness of that cast. > This actually doesn't introduce any more macros, its the same number > with more reasonable naming. > Sure, it just uses #undef. I have no problem with changing it.

1 0

Re: [petsc-dev] macro wrappers around functions to caste suck
by Barry Smith 05 Apr '13

05 Apr '13

The biggest mistake of C was CPP Hey, we can eliminate the currently needed (PetscObject) cast in a bunch of places with this horrible trick. This actually doesn't introduce any more macros, its the same number with more reasonable naming. Barry On Apr 5, 2013, at 7:50 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Fri, Apr 5, 2013 at 7:40 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > (lldb) b PetscFunctionListAdd > Breakpoint 4: no locations (pending). > WARNING: Unable to resolve breakpoint to any actual locations. > (lldb) b PetscFunctionListAdd_Private > Breakpoint 5: where = libpetsc.dylib`PetscFunctionListAdd_Private + 23 at reg.c:173, address = 0x000000010a1d3697 > > The solution to too many macros is always MOAR MACROS! > > This is valid: > > PETSC_EXTERN PetscErrorCode PetscFunctionListAdd(PetscFunctionList*,const char[],void (*)(void)); > #define PetscFunctionListAdd(list,name,fptr) PetscFunctionListAdd((list),(name),(PetscVoidFunction)(fptr)) > > > off in the implementation: > > #undef PetscFunctionListAdd > PETSC_EXTERN PetscErrorCode PetscFunctionListAdd(PetscFunctionList *fl,const char name[],void (*fnc)(void)) > { > ... > } > > > This would make the debugging thing work, at the expense of being slightly more confusing to the reader. But maybe comments would be enough to explain what's going on?

1 0

Re: [petsc-dev] XXXRegisterDestroy() are not called
by Jed Brown 05 Apr '13

05 Apr '13

[Cc'ing Lisandro because petsc4py seems to be most sensitive to changes like this, though I don't think this affects him.] On Fri, Apr 5, 2013 at 8:01 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Currently PetscFunctionListAdd() maintains a list of all function lists in > existence and in PetscFinalize() PetscFunctionListDestroyAll() loops over > all the list of lists destroying each list. Thus all of these lists are > destroyed without the XXXRegisterDestroy() needing to be called. A drawback > is that PetscFunctionListDestroyAll() is called before some of the > XXXFinalizePackage() are called thus leaving XXXList global variables > pointing to freed memory (this is why for example VecFinalizePackage() has > VecList = NULL; in it.) > > I propose the following change; each appropriate XXXFinalizePackage() > call the appropriate XXXRegisterDestroy() (this would replace the VecList > = NULL; lines) and PetscFunctionListDestroyAll() be renamed to > just generate a dump of any lists that don't get properly freed. > Okay, note that PetscFunctionListAdd could store the address of the FunctionList (which it is passed) rather than just the list, in which case PetscFunctionListDestroyAll() would be able to zero VecList itself, getting rid of the problem of dangling lists. I think we should either do what you propose and consistently make VecList/MatList/etc static or we should consistently make them visible, get rid of VecRegisterAllCalled (which is redundant if PetscFunctionListDestroyAll can zero VecList by storing the pointer), and do away with all the XRegisterDestroy functions. I may be wrong, but I think it's rare that a user really wants to selectively clear a FunctionList, and in the rare case that they need it, PetscFunctionListDestroy(&VecList) would do the trick.

1 0

XXXRegisterDestroy() are not called
by Barry Smith 05 Apr '13

05 Apr '13

Folks, Currently we have all these XXXRegisterDestroy() routines that are not called petscao.h:PETSC_EXTERN PetscErrorCode AORegisterDestroy(void); petsccharacteristic.h:PETSC_EXTERN PetscErrorCode CharacteristicRegisterDestroy(void); petscdm.h:PETSC_EXTERN PetscErrorCode DMRegisterDestroy(void); petscdraw.h:PETSC_EXTERN PetscErrorCode PetscDrawRegisterDestroy(void); petscis.h:PETSC_EXTERN PetscErrorCode ISRegisterDestroy(void); petscksp.h:PETSC_EXTERN PetscErrorCode KSPRegisterDestroy(void); petscmat.h:PETSC_EXTERN PetscErrorCode MatOrderingRegisterDestroy(void); petscmat.h:PETSC_EXTERN PetscErrorCode MatColoringRegisterDestroy(void); petscmat.h:PETSC_EXTERN PetscErrorCode MatPartitioningRegisterDestroy(void); petscmat.h:PETSC_EXTERN PetscErrorCode MatCoarsenRegisterDestroy(void); petscmat.h:PETSC_EXTERN PetscErrorCode MatMFFDRegisterDestroy(void); petscpc.h:PETSC_EXTERN PetscErrorCode PCRegisterDestroy(void); petscpf.h:PETSC_EXTERN PetscErrorCode PFRegisterDestroy(void); petscsf.h:PETSC_EXTERN PetscErrorCode PetscSFRegisterDestroy(void); petscsnes.h:PETSC_EXTERN PetscErrorCode SNESRegisterDestroy(void); petscsnes.h:PETSC_EXTERN PetscErrorCode SNESLineSearchRegisterDestroy(void); petscsnes.h:PETSC_EXTERN PetscErrorCode SNESMSRegisterDestroy(void); petscsys.h:PETSC_EXTERN PetscErrorCode PetscObjectRegisterDestroy(PetscObject); petscsys.h:PETSC_EXTERN PetscErrorCode PetscObjectRegisterDestroyAll(void); petscsys.h:PETSC_EXTERN PetscErrorCode PetscRandomRegisterDestroy(void); petscthreadcomm.h:PETSC_EXTERN PetscErrorCode PetscThreadCommRegisterDestroy(void); petscts.h:PETSC_EXTERN PetscErrorCode TSRegisterDestroy(void); petscts.h:PETSC_EXTERN PetscErrorCode TSAdaptRegisterDestroy(void); petscts.h:PETSC_EXTERN PetscErrorCode TSGLAdaptRegisterDestroy(void); petscts.h:PETSC_EXTERN PetscErrorCode TSGLRegisterDestroy(void); petscts.h:PETSC_EXTERN PetscErrorCode TSARKIMEXRegisterDestroy(void); petscts.h:PETSC_EXTERN PetscErrorCode TSRosWRegisterDestroy(void); petscvec.h:PETSC_EXTERN PetscErrorCode VecRegisterDestroy(void); petscviewer.h:PETSC_EXTERN PetscErrorCode PetscViewerRegisterDestroy(void); The only one that is called is PetscThreadCommRegisterDestroy() and that is actually a (harmless) bug. Currently PetscFunctionListAdd() maintains a list of all function lists in existence and in PetscFinalize() PetscFunctionListDestroyAll() loops over all the list of lists destroying each list. Thus all of these lists are destroyed without the XXXRegisterDestroy() needing to be called. A drawback is that PetscFunctionListDestroyAll() is called before some of the XXXFinalizePackage() are called thus leaving XXXList global variables pointing to freed memory (this is why for example VecFinalizePackage() has VecList = NULL; in it.) I propose the following change; each appropriate XXXFinalizePackage() call the appropriate XXXRegisterDestroy() (this would replace the VecList = NULL; lines) and PetscFunctionListDestroyAll() be renamed to just generate a dump of any lists that don't get properly freed. Comments? I'd like to do it soon so it gets tested before the release but it is pretty straightforward, Barry

1 0

Re: [petsc-dev] macro wrappers around functions to caste suck
by Jed Brown 05 Apr '13

05 Apr '13

On Fri, Apr 5, 2013 at 7:40 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > (lldb) b PetscFunctionListAdd > Breakpoint 4: no locations (pending). > WARNING: Unable to resolve breakpoint to any actual locations. > (lldb) b PetscFunctionListAdd_Private > Breakpoint 5: where = libpetsc.dylib`PetscFunctionListAdd_Private + 23 at > reg.c:173, address = 0x000000010a1d3697 > The solution to too many macros is always MOAR MACROS! This is valid: PETSC_EXTERN PetscErrorCode PetscFunctionListAdd(PetscFunctionList*,const char[],void (*)(void)); #define PetscFunctionListAdd(list,name,fptr) PetscFunctionListAdd((list),(name),(PetscVoidFunction)(fptr)) off in the implementation: #undef PetscFunctionListAdd PETSC_EXTERN PetscErrorCode PetscFunctionListAdd(PetscFunctionList *fl,const char name[],void (*fnc)(void)) { ... } This would make the debugging thing work, at the expense of being slightly more confusing to the reader. But maybe comments would be enough to explain what's going on?

1 0

macro wrappers around functions to caste suck
by Barry Smith 05 Apr '13

05 Apr '13

(lldb) b PetscFunctionListAdd Breakpoint 4: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. (lldb) b PetscFunctionListAdd_Private Breakpoint 5: where = libpetsc.dylib`PetscFunctionListAdd_Private + 23 at reg.c:173, address = 0x000000010a1d3697

1 0

Re: [petsc-dev] Matlab interface
by Barry Smith 05 Apr '13

05 Apr '13

I have fixed the bug, it was introduced by me when changing MPIUni to have different MPI_COMM_SELF and WORLD. The fix is in next and in barry/fix-matlab Note I did not update the MATLAB scripts that are out of date. This fix needs to get into Master before the release. Thanks for reporting the problem, Barry On Apr 5, 2013, at 10:52 AM, Jose E. Roman <jroman(a)dsic.upv.es> wrote: > Has anyone tried the Matlab interface with petsc-dev? > > If I run exKSP.m three consecutive times, the first time it runs ok, the second time I see a memory leak (see below) and after that I get an error (with exKSP or any other one). This was not happening in 3.3. > > Also, some scripts are out-of-date. It is necessary to add mat.SetUp() and other minor fixes. > > Jose > >>> exKSP > Vector Object: 1 MPI processes > type: seq > 12.5 > 14.5 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > 10 > Matrix Object: 1 MPI processes > type: seqaij > row 0: (0, 10) > row 1: (1, 10) > row 2: (2, 10) > row 3: (3, 10) > row 4: (4, 10) > row 5: (5, 10) > row 6: (6, 10) > row 7: (7, 10) > row 8: (8, 10) > row 9: (9, 10) > 0 KSP Residual norm 2.732215218463e+00 > 1 KSP Residual norm 1.516684121884e-16 > Vector Object: 1 MPI processes > type: seq > 1.25 > 1.45 > 0.3 > 0.4 > 0.5 > 0.6 > 0.7 > 0.8 > 0.9 > 1 > KSP Object: 1 MPI processes > type: gmres > GMRES: restart=30, using Classical (unmodified) Gram-Schmidt Orthogonalization with no iterative refinement > GMRES: happy breakdown tolerance 1e-30 > maximum iterations=10000, initial guess is zero > tolerances: relative=1e-05, absolute=1e-50, divergence=10000 > left preconditioning > using PRECONDITIONED norm type for convergence test > PC Object: 1 MPI processes > type: ilu > ILU: out-of-place factorization > 0 levels of fill > tolerance for zero pivot 2.22045e-14 > using diagonal shift on blocks to prevent zero pivot > matrix ordering: natural > factor fill ratio given 1, needed 1 > Factored matrix follows: > Matrix Object: 1 MPI processes > type: seqaij > rows=10, cols=10 > package used to perform factorization: petsc > total: nonzeros=10, allocated nonzeros=10 > total number of mallocs used during MatSetValues calls =0 > not using I-node routines > linear system matrix = precond matrix: > Matrix Object: 1 MPI processes > type: seqaij > rows=10, cols=10 > total: nonzeros=10, allocated nonzeros=50 > total number of mallocs used during MatSetValues calls =0 > not using I-node routines > [0]Total space allocated 4880 bytes > [ 0]16 bytes PetscThreadCommReductionCreate() line 448 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcommred.c > [0] PetscThreadCommReductionCreate() line 448 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcommred.c > [0] PetscThreadCommWorldInitialize() line 1251 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]512 bytes PetscThreadCommReductionCreate() line 440 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcommred.c > [0] PetscThreadCommReductionCreate() line 440 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcommred.c > [0] PetscThreadCommWorldInitialize() line 1251 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]128 bytes PetscThreadCommReductionCreate() line 436 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcommred.c > [0] PetscThreadCommReductionCreate() line 436 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcommred.c > [0] PetscThreadCommWorldInitialize() line 1251 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]1280 bytes PetscThreadCommReductionCreate() line 435 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcommred.c > [0] PetscThreadCommReductionCreate() line 435 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcommred.c > [0] PetscThreadCommWorldInitialize() line 1251 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]32 bytes PetscThreadCommReductionCreate() line 432 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcommred.c > [0] PetscThreadCommReductionCreate() line 432 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcommred.c > [0] PetscThreadCommWorldInitialize() line 1251 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]64 bytes PetscThreadCommWorldInitialize() line 1265 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommWorldInitialize() line 1265 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]2432 bytes PetscThreadCommWorldInitialize() line 1264 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommWorldInitialize() line 1264 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]16 bytes PetscThreadCommWorldInitialize() line 1256 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommWorldInitialize() line 1256 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]16 bytes PetscThreadCommSetAffinities() line 423 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommSetAffinities() line 423 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommWorldInitialize() line 1251 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]48 bytes PetscThreadCommCreate() line 150 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommCreate() line 150 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommWorldInitialize() line 1251 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]320 bytes PetscThreadCommCreate() line 146 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommCreate() line 146 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscThreadCommWorldInitialize() line 1251 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscGetThreadCommWorld() line 80 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommGetThreadComm() line 114 in /Users/jroman/soft/petsc/src/sys/threadcomm/interface/threadcomm.c > [0] PetscCommDuplicate() line 139 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c > [ 0]16 bytes PetscCommDuplicate() line 151 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscCommDuplicate() line 151 in /Users/jroman/soft/petsc/src/sys/objects/tagm.c > [0] PetscHeaderCreate_Private() line 31 in /Users/jroman/soft/petsc/src/sys/objects/inherit.c > [0] VecCreate() line 32 in /Users/jroman/soft/petsc/src/vec/vec/interface/veccreate.c >>> exKSP > [0]PETSC ERROR: --------------------- Error Message ------------------------------------ > [0]PETSC ERROR: Invalid argument! > [0]PETSC ERROR: Wrong type of object: Parameter # 2! > [0]PETSC ERROR: ------------------------------------------------------------------------ > [0]PETSC ERROR: Petsc Development GIT revision: 854e096b3f56ee49eddbdee02830d60adb46893b GIT Date: 2013-04-03 20:53:18 -0500 > [0]PETSC ERROR: See docs/changes/index.html for recent updates. > [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > [0]PETSC ERROR: See docs/index.html for manual pages. > [0]PETSC ERROR: ------------------------------------------------------------------------ > [0]PETSC ERROR: matlab on a arch-darwin-c-debug-matlab named pptp243-73.vpns.upv.es by jroman Fri Apr 5 17:49:20 2013 > [0]PETSC ERROR: Libraries linked from /Users/jroman/soft/petsc/arch-darwin-c-debug-matlab/lib > [0]PETSC ERROR: Configure run at Fri Apr 5 17:31:03 2013 > [0]PETSC ERROR: Configure options --with-matlab --with-matlab-engine --with-mpi=0 > [0]PETSC ERROR: ------------------------------------------------------------------------ > [0]PETSC ERROR: VecView() line 682 in /Users/jroman/soft/petsc/src/vec/vec/interface/vector.c > ??? Error using ==> PetscCHKERRQ at 3 > Errors generated on calling Petsc library function > > Error in ==> PetscVec>PetscVec.View at 106 > err = calllib('libpetsc', 'VecView', obj.pobj,0);PetscCHKERRQ(err); > > Error in ==> PetscVec>PetscVec.subsref at 123 > [varargout{1:nargout}] = builtin('subsref', obj, S); > > Error in ==> exKSP at 18 > b.View; > >

1 0