Re: [petsc-dev] upcoming release and testing
Hi Satish, I'll try to send follow up emails on master brakages. Karl, http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/03/31/examples_master_arch-c-exodus-dbg-builder_es.log not ok ksp_ksp_tests-ex43_1 # terminate called after throwing an instance of 'thrust::system::system_error' # what(): cudaFree in free: an illegal memory access was encountered Is this related to cuda change? [I haven't explored yet] this looks like a one-off test failure. The previous day that test ran through. Also, I only removed CUSP stuff, but did not alter the existing CUDA backend. Best regards, Karli
Re: [petsc-dev] upcoming release and testing
I've merged the following branches [tested in next-tmp] to master. http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/01/next-tmp.html origin/jed/fix-analyzer-bugs origin/balay/update-hypre-v2.14.0 origin/denera/tao-lmvm-info-bugfix origin/knepley/feature-med-pkg origin/knepley/fix-hdf5-attribute origin/knepley/test-allow-line-continuation origin/balay/update-zoltan-v3.83 The outstanding branches in next are: origin/knepley/fix-cylinder-mesh origin/knepley/fix-dm-gmg origin/knepley/fix-ex62-tests origin/knepley/fix-fe-bd-integral origin/knepley/fix-fe-vector-spaces origin/knepley/fix-snes-ex69 origin/tisaac/feature-dmfield So any issues in 'next' that are not in 'master' are likely due to these branches. http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/01/next.html http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/03/31/master.html Matt, Toby - can you take a look at these issues? If needed - we can schedule one branch at a time in next-tmp testing. Thanks, Satish
Re: [petsc-dev] upcoming release and testing
On Sun, 1 Apr 2018, Satish Balay wrote: > On Sun, 1 Apr 2018, Satish Balay wrote: > > > I'll try to send follow up emails on master brakages. > > Barry, > > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/03/31/examples_master_arch-cuda-single_es.log > > not ok diff-ksp_ksp_tests-ex49_1_bs-7 > # 0a1 > # > Norm of residual 0.00159951 iterations 2 bs 7 > > This came up on 2018/01/24 - I think - from migrating from old to new > testsuite. How to fix? Add alt output file? > > > diff --git a/src/ksp/ksp/examples/tests/output/ex49_1_alt.out > b/src/ksp/ksp/examples/tests/output/ex49_1_alt.out > new file mode 100644 > index 000..828d9d9 > --- /dev/null > +++ b/src/ksp/ksp/examples/tests/output/ex49_1_alt.out > @@ -0,0 +1 @@ > +Norm of residual 0.00159951 iterations 2 bs 7 pushed this fix. Satish
Re: [petsc-dev] upcoming release and testing
On Sun, 1 Apr 2018, Satish Balay wrote: > I'll try to send follow up emails on master brakages. Barry, http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/03/31/examples_master_arch-cuda-single_es.log not ok diff-ksp_ksp_tests-ex49_1_bs-7 # 0a1 # > Norm of residual 0.00159951 iterations 2 bs 7 This came up on 2018/01/24 - I think - from migrating from old to new testsuite. How to fix? Add alt output file? diff --git a/src/ksp/ksp/examples/tests/output/ex49_1_alt.out b/src/ksp/ksp/examples/tests/output/ex49_1_alt.out new file mode 100644 index 000..828d9d9 --- /dev/null +++ b/src/ksp/ksp/examples/tests/output/ex49_1_alt.out @@ -0,0 +1 @@ +Norm of residual 0.00159951 iterations 2 bs 7 Thanks, Satish
Re: [petsc-dev] upcoming release and testing
Hi Satish, I am working on it. ex26 tests a bunch of DMPlex functions which I don’t think are tested anywhere else. The test itself may also have leaks. Blaise > On Apr 1, 2018, at 11:42 AM, Satish Balay wrote: > > On Sun, 1 Apr 2018, Satish Balay wrote: > >> I'll try to send follow up emails on master brakages. > > Blaise, > > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/03/31/examples_master_arch-c-exodus-dbg-builder_es.log > > dm_impls_plex_tests-ex26 has bunch of memory leaks and diffs. I could track > one of the memory leaks to f94b4a023f1c697a53e49ac853a9031583ab9737 - but > don't know what the trigger is - or how to fix it. > > not ok diff-dm_impls_plex_tests-ex26_6 > # 969a970,2569 > # > [ 0]16 bytes PetscSFBasicGetPack() line 806 in > /sandbox/petsc/petsc.master-3/src/vec/is/sf/impls/basic/sfbasic.c > # > [0] PetscMallocA() line 806 in > /sandbox/petsc/petsc.master-3/src/sys/memory/mal.c > # > [0] PetscSFBasicGetPack() line 778 in > /sandbox/petsc/petsc.master-3/src/vec/is/sf/impls/basic/sfbasic.c > # > [0] PetscSFBcastBegin_Basic() line 923 in > /sandbox/petsc/petsc.master-3/src/vec/is/sf/impls/basic/sfbasic.c > # > [0] PetscSFBcastBegin() line 1045 in > /sandbox/petsc/petsc.master-3/src/vec/is/sf/interface/sf.c > # > [0] DMPlexGlobalToNaturalBegin() line 183 in > /sandbox/petsc/petsc.master-3/src/dm/impls/plex/plexnatural.c > # > [0] VecViewPlex_ExodusII_Zonal_Internal() line 678 in > /sandbox/petsc/petsc.master-3/src/dm/impls/plex/plexexodusii.c > > And there are diffs which should be checked.. > > not ok diff-dm_impls_plex_tests-ex26_7 > # 536c536 > # < Cell Sets: 2 strata with value/size (3 (9), 5 (9)) > # --- > # > Cell Sets: 2 strata with value/size (1 (9), 2 (9)) > # 537a538,2137 > > not ok diff-dm_impls_plex_tests-ex26_10 > # 536c536 > # < Cell Sets: 2 strata with value/size (3 (9), 5 (9)) > # --- > # > Cell Sets: 2 strata with value/size (1 (9), 2 (9)) > # 537a538,2137 > > > # < 0-cells: 28 36 > # < 1-cells: 58 67 > # --- > # > 0-cells: 34 32 > # > 1-cells: 64 63 > # 734,735c734,2335 > # < Cell Sets: 3 strata with value/size (2 (1), 3 (28), 5 (3)) > # < depth: 3 strata with value/size (0 (28), 1 (58), 2 (32)) > # --- > # > Cell Sets: 3 strata with value/size (1 (9), 2 (18), 3 (5)) > # > depth: 3 strata with value/size (0 (34), 1 (64), 2 (32)) > > etc.. > > thanks, > Satish > -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin
Re: [petsc-dev] upcoming release and testing
On Sun, 1 Apr 2018, Satish Balay wrote: > I'll try to send follow up emails on master brakages. Blaise, http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/03/31/examples_master_arch-c-exodus-dbg-builder_es.log dm_impls_plex_tests-ex26 has bunch of memory leaks and diffs. I could track one of the memory leaks to f94b4a023f1c697a53e49ac853a9031583ab9737 - but don't know what the trigger is - or how to fix it. not ok diff-dm_impls_plex_tests-ex26_6 # 969a970,2569 # > [ 0]16 bytes PetscSFBasicGetPack() line 806 in /sandbox/petsc/petsc.master-3/src/vec/is/sf/impls/basic/sfbasic.c # > [0] PetscMallocA() line 806 in /sandbox/petsc/petsc.master-3/src/sys/memory/mal.c # > [0] PetscSFBasicGetPack() line 778 in /sandbox/petsc/petsc.master-3/src/vec/is/sf/impls/basic/sfbasic.c # > [0] PetscSFBcastBegin_Basic() line 923 in /sandbox/petsc/petsc.master-3/src/vec/is/sf/impls/basic/sfbasic.c # > [0] PetscSFBcastBegin() line 1045 in /sandbox/petsc/petsc.master-3/src/vec/is/sf/interface/sf.c # > [0] DMPlexGlobalToNaturalBegin() line 183 in /sandbox/petsc/petsc.master-3/src/dm/impls/plex/plexnatural.c # > [0] VecViewPlex_ExodusII_Zonal_Internal() line 678 in /sandbox/petsc/petsc.master-3/src/dm/impls/plex/plexexodusii.c And there are diffs which should be checked.. not ok diff-dm_impls_plex_tests-ex26_7 # 536c536 # < Cell Sets: 2 strata with value/size (3 (9), 5 (9)) # --- # > Cell Sets: 2 strata with value/size (1 (9), 2 (9)) # 537a538,2137 not ok diff-dm_impls_plex_tests-ex26_10 # 536c536 # < Cell Sets: 2 strata with value/size (3 (9), 5 (9)) # --- # > Cell Sets: 2 strata with value/size (1 (9), 2 (9)) # 537a538,2137 # < 0-cells: 28 36 # < 1-cells: 58 67 # --- # > 0-cells: 34 32 # > 1-cells: 64 63 # 734,735c734,2335 # < Cell Sets: 3 strata with value/size (2 (1), 3 (28), 5 (3)) # < depth: 3 strata with value/size (0 (28), 1 (58), 2 (32)) # --- # > Cell Sets: 3 strata with value/size (1 (9), 2 (18), 3 (5)) # > depth: 3 strata with value/size (0 (34), 1 (64), 2 (32)) etc.. thanks, Satish
Re: [petsc-dev] upcoming release and testing
Everyone, I think this model is way to labor intense on Satish to keep permanently but we'll keep it to get past the release and then rethink the model. Satish is also working to decrease the test time so we can hopefully open up more testing slots. My dream is each person gets a testing slot for themselves but this is not likely in the short term so we may have a small number of people share each testing slot. Barry > On Apr 1, 2018, at 11:24 AM, Satish Balay wrote: > > PETSc developers, > > I've change daily/nightly tests to have 3 tests every day [from the current 2 > tests]: > > - next > - next-tmp [can change this test slot as needed] > - master > > Please note the time/schedule of these tests > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/ > > next; run everyday 12am to 7:30am Chicago time > next-tmp; run everyday 8am to 3:30pm > master; run weekdays 4pm to 11:30pm > > [I haven't yet added back 'maint' - will do it at some point] > > Plan is to test branches in next-tmp before merge to master so: > > Please do *not* merge any feature branches from next to master without > additional testing via next-tmp. > > If you think a branch is ready for merge - let me know - and I'll schedule it > into next-tmp > > Also - please look at breakages in master [without a clean master - its > difficult to know when feature branches in next/next-tmp are clean. And when > feature branches from dirty next are merged to master - master gets more > broke] > > I'll try to send follow up emails on master brakages. > > Notes about next-tmp: > > - for now only I have push access to it [so that I can test selected feature > branches with it, and reset it as needed] > > - it will be 'latest-master + a few test branches' and updated with 'push -f' > [i.e not a continuously updated branch like next] > > Thanks, > Satish
Re: [petsc-dev] upcoming release and testing
On Sun, 1 Apr 2018, Satish Balay wrote: > I'll try to send follow up emails on master brakages. Karl, http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/03/31/examples_master_arch-c-exodus-dbg-builder_es.log not ok ksp_ksp_tests-ex43_1 # terminate called after throwing an instance of 'thrust::system::system_error' # what(): cudaFree in free: an illegal memory access was encountered Is this related to cuda change? [I haven't explored yet] Satish
[petsc-dev] upcoming release and testing
PETSc developers, I've change daily/nightly tests to have 3 tests every day [from the current 2 tests]: - next - next-tmp [can change this test slot as needed] - master Please note the time/schedule of these tests http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/ next; run everyday 12am to 7:30am Chicago time next-tmp; run everyday 8am to 3:30pm master; run weekdays 4pm to 11:30pm [I haven't yet added back 'maint' - will do it at some point] Plan is to test branches in next-tmp before merge to master so: Please do *not* merge any feature branches from next to master without additional testing via next-tmp. If you think a branch is ready for merge - let me know - and I'll schedule it into next-tmp Also - please look at breakages in master [without a clean master - its difficult to know when feature branches in next/next-tmp are clean. And when feature branches from dirty next are merged to master - master gets more broke] I'll try to send follow up emails on master brakages. Notes about next-tmp: - for now only I have push access to it [so that I can test selected feature branches with it, and reset it as needed] - it will be 'latest-master + a few test branches' and updated with 'push -f' [i.e not a continuously updated branch like next] Thanks, Satish
Re: [petsc-dev] No MatGetOperation() ?
Changed my mind a little about Mat{Set|Get}Operation() and fixed some
mess in MATSHELL:
https://bitbucket.org/petsc/petsc/pull-requests/915/add-matgetoperation-and-fixes-to-matshell/diff
On 1 April 2018 at 12:30, Lisandro Dalcin wrote:
> Moreover, after a second look, I think MatSetOperation() is wrong. It
> should special-case MATSHELL and dispatch to MatShellSetOperation()
> if the type match, otherwise bad things would happen.
>
> On 1 April 2018 at 12:08, Lisandro Dalcin wrote:
>> Barry, you made the distinction MatSetOperation() vs. MatShellSetOperation().
>>
>> 1) MatSetOperation() is misplaced, it should go somewhere in
>> src/mat/interface/matrix.c
>>
>> 2) We should add MatGetOperation(), right? Should it just return the
>> routine set in mat-ops? Are you ok with this?
>>
>>
>>
>> --
>> Lisandro Dalcin
>>
>> Research Scientist
>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
>> Extreme Computing Research Center (ECRC)
>> King Abdullah University of Science and Technology (KAUST)
>> http://ecrc.kaust.edu.sa/
>>
>> 4700 King Abdullah University of Science and Technology
>> al-Khawarizmi Bldg (Bldg 1), Office # 0109
>> Thuwal 23955-6900, Kingdom of Saudi Arabia
>> http://www.kaust.edu.sa
>>
>> Office Phone: +966 12 808-0459
>
>
>
> --
> Lisandro Dalcin
>
> Research Scientist
> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
> Extreme Computing Research Center (ECRC)
> King Abdullah University of Science and Technology (KAUST)
> http://ecrc.kaust.edu.sa/
>
> 4700 King Abdullah University of Science and Technology
> al-Khawarizmi Bldg (Bldg 1), Office # 0109
> Thuwal 23955-6900, Kingdom of Saudi Arabia
> http://www.kaust.edu.sa
>
> Office Phone: +966 12 808-0459
--
Lisandro Dalcin
Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/
4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa
Office Phone: +966 12 808-0459
Re: [petsc-dev] No MatGetOperation() ?
Moreover, after a second look, I think MatSetOperation() is wrong. It should special-case MATSHELL and dispatch to MatShellSetOperation() if the type match, otherwise bad things would happen. On 1 April 2018 at 12:08, Lisandro Dalcin wrote: > Barry, you made the distinction MatSetOperation() vs. MatShellSetOperation(). > > 1) MatSetOperation() is misplaced, it should go somewhere in > src/mat/interface/matrix.c > > 2) We should add MatGetOperation(), right? Should it just return the > routine set in mat-ops? Are you ok with this? > > > > -- > Lisandro Dalcin > > Research Scientist > Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) > Extreme Computing Research Center (ECRC) > King Abdullah University of Science and Technology (KAUST) > http://ecrc.kaust.edu.sa/ > > 4700 King Abdullah University of Science and Technology > al-Khawarizmi Bldg (Bldg 1), Office # 0109 > Thuwal 23955-6900, Kingdom of Saudi Arabia > http://www.kaust.edu.sa > > Office Phone: +966 12 808-0459 -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459
[petsc-dev] No MatGetOperation() ?
Barry, you made the distinction MatSetOperation() vs. MatShellSetOperation(). 1) MatSetOperation() is misplaced, it should go somewhere in src/mat/interface/matrix.c 2) We should add MatGetOperation(), right? Should it just return the routine set in mat-ops? Are you ok with this? -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459
