July 2016 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] p4est configure error
by Mark Adams 07 Jul '16

07 Jul '16

Yes, if fails on debug=0. This used to work on Edison and it does work now on Cori. On Fri, Jul 8, 2016 at 1:07 AM, Mark Adams <mfadams(a)lbl.gov> wrote: > whoops, that did not have p4est > > > On Fri, Jul 8, 2016 at 1:04 AM, Mark Adams <mfadams(a)lbl.gov> wrote: > >> >> >> On Fri, Jul 8, 2016 at 12:18 AM, Tobin Isaac <tisaac(a)uchicago.edu> wrote: >> >>> Interesting, you'd think that --disable-shared would be all that >>> matters. Could you please send that configure.log for comparison? >>> >>> On July 7, 2016 5:14:13 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: >>> >Well, this did not work as you suspected ... FYI, it seems to work >>> >with-debugging=0. >>> > >>> >On Thu, Jul 7, 2016 at 11:13 PM, Satish Balay <balay(a)mcs.anl.gov> >>> >wrote: >>> > >>> >> >>> >> >>> >> >>>>>>> >>> >> /bin/sh ./libtool --tag=CC --mode=link cc -no-ipo -g -O0 -o >>> >> libb64/sc_b64enc libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la >>> >-lgomp >>> >> libtool: link: cc -no-ipo -g -O0 -o libb64/sc_b64enc >>> >> libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a >>> >> /opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so -lrt -ldl -Wl,-rpath >>> >> -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 -Wl,-rpath >>> >> -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 >>> >> <<<<<<< >>> >> >>> >> For some reason libtool is converting "-lgomp" into >>> >> "/opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so" - and giving an ld >>> >error. >>> >> >>> >> On my linux box - I see: >>> >> >>>>>>> >>> >> /bin/sh ./libtool --tag=CC --mode=link mpicc -g3 -o >>> >libb64/sc_b64enc >>> >> libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la -lgomp -lpthread -lz >>> >-lm >>> >> libtool: link: mpicc -g3 -o libb64/sc_b64enc >>> >> libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a -lgomp >>> >-lpthread -lz >>> >> -lm >>> >> <<<<<< >>> >> >>> >> I don't really understand libtool - or this error.. >>> >> >>> >> Satish >>> >> >>> >> On Thu, 7 Jul 2016, Tobin Isaac wrote: >>> >> >>> >> > Nope, different error: p4est autotools found an openmp library and >>> >tried >>> >> to link it, but there's a shared/static mismatch. I'll try to get to >>> >the >>> >> bottom of this. >>> >> > >>> >> > >>> >> > On July 7, 2016 3:27:23 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: >>> >> > >I nuked and ran this twice: >>> >> > > >>> >> > >1013 rm -fr arch-xc30-dbg64-intel >>> >> > > 1014 ../arch-xc30-dbg64-intel.py >>> >> > > 1015 h >>> >> > > 1016 ../arch-xc30-dbg64-intel.py >>> >> > > >>> >> > >Same error. >>> >> > > >>> >> > > >>> >> > >On Thu, Jul 7, 2016 at 9:36 PM, Satish Balay <balay(a)mcs.anl.gov> >>> >wrote: >>> >> > > >>> >> > >> perhaps configure was not rerun - so a stale p4est was being >>> >used.. >>> >> > >> >>> >> > >> Satish >>> >> > >> >>> >> > >> On Thu, 7 Jul 2016, Tobin Isaac wrote: >>> >> > >> >>> >> > >> > p4est.py automatically pulls from whatever p4est branch I call >>> >> > >'petsc' >>> >> > >> > in my repo, so I don't see how this problem persists if you >>> >really >>> >> > >> > nuked it. >>> >> > >> > >>> >> > >> > - Did you nuke the right directory? >>> >> > >> > - Did you send me the right configure.log? >>> >> > >> > - Is the new failure the same (the same stale p4est commit is >>> >being >>> >> > >> > used)? >>> >> > >> > >>> >> > >> > On Thu, Jul 07, 2016 at 08:33:57PM +0200, Mark Adams wrote: >>> >> > >> > > It sounds like I have not merged your fix. Should I pull >>> >from >>> >> > >master? >>> >> > >> > > >>> >> > >> > > I have nuked this many times. >>> >> > >> > > >>> >> > >> > > On Thu, Jul 7, 2016 at 4:26 PM, Tobin Isaac >>> ><tisaac(a)uchicago.edu> >>> >> > >> wrote: >>> >> > >> > > >>> >> > >> > > > >>> >> > >> > > > On Thu, Jul 07, 2016 at 03:16:40PM +0200, Mark Adams >>> >wrote: >>> >> > >> > > > > p4est on Edison configures in w/o debugging, although I >>> >have >>> >> > >to run >>> >> > >> > > > > configure twice. >>> >> > >> > > > > But with debugging it fails. I can not see any >>> >difference >>> >> > >between >>> >> > >> the >>> >> > >> > > > two >>> >> > >> > > > > configures other than debugging. >>> >> > >> > > > > Mark >>> >> > >> > > > >>> >> > >> > > > The log shows that you are configuring a p4est commit >>> >(3d3e1) >>> >> > >that is >>> >> > >> > > > before the one I pushed specifically to avoid the fortran >>> >> > >> > > > configuration error (f54bb3). Please clear the git.p4est >>> >> > >directory, >>> >> > >> > > > and confirm that you are configuring with the current >>> >'petsc' >>> >> > >branch >>> >> > >> > > > of p4est (`grep 'checking Point version' configure.log` >>> >should >>> >> > >show >>> >> > >> > > > X.XXX-a9f22). >>> >> > >> > > > >>> >> > >> > > > Cheers, >>> >> > >> > > > Toby >>> >> > >> > > > >>> >> > >> > >>> >> > >> >>> >> > >> >>> >> > >>> >> > >>> >> >>> >> >>> >>> >> >

1 0

Re: [petsc-dev] Soliciting suggestions for linear solver work under SciDAC 4 Institutes
by Jeff Hammond 07 Jul '16

07 Jul '16

On Thu, Jul 7, 2016 at 4:34 PM, Richard Mills <richardtmills(a)gmail.com> wrote: > On Fri, Jul 1, 2016 at 4:13 PM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: > >> [...] >> >> Maybe I am just biased because I spend all of my time reading >> www.nextplatform.com, but I hear machine learning is becoming an >> important HPC workload. While the most hyped efforts related to running >> inaccurate - the technical term is half-precision - dense matrix >> multiplication as fast as possible, I suspect that more elegant approaches >> will prevail. Presumably there is something that PETSc can do to enable >> machine learning algorithms. As most of the existing approaches use silly >> programming models based on MapReduce, it can't be too hard for PETSc to do >> better. >> > > "Machine learning" is definitely the hype du jour, but when that term gets > thrown around, everyone is equating it with neural networks with a lot of > layers ("deep learning"). That's why everyone is going on about half > precision dense matrix multiplication, as low accuracy works fine for some > of this stuff. The thing is, there are a a ton of machine-learning > approaches out there that are NOT neural networks, and I worry that > everyone is too ready to jump into specialized hardware for neural nets > when maybe there are better approaches out there. Regarding machine > learning approaches that use sparse matrix methods, I think that PETSc > (plus SLEPc) provide pretty good building blocks right now for these, > though there are probably things that could be better supported. But what > machine learning approaches PETSc should target right now, I don't know. > Program managers currently like terms like "neuromorphic computing" and > half-precision computations seem to be the focus. (Though why stop there? > Why not quarter precision?!!) > > Google TPU does quarter precision i.e. 8-bit fixed-point [ http://www.nextplatform.com/2016/05/19/google-takes-unconventional-route-ho…] so the machine learning folks have already gone there. No need to speculate about it :-) Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [petsc-dev] Soliciting suggestions for linear solver work under SciDAC 4 Institutes
by Jeff Hammond 07 Jul '16

07 Jul '16

On Thu, Jul 7, 2016 at 1:04 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Fri, Jul 1, 2016 at 4:32 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> >> The DOE SciDAC institutes have supported PETSc linear solver >> research/code development for the past fifteen years. >> >> This email is to solicit ideas for linear solver research/code >> development work for the next round of SciDAC institutes (which will be a 4 >> year period) in PETSc. Please send me any ideas, no matter how crazy, on >> things you feel are missing, broken, or incomplete in PETSc with regard to >> linear solvers that we should propose to work on. In particular, issues >> coming from particular classes of applications would be good. Generic >> "multi physics" coupling types of things are too general (and old :-)) >> while work for extreme large scale is also out since that is covered under >> another call (ECP). But particular types of optimizations etc for existing >> or new codes could be in, just not for the very large scale. >> >> Rough ideas and pointers to publications are all useful. There is an >> extremely short fuse so the sooner the better, >> > > I think the suggestions so far are fine, however they all seem to start at > the "how", whereas I would prefer we start at the "why". Maybe something > like > > 1) How do we run at bandwidth peak on new architectures like Cori or > Aurora? > > Patrick and Rich have good suggestions here. Karl and Rich showed some > promising numbers for KNL at the PETSc meeting. > > Future systems from multiple vendors basically move from 2-tier memory hierarchy of shared LLC and DRAM to a 3-tier hierarchy of fast memory (e.g. HBM), regular memory (e.g. DRAM), and slow (likely nonvolatile) memory on a node. Xeon Phi and some GPUs have caches, but it is unclear to me if it actually benefits software like PETSc to consider them. Figuring out how to run PETSc effectively on KNL should be generally useful... Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [petsc-dev] Soliciting suggestions for linear solver work under SciDAC 4 Institutes
by Richard Mills 07 Jul '16

07 Jul '16

On Fri, Jul 1, 2016 at 4:13 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > [...] > > Maybe I am just biased because I spend all of my time reading > www.nextplatform.com, but I hear machine learning is becoming an > important HPC workload. While the most hyped efforts related to running > inaccurate - the technical term is half-precision - dense matrix > multiplication as fast as possible, I suspect that more elegant approaches > will prevail. Presumably there is something that PETSc can do to enable > machine learning algorithms. As most of the existing approaches use silly > programming models based on MapReduce, it can't be too hard for PETSc to do > better. > "Machine learning" is definitely the hype du jour, but when that term gets thrown around, everyone is equating it with neural networks with a lot of layers ("deep learning"). That's why everyone is going on about half precision dense matrix multiplication, as low accuracy works fine for some of this stuff. The thing is, there are a a ton of machine-learning approaches out there that are NOT neural networks, and I worry that everyone is too ready to jump into specialized hardware for neural nets when maybe there are better approaches out there. Regarding machine learning approaches that use sparse matrix methods, I think that PETSc (plus SLEPc) provide pretty good building blocks right now for these, though there are probably things that could be better supported. But what machine learning approaches PETSc should target right now, I don't know. Program managers currently like terms like "neuromorphic computing" and half-precision computations seem to be the focus. (Though why stop there? Why not quarter precision?!!) --Richard > Jeff > > On Fri, Jul 1, 2016 at 2:32 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> >> The DOE SciDAC institutes have supported PETSc linear solver >> research/code development for the past fifteen years. >> >> This email is to solicit ideas for linear solver research/code >> development work for the next round of SciDAC institutes (which will be a 4 >> year period) in PETSc. Please send me any ideas, no matter how crazy, on >> things you feel are missing, broken, or incomplete in PETSc with regard to >> linear solvers that we should propose to work on. In particular, issues >> coming from particular classes of applications would be good. Generic >> "multi physics" coupling types of things are too general (and old :-)) >> while work for extreme large scale is also out since that is covered under >> another call (ECP). But particular types of optimizations etc for existing >> or new codes could be in, just not for the very large scale. >> >> Rough ideas and pointers to publications are all useful. There is an >> extremely short fuse so the sooner the better, >> >> Thanks >> >> Barry >> >> >> >> > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ >

1 0

Re: [petsc-dev] p4est configure error
by Mark Adams 07 Jul '16

07 Jul '16

whoops, that did not have p4est On Fri, Jul 8, 2016 at 1:04 AM, Mark Adams <mfadams(a)lbl.gov> wrote: > > > On Fri, Jul 8, 2016 at 12:18 AM, Tobin Isaac <tisaac(a)uchicago.edu> wrote: > >> Interesting, you'd think that --disable-shared would be all that >> matters. Could you please send that configure.log for comparison? >> >> On July 7, 2016 5:14:13 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: >> >Well, this did not work as you suspected ... FYI, it seems to work >> >with-debugging=0. >> > >> >On Thu, Jul 7, 2016 at 11:13 PM, Satish Balay <balay(a)mcs.anl.gov> >> >wrote: >> > >> >> >> >> >> >> >>>>>>> >> >> /bin/sh ./libtool --tag=CC --mode=link cc -no-ipo -g -O0 -o >> >> libb64/sc_b64enc libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la >> >-lgomp >> >> libtool: link: cc -no-ipo -g -O0 -o libb64/sc_b64enc >> >> libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a >> >> /opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so -lrt -ldl -Wl,-rpath >> >> -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 -Wl,-rpath >> >> -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 >> >> <<<<<<< >> >> >> >> For some reason libtool is converting "-lgomp" into >> >> "/opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so" - and giving an ld >> >error. >> >> >> >> On my linux box - I see: >> >> >>>>>>> >> >> /bin/sh ./libtool --tag=CC --mode=link mpicc -g3 -o >> >libb64/sc_b64enc >> >> libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la -lgomp -lpthread -lz >> >-lm >> >> libtool: link: mpicc -g3 -o libb64/sc_b64enc >> >> libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a -lgomp >> >-lpthread -lz >> >> -lm >> >> <<<<<< >> >> >> >> I don't really understand libtool - or this error.. >> >> >> >> Satish >> >> >> >> On Thu, 7 Jul 2016, Tobin Isaac wrote: >> >> >> >> > Nope, different error: p4est autotools found an openmp library and >> >tried >> >> to link it, but there's a shared/static mismatch. I'll try to get to >> >the >> >> bottom of this. >> >> > >> >> > >> >> > On July 7, 2016 3:27:23 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: >> >> > >I nuked and ran this twice: >> >> > > >> >> > >1013 rm -fr arch-xc30-dbg64-intel >> >> > > 1014 ../arch-xc30-dbg64-intel.py >> >> > > 1015 h >> >> > > 1016 ../arch-xc30-dbg64-intel.py >> >> > > >> >> > >Same error. >> >> > > >> >> > > >> >> > >On Thu, Jul 7, 2016 at 9:36 PM, Satish Balay <balay(a)mcs.anl.gov> >> >wrote: >> >> > > >> >> > >> perhaps configure was not rerun - so a stale p4est was being >> >used.. >> >> > >> >> >> > >> Satish >> >> > >> >> >> > >> On Thu, 7 Jul 2016, Tobin Isaac wrote: >> >> > >> >> >> > >> > p4est.py automatically pulls from whatever p4est branch I call >> >> > >'petsc' >> >> > >> > in my repo, so I don't see how this problem persists if you >> >really >> >> > >> > nuked it. >> >> > >> > >> >> > >> > - Did you nuke the right directory? >> >> > >> > - Did you send me the right configure.log? >> >> > >> > - Is the new failure the same (the same stale p4est commit is >> >being >> >> > >> > used)? >> >> > >> > >> >> > >> > On Thu, Jul 07, 2016 at 08:33:57PM +0200, Mark Adams wrote: >> >> > >> > > It sounds like I have not merged your fix. Should I pull >> >from >> >> > >master? >> >> > >> > > >> >> > >> > > I have nuked this many times. >> >> > >> > > >> >> > >> > > On Thu, Jul 7, 2016 at 4:26 PM, Tobin Isaac >> ><tisaac(a)uchicago.edu> >> >> > >> wrote: >> >> > >> > > >> >> > >> > > > >> >> > >> > > > On Thu, Jul 07, 2016 at 03:16:40PM +0200, Mark Adams >> >wrote: >> >> > >> > > > > p4est on Edison configures in w/o debugging, although I >> >have >> >> > >to run >> >> > >> > > > > configure twice. >> >> > >> > > > > But with debugging it fails. I can not see any >> >difference >> >> > >between >> >> > >> the >> >> > >> > > > two >> >> > >> > > > > configures other than debugging. >> >> > >> > > > > Mark >> >> > >> > > > >> >> > >> > > > The log shows that you are configuring a p4est commit >> >(3d3e1) >> >> > >that is >> >> > >> > > > before the one I pushed specifically to avoid the fortran >> >> > >> > > > configuration error (f54bb3). Please clear the git.p4est >> >> > >directory, >> >> > >> > > > and confirm that you are configuring with the current >> >'petsc' >> >> > >branch >> >> > >> > > > of p4est (`grep 'checking Point version' configure.log` >> >should >> >> > >show >> >> > >> > > > X.XXX-a9f22). >> >> > >> > > > >> >> > >> > > > Cheers, >> >> > >> > > > Toby >> >> > >> > > > >> >> > >> > >> >> > >> >> >> > >> >> >> > >> >> > >> >> >> >> >> >> >

1 0

Re: [petsc-dev] p4est configure error
by Mark Adams 07 Jul '16

07 Jul '16

On Fri, Jul 8, 2016 at 12:18 AM, Tobin Isaac <tisaac(a)uchicago.edu> wrote: > Interesting, you'd think that --disable-shared would be all that matters. > Could you please send that configure.log for comparison? > > On July 7, 2016 5:14:13 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: > >Well, this did not work as you suspected ... FYI, it seems to work > >with-debugging=0. > > > >On Thu, Jul 7, 2016 at 11:13 PM, Satish Balay <balay(a)mcs.anl.gov> > >wrote: > > > >> > >> > >> >>>>>>> > >> /bin/sh ./libtool --tag=CC --mode=link cc -no-ipo -g -O0 -o > >> libb64/sc_b64enc libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la > >-lgomp > >> libtool: link: cc -no-ipo -g -O0 -o libb64/sc_b64enc > >> libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a > >> /opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so -lrt -ldl -Wl,-rpath > >> -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 -Wl,-rpath > >> -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 > >> <<<<<<< > >> > >> For some reason libtool is converting "-lgomp" into > >> "/opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so" - and giving an ld > >error. > >> > >> On my linux box - I see: > >> >>>>>>> > >> /bin/sh ./libtool --tag=CC --mode=link mpicc -g3 -o > >libb64/sc_b64enc > >> libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la -lgomp -lpthread -lz > >-lm > >> libtool: link: mpicc -g3 -o libb64/sc_b64enc > >> libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a -lgomp > >-lpthread -lz > >> -lm > >> <<<<<< > >> > >> I don't really understand libtool - or this error.. > >> > >> Satish > >> > >> On Thu, 7 Jul 2016, Tobin Isaac wrote: > >> > >> > Nope, different error: p4est autotools found an openmp library and > >tried > >> to link it, but there's a shared/static mismatch. I'll try to get to > >the > >> bottom of this. > >> > > >> > > >> > On July 7, 2016 3:27:23 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: > >> > >I nuked and ran this twice: > >> > > > >> > >1013 rm -fr arch-xc30-dbg64-intel > >> > > 1014 ../arch-xc30-dbg64-intel.py > >> > > 1015 h > >> > > 1016 ../arch-xc30-dbg64-intel.py > >> > > > >> > >Same error. > >> > > > >> > > > >> > >On Thu, Jul 7, 2016 at 9:36 PM, Satish Balay <balay(a)mcs.anl.gov> > >wrote: > >> > > > >> > >> perhaps configure was not rerun - so a stale p4est was being > >used.. > >> > >> > >> > >> Satish > >> > >> > >> > >> On Thu, 7 Jul 2016, Tobin Isaac wrote: > >> > >> > >> > >> > p4est.py automatically pulls from whatever p4est branch I call > >> > >'petsc' > >> > >> > in my repo, so I don't see how this problem persists if you > >really > >> > >> > nuked it. > >> > >> > > >> > >> > - Did you nuke the right directory? > >> > >> > - Did you send me the right configure.log? > >> > >> > - Is the new failure the same (the same stale p4est commit is > >being > >> > >> > used)? > >> > >> > > >> > >> > On Thu, Jul 07, 2016 at 08:33:57PM +0200, Mark Adams wrote: > >> > >> > > It sounds like I have not merged your fix. Should I pull > >from > >> > >master? > >> > >> > > > >> > >> > > I have nuked this many times. > >> > >> > > > >> > >> > > On Thu, Jul 7, 2016 at 4:26 PM, Tobin Isaac > ><tisaac(a)uchicago.edu> > >> > >> wrote: > >> > >> > > > >> > >> > > > > >> > >> > > > On Thu, Jul 07, 2016 at 03:16:40PM +0200, Mark Adams > >wrote: > >> > >> > > > > p4est on Edison configures in w/o debugging, although I > >have > >> > >to run > >> > >> > > > > configure twice. > >> > >> > > > > But with debugging it fails. I can not see any > >difference > >> > >between > >> > >> the > >> > >> > > > two > >> > >> > > > > configures other than debugging. > >> > >> > > > > Mark > >> > >> > > > > >> > >> > > > The log shows that you are configuring a p4est commit > >(3d3e1) > >> > >that is > >> > >> > > > before the one I pushed specifically to avoid the fortran > >> > >> > > > configuration error (f54bb3). Please clear the git.p4est > >> > >directory, > >> > >> > > > and confirm that you are configuring with the current > >'petsc' > >> > >branch > >> > >> > > > of p4est (`grep 'checking Point version' configure.log` > >should > >> > >show > >> > >> > > > X.XXX-a9f22). > >> > >> > > > > >> > >> > > > Cheers, > >> > >> > > > Toby > >> > >> > > > > >> > >> > > >> > >> > >> > >> > >> > > >> > > >> > >> > >

1 0

Re: [petsc-dev] p4est configure error
by Tobin Isaac 07 Jul '16

07 Jul '16

Interesting, you'd think that --disable-shared would be all that matters. Could you please send that configure.log for comparison? On July 7, 2016 5:14:13 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: >Well, this did not work as you suspected ... FYI, it seems to work >with-debugging=0. > >On Thu, Jul 7, 2016 at 11:13 PM, Satish Balay <balay(a)mcs.anl.gov> >wrote: > >> >> >> >>>>>>> >> /bin/sh ./libtool --tag=CC --mode=link cc -no-ipo -g -O0 -o >> libb64/sc_b64enc libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la >-lgomp >> libtool: link: cc -no-ipo -g -O0 -o libb64/sc_b64enc >> libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a >> /opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so -lrt -ldl -Wl,-rpath >> -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 -Wl,-rpath >> -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 >> <<<<<<< >> >> For some reason libtool is converting "-lgomp" into >> "/opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so" - and giving an ld >error. >> >> On my linux box - I see: >> >>>>>>> >> /bin/sh ./libtool --tag=CC --mode=link mpicc -g3 -o >libb64/sc_b64enc >> libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la -lgomp -lpthread -lz >-lm >> libtool: link: mpicc -g3 -o libb64/sc_b64enc >> libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a -lgomp >-lpthread -lz >> -lm >> <<<<<< >> >> I don't really understand libtool - or this error.. >> >> Satish >> >> On Thu, 7 Jul 2016, Tobin Isaac wrote: >> >> > Nope, different error: p4est autotools found an openmp library and >tried >> to link it, but there's a shared/static mismatch. I'll try to get to >the >> bottom of this. >> > >> > >> > On July 7, 2016 3:27:23 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: >> > >I nuked and ran this twice: >> > > >> > >1013 rm -fr arch-xc30-dbg64-intel >> > > 1014 ../arch-xc30-dbg64-intel.py >> > > 1015 h >> > > 1016 ../arch-xc30-dbg64-intel.py >> > > >> > >Same error. >> > > >> > > >> > >On Thu, Jul 7, 2016 at 9:36 PM, Satish Balay <balay(a)mcs.anl.gov> >wrote: >> > > >> > >> perhaps configure was not rerun - so a stale p4est was being >used.. >> > >> >> > >> Satish >> > >> >> > >> On Thu, 7 Jul 2016, Tobin Isaac wrote: >> > >> >> > >> > p4est.py automatically pulls from whatever p4est branch I call >> > >'petsc' >> > >> > in my repo, so I don't see how this problem persists if you >really >> > >> > nuked it. >> > >> > >> > >> > - Did you nuke the right directory? >> > >> > - Did you send me the right configure.log? >> > >> > - Is the new failure the same (the same stale p4est commit is >being >> > >> > used)? >> > >> > >> > >> > On Thu, Jul 07, 2016 at 08:33:57PM +0200, Mark Adams wrote: >> > >> > > It sounds like I have not merged your fix. Should I pull >from >> > >master? >> > >> > > >> > >> > > I have nuked this many times. >> > >> > > >> > >> > > On Thu, Jul 7, 2016 at 4:26 PM, Tobin Isaac ><tisaac(a)uchicago.edu> >> > >> wrote: >> > >> > > >> > >> > > > >> > >> > > > On Thu, Jul 07, 2016 at 03:16:40PM +0200, Mark Adams >wrote: >> > >> > > > > p4est on Edison configures in w/o debugging, although I >have >> > >to run >> > >> > > > > configure twice. >> > >> > > > > But with debugging it fails. I can not see any >difference >> > >between >> > >> the >> > >> > > > two >> > >> > > > > configures other than debugging. >> > >> > > > > Mark >> > >> > > > >> > >> > > > The log shows that you are configuring a p4est commit >(3d3e1) >> > >that is >> > >> > > > before the one I pushed specifically to avoid the fortran >> > >> > > > configuration error (f54bb3). Please clear the git.p4est >> > >directory, >> > >> > > > and confirm that you are configuring with the current >'petsc' >> > >branch >> > >> > > > of p4est (`grep 'checking Point version' configure.log` >should >> > >show >> > >> > > > X.XXX-a9f22). >> > >> > > > >> > >> > > > Cheers, >> > >> > > > Toby >> > >> > > > >> > >> > >> > >> >> > >> >> > >> > >> >>

1 0

Re: [petsc-dev] p4est configure error
by Mark Adams 07 Jul '16

07 Jul '16

Well, this did not work as you suspected ... FYI, it seems to work with-debugging=0. On Thu, Jul 7, 2016 at 11:13 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > >>>>>>> > /bin/sh ./libtool --tag=CC --mode=link cc -no-ipo -g -O0 -o > libb64/sc_b64enc libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la -lgomp > libtool: link: cc -no-ipo -g -O0 -o libb64/sc_b64enc > libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a > /opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so -lrt -ldl -Wl,-rpath > -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 -Wl,-rpath > -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 > <<<<<<< > > For some reason libtool is converting "-lgomp" into > "/opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so" - and giving an ld error. > > On my linux box - I see: > >>>>>>> > /bin/sh ./libtool --tag=CC --mode=link mpicc -g3 -o libb64/sc_b64enc > libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la -lgomp -lpthread -lz -lm > libtool: link: mpicc -g3 -o libb64/sc_b64enc > libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a -lgomp -lpthread -lz > -lm > <<<<<< > > I don't really understand libtool - or this error.. > > Satish > > On Thu, 7 Jul 2016, Tobin Isaac wrote: > > > Nope, different error: p4est autotools found an openmp library and tried > to link it, but there's a shared/static mismatch. I'll try to get to the > bottom of this. > > > > > > On July 7, 2016 3:27:23 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: > > >I nuked and ran this twice: > > > > > >1013 rm -fr arch-xc30-dbg64-intel > > > 1014 ../arch-xc30-dbg64-intel.py > > > 1015 h > > > 1016 ../arch-xc30-dbg64-intel.py > > > > > >Same error. > > > > > > > > >On Thu, Jul 7, 2016 at 9:36 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > > >> perhaps configure was not rerun - so a stale p4est was being used.. > > >> > > >> Satish > > >> > > >> On Thu, 7 Jul 2016, Tobin Isaac wrote: > > >> > > >> > p4est.py automatically pulls from whatever p4est branch I call > > >'petsc' > > >> > in my repo, so I don't see how this problem persists if you really > > >> > nuked it. > > >> > > > >> > - Did you nuke the right directory? > > >> > - Did you send me the right configure.log? > > >> > - Is the new failure the same (the same stale p4est commit is being > > >> > used)? > > >> > > > >> > On Thu, Jul 07, 2016 at 08:33:57PM +0200, Mark Adams wrote: > > >> > > It sounds like I have not merged your fix. Should I pull from > > >master? > > >> > > > > >> > > I have nuked this many times. > > >> > > > > >> > > On Thu, Jul 7, 2016 at 4:26 PM, Tobin Isaac <tisaac(a)uchicago.edu> > > >> wrote: > > >> > > > > >> > > > > > >> > > > On Thu, Jul 07, 2016 at 03:16:40PM +0200, Mark Adams wrote: > > >> > > > > p4est on Edison configures in w/o debugging, although I have > > >to run > > >> > > > > configure twice. > > >> > > > > But with debugging it fails. I can not see any difference > > >between > > >> the > > >> > > > two > > >> > > > > configures other than debugging. > > >> > > > > Mark > > >> > > > > > >> > > > The log shows that you are configuring a p4est commit (3d3e1) > > >that is > > >> > > > before the one I pushed specifically to avoid the fortran > > >> > > > configuration error (f54bb3). Please clear the git.p4est > > >directory, > > >> > > > and confirm that you are configuring with the current 'petsc' > > >branch > > >> > > > of p4est (`grep 'checking Point version' configure.log` should > > >show > > >> > > > X.XXX-a9f22). > > >> > > > > > >> > > > Cheers, > > >> > > > Toby > > >> > > > > > >> > > > >> > > >> > > > > > >

1 0

Re: [petsc-dev] p4est configure error
by Satish Balay 07 Jul '16

07 Jul '16

>>>>>>> /bin/sh ./libtool --tag=CC --mode=link cc -no-ipo -g -O0 -o libb64/sc_b64enc libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la -lgomp libtool: link: cc -no-ipo -g -O0 -o libb64/sc_b64enc libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a /opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so -lrt -ldl -Wl,-rpath -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 -Wl,-rpath -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 <<<<<<< For some reason libtool is converting "-lgomp" into "/opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so" - and giving an ld error. On my linux box - I see: >>>>>>> /bin/sh ./libtool --tag=CC --mode=link mpicc -g3 -o libb64/sc_b64enc libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la -lgomp -lpthread -lz -lm libtool: link: mpicc -g3 -o libb64/sc_b64enc libb64/libb64_sc_b64enc-b64enc.o ./src/.libs/libsc.a -lgomp -lpthread -lz -lm <<<<<< I don't really understand libtool - or this error.. Satish On Thu, 7 Jul 2016, Tobin Isaac wrote: > Nope, different error: p4est autotools found an openmp library and tried to link it, but there's a shared/static mismatch. I'll try to get to the bottom of this. > > > On July 7, 2016 3:27:23 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: > >I nuked and ran this twice: > > > >1013 rm -fr arch-xc30-dbg64-intel > > 1014 ../arch-xc30-dbg64-intel.py > > 1015 h > > 1016 ../arch-xc30-dbg64-intel.py > > > >Same error. > > > > > >On Thu, Jul 7, 2016 at 9:36 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > >> perhaps configure was not rerun - so a stale p4est was being used.. > >> > >> Satish > >> > >> On Thu, 7 Jul 2016, Tobin Isaac wrote: > >> > >> > p4est.py automatically pulls from whatever p4est branch I call > >'petsc' > >> > in my repo, so I don't see how this problem persists if you really > >> > nuked it. > >> > > >> > - Did you nuke the right directory? > >> > - Did you send me the right configure.log? > >> > - Is the new failure the same (the same stale p4est commit is being > >> > used)? > >> > > >> > On Thu, Jul 07, 2016 at 08:33:57PM +0200, Mark Adams wrote: > >> > > It sounds like I have not merged your fix. Should I pull from > >master? > >> > > > >> > > I have nuked this many times. > >> > > > >> > > On Thu, Jul 7, 2016 at 4:26 PM, Tobin Isaac <tisaac(a)uchicago.edu> > >> wrote: > >> > > > >> > > > > >> > > > On Thu, Jul 07, 2016 at 03:16:40PM +0200, Mark Adams wrote: > >> > > > > p4est on Edison configures in w/o debugging, although I have > >to run > >> > > > > configure twice. > >> > > > > But with debugging it fails. I can not see any difference > >between > >> the > >> > > > two > >> > > > > configures other than debugging. > >> > > > > Mark > >> > > > > >> > > > The log shows that you are configuring a p4est commit (3d3e1) > >that is > >> > > > before the one I pushed specifically to avoid the fortran > >> > > > configuration error (f54bb3). Please clear the git.p4est > >directory, > >> > > > and confirm that you are configuring with the current 'petsc' > >branch > >> > > > of p4est (`grep 'checking Point version' configure.log` should > >show > >> > > > X.XXX-a9f22). > >> > > > > >> > > > Cheers, > >> > > > Toby > >> > > > > >> > > >> > >> > >

1 0

Re: [petsc-dev] p4est configure error
by Tobin Isaac 07 Jul '16

07 Jul '16

Nope, different error: p4est autotools found an openmp library and tried to link it, but there's a shared/static mismatch. I'll try to get to the bottom of this. On July 7, 2016 3:27:23 PM CDT, Mark Adams <mfadams(a)lbl.gov> wrote: >I nuked and ran this twice: > >1013 rm -fr arch-xc30-dbg64-intel > 1014 ../arch-xc30-dbg64-intel.py > 1015 h > 1016 ../arch-xc30-dbg64-intel.py > >Same error. > > >On Thu, Jul 7, 2016 at 9:36 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > >> perhaps configure was not rerun - so a stale p4est was being used.. >> >> Satish >> >> On Thu, 7 Jul 2016, Tobin Isaac wrote: >> >> > p4est.py automatically pulls from whatever p4est branch I call >'petsc' >> > in my repo, so I don't see how this problem persists if you really >> > nuked it. >> > >> > - Did you nuke the right directory? >> > - Did you send me the right configure.log? >> > - Is the new failure the same (the same stale p4est commit is being >> > used)? >> > >> > On Thu, Jul 07, 2016 at 08:33:57PM +0200, Mark Adams wrote: >> > > It sounds like I have not merged your fix. Should I pull from >master? >> > > >> > > I have nuked this many times. >> > > >> > > On Thu, Jul 7, 2016 at 4:26 PM, Tobin Isaac <tisaac(a)uchicago.edu> >> wrote: >> > > >> > > > >> > > > On Thu, Jul 07, 2016 at 03:16:40PM +0200, Mark Adams wrote: >> > > > > p4est on Edison configures in w/o debugging, although I have >to run >> > > > > configure twice. >> > > > > But with debugging it fails. I can not see any difference >between >> the >> > > > two >> > > > > configures other than debugging. >> > > > > Mark >> > > > >> > > > The log shows that you are configuring a p4est commit (3d3e1) >that is >> > > > before the one I pushed specifically to avoid the fortran >> > > > configuration error (f54bb3). Please clear the git.p4est >directory, >> > > > and confirm that you are configuring with the current 'petsc' >branch >> > > > of p4est (`grep 'checking Point version' configure.log` should >show >> > > > X.XXX-a9f22). >> > > > >> > > > Cheers, >> > > > Toby >> > > > >> > >> >>

1 0