April 2021 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] CI error
by Barry Smith 11 Apr '21

11 Apr '21

With PETSc, since we don't like having any warning messages while compiling for users (how can they know if the warning is meaningful or not), we try to initialize anything that any compiler at any optimization level complains about. So lots of initializations are not technically needed but are good for PR. Mark's case is kind of annoying because the size of the array is configure dependent and so initializing "all entries" depends on the size of the array which for other people may be different. This is why it would be nice (I don't know if possible) to have a standard C99 way of initializing arrays. My rule is, if it every complains (wrongly) about initialized values then initialize them. Barry > On Apr 11, 2021, at 8:10 PM, Mark Adams <mfadams(a)lbl.gov> wrote: > > It did seem to be non-deterministic. (how is that possible?). > I got this error, sent my message. > Tried Barry's idea and initialized them all (5) by hand. > It worked! > I tried initializing just one. > It worked. > I tried initializing none (yes, back to where I started) > And it worked :o > > I guess this error is another try-it-again CI error. > > On Sun, Apr 11, 2021 at 8:06 PM <jacob.fai(a)gmail.com <mailto:[email protected]>> wrote: > I ran into a similar problem months ago and the long and short of it is that any compilers uninitialized variable detection is incredibly dependent on optimization level, which the higher you go becomes non-deterministic. > > > > That being said, gcc is pretty terrible at getting this particular warning right :) https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=may%20be%20uninitializ… <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=may%20be%20uninitializ…> > > > Best regards, > > > > Jacob Faibussowitsch > > (Jacob Fai - booss - oh - vitch) > > Cell: (312) 694-3391 > > > > From: petsc-dev <petsc-dev-bounces(a)mcs.anl.gov <mailto:[email protected]>> On Behalf Of Barry Smith > Sent: Sunday, April 11, 2021 17:51 > To: Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> > Cc: For users of the development version of PETSc <petsc-dev(a)mcs.anl.gov <mailto:[email protected]>> > Subject: Re: [petsc-dev] CI error > > > > > > You might be able to do: > > > > col_scale[LANDAU_MAX_Q_FACE = {0}; > > > > but then the compiler may complain about not initializing enough values. Googling this type of initialization might help, something C initialize arrays "may be used uninitialized" > > > > > > > > > > > On Apr 11, 2021, at 2:05 PM, Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: > > > > This warning went away. i don't know why. > > > > On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: > > I get this error in CI with complex float: https://gitlab.com/petsc/petsc/-/jobs/1170144554 <https://gitlab.com/petsc/petsc/-/jobs/1170144554> > > > I put in code earlier to fix this warning about uninitialized vars, but now it does not seem to work: > > > > /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: error: ‘col_scale[4]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] > > 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; > > > Yet I have code to initialize col_scale: > > > > for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // suppress warnings > > > > I get a similar error with an integer array. > > > > Any suggestions? > > >

1 0

Re: [petsc-dev] CI error
by Mark Adams 11 Apr '21

11 Apr '21

It did seem to be non-deterministic. (how is that possible?). I got this error, sent my message. Tried Barry's idea and initialized them all (5) by hand. It worked! I tried initializing just one. It worked. I tried initializing none (yes, back to where I started) And it worked :o I guess this error is another try-it-again CI error. On Sun, Apr 11, 2021 at 8:06 PM <jacob.fai(a)gmail.com> wrote: > I ran into a similar problem months ago and the long and short of it is > that any compilers uninitialized variable detection is incredibly dependent > on optimization level, which the higher you go becomes non-deterministic. > > > > That being said, gcc is pretty terrible at getting this particular warning > right :) > https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=may%20be%20uninitializ… > > > > Best regards, > > > > Jacob Faibussowitsch > > (Jacob Fai - booss - oh - vitch) > > Cell: (312) 694-3391 > > > > *From:* petsc-dev <petsc-dev-bounces(a)mcs.anl.gov> *On Behalf Of *Barry > Smith > *Sent:* Sunday, April 11, 2021 17:51 > *To:* Mark Adams <mfadams(a)lbl.gov> > *Cc:* For users of the development version of PETSc <petsc-dev(a)mcs.anl.gov > > > *Subject:* Re: [petsc-dev] CI error > > > > > > You might be able to do: > > > > col_scale[LANDAU_MAX_Q_FACE = {0}; > > > > but then the compiler may complain about not initializing enough values. > Googling this type of initialization might help, something C initialize > arrays "may be used uninitialized" > > > > > > > > On Apr 11, 2021, at 2:05 PM, Mark Adams <mfadams(a)lbl.gov> wrote: > > > > This warning went away. i don't know why. > > > > On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov> wrote: > > I get this error in CI with complex float: > https://gitlab.com/petsc/petsc/-/jobs/1170144554 > > > > I put in code earlier to fix this warning about uninitialized vars, but > now it does not seem to work: > > > > /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: > error: ‘col_scale[4]’ may be used uninitialized in this function > [-Werror=maybe-uninitialized] > > 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar > vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; > > > Yet I have code to initialize col_scale: > > > > for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // > suppress warnings > > > > I get a similar error with an integer array. > > > > Any suggestions? > > >

1 0

Re: [petsc-dev] CI error
by jacob.fai＠gmail.com 11 Apr '21

11 Apr '21

I ran into a similar problem months ago and the long and short of it is that any compilers uninitialized variable detection is incredibly dependent on optimization level, which the higher you go becomes non-deterministic. That being said, gcc is pretty terrible at getting this particular warning right :) https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=may%20be%20uninitializ… Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 From: petsc-dev <petsc-dev-bounces(a)mcs.anl.gov> On Behalf Of Barry Smith Sent: Sunday, April 11, 2021 17:51 To: Mark Adams <mfadams(a)lbl.gov> Cc: For users of the development version of PETSc <petsc-dev(a)mcs.anl.gov> Subject: Re: [petsc-dev] CI error You might be able to do: col_scale[LANDAU_MAX_Q_FACE = {0}; but then the compiler may complain about not initializing enough values. Googling this type of initialization might help, something C initialize arrays "may be used uninitialized" On Apr 11, 2021, at 2:05 PM, Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]> > wrote: This warning went away. i don't know why. On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]> > wrote: I get this error in CI with complex float: https://gitlab.com/petsc/petsc/-/jobs/1170144554 I put in code earlier to fix this warning about uninitialized vars, but now it does not seem to work: /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: error: ‘col_scale[4]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> 2251 PetscScalar vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; Yet I have code to initialize col_scale: for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // suppress warnings I get a similar error with an integer array. Any suggestions?

1 0

Re: [petsc-dev] CI error
by Barry Smith 11 Apr '21

11 Apr '21

You might be able to do: > col_scale[LANDAU_MAX_Q_FACE = {0}; but then the compiler may complain about not initializing enough values. Googling this type of initialization might help, something C initialize arrays "may be used uninitialized" > On Apr 11, 2021, at 2:05 PM, Mark Adams <mfadams(a)lbl.gov> wrote: > > This warning went away. i don't know why. > > On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: > I get this error in CI with complex float: https://gitlab.com/petsc/petsc/-/jobs/1170144554 <https://gitlab.com/petsc/petsc/-/jobs/1170144554> > > I put in code earlier to fix this warning about uninitialized vars, but now it does not seem to work: > > /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: error: ‘col_scale[4]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] > 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; > > Yet I have code to initialize col_scale: > > for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // suppress warnings > > I get a similar error with an integer array. > > Any suggestions?

1 0

Re: [petsc-dev] CI error
by Mark Adams 11 Apr '21

11 Apr '21

This warning went away. i don't know why. On Sun, Apr 11, 2021 at 2:10 PM Mark Adams <mfadams(a)lbl.gov> wrote: > I get this error in CI with complex float: > https://gitlab.com/petsc/petsc/-/jobs/1170144554 > > I put in code earlier to fix this warning about uninitialized vars, but > now it does not seem to work: > > /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: > error: ‘col_scale[4]’ may be used uninitialized in this function > [-Werror=maybe-uninitialized] > 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar > vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; > > Yet I have code to initialize col_scale: > > for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // > suppress warnings > > I get a similar error with an integer array. > > Any suggestions? >

1 0

CI error
by Mark Adams 11 Apr '21

11 Apr '21

I get this error in CI with complex float: https://gitlab.com/petsc/petsc/-/jobs/1170144554 I put in code earlier to fix this warning about uninitialized vars, but now it does not seem to work: /home/glci/builds-stage1/AbTGp5-t/0/petsc/petsc/src/ts/utils/dmplexlandau/plexland.c:414:94: error: ‘col_scale[4]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 2251 <https://gitlab.com/petsc/petsc/-/jobs/1170144554#L2251> PetscScalar vals[LANDAU_MAX_Q_FACE*LANDAU_MAX_Q_FACE],row_scale[LANDAU_MAX_Q_FACE],col_scale[LANDAU_MAX_Q_FACE]; Yet I have code to initialize col_scale: for (q = 0; q < LANDAU_MAX_Q_FACE; q++) col_scale[q] = 0.0; // suppress warnings I get a similar error with an integer array. Any suggestions?

1 0

Re: [petsc-dev] -with-kokkos-cuda-arch=AMPERE80 nonsense
by Matthew Knepley 07 Apr '21

07 Apr '21

On Wed, Apr 7, 2021 at 5:47 PM Scott Kruger <kruger(a)txcorp.com> wrote: > On 2021-04-06 14:44, Matthew Knepley did write: > > > > Does spack have some magic for this we could use? > > > > > > > > > > spack developed the archspec repo to abstract all of these issues: > > > https://github.com/archspec/archspec > > > > > > I do not love it. Besides the actual code (you can always complain about > > code), > > they do not really do any tests. They go look in a few places that data > > should be. > > We can do the same thing in probably 10x less code. It would be great to > > actually > > test the hardware to verify. > > > > My impression is that the current project is languishing because they > are focusing on the spack side right now. But if this is the project > that is the ECP-annointed solution, then it has the best chance of > succeeding through sheer resources. > Maybe this will end up eventually being good. However, in my lifetime at DOE, funded projects are usually the best indicator of what not to do. Matt > The thing I like the best is that having a stand-alone project to handle > these issues is a real forehead-slapper (i.e., "why didn't I think of > that?!"). Todd Gamblin has stated that the goal is to allow vendors to > contribute because it will be in their interest to contribute. This > should have been done years ago. > > Regarding whether we could do better: Now would actually be a good time > to contribute while the project is young, but I don't have the time > (like everyone else which is why this is a perennial problem). It > would also be a good time to create a separate project if this one is > too annoying for folks. In general, like spack, they have done a good > job on the interface so that part is important. > > Scott > > > > > > Thanks, > > > > Matt > > > > > > > This is a *great* idea and eventually BuildSystem should incorporate > it as > > > the standard way of doing things; however, it is been focused mostly on > > > the CPU issues, and is still under active development (my understanding > > > is that the pulling it out of spack and getting those interop issues > > > sorted out is tangled up in how spack handles dependencies and > > > compilers). It'd be nice if someone would go in and port the Kokkos > gpu > > > mappings to archspec as there is some great knowledge on these mapping > > > buried in the Kokkos build system (not volunteering); i.e., translating > > > that webpage to some real code (even if it is in make) is valuable. > > > > > > TL;DR: It's a known problem with currently no good solution AFAIK. > > > Waiting until archspec gets further along seems like the best solution. > > > > > > Scott > > > > > > P.S. ROCm has rocminfo which also doesn't solve the problem but is at > > > least sane. > > > > > > > > > -- > > 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/ < > http://www.cse.buffalo.edu/~knepley/> > > -- > Scott Kruger > Tech-X Corporation kruger(a)txcorp.com > 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 > Boulder, CO 80303 Fax: (303) 448-7756 > -- 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/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] -with-kokkos-cuda-arch=AMPERE80 nonsense
by Scott Kruger 07 Apr '21

07 Apr '21

On 2021-04-06 14:44, Matthew Knepley did write: > > > Does spack have some magic for this we could use? > > > > > > > spack developed the archspec repo to abstract all of these issues: > > https://github.com/archspec/archspec > > > I do not love it. Besides the actual code (you can always complain about > code), > they do not really do any tests. They go look in a few places that data > should be. > We can do the same thing in probably 10x less code. It would be great to > actually > test the hardware to verify. > My impression is that the current project is languishing because they are focusing on the spack side right now. But if this is the project that is the ECP-annointed solution, then it has the best chance of succeeding through sheer resources. The thing I like the best is that having a stand-alone project to handle these issues is a real forehead-slapper (i.e., "why didn't I think of that?!"). Todd Gamblin has stated that the goal is to allow vendors to contribute because it will be in their interest to contribute. This should have been done years ago. Regarding whether we could do better: Now would actually be a good time to contribute while the project is young, but I don't have the time (like everyone else which is why this is a perennial problem). It would also be a good time to create a separate project if this one is too annoying for folks. In general, like spack, they have done a good job on the interface so that part is important. Scott > Thanks, > > Matt > > > > This is a *great* idea and eventually BuildSystem should incorporate it as > > the standard way of doing things; however, it is been focused mostly on > > the CPU issues, and is still under active development (my understanding > > is that the pulling it out of spack and getting those interop issues > > sorted out is tangled up in how spack handles dependencies and > > compilers). It'd be nice if someone would go in and port the Kokkos gpu > > mappings to archspec as there is some great knowledge on these mapping > > buried in the Kokkos build system (not volunteering); i.e., translating > > that webpage to some real code (even if it is in make) is valuable. > > > > TL;DR: It's a known problem with currently no good solution AFAIK. > > Waiting until archspec gets further along seems like the best solution. > > > > Scott > > > > P.S. ROCm has rocminfo which also doesn't solve the problem but is at > > least sane. > > > > > -- > 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/ <http://www.cse.buffalo.edu/~knepley/> -- Scott Kruger Tech-X Corporation kruger(a)txcorp.com 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 Boulder, CO 80303 Fax: (303) 448-7756

1 0

Re: [petsc-dev] (arm64) could not find object file symbol for symbol ___muldc3
by Barry Smith 07 Apr '21

07 Apr '21

Ok, thanks. I am not sure how to handle it. libgcc_s.1.dylib never appears in the configure process and we don't actually test that the Fortran compiler can link C; for 25 years it just always could. Barry > On Apr 7, 2021, at 10:49 AM, Blaise A Bourdin <bourdin(a)lsu.edu> wrote: > > No luck with -lgcc but it looks like this symbol is defined in > /usr/local/Cellar/gcc/10.2.0_4/lib/gcc/10/libgcc_s.1.dylib > 00000000000039b0 T ___muldc3 > > So adding -lgcc_s.1 eliminates the warning. > I assume that the issue is with gcc-10 on macOS ARM. I can try to report it to upstream to although building a small test may be a bit challenging. > > Regards, > Blaise > >> On Apr 6, 2021, at 5:32 PM, Barry Smith <bsmith(a)petsc.dev <mailto:[email protected]>> wrote: >> >> >> Blaise, >> >> Thanks, can you try cd src/snes/tutorials and then cut and paste the huge line that you sent earlier that begins with mpif90 -Wl,-bind_at_load ..... and add at the end -lgcc and see if that line successfully links the Fortran code? >> >> Thanks >> >> Barry >> >> >> >>> On Apr 6, 2021, at 12:22 PM, Blaise A Bourdin <bourdin(a)lsu.edu <mailto:[email protected]>> wrote: >>> >>> Hi Barry, >>> >>>> >>>> Please send configure.log >>> See attached >>> >>>> >>>> It would also be helpful if you could run >>>> >>>> nm -o /usr/lib/lib* | grep muldc3 >>> >>> That is uneventful (I have no idea how these broken symbolic link got there and can’t delete them because of SIP)… >>> SiMini:lib $ nm -o /usr/lib/lib* | grep muldc3 >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /usr/lib/libhunspell-1.2.0.dylib: No such file or directory. >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /usr/lib/libhunspell-1.2.dylib: No such file or directory. >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /usr/lib/libiodbc.2.dylib: No such file or directory. >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /usr/lib/libiodbc.dylib: No such file or directory. >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /usr/lib/libiodbcinst.2.dylib: No such file or directory. >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /usr/lib/libiodbcinst.dylib: No such file or directory. >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /usr/lib/libstdc++.6.dylib: No such file or directory. >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /usr/lib/libstdc++.dylib: No such file or directory. >>> >>> Blaise >>> >>> >>> >>>> >>>> Our cross language linker tests are not adding all the libraries they need to add when using Fortran for linking. >>>> >>>> Barry >>>> >>>> >>>> >>>>> On Apr 6, 2021, at 11:00 AM, Matthew Knepley <knepley(a)gmail.com <mailto:[email protected]>> wrote: >>>>> >>>>> On Tue, Apr 6, 2021 at 11:04 AM Blaise A Bourdin <bourdin(a)lsu.edu <mailto:[email protected]>> wrote: >>>>> Hi, >>>>> >>>>> I am having the following warning when compiling any fortran example (currently on main, but it’s been going on for a little while) on a ARM mac. >>>>> >>>>> >>>>> *******************Error detected during compile or link!******************* >>>>> See http://www.mcs.anl.gov/petsc/documentation/faq.html <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mcs.an…> >>>>> /opt/HPC/petsc-main/src/snes/tutorials ex5f >>>>> ********************************************************* >>>>> mpif90 -Wl,-bind_at_load -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -Wl,-no_compact_unwind -ffree-line-length-none -fallow-argument-mismatch -fPIC -g -ffree-line-length-none -fallow-argument-mismatch -fPIC -g -I/opt/HPC/petsc-main/include -I/opt/HPC/petsc-main/bigsur-gcc10.2-arm64-reallybasic-g/include -I/opt/X11/include ex5f.F90 -Wl,-rpath,/opt/HPC/petsc-main/bigsur-gcc10.2-arm64-reallybasic-g/lib -L/opt/HPC/petsc-main/bigsur-gcc10.2-arm64-reallybasic-g/lib -Wl,-rpath,/opt/X11/lib -L/opt/X11/lib -Wl,-rpath,/opt/homebrew/Cellar/mpich/3.4.1_2/lib -L/opt/homebrew/Cellar/mpich/3.4.1_2/lib -Wl,-rpath,/opt/homebrew/Cellar/gcc/10.2.0_4/lib/gcc/10/gcc/aarch64-apple-darwin20/10.2.1 -L/opt/homebrew/Cellar/gcc/10.2.0_4/lib/gcc/10/gcc/aarch64-apple-darwin20/10.2.1 -Wl,-rpath,/opt/homebrew/Cellar/gcc/10.2.0_4/lib/gcc/10 -L/opt/homebrew/Cellar/gcc/10.2.0_4/lib/gcc/10 -lpetsc -llapack -lblas -lX11 -lc++ -ldl -lmpifort -lmpi -lpmpi -lgfortran -lemutls_w -lm -lc++ -ldl -o ex5f >>>>> warning: (arm64) could not find object file symbol for symbol muldc3 >>>>> Fortran example src/snes/tutorials/ex5f run successfully with 1 MPI process >>>>> >>>>> >>>>> For reference, here is how I configured petsc: >>>>> ./configure --CFLAGS='-Wimplicit-function-declaration' --FFLAGS="-ffree-line-length-none -fallow-argument-mismatch" --with-debugging=1 --with-shared-libraries=1 --with-x11=1 >>>>> >>>>> It looks like this symbol is referenced in: sfpack.o >>>>> >>>>> SiMini:petsc-main (main)$ grep -ri muldc3 bigsur-gcc10.2-arm64-reallybasic-g/* >>>>> Binary file bigsur-gcc10.2-arm64-reallybasic-g/lib/libpetsc.3.015.0.dylib matches >>>>> Binary file bigsur-gcc10.2-arm64-reallybasic-g/lib/libpetsc.3.015.dylib matches >>>>> bigsur-gcc10.2-arm64-reallybasic-g/lib/petsc/conf/check.log:warning: (arm64) could not find object file symbol for symbol ___muldc3 >>>>> Binary file bigsur-gcc10.2-arm64-reallybasic-g/lib/libpetsc.dylib matches >>>>> Binary file bigsur-gcc10.2-arm64-reallybasic-g/obj/vec/is/sf/impls/basic/sfpack.o matches >>>>> >>>>> SiMini:petsc-main (main)$ nm bigsur-gcc10.2-arm64-reallybasic-g/obj/vec/is/sf/impls/basic/sfpack.o | grep muldc3 >>>>> U ___muldc3 >>>>> >>>>> Google tells me it is a gcc thing for complex multiplication. Ah, I think this is the problem: >>>>> >>>>> https://lists.mcs.anl.gov/pipermail/mpich-discuss/2012-August/012920.html <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mcs…> >>>>> >>>>> It is in the C library and you are linking from Fortran, so the compatibility libraries are not correct. >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> Any idea? >>>>> 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 <http://www.math.lsu.edu/~bourdin> >>>>> >>>>> >>>>> -- >>>>> 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/ <https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cse.buff…> >>>> >>> >>> -- >>> 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 <http://www.math.lsu.edu/~bourdin> >>> <configure.log> >> > > -- > 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 <http://www.math.lsu.edu/~bourdin>

1 0

Re: [petsc-dev] ?????? Petsc: Error code 1
by Satish Balay 07 Apr '21

07 Apr '21

There are always diffs (between different compilers, versions, hardware) - doesn't necessarily mean failures. Very large diffs [as Barry mentioned] might require a closer look. Depending upon your purpose - you might consider that you have a valid petsc install and start using it. Obviously - based on the problem that you are solving - you might need to re-visit this issue [checking how your application behaves between a debug build and optimized build - and play with different optimization flags] Satish On Wed, 7 Apr 2021, Chen Gang wrote: > ARM: configure with the following: -ffp-contract=off > > > ./configure -with-debugging=0 COPTFLAGS='-O3 -ffp-contract=off -march=armv8.2-a -mtune=tsv110' CXXOPTFLAGS='-O3 -ffp-contract=off -march=armv8.2-a -mtune=tsv110' FOPTFLAGS='-O3 -ffp-contract=off -march=armv8.2-a -mtune=tsv110' --with-x=1 -download-fblaslapack PETSC-KERNEL-USE-UNROLL-4 > > > There are 3 failures, all related to FC code > > > > > # ------------- > #   Summary > # ------------- > # FAILED diff-tao_bound_tutorials-plate2f_2 diff-tao_bound_tutorials-plate2f_1 diff-vec_is_is_tutorials-ex2f_1 > # success 7547/9528 tests (79.2%) > # failed 3/9528 tests (0.0%) > # todo 225/9528 tests (2.4%) > # skip 1753/9528 tests (18.4%) > # > # Wall clock time for tests: 1371 sec > # Approximate CPU time (not incl. build time): 106722.62999999999 sec > # > # To rerun failed tests: > #     /opt/rh/devtoolset-9/root/usr/bin/gmake -f gmakefile test test-fail=1 > # > # Timing summary (actual test time / total CPU time): > #   dm_tests-ex36_3dp1: 467.68 sec / 477.71 sec > #   dm_impls_stag_tests-ex1_multidof_3: 395.16 sec / 398.45 sec > #   ts_tutorials-ex29_1: 236.54 sec / 238.30 sec > #   dm_impls_stag_tests-ex1_basic_2: 205.41 sec / 207.34 sec > #   dm_tests-ex34_1: 178.94 sec / 180.26 sec > > > > > > > > ------------------ ???????? ------------------ > ??????: "Chen Gang" <569615491(a)qq.com>; > ????????: 2021??4??7??(??????) ????10:49 > ??????: "petsc-dev"<petsc-dev(a)mcs.anl.gov>; > > ????: ?????? [petsc-dev] Petsc: Error code 1 > > > > ARM: configure with the following: -ffp-contract=off > > > ./configure -with-debugging=0 COPTFLAGS='-O3 -ffp-contract=off -march=armv8.2-a -mtune=tsv110' CXXOPTFLAGS='-O3 -ffp-contract=off -march=armv8.2-a -mtune=tsv110' FOPTFLAGS='-O3 -ffp-contract=off -march=armv8.2-a -mtune=tsv110' --with-x=1 -download-fblaslapack PETSC-KERNEL-USE-UNROLL-4 > > > There are 3 failures, all related to FC code > > > > > # ------------- > #   Summary > # ------------- > # FAILED diff-tao_bound_tutorials-plate2f_2 diff-tao_bound_tutorials-plate2f_1 diff-vec_is_is_tutorials-ex2f_1 > # success 7547/9528 tests (79.2%) > # failed 3/9528 tests (0.0%) > # todo 225/9528 tests (2.4%) > # skip 1753/9528 tests (18.4%) > # > # Wall clock time for tests: 1371 sec > # Approximate CPU time (not incl. build time): 106722.62999999999 sec > # > # To rerun failed tests: > #     /opt/rh/devtoolset-9/root/usr/bin/gmake -f gmakefile test test-fail=1 > # > # Timing summary (actual test time / total CPU time): > #   dm_tests-ex36_3dp1: 467.68 sec / 477.71 sec > #   dm_impls_stag_tests-ex1_multidof_3: 395.16 sec / 398.45 sec > #   ts_tutorials-ex29_1: 236.54 sec / 238.30 sec > #   dm_impls_stag_tests-ex1_basic_2: 205.41 sec / 207.34 sec > #   dm_tests-ex34_1: 178.94 sec / 180.26 sec > > > > ------------------ ???????? ------------------ > ??????: "petsc-dev" <balay(a)mcs.anl.gov>; > ????????: 2021??4??7??(??????) ????1:06 > ??????: "Barry Smith"<bsmith(a)petsc.dev>; > ????: "Chen Gang"<569615491(a)qq.com>;"Alp Dener"<alp.dener(a)gmail.com>;"petsc-dev"<petsc-dev(a)mcs.anl.gov>;"cglwdm"<cglwdm(a)scu.edu.cn>; > ????: Re: [petsc-dev] Petsc: Error code 1 > > > > > See the attachements. alltest.log is on a machine with 96 cores, ARM, with FC,gcc9.3.5,mpich3.4.1,fblaslapack; 6 failures > > Perhaps this is an issue with ARM - and such diffs are expected - as we already have multiple alt files for some of these tests > > $ ls -lt src/tao/bound/tutorials/output/plate2f_* > -rw-r--r--. 1 balay balay 1029 Mar 23 19:48 src/tao/bound/tutorials/output/plate2f_1_alt.out > -rw-r--r--. 1 balay balay 1071 Mar 23 19:48 src/tao/bound/tutorials/output/plate2f_1.out > -rw-r--r--. 1 balay balay 1029 Mar 23 19:48 src/tao/bound/tutorials/output/plate2f_2_alt.out > -rw-r--r--. 1 balay balay 1071 Mar 23 19:48 src/tao/bound/tutorials/output/plate2f_2.out > > >>>>>> > not ok diff-vec_is_is_tutorials-ex2f_1 # Error code: 1 > #       16,24d15 > #       <   5 > #       <   7 > #       <   9 > #       <  11 > #       <  13 > #       <  15 > #       <  17 > #       <  19 > #       <  21 > <<<<< > > This one is puzzling - missing fortran stdout? Perhaps compile issue on ARM? [its a sequential example - so can't blame MPI] > > Or they are all related to the optimization flags used? What configure options were used for the build? > > Satish > > On Tue, 6 Apr 2021, Barry Smith wrote: > > > > >     Alp, > > > >    Except for the first test, these are all optimization problems (mostly in Fortran). The function values are very different so I am sending it to our optimization expert to take a look at it. The differences could possibly be related to the use of real() and maybe the direct use of floating point numbers that the compiler first treats as single and then converts to double thus losing precision. > > > >    Chen Gang, I assume you compiled with the default standard precision PETSc configure options? > > > > > > > > On Apr 6, 2021, at 3:56 AM, Chen Gang <569615491(a)qq.com<mailto:[email protected]>> wrote: > > > > > > See the attachements. alltest.log is on a machine with 96 cores, ARM, with FC,gcc9.3.5,mpich3.4.1,fblaslapack; 6 failures > >                                  alltest2.log is on an intel machine with 40  cores,x86, without FC; icc&mkl& intel mpi; only 1 failure > > > > ------------------ ???????? ------------------ > > ??????: "petsc-dev" <balay(a)mcs.anl.gov<mailto:[email protected]>>; > > ????????: 2021??4??6??(??????) ????12:38 > > ??????: "petsc-dev"<petsc-dev(a)mcs.anl.gov<mailto:[email protected]>>; > > ????: "Chen Gang"<569615491(a)qq.com<mailto:[email protected]>>;"cglwdm"<cglwdm(a)scu.edu.cn<mailto:[email protected]>>; > > ????: Re: [petsc-dev] Petsc: Error code 1 > > > > Note: do not use '-j' with alltests. > > > > And run alltests on both machines [but *not* at the same time on machines] and send us logs from both the runs. > > > > Satish > > > > > > On Mon, 5 Apr 2021, Satish Balay wrote: > > > > > Try: > > > > > > make alltests TIMEOUT=600 > > > > > > And send us the complete log (alltests.log) > > > > > > Satish > > > > > > On Tue, 6 Apr 2021, Chen Gang wrote: > > > > > > > Dear sir, > > > > > > > > > > > > The result of make check is OK. And I do set the timeout to a larger value, which keeps me from getting timeout error. The thing is I have two machines. And I get the error code 1 in different tests on different machines.I don??t know what is error code1. What case this? How can I fix the failure tests. > > > > > > > > > > > > ------------------ Original ------------------ > > > > From: Satish Balay <balay(a)mcs.anl.gov<mailto:[email protected]>&gt; > > > > Date: Tue,Apr 6,2021 0:18 PM > > > > To: Chen Gang <569615491(a)qq.com<mailto:[email protected]>&gt; > > > > Cc: petsc-dev <petsc-dev(a)mcs.anl.gov<mailto:[email protected]>&gt;, cglwdm <cglwdm(a)scu.edu.cn<mailto:[email protected]>&gt; > > > > Subject: Re: [petsc-dev] Petsc: Error code 1 > > > > > > > <alltests2.log><alltests.log> > > > >

1 0