[petsc-dev] PetscSectionSetDofbreaks if PetscSectionSetNumFields is called AFTER PetscSectionSetChart

[Blaise A Bourdin]

Hi,

I a seeing a bizarre behavior when setting up a DM for multiple fields.
In the attached example, if the call to PetscSectionSetNumFields is moved until 
AFTER that to PetscSectionSetChart, I get an error while calling 
PetscSectionSetDof.

Is this intended? If so, the documentation needs some mention of this behavior.

Blaise

--
Department of Mathematics and Center for Computation & Technology
Louisiana State University, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin









EXOTest10.c
Description: EXOTest10.c

Re: [petsc-dev] PETSc 3.8.2 and Sundials 3.0.0

[Matthew Knepley]

Do you have any idea what they changed the name of CVSpgmr to in 3.0?

   Matt

On Wed, Nov 15, 2017 at 2:53 PM, Antonio Trande 
wrote:

> Hi all.
>
> I can't build 'PETSc 3.8.*' with MPI against new 'Sundials-3.0.0':
>
> 
> ***
>  UNABLE to CONFIGURE with GIVEN OPTIONS(see configure.log
> for details):
> 
> ---
> --with-sundials-lib=['-L/usr/lib64/openmpi/lib',
> '-lsundials_nvecparallel'] and
> --with-sundials-include=['/usr/include/openmpi-x86_64'] did not work
> 
> ***
>
> configure.log reports something like that:
>
> Executing: /usr/lib64/openmpi/bin/mpicc  -o
> /tmp/petsc-080_o1/config.libraries/conftest -Wl,-z,relro  -Wl,-z,now
> -fPIC  -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -O3
> -Wl,-z,now -fPIC   /tmp/petsc-080_o1/config.libraries/conftest.o
> -L/usr/lib64/openmpi/lib -lsundials_nvecparallel -lopenblas -lm -ldl
> Possible ERROR while running linker: exit code 256
> stderr:
> /tmp/petsc-080_o1/config.libraries/conftest.o: In function
> `_check_CVSpgmr':
> /tmp/petsc-080_o1/config.libraries/conftest.c:5: undefined reference to
> `CVSpgmr'
> collect2: error: ld returned 1 exit status
>
> 'configure.log' is attached.
>
> --
> --
> Antonio Trande
> sagitter AT fedoraproject dot org
> See my vCard.
>



-- 
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] PETSc 3.8.2 and Sundials 3.0.0

[Smith, Barry F.]

  In general PETSc will not work out of the box against newer versions of 
external packages. If you do not need the new features of Sundials then just 
use the default download of Sundials that PETSc uses automatically. If you need 
the latest Sundials then someone needs to go through the process of updating 
the PETSc interface (from the PETSc master branch at bitbucket) to work with 
the latest Sundials.

   Barry


> On Nov 15, 2017, at 1:53 PM, Antonio Trande  wrote:
> 
> Hi all.
> 
> I can't build 'PETSc 3.8.*' with MPI against new 'Sundials-3.0.0':
> 
> ***
> UNABLE to CONFIGURE with GIVEN OPTIONS(see configure.log
> for details):
> ---
> --with-sundials-lib=['-L/usr/lib64/openmpi/lib',
> '-lsundials_nvecparallel'] and
> --with-sundials-include=['/usr/include/openmpi-x86_64'] did not work
> ***
> 
> configure.log reports something like that:
> 
> Executing: /usr/lib64/openmpi/bin/mpicc  -o
> /tmp/petsc-080_o1/config.libraries/conftest -Wl,-z,relro  -Wl,-z,now
> -fPIC  -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -O3
> -Wl,-z,now -fPIC   /tmp/petsc-080_o1/config.libraries/conftest.o
> -L/usr/lib64/openmpi/lib -lsundials_nvecparallel -lopenblas -lm -ldl
> Possible ERROR while running linker: exit code 256
> stderr:
> /tmp/petsc-080_o1/config.libraries/conftest.o: In function `_check_CVSpgmr':
> /tmp/petsc-080_o1/config.libraries/conftest.c:5: undefined reference to
> `CVSpgmr'
> collect2: error: ld returned 1 exit status
> 
> 'configure.log' is attached.
> 
> -- 
> --
> Antonio Trande
> sagitter AT fedoraproject dot org
> See my vCard.
> 

Re: [petsc-dev] PETSc 3.8.2 and Sundials 3.0.0

[Antonio Trande]

On 11/15/2017 08:58 PM, Matthew Knepley wrote:
> Do you have any idea what they changed the name of CVSpgmr to in 3.0?
> 
>    Matt

No, but release change-log
(https://computation.llnl.gov/projects/sundials/cvode) reports:

*Added generic SUNLINEARSOLVER module with eleven provided
implementations: dense, banded, LAPACK dense, LAPACK band, KLU,
SuperLU_MT, SPGMR, SPBCGS, SPTFQMR, SPFGMR, and PCG.  These
implementations replicate previous SUNDIALS generic linear solvers in a
single object-oriented API.*

> 
> On Wed, Nov 15, 2017 at 2:53 PM, Antonio Trande  > wrote:
> 
> Hi all.
> 
> I can't build 'PETSc 3.8.*' with MPI against new 'Sundials-3.0.0':
> 
> 
> ***
>          UNABLE to CONFIGURE with GIVEN OPTIONS    (see configure.log
> for details):
> 
> ---
> --with-sundials-lib=['-L/usr/lib64/openmpi/lib',
> '-lsundials_nvecparallel'] and
> --with-sundials-include=['/usr/include/openmpi-x86_64'] did not work
> 
> ***
> 
> configure.log reports something like that:
> 
> Executing: /usr/lib64/openmpi/bin/mpicc  -o
> /tmp/petsc-080_o1/config.libraries/conftest -Wl,-z,relro  -Wl,-z,now
> -fPIC  -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -O3
> -Wl,-z,now -fPIC   /tmp/petsc-080_o1/config.libraries/conftest.o
> -L/usr/lib64/openmpi/lib -lsundials_nvecparallel -lopenblas -lm -ldl
> Possible ERROR while running linker: exit code 256
> stderr:
> /tmp/petsc-080_o1/config.libraries/conftest.o: In function
> `_check_CVSpgmr':
> /tmp/petsc-080_o1/config.libraries/conftest.c:5: undefined reference to
> `CVSpgmr'
> collect2: error: ld returned 1 exit status
> 
> 'configure.log' is attached.
> 
> --
> --
> Antonio Trande
> sagitter AT fedoraproject dot org
> See my vCard.
> 
> 
> 
> 
> -- 
> 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/ 

-- 
--
Antonio Trande
sagitter AT fedoraproject dot org
See my vCard.
<>

signature.asc
Description: OpenPGP digital signature

Re: [petsc-dev] [petsc-users] ISGlobalToLocalMappingApplyBlock

[Adrian Croucher]

I've debugged into the ISGlobalToLocalMappingApplyBlock() function and 
it seems to me the bounds checking in there is not correct when the 
blocksize is > 1.


It checks against the same bounds, scaled up by the blocksize, in both 
the block and non-block versions of the function. I think for the block 
version the bounds should not be scaled.


I've just created a pull request 
(acroucher/fix-IS-global-to-local-mapping-block) with a suggested fix.


- Adrian


On 16/11/17 11:52, Adrian Croucher wrote:
I actually attached the wrong test program last time- I've attached 
the right one here, which is much simpler. It test global indices 0, 
1, ... 9.


If I run on 2 processes, the local indices it returns are:

rank 0: 0, 1, 2, 3, 4, 0, 0, 0, -253701943, 0
rank 1: -1, -1, -1, -1, -1, -1, -1, -1, -1, -1

The results I expected are:

rank 0: 0, 1, 2, 3, 4, -1, -1, -1, -1, -1
rank 1: -1, -1, -1, -1, -1, 0, 1, 2, 3, 4

So the results for global indices 0, 1,... 4 are what I expected, on 
both ranks. But the results for global indices 5, 6, ... 9 are not.


I tried increasing the blocksize to 3 or 4, and the results were 
exactly the same.


It only gives the results I expected if I change the blocksize to 1.

- Adrian



--
Dr Adrian Croucher
Senior Research Fellow
Department of Engineering Science
University of Auckland, New Zealand
email: a.crouc...@auckland.ac.nz
tel: +64 (0)9 923 4611

Re: [petsc-dev] nightlybuilds (next vs next-tmp)

[Satish Balay]

I'm switching the nightlybuild to next-tmp with the following branches for 
tonight.

$ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | sort) 
<(git branch -r --no-merged origin/master | sort) |grep -v ' origin/next-tmp'
  origin/barry/remove-petscdatatype-dmgetworkarray
  origin/barry/snes-view-display-fd
  origin/jed/fix-matcreatempibaij/maint
  origin/knepley/feature-adaptor-plex

Satish

Re: [petsc-dev] nightlybuilds (next vs next-tmp)

[Richard Tran Mills]

On Sun, Nov 12, 2017 at 9:54 AM, Smith, Barry F.  wrote:

>
>
> > On Nov 12, 2017, at 11:21 AM, Matthew Knepley  wrote:
> >
> > On Sun, Nov 12, 2017 at 12:17 PM, Satish Balay 
> wrote:
> > On Sun, 12 Nov 2017, Matthew Knepley wrote:
> >
> > >
> > > Have we tried histogramming test times? It would be nice to know how
> much
> > > cumulative
> > > time it takes to run 37%, 67%, 95%, etc.
> >
> > I'm not sure what 'histogramming test time' means.
> >
> > The below looked like cumulative times over all tests. I want the time
> for each test, and then
> > we bin them into say 10s wide bins and see which ones are taking the
> most time.
>
>   WE FREAKING NEED TO CONVERT TO THE NEW TEST HARNESS TO DO THIS, then it
> is easy.
>
>   So everyone, please, instead of spending twenty minutes a day sending
> and reading email about testing spend 20 minutes a day converting examples
> from the old tests to the new harness!
>

For those of us who have no idea how to do this, could someone please give
me a pointer or two on where to look for an example or two or some
documentation? I should probably be spending a few minutes a day converting
some examples, but I don't know how or where to start.

--Richard


>
> >
> >Matt
> >
> > All logs record time. And Karl's script summarizes those times on the
> > dashboard. For eg:
> >
> > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2017/
> 11/11/maint.html
> >
> > If you want to do some analysis on those times - you can grab the
> > [historical] logs and run the required analysis.
> >
> > 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] nightlybuilds (next vs next-tmp)

[Matthew Knepley]

On Wed, Nov 15, 2017 at 8:56 PM, Richard Tran Mills  wrote:

> On Sun, Nov 12, 2017 at 9:54 AM, Smith, Barry F. 
> wrote:
>
>>
>>
>> > On Nov 12, 2017, at 11:21 AM, Matthew Knepley 
>> wrote:
>> >
>> > On Sun, Nov 12, 2017 at 12:17 PM, Satish Balay 
>> wrote:
>> > On Sun, 12 Nov 2017, Matthew Knepley wrote:
>> >
>> > >
>> > > Have we tried histogramming test times? It would be nice to know how
>> much
>> > > cumulative
>> > > time it takes to run 37%, 67%, 95%, etc.
>> >
>> > I'm not sure what 'histogramming test time' means.
>> >
>> > The below looked like cumulative times over all tests. I want the time
>> for each test, and then
>> > we bin them into say 10s wide bins and see which ones are taking the
>> most time.
>>
>>   WE FREAKING NEED TO CONVERT TO THE NEW TEST HARNESS TO DO THIS, then it
>> is easy.
>>
>>   So everyone, please, instead of spending twenty minutes a day sending
>> and reading email about testing spend 20 minutes a day converting examples
>> from the old tests to the new harness!
>>
>
> For those of us who have no idea how to do this, could someone please give
> me a pointer or two on where to look for an example or two or some
> documentation? I should probably be spending a few minutes a day converting
> some examples, but I don't know how or where to start.
>

There is a manual chapter on the test system, but for cut & paste
semantics, you can look at SNES which has a lot of converted examples.
Basically, you take each test entry from the makefile, and move it into the
source file itself.

  Matt


> --Richard
>
>
>>
>> >
>> >Matt
>> >
>> > All logs record time. And Karl's script summarizes those times on the
>> > dashboard. For eg:
>> >
>> > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2017/11
>> /11/maint.html
>> >
>> > If you want to do some analysis on those times - you can grab the
>> > [historical] logs and run the required analysis.
>> >
>> > 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/
>>
>>
>


-- 
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] nightlybuilds (next vs next-tmp)

[Smith, Barry F.]

> On Nov 15, 2017, at 8:30 PM, Matthew Knepley  wrote:
> 
> On Wed, Nov 15, 2017 at 8:56 PM, Richard Tran Mills  wrote:
> On Sun, Nov 12, 2017 at 9:54 AM, Smith, Barry F.  wrote:
> 
> 
> > On Nov 12, 2017, at 11:21 AM, Matthew Knepley  wrote:
> >
> > On Sun, Nov 12, 2017 at 12:17 PM, Satish Balay  wrote:
> > On Sun, 12 Nov 2017, Matthew Knepley wrote:
> >
> > >
> > > Have we tried histogramming test times? It would be nice to know how much
> > > cumulative
> > > time it takes to run 37%, 67%, 95%, etc.
> >
> > I'm not sure what 'histogramming test time' means.
> >
> > The below looked like cumulative times over all tests. I want the time for 
> > each test, and then
> > we bin them into say 10s wide bins and see which ones are taking the most 
> > time.
> 
>   WE FREAKING NEED TO CONVERT TO THE NEW TEST HARNESS TO DO THIS, then it is 
> easy.
> 
>   So everyone, please, instead of spending twenty minutes a day sending and 
> reading email about testing spend 20 minutes a day converting examples from 
> the old tests to the new harness!
> 
> For those of us who have no idea how to do this, could someone please give me 
> a pointer or two on where to look for an example or two or some 
> documentation? I should probably be spending a few minutes a day converting 
> some examples, but I don't know how or where to start.
> 
> There is a manual chapter on the test system, but for cut & paste semantics, 
> you can look at SNES which has a lot of converted examples.
> Basically, you take each test entry from the makefile, and move it into the 
> source file itself.

  Richard,

   Scott wrote a tool to semi-automatically do it from the makefile but sadly 
the tool is currently broken (it had no nightly testing) and like most python 
code is undebuggable.  Anyways  after you have put a test in the example source 
code manually as Matt says, you run from PETSC_DIR

./config/gmakegentest.py 

this parses all the examples and sets up the scripts that are run to do the 
testing. Then use, for example, 

  make -f gmakefile test globsearch='*heat*'

to run all tests that have heat in the example name or path. Or you can do


  make -f gmakefile test globsearch='dm*'

to run all tests in the dm directories. Sometimes you need a little trial and 
error to get the globsearch right to run your example and not others.

You will get a little frustrated the first couple times you do it, just bug us 
and we'll help you get past the stumbling blocks.

  Barry




   




> 
>   Matt
>  
> --Richard
> 
> 
> 
> >
> >Matt
> >
> > All logs record time. And Karl's script summarizes those times on the
> > dashboard. For eg:
> >
> > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2017/11/11/maint.html
> >
> > If you want to do some analysis on those times - you can grab the
> > [historical] logs and run the required analysis.
> >
> > 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/
> 
> 
> 
> 
> 
> -- 
> 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/