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
>
>
> 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
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
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
> 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
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"
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
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
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
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
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:
>
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
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:
>
When can we delete the legacy test system? Are we currently using it
anywhere?
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
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
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
>
>
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
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
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
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
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
> 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
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"
>
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
>>
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
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
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
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
29 matches
Mail list logo
