date:20210317

Re: [petsc-dev] MatTransposeMatMult() bug

2021-03-17 Thread Pierre Jolivet

https://www.sciencedirect.com/science/article/abs/pii/S089812212155 

https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPHPDDM.html 

https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/PC/PCHPDDM.html 

I need to update the PETSc user manual though, specifically with respect to 
systems with multiple right-hand sides.
But don’t worry, Stefano has sorted the bug out, which was due to a faulty 
MatSetFromOptions() in MatMAIJ, used by MatTransposeMatMult().

Thanks,
Pierre

> On 17 Mar 2021, at 11:21 PM, Zhang, Hong  wrote:
> 
> What is hpddm? I do not see its document.
> Hong
> 
> From: Matthew Knepley 
> Sent: Wednesday, March 17, 2021 2:49 PM
> To: Zhang, Hong 
> Cc: Pierre Jolivet ; For users of the development version of 
> PETSc 
> Subject: Re: [petsc-dev] MatTransposeMatMult() bug
>  
> On Wed, Mar 17, 2021 at 3:27 PM Zhang, Hong via petsc-dev 
> mailto:petsc-dev@mcs.anl.gov>> wrote:
> Pierre,
> Do you mean a possible bug in C=AtB MatTransposeMatMult()?
> Can you provide a stand-alone test without hpddm that reproduces this error? 
> 
> Hong, you should be able to just configure with --download-hpddm and then run 
> that ex76 test.
> 
>   Thanks,
> 
>  Matt
>  
> Hong
> From: petsc-dev  > on behalf of Pierre Jolivet 
> mailto:pie...@joliv.et>>
> Sent: Wednesday, March 17, 2021 4:31 AM
> To: For users of the development version of PETSc  >
> Subject: [petsc-dev] MatTransposeMatMult() bug
>  
> Hello,
> While trying out Stefano’s PCApplyMat_MG() code (*), we stumbled upon weird 
> numerical errors when reusing a Mat for both MatProduct_AB and MatProduct_AtB.
> This reminded me that there has been a long-standing issue with 
> MatTransposeMatMult(), see 
> https://www.mcs.anl.gov/petsc/petsc-current/src/ksp/pc/impls/hpddm/hpddm.cxx.html#line608
>  
> ,
>  that I never looked into.
> I’ve now been trying to figure this out, because this has side effects in 
> multiple places (PCMG and PCHPDDM at least), and thus could impact user-code 
> as well?
> With this commit: 
> https://gitlab.com/petsc/petsc/-/commit/03d8bd538039defc2fcc3e37d523735c4aaceba0
>  
> 
> +
> $ mpirun -n 4 src/ksp/ksp/tutorials/ex76 -ksp_converged_reason -pc_type hpddm 
> -pc_hpddm_levels_1_eps_nev 20 -ksp_type preonly -mat_type aij -load_dir 
> ${DATAFILESPATH}/matrices/hpddm/GENEO -rhs 2 -pc_hpddm_coarse_correction 
> balanced -C_input_mattransposematmult -D_output_mattransposematmult
> I’m seeing that C is nonzero, but D is full of zeros.
> Mat Object: 4 MPI processes
>   type: mpidense
> 5.7098316584361917e-08 1.0159399260517841e-07
> 1.5812349976211856e-07 2.0688121715350138e-07
> 2.4887556933361981e-08 4.8111092300772958e-08
> 1.4606298643602107e-07 1.7213611729839211e-07
> […]
> Mat Object: 4 MPI processes
>   type: mpidense
> 0.e+00 0.e+00
> 0.e+00 0.e+00
> 0.e+00 0.e+00
> 0.e+00 0.e+00
> […]
> 
> If one switches to a MatType which has no MatProduct_AtB implementation with 
> B of type MPIDense (reminder: in that case, the product is computed 
> column-by-column), e.g., -mat_type sbaij, one gets the expected result.
> Mat Object: 4 MPI processes
>   type: mpidense
> 7.2003197398135299e-01 9.5191869895699011e-01
> 6.1793966541680234e-02 9.3884397585488877e-01
> 1.0022337823233585e-02 2.4653068080134588e-01
> 1.4463931936094099e-01 8.6111517670701687e-01
> 
> Is there a bug somewhere with the MatAIJ implementation, or am I doing 
> something which is not allowed by the MatProduct() machinery?
> 
> Thanks,
> Pierre
> 
> (*) https://gitlab.com/petsc/petsc/-/merge_requests/3717 
>  
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments 
> is infinitely more interesting than any results to which their experiments 
> lead.
> -- Norbert Wiener
> 
> https://www.cse.buffalo.edu/~knepley/

Re: [petsc-dev] MatTransposeMatMult() bug

2021-03-17 Thread Zhang, Hong via petsc-dev

What is hpddm? I do not see its document.
Hong

From: Matthew Knepley 
Sent: Wednesday, March 17, 2021 2:49 PM
To: Zhang, Hong 
Cc: Pierre Jolivet ; For users of the development version of 
PETSc 
Subject: Re: [petsc-dev] MatTransposeMatMult() bug

On Wed, Mar 17, 2021 at 3:27 PM Zhang, Hong via petsc-dev 
mailto:petsc-dev@mcs.anl.gov>> wrote:
Pierre,
Do you mean a possible bug in C=AtB MatTransposeMatMult()?
Can you provide a stand-alone test without hpddm that reproduces this error?

Hong, you should be able to just configure with --download-hpddm and then run 
that ex76 test.

  Thanks,

 Matt

Hong

From: petsc-dev 
mailto:petsc-dev-boun...@mcs.anl.gov>> on behalf 
of Pierre Jolivet mailto:pie...@joliv.et>>
Sent: Wednesday, March 17, 2021 4:31 AM
To: For users of the development version of PETSc 
mailto:petsc-dev@mcs.anl.gov>>
Subject: [petsc-dev] MatTransposeMatMult() bug

Hello,
While trying out Stefano’s PCApplyMat_MG() code (*), we stumbled upon weird 
numerical errors when reusing a Mat for both MatProduct_AB and MatProduct_AtB.
This reminded me that there has been a long-standing issue with 
MatTransposeMatMult(), see 
https://www.mcs.anl.gov/petsc/petsc-current/src/ksp/pc/impls/hpddm/hpddm.cxx.html#line608,
 that I never looked into.
I’ve now been trying to figure this out, because this has side effects in 
multiple places (PCMG and PCHPDDM at least), and thus could impact user-code as 
well?
With this commit: 
https://gitlab.com/petsc/petsc/-/commit/03d8bd538039defc2fcc3e37d523735c4aaceba0
+
$ mpirun -n 4 src/ksp/ksp/tutorials/ex76 -ksp_converged_reason -pc_type hpddm 
-pc_hpddm_levels_1_eps_nev 20 -ksp_type preonly -mat_type aij -load_dir 
${DATAFILESPATH}/matrices/hpddm/GENEO -rhs 2 -pc_hpddm_coarse_correction 
balanced -C_input_mattransposematmult -D_output_mattransposematmult
I’m seeing that C is nonzero, but D is full of zeros.
Mat Object: 4 MPI processes
  type: mpidense
5.7098316584361917e-08 1.0159399260517841e-07
1.5812349976211856e-07 2.0688121715350138e-07
2.4887556933361981e-08 4.8111092300772958e-08
1.4606298643602107e-07 1.7213611729839211e-07
[…]
Mat Object: 4 MPI processes
  type: mpidense
0.e+00 0.e+00
0.e+00 0.e+00
0.e+00 0.e+00
0.e+00 0.e+00
[…]

If one switches to a MatType which has no MatProduct_AtB implementation with B 
of type MPIDense (reminder: in that case, the product is computed 
column-by-column), e.g., -mat_type sbaij, one gets the expected result.
Mat Object: 4 MPI processes
  type: mpidense
7.2003197398135299e-01 9.5191869895699011e-01
6.1793966541680234e-02 9.3884397585488877e-01
1.0022337823233585e-02 2.4653068080134588e-01
1.4463931936094099e-01 8.6111517670701687e-01

Is there a bug somewhere with the MatAIJ implementation, or am I doing 
something which is not allowed by the MatProduct() machinery?

Thanks,
Pierre

(*) https://gitlab.com/petsc/petsc/-/merge_requests/3717

--
What most experimenters take for granted before they begin their experiments is 
infinitely more interesting than any results to which their experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/

Re: [petsc-dev] MatTransposeMatMult() bug

2021-03-17 Thread Matthew Knepley

On Wed, Mar 17, 2021 at 3:27 PM Zhang, Hong via petsc-dev <
petsc-dev@mcs.anl.gov> wrote:

> Pierre,
> Do you mean a possible bug in C=AtB MatTransposeMatMult()?
> Can you provide a stand-alone test without hpddm that reproduces this
> error?
>

Hong, you should be able to just configure with --download-hpddm and then
run that ex76 test.

  Thanks,

 Matt


> Hong
> --
> *From:* petsc-dev  on behalf of Pierre
> Jolivet 
> *Sent:* Wednesday, March 17, 2021 4:31 AM
> *To:* For users of the development version of PETSc  >
> *Subject:* [petsc-dev] MatTransposeMatMult() bug
>
> Hello,
> While trying out Stefano’s PCApplyMat_MG() code (*), we stumbled upon
> weird numerical errors when reusing a Mat for both MatProduct_AB and
> MatProduct_AtB.
> This reminded me that there has been a long-standing issue
> with MatTransposeMatMult(), see
> https://www.mcs.anl.gov/petsc/petsc-current/src/ksp/pc/impls/hpddm/hpddm.cxx.html#line608,
> that I never looked into.
> I’ve now been trying to figure this out, because this has side effects in
> multiple places (PCMG and PCHPDDM at least), and thus could impact
> user-code as well?
> With this commit:
> https://gitlab.com/petsc/petsc/-/commit/03d8bd538039defc2fcc3e37d523735c4aaceba0
> +
> $ mpirun -n 4 src/ksp/ksp/tutorials/ex76 -ksp_converged_reason -pc_type
> hpddm -pc_hpddm_levels_1_eps_nev 20 -ksp_type preonly -mat_type aij
> -load_dir ${DATAFILESPATH}/matrices/hpddm/GENEO -rhs 2
> -pc_hpddm_coarse_correction balanced -C_input_mattransposematmult
> -D_output_mattransposematmult
> I’m seeing that C is nonzero, but D is full of zeros.
> Mat Object: 4 MPI processes
>   type: mpidense
> 5.7098316584361917e-08 1.0159399260517841e-07
> 1.5812349976211856e-07 2.0688121715350138e-07
> 2.4887556933361981e-08 4.8111092300772958e-08
> 1.4606298643602107e-07 1.7213611729839211e-07
> […]
> Mat Object: 4 MPI processes
>   type: mpidense
> 0.e+00 0.e+00
> 0.e+00 0.e+00
> 0.e+00 0.e+00
> 0.e+00 0.e+00
> […]
>
> If one switches to a MatType which has no MatProduct_AtB implementation
> with B of type MPIDense (reminder: in that case, the product is computed
> column-by-column), e.g., -mat_type sbaij, one gets the expected result.
> Mat Object: 4 MPI processes
>   type: mpidense
> 7.2003197398135299e-01 9.5191869895699011e-01
> 6.1793966541680234e-02 9.3884397585488877e-01
> 1.0022337823233585e-02 2.4653068080134588e-01
> 1.4463931936094099e-01 8.6111517670701687e-01
>
> Is there a bug somewhere with the MatAIJ implementation, or am I doing
> something which is not allowed by the MatProduct() machinery?
>
> Thanks,
> Pierre
>
> (*) https://gitlab.com/petsc/petsc/-/merge_requests/3717
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/

Re: [petsc-dev] MatTransposeMatMult() bug

2021-03-17 Thread Pierre Jolivet

Thanks Hong, this has been fixed by Stefano there: 
https://gitlab.com/petsc/petsc/-/commit/38faa66a3f98cdf432182095b5ca9cf1fc38724a?merge_request_iid=3717
 

Pierre

> On 17 Mar 2021, at 8:27 PM, Zhang, Hong  wrote:
> 
> Pierre,
> Do you mean a possible bug in C=AtB MatTransposeMatMult()?
> Can you provide a stand-alone test without hpddm that reproduces this error? 
> Hong
> From: petsc-dev  on behalf of Pierre Jolivet 
> 
> Sent: Wednesday, March 17, 2021 4:31 AM
> To: For users of the development version of PETSc 
> Subject: [petsc-dev] MatTransposeMatMult() bug
>  
> Hello,
> While trying out Stefano’s PCApplyMat_MG() code (*), we stumbled upon weird 
> numerical errors when reusing a Mat for both MatProduct_AB and MatProduct_AtB.
> This reminded me that there has been a long-standing issue with 
> MatTransposeMatMult(), see 
> https://www.mcs.anl.gov/petsc/petsc-current/src/ksp/pc/impls/hpddm/hpddm.cxx.html#line608
>  
> ,
>  that I never looked into.
> I’ve now been trying to figure this out, because this has side effects in 
> multiple places (PCMG and PCHPDDM at least), and thus could impact user-code 
> as well?
> With this commit: 
> https://gitlab.com/petsc/petsc/-/commit/03d8bd538039defc2fcc3e37d523735c4aaceba0
>  
> 
> +
> $ mpirun -n 4 src/ksp/ksp/tutorials/ex76 -ksp_converged_reason -pc_type hpddm 
> -pc_hpddm_levels_1_eps_nev 20 -ksp_type preonly -mat_type aij -load_dir 
> ${DATAFILESPATH}/matrices/hpddm/GENEO -rhs 2 -pc_hpddm_coarse_correction 
> balanced -C_input_mattransposematmult -D_output_mattransposematmult
> I’m seeing that C is nonzero, but D is full of zeros.
> Mat Object: 4 MPI processes
>   type: mpidense
> 5.7098316584361917e-08 1.0159399260517841e-07
> 1.5812349976211856e-07 2.0688121715350138e-07
> 2.4887556933361981e-08 4.8111092300772958e-08
> 1.4606298643602107e-07 1.7213611729839211e-07
> […]
> Mat Object: 4 MPI processes
>   type: mpidense
> 0.e+00 0.e+00
> 0.e+00 0.e+00
> 0.e+00 0.e+00
> 0.e+00 0.e+00
> […]
> 
> If one switches to a MatType which has no MatProduct_AtB implementation with 
> B of type MPIDense (reminder: in that case, the product is computed 
> column-by-column), e.g., -mat_type sbaij, one gets the expected result.
> Mat Object: 4 MPI processes
>   type: mpidense
> 7.2003197398135299e-01 9.5191869895699011e-01
> 6.1793966541680234e-02 9.3884397585488877e-01
> 1.0022337823233585e-02 2.4653068080134588e-01
> 1.4463931936094099e-01 8.6111517670701687e-01
> 
> Is there a bug somewhere with the MatAIJ implementation, or am I doing 
> something which is not allowed by the MatProduct() machinery?
> 
> Thanks,
> Pierre
> 
> (*) https://gitlab.com/petsc/petsc/-/merge_requests/3717 
>

Re: [petsc-dev] MatTransposeMatMult() bug

2021-03-17 Thread Zhang, Hong via petsc-dev

Pierre,
Do you mean a possible bug in C=AtB MatTransposeMatMult()?
Can you provide a stand-alone test without hpddm that reproduces this error?
Hong

From: petsc-dev  on behalf of Pierre Jolivet 

Sent: Wednesday, March 17, 2021 4:31 AM
To: For users of the development version of PETSc 
Subject: [petsc-dev] MatTransposeMatMult() bug

Hello,
While trying out Stefano’s PCApplyMat_MG() code (*), we stumbled upon weird 
numerical errors when reusing a Mat for both MatProduct_AB and MatProduct_AtB.
This reminded me that there has been a long-standing issue with 
MatTransposeMatMult(), see 
https://www.mcs.anl.gov/petsc/petsc-current/src/ksp/pc/impls/hpddm/hpddm.cxx.html#line608,
 that I never looked into.
I’ve now been trying to figure this out, because this has side effects in 
multiple places (PCMG and PCHPDDM at least), and thus could impact user-code as 
well?
With this commit: 
https://gitlab.com/petsc/petsc/-/commit/03d8bd538039defc2fcc3e37d523735c4aaceba0
+
$ mpirun -n 4 src/ksp/ksp/tutorials/ex76 -ksp_converged_reason -pc_type hpddm 
-pc_hpddm_levels_1_eps_nev 20 -ksp_type preonly -mat_type aij -load_dir 
${DATAFILESPATH}/matrices/hpddm/GENEO -rhs 2 -pc_hpddm_coarse_correction 
balanced -C_input_mattransposematmult -D_output_mattransposematmult
I’m seeing that C is nonzero, but D is full of zeros.
Mat Object: 4 MPI processes
  type: mpidense
5.7098316584361917e-08 1.0159399260517841e-07
1.5812349976211856e-07 2.0688121715350138e-07
2.4887556933361981e-08 4.8111092300772958e-08
1.4606298643602107e-07 1.7213611729839211e-07
[…]
Mat Object: 4 MPI processes
  type: mpidense
0.e+00 0.e+00
0.e+00 0.e+00
0.e+00 0.e+00
0.e+00 0.e+00
[…]

If one switches to a MatType which has no MatProduct_AtB implementation with B 
of type MPIDense (reminder: in that case, the product is computed 
column-by-column), e.g., -mat_type sbaij, one gets the expected result.
Mat Object: 4 MPI processes
  type: mpidense
7.2003197398135299e-01 9.5191869895699011e-01
6.1793966541680234e-02 9.3884397585488877e-01
1.0022337823233585e-02 2.4653068080134588e-01
1.4463931936094099e-01 8.6111517670701687e-01

Is there a bug somewhere with the MatAIJ implementation, or am I doing 
something which is not allowed by the MatProduct() machinery?

Thanks,
Pierre

(*) https://gitlab.com/petsc/petsc/-/merge_requests/3717

Re: [petsc-dev] Petsc "make test" have more failures for --with-openmp=1

2021-03-17 Thread Eric Chamberland

Thanks Barry,

Just to report:

I tried to switch to the proposed smoother by default in our code:

-pc_hypre_boomeramg_relax_type_all l1scaled-SOR/Jacobi

However, I have some failures, even if I compiled without --with-openmp=1.

[0]PETSC ERROR: - Error Message 
--

[0]PETSC ERROR: Error in external library
[0]PETSC ERROR: Error in jac->setup(): error code 12
[0]PETSC ERROR: See https://www.mcs.anl.gov/petsc/documentation/faq.html 
for trouble shooting.

[0]PETSC ERROR: Petsc Release Version 3.14.5, Mar 03, 2021
[0]PETSC ERROR: 
/home/mefpp_ericc/GIREF/bin/Test.EstimationGradientHessien.dev on a  
named rohan by ericc Wed Mar 17 11:05:23 2021
[0]PETSC ERROR: Configure options 
--prefix=/opt/petsc-3.14.5_debug_openmpi-4.1.0 --with-mpi-compilers=1 
--with-mpi-dir=/opt/openmpi-4.1.0 --with-cxx-dialect=C++14 
--with-make-np=12 --with-shared-libraries=1 --with-debugging=yes 
--with-memalign=64 --with-visibility=0 --with-64-bit-indices=0 
--download-ml=yes --download-mumps=yes --download-superlu=yes 
--download-hpddm=yes --download-slepc=yes --download-superlu_dist=yes 
--download-parmetis=yes --download-ptscotch=yes --download-metis=yes 
--download-strumpack=yes --download-suitesparse=yes --download-hypre=yes 
--with-blaslapack-dir=/opt/intel/oneapi/mkl/2021.1.1/env/../lib/intel64 
--with-mkl_pardiso-dir=/opt/intel/oneapi/mkl/2021.1.1/env/.. 
--with-mkl_cpardiso-dir=/opt/intel/oneapi/mkl/2021.1.1/env/.. 
--with-scalapack=1 
--with-scalapack-include=/opt/intel/oneapi/mkl/2021.1.1/env/../include 
--with-scalapack-lib="-L/opt/intel/oneapi/mkl/2021.1.1/env/../lib/intel64 
-lmkl_scalapack_lp64 -lmkl_blacs_openmpi_lp64"
[0]PETSC ERROR: #1 PCSetUp_HYPRE() line 408 in 
/tmp/petsc-3.14.5-debug/src/ksp/pc/impls/hypre/hypre.c
[0]PETSC ERROR: #2 PCSetUp() line 1009 in 
/tmp/petsc-3.14.5-debug/src/ksp/pc/interface/precon.c
[0]PETSC ERROR: #3 KSPSetUp() line 406 in 
/tmp/petsc-3.14.5-debug/src/ksp/ksp/interface/itfunc.c

But it seems to happen only on some cases, actually hermitian elements 
which have a lots of DOF per vertices... It seems to work well 
otherwise, with some results differences I still have to analyse...

Do you think this might be a PETSc bug?

Does the error code is from PETSc or Hypre?

(if from hypre, I suggest to say "Hypre error code: 12" instead...)

Thanks,

Eric

On 2021-03-15 2:50 p.m., Barry Smith wrote:

   I posted some information at the issue.

   IMHO it is likely a bug in one or more of hypre's smoothers that 
use OpenMP. We have never tested them before (and likely hypre has not 
tested all the combinations) and so would not have seen the bug. 
Hopefully they can just fix it.

   Barry

    I got the problem to occur with ex56 with 2 MPI ranks and 4 OpenMP 
threads, if I used less than 4 threads it did not generate an 
indefinite preconditioner.

On Mar 14, 2021, at 1:18 PM, Eric Chamberland 
> wrote:

Done:

https://github.com/hypre-space/hypre/issues/303

Maybe I will need some help about PETSc to answer their questions...

Eric

On 2021-03-14 3:44 a.m., Stefano Zampini wrote:

Eric

You should report these HYPRE issues upstream 
https://github.com/hypre-space/hypre/issues 

On Mar 14, 2021, at 3:44 AM, Eric Chamberland 
> wrote:

For us it clearly creates problems in real computations...

I understand the need to have clean test for PETSc, but for me, it 
reveals that hypre isn't usable with more than one thread for now...

Another solution:  force single-threaded configuration for hypre 
until this is fixed?

Eric

On 2021-03-13 8:50 a.m., Pierre Jolivet wrote:

-pc_hypre_boomeramg_relax_type_all Jacobi =>
  Linear solve did not converge due to DIVERGED_INDEFINITE_PC 
iterations 3

-pc_hypre_boomeramg_relax_type_all l1scaled-Jacobi =>
OK, independently of the architecture it seems (Eric Docker image 
with 1 or 2 threads or my macOS), but contraction factor is higher

  Linear solve converged due to CONVERGED_RTOL iterations 8
  Linear solve converged due to CONVERGED_RTOL iterations 24
  Linear solve converged due to CONVERGED_RTOL iterations 26
v. currently
  Linear solve converged due to CONVERGED_RTOL iterations 7
  Linear solve converged due to CONVERGED_RTOL iterations 9
  Linear solve converged due to CONVERGED_RTOL iterations 10

Do we change this? Or should we force OMP_NUM_THREADS=1 for make test?

Thanks,
Pierre

On 13 Mar 2021, at 2:26 PM, Mark Adams > wrote:

Hypre uses a multiplicative smoother by default. It has a 
chebyshev smoother. That with a Jacobi PC should be thread 
invariant.

Mark

On Sat, Mar 13, 2021 at 8:18 AM Pierre Jolivet > wrote:

On 13 Mar 2021, at 9:17 AM, Pierre Jolivet mailto:pie...@joliv.et>> wrote:

Hello Eric,
I’ve made an “interesting” discovery, so I’ll put back th

Re: [petsc-dev] Case TS005062693 - XLF: ICE in xlfentry compiling a module with 358 subroutines

2021-03-17 Thread Satish Balay via petsc-dev

On Wed, 17 Mar 2021, Blaise A Bourdin wrote:

> 
> 
> On Mar 16, 2021, at 11:17 PM, Barry Smith 
> mailto:bsm...@petsc.dev>> wrote:
> 
> 
>   So it actually does not load everything at the call to use but waits until 
> the subroutine definitions and then only loads what you ask to import?
> 
>   Sorry, this is odd, with C include or python import it immediately loads up 
> everything as soon as it sees the include or import, there is no way later to 
> say "wo hoarsy I didn't really mean you should get everything I asked, for 
> please only load up a subset".
> 
> 
> But then Fortran was always weird, when I saw presentations of the Fortran 
> standards committee members I always felt like they read every third page of 
> some computer science book but never realized they missed many of the pages.
> 
> Which proves that they know their target audience ;)
> 
> >From the standpoint of somebody who also read every third page of a computer 
> >science book, fortran modules sounded like a good idea on the paper (I 
> >basically think of them as auto-generated header files), but they are 
> >miserable in practice, and in particular a major block to cross compiler 
> >compatibility since the format of .mod file was left to the discretion of 
> >the compiler writers.
> 

Not just (a)cross compiler - different versions of gfortran are incompatible 
with each other's .mod format..

Satish

> Blaise
> 
> --
> A.K. & Shirley Barton Professor of  Mathematics
> Adjunct Professor of Mechanical Engineering
> Adjunct of the Center for Computation & Technology
> Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
> Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
> http://www.math.lsu.edu/~bourdin
> 
>

Re: [petsc-dev] Case TS005062693 - XLF: ICE in xlfentry compiling a module with 358 subroutines

2021-03-17 Thread Blaise A Bourdin

On Mar 16, 2021, at 11:17 PM, Barry Smith 
mailto:bsm...@petsc.dev>> wrote:

  So it actually does not load everything at the call to use but waits until 
the subroutine definitions and then only loads what you ask to import?

  Sorry, this is odd, with C include or python import it immediately loads up 
everything as soon as it sees the include or import, there is no way later to 
say "wo hoarsy I didn't really mean you should get everything I asked, for 
please only load up a subset".

But then Fortran was always weird, when I saw presentations of the Fortran 
standards committee members I always felt like they read every third page of 
some computer science book but never realized they missed many of the pages.

Which proves that they know their target audience ;)

>From the standpoint of somebody who also read every third page of a computer 
>science book, fortran modules sounded like a good idea on the paper (I 
>basically think of them as auto-generated header files), but they are 
>miserable in practice, and in particular a major block to cross compiler 
>compatibility since the format of .mod file was left to the discretion of the 
>compiler writers.

Blaise

--
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

[petsc-dev] MatTransposeMatMult() bug

2021-03-17 Thread Pierre Jolivet

Hello,
While trying out Stefano’s PCApplyMat_MG() code (*), we stumbled upon weird 
numerical errors when reusing a Mat for both MatProduct_AB and MatProduct_AtB.
This reminded me that there has been a long-standing issue with 
MatTransposeMatMult(), see 
https://www.mcs.anl.gov/petsc/petsc-current/src/ksp/pc/impls/hpddm/hpddm.cxx.html#line608
 
,
 that I never looked into.
I’ve now been trying to figure this out, because this has side effects in 
multiple places (PCMG and PCHPDDM at least), and thus could impact user-code as 
well?
With this commit: 
https://gitlab.com/petsc/petsc/-/commit/03d8bd538039defc2fcc3e37d523735c4aaceba0
 

+
$ mpirun -n 4 src/ksp/ksp/tutorials/ex76 -ksp_converged_reason -pc_type hpddm 
-pc_hpddm_levels_1_eps_nev 20 -ksp_type preonly -mat_type aij -load_dir 
${DATAFILESPATH}/matrices/hpddm/GENEO -rhs 2 -pc_hpddm_coarse_correction 
balanced -C_input_mattransposematmult -D_output_mattransposematmult
I’m seeing that C is nonzero, but D is full of zeros.
Mat Object: 4 MPI processes
  type: mpidense
5.7098316584361917e-08 1.0159399260517841e-07
1.5812349976211856e-07 2.0688121715350138e-07
2.4887556933361981e-08 4.8111092300772958e-08
1.4606298643602107e-07 1.7213611729839211e-07
[…]
Mat Object: 4 MPI processes
  type: mpidense
0.e+00 0.e+00
0.e+00 0.e+00
0.e+00 0.e+00
0.e+00 0.e+00
[…]

If one switches to a MatType which has no MatProduct_AtB implementation with B 
of type MPIDense (reminder: in that case, the product is computed 
column-by-column), e.g., -mat_type sbaij, one gets the expected result.
Mat Object: 4 MPI processes
  type: mpidense
7.2003197398135299e-01 9.5191869895699011e-01
6.1793966541680234e-02 9.3884397585488877e-01
1.0022337823233585e-02 2.4653068080134588e-01
1.4463931936094099e-01 8.6111517670701687e-01

Is there a bug somewhere with the MatAIJ implementation, or am I doing 
something which is not allowed by the MatProduct() machinery?

Thanks,
Pierre

(*) https://gitlab.com/petsc/petsc/-/merge_requests/3717

Re: [petsc-dev] MatTransposeMatMult() bug

Re: [petsc-dev] MatTransposeMatMult() bug

Re: [petsc-dev] MatTransposeMatMult() bug

Re: [petsc-dev] MatTransposeMatMult() bug

Re: [petsc-dev] MatTransposeMatMult() bug

Re: [petsc-dev] Petsc "make test" have more failures for --with-openmp=1

Re: [petsc-dev] Case TS005062693 - XLF: ICE in xlfentry compiling a module with 358 subroutines

Re: [petsc-dev] Case TS005062693 - XLF: ICE in xlfentry compiling a module with 358 subroutines

[petsc-dev] MatTransposeMatMult() bug

9 matches

Site Navigation

Mail list logo

Footer information