Re: [petsc-dev] Suggestion regarding CI issues

Great idea and good text: https://gitlab.com/petsc/petsc/issues/360 https://gitlab.com/petsc/petsc/wikis/home > On Oct 23, 2019, at 4:13 AM, Hapla Vaclav via petsc-dev > wrote: > > Issues related to CI testing often affect multiple independent MRs. There > should be a single point where

Re: [petsc-dev] [Suggestion] Configure QOL Improvements

https://www.youtube.com/watch?v=NVopDink4uQ https://gitlab.com/petsc/petsc/merge_requests/2207 > On Oct 23, 2019, at 8:34 PM, Matthew Knepley via petsc-dev > wrote: > > On Wed, Oct 23, 2019 at 5:08 PM Faibussowitsch, Jacob > wrote: > I think Jed is referring to the fact that configure app

Re: [petsc-dev] I think the test system is broken in master

The test system really has to dump all the output including stderr to GitLab; the stack frames etc. Drop just little tidbits without all the error output is worse than users who cut and paste one line from configure.log and expect it to help. I don't know how you decide to redirect stuff an

Re: [petsc-dev] PetscLayoutFindOwner and PetscLayoutFindOwnerIndex

These routines should be fixed. > On Oct 16, 2019, at 5:19 AM, Pierre Jolivet via petsc-dev > wrote: > > Hello, > These two functions use a parameter “owner” of type PetscInt*. > Shouldn’t this be PetscMPIInt*? > This implies changes left and right, so I want to check I’m not pushing an >

Re: [petsc-dev] Right-preconditioned GMRES

hat the problem is _most likely_ in my > RHS. > But I need to figure out why I only get this problem with > right-preconditioned KSPs with restrict or none. > > Thanks, > Pierre > > > > > On 13 Oct 2019, at 8:16 PM, Smith, Barry F. wrote: > > >

Re: [petsc-dev] AVX kernels, old gcc, still broken

This needs to be fixed properly with a configure test(s) and not with huge and inconsistent checks like this #if defined(PETSC_HAVE_IMMINTRIN_H) && defined(__AVX512F__) && defined(PETSC_USE_REAL_DOUBLE) && !defined(PETSC_USE_COMPLEX) && !defined(PETSC_USE_64BIT_INDICES) or this #elif d

Re: [petsc-dev] AVX kernels, old gcc, still broken

https://gitlab.com/petsc/petsc/issues/434 > On Oct 25, 2019, at 9:16 AM, Smith, Barry F. wrote: > > > This needs to be fixed properly with a configure test(s) and not with huge > and inconsistent checks like this > > #if defined(PETSC_HAVE_IMMINTRIN_H) &

Re: [petsc-dev] AVX kernels, old gcc, still broken

think it should be used minimally, you hate configure and think it should be used minimally. Barry > On Oct 25, 2019, at 1:54 PM, Jed Brown wrote: > > "Smith, Barry F. via petsc-dev" writes: > >> This needs to be fixed properly with a configure test(s)

Re: [petsc-dev] AVX kernels, old gcc, still broken

> On Oct 26, 2019, at 9:09 AM, Jed Brown wrote: > > "Smith, Barry F." writes: > >> The proposed fix is #if defined(PETSC_USE_AVX512_KERNELS) && && && && && >> in https://gitlab.com/petsc/pets

Re: [petsc-dev] Feed back on report on performance of vector operations on Summit requested

will report a much higher latency than the latter, because > synchronizations are expensive (i.e. your latency consists of kernel launch > latency plus device synchronization latency). Approach B is slightly > over-optimistic, but I've found it to better match what one observes for a

Re: [petsc-dev] Feed back on report on performance of vector operations on Summit requested

ou give me access to the repository with data and current plotting > scripts, I can take a crack at slicing it in the way that I think would > be useful. Hannah will give you the data. Barry > > "Smith, Barry F. via petsc-dev" writes: > >> We've prepare

Re: [petsc-dev] Feed back on report on performance of vector operations on Summit requested

Jed, Thanks, this is very useful. Barry > On Oct 31, 2019, at 11:47 AM, Jed Brown wrote: > > "Smith, Barry F." writes: > >>> On Oct 23, 2019, at 7:15 PM, Jed Brown wrote: >>> >>> IMO, Figures 2 and 7+ are more interesting

Re: [petsc-dev] Right-preconditioned GMRES

is > is the case. > > Thanks, > Pierre > >> On 24 Oct 2019, at 5:40 PM, Smith, Barry F. wrote: >> >> >> Send the code and exact instructions to run a "good" and a "bad" ASM >> >> Barry >> >> >>> On

Re: [petsc-dev] Right-preconditioned GMRES

https://gitlab.com/petsc/petsc/merge_requests/2290 > On Nov 7, 2019, at 4:24 AM, Pierre Jolivet wrote: > > > >> On 7 Nov 2019, at 5:32 AM, Smith, Barry F. wrote: >> >> >> Some idiot logged what they did, but not why they did it. >> >>

[petsc-dev] Place to capture all our work on GPUs (and ECP ...)

Please do not respond to this email: use https://gitlab.com/petsc/petsc/issues/490 Mark Adams has been generating some great information on Summit with GAMG and now AMGx and other people such as Hannah and Junchao generating information important to our education about GPUs and, of cours

Re: [petsc-dev] Parmetis bug

Nice. Anyway to add this exact reproducibility into a PETSc example that runs daily? The truism: all codes are buggy, even those that haven't been touched in 15 years, is definitely represented here. Barry > On Nov 10, 2019, at 7:31 PM, Fande Kong via petsc-dev > wrote: > > Valgr

Re: [petsc-dev] Gitlab notifications and labels

Scott, Thanks for researching this and send it out. Yes, I think all MR on DMPLEX should use a label DMPLEX; I don't think having an additional DM label is worth the effort since all the meat at the moment is DMPLEX. We should probably also have a TS label. Maybe others wil

Re: [petsc-dev] KSP in DMPlex

> On Nov 14, 2019, at 12:30 PM, Faibussowitsch, Jacob via petsc-dev > wrote: > > Hello, > > So I am trying to make a simple 5 pt stencil finite difference laplacian > operator (https://akmitra.public.iastate.edu/aero361/design_web/Laplace.pdf) > work on a dmplex mesh, but all of the example

[petsc-dev] https://software.intel.com/en-us/devcloud/oneapi

Re: [petsc-dev] Weird errors with enum in 64-bit ints

I looked at the code and see nothing glaring wrong. I guess it requires valgrind and the debugger on the machine where the trouble occurs. Your enum should not need to be changed. Barry > On Jan 13, 2020, at 3:52 AM, Matthew Knepley wrote: > > I have some unexplainable errors with 64-b

Re: [petsc-dev] Fortran equivalent + separate output with output_file

> On Jan 13, 2020, at 9:32 AM, Pierre Jolivet > wrote: > > Hello, > This is actually two separate questions, sorry. > 1) I’m looking for the Fortran equivalent of the following, but I couldn’t > get any help looking at the sources. > ierr = PetscOptionsBegin(PETSC_COMM_WORLD,"","","");CHKERR

Re: [petsc-dev] Fortran equivalent + separate output with output_file

them in the Fortran stubs, we have missed this case but we need to know what it is so we can fix it. Barry > On Jan 17, 2020, at 3:18 PM, Pierre Jolivet > wrote: > > > >> On 13 Jan 2020, at 4:38 PM, Smith, Barry F. wrote: >> >> >> >>

[petsc-dev] how do see artifacts?

With the new Gitlab interfaces how do you see the artifacts for failed pipelines/tests? I can't find them anywhere. It just takes me straight to the output with no sidebar for artifacts? Thanks Barry

Re: [petsc-dev] how do see artifacts?

g > > Satish > > On Sun, 19 Jan 2020, Smith, Barry F. via petsc-dev wrote: > >> >> With the new Gitlab interfaces how do you see the artifacts for failed >> pipelines/tests? I can't find them anywhere. It just takes me straight to >> the output with no sidebar for artifacts? >> >>Thanks >> >> Barry >> >

Re: [petsc-dev] how do see artifacts?

ng a different > one > > https://gitlab.com/petsc/petsc/-/jobs/407945185 > > Attaching what I see [with the 'artifact' section in the right side column] > > Satish > > On Mon, 20 Jan 2020, Smith, Barry F. via petsc-dev wrote: > >> >> >>

Re: [petsc-dev] how do see artifacts?

> On Jan 19, 2020, at 10:39 PM, Jed Brown wrote: > > "Smith, Barry F. via petsc-dev" writes: > >> I have no left hand side. > > Right hand side? I certainly see them. Are you using a funny browser? Apple's :-) > >> If I grab the lef

Re: [petsc-dev] how do see artifacts?

Do they link with iCloud? ☠️ > On Jan 20, 2020, at 5:07 AM, Matthew Knepley wrote: > > Try Firefox or Chrome? > >Matt > > On Sun, Jan 19, 2020 at 11:41 PM Smith, Barry F. via petsc-dev > wrote: > > > > On Jan 19, 2020, at 10:39 PM, Jed Brown

Re: [petsc-dev] complex fix and -Wfloat-equal

> On Jan 27, 2020, at 3:42 PM, Lisandro Dalcin wrote: > > I usually compile my code with almost most warning flags on, including > -Wfloat-equal. > My implementation of the C++ complex fix that is not included by default is > an obvious offender (see warning messages at the end). > > A simp

[petsc-dev] is make alldoc tested?

Generating manual example links Unexpected argument -printmatch-link! Unexpected argument -printmatch-link! manualpages in: /Users/barrysmith/Src/petsc/src/snes/linesearch/impls/bt Error: Error reading html.def in path .:/Users/barrysmith/Src/petsc/arch-master/share or TEXTFILTER_PATH environm

Re: [petsc-dev] is make alldoc tested?

- but not > in gitlab-ci. > > I have the fixes at https://gitlab.com/petsc/petsc/-/merge_requests/2503 > > Satish > > On Sat, 1 Feb 2020, Smith, Barry F. via petsc-dev wrote: > >> >> Generating manual example links >> Unexpected argument -print

Re: [petsc-dev] is make alldoc tested?

es in doc build targets - and errors in each > stage are ignored. So will have to fix them to stop on error [in the subset > of targets we build in CI] > > And all doc-only changes would have to be run through this CI test - before > merge.. > > Satish > > On Tue,

Re: [petsc-dev] is make alldoc tested?

We should still be doing the testing now > On Feb 4, 2020, at 2:46 PM, Jed Brown wrote: > > Moving toward Sphinx (as Patrick has been working on) will help reduce > the number of stages and improve identification and reporting of > diagnostics/errors. > > Satish Balay via petsc-dev writes

[petsc-dev] Fwd: [SIAM-CSE] Introducing hIPPYlib, a python-based inverse problems solver library

Lois sent out this announcement on hIPPYlib 3.0 Begin forwarded message: From: "McInnes, Lois Curfman" mailto:curf...@anl.gov>> Subject: FW: [SIAM-CSE] Introducing hIPPYlib, a python-based inverse problems solver library Date: February 4, 2020 at 8:52:46 AM CST To:

Re: [petsc-dev] First call to cudaMalloc or cudaFree is very slow on summit

ldd -o on the executable of both linkings of your code. My guess is that without PETSc it is linking the static version of the needed libraries and with PETSc the shared. And, in typical fashion, the shared libraries are off on some super slow file system so take a long time to be loaded

Re: [petsc-dev] First call to cudaMalloc or cudaFree is very slow on summit

pack/20180914/linux-rhel7-ppc64le/pgi-19.4/zlib-1.2.11-2htm7ws4hgrthi5tyjnqxtjxgpfklxsc/lib/libz.so.1 >> (0x200021a1) >> libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x200021a6) >> /lib64/ld64.so.2 (0x2000) >>

Re: [petsc-dev] First call to cudaMalloc or cudaFree is very slow on summit

spack/20180914/linux-rhel7-ppc64le/gcc-4.8.5/pgi-19.4-6acz4xyqjlpoaonjiiqjme2aknrfnzoy/linuxpower/19.4/lib/libpgf902.so >>>>> (0x20002124) >>>>> libpgftnrtl.so => >>>>> /autofs/nccs-svm1_sw/summit/.swci/0-core/opt/spack/20180914/linux-rhel7-pp

Re: [petsc-dev] First call to cudaMalloc or cudaFree is very slow on summit

gt;> 0.00% 1.7260us 2 863ns 490ns 1.2360us cuDeviceGet >>> >>> 0.00% 377ns 1 377ns 377ns 377ns cuDeviceGetUuid >>> >>> >>> >>> I also get the expected behavior if I add an MPI_Init and MPI_Finalize to >>> the >>> code inst

Re: [petsc-dev] First call to cudaMalloc or cudaFree is very slow on summit

ote: > > > >> On Feb 12, 2020, at 5:11 PM, Smith, Barry F. wrote: >> >> >> ldd -o on the petsc program (static) and the non petsc program (static), >> what are the differences? > > There is no difference in the outputs. > >> >> nm -o both exe

Re: [petsc-dev] First call to cudaMalloc or cudaFree is very slow on summit

> On Feb 13, 2020, at 5:39 PM, Zhang, Hong wrote: > > > >> On Feb 13, 2020, at 7:39 AM, Smith, Barry F. wrote: >> >> >> How are the two being compiled and linked? The same way, one with the PETSc >> library in the path and the other without? Or

[petsc-dev] Fwd: [petsc-users] Matrix-free method in PETSc

but didn’t know how the time stepping can be set up. Thanks, Yuyun From: Matthew Knepley mailto:knep...@gmail.com>> Date: Tuesday, February 18, 2020 at 9:23 PM To: Yuyun Yang mailto:yyan...@stanford.edu>> Cc: "Smith, Barry F." mailto:bsm...@mcs.anl.gov>>, "petsc

Re: [petsc-dev] [petsc-users] Matrix-free method in PETSc

ith, Barry F. wrote: > > > In the past you needed a brain to get a Stanford email account > > >> Begin forwarded message: >> >> From: Yuyun Yang >> Subject: Re: [petsc-users] Matrix-free method in PETSc >> Date: February 18, 2020 at 8:26:11 AM CS

[petsc-dev] Fwd: [Xlab] El Capitan CPU announcement

Begin forwarded message: From: "Thakur, Rajeev" mailto:tha...@anl.gov>> Subject: [Xlab] El Capitan CPU announcement Date: March 4, 2020 at 1:33:13 PM CST To: "x...@cels.anl.gov" mailto:x...@cels.anl.gov>> AMD https://www.anandtech.com/show/15581/el-capitan-supercomput

[petsc-dev] PETSc Social on line in 2 hours. 5pm Central time

We are having a PETSc social event at 5 pm central time today (in 2 hours). Everyone is welcome. Hope to see many of you, Barry Begin forwarded message: From: Todd Munson via BlueJeans Network mailto:inv...@bluejeans.com>> Subject: PETSc Social Date: March 31, 2020 at 5:16:32 PM CDT T

<    3   4   5   6   7   8