The tests are run in parallel - but most other tests are sequential.
When I tried to reproduce I ran sequentially [as in 'make -f gmakefile' without
-j] - and some of them hung..
Satish
On Fri, 6 Apr 2018, Karl Rupp wrote:
> Hi again,
>
> the reason for the higher number of timeouts is
Hi again,
the reason for the higher number of timeouts is likely to be due to the
higher number of GPU tests. GPU builds that formerly only used CUSP now
run against the CUDA backend, which has a higher number of tests. Also,
the CUDA backend uses CUBLAS and CUSPARSE, whereas CUSP used its
Hi,
The CUDA tests are hanging/timing-out more often now. For eg:
http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/06/examples_next_arch-cuda-double_es.log
And I did see some build where they didn't get killed due to timeout. For eg:
Satish: Oops, I noticed that the order of the developer photos got messed
up (Hong and Stefano's photos switched) when I updated the website. Have
pushed a fix to master.
--Richard
On Thu, Apr 5, 2018 at 7:07 PM, Balay, Satish wrote:
> On Fri, 6 Apr 2018, Richard Tran Mills
I have the following branches for today's next-tmp test.
origin/knepley/fix-dm-gmg
origin/knepley/fix-ex62-tests
origin/knepley/fix-fe-bd-integral
origin/knepley/fix-fe-vector-spaces
origin/knepley/fix-snes-ex69
origin/tisaac/feature-dmfield
origin/hzhang/iscoloring-testvalid
On Fri, 6 Apr 2018, Matthew Knepley wrote:
> On Thu, Apr 5, 2018 at 10:34 PM, Satish Balay wrote:
>
> > On Fri, 6 Apr 2018, Matthew Knepley wrote:
> >
> > > Okay, I pushed fixes for everything I saw except:
> > >
> >
> > > 1) The weird ex56_1 bug. This is only due to
On Thu, Apr 5, 2018 at 10:34 PM, Satish Balay wrote:
> On Fri, 6 Apr 2018, Matthew Knepley wrote:
>
> > Okay, I pushed fixes for everything I saw except:
> >
>
> > 1) The weird ex56_1 bug. This is only due to feature-dmfield, and
> > its very strange that this logic error
On Fri, 6 Apr 2018, Matthew Knepley wrote:
> Okay, I pushed fixes for everything I saw except:
>
> 1) The weird ex56_1 bug. This is only due to feature-dmfield, and
> its very strange that this logic error appears on only some
> arches. Toby is looking at it, but it should not hold the other
On Thu, Apr 5, 2018 at 9:05 AM, Matthew Knepley wrote:
> On Thu, Apr 5, 2018 at 8:58 AM, Satish Balay wrote:
>
>> All,
>>
>> master builds have been clean for the past 2 days [except for some
>> timeouts]
>>
>>
On Fri, 6 Apr 2018, Richard Tran Mills wrote:
> Thanks, Satish! I notice also that, in the stanza beginning "When citing
> PETSc, please do not refer to this document", Dave May is still missing.
pushed to master.
> Also, that stanza still refers to version 3.7 and 2016.
updated in
Thanks, Satish! I notice also that, in the stanza beginning "When citing
PETSc, please do not refer to this document", Dave May is still missing.
Also, that stanza still refers to version 3.7 and 2016.
--Richard
On Thu, Apr 5, 2018 at 6:26 PM, Balay, Satish wrote:
> Thanks!
Thanks! I pushed some fixes to rmills/doc-add-rmills-to-user-manual.
Satish
On Fri, 6 Apr 2018, Richard Tran Mills wrote:
> Hi Satish,
>
> I decided that I don't have time to polish things as much as I'd like, so
> I'll make the significant user manual edit I had in mind after the release.
>
Hi Satish,
I decided that I don't have time to polish things as much as I'd like, so
I'll make the significant user manual edit I had in mind after the release.
It's something that can wait.
I do have some minor doc changes to go into master for the release. I've
tested these on my laptop to
On Thu, 5 Apr 2018, Satish Balay wrote:
> I have the following branches in queue for master [via next-tmp - these
> builds will start soon]
>
> origin/balay/update-petsc4py-pre-39
> origin/dalcinl/mat-getset-ops
> origin/jczhang/fix-vecscatter-msg-logging
>
> If next-tmp is clean - I can
Sure - we can push doc changes without going through the test cycle [just a doc
build cycle]
thanks,
Satish
On Thu, 5 Apr 2018, Richard Tran Mills wrote:
> Hi Satish,
>
> I'm working on right now on some edits to part of the "Performance Turning"
> part of the manual. If I can get these edits
Hi Satish,
I'm working on right now on some edits to part of the "Performance Turning"
part of the manual. If I can get these edits to a state I'm happy with, I'd
like them to go in the release, but I'm not sure if I will have them ready
before this evening.
--Richard
On Thu, Apr 5, 2018 at
On Thu, Apr 5, 2018 at 9:28 AM, Satish Balay wrote:
> On Thu, 5 Apr 2018, Matthew Knepley wrote:
>
> > >
> > > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/
> 2018/04/05/next.html
> >
> > I think I know all the fixes. I cannot do it until tonight at the
> earliest.
> >
On Thu, 5 Apr 2018, Matthew Knepley wrote:
> >
> > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/05/next.html
>
> I think I know all the fixes. I cannot do it until tonight at the earliest.
> One of them, FETIDP, is an indentation fix.
Once the fixes are in - I think it will take
On Thu, Apr 5, 2018 at 8:58 AM, Satish Balay wrote:
> All,
>
> master builds have been clean for the past 2 days [except for some
> timeouts]
>
> http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/
> 2018/04/04/master.html
>
> However next is still not clean [slightly better
All,
master builds have been clean for the past 2 days [except for some timeouts]
http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/04/master.html
However next is still not clean [slightly better than previous build]
On Wed, 4 Apr 2018, Satish Balay wrote:
> I have the following branches in queue for master [via next-tmp - this build
> will start now]
>
> origin/dalcinl/fix-scatter-destroy
> origin/dalcinl/fix-vecscatter-initpkg
> origin/knepley/fix-cylinder-mesh
>
FYI - I have the release related strings in
https://bitbucket.org/petsc/petsc/branch/balay/release-3.9
This change should be similar to what was done for 3.8 release
https://bitbucket.org/petsc/petsc/commits/0e50f9e530a7b78427514d3e384f6941d4a9cc62?at=v3.8
For now - I'm using tomorrow's date
22 matches
Mail list logo