Re: [petsc-dev] GAMG error with MKL

[Smith, Barry F.]

   Jed,

 You could use your same argument to argue PETSc should do "something" to 
help people who have (rightly or wrongly) chosen to code their application in 
High Performance Fortran or any other similar inane parallel programming model.

   Barry



> On Jul 4, 2018, at 11:51 PM, Jed Brown  wrote:
> 
> Matthew Knepley  writes:
> 
>> On Wed, Jul 4, 2018 at 4:51 PM Jeff Hammond  wrote:
>> 
>>> On Wed, Jul 4, 2018 at 6:31 AM Matthew Knepley  wrote:
>>> 
 On Tue, Jul 3, 2018 at 10:32 PM Jeff Hammond 
 wrote:
 
> 
> 
> On Tue, Jul 3, 2018 at 4:35 PM Mark Adams  wrote:
> 
>> On Tue, Jul 3, 2018 at 1:00 PM Richard Tran Mills 
>> wrote:
>> 
>>> Hi Mark,
>>> 
>>> I'm glad to see you trying out the AIJMKL stuff. I think you are the
>>> first person trying to actually use it, so we are probably going to 
>>> expose
>>> some bugs and also some performance issues. My somewhat limited testing 
>>> has
>>> shown that the MKL sparse routines often perform worse than our own
>>> implementations in PETSc.
>>> 
>> 
>> My users just want OpenMP.
>> 
>> 
> 
> Why not just add OpenMP to PETSc? I know certain developers hate it, but
> it is silly to let a principled objection stand in the way of enabling 
> users
> 
 
 "if that would deliver the best performance for NERSC users."
 
 You have answered your own question.
 
>>> 
>>> Please share the results of your experiments that prove OpenMP does not
>>> improve performance for Mark’s users.
>>> 
>> 
>> Oh God. I am supremely uninterested in minutely proving yet again that
>> OpenMP is not better than MPI.
>> There are already countless experiments. One more will not add anything of
>> merit.
> 
> Jeff assumes an absurd null hypothesis, Matt selfishly believes that
> users should modify their code/execution environment to subscribe to a
> more robust and equally performant approach, and the MPI forum abdicates
> by stalling on endpoints.  How do we resolve this?
> 
>>> Also we are not in the habit of fucking up our codebase in order to follow
 some fad.
 
>>> 
>>> If you can’t use OpenMP without messing up your code base, you probably
>>> don’t know how to design software.
>>> 
>> 
>> That is an interesting, if wrong, opinion. It might be your contention that
>> sticking any random paradigm in a library should
>> be alright if its "well designed"? I have never encountered such a
>> well-designed library.
>> 
>> 
>>> I guess if you refuse to use _Pragma because C99 is still a fad for you,
>>> it is harder, but clearly _Complex is tolerated.
>>> 
>> 
>> Yes, littering your code with preprocessor directives improves almost
>> everything. Doing proper resource management
>> using Pragmas, in an environment with several layers of libraries, is a
>> dream.
>> 
>> 
>>> More seriously, you’ve adopted OpenMP hidden behind MKL
>>> 
>> 
>> Nope. We can use MKL with that crap shutoff.
>> 
>> 
>>> so I see no reason why you can’t wrap OpenMP implementations of the PETSc
>>> sparse kernels in a similar manner.
>>> 
>> 
>> We could, its just a colossal waste of time and effort, as well as
>> counterproductive for the codebase :)
> 
> Endpoints either need to become a thing we can depend on or we need a
> solution for users that insist on using threads (even if their decision
> to use threads is objectively bad).  The problem Matt harps on is
> legitimate: OpenMP parallel regions cannot reliably cross module
> boundaries except for embarrassingly parallel operations.  This means
> loop-level omp parallel which significantly increases overhead for small
> problem sizes (e.g., slowing coarse grid solves and strong scaling
> limits).  It can be done and isn't that hard, but the Imperial group
> discarded their branch after observing that it also provided no
> performance benefit.  However, I'm coming around to the idea that PETSc
> should do it so that there is _a_ solution for users that insist on
> using threads in a particular way.  Unless Endpoints become available
> and reliable, in which case we could do it right.

Re: [petsc-dev] GAMG error with MKL

[Mark Adams]

>
>
> Please share the results of your experiments that prove OpenMP does not
> improve performance for Mark’s users.
>

This obviously does not "prove" anything but my users use OpenMP primarily
because they do not distribute their mesh metadata. They can not replicated
the mesh on every core, on large scale problems and shared memory allows
them to survive. They have decided to use threads as opposed to MPI shared
memory. (Not a big deal, once you decide not to use distributed memory the
damage is done and NERSC seems to be OMP centric so they can probably get
better support for OMP than MPI shared memory.)

BTW, PETSc does support OMP, that is what I have been working on testing
for the last few weeks. First with Hypre (numerics are screwed up from an
apparent compiler bug or a race condition of some sort; it fails at higher
levels of optimization), and second with MKL kernels. The numerics are
working with MKL and we are working on packaging this up to deliver to a
user (they will test performance).

Re: [petsc-dev] trying to make MKL work with GAMG

[Mark Adams]

On Wed, Jul 4, 2018 at 1:09 PM Smith, Barry F.  wrote:

>
>
> > On Jul 4, 2018, at 9:40 AM, Mark Adams  wrote:
> >
> > "-mat_seqaij_type seqaijmkl" just worked.
>
> Mark,
>
>   Please clarify. Does this mean you can use -mat_seqaij_type
> seqaijmkl to satisfy all your needs now without changing any code?


Apparently yes. I timed the code and it took much longer with
NUM_OMP_THREADS > 1 (not sure what that is about but not my problem now),
so that tells me that threads were activated.

I want to package up this simple approach and my branch that works
with -mat_type
aijmkl , and let the user analyze each. (So I am not worrying about
performance, I just want correctness).


>
>
>Barry
>
>
> > On Wed, Jul 4, 2018 at 9:44 AM Mark Adams  wrote:
> >
> >
> > On Wed, Jul 4, 2018 at 3:01 AM Richard Tran Mills 
> wrote:
> > Hi Mark,
> >
> > I'd never looked at the code for MatCreateMPIAIJWithSeqAIJ(), but it
> looks like if you are using MPIAIJ matrices but you've set
> "-mat_seqaij_type seqaijmkl",
> >
> > No, I am using -mat_type aijmkl
> >
> > then the "diagonal" portion of the MPIAIJ matrix ends up as a SEQAIJMKL
> instance, but the off-diagonal portion ends up as a plain SEQAIJ when it is
> created with MatCreateSeqAIJWithArrays(). (I have not stepped through this
> with a debugger to verify that this is actually what happens.) So, if we
> want the off-diagonal matrix to also be a SEQAIJMKL, then we either need to
> add some logic after the MatCreateSeqAIJWithArrays() call to check to see
> if a different subtype of SEQAIJ is being used and then convert it to the
> correct type, or we need a variant of MatCreateSeqAIJWithArrays() that will
> honor the subtype of SEQAIJ that we are using. Barry, since you added the
> concept of subtyping for SEQAIJ, what do you prefer?
> >
> > No preference.
> >
> > I note that in some (most?) cases, I think we are OK or even better off
> with the off-diagonal matrix in the MPIAIJ not being a SEQAIJMKL one,
> because the PETSc routines can used the "compressed row" stuff to speed up
> handling the many zero rows that often end up in the off-diagonal, whereas
> the MKL routines cannot.
> >
> >
> > OK , I'll keep that in mind. I pushed a branch with fixes to get my gamg
> tests working (ksp ex56 primarily). I'm going to make a new branch and try
> "-mat_seqaij_type seqaijmkl".
> >
> > Thanks,
> > Mark
> >
> > --Richard
> >
> > On Tue, Jul 3, 2018 at 4:31 PM, Mark Adams  wrote:
> > I have having to fix AIJ methods that don't get the type from the args
> to set created matrix type, so as to keep the MKL typing.
> >
> > I am not sure how to fix this because I don't know to say 'make MPI from
> SEQ' in this method
> >
> > PetscErrorCode MatCreateMPIAIJWithSeqAIJ(MPI_Comm comm,Mat A,Mat B,const
> PetscInt garray[],Mat *mat)
> > {
> >  
> >   ierr = MatCreate(comm,mat);CHKERRQ(ierr);
> >   ierr = MatGetSize(A,,);CHKERRQ(ierr);
> > 
> >   ierr = MatSetSizes(*mat,m,n,PETSC_DECIDE,N);CHKERRQ(ierr);
> >   ierr = MatSetType(*mat,MATMPIAIJ);CHKERRQ(ierr);
> >
> > How should I do this?  Other places in the code I get the type from
> input (MPI) args and set created matrix types accordingly. I could just put
> a switch with an error for any new types that might come along in the
> future ...
> >
> > Mark
> >
>
>

Re: [petsc-dev] GAMG error with MKL

[Tobin Isaac]

On Thu, Jul 05, 2018 at 09:28:16AM -0400, Mark Adams wrote:
> >
> >
> > Please share the results of your experiments that prove OpenMP does not
> > improve performance for Mark’s users.
> >
> 
> This obviously does not "prove" anything but my users use OpenMP primarily
> because they do not distribute their mesh metadata. They can not replicated
> the mesh on every core, on large scale problems and shared memory allows
> them to survive. They have decided to use threads as opposed to MPI shared
> memory. (Not a big deal, once you decide not to use distributed memory the
> damage is done and NERSC seems to be OMP centric so they can probably get
> better support for OMP than MPI shared memory.)

Out of curiosity, is the mesh immutable for a full simulation or adaptive?
If it's immutable, that seems like a poster child for the "private by
default, shared by choice" paradigm.

> BTW, PETSc does support OMP, that is what I have been working on testing
> for the last few weeks. First with Hypre (numerics are screwed up from an
> apparent compiler bug or a race condition of some sort; it fails at higher
> levels of optimization), and second with MKL kernels. The numerics are
> working with MKL and we are working on packaging this up to deliver to a
> user (they will test performance).

Re: [petsc-dev] GAMG error with MKL

[Smith, Barry F.]

> On Jul 5, 2018, at 8:28 AM, Mark Adams  wrote:
> 
> 
> Please share the results of your experiments that prove OpenMP does not 
> improve performance for Mark’s users. 
> 
> This obviously does not "prove" anything but my users use OpenMP primarily 
> because they do not distribute their mesh metadata.

   I.e. my users have decided not to write scalable code. 

> They can not replicated the mesh on every core,
> on large scale problems and shared memory allows them to survive. They have 
> decided to use threads as opposed to MPI shared memory. (Not a big deal, once 
> you decide not to use distributed memory the damage is done and NERSC seems 
> to be OMP centric so they can probably get better support for OMP than MPI 
> shared memory.)
> 
> BTW, PETSc does support OMP, that is what I have been working on testing for 
> the last few weeks. First with Hypre (numerics are screwed up from an 
> apparent compiler bug or a race condition of some sort; it fails at higher 
> levels of optimization), and second with MKL kernels. The numerics are 
> working with MKL and we are working on packaging this up to deliver to a user 
> (they will test performance).
>  

Re: [petsc-dev] GAMG error with MKL

[Mark Adams]

On Thu, Jul 5, 2018 at 12:41 PM Tobin Isaac  wrote:

> On Thu, Jul 05, 2018 at 09:28:16AM -0400, Mark Adams wrote:
> > >
> > >
> > > Please share the results of your experiments that prove OpenMP does not
> > > improve performance for Mark’s users.
> > >
> >
> > This obviously does not "prove" anything but my users use OpenMP
> primarily
> > because they do not distribute their mesh metadata. They can not
> replicated
> > the mesh on every core, on large scale problems and shared memory allows
> > them to survive. They have decided to use threads as opposed to MPI
> shared
> > memory. (Not a big deal, once you decide not to use distributed memory
> the
> > damage is done and NERSC seems to be OMP centric so they can probably get
> > better support for OMP than MPI shared memory.)
>
> Out of curiosity, is the mesh immutable for a full simulation or adaptive?
> If it's immutable, that seems like a poster child for the "private by
> default, shared by choice" paradigm.
>

This is Chombo so it is dynamic.


>
> > BTW, PETSc does support OMP, that is what I have been working on testing
> > for the last few weeks. First with Hypre (numerics are screwed up from an
> > apparent compiler bug or a race condition of some sort; it fails at
> higher
> > levels of optimization), and second with MKL kernels. The numerics are
> > working with MKL and we are working on packaging this up to deliver to a
> > user (they will test performance).
>

Re: [petsc-dev] GAMG error with MKL

[Matthew Knepley]

On Thu, Jul 5, 2018 at 2:04 PM Mark Adams  wrote:

>
>
> On Thu, Jul 5, 2018 at 12:41 PM Tobin Isaac  wrote:
>
>> On Thu, Jul 05, 2018 at 09:28:16AM -0400, Mark Adams wrote:
>> > >
>> > >
>> > > Please share the results of your experiments that prove OpenMP does
>> not
>> > > improve performance for Mark’s users.
>> > >
>> >
>> > This obviously does not "prove" anything but my users use OpenMP
>> primarily
>> > because they do not distribute their mesh metadata. They can not
>> replicated
>> > the mesh on every core, on large scale problems and shared memory allows
>> > them to survive. They have decided to use threads as opposed to MPI
>> shared
>> > memory. (Not a big deal, once you decide not to use distributed memory
>> the
>> > damage is done and NERSC seems to be OMP centric so they can probably
>> get
>> > better support for OMP than MPI shared memory.)
>>
>> Out of curiosity, is the mesh immutable for a full simulation or adaptive?
>> If it's immutable, that seems like a poster child for the "private by
>> default, shared by choice" paradigm.
>>
>
> This is Chombo so it is dynamic.
>

We need more competitors like this :) We need to give more talks advocating
serial meshes,
unstable algorithms, OpenMP, and templates.

   Matt


>
>

>> > BTW, PETSc does support OMP, that is what I have been working on testing
>> > for the last few weeks. First with Hypre (numerics are screwed up from
>> an
>> > apparent compiler bug or a race condition of some sort; it fails at
>> higher
>> > levels of optimization), and second with MKL kernels. The numerics are
>> > working with MKL and we are working on packaging this up to deliver to a
>> > user (they will test performance).
>>
>

-- 
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/ 

[petsc-dev] My configure is non-working again because of CMake

[Matthew Knepley]

Now we require a fully C++11 compliant compiler, or the CMake build dies.
This is crazy.

   Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ 

Re: [petsc-dev] My configure is non-working again because of CMake

[Smith, Barry F.]

  I complained about this a couple of weeks ago and no one (including you) 
responded. It seems nuts to me, do we really need that new a version of cmake?

   Barry


> On Jul 5, 2018, at 5:07 PM, Matthew Knepley  wrote:
> 
> Now we require a fully C++11 compliant compiler, or the CMake build dies. 
> This is crazy.
> 
>Matt
> 
> -- 
> What most experimenters take for granted before they begin their experiments 
> is infinitely more interesting than any results to which their experiments 
> lead.
> -- Norbert Wiener
> 
> https://www.cse.buffalo.edu/~knepley/

Re: [petsc-dev] My configure is non-working again because of CMake

[Matthew Knepley]

On Thu, Jul 5, 2018 at 5:18 PM Satish Balay  wrote:

> Logs?
>

I can send it, but its really straightforward. The clang++/g++ on my box
(which I will not upgrade because the latest MacOS is crazy)
does not have the  header, and thus is not compliant C++11.


> And what version of cmake does not require C++11 compliant compiler? We
> could downgrade to that..
>

I reverted back to 3.7 which worked, so somewhere in between 3.7 and 3.11
they made the change.

  Thanks,

Matt


> Satish
>
> On Thu, 5 Jul 2018, Matthew Knepley wrote:
>
> > Now we require a fully C++11 compliant compiler, or the CMake build dies.
> > This is crazy.
> >
> >Matt
> >
> >
>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ 

Re: [petsc-dev] My configure is non-working again because of CMake

[Jed Brown]

Matt, you're gonna have to upgrade your compiler eventually.  You can
postpone it a few months or perhaps a year.

Satish Balay  writes:

> Well - can you find the version between 3.7 and 3.11 that works on your box?
>
> The previous update was done due to:
> https://bitbucket.org/petsc/petsc/commits/e5b329dd4ac
>
> No point in going back to having old issues..
>
> Satish
>
> On Thu, 5 Jul 2018, Matthew Knepley wrote:
>
>> On Thu, Jul 5, 2018 at 5:18 PM Satish Balay  wrote:
>> 
>> > Logs?
>> >
>> 
>> I can send it, but its really straightforward. The clang++/g++ on my box
>> (which I will not upgrade because the latest MacOS is crazy)
>> does not have the  header, and thus is not compliant C++11.
>> 
>> 
>> > And what version of cmake does not require C++11 compliant compiler? We
>> > could downgrade to that..
>> >
>> 
>> I reverted back to 3.7 which worked, so somewhere in between 3.7 and 3.11
>> they made the change.
>> 
>>   Thanks,
>> 
>> Matt
>> 
>> 
>> > Satish
>> >
>> > On Thu, 5 Jul 2018, Matthew Knepley wrote:
>> >
>> > > Now we require a fully C++11 compliant compiler, or the CMake build dies.
>> > > This is crazy.
>> > >
>> > >Matt
>> > >
>> > >
>> >
>> >
>> 
>> 

Re: [petsc-dev] My configure is non-working again because of CMake

[Satish Balay]

Well - can you find the version between 3.7 and 3.11 that works on your box?

The previous update was done due to:
https://bitbucket.org/petsc/petsc/commits/e5b329dd4ac

No point in going back to having old issues..

Satish

On Thu, 5 Jul 2018, Matthew Knepley wrote:

> On Thu, Jul 5, 2018 at 5:18 PM Satish Balay  wrote:
> 
> > Logs?
> >
> 
> I can send it, but its really straightforward. The clang++/g++ on my box
> (which I will not upgrade because the latest MacOS is crazy)
> does not have the  header, and thus is not compliant C++11.
> 
> 
> > And what version of cmake does not require C++11 compliant compiler? We
> > could downgrade to that..
> >
> 
> I reverted back to 3.7 which worked, so somewhere in between 3.7 and 3.11
> they made the change.
> 
>   Thanks,
> 
> Matt
> 
> 
> > Satish
> >
> > On Thu, 5 Jul 2018, Matthew Knepley wrote:
> >
> > > Now we require a fully C++11 compliant compiler, or the CMake build dies.
> > > This is crazy.
> > >
> > >Matt
> > >
> > >
> >
> >
> 
> 

Re: [petsc-dev] My configure is non-working again because of CMake

[Matthew Knepley]

On Thu, Jul 5, 2018 at 5:31 PM Satish Balay  wrote:

> Well - can you find the version between 3.7 and 3.11 that works on your
> box?
>

Those bastards do not even have a Changes page. I will have to download
every version and try it.

   Matt


> The previous update was done due to:
> https://bitbucket.org/petsc/petsc/commits/e5b329dd4ac
>
> No point in going back to having old issues..
>
> Satish
>
> On Thu, 5 Jul 2018, Matthew Knepley wrote:
>
> > On Thu, Jul 5, 2018 at 5:18 PM Satish Balay  wrote:
> >
> > > Logs?
> > >
> >
> > I can send it, but its really straightforward. The clang++/g++ on my box
> > (which I will not upgrade because the latest MacOS is crazy)
> > does not have the  header, and thus is not compliant C++11.
> >
> >
> > > And what version of cmake does not require C++11 compliant compiler? We
> > > could downgrade to that..
> > >
> >
> > I reverted back to 3.7 which worked, so somewhere in between 3.7 and 3.11
> > they made the change.
> >
> >   Thanks,
> >
> > Matt
> >
> >
> > > Satish
> > >
> > > On Thu, 5 Jul 2018, Matthew Knepley wrote:
> > >
> > > > Now we require a fully C++11 compliant compiler, or the CMake build
> dies.
> > > > This is crazy.
> > > >
> > > >Matt
> > > >
> > > >
> > >
> > >
> >
> >
>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ 

[petsc-dev] Remove legacy tests?

[Jed Brown]

When can we delete the legacy test system?  Are we currently using it
anywhere?

Re: [petsc-dev] Remove legacy tests?

[Matthew Knepley]

On Thu, Jul 5, 2018 at 5:37 PM Jed Brown  wrote:

> When can we delete the legacy test system?  Are we currently using it
> anywhere?
>

Not I said the fox.

   Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ 

Re: [petsc-dev] Remove legacy tests?

[Satish Balay]

On Thu, 5 Jul 2018, Jed Brown wrote:

> When can we delete the legacy test system?  Are we currently using it
> anywhere?

[Don't know exactly which parts we would delete] - but the new targets
cover ex*[f,f90] type examples - and not anything else.

So all other examples that don't fit this string format still use the
old targets.

Also they are still useful to users [to create their own makefiles] -
as we don't have an equivalent simiple replacement yet..

Satish

Re: [petsc-dev] My configure is non-working again because of CMake

[Satish Balay]

Logs?

And what version of cmake does not require C++11 compliant compiler? We could 
downgrade to that..

Satish

On Thu, 5 Jul 2018, Matthew Knepley wrote:

> Now we require a fully C++11 compliant compiler, or the CMake build dies.
> This is crazy.
> 
>Matt
> 
> 

Re: [petsc-dev] My configure is non-working again because of CMake

[Matthew Knepley]

On Thu, Jul 5, 2018 at 5:36 PM Jed Brown  wrote:

> Matt, you're gonna have to upgrade your compiler eventually.  You can
> postpone it a few months or perhaps a year.
>

In a year, I will buy a new machine.

  Matt


> Satish Balay  writes:
>
> > Well - can you find the version between 3.7 and 3.11 that works on your
> box?
> >
> > The previous update was done due to:
> > https://bitbucket.org/petsc/petsc/commits/e5b329dd4ac
> >
> > No point in going back to having old issues..
> >
> > Satish
> >
> > On Thu, 5 Jul 2018, Matthew Knepley wrote:
> >
> >> On Thu, Jul 5, 2018 at 5:18 PM Satish Balay  wrote:
> >>
> >> > Logs?
> >> >
> >>
> >> I can send it, but its really straightforward. The clang++/g++ on my box
> >> (which I will not upgrade because the latest MacOS is crazy)
> >> does not have the  header, and thus is not compliant
> C++11.
> >>
> >>
> >> > And what version of cmake does not require C++11 compliant compiler?
> We
> >> > could downgrade to that..
> >> >
> >>
> >> I reverted back to 3.7 which worked, so somewhere in between 3.7 and
> 3.11
> >> they made the change.
> >>
> >>   Thanks,
> >>
> >> Matt
> >>
> >>
> >> > Satish
> >> >
> >> > On Thu, 5 Jul 2018, Matthew Knepley wrote:
> >> >
> >> > > Now we require a fully C++11 compliant compiler, or the CMake build
> dies.
> >> > > This is crazy.
> >> > >
> >> > >Matt
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ 

Re: [petsc-dev] My configure is non-working again because of CMake

[Satish Balay]

Can you try the following and see if it works for you

./configure PETSC_ARCH=arch-cmake-test --with-mpi=0 --with-sowing=0 --with-fc=0 
--download-cmake=https://cmake.org/files/v3.9/cmake-3.9.1.tar.gz

Satish


On Thu, 5 Jul 2018, Matthew Knepley wrote:

> On Thu, Jul 5, 2018 at 5:31 PM Satish Balay  wrote:
> 
> > Well - can you find the version between 3.7 and 3.11 that works on your
> > box?
> >
> 
> Those bastards do not even have a Changes page. I will have to download
> every version and try it.
> 
>Matt
> 
> 
> > The previous update was done due to:
> > https://bitbucket.org/petsc/petsc/commits/e5b329dd4ac
> >
> > No point in going back to having old issues..
> >
> > Satish
> >
> > On Thu, 5 Jul 2018, Matthew Knepley wrote:
> >
> > > On Thu, Jul 5, 2018 at 5:18 PM Satish Balay  wrote:
> > >
> > > > Logs?
> > > >
> > >
> > > I can send it, but its really straightforward. The clang++/g++ on my box
> > > (which I will not upgrade because the latest MacOS is crazy)
> > > does not have the  header, and thus is not compliant C++11.
> > >
> > >
> > > > And what version of cmake does not require C++11 compliant compiler? We
> > > > could downgrade to that..
> > > >
> > >
> > > I reverted back to 3.7 which worked, so somewhere in between 3.7 and 3.11
> > > they made the change.
> > >
> > >   Thanks,
> > >
> > > Matt
> > >
> > >
> > > > Satish
> > > >
> > > > On Thu, 5 Jul 2018, Matthew Knepley wrote:
> > > >
> > > > > Now we require a fully C++11 compliant compiler, or the CMake build
> > dies.
> > > > > This is crazy.
> > > > >
> > > > >Matt
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> 
> 

Re: [petsc-dev] Remove legacy tests?

[Satish Balay]

Ok - there is some confusion here.

The test harness does not use targets in
examples/[tests,tutorials]/makefile.

However we want to keep the functionality of us/users compiling
individual examples manually - without going through the test harness.

i.e the following should continue to work:

cd src/ksp/ksp/examples/tutorials
make ex2

On Thu, 5 Jul 2018, Jed Brown wrote:

> Satish Balay  writes:
> 
> > On Thu, 5 Jul 2018, Jed Brown wrote:
> >
> >> When can we delete the legacy test system?  Are we currently using it
> >> anywhere?
> >
> > [Don't know exactly which parts we would delete] - but the new targets
> > cover ex*[f,f90] type examples - and not anything else.
> 
> Which targets are you referring to?  I don't see any build targets in
> the source directories.

ex%f90: etc targets in lib/petsc/conf/test

>  There are a few run targets that I don't
> understand.  We could delete lib/petsc/conf/test and any top-level
> legacy targets.

well lib/petsc/conf/test enables the above feature of 'make ex2'

> 
> > So all other examples that don't fit this string format still use the
> > old targets.
> 
> Where are those?  They evidently aren't part of the nightly tests, thus
> need to be updated.

[With the above context] - I was refering to - say
spectraladjointassimilation, burgers_spectral etc targes in
src/tao/unconstrained/examples/tutorials/makefile

Sure - this is not part of the test harness and nightlybilds.


> > Also they are still useful to users [to create their own makefiles] -
> > as we don't have an equivalent simiple replacement yet..
> 
> I don't mind makefiles sitting in source directories.  They're basically
> just includes and a list of source files right now, and we can remove
> the lists of source files.

They also list dependencies compile dependencies [for the above purpose]

Satish

Re: [petsc-dev] Remove legacy tests?

[Jed Brown]

Satish Balay  writes:

> On Thu, 5 Jul 2018, Jed Brown wrote:
>
>> When can we delete the legacy test system?  Are we currently using it
>> anywhere?
>
> [Don't know exactly which parts we would delete] - but the new targets
> cover ex*[f,f90] type examples - and not anything else.

Which targets are you referring to?  I don't see any build targets in
the source directories.  There are a few run targets that I don't
understand.  We could delete lib/petsc/conf/test and any top-level
legacy targets.

> So all other examples that don't fit this string format still use the
> old targets.

Where are those?  They evidently aren't part of the nightly tests, thus
need to be updated.

> Also they are still useful to users [to create their own makefiles] -
> as we don't have an equivalent simiple replacement yet..

I don't mind makefiles sitting in source directories.  They're basically
just includes and a list of source files right now, and we can remove
the lists of source files.

Re: [petsc-dev] Remove legacy tests?

[Matthew Knepley]

On Thu, Jul 5, 2018 at 6:07 PM Satish Balay  wrote:

> Ok - there is some confusion here.
>
> The test harness does not use targets in
> examples/[tests,tutorials]/makefile.
>
> However we want to keep the functionality of us/users compiling
> individual examples manually - without going through the test harness.
>
> i.e the following should continue to work:
>
> cd src/ksp/ksp/examples/tutorials
> make ex2
>

I believe that only relies on

  a) Having compile targets, or a generic example compile target

  b) the compile rules in the toplevel makefiles

I do not think Jed objects to either.

   Matt


> On Thu, 5 Jul 2018, Jed Brown wrote:
>
> > Satish Balay  writes:
> >
> > > On Thu, 5 Jul 2018, Jed Brown wrote:
> > >
> > >> When can we delete the legacy test system?  Are we currently using it
> > >> anywhere?
> > >
> > > [Don't know exactly which parts we would delete] - but the new targets
> > > cover ex*[f,f90] type examples - and not anything else.
> >
> > Which targets are you referring to?  I don't see any build targets in
> > the source directories.
>
> ex%f90: etc targets in lib/petsc/conf/test
>
> >  There are a few run targets that I don't
> > understand.  We could delete lib/petsc/conf/test and any top-level
> > legacy targets.
>
> well lib/petsc/conf/test enables the above feature of 'make ex2'
>
> >
> > > So all other examples that don't fit this string format still use the
> > > old targets.
> >
> > Where are those?  They evidently aren't part of the nightly tests, thus
> > need to be updated.
>
> [With the above context] - I was refering to - say
> spectraladjointassimilation, burgers_spectral etc targes in
> src/tao/unconstrained/examples/tutorials/makefile
>
> Sure - this is not part of the test harness and nightlybilds.
>
>
> > > Also they are still useful to users [to create their own makefiles] -
> > > as we don't have an equivalent simiple replacement yet..
> >
> > I don't mind makefiles sitting in source directories.  They're basically
> > just includes and a list of source files right now, and we can remove
> > the lists of source files.
>
> They also list dependencies compile dependencies [for the above purpose]
>
> Satish
>


-- 
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/ 

Re: [petsc-dev] Remove legacy tests?

[Smith, Barry F.]

> On Jul 5, 2018, at 5:36 PM, Jed Brown  wrote:
> 
> When can we delete the legacy test system?  Are we currently using it
> anywhere?

  Make test currently requires the test include file

   Barry

Re: [petsc-dev] Error compiling PETSc on Windows

[Satish Balay]

A few additional notes:

On Thu, 5 Jul 2018, Satish Balay wrote:

> >
> Using configure Options: 
> --prefix=/cygdrive/c/installed/petsc_git-intel-debug/ 
> --PETSC_DIR=/cygdrive/c/sources/petsc --PETSC_ARCH=windows-intel-debug 
> --with-cc="win32fe cl" --with-fc="win32fe ifort" 
> --with-mpi-include="[/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mpi/intel64/include]" 
> --with-mpi-lib="[/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mpi/intel64/lib/release_mt/impi.lib]"

>  --with-openmp=1

I don't think this option does anything [on windows]

> --with-parmetis-lib=/cygdrive/c/installed/parmetis/lib/parmetis.lib 
> --with-parmetis-include=/cygdrive/c/installed/parmetis/include 
> --with-metis-lib=/cygdrive/c/installed/parmetis/lib/metis.lib 
> --with-metis-include=/cygdrive/c/installed/parmetis/include 
> --with-zoltan-include=/cygdrive/c/installed/zoltan/include 
> --with-zoltan-lib=/cygdrive/c/installed/zoltan/lib/zoltan.lib 
> --with-hypre-include=/cygdrive/c/installed/hypre/include 
> --with-hypre-lib=/cygdrive/c/installed/hypre/lib/HYPRE.lib 
> --with-blaslapack-lib="[/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_lp64.lib,/cygdrive/c/Program
>  Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_core.lib,/cygdrive/c/Program
>  Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_thread.lib]"

>  --with-scalapack-include="/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/include" 
> --with-scalapack-lib="[/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_scalapack_lp64.lib,/cygdrive/c/Program
>  Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_blacs_intelmpi_lp64.lib]"

PETSc does not use scalapack or blacs. They are dependencies for MUMPS [which 
petsc has an interface to]

> --with-shared-libraries=0 

> -LIBS=""/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_lp64.lib"
>  "/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_thread.lib"
>  "/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64//mkl_core.lib"
>  "/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_scalapack_lp64.lib"
>  "/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_blacs_intelmpi_lp64.lib"
>  libiomp5md.lib"

I'm not sure why you are having to respecify MKL via LIBS option.

Also with PETSc MPI usage - its best to use sequential MKL - and not threaded 
MKL - for eg:

> --with-blaslapack-lib='-L/cygdrive/c/PROGRA~2/INTELS~1/COMPIL~2/windows/mkl/lib/intel64
>  mkl_intel_lp64_dll.lib mkl_sequential_dll.lib mkl_core_dll.lib'

> > mhypre.c
> > C:\sources\petsc\src\mat\impls\hypre\mhypre.c(1453): warning C4002: too 
> > many actual parameters for macro 'hypre_TFree'

You can switch to the compatible version of hypre - or fix revert the code 
change..

https://bitbucket.org/petsc/petsc/commits/e6de09342ce9c4562cc062ff2c1bac4bd956bda0

Satish

Re: [petsc-dev] Remove legacy tests?

[Jose E. Roman]

SLEPc still uses the legacy test system. I have not had time to move to the new 
test harness.
Jose


> El 6 jul 2018, a las 2:42, Smith, Barry F.  escribió:
> 
> 
> 
>> On Jul 5, 2018, at 5:36 PM, Jed Brown  wrote:
>> 
>> When can we delete the legacy test system?  Are we currently using it
>> anywhere?
> 
>  Make test currently requires the test include file
> 
>   Barry
> 
> 

Re: [petsc-dev] Error compiling PETSc on Windows

[Smith, Barry F.]

  Try running

make test

if that works then the build is ok; it could be the warnings during the compile 
triggered the message at the end about the failed build.

   Barry


> On Jul 5, 2018, at 7:21 PM, Hector E Barrios Molano  
> wrote:
> 
> Hi PETSc Experts,
> 
> I am compiling PETSc from git repository on Windows 7. I am getting the 
> following error, attached you will find make.log file:
> 
>   CC windows-intel-debug/obj/tao/leastsquares/impls/pounders/gqt.o
> gqt.c
>   FC windows-intel-debug/obj/dm/f90-mod/petscdmplexmod.o
>   FC windows-intel-debug/obj/ksp/f90-mod/petsckspmod.o
>   FC windows-intel-debug/obj/snes/f90-mod/petscsnesmod.o
>   FC windows-intel-debug/obj/ts/f90-mod/petsctsmod.o
>   FC windows-intel-debug/obj/tao/f90-mod/petsctaomod.o
>   AR windows-intel-debug/lib/libpetsc.lib
>   RANLIB windows-intel-debug/lib/libpetsc.lib
> make[2]: Leaving directory '/cygdrive/c/sources/petsc'
> make[1]: Leaving directory '/cygdrive/c/sources/petsc'
> **ERROR*
>   Error during compile, check windows-intel-debug/lib/petsc/conf/make.log
>   Send it and windows-intel-debug/lib/petsc/conf/configure.log to 
> petsc-ma...@mcs.anl.gov
> 
> make: *** [makefile:36: all] Error 1
> 
> 
> Here is the configure command I am using:
> 
> ./configure --prefix=/cygdrive/c/installed/petsc_git-intel-debug/ 
> --PETSC_DIR=/cygdrive/c/sources/petsc --PETSC_ARCH=windows-intel-debug 
> --with-cc='win32fe cl' --with-fc='win32fe ifort' 
> --with-mpi-include=["/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mpi/intel64/include"] 
> --with-mpi-lib=["/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mpi/intel64/lib/release_mt/impi.lib"]
>  --with-openmp=1 
> --with-parmetis-lib=/cygdrive/c/installed/parmetis/lib/parmetis.lib 
> --with-parmetis-include=/cygdrive/c/installed/parmetis/include 
> --with-metis-lib=/cygdrive/c/installed/parmetis/lib/metis.lib 
> --with-metis-include=/cygdrive/c/installed/parmetis/include 
> --with-zoltan-include=/cygdrive/c/installed/zoltan/include 
> --with-zoltan-lib=/cygdrive/c/installed/zoltan/lib/zoltan.lib 
> --with-hypre-include=/cygdrive/c/installed/hypre/include 
> --with-hypre-lib=/cygdrive/c/installed/hypre/lib/HYPRE.lib 
> --with-blas-lapack-lib=["/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_lp64.lib","/cygdrive/c/Program
>  Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_core.lib","/cygdrive/c/Program
>  Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_thread.lib"]
>  --with-scalapack-include="/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/include" 
> --with-scalapack-lib=["/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_scalapack_lp64.lib","/cygdrive/c/Program
>  Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_blacs_intelmpi_lp64.lib"]
>  --with-shared-libraries=0 -LIBS="\"/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_lp64.lib\"
>  \"/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_thread.lib\"
>  \"/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64//mkl_core.lib\"
>  \"/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_scalapack_lp64.lib\"
>  \"/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_blacs_intelmpi_lp64.lib\"
>  libiomp5md.lib"
> 
> What could be the problem?
> 
> Thanks,
> 
> Hector
> 
> 
> 

Re: [petsc-dev] Error compiling PETSc on Windows

[Satish Balay]

The primary error is:
>>>
make[1]: Leaving directory '/cygdrive/c/sources/petsc'
^[[1;31m**ERROR*
  Error during compile, check windows-intel-debug/lib/petsc/conf/make.log
  Send it and windows-intel-debug/lib/petsc/conf/configure.log to 
petsc-ma...@mcs.anl.gov
^[[0;39m^[[0;49m
<

The tirgger for this is:


/usr/bin/sh: -c: line 0: syntax error near unexpected token `('
/usr/bin/sh: -c: line 0: `echo "Using libraries: 
-L/cygdrive/c/sources/petsc/windows-intel-debug/lib /cygdrive/c/Program\ Files\ 
\(x86\)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_scalapack_lp64.lib
 /cygdrive/c/Program\ Files\ 
\(x86\)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_blacs_intelmpi_lp64.lib
 /cygdrive/c/installed/hypre/lib/HYPRE.lib /cygdrive/c/Program\ Files\ 
\(x86\)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_lp64.lib
 /cygdrive/c/Program\ Files\ 
\(x86\)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_core.lib
 /cygdrive/c/Program\ Files\ 
\(x86\)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_thread.lib
 /cygdrive/c/installed/zoltan/lib/zoltan.lib 
/cygdrive/c/installed/parmetis/lib/parmetis.lib 
/cygdrive/c/installed/parmetis/lib/metis.lib /cygdrive/c/Program\ Files\ 
\(x86\)/IntelSWTools/compilers_and_libraries_2018/windows/mpi/intel64/lib/release_mt/impi.lib
 Gdi32.lib User32.lib Advapi32.lib Kernel32.lib Ws2_32.lib libiomp5md.lib 
-lpetsc -l"/cygdrive/c/Program -lFiles 
-l(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_lp64.lib"
 -l"/cygdrive/c/Program -lFiles 
-l(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_thread.lib"
 -l"/cygdrive/c/Program -lFiles 
-l(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64//mkl_core.lib"
 -l"/cygdrive/c/Program -lFiles 
-l(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_scalapack_lp64.lib"
 -l"/cygdrive/c/Program -lFiles 
-l(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_blacs_intelmpi_lp64.lib""'
make[1]: [makefile:110: info] Error 1 (ignored)
<<<

The line that got executed is:

-@echo "Using libraries: ${PETSC_LIB}"

You can ignore this error. Its strange that the contents of PETSC_LIB is 
causing a shell error.

Your configure line is a bit compilcated.

>
Using configure Options: --prefix=/cygdrive/c/installed/petsc_git-intel-debug/ 
--PETSC_DIR=/cygdrive/c/sources/petsc --PETSC_ARCH=windows-intel-debug 
--with-cc="win32fe cl" --with-fc="win32fe ifort" 
--with-mpi-include="[/cygdrive/c/Program Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mpi/intel64/include]" 
--with-mpi-lib="[/cygdrive/c/Program Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mpi/intel64/lib/release_mt/impi.lib]"
 --with-openmp=1 
--with-parmetis-lib=/cygdrive/c/installed/parmetis/lib/parmetis.lib 
--with-parmetis-include=/cygdrive/c/installed/parmetis/include 
--with-metis-lib=/cygdrive/c/installed/parmetis/lib/metis.lib 
--with-metis-include=/cygdrive/c/installed/parmetis/include 
--with-zoltan-include=/cygdrive/c/installed/zoltan/include 
--with-zoltan-lib=/cygdrive/c/installed/zoltan/lib/zoltan.lib 
--with-hypre-include=/cygdrive/c/installed/hypre/include 
--with-hypre-lib=/cygdrive/c/installed/hypre/lib/HYPRE.lib 
--with-blaslapack-lib="[/cygdrive/c/Program Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_lp64.lib,/cygdrive/c/Program
 Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_core.lib,/cygdrive/c/Program
 Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_thread.lib]"
 --with-scalapack-include="/cygdrive/c/Program Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/include" 
--with-scalapack-lib="[/cygdrive/c/Program Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_scalapack_lp64.lib,/cygdrive/c/Program
 Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_blacs_intelmpi_lp64.lib]"
 --with-shared-libraries=0 -LIBS=""/cygdrive/c/Program Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_lp64.lib"
 "/cygdrive/c/Program Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_thread.lib"
 "/cygdrive/c/Program Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64//mkl_core.lib"
 "/cygdrive/c/Program Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_scalapack_lp64.lib"
 "/cygdrive/c/Program Files 
(x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_blacs_intelmpi_lp64.lib"
 

Re: [petsc-dev] Error compiling PETSc on Windows

[Smith, Barry F.]

  This is not the cause of your problem but you have the wrong version of hypre 
installed for the version of PETSc.

  CC windows-intel-debug/obj/mat/impls/hypre/mhypre.o
mhypre.c
C:\sources\petsc\src\mat\impls\hypre\mhypre.c(1453): warning C4002: too many 
actual parameters for macro 'hypre_TFree'

You need to use the same version as is listed in 
config/BuildSystem/config/packages/hypre.py

If you run code that uses hypre it will crash.

   Barry





> On Jul 5, 2018, at 7:21 PM, Hector E Barrios Molano  
> wrote:
> 
> Hi PETSc Experts,
> 
> I am compiling PETSc from git repository on Windows 7. I am getting the 
> following error, attached you will find make.log file:
> 
>   CC windows-intel-debug/obj/tao/leastsquares/impls/pounders/gqt.o
> gqt.c
>   FC windows-intel-debug/obj/dm/f90-mod/petscdmplexmod.o
>   FC windows-intel-debug/obj/ksp/f90-mod/petsckspmod.o
>   FC windows-intel-debug/obj/snes/f90-mod/petscsnesmod.o
>   FC windows-intel-debug/obj/ts/f90-mod/petsctsmod.o
>   FC windows-intel-debug/obj/tao/f90-mod/petsctaomod.o
>   AR windows-intel-debug/lib/libpetsc.lib
>   RANLIB windows-intel-debug/lib/libpetsc.lib
> make[2]: Leaving directory '/cygdrive/c/sources/petsc'
> make[1]: Leaving directory '/cygdrive/c/sources/petsc'
> **ERROR*
>   Error during compile, check windows-intel-debug/lib/petsc/conf/make.log
>   Send it and windows-intel-debug/lib/petsc/conf/configure.log to 
> petsc-ma...@mcs.anl.gov
> 
> make: *** [makefile:36: all] Error 1
> 
> 
> Here is the configure command I am using:
> 
> ./configure --prefix=/cygdrive/c/installed/petsc_git-intel-debug/ 
> --PETSC_DIR=/cygdrive/c/sources/petsc --PETSC_ARCH=windows-intel-debug 
> --with-cc='win32fe cl' --with-fc='win32fe ifort' 
> --with-mpi-include=["/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mpi/intel64/include"] 
> --with-mpi-lib=["/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mpi/intel64/lib/release_mt/impi.lib"]
>  --with-openmp=1 
> --with-parmetis-lib=/cygdrive/c/installed/parmetis/lib/parmetis.lib 
> --with-parmetis-include=/cygdrive/c/installed/parmetis/include 
> --with-metis-lib=/cygdrive/c/installed/parmetis/lib/metis.lib 
> --with-metis-include=/cygdrive/c/installed/parmetis/include 
> --with-zoltan-include=/cygdrive/c/installed/zoltan/include 
> --with-zoltan-lib=/cygdrive/c/installed/zoltan/lib/zoltan.lib 
> --with-hypre-include=/cygdrive/c/installed/hypre/include 
> --with-hypre-lib=/cygdrive/c/installed/hypre/lib/HYPRE.lib 
> --with-blas-lapack-lib=["/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_lp64.lib","/cygdrive/c/Program
>  Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_core.lib","/cygdrive/c/Program
>  Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_thread.lib"]
>  --with-scalapack-include="/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/include" 
> --with-scalapack-lib=["/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_scalapack_lp64.lib","/cygdrive/c/Program
>  Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_blacs_intelmpi_lp64.lib"]
>  --with-shared-libraries=0 -LIBS="\"/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_lp64.lib\"
>  \"/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_intel_thread.lib\"
>  \"/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64//mkl_core.lib\"
>  \"/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_scalapack_lp64.lib\"
>  \"/cygdrive/c/Program Files 
> (x86)/IntelSWTools/compilers_and_libraries_2018/windows/mkl/lib/intel64/mkl_blacs_intelmpi_lp64.lib\"
>  libiomp5md.lib"
> 
> What could be the problem?
> 
> Thanks,
> 
> Hector
> 
> 
> 

Re: [petsc-dev] My configure is non-working again because of CMake

[Matthew Knepley]

On Thu, Jul 5, 2018 at 5:45 PM Satish Balay  wrote:

> Can you try the following and see if it works for you
>
> ./configure PETSC_ARCH=arch-cmake-test --with-mpi=0 --with-sowing=0
> --with-fc=0 --download-cmake=
> https://cmake.org/files/v3.9/cmake-3.9.1.tar.gz


Yes, that worked. We can move back to that one if we want.

Maybe at the meeting we can issue a declaration of war on CMake (or at
least get Zimmerman to send a telegram to Autotools).

  Thanks,

 Matt


>
> Satish
>
>
> On Thu, 5 Jul 2018, Matthew Knepley wrote:
>
> > On Thu, Jul 5, 2018 at 5:31 PM Satish Balay  wrote:
> >
> > > Well - can you find the version between 3.7 and 3.11 that works on your
> > > box?
> > >
> >
> > Those bastards do not even have a Changes page. I will have to download
> > every version and try it.
> >
> >Matt
> >
> >
> > > The previous update was done due to:
> > > https://bitbucket.org/petsc/petsc/commits/e5b329dd4ac
> > >
> > > No point in going back to having old issues..
> > >
> > > Satish
> > >
> > > On Thu, 5 Jul 2018, Matthew Knepley wrote:
> > >
> > > > On Thu, Jul 5, 2018 at 5:18 PM Satish Balay 
> wrote:
> > > >
> > > > > Logs?
> > > > >
> > > >
> > > > I can send it, but its really straightforward. The clang++/g++ on my
> box
> > > > (which I will not upgrade because the latest MacOS is crazy)
> > > > does not have the  header, and thus is not compliant
> C++11.
> > > >
> > > >
> > > > > And what version of cmake does not require C++11 compliant
> compiler? We
> > > > > could downgrade to that..
> > > > >
> > > >
> > > > I reverted back to 3.7 which worked, so somewhere in between 3.7 and
> 3.11
> > > > they made the change.
> > > >
> > > >   Thanks,
> > > >
> > > > Matt
> > > >
> > > >
> > > > > Satish
> > > > >
> > > > > On Thu, 5 Jul 2018, Matthew Knepley wrote:
> > > > >
> > > > > > Now we require a fully C++11 compliant compiler, or the CMake
> build
> > > dies.
> > > > > > This is crazy.
> > > > > >
> > > > > >Matt
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/