Re: [petsc-dev] Discussion about time-dependent optimization moved from PR

2017-10-18 Thread Stefano Zampini
I don't have a real API, just a sketch of a possible general framework (with holes) First, I prefer having TSCreateAdjointTS(ts,&ats) (and possibly SNESGetAdjointSNES for optimization with nonlinear time-independent problems) that allows users to replace their Jacobian evaluation routines. Th

[petsc-dev] Cleanup of dmhooks in snesdestroy (was: Re: Discussion about time-dependent optimization moved from PR)

2017-10-18 Thread Lawrence Mitchell
> On 17 Oct 2017, at 17:40, Lawrence Mitchell wrote: > > >> On 17 Oct 2017, at 17:35, Jed Brown wrote: >> >>> >>> So my initial concern was that if I do: >>> >>> SNESSetDM(snes, dm); >>> SNESSolve(snes); >>> SNESDestroy(&snes); >>> >>> Then dm still has stale pointers to snes (in the conte

Re: [petsc-dev] Discussion about time-dependent optimization moved from PR

2017-10-18 Thread Barry Smith
> On Oct 18, 2017, at 4:47 AM, Stefano Zampini > wrote: > > I don't have a real API, just a sketch of a possible general framework (with > holes) > > First, I prefer having TSCreateAdjointTS(ts,&ats) (and possibly > SNESGetAdjointSNES for optimization with nonlinear time-independent prob

Re: [petsc-dev] PetscSF in Fortran

2017-10-18 Thread Matthew Knepley
On Tue, Oct 17, 2017 at 11:35 PM, Adrian Croucher wrote: > hi > > On 16/10/17 15:16, Jed Brown wrote: > >> Adrian Croucher writes: >> >> So do you think the SF stuff in petsc/finclude/petscis.h should be taken >>> out, and put into a new petsc/finclude/petscsf.h ? >>> >> I think that's desirable

Re: [petsc-dev] Discussion about time-dependent optimization moved from PR

2017-10-18 Thread Stefano Zampini
> On Oct 18, 2017, at 7:31 PM, Barry Smith wrote: > > >> On Oct 18, 2017, at 4:47 AM, Stefano Zampini >> wrote: >> >> I don't have a real API, just a sketch of a possible general framework (with >> holes) >> >> First, I prefer having TSCreateAdjointTS(ts,&ats) (and possibly >> SNESGet

[petsc-dev] Improving nightly builds for maint

2017-10-18 Thread Lisandro Dalcin
I opened this PR: https://bitbucket.org/petsc/petsc/pull-requests/ However, this is unlikely to fix these failures: http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2017/10/15/examples_maint_arch-linux-pkgs-valgrind_el6.log Satish, can we find a way to disable these tests when running under

Re: [petsc-dev] Improving nightly builds for maint

2017-10-18 Thread Satish Balay
On Wed, 18 Oct 2017, Lisandro Dalcin wrote: > I opened this PR: https://bitbucket.org/petsc/petsc/pull-requests/ > > However, this is unlikely to fix these failures: > > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2017/10/15/examples_maint_arch-linux-pkgs-valgrind_el6.log > > Satish, c

Re: [petsc-dev] Improving nightly builds for maint

2017-10-18 Thread Lisandro Dalcin
On 18 October 2017 at 22:36, Satish Balay wrote: > On Wed, 18 Oct 2017, Lisandro Dalcin wrote: > > Alternate is to remove/increase the timout. It doesn't work for some > builds anyway [esp valgrind runs] > > This feature relies on sending 'kill' message to the process it > started - i.e mpiexec. B

Re: [petsc-dev] Improving nightly builds for maint

2017-10-18 Thread Satish Balay
On Wed, 18 Oct 2017, Lisandro Dalcin wrote: > On 18 October 2017 at 22:36, Satish Balay wrote: > > On Wed, 18 Oct 2017, Lisandro Dalcin wrote: > > > > Alternate is to remove/increase the timout. It doesn't work for some > > builds anyway [esp valgrind runs] > > > > This feature relies on sending

Re: [petsc-dev] Improving nightly builds for maint

2017-10-18 Thread Lisandro Dalcin
On 18 October 2017 at 23:26, Satish Balay wrote: > > BTW: Just so clarify - eventhough you see a 'killed' message - > currently those jobs are running to completion. [however long it takes > under valgrind] > . And then we get a yellow row in the nightly build matrix, right? -- Lisandro Dalcin

Re: [petsc-dev] Improving nightly builds for maint

2017-10-18 Thread Satish Balay
On Wed, 18 Oct 2017, Lisandro Dalcin wrote: > On 18 October 2017 at 23:26, Satish Balay wrote: > > > > BTW: Just so clarify - eventhough you see a 'killed' message - > > currently those jobs are running to completion. [however long it takes > > under valgrind] > > > . > And then we get a yellow r