On Mon, Jun 27, 2022 at 2:16 PM Matthew Martineau
wrote:
> Theoretically the access patterns can be worse, but our sparse operations
> output matrices with unordered columns, so the fine matrix being sorted
> shouldn’t impact the overall performance.
>
And this "unsorted" is really two _sorted_
of the development version of PETSc
Subject: Re: [petsc-dev] MatMPIAIJGetLocalMat problem with GPUs
External email: Use caution opening links or attachments
On Jun 25, 2022, at 9:44 AM, Matthew Martineau
mailto:mmartin...@nvidia.com>> wrote:
Thanks - AmgX will accept unordered column indices.
It looks like the problem is with a commit: ** | | | | | e24d7920346 -
Fixing issue with PCReset_AMGX (5 days ago) *
(see at end of log below)
Somehow this got on a different "branch".
I manually merged this commit and the rest of the rebase went well.
* 3d182f284fb - (HEAD -> adams/pcamgx,
On Sat, Jun 25, 2022 at 9:39 AM Barry Smith wrote:
>
> Does AMGX require sorted column indices? (Python indentation notation
> below)
>
> If not
> just use MatMPIAIJGetLocalMatMerge instead of MatMPIAIJGetLocalMat.
>
>
Ugh, I worked on this this AM without rebasing over main and lost my
>
> From: Barry Smith
> Sent: Saturday, 25 June 2022, 14:39
> To: Mark Adams
> Cc: Matthew Martineau ; For users of the development
> version of PETSc
> Subject: Re: [petsc-dev] MatMPIAIJGetLocalMat problem with GPUs
>
> External email: Use caution opening links
Thanks - AmgX will accept unordered column indices.
From: Barry Smith
Sent: Saturday, 25 June 2022, 14:39
To: Mark Adams
Cc: Matthew Martineau ; For users of the development
version of PETSc
Subject: Re: [petsc-dev] MatMPIAIJGetLocalMat problem with GPUs
;>>> errors (presumably because of the type mismatch).
>>>>
>>>> If we call MatSeqAIJGetArrayRead on localA and then pass the `values` to
>>>> AmgX it seems to detect that the pointer is a device mapped pointer but
>>>> that it is inval
GetArrayRead on localA and then pass the `values`
>>>> to AmgX it seems to detect that the pointer is a device mapped pointer but
>>>> that it is invalid.
>>>>
>>>> PetscCall(MatMPIAIJGetLocalMat(Pmat, MAT_REUSE_MATRIX, >localA));
>>>&
eems to
>>> return invalid pointer, but I’ll investigate more
>>>
>>> This doesn’t reproduce if we call:
>>>
>>> PetscCall(MatMPIAIJGetLocalMat(Pmat, MAT_INITIAL_MATRIX, >localA));
>>> PetscCall(MatSeqAIJGetArrayRead(amgx->localA, >valu
tArrayRead(amgx->localA, >values)); // Seems
>>> to return invalid pointer, but I’ll investigate more
>>>
>>> This doesn’t reproduce if we call:
>>>
>>> PetscCall(MatMPIAIJGetLocalMat(Pmat, MAT_INITIAL_MATRIX, >localA));
>>> PetscCall(MatSeqAIJGe
t of A and the device pointer to the matrix values from that
>> structure so that we can pass to AmgX. Preferring whichever API calls are
>> the most efficient.
>>
>>
>> From: Stefano Zampini > <mailto:stefano.zamp...@gmail.com>>
>> Sent: 23 June
tch
>> the local part of A and the device pointer to the matrix values from that
>> structure so that we can pass to AmgX. Preferring whichever API calls are
>> the most efficient.
>>
>>
>> *From:* Stefano Zampini
>> *Sent:* 23 June 2022 20:55
>> *To:* Mark Adam
achieve is that when we are parallel, we fetch
> the local part of A and the device pointer to the matrix values from that
> structure so that we can pass to AmgX. Preferring whichever API calls are
> the most efficient.
>
>
> *From:* Stefano Zampini
> *Sent:* 23 June 2022 20:5
r users of the development version of
PETSc ; Matthew Martineau
Subject: Re: [petsc-dev] MatMPIAIJGetLocalMat problem with GPUs
External email: Use caution opening links or attachments
The logic is wrong. It should check for MATSEQAIJCUSPARSE.
On Thu, Jun 23, 2022, 21:36 Mark Adams
mailto:mfad...
t efficient.
>
>
> From: Stefano Zampini <mailto:stefano.zamp...@gmail.com>>
> Sent: 23 June 2022 20:55
> To: Mark Adams mailto:mfad...@lbl.gov>>
> Cc: Barry Smith mailto:bsm...@petsc.dev>>; For users of
> the development version of PETSc <mailto
The logic is wrong. It should check for MATSEQAIJCUSPARSE.
On Thu, Jun 23, 2022, 21:36 Mark Adams wrote:
>
>
> On Thu, Jun 23, 2022 at 3:02 PM Barry Smith wrote:
>
>>
>> It looks like the current code copies the nonzero values to the CPU
>> from the MPI matrix (with the calls
>>
On Thu, Jun 23, 2022 at 3:02 PM Barry Smith wrote:
>
> It looks like the current code copies the nonzero values to the CPU from
> the MPI matrix (with the calls
> PetscCall(MatSeqAIJGetArrayRead(mpimat->A,));
> PetscCall(MatSeqAIJGetArrayRead(mpimat->B,));, then copies them into
> the CPU
It looks like the current code copies the nonzero values to the CPU from the
MPI matrix (with the calls PetscCall(MatSeqAIJGetArrayRead(mpimat->A,));
PetscCall(MatSeqAIJGetArrayRead(mpimat->B,));, then copies them into the
CPU memory of the Seq matrix. When the matrix entries are next
How do you use amgx->localA after it is created?
On Thu, Jun 23, 2022, 20:25 Mark Adams wrote:
> We have a bug in the AMGx test snes_tests-ex13_amgx in parallel.
> Matt Martineau found that MatMPIAIJGetLocalMat worked in the first pass in
> the code below, where the local matrix is created
We have a bug in the AMGx test snes_tests-ex13_amgx in parallel.
Matt Martineau found that MatMPIAIJGetLocalMat worked in the first pass in
the code below, where the local matrix is created (INITIAL), but in the
next pass, when "REUSE" is used, he sees an invalid pointer.
Matt found that it does
20 matches
Mail list logo
