<div dir="ltr">On Wed, Sep 18, 2013 at 10:06 AM, Vijay S. Mahadevan <span dir="ltr"><<a href="mailto:vijay.m@gmail.com" target="_blank">vijay.m@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Until you can provide the preallocation you need to simply call MatSetUp() and then MatAssemblyBegin/End() on your matrix inside your DMCreateMatrix_Moab(). The expectation is that the DM matrix provided is "ready to go", we didn't expect to handle matrices that were "incomplete" in other parts of the code.<br>
<br>
Interesting. Calling MatAssemblyBegin/End() without any MatSetValues*<br>
wipes out the preallocation information. With -info turned on, I get<br>
the following for some sample run.<br>
<br>
[0] MatAssemblyEnd_SeqAIJ(): Matrix size: 5192 X 5192; storage space:<br>
6906304 unneeded,0 used<br>
[0] MatAssemblyEnd_SeqAIJ(): Number of mallocs during MatSetValues() is 0<br>
[0] MatAssemblyEnd_SeqAIJ(): Maximum nonzeros in any row is 0<br>
<br>
I do understand the expectation that matrix from DMCreateMatrix needs<br>
to be complete but just that traversing through the mesh and setting<br>
the right NNZ is difficult (I dont think this should exist in the<br>
library code since this is physics/problem dependent). Somewhat<br>
manageable for DMDA since it relies on a predefined stencil but I<br>
couldn't wrap my head around doing this for a generic enough<br>
implementation. I will think about this some more.<br></blockquote><div><br></div><div>DMPlex does it.</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The "user matrix" must have been assembled otherwise it would have stopped above.<br>
<br>
It did.<br>
<br>
Vijay<br>
<br>
On Wed, Sep 18, 2013 at 11:17 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> On Sep 18, 2013, at 10:52 AM, "Vijay S. Mahadevan" <<a href="mailto:vijay.m@gmail.com">vijay.m@gmail.com</a>> wrote:<br>
><br>
>>> Why are you setting this flag? If you don't set it then the code will go through.<br>
>><br>
>> Yes it passes through with DMDA. But with my custom DM implementation<br>
>> (MOAB based), this fails unless I explicitly set the NNZ pattern in<br>
>> DMCreateMatrix. I currently don't do that and the only way to<br>
>> replicate this behavior with DMDA was setting the flag explicitly.<br>
><br>
> Until you can provide the preallocation you need to simply call MatSetUp() and then MatAssemblyBegin/End() on your matrix inside your DMCreateMatrix_Moab(). The expectation is that the DM matrix provided is "ready to go", we didn't expect to handle matrices that were "incomplete" in other parts of the code.<br>
><br>
>><br>
>>> There is no reason to use a user created matrix since the DM can provide the correct one. One of the "main jobs" of DM is to create that matrix so we really don't intend people to use a DM but then create the matrix themselves.<br>
>><br>
>> Agreed, and that's what I expected when I passed in NULL args instead<br>
>> of user matrix. But the DM created matrix errors out during Duplicate<br>
>> while user provided matrix passes through, even though both of them<br>
>> are unassembled.<br>
><br>
> PetscErrorCode MatDuplicate(Mat mat,MatDuplicateOption op,Mat *M)<br>
> {<br>
> PetscErrorCode ierr;<br>
> Mat B;<br>
> PetscInt i;<br>
><br>
> PetscFunctionBegin;<br>
> PetscValidHeaderSpecific(mat,MAT_CLASSID,1);<br>
> PetscValidType(mat,1);<br>
> PetscValidPointer(M,3);<br>
> if (!mat->assembled) SETERRQ(PetscObjectComm((PetscObject)mat),PETSC_ERR_ARG_WRONGSTATE,"Not for unassembled matrix");<br>
><br>
> The "user matrix" must have been assembled otherwise it would have stopped above.<br>
><br>
><br>
>> And this is what is confusing.<br>
>><br>
>> Vijay<br>
>><br>
>> On Wed, Sep 18, 2013 at 10:46 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>>><br>
>>> The code did not "crash", it ended with an error message<br>
>>><br>
>>><br>
>>> On Sep 18, 2013, at 10:32 AM, "Vijay S. Mahadevan" <<a href="mailto:vijay.m@gmail.com">vijay.m@gmail.com</a>> wrote:<br>
>>><br>
>>>> All,<br>
>>>><br>
>>>> When I call DMSetMatrixPreallocateOnly<br>
>>><br>
>>> Why are you setting this flag? If you don't set it then the code will go through.<br>
>>><br>
>>>> and then TSSetRHSJacobian<br>
>>>> without a matrix input argument (NULL instead), then the code crashes<br>
>>>> during TSSolve and more specifically during MatDuplicate. This is<br>
>>>> replicable with src/ts/examples/tutorials/ex2.c. Here's the error with<br>
>>><br>
>>> Jed is reworking the logic here so the code will change.<br>
>>><br>
>>><br>
>>>> stack trace.<br>
>>>><br>
>>>> [0]PETSC ERROR: --------------------- Error Message<br>
>>>><br>
>>>><br>
>>>> I hope this is not supposed to happen. The fix seems to be to call<br>
>>>> TSSetRHSJacobian with a user created matrix instead of letting DM<br>
>>>> create one,<br>
>>><br>
>>> There is no reason to use a user created matrix since the DM can provide the correct one. One of the "main jobs" of DM is to create that matrix so we really don't intend people to use a DM but then create the matrix themselves.<br>
>>><br>
>>> Barry<br>
>>><br>
>>><br>
>>>> which rectifies this issue. This behavior feels<br>
>>>> inconsistent and is there a way to fix this.<br>
>>>><br>
>>>> Vijay<br>
>>>><br>
>>>> PS: Just replace the following lines in ex2.c to replicate the error.<br>
>>>><br>
>>>> /* ierr = TSSetRHSJacobian(ts,A,A,RHSJacobian,&appctx);CHKERRQ(ierr); */<br>
>>>> ierr = TSSetRHSJacobian(ts,NULL,NULL,RHSJacobian,&appctx);CHKERRQ(ierr);<br>
>>>> ierr = DMSetMatrixPreallocateOnly(appctx.da,PETSC_TRUE);CHKERRQ(ierr);<br>
>>><br>
><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>