Oh sorry, I missed that. That's great!
Thanks,
Myriam
Le 05/29/19 à 16:55, Zhang, Hong a écrit :
> Myriam:
> This branch is merged to master.
> Thanks for your work and patience. It helps us a lot. The graphs are
> very nice :-)
>
> We plan to re-organise the APIs of mat-mat opts, make them
Myriam:
This branch is merged to master.
Thanks for your work and patience. It helps us a lot. The graphs are very nice
:-)
We plan to re-organise the APIs of mat-mat opts, make them easier for users.
Hong
Hi,
Do you have any idea when Barry's fix
Hmm, I had already fixed this, I think,
https://bitbucket.org/petsc/petsc/pull-requests/1606/change-handling-of-matptap_mpiaij_mpimaij/diff
but unfortunately our backlog of pull requests kept it out of master. We are
(well Satish and Jed) working on a new CI infrastructure that
Myriam:
Very interesting results. Do you have time for petsc-3.10 (blue) and 3.6
(green)?
I do not understand why all algorithms gives non-scalable memory performance
except petsc-3.6. We can easily resume petsc-3.6's MatPtAP though.
Hong
And the attached files... Sorry
Le 05/03/19 à 16:11,
Hi,
I plotted new scalings (memory and time) using the new algorithms. I
used the options /-options_left true /to make sure that the options are
effectively used. They are.
I don't have access to the platform I used to run my computations on, so
I ran them on a different one. In particular, I
On Tue, Mar 5, 2019 at 8:06 AM Matthew Knepley wrote:
> On Tue, Mar 5, 2019 at 7:14 AM Myriam Peyrounette <
> myriam.peyroune...@idris.fr> wrote:
>
>> Hi Matt,
>>
>> I plotted the memory scalings using different threshold values. The two
>> scalings are slightly translated (from -22 to -88 mB)
Hi,
that's really good news for us, thanks! I will plot again the memory
scaling using these new options and let you know. Next week I hope.
Before that, I just need to clarify the situation. Throughout our
discussions, we mentionned a number of options concerning the scalability:
-matptatp_via
On Mon, Mar 11, 2019 at 6:32 AM Myriam Peyrounette <
myriam.peyroune...@idris.fr> wrote:
> Hi,
>
> good point, I changed the 3.10 version so that it is configured with
> --with-debugging=0. You'll find attached the output of the new LogView. The
> execution time is reduced (although still not as
Increasing the threshold should increase the size of the coarse grids, but
yours are decreasing. I'm puzzled by that.
On Tue, Mar 5, 2019 at 11:53 AM Myriam Peyrounette <
myriam.peyroune...@idris.fr> wrote:
> I used PCView to display the size of the linear system in each level of
> the MG.
> Mark, what is the option she can give to output all the GAMG data?
>
>
-info and then grep on GAMG.
This will print the number of non-zeros per row, which is useful. The
memory size of the matrices will also give you data on this.
> Also, run using -ksp_view. GAMG will report all the sizes
Myriam:
Checking MatPtAP() in petsc-3.6.4, I realized that it uses different algorithm
than petsc-10 and later versions. petsc-3.6 uses out-product for C=P^T * AP,
while petsc-3.10 uses local transpose of P. petsc-3.10 accelerates data
accessing, but doubles the memory of P.
Fande added two
Myriam:
Thank you very much for providing these results!
I have put effort to accelerate execution time and avoid using global sizes in
PtAP, for which the algorithm of transpose of P_local and P_other likely
doubles the memory usage. I'll try to investigate why it becomes unscalable.
Hong
Hi,
Hi,
you'll find the new scaling attached (green line). I used the version
3.11 and the four scalability options :
-matptap_via scalable
-inner_diag_matmatmult_via scalable
-inner_offdiag_matmatmult_via scalable
-mat_freeintermediatedatastructures
The scaling is much better! The code even uses
Myriam :
Thanks for your effort. It will help us improve PETSc.
Hong
Hi all,
I used the wrong script, that's why it diverged... Sorry about that.
I tried again with the right script applied on a tiny problem (~200
elements). I can see a small difference in memory usage (gain ~ 1mB).
when adding
Hi all,
I used the wrong script, that's why it diverged... Sorry about that.
I tried again with the right script applied on a tiny problem (~200
elements). I can see a small difference in memory usage (gain ~ 1mB).
when adding the -mat_freeintermediatestructures option. I still have to
execute
"Zhang, Hong" writes:
> Jed:
>>> Myriam,
>>> Thanks for the plot. '-mat_freeintermediatedatastructures' should not
>>> affect solution. It releases almost half of memory in C=PtAP if C is not
>>> reused.
>
>> And yet if turning it on causes divergence, that would imply a bug.
>> Hong, are you
Jed:
> Myriam,
> Thanks for the plot. '-mat_freeintermediatedatastructures' should not affect
> solution. It releases almost half of memory in C=PtAP if C is not reused.
And yet if turning it on causes divergence, that would imply a bug.
Hong, are you able to reproduce the experiment to see the
"Zhang, Hong via petsc-users" writes:
> Myriam,
> Thanks for the plot. '-mat_freeintermediatedatastructures' should not affect
> solution. It releases almost half of memory in C=PtAP if C is not reused.
And yet if turning it on causes divergence, that would imply a bug.
Hong, are you able to
Myriam,
Thanks for the plot. '-mat_freeintermediatedatastructures' should not affect
solution. It releases almost half of memory in C=PtAP if C is not reused.
Hong
On Wed, Apr 10, 2019 at 7:21 AM Mark Adams
mailto:mfad...@lbl.gov>> wrote:
This looks like it might be noisy data. I'd make sure
This looks like it might be noisy data. I'd make sure you run each size on
the same set of nodes and you might run each job twice (A,B,A,B) in a job
script.
On Wed, Apr 10, 2019 at 8:12 AM Myriam Peyrounette via petsc-users <
petsc-users@mcs.anl.gov> wrote:
> Here is the time weak scaling from
Here is the time weak scaling from the same study. The 3.10.2 version
seems to be much more stable with regard to the execution time. But not
necessarily faster for "large scale" simulations (problem size = 1e8).
I didn't use -mat_freeintermediatedatastructures. I tested it this
morning and the
Myriam,
Do you have 'execution time scalability' plot? Did you use
'-mat_freeintermediatedatastructures' for PETSc 3.10.2?
We made several computing optimizations on MatPtAP(), which might trade memory
for speed. It would be helpful to see a complete comparison.
Hong
On Tue, Apr 9, 2019 at 7:43
Myriam Peyrounette via petsc-users writes:
> Hi all,
>
> for your information, you'll find attached the comparison of the weak
> memory scalings when using :
>
> - PETSc 3.6.4 (reference)
> - PETSc 3.10.4 without specific options
> - PETSc 3.10.4 with the three scalability options you mentionned
*SetFromOptions() was not called indeed... Thanks! The code performance
is better now with regard to memory usage!
I still have to plot the memory scaling on bigger cases to see if it has
the same good behaviour as when using the 3.6 version.
I'll let ou know as soon as I have plotted it.
On Tue, Mar 26, 2019 at 9:27 AM Myriam Peyrounette <
myriam.peyroune...@idris.fr> wrote:
> I checked with -ksp_view (attached) but no prefix is associated with the
> matrix. Some are associated to the KSP and PC, but none to the Mat
>
Another thing that could prevent options being used is that
I checked with -ksp_view (attached) but no prefix is associated with the
matrix. Some are associated to the KSP and PC, but none to the Mat.
Le 03/26/19 à 11:55, Dave May a écrit :
>
>
> On Tue, 26 Mar 2019 at 10:36, Myriam Peyrounette
> mailto:myriam.peyroune...@idris.fr>> wrote:
>
> Oh you
Oh you were right, the three options are unsused (-matptap_via scalable,
-inner_offdiag_matmatmult_via scalable and -inner_diag_matmatmult_via
scalable). Does this mean I am not using the associated PtAP functions?
Myriam
Le 03/26/19 à 11:10, Dave May a écrit :
>
> On Tue, 26 Mar 2019 at 09:52,
How can I be sure they are indeed used? Can I print this information in
some log file?
Thanks in advance
Myriam
Le 03/25/19 à 18:24, Matthew Knepley a écrit :
> On Mon, Mar 25, 2019 at 10:54 AM Myriam Peyrounette via petsc-users
> mailto:petsc-users@mcs.anl.gov>> wrote:
>
> Hi,
>
>
Hi,
thanks for the explanations. I tried the last PETSc version (commit
fbc5705bc518d02a4999f188aad4ccff5f754cbf), which includes the patch you
talked about. But the memory scaling shows no improvement (see scaling
attached), even when using the "scalable" options :(
I had a look at the PETSc
More precisely: something happens when upgrading the functions
MatPtAPNumeric_MPIAIJ_MPIAIJ and/or MatPtAPSymbolic_MPIAIJ_MPIAIJ.
Unfortunately, there are a lot of differences between the old and new
versions of these functions. I keep investigating but if you have any
idea, please let me know.
Hi all,
I used git bisect to determine when the memory need increased. I found
that the first "bad" commit is aa690a28a7284adb519c28cb44eae20a2c131c85.
Barry was right, this commit seems to be about an evolution of
MatPtAPSymbolic_MPIAIJ_MPIAIJ. You mentioned the option "-matptap_via
scalable"
There is a small difference in memory usage already (of 135mB). It is
not a big deal but it will be for larger problems (as shown by the
memory scaling). If we find the origin of this small gap for a small
case, we probably find the reason why the memory scaling is so bad with
3.10.
I am
Is there a difference in memory usage on your tiny problem? I assume no.
I don't see anything that could come from GAMG other than the RAP stuff
that you have discussed already.
On Mon, Mar 11, 2019 at 9:32 AM Myriam Peyrounette <
myriam.peyroune...@idris.fr> wrote:
> The code I am using here
The code I am using here is the example 42 of PETSc
(https://www.mcs.anl.gov/petsc/petsc-3.9/src/ksp/ksp/examples/tutorials/ex42.c.html).
Indeed it solves the Stokes equation. I thought it was a good idea to
use an example you might know (and didn't find any that uses GAMG
functions). I just
In looking at this larger scale run ...
* Your eigen estimates are much lower than your tiny test problem. But
this is Stokes apparently and it should not work anyway. Maybe you have a
small time step that adds a lot of mass that brings the eigen estimates
down. And your min eigenvalue (not
GAMG look fine here but the convergence rate looks terrible, like 4k+
iterations. You have 4 degrees of freedom per vertex. What equations and
discretization are you using?
Your eigen estimates are a little high, but not crazy. I assume this system
is not symmetric.
AMG is oriented toward the
Hi,
good point, I changed the 3.10 version so that it is configured with
--with-debugging=0. You'll find attached the output of the new LogView.
The execution time is reduced (although still not as good as 3.6) but I
can't see any improvement with regard to memory.
You'll also find attached the
Just seeing this now. It is hard to imagine how bad GAMG could be on a
coarse grid, but you can run with -info and grep on GAMG and send that. You
will see listing of levels, number of equations and number of non-zeros
(nnz). You can send that and I can get some sense of GAMG is going nuts.
Mark
It may not address the memory issue, but can you build 3.10 with the
same options you used for 3.6? It is currently a debugging build:
##
##
#
Myriam, in your first message, there was a significant (about 50%)
increase in memory consumption already on 4 cores. Before attacking
scaling, it may be useful to trace memory usage for that base case.
Even better if you can reduce to one process. Anyway, I would start by
running both cases
Myriam,
Sorry we have not been able to resolve this problem with memory scaling yet.
The best tool to determine the change in a code that results in large
differences in a program's run is git bisect. Basically you tell git bisect
the git commit of the code that is "good" and the
I used PCView to display the size of the linear system in each level of
the MG. You'll find the outputs attached to this mail (zip file) for
both the default threshold value and a value of 0.1, and for both 3.6
and 3.10 PETSc versions.
For convenience, I summarized the information in a graph,
Hi Matt,
I plotted the memory scalings using different threshold values. The two
scalings are slightly translated (from -22 to -88 mB) but this gain is
neglectable. The 3.6-scaling keeps being robust while the 3.10-scaling
deteriorates.
Do you have any other suggestion?
Thanks
Myriam
Le
43 matches
Mail list logo
