[petsc-dev] OS X message "Do you want ex3 to ..." are killing me
PETSc codes running on my Mac open a sticky top window asking for permission for the executable to do something. These windows, one for each process, grab the mouse focus and stay above normal windows. This is generally annoying but when I run 'make allltest' it creates many windows per second, all grabbing the mouse, resulting in an effective DoS attack on my keyboard. And Cntr-C does not seem to work so it is really effective. Any ideas how to fix this? Mark
[petsc-dev] OS X message "Do you want ex3 to ..." are killing me
Weird, OS X version and command line? On Tue, May 15, 2012 at 10:29 PM, Mark F. Adams wrote: > PETSc codes running on my Mac open a sticky top window asking for > permission for the executable to do something. These windows, one for each > process, grab the mouse focus and stay above normal windows. This is > generally annoying but when I run 'make allltest' it creates many windows > per second, all grabbing the mouse, resulting in an effective DoS attack on > my keyboard. And Cntr-C does not seem to work so it is really effective. > > Any ideas how to fix this? > > Mark -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120515/30366750/attachment.html>
[petsc-dev] OS X message "Do you want ex3 to ..." are killing me
On May 15, 2012, at 3:31 PM, Aron Ahmadia wrote: > Weird, OS X version and command line? Simple one year old Mac, OSX 10.6.8. I can run the raw executable w/o this message, apparently. So it must be something in the $MPIEXEC... > > On Tue, May 15, 2012 at 10:29 PM, Mark F. Adams > wrote: > PETSc codes running on my Mac open a sticky top window asking for permission > for the executable to do something. These windows, one for each process, > grab the mouse focus and stay above normal windows. This is generally > annoying but when I run 'make allltest' it creates many windows per second, > all grabbing the mouse, resulting in an effective DoS attack on my keyboard. > And Cntr-C does not seem to work so it is really effective. > > Any ideas how to fix this? > > Mark > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120515/057083e9/attachment.html>
[petsc-dev] OS X message "Do you want ex3 to ..." are killing me
System preferences security firewall stop Barry On May 15, 2012, at 2:31 PM, Aron Ahmadia wrote: > Weird, OS X version and command line? > > On Tue, May 15, 2012 at 10:29 PM, Mark F. Adams > wrote: > PETSc codes running on my Mac open a sticky top window asking for permission > for the executable to do something. These windows, one for each process, > grab the mouse focus and stay above normal windows. This is generally > annoying but when I run 'make allltest' it creates many windows per second, > all grabbing the mouse, resulting in an effective DoS attack on my keyboard. > And Cntr-C does not seem to work so it is really effective. > > Any ideas how to fix this? > > Mark >
[petsc-dev] ex43_3 stokes problem FAIL
I do not seem to be able to reproduce these errors. This is what I see:
~/Codes/petsc-dev/src/ksp/ksp/examples/tutorials>make runex49
30c30
< 28 KSP Residual norm 0.000350713
---
> 28 KSP Residual norm 0.000350714
41c41
< 39 KSP Residual norm 9.38531e-05
---
> 39 KSP Residual norm 9.38532e-05
43c43
< 41 KSP Residual norm 5.55156e-05
---
> 41 KSP Residual norm 5.55157e-05
/Users/markadams/Codes/petsc-dev/src/ksp/ksp/examples/tutorials
Possible problem with with ex49_1, diffs above
=
~/Codes/petsc-dev/src/ksp/ksp/examples/tutorials>make runex49_3
~/Codes/petsc-dev/src/ksp/ksp/examples/tutorials>make runex49_2
~/Codes/petsc-dev/src/ksp/ksp/examples/tutorials>
Mark
On May 11, 2012, at 10:34 PM, Barry Smith wrote:
>
> Same problem with ex49, what the fuck are you guys thinking?
>
>
> [2]PETSC ERROR: - Error Message
>
>> [2]PETSC ERROR: Arguments are incompatible!
>> [2]PETSC ERROR: Local size 315 not compatible with block size 2!
>> [2]PETSC ERROR:
>>
>> [2]PETSC ERROR: Petsc Development HG revision:
>> 5df5da2fbee0018d6214063ab12ea49c0847b4f8 HG Date: Fri May 11 13:26:59 2012
>> -0500
>> [2]PETSC ERROR: See docs/changes/index.html for recent updates.
>> [2]PETSC ERROR: See docs/faq.html for hints about trouble shooting.
>> [2]PETSC ERROR: See docs/index.html for manual pages.
>> [2]PETSC ERROR:
>>
>> [2]PETSC ERROR: ./ex49 on a arch-gnu named barry-smiths-macbook-pro.local by
>> barrysmith Fri May 11 18:47:27 2012
>> [2]PETSC ERROR: Libraries linked from
>> /Users/barrysmith/Src/petsc-dev/arch-gnu/lib
>> [2]PETSC ERROR: Configure run at Fri May 11 18:30:02 2012
>> [2]PETSC ERROR: Configure options --download-blacs --download-fftw
>> --download-hypre --download-libyaml --download-metis --download-ml
>> --download-mpich --download-mumps --download-parmetis --download-ptscotch
>> --download-scalapack --download-superlu --download-superlu_dist
>> --download-yaml --with-ams-dir=/Users/barrysmith/Src/ams-dev --with-java
>> --with-openmp --with-server --with-shared-libraries PETSC_ARCH=arch-gnu
>> [2]PETSC ERROR:
>>
>> [2]PETSC ERROR: PetscLayoutSetBlockSize() line 459 in
>> /Users/barrysmith/Src/petsc-dev/src/vec/vec/impls/mpi/pmap.c
>> [2]PETSC ERROR: MatSetBlockSizes() line 6843 in
>> /Users/barrysmith/Src/petsc-dev/src/mat/interface/matrix.c
>> [2]PETSC ERROR: MatGetSubMatrices_MPIAIJ_Local() line 1312 in
>> /Users/barrysmith/Src/petsc-dev/src/mat/impls/aij/mpi/mpiov.c
>> [2]PETSC ERROR: MatGetSubMatrices_MPIAIJ() line 786 in
>> /Users/barrysmith/Src/petsc-dev/src/mat/impls/aij/mpi/mpiov.c
>> [2]PETSC ERROR: MatGetSubMatrices() line 6498 in
>> /Users/barrysmith/Src/petsc-dev/src/mat/interface/matrix.c
>> [2]PETSC ERROR: MatGetSubMatrix_MPIAIJ_Private() line 3554 in
>> /Users/barrysmith/Src/petsc-dev/src/mat/impls/aij/mpi/mpiaij.c
>> [2]PETSC ERROR: MatGetSubMatrix_MPIAIJ() line 3515 in
>> /Users/barrysmith/Src/petsc-dev/src/mat/impls/aij/mpi/mpiaij.c
>> [2]PETSC ERROR: MatGetSubMatrix() line 7344 in
>> /Users/barrysmith/Src/petsc-dev/src/mat/interface/matrix.c
>> [2]PETSC ERROR: DMDABCApplySymmetricCompression() line 1348 in
>> src/ksp/ksp/examples/tutorials/ex49.c
>> [2]PETSC ERROR: solve_elasticity_2d() line 1080 in
>> src/ksp/ksp/examples/tutorials/ex49.c
>> [2]PETSC ERROR: main() line 1138 in src/ksp/ksp/examples/tutorials/ex49.c
>> application called MPI_Abort(MPI_COMM_WORLD, 75) - process 2
>> [cli_2]: aborting job:
>
> On May 11, 2012, at 9:31 PM, Barry Smith wrote:
>
>>
>> Please run make alltests before pushing changes!
>>
>> Who ever pushed this broken code please fix.
>> runex43_3:
>> -@${MPIEXEC} -n 4 ./ex43 -stokes_ksp_type gcr -stokes_ksp_gcr_restart
>> 60 -stokes_ksp_norm_type unpreconditioned -stokes_ksp_rtol 1e-8 -c_str 3
>> -sinker_eta0 1.0 -sinker_eta1 100 -sinker_dx 0.4 -sinker_dy 0.3 -mx 128 -my
>> 128 -stokes_ksp_monitor_short -stokes_pc_type mg -stokes_mg_levels_pc_type
>> fieldsplit -stokes_pc_mg_galerkin -stokes_mg_levels_pc_fieldsplit_block_size
>> 3 -stokes_mg_levels_pc_fieldsplit_0_fields 0,1
>> -stokes_mg_levels_pc_fieldsplit_1_fields 2
>> -stokes_mg_levels_fieldsplit_0_pc_type sor
>> -stokes_mg_levels_fieldsplit_1_pc_type sor -stokes_mg_levels_ksp_type
>> chebyshev -stokes_mg_levels_ksp_max_it 1
>> -stokes_mg_levels_ksp_chebyshev_estimate_eigenvalues 0,0.2,0,1.1
>> -stokes_pc_mg_levels 4 -stokes_ksp_view > ex43_3.tmp 2>&1;\
>> ${DIFF} output/ex43_3.out ex43_3.tmp || echo ${PWD} "\nPossible
>> problem with with ex43_3, diffs above
>> \n="; \
>> ${RM} -f ex43_3.tmp
>>
>> [2]PETSC ERROR: - Error Message
>> ---
[petsc-dev] ex43_3 stokes problem FAIL
Mark,
I commented out the MatSetBlockSize() calls in the MatGetSubMatrices() this
is why it no longer crashes. But, of course, you will never get the blocksize
you want out of it. You need to set the block size conditionally based on the
"right" IS being passed in.
Barry
On May 15, 2012, at 2:48 PM, Mark F. Adams wrote:
> I do not seem to be able to reproduce these errors. This is what I see:
>
> ~/Codes/petsc-dev/src/ksp/ksp/examples/tutorials>make runex49
> 30c30
> < 28 KSP Residual norm 0.000350713
> ---
>> 28 KSP Residual norm 0.000350714
> 41c41
> < 39 KSP Residual norm 9.38531e-05
> ---
>> 39 KSP Residual norm 9.38532e-05
> 43c43
> < 41 KSP Residual norm 5.55156e-05
> ---
>> 41 KSP Residual norm 5.55157e-05
> /Users/markadams/Codes/petsc-dev/src/ksp/ksp/examples/tutorials
> Possible problem with with ex49_1, diffs above
> =
> ~/Codes/petsc-dev/src/ksp/ksp/examples/tutorials>make runex49_3
> ~/Codes/petsc-dev/src/ksp/ksp/examples/tutorials>make runex49_2
> ~/Codes/petsc-dev/src/ksp/ksp/examples/tutorials>
>
>
> Mark
>
> On May 11, 2012, at 10:34 PM, Barry Smith wrote:
>
>>
>> Same problem with ex49, what the fuck are you guys thinking?
>>
>>
>> [2]PETSC ERROR: - Error Message
>>
>>> [2]PETSC ERROR: Arguments are incompatible!
>>> [2]PETSC ERROR: Local size 315 not compatible with block size 2!
>>> [2]PETSC ERROR:
>>>
>>> [2]PETSC ERROR: Petsc Development HG revision:
>>> 5df5da2fbee0018d6214063ab12ea49c0847b4f8 HG Date: Fri May 11 13:26:59 2012
>>> -0500
>>> [2]PETSC ERROR: See docs/changes/index.html for recent updates.
>>> [2]PETSC ERROR: See docs/faq.html for hints about trouble shooting.
>>> [2]PETSC ERROR: See docs/index.html for manual pages.
>>> [2]PETSC ERROR:
>>>
>>> [2]PETSC ERROR: ./ex49 on a arch-gnu named barry-smiths-macbook-pro.local
>>> by barrysmith Fri May 11 18:47:27 2012
>>> [2]PETSC ERROR: Libraries linked from
>>> /Users/barrysmith/Src/petsc-dev/arch-gnu/lib
>>> [2]PETSC ERROR: Configure run at Fri May 11 18:30:02 2012
>>> [2]PETSC ERROR: Configure options --download-blacs --download-fftw
>>> --download-hypre --download-libyaml --download-metis --download-ml
>>> --download-mpich --download-mumps --download-parmetis --download-ptscotch
>>> --download-scalapack --download-superlu --download-superlu_dist
>>> --download-yaml --with-ams-dir=/Users/barrysmith/Src/ams-dev --with-java
>>> --with-openmp --with-server --with-shared-libraries PETSC_ARCH=arch-gnu
>>> [2]PETSC ERROR:
>>>
>>> [2]PETSC ERROR: PetscLayoutSetBlockSize() line 459 in
>>> /Users/barrysmith/Src/petsc-dev/src/vec/vec/impls/mpi/pmap.c
>>> [2]PETSC ERROR: MatSetBlockSizes() line 6843 in
>>> /Users/barrysmith/Src/petsc-dev/src/mat/interface/matrix.c
>>> [2]PETSC ERROR: MatGetSubMatrices_MPIAIJ_Local() line 1312 in
>>> /Users/barrysmith/Src/petsc-dev/src/mat/impls/aij/mpi/mpiov.c
>>> [2]PETSC ERROR: MatGetSubMatrices_MPIAIJ() line 786 in
>>> /Users/barrysmith/Src/petsc-dev/src/mat/impls/aij/mpi/mpiov.c
>>> [2]PETSC ERROR: MatGetSubMatrices() line 6498 in
>>> /Users/barrysmith/Src/petsc-dev/src/mat/interface/matrix.c
>>> [2]PETSC ERROR: MatGetSubMatrix_MPIAIJ_Private() line 3554 in
>>> /Users/barrysmith/Src/petsc-dev/src/mat/impls/aij/mpi/mpiaij.c
>>> [2]PETSC ERROR: MatGetSubMatrix_MPIAIJ() line 3515 in
>>> /Users/barrysmith/Src/petsc-dev/src/mat/impls/aij/mpi/mpiaij.c
>>> [2]PETSC ERROR: MatGetSubMatrix() line 7344 in
>>> /Users/barrysmith/Src/petsc-dev/src/mat/interface/matrix.c
>>> [2]PETSC ERROR: DMDABCApplySymmetricCompression() line 1348 in
>>> src/ksp/ksp/examples/tutorials/ex49.c
>>> [2]PETSC ERROR: solve_elasticity_2d() line 1080 in
>>> src/ksp/ksp/examples/tutorials/ex49.c
>>> [2]PETSC ERROR: main() line 1138 in src/ksp/ksp/examples/tutorials/ex49.c
>>> application called MPI_Abort(MPI_COMM_WORLD, 75) - process 2
>>> [cli_2]: aborting job:
>>
>> On May 11, 2012, at 9:31 PM, Barry Smith wrote:
>>
>>>
>>> Please run make alltests before pushing changes!
>>>
>>> Who ever pushed this broken code please fix.
>>> runex43_3:
>>> -@${MPIEXEC} -n 4 ./ex43 -stokes_ksp_type gcr -stokes_ksp_gcr_restart
>>> 60 -stokes_ksp_norm_type unpreconditioned -stokes_ksp_rtol 1e-8 -c_str 3
>>> -sinker_eta0 1.0 -sinker_eta1 100 -sinker_dx 0.4 -sinker_dy 0.3 -mx 128 -my
>>> 128 -stokes_ksp_monitor_short -stokes_pc_type mg -stokes_mg_levels_pc_type
>>> fieldsplit -stokes_pc_mg_galerkin
>>> -stokes_mg_levels_pc_fieldsplit_block_size 3
>>> -stokes_mg_levels_pc_fieldsplit_0_fields 0,1
>>> -stokes_mg_levels_pc_fieldsplit_1_fields 2
>>> -stokes_mg_levels_fieldsplit_0_pc_type sor
>>> -stokes_mg_levels_fieldsplit_1_pc_type sor -stokes_mg_levels_ksp_type
>
[petsc-dev] SNESDMComputeJacobian()
*- ptr - pointer to a structure that must have a DM as its first entry.* *This ptr must have been passed into SNESDMComputeFunction() as the context.* This is considered very bad form now since resolution-dependent information in the function context tends to make it not work with grid sequencing or FAS. Are we ready to remove it yet? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120515/5e450a95/attachment.html>
[petsc-dev] SNESDMComputeJacobian()
On Tue, May 15, 2012 at 10:11 PM, Jed Brown wrote: > *- ptr - pointer to a structure that must have a DM as its first entry.* > *This ptr must have been passed into SNESDMComputeFunction() as > the context.* > > This is considered very bad form now since resolution-dependent > information in the function context tends to make it not work with grid > sequencing or FAS. Are we ready to remove it yet? > How does the DM info get there? I thought we were still using this. Matt -- 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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120515/9a1916ba/attachment.html>
[petsc-dev] SNESDMComputeJacobian()
On Tue, May 15, 2012 at 8:24 PM, Matthew Knepley wrote: > How does the DM info get there? I thought we were still using this. Well, it was the reason for the failing -snes_mf_operator business. I finally pushed a fix for that. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/d9d273010a81 There is still some dispatch through DM, but it's handled by DMSNESSetUpLegacy() and doesn't rely on the function context having a DM as its first member. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120515/92dbf125/attachment.html>
[petsc-dev] SNESDMComputeJacobian()
On Tue, May 15, 2012 at 9:24 PM, Matthew Knepley wrote: > On Tue, May 15, 2012 at 10:11 PM, Jed Brown wrote: > >> *- ptr - pointer to a structure that must have a DM as its first entry.* >> *This ptr must have been passed into SNESDMComputeFunction() as >> the context.* >> >> This is considered very bad form now since resolution-dependent >> information in the function context tends to make it not work with grid >> sequencing or FAS. Are we ready to remove it yet? >> > > How does the DM info get there? I thought we were still using this. > > SNESGetDM anyone? Having that as part of the context, and not even a named part of the context, is terrible. - Peter >Matt > > -- > 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 > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120515/630d1239/attachment.html>
[petsc-dev] SNESDMComputeJacobian()
On Tue, May 15, 2012 at 10:30 PM, Peter Brune wrote: > > > On Tue, May 15, 2012 at 9:24 PM, Matthew Knepley wrote: > >> On Tue, May 15, 2012 at 10:11 PM, Jed Brown wrote: >> >>> *- ptr - pointer to a structure that must have a DM as its first entry.* >>> *This ptr must have been passed into SNESDMComputeFunction() as >>> the context.* >>> >>> This is considered very bad form now since resolution-dependent >>> information in the function context tends to make it not work with grid >>> sequencing or FAS. Are we ready to remove it yet? >>> >> >> How does the DM info get there? I thought we were still using this. >> >> > SNESGetDM anyone? Having that as part of the context, and not even a > named part of the context, is terrible. > I guess I am fine with this. Its definitely no worse than the context arg. Matt > - Peter > > >>Matt >> >> -- >> 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 >> > > -- 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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120515/30d643a6/attachment.html>
[petsc-dev] SNESDMComputeJacobian()
On May 15, 2012, at 9:11 PM, Jed Brown wrote: > - ptr - pointer to a structure that must have a DM as its first entry. > This ptr must have been passed into SNESDMComputeFunction() as the > context. > > This is considered very bad form now since resolution-dependent information > in the function context tends to make it not work with grid sequencing or > FAS. Are we ready to remove it yet? Jed, I assumed that your updates to SNES/DM had/would eliminate this whole business. So, yes, nothing should depend on the DM being in the user context anymore. Barry
