[petsc-dev] (arm64) could not find object file symbol for symbol ___muldc3

[Blaise A Bourdin]

Hi,

I am having the following warning when compiling any fortran example (currently 
on main, but  it’s been going on for a little while) on a ARM mac.


***Error detected during compile or link!***
See http://www.mcs.anl.gov/petsc/documentation/faq.html
/opt/HPC/petsc-main/src/snes/tutorials ex5f
*
mpif90 -Wl,-bind_at_load -Wl,-multiply_defined,suppress -Wl,-multiply_defined 
-Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first 
-Wl,-no_compact_unwind -ffree-line-length-none -fallow-argument-mismatch -fPIC 
-g   -ffree-line-length-none -fallow-argument-mismatch -fPIC -g
-I/opt/HPC/petsc-main/include 
-I/opt/HPC/petsc-main/bigsur-gcc10.2-arm64-reallybasic-g/include 
-I/opt/X11/include ex5f.F90  
-Wl,-rpath,/opt/HPC/petsc-main/bigsur-gcc10.2-arm64-reallybasic-g/lib 
-L/opt/HPC/petsc-main/bigsur-gcc10.2-arm64-reallybasic-g/lib 
-Wl,-rpath,/opt/X11/lib -L/opt/X11/lib 
-Wl,-rpath,/opt/homebrew/Cellar/mpich/3.4.1_2/lib 
-L/opt/homebrew/Cellar/mpich/3.4.1_2/lib 
-Wl,-rpath,/opt/homebrew/Cellar/gcc/10.2.0_4/lib/gcc/10/gcc/aarch64-apple-darwin20/10.2.1
 
-L/opt/homebrew/Cellar/gcc/10.2.0_4/lib/gcc/10/gcc/aarch64-apple-darwin20/10.2.1
 -Wl,-rpath,/opt/homebrew/Cellar/gcc/10.2.0_4/lib/gcc/10 
-L/opt/homebrew/Cellar/gcc/10.2.0_4/lib/gcc/10 -lpetsc -llapack -lblas -lX11 
-lc++ -ldl -lmpifort -lmpi -lpmpi -lgfortran -lemutls_w -lm -lc++ -ldl -o ex5f
warning: (arm64)  could not find object file symbol for symbol ___muldc3
Fortran example src/snes/tutorials/ex5f run successfully with 1 MPI process


For reference, here is how I configured petsc:
./configure --CFLAGS='-Wimplicit-function-declaration'
--FFLAGS="-ffree-line-length-none -fallow-argument-mismatch"
--with-debugging=1--with-shared-libraries=1 
--with-x11=1

It looks like this symbol is referenced in: sfpack.o

SiMini:petsc-main (main)$ grep -ri muldc3 bigsur-gcc10.2-arm64-reallybasic-g/*
Binary file bigsur-gcc10.2-arm64-reallybasic-g/lib/libpetsc.3.015.0.dylib 
matches
Binary file bigsur-gcc10.2-arm64-reallybasic-g/lib/libpetsc.3.015.dylib matches
bigsur-gcc10.2-arm64-reallybasic-g/lib/petsc/conf/check.log:warning: (arm64)  
could not find object file symbol for symbol ___muldc3
Binary file bigsur-gcc10.2-arm64-reallybasic-g/lib/libpetsc.dylib matches
Binary file 
bigsur-gcc10.2-arm64-reallybasic-g/obj/vec/is/sf/impls/basic/sfpack.o matches

SiMini:petsc-main (main)$ nm 
bigsur-gcc10.2-arm64-reallybasic-g/obj/vec/is/sf/impls/basic/sfpack.o | grep 
muldc3
 U ___muldc3


Any idea?
Blaise


--
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

Re: [petsc-dev] Case TS005062693 - XLF: ICE in xlfentry compiling a module with 358 subroutines

[Blaise A Bourdin]

On Mar 16, 2021, at 11:17 PM, Barry Smith 
mailto:bsm...@petsc.dev>> wrote:


  So it actually does not load everything at the call to use but waits until 
the subroutine definitions and then only loads what you ask to import?

  Sorry, this is odd, with C include or python import it immediately loads up 
everything as soon as it sees the include or import, there is no way later to 
say "wo hoarsy I didn't really mean you should get everything I asked, for 
please only load up a subset".


But then Fortran was always weird, when I saw presentations of the Fortran 
standards committee members I always felt like they read every third page of 
some computer science book but never realized they missed many of the pages.

Which proves that they know their target audience ;)

>From the standpoint of somebody who also read every third page of a computer 
>science book, fortran modules sounded like a good idea on the paper (I 
>basically think of them as auto-generated header files), but they are 
>miserable in practice, and in particular a major block to cross compiler 
>compatibility since the format of .mod file was left to the discretion of the 
>compiler writers.

Blaise

--
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

[petsc-dev] Commit squashing in MR

[Blaise A Bourdin]

Hi,

This is not technically a petsc question. 
It would be great to have a short section in the PETSc integration workflow 
document explaining how to squash commits in a MR for git-impaired developers 
like me.

Anybody wants to pitch in, or explain me how to do this?

Regards,
Blaise
 
-- 
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

[petsc-dev] Comparing binary output files in test harness

[Blaise A Bourdin]

Hi,

I would like to write better tests for my exodus I/O functions and compare the 
binary files written to the drive instead of the output of the examples.
For instance, would it be possible to do the following:
ex26 -i  -o output1.exo; mpirun -np 2 ex26 -i  
-o output2.exo; exodiff output1.exo output2.exo
And check the result of exodiff, or run exodiff between output1.exo or 
output2.exo and a stored binary result?

Regards,
Blaise

-- 
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

[petsc-dev] Fortran interface for DMCreateSuperDM

[Blaise A Bourdin]

Hi,

I am porting src/dm/impls/plex/tests/ex26.c to fortran90 but am having a hard 
time figuring out how to write the fortran binding for DMCreateSuperDM. 
Can anybody help?

Regards,
Blaise
-- 
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

Re: [petsc-dev] Rebuilding pets-library only

[Blaise A Bourdin]

Thanks

Blaise


On Feb 17, 2021, at 10:03 AM, Jed Brown 
mailto:j...@jedbrown.org>> wrote:

make libs should do that.

Blaise A Bourdin mailto:bour...@lsu.edu>> writes:

Hi,

Is there a way to rebuild the petsc library only, skipping rebuilding mpi4py 
and petsc4py if petsc is configured with them? I know I can ctrl-C this step if 
all I want is to rebuild the lib, but I would not mind a more elegant way..

Regards,
Blaise

--
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

--
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

[petsc-dev] Rebuilding pets-library only

[Blaise A Bourdin]

Hi,

Is there a way to rebuild the petsc library only, skipping rebuilding mpi4py 
and petsc4py if petsc is configured with them? I know I can ctrl-C this step if 
all I want is to rebuild the lib, but I would not mind a more elegant way..

Regards,
Blaise

-- 
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

Re: [petsc-dev] Building Sowing fails with old system gcc

[Blaise A Bourdin]

> On Dec 3, 2020, at 10:32 AM, Satish Balay  wrote:
> 
>>>>>>> 
> configure:6247: /lib/cpp  conftest.c
> In file included from conftest.c:11:0:
> /share/apps/intel-2020.2/compilers_and_libraries/linux/include/limits.h:37:54:
>  error: missing binary operator before token "("
> defined(__has_include_next) && __has_include_next()
>  ^
> configure:6247: $? = 1
> <<<<<
> 
> 
> I've seen these bad interactions with intel compilers and gcc. i.e - when 
> intel compiler modifies env for itself - it breaks gcc.
> 
> [and this newer version if intel compiler requires a newer gcc in PATH anyway 
> :(  - otherwise some c++ features don't work..]
> 
> Don't know how to deal with such issues [created by intel compilers..]

Let’s not try to fix what the intel compilers break! Passing epic and mlicxx as 
the compilers to sowing works well enough.

Regards,
Blaise


> 
> Satish
> 
> On Thu, 3 Dec 2020, Blaise A Bourdin wrote:
> 
>> 
>> 
>>> On Dec 3, 2020, at 10:15 AM, Satish Balay  wrote:
>>> 
>>> On Thu, 3 Dec 2020, Blaise A Bourdin wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Building sowing fails when I try to compile petsc on a RHEL7 system with 
>>>> the default gcc (4.8.5) and intel compilers.
>>>> Looking at the log file and sowing.py, it looks like sowing configure step 
>>>> does not inherit from the compilers detected by BuildSystem at an earlier 
>>>> stage, so that instead of using the intel compilers, it pulls my ancient 
>>>> gcc.
>>>> 
>>>> Instead of having to clumsily add --download-sowing-cc=mpicc 
>>>> --download-sowing-cxx=mpicxx to the configure options, would it make sense 
>>>> to populate the CC, CXX, CPP, CXXPP configure options (sowing.py:40-47) 
>>>> with the PETSc compilers? I can do it if that is OK.
>>> 
>>> The reason for the current design is - sowing [and similar build tools] - 
>>> are for the build machine - and the petsc library [and CC etc] are for the 
>>> compute machine [in cases where these are different].
>>> 
>>> Also sowing didn't work with most compilers - and default gcc [from PATH] 
>>> was the most sane default compiler for it.
>>> 
>>> And defaults don't always work [if defaults are changed - if might fix this 
>>> senario - but break in others that are curently working...] - hence we have 
>>> these extra options for use - in these cases.
>> 
>> OK, that does make a lot of sense.
>> 
>>> 
>>> I'm surprised sowing doesn't work with gcc-4.8.5. I'll have to recheck.
>> I am attaching my sowing config.log and configure.log
>> 
>> 
>> 
>> Regards,
>> Blaise
>> 
>> --
>> A.K. & Shirley Barton Professor of  Mathematics
>> Adjunct Professor of Mechanical Engineering
>> Adjunct of the Center for Computation & Technology
>> Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
>> Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
>> http://www.math.lsu.edu/~bourdin
>> 
>> 
> 

-- 
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

[petsc-dev] Building Sowing fails with old system gcc

[Blaise A Bourdin]

Hi,

Building sowing fails when I try to compile petsc on a RHEL7 system with the 
default gcc (4.8.5) and intel compilers.
Looking at the log file and sowing.py, it looks like sowing configure step does 
not inherit from the compilers detected by BuildSystem at an earlier stage, so 
that instead of using the intel compilers, it pulls my ancient gcc.

Instead of having to clumsily add --download-sowing-cc=mpicc 
--download-sowing-cxx=mpicxx to the configure options, would it make sense to 
populate the CC, CXX, CPP, CXXPP configure options (sowing.py:40-47) with the 
PETSc compilers? I can do it if that is OK.

Regards,
Blaise
-- 
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

Re: [petsc-dev] Get a list of package download URL

[Blaise A Bourdin]

Awesome, thanks.

Blaise


> On Nov 18, 2020, at 6:01 PM, Satish Balay  wrote:
> 
> Check --with-packages-download-dir option.
> 
> This is a 2 step process. For ex - the first step:
> 
>>>> 
> balay@sb /home/balay/petsc (master=)
> $ ./configure --with-packages-download-dir=$HOME/tmp --download-metis 
> --download-parmetis
> ===
> Configuring PETSc to compile on your system   
> ===
> Download the following packages to /home/balay/tmp 
> 
> metis 
> ['git://https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fpetsc%2Fpkg-metis.gitdata=04%7C01%7Cbourdin%40lsu.edu%7Cdc3a2e8e9424476634ca08d88c1e49e2%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C637413409027494849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tIgSO%2BhWR7Nz0SYO0jJ2xpZmW2rXWWhOhXv7ZG1FT4s%3Dreserved=0',
>  
> 'https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fpetsc%2Fpkg-metis%2Fget%2Fv5.1.0-p10.tar.gzdata=04%7C01%7Cbourdin%40lsu.edu%7Cdc3a2e8e9424476634ca08d88c1e49e2%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C637413409027494849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nZSgkp8hJFv7yJj2PpYdqltF0VETWvFsG%2BPgjZZhWQM%3Dreserved=0']
> parmetis 
> ['git://https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fpetsc%2Fpkg-parmetis.gitdata=04%7C01%7Cbourdin%40lsu.edu%7Cdc3a2e8e9424476634ca08d88c1e49e2%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C637413409027504803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Tq6wjnHdqyNY3aABmpppTwT%2FKWCLFc5opda70UHSmG8%3Dreserved=0',
>  
> 'https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fpetsc%2Fpkg-parmetis%2Fget%2Fv4.0.3-p6.tar.gzdata=04%7C01%7Cbourdin%40lsu.edu%7Cdc3a2e8e9424476634ca08d88c1e49e2%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C637413409027504803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CsqwH7BZVjyNrNv8aDQwRZeOf%2B4HXtsCN5ni%2BzhKkC0%3Dreserved=0']
> 
> Then run the script again
> <<<<
> 
> Satish
> 
> On Wed, 18 Nov 2020, Blaise A Bourdin wrote:
> 
>> Hi,
>> 
>> I am working with a company whose cluster is an a private network without 
>> connectivity to the outside world. Our process to install petsc is to 
>> manually extract the packages URL from config/BuildSystem/packages/ and 
>> download the appropriate files.
>> Another approach is to run configure and let it fail when it cannot download 
>> a package, note the download URL, and manually download it from a separate 
>> machine.
>> 
>> Is there a quicker way to get the URL of all packages that will be 
>> downloaded without running through the whole configure process? 
>> 
>> Assuming that I know the list of package that I will want, is there a 
>> programmatic way to figure out what os the download URL for say Metis or 
>> sowing?
>> 
>> Regards,
>> Blaise
>> 
>> 
>> 
> 

-- 
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

[petsc-dev] Get a list of package download URL

[Blaise A Bourdin]

Hi,

I am working with a company whose cluster is an a private network without 
connectivity to the outside world. Our process to install petsc is to manually 
extract the packages URL from config/BuildSystem/packages/ and download the 
appropriate files.
Another approach is to run configure and let it fail when it cannot download a 
package, note the download URL, and manually download it from a separate 
machine.

Is there a quicker way to get the URL of all packages that will be downloaded 
without running through the whole configure process? 

Assuming that I know the list of package that I will want, is there a 
programmatic way to figure out what os the download URL for say Metis or sowing?

Regards,
Blaise

  
-- 
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

Re: [petsc-dev] Statistics on the popularity of PETSc

[Blaise A Bourdin]

But even this would only count the users who load the TACC provided modules, 
and not those rebuilding petsc with a specific configuration.

Blaise


> On Sep 17, 2020, at 9:34 AM, Victor Eijkhout  wrote:
> 
> 
> 
>> On , 2020Sep17, at 09:13, Jacob Faibussowitsch  wrote:
>> 
>> Victor - Does this count the number of users who simply loaded the module? 
>> Or users who submitted a job using the petsc module (if that’s even 
>> tracked?). 
> 
> The latter. It tracks what modules are loaded when a batch job starts. That’s 
> not entirely the same as PETSc actually being used but I guess it’s a pretty 
> close proxy.
> 
> We track a whole bunch of statistics on batch jobs. (Including hardware 
> performance counters on processors, network, file system. One snapshot per 30 
> minutes, so it doesn’t interfere too much.) I don’t think we track anything 
> about interactive loading of modules. 
> 
> Btw, almost 1000 unique users over the lifetime of the database, which goes 
> back to petsc 3.4, whenever that was.
> 
> Victor.

-- 
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

[petsc-dev] Exodus viewer

[Blaise A Bourdin]

Hi,

I just noticed recent changes to the exodus I/O and a new exodus viewer, which 
had been on my todo list forever…
Is there a test or example available? Is there anything that remains I could 
help with?

Regards,
Blaise


-- 
A.K. & Shirley Barton Professor of  Mathematics
Adjunct Professor of Mechanical Engineering
Adjunct of the Center for Computation & Technology
Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 Web 
http://www.math.lsu.edu/~bourdin

Re: [petsc-dev] plex test 26 failing for complex

[Blaise A Bourdin]

On Oct 24, 2018, at 9:03 AM, Matthew Knepley 
mailto:knep...@gmail.com>> wrote:

On Wed, Oct 24, 2018 at 9:54 AM Hapla Vaclav 
mailto:vaclav.ha...@erdw.ethz.ch>> wrote:
Tests dm_impls_plex_tests-ex26% fail for exodusii+complex build.

E.g.
not ok dm_impls_plex_tests-ex26_15
#   [0]PETSC ERROR: - Error Message 
--
#   [0]PETSC ERROR: Petsc has generated inconsistent data
#   [0]PETSC ERROR: UAlpha ||Vin - Vout|| = 1000.56
#
#   [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html 
for trouble shooting.
#   [0]PETSC ERROR: Petsc Development GIT revision: v3.10.1-219-g632bab2  
GIT Date: 2018-10-24 12:51:19 +0200
#   [0]PETSC ERROR: ../ex26 on a arch-linux-gcc-complex-single-64idx named 
swp-group-pc by vhapla Wed Oct 24 15:43:20 2018
#   [0]PETSC ERROR: Configure options --download-c2html 
--download-f2cblaslapack --download-exodusii --download-hdf5 --download-metis 
--download-netcdf --download-pnetcdf --download-parmetis --download-ptscotch 
--download-ctetgen --with-64-bit-indices --download-zlib --with-cc=mpicc 
--with-cxx=mpicxx --with-fc=mpifort --with-precision=single --with-python=1 
--with-scalar-type=complex --with-shared-libraries=1 
--with-valgrind-dir=/home/vhapla PETSC_ARCH=arch-linux-gcc-complex-single-64idx
#   [0]PETSC ERROR: #1 main() line 387 in 
/home/vhapla/petsc-1/src/dm/impls/plex/examples/tests/ex26.c


Should this be fixed or "requires: !complex" added?

Yes. This is Blaise's test, and I do not know if it was intended to work with 
complex.

No, it is not.

Blaise


  Thanks,

 Matt

Is this configuration not covered by nightly tests?

Vaclav


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

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

Re: [petsc-dev] upcoming release and testing

[Blaise A Bourdin]

Hi Satish,

I am working on it. ex26 tests a bunch of DMPlex functions which I don’t think 
are tested anywhere else. The test itself may also have leaks.

Blaise


> On Apr 1, 2018, at 11:42 AM, Satish Balay  wrote:
> 
> On Sun, 1 Apr 2018, Satish Balay wrote:
> 
>> I'll try to send follow up emails on master brakages.
> 
> Blaise,
> 
> http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/03/31/examples_master_arch-c-exodus-dbg-builder_es.log
> 
> dm_impls_plex_tests-ex26 has bunch of memory leaks and diffs. I could track 
> one of the memory leaks to f94b4a023f1c697a53e49ac853a9031583ab9737 -  but 
> don't know what the trigger is - or how to fix it.
> 
> not ok diff-dm_impls_plex_tests-ex26_6
> # 969a970,2569
> # > [ 0]16 bytes PetscSFBasicGetPack() line 806 in 
> /sandbox/petsc/petsc.master-3/src/vec/is/sf/impls/basic/sfbasic.c
> # >   [0]  PetscMallocA() line 806 in 
> /sandbox/petsc/petsc.master-3/src/sys/memory/mal.c
> # >   [0]  PetscSFBasicGetPack() line 778 in 
> /sandbox/petsc/petsc.master-3/src/vec/is/sf/impls/basic/sfbasic.c
> # >   [0]  PetscSFBcastBegin_Basic() line 923 in 
> /sandbox/petsc/petsc.master-3/src/vec/is/sf/impls/basic/sfbasic.c
> # >   [0]  PetscSFBcastBegin() line 1045 in 
> /sandbox/petsc/petsc.master-3/src/vec/is/sf/interface/sf.c
> # >   [0]  DMPlexGlobalToNaturalBegin() line 183 in 
> /sandbox/petsc/petsc.master-3/src/dm/impls/plex/plexnatural.c
> # >   [0]  VecViewPlex_ExodusII_Zonal_Internal() line 678 in 
> /sandbox/petsc/petsc.master-3/src/dm/impls/plex/plexexodusii.c
> 
> And there are diffs which should be checked..
> 
> not ok diff-dm_impls_plex_tests-ex26_7
> # 536c536
> # <   Cell Sets: 2 strata with value/size (3 (9), 5 (9))
> # ---
> # >   Cell Sets: 2 strata with value/size (1 (9), 2 (9))
> # 537a538,2137
> 
> not ok diff-dm_impls_plex_tests-ex26_10
> # 536c536
> # <   Cell Sets: 2 strata with value/size (3 (9), 5 (9))
> # ---
> # >   Cell Sets: 2 strata with value/size (1 (9), 2 (9))
> # 537a538,2137
> 
> 
> # <   0-cells: 28 36
> # <   1-cells: 58 67
> # ---
> # >   0-cells: 34 32
> # >   1-cells: 64 63
> # 734,735c734,2335
> # <   Cell Sets: 3 strata with value/size (2 (1), 3 (28), 5 (3))
> # <   depth: 3 strata with value/size (0 (28), 1 (58), 2 (32))
> # ---
> # >   Cell Sets: 3 strata with value/size (1 (9), 2 (18), 3 (5))
> # >   depth: 3 strata with value/size (0 (34), 1 (64), 2 (32))
> 
> etc..
> 
> thanks,
> Satish
> 

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

[petsc-dev] How is PETSC_FLIB generated in BuildSystem?

[Blaise A Bourdin]

Hi,

I can’t figure out how is the library list in $PETSC_FLIB generated. How would 
I need to modify exodusii.py in order to add the proper library (libexodus_for 
with 64bit int and libexoIIv2for32 with 32 bit int)?

Regards,
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

Re: [petsc-dev] SETERRQ in fortran

[Blaise A Bourdin]

> On Jan 4, 2018, at 3:16 PM, Smith, Barry F. <bsm...@mcs.anl.gov> wrote:
> 
> 
>  It's changed a bit.  It is better but you need to understand how the new one 
> works, so take a few minutes to see how it works before converting.
Got it.
An example or a link to the fortran macro definition from the man page would be 
nice 
I am confused about the rationale for putting the endif in the macro, though.
Beside not having unmatched if / end if in my code, in a select case construct, 
I have to write something as ugly as

select case (i)
case(1) 
!do something
case(2)
!do something else
case default
if (0 == 0) then

SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
end select

Am I missing something again?

Blaise


> 
>  Use CHKERRA() for main Fortran problem and CHKERRQ() for subroutines.
> 
>  Also look at their definitions to see how the if () business is handled. 
> 
>  Barry
> 
> 
>> On Jan 4, 2018, at 2:02 PM, Matthew Knepley <knep...@gmail.com> wrote:
>> 
>> On Thu, Jan 4, 2018 at 2:42 PM, Blaise A Bourdin <bour...@lsu.edu> wrote:
>> Hi,
>> 
>> Is SETERRQ still available in fortran? I notice that it is not used in any 
>> of the example, but the man page still mentions fortran. Using it in a 
>> fortran code leads to compiler errors.
>> Am I doing something wrong?
>> 
>> I see it here:
>> 
>>  
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fpetsc%2Fpetsc%2Fsrc%2Fc925fbded0167f274f0216824a05edb59a5721f5%2Finclude%2Fpetsc%2Ffinclude%2Fpetscsys.h%3Fat%3Dmaster%26fileviewer%3Dfile-view-default%23petscsys.h-197=02%7C01%7Cbourdin%40lsu.edu%7C9e126b88c4de4bb5b1c108d553b87d8a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C636506974199979974=R6xnRLTzelnxPz39tkA0warCI%2BUFt%2FAnM8haZbjANQA%3D=0
>> 
>> I think its complaining about the 'return;endif'
>> 
>>  Matt
>> 
>> MacBookGray:F90 $ cat TestSETERRQ.F90
>> Program TestSETERRQ
>> #include 
>>   Use petsc
>> 
>>   Implicit NONE
>>   PetscInt   :: ierr
>>   Character(len=256) :: IOBuffer
>> 
>>   Call PetscInitialize(PETSC_NULL_CHARACTER, ierr);CHKERRA(ierr)
>>   write(IOBuffer,'("This is a test ierr = ",I2,"\n")') ierr
>>   SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>>   call foo()
>>   Call PetscFinalize(ierr)
>> Contains
>>subroutine foo()
>>   Character(len=256) :: IOBuffer
>> 
>>   write(IOBuffer,'("This is a test ierr = ",I2,"\n")') 42
>>   SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>>end subroutine foo
>> End Program TestSETERRQ
>> 
>> MacBookGray:F90 $ make -f makefile.TestSETERRQ TestSETERRQ
>> mpif90 -c -Wall -ffree-line-length-0 -Wno-unused-dummy-argument -g
>> -I/opt/HPC/petsc-next/include -I/opt/HPC/petsc-next/Darwin-gcc7.2-g/include 
>> -I/opt/X11/include-o TestSETERRQ.o TestSETERRQ.F90
>> TestSETERRQ.F90:11:61:
>> 
>>SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>> 1
>> Error: Expecting END PROGRAM statement at (1)
>> TestSETERRQ.F90:19:65:
>> 
>>SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>> 1
>> Error: Expecting END SUBROUTINE statement at (1)
>> make: [TestSETERRQ.o] Error 1 (ignored)
>> 
>> 
>> 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 
>> https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.math.lsu.edu%2F~bourdin=02%7C01%7Cbourdin%40lsu.edu%7C9e126b88c4de4bb5b1c108d553b87d8a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C636506974199979974=DM5ZtUYkEBxwU%2FVS7eHC8dF%2Fw2w9aSbP9l8YvL3Nj6o%3D=0
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> 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://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.cse.buffalo.edu%2F~knepley%2F=02%7C01%7Cbourdin%40lsu.edu%7C9e126b88c4de4bb5b1c108d553b87d8a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C636506974199979974=99K5TljrSNkF7MGImBkWQTjXCUt%2BdwB8XAHB%2FQztQZY%3D=0
> 

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

[petsc-dev] SETERRQ in fortran

[Blaise A Bourdin]

Hi,

Is SETERRQ still available in fortran? I notice that it is not used in any of 
the example, but the man page still mentions fortran. Using it in a fortran 
code leads to compiler errors.
Am I doing something wrong?

MacBookGray:F90 $ cat TestSETERRQ.F90 
Program TestSETERRQ
#include 
   Use petsc

   Implicit NONE
   PetscInt   :: ierr
   Character(len=256) :: IOBuffer
   
   Call PetscInitialize(PETSC_NULL_CHARACTER, ierr);CHKERRA(ierr)
   write(IOBuffer,'("This is a test ierr = ",I2,"\n")') ierr
   SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
   call foo()
   Call PetscFinalize(ierr)
Contains
subroutine foo()
   Character(len=256) :: IOBuffer
   
   write(IOBuffer,'("This is a test ierr = ",I2,"\n")') 42
   SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
end subroutine foo
End Program TestSETERRQ

MacBookGray:F90 $ make -f makefile.TestSETERRQ TestSETERRQ
mpif90 -c -Wall -ffree-line-length-0 -Wno-unused-dummy-argument -g
-I/opt/HPC/petsc-next/include -I/opt/HPC/petsc-next/Darwin-gcc7.2-g/include 
-I/opt/X11/include-o TestSETERRQ.o TestSETERRQ.F90
TestSETERRQ.F90:11:61:

SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
 1
Error: Expecting END PROGRAM statement at (1)
TestSETERRQ.F90:19:65:

SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
 1
Error: Expecting END SUBROUTINE statement at (1)
make: [TestSETERRQ.o] Error 1 (ignored)


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

[petsc-dev] DM exodus viewer

[Blaise A Bourdin]

Hi,

Now that all the low-level functions are in next, I’d like to add proper 
support for an exodus viewer for Vector and DM, but I really don’t know where 
to start from.
Can anybody point me to where I should start looking at in the source code?

Regards,
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

Re: [petsc-dev] pnetcdf is a big problem

[Blaise A Bourdin]

There are two ways to write parallel netcdf files:

Use netcdf-4 (hdf5 based) files
Use pnetcdf and old-style netcdf files.

Perhaps the best would be to compile netcdf with pnetcdf support only if petsc 
is configured with exodusii? I can send a patch this afternoon.
Greg Sjaardema, the exodus maintainer, has been very responsive, I will try to 
iron out the last exodus / netcdf-4 bugs, but it sure would be noce to be able 
to read / write old style files too…

Blaise



> On Dec 19, 2017, at 5:32 PM, Smith, Barry F.  wrote:
> 
> 
> 
>> On Dec 19, 2017, at 5:30 PM, Jed Brown  wrote:
>> 
>> Does ExodusII write pnetcdf?  It's a different interface from (parallel)
>> NetCDF4.
> 
>   Shudder!
> 
>> 
>> Matthew Knepley  writes:
>> 
>>> Blaise really wants to write in parallel. It would be better to use HDF5,
>>> but evidently
>>> it is broken in ExodusII. Thats what we get for using something from
>>> Sandia. They
>>> finally have their revenge.
>>> 
>>>  Matt
>>> 
>>> On Tue, Dec 19, 2017 at 5:53 PM, Smith, Barry F.  wrote:
>>> 
 
 Do you really need to use pnetcdf? No one uses it and what usefulness
 does it really provide, best to be avoided.
 
  Barry
 
 
> On Dec 19, 2017, at 1:12 PM, Satish Balay  wrote:
> 
> parallel-netcdf-1.9.0.pre1/INSTALL has:
> 
 
> 
> 4. Reporting Installation or Usage Problems
> ===
> 
> Please send an email to parallel-net...@mcs.anl.gov
> 
> <<
> 
> We'll have to send in these bug reports.
> 
> Satish
> 
> 
> On Tue, 19 Dec 2017, Matthew Knepley wrote:
> 
>> The configure is broken, perhaps beyond fixing. I need to give
 --with-mpi
>> to get anything
>> to work because the way it checks for MPI is screwed up. I will see if I
>> can throw away all its idiotic configure stuff in favor of just telling
 it
>> everything, but I am not eager to depend on something so rickety.
>> 
>> 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/ 
> 

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

[petsc-dev] DMCreateSubDM error

[Blaise A Bourdin]

Hi,

I am building torture test for DMPlex with somewhat complicated dof layout. In 
some situations, DMCreateSubDM fails.

DMUAS has 3 fields corresponding to
U: corresponding to vector-valued P1 or P2 Lagrange FE, Sigma, vector-valued 
cell centered, and Alpha, same element type as U but scalar.
For Tri / Tet, P1 or P2, all is well, but with Quads / Hex and polynomial order 
2, when trying to extract the DM for the (U,alpha) pair of fields, I get a 
"Nonconforming object sizes” error.

Try EXOTest12 -i TwoQuads.exo -order 2 for instance

I am attaching an code illustrating this behavior and three example meshes.

Regards,
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









EXOTest12.c
Description: EXOTest12.c


OneHex8.exo
Description: OneHex8.exo


twobytwo.exo
Description: twobytwo.exo


TwoQuads.exo
Description: TwoQuads.exo

Re: [petsc-dev] BuildSystem: how to prevent 'make clean' before 'make'

[Blaise A Bourdin]

Unfortunately, the weakest assumption is that each package’s build system is 
not screwed up… 

Blaise


> On Nov 29, 2017, at 5:40 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> 
> Sure - there are lots of assumptions in GNUPackage and CMAKEPackage
> [they assume most packages behave similarly wrt these types of builds]
> 
> And one can also override these default routines provided.
> 
> Some pacakges might provide a different 'clean' target. And some might prefer
> VPATH? builds? [i.e mkdir objdir && cd objdir && ../configure && make]. 
> 
> The CMAKE packages default to this mode. Perhaps we need to add this for 
> gnupackages aswell..
> 
> Satish
> 
> On Wed, 29 Nov 2017, Blaise A Bourdin wrote:
> 
>> Thanks.
>> 
>> I understand that it is not optimal. But OTOH, you are also assuming that 
>> make clean does what it is supposed to do…
>> 
>> Blaise
>> 
>> 
>>> On Nov 29, 2017, at 5:29 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
>>> 
>>> Right now there is no provision for this. The following can add it.
>>> 
>>> 
>>>>>>>>>>> 
>>> $ git diff
>>> diff --git a/config/BuildSystem/config/package.py 
>>> b/config/BuildSystem/config/package.py
>>> index 14de19502b..f9a2e68a25 100644
>>> --- a/config/BuildSystem/config/package.py
>>> +++ b/config/BuildSystem/config/package.py
>>> @@ -80,6 +80,7 @@ class Package(config.base.Configure):
>>>self.makerulename   = '' # some packages do too many things with 
>>> the make stage; this allows a package to limit to, for example, just 
>>> building the libraries
>>>self.installedpetsc = 0
>>>self.installwithbatch   = 0  # install the package even though 
>>> configure is running in the initial batch mode; f2blaslapack and 
>>> fblaslapack for example
>>> +self.skipcleanbeforebuild   = 0  # skip running 'make clean' before 
>>> starting a fresh build of a package
>>>return
>>> 
>>>  def __str__(self):
>>> @@ -1322,7 +1323,8 @@ class GNUPackage(Package):
>>>  if self.parallelMake: pmake = self.make.make_jnp+' 
>>> '+self.makerulename+' '
>>>  else: pmake = self.make.make+' '+self.makerulename+' '
>>> 
>>> -  output2,err2,ret2  = config.base.Configure.executeShellCommand('cd 
>>> '+self.packageDir+' && '+self.make.make+' clean', timeout=200, log = 
>>> self.log)
>>> +  if not self.skipcleanbeforebuild:
>>> +output2,err2,ret2  = config.base.Configure.executeShellCommand('cd 
>>> '+self.packageDir+' && '+self.make.make+' clean', timeout=200, log = 
>>> self.log)
>>>  output3,err3,ret3  = config.base.Configure.executeShellCommand('cd 
>>> '+self.packageDir+' && '+pmake, timeout=6000, log = self.log)
>>>  self.logPrintBox('Running make install on '+self.PACKAGE+'; this may 
>>> take several minutes')
>>>  self.installDirProvider.printSudoPasswordMessage(self.installSudo)
>>> <<<<<<<<
>>> 
>>> But then - a dirty build dir might break subsequent builds with the same 
>>> PETSC_ARCH [usually triggered when configure options change]
>>> 
>>> Satish
>>> 
>>> On Wed, 29 Nov 2017, Blaise A Bourdin wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I am trying to get BuildSystem to build pnetcdf (parallel netcdf 
>>>> automatically).
>>>> The build process is very straightforward (configure; make; make install)
>>>> Looking at other packages, I came up with the following for 
>>>> $PETSC_DIR/config/BuildSystem/config/packages/pnetcdf.py
>>>> 
>>>> import config.package
>>>> import os
>>>> 
>>>> class Configure(config.package.GNUPackage):
>>>> def __init__(self, framework):
>>>>   config.package.Package.__init__(self, framework)
>>>>   self.download  = 
>>>> ['http://cucis.ece.northwestern.edu/projects/PnetCDF/Release/parallel-netcdf-1.8.1.tar.gz']
>>>>   self.functions = ['ncmpi_create']
>>>>   self.includes  = ['pnetcdf.h']
>>>>   self.liblist   = [['libpnetcdf.a']]
>>>>   self.downloaddirnames  = ['parallel-netcdf-1.8.1']
>>>>   return
>>>> 
>>>> def setupDependencies(self, framework):
>>>>   config.package.GNUPackage.setupDependencies(self, framework)
>>>>   self.mpi   = framework.require('config.packages.MPI', self)
>>>>   self.deps  = [self.mpi]
>>>>   return
>>>> 
>>>> def formGNUConfigureArgs(self):
>>>>   args = config.package.GNUPackage.formGNUConfigureArgs(self)
>>>>   args.append('LIBS="'+self.compilers.LIBS+'"')
>>>>   return args
>>>> 
>>>> 
>>>> Looking at configure.log, it looks like BuildSystem does a make clean 
>>>> between configure and make
>>>> Unfortunately, there must be something wrong with the parallel-netcdf 
>>>> makefile, as make clean erases some of the files generated by pkgconfig 
>>>> (?), so that make install later fails...
>>>> 
>>>> Is there an easy way to skip the 'make clean' step? 
>>>> 
>>>> 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

Re: [petsc-dev] BuildSystem: how to prevent 'make clean' before 'make'

[Blaise A Bourdin]

Thanks.

I understand that it is not optimal. But OTOH, you are also assuming that make 
clean does what it is supposed to do…

Blaise


> On Nov 29, 2017, at 5:29 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> 
> Right now there is no provision for this. The following can add it.
> 
> 
>>>>>>>>> 
> $ git diff
> diff --git a/config/BuildSystem/config/package.py 
> b/config/BuildSystem/config/package.py
> index 14de19502b..f9a2e68a25 100644
> --- a/config/BuildSystem/config/package.py
> +++ b/config/BuildSystem/config/package.py
> @@ -80,6 +80,7 @@ class Package(config.base.Configure):
> self.makerulename   = '' # some packages do too many things with 
> the make stage; this allows a package to limit to, for example, just building 
> the libraries
> self.installedpetsc = 0
> self.installwithbatch   = 0  # install the package even though 
> configure is running in the initial batch mode; f2blaslapack and fblaslapack 
> for example
> +self.skipcleanbeforebuild   = 0  # skip running 'make clean' before 
> starting a fresh build of a package
> return
> 
>   def __str__(self):
> @@ -1322,7 +1323,8 @@ class GNUPackage(Package):
>   if self.parallelMake: pmake = self.make.make_jnp+' 
> '+self.makerulename+' '
>   else: pmake = self.make.make+' '+self.makerulename+' '
> 
> -  output2,err2,ret2  = config.base.Configure.executeShellCommand('cd 
> '+self.packageDir+' && '+self.make.make+' clean', timeout=200, log = self.log)
> +  if not self.skipcleanbeforebuild:
> +output2,err2,ret2  = config.base.Configure.executeShellCommand('cd 
> '+self.packageDir+' && '+self.make.make+' clean', timeout=200, log = self.log)
>   output3,err3,ret3  = config.base.Configure.executeShellCommand('cd 
> '+self.packageDir+' && '+pmake, timeout=6000, log = self.log)
>   self.logPrintBox('Running make install on '+self.PACKAGE+'; this may 
> take several minutes')
>   self.installDirProvider.printSudoPasswordMessage(self.installSudo)
> <<<<<<<<
> 
> But then - a dirty build dir might break subsequent builds with the same 
> PETSC_ARCH [usually triggered when configure options change]
> 
> Satish
> 
> On Wed, 29 Nov 2017, Blaise A Bourdin wrote:
> 
>> Hi,
>> 
>> I am trying to get BuildSystem to build pnetcdf (parallel netcdf 
>> automatically).
>> The build process is very straightforward (configure; make; make install)
>> Looking at other packages, I came up with the following for 
>> $PETSC_DIR/config/BuildSystem/config/packages/pnetcdf.py
>> 
>> import config.package
>> import os
>> 
>> class Configure(config.package.GNUPackage):
>>  def __init__(self, framework):
>>config.package.Package.__init__(self, framework)
>>self.download  = 
>> ['http://cucis.ece.northwestern.edu/projects/PnetCDF/Release/parallel-netcdf-1.8.1.tar.gz']
>>self.functions = ['ncmpi_create']
>>self.includes  = ['pnetcdf.h']
>>self.liblist   = [['libpnetcdf.a']]
>>self.downloaddirnames  = ['parallel-netcdf-1.8.1']
>>return
>> 
>>  def setupDependencies(self, framework):
>>config.package.GNUPackage.setupDependencies(self, framework)
>>self.mpi   = framework.require('config.packages.MPI', self)
>>self.deps  = [self.mpi]
>>return
>> 
>>  def formGNUConfigureArgs(self):
>>args = config.package.GNUPackage.formGNUConfigureArgs(self)
>>args.append('LIBS="'+self.compilers.LIBS+'"')
>>return args
>> 
>> 
>> Looking at configure.log, it looks like BuildSystem does a make clean 
>> between configure and make
>> Unfortunately, there must be something wrong with the parallel-netcdf 
>> makefile, as make clean erases some of the files generated by pkgconfig (?), 
>> so that make install later fails...
>> 
>> Is there an easy way to skip the 'make clean' step? 
>> 
>> 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

[petsc-dev] BuildSystem: how to prevent 'make clean' before 'make'

[Blaise A Bourdin]

Hi,

I am trying to get BuildSystem to build pnetcdf (parallel netcdf automatically).
The build process is very straightforward (configure; make; make install)
Looking at other packages, I came up with the following for 
$PETSC_DIR/config/BuildSystem/config/packages/pnetcdf.py

import config.package
import os

class Configure(config.package.GNUPackage):
  def __init__(self, framework):
config.package.Package.__init__(self, framework)
self.download  = 
['http://cucis.ece.northwestern.edu/projects/PnetCDF/Release/parallel-netcdf-1.8.1.tar.gz']
self.functions = ['ncmpi_create']
self.includes  = ['pnetcdf.h']
self.liblist   = [['libpnetcdf.a']]
self.downloaddirnames  = ['parallel-netcdf-1.8.1']
return

  def setupDependencies(self, framework):
config.package.GNUPackage.setupDependencies(self, framework)
self.mpi   = framework.require('config.packages.MPI', self)
self.deps  = [self.mpi]
return

  def formGNUConfigureArgs(self):
args = config.package.GNUPackage.formGNUConfigureArgs(self)
args.append('LIBS="'+self.compilers.LIBS+'"')
return args


Looking at configure.log, it looks like BuildSystem does a make clean between 
configure and make
Unfortunately, there must be something wrong with the parallel-netcdf makefile, 
as make clean erases some of the files generated by pkgconfig (?), so that make 
install later fails...

Is there an easy way to skip the 'make clean' step? 

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

Re: [petsc-dev] DMplex: Natural Ordering and subDM

[Blaise A Bourdin]

> On Nov 28, 2017, at 12:39 AM, Jed Brown <j...@jedbrown.org> wrote:
> 
> Blaise A Bourdin <bour...@lsu.edu> writes:
> 
>> There may be good reasons to want to read / write in a given ordering:  
>> post-processing an existing computation, applying non trivial boundary 
>> conditions that need to be computed separately, or restarting a computation 
>> on a different number of processors.
>> Also, Exodus has restriction on cell ordering (cells in an element block 
>> must be numbered sequentially) so the distributed cell ordering may not be 
>> acceptable.
> 
> Does PETSc have the ability to write Exodus files?  Yes, if this is a
> requirement then that viewer needs to reorder in some way to write.
> 
> For concreteness, what postprocessors are you thinking about here that
> need an ordering that matches that of the input file?  (I ask because I
> usually see the simulation writing a different format from the input
> file, and often viewed using different tools.)

I have a bunch that I wrote myself. For example: computing stress intensity 
factor using the G_theta method. This involves computing integrals but not 
solving linear systems, it can be run on a much smaller system than the 
analysis itself. It would be a pain to have to move back the data file to a 
large syste and requeue in order to get the same parallel layout.

But the main difficulty with exodus is that the distributed cell ordering is 
not necessarily admissible for exodus element blocks, and that exodus cell sets 
are not implemented in most tools... Fine elements file formats are a mess and 
there are very few formats for which mesh generator, visualization, and I/O 
library are available.

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

[petsc-dev] DMplex: Natural Ordering and subDM

[Blaise A Bourdin]

Hi,
I am fighting with natural ordering in DMplex with multi-fields / multi 
components DM.
I need to read / write files in a distribution-independent ordering. The 
natural way to do so is to define the natural ordering as that of the file, 
then call DMPlexGlobalToNaturalBegin/End before VecView:
The pseudo code would be

  DMPlexCreateFromFile(PETSC_COMM_WORLD,ifilename,interpolate,);
  // create default section associated with a complicated layout of multiple 
fields 
  // (U,\alpha,\sigma)
  DMSetUseNatural(dmUAS,PETSC_TRUE);
  DMPlexDistribute(dmUAS,0,,);

  DMGetGlobalVector(dmDist,);
  DMGetGlobalVector(dmDist,);
  DMPlexGlobalToNaturalBegin(dmDist,UAS,UASNatural);
  DMPlexGlobalToNaturalEnd(dmDist,UAS,UASNatural);
  // Do my I/O stuff using UASNatural

If I try to do the same thing one field at a time, things break:
Say that I get the subDM for the first field (U):

  DMCreateSubDM(dmDist,1,,,);

Then dmU->useNatural is PETSC_FALSE and  I cannot compute dmU->sfnatural using 
DMPlexCreateGlobalToNaturalSF since I do not have the “sequential” version of 
dmU.

What is the proper way to handle this situation? Creating sequential subDMs and 
calling DMDistribute on each of them is ugly and possibly costly.

Regards,

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

[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] One DM two SNES

[Blaise A Bourdin]

On Nov 1, 2017, at 7:46 PM, Jed Brown 
<j...@jedbrown.org<mailto:j...@jedbrown.org>> wrote:

Matthew Knepley <knep...@gmail.com<mailto:knep...@gmail.com>> writes:

On Wed, Nov 1, 2017 at 6:50 PM, Blaise A Bourdin 
<bour...@lsu.edu<mailto:bour...@lsu.edu>> wrote:

Hi,

I have just spent 2h helping a student debugging a code, and I think that
the problem is not ours…
See the attached example: 1 create 1 DM and 2 SNES.
If I assign the same DM to both SNES, the function and Jacobean of the
second are ignored, and the first one is used.
Replace the block l 138 - l. 149 with the one commented above, and the
result is even weirder.

Is this the intended behavior? If so, should there be a note of this
behavior in the SNESSetDM man page?

You can DMClone() when solving the other problem.

I am not sure I understand everything this is doing, but I want to make an
upfront point:

 SNESSetFunction() is intended for use without a DM

When the solver has a DM, we intend you to use

 DMSNESSetFunctionLocal() and DMSNESSetJacobianLocal()

This doesn't really matter -- SNESSetFunction just calls
DMSNESSetFunction.  Getting rid of SNESSetFunction would save the
confusion but break every existing PETSc code.

However, now I think I see what is happening. The DMSNES is a structure
that is intended to mediate between the solver
and mesh. When you do SNESSetDM(), it copies over the DMSNES context. This
context is already holding the formfunction
and formjacobian pointers. Yes, this is confusing.

Jed, how should this be documented?

I don't know of a simple rule to prevent this in code.  You can have
several SNES that are "related" in the sense that they help solve a
given problem (nonlinear preconditioners, for example) and they can
share a DM.  If you are solving different problems, you need to create a
different DM.  Does this documentation help?

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

Yes, I think it does. How about adding a  statement in the main DM man page 
stating that each field should get its SNES and its DM, possibly through 
cloning a main DM?
I should have thought about it.

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

[petsc-dev] One DM two SNES

[Blaise A Bourdin]

Hi,

I have just spent 2h helping a student debugging a code, and I think that the 
problem is not ours…
See the attached example: 1 create 1 DM and 2 SNES.
If I assign the same DM to both SNES, the function and Jacobean of the second 
are ignored, and the first one is used.
Replace the block l 138 - l. 149 with the one commented above, and the result 
is even weirder.

Is this the intended behavior? If so, should there be a note of this behavior 
in the SNESSetDM man page?

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









twosnes.c
Description: twosnes.c

Re: [petsc-dev] Segfault in DMPlexVecGetClosure

[Blaise A Bourdin]

On Oct 31, 2017, at 12:39 PM, Matthew Knepley 
<knep...@gmail.com<mailto:knep...@gmail.com>> wrote:

On Tue, Oct 31, 2017 at 11:36 AM, Blaise A Bourdin 
<bour...@lsu.edu<mailto:bour...@lsu.edu>> wrote:
Hi,

I am losing my mind over segfaults in DMPlexVecGetClosure.

In the example below, I get a segfault whenever cval is not set to NULL before 
calling DMPlexVecGetClosure. Is this expected?

Yes. If cval is NULL, it allocates the necessary space and passes back the 
array. If it is not NULL, it uses the pointer that you passed
in (so you can allocate your own temp storage if you are smarter).

The documentations says nothing about this

That is a problem.

Also, after calling DMPlexVecRestoreClosure, the values of cval are discarded 
and neither global nor coord are changed.

Ah, GetClosure() is not like GetArray(), in that it is a temp copy. You need 
SetClosure() in order to change values.

So DMPlexVecGetClosure / DMPlexVecRestoreClosure behaves more like 
ISCreateGeneral / ISDestroy than as a standard PETSc XXXGet / XXXRestore.

I’ll do my best to submit a pull request with an updated man page and an 
example.

Blaise


   Matt

I am obviously doing something wrong but cannot figure it out...

Blaise


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










--
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/<http://www.caam.rice.edu/~mk51/>

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

[petsc-dev] Segfault in DMPlexVecGetClosure

[Blaise A Bourdin]

Hi,

I am losing my mind over segfaults in DMPlexVecGetClosure.

In the example below, I get a segfault whenever cval is not set to NULL before 
calling DMPlexVecGetClosure. Is this expected? The documentations says nothing 
about this
Also, after calling DMPlexVecRestoreClosure, the values of cval are discarded 
and neither global nor coord are changed.

I am obviously doing something wrong but cannot figure it out...

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









EXOTest7.c
Description: EXOTest7.c


out2.gen
Description: out2.gen

[petsc-dev] VecView HDF5 read / write partial array

[Blaise A Bourdin]

Hi,

Recent versions of exodus are implemented with netcdf4, which is based on hdf5.
Instead of going through the process of rewriting exodus viewers, I would like 
to use PETSc’s HDF5 I/O operations.
Problem is that as far as I can understand, exodus / netcdf does not use hdf5 
time steps. Instead, it writes a single vector containing all values of a field 
at all time steps.
(i.e. if vij denotes the i^th component of v at time step j, v is written as a 
single array v11, v21, v31, . . ., v12, v22, v32, . . ., v13, v23,  . . .) and 
so on).
Is there a way to use VecView hdf5 to read/write only entries kn:(k+1)n-1 in an 
hdf5 file?

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

[petsc-dev] petsc makefiles

[Blaise A Bourdin]

Hi,

Is there a way in petsc makefiles to figure out how to link a shared / dynamic 
library
i.e. if I want to know how to do 
$CC -shared *.o lib.so
vs.
$CC -dynamiclib *.o lib.dylib
what variable gives me the extension .so vs .dylib and the linker option 
-shared vs -dynamiclib

How about doing the same thing in BuildSystem (I need to build a shared library 
for exodus)?

Also, is there a way to know the family of compiler I am using (gnu vs intel vs 
something else)?
The long line fortran compiler options for fortran and ifort are of course 
different, and the default behavior opposite…

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

Re: [petsc-dev] Get/Restore vs Create/Destroy

[Blaise A Bourdin]

> On Jul 20, 2017, at 1:20 PM, Barry Smith <bsm...@mcs.anl.gov> wrote:
> 
> 
>  Let us know of specific cases that your feel violate the intended paradigm.


I was missing the fact that a Restore operation is not always needed, hence my 
confusion.
I think that it would be helpful to flag these in the documentation. I will do 
my best to locate these and send in a patch

Blaise



> 
>   Barry
> 
>> On Jul 20, 2017, at 10:15 AM, Matthew Knepley <knep...@gmail.com> wrote:
>> 
>> On Thu, Jul 20, 2017 at 9:25 AM, Blaise A Bourdin <bour...@lsu.edu> wrote:
>> Hi,
>> 
>> It’s always been my understanding that and pets object obtained by a 
>> XXXGetYYY had to be released with a matching XXXRestoreYYY, and that those 
>> created using XXXCreateYYY had to be destroyed with a YYYDestroy.
>> 
>> It seems that this convention is getting broken in several place. I 
>> understand that in several situations, this is because the XXXRestoreYYY 
>> would essentially do nothing.
>> 
>> Is it safe to assume that if a function XXXGetYYY does not have a matching 
>> XXXRestoreYYY, the instance of PetscYYY does not have to be destroyed in any 
>> way?
>> 
>> Yes. We use Get in two ways:
>> 
>>  1) Get a borrowed reference. Then nothing has to be done
>> 
>>  2) Get a reference which need extra processing. This requires a matching 
>> Restore
>> 
>> Is it safe to assume that any instance of a PetscYYY created from 
>> XXXCreateYYY can be safely destroyed with a YYYDestroy without side effects?
>> 
>> Yes.
>> 
>> If so, should the offending functions be renamed or should something be 
>> explicitly added to their man page?
>> 
>> We try to always have the matching restore on the manpage. If it is not, we 
>> should fix it.
>> 
>>  Thanks,
>> 
>>Matt
>> 
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> 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
>> 
>> http://www.caam.rice.edu/~mk51/
> 

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

[petsc-dev] Get/Restore vs Create/Destroy

[Blaise A Bourdin]

Hi,

It’s always been my understanding that and pets object obtained by a XXXGetYYY 
had to be released with a matching XXXRestoreYYY, and that those created using 
XXXCreateYYY had to be destroyed with a YYYDestroy.

It seems that this convention is getting broken in several place. I understand 
that in several situations, this is because the XXXRestoreYYY would essentially 
do nothing.

Is it safe to assume that if a function XXXGetYYY does not have a matching 
XXXRestoreYYY, the instance of PetscYYY does not have to be destroyed in any 
way?
Is it safe to assume that any instance of a PetscYYY created from XXXCreateYYY 
can be safely destroyed with a YYYDestroy without side effects?

If so, should the offending functions be renamed or should something be 
explicitly added to their man page?

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

Re: [petsc-dev] PetscDataTypeGetSize fortran binding is gone?

[Blaise A Bourdin]

Great, thanks

> On Jul 14, 2017, at 4:53 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> 
> Added - and merged to next.
> 
> satish
> 
> On Fri, 14 Jul 2017, Blaise A Bourdin wrote:
> 
>> Got it. It works.
>> 
>> While you are at it, would you minding adding the binding for 
>> PetscOptionsLeft.
>> I am attaching the patch,
>> 
>> diff --git a/src/sys/objects/ftn-custom/zoptionsf.c 
>> b/src/sys/objects/ftn-custom/zoptionsf.c
>> index 65d64b1580..9d36bc2d4d 100644
>> --- a/src/sys/objects/ftn-custom/zoptionsf.c
>> +++ b/src/sys/objects/ftn-custom/zoptionsf.c
>> @@ -24,6 +24,7 @@
>> #define petscoptionsclear_ PETSCOPTIONSCLEAR
>> #define petscoptionsinsertstring_  PETSCOPTIONSINSERTSTRING
>> #define petscoptionsview_  PETSCOPTIONSVIEW
>> +#define petscoptionsleft_  PETSCOPTIONSLEFT
>> #define petscobjectviewfromoptions_PETSCOBJECTVIEWFROMOPTIONS
>> #elif !defined(PETSC_HAVE_FORTRAN_UNDERSCORE)
>> #define petscoptionsgetenumprivate_petscoptionsgetenumprivate
>> @@ -42,6 +43,7 @@
>> #define petscoptionsclear_ petscoptionsclear
>> #define petscoptionsinsertstring_  petscoptionsinsertstring
>> #define petscoptionsview_  petscoptionsview
>> +#define petscoptionsleft_  petscoptionsleft
>> #define petscobjectviewfromoptions_petscobjectviewfromoptions
>> #endif
>> 
>> 
>> 
>> @@ -254,6 +256,12 @@ PETSC_EXTERN void PETSC_STDCALL 
>> petscoptionsview_(PetscOptions *options,PetscVie
>>   *ierr = PetscOptionsView(*options,v);
>> }
>> 
>> 
>> 
>> +PETSC_EXTERN void PETSC_STDCALL petscoptionsleft_(PetscOptions 
>> *options,PetscErrorCode *ierr)
>> +{
>> + CHKFORTRANNULLOBJECTDEREFERENCE(options);
>> +  *ierr = PetscOptionsLeft(*options);
>> +}
>> +
>> PETSC_EXTERN void PETSC_STDCALL petscobjectviewfromoptions_(PetscObject 
>> *obj,PetscObject *bobj,char* option PETSC_MIXED_LEN(loption),PetscErrorCode 
>> *ierr  PETSC_END_LEN(loption))
>> {
>>   char *o;
>> 
>> 
>> Blaise
>> 
>> On Jul 14, 2017, at 3:54 PM, Satish Balay 
>> <ba...@mcs.anl.gov<mailto:ba...@mcs.anl.gov>> wrote:
>> 
>> include/petscsys.h:PETSC_EXTERN PetscErrorCode 
>> PetscDataTypeGetSize(PetscDataType,size_t*);
>> 
>> Looks like this needs a custom stub due to 'size_t' parameter.
>> 
>> I've aded the custom interface to balay/add-ftn-PetscDataTypeGetSize. Can 
>> you give it a try?
>> 
>> You would have to use a datatype that matches 'size_t' on the fortran size - 
>> i.e PetscSizeT.
>> 
>> Satish
>> 
>> On Fri, 14 Jul 2017, Blaise A Bourdin wrote:
>> 
>> Hi,
>> 
>> It looks like the fortran binding for PetscDataTypeGetSize was removed a 
>> while ago. Evidently, auto generated binding won’t work here.
>> I’m a bit out of sync with the recent fortran changes, but why are 
>> automatically generated binding not working anymore, and what should the 
>> proper binding look like?
>> 
>> Alternatively, is there a new recommended way to query the size of a Petsc 
>> type from fortran?
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 

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

[petsc-dev] PetscDataTypeGetSize fortran binding is gone?

[Blaise A Bourdin]

Hi,

It looks like the fortran binding for PetscDataTypeGetSize was removed a while 
ago. Evidently, auto generated binding won’t work here.
I’m a bit out of sync with the recent fortran changes, but why are 
automatically generated binding not working anymore, and what should the proper 
binding look like?

Alternatively, is there a new recommended way to query the size of a Petsc type 
from fortran?

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

Re: [petsc-dev] higher-order coordiate fields in DMPlex

[Blaise A Bourdin]

Hi,
Do you have a link for the MED format description and implementation?
The problem with FE file format is that unless they are supported by mesh 
generators and visualization software, they are just nice toys...

Blaise


> On Jun 2, 2017, at 11:21 PM, Vijay S. Mahadevan  wrote:
> 
>>> Can Cubit produce MED or be converted to MED?  I haven't used it, but it
>>> sounds like there is some mesh generation software available for it.
> 
> Cubit does not support MED out of the box (as of 15.0). They may have
> a plugin, not sure.
> 
>> Gmsh can convert anything it can read to MED I believe.
> 
> I have not used meshes in MED format but I think it doesn't
> handle/represent solid geometries.
> 
> GMsh uses OpenCascade primarily under the hood. AFAIK, they've been
> using it for a while. So they should be able to load step/brep/iges
> format through the OCC interface. But if we are talking about meshes,
> then they may have a MED format writer that preserves second-order
> accuracy in meshes. In which case, their native "msh" format may
> support this too.
> 
> Vijay
> 
> On Fri, Jun 2, 2017 at 9:56 PM, Matthew Knepley  wrote:
>> On Fri, Jun 2, 2017 at 9:45 PM, Jed Brown  wrote:
>>> 
>>> Matthew Knepley  writes:
>>> 
 On Fri, Jun 2, 2017 at 8:38 PM, Jed Brown  wrote:
 
> Matthew Knepley  writes:
> 
>> On Fri, Jun 2, 2017 at 7:55 PM, Jed Brown  wrote:
>> 
>>> Matthew Knepley  writes:
>>> 
 On Fri, Jun 2, 2017 at 5:04 PM, Alberto Paganini <
 alberto.pagan...@maths.ox.ac.uk> wrote:
 
> Dear PETSc developers,
> 
> I'm Alberto and I'm a user of the finite element library
> Firedrake,
> which relies on DMPlex to import meshes.
> 
 
 Great.
 
 
> In order to use higher-order FEs, it is desirable to import
> higher-order
> meshes.
> 
 
 I really do not like that term. Let me try and convince you that
 it is
 wrong. The topology of the
 mesh is unchanged. You are only talking about the order of the
 representation of the geometry
 field. Thus, it is not the mesh that is "higher order", but the
> geometry.
 
 
> I've been told that DMPlex does not offer this future (at
> present).
> 
 
 Toby just merged this to master, so I think we can say that we
 have
> alpha
 support for this. How
 does it work? We already have a coordinateDM and coordinates Vec,
 so
> you
 just choose a
 higher order discretization for the DS inside the coordinateDM.
 Does
> that
 make sense?
>>> 
>>> Can it load quadratic geometry from a file (ExodusII or otherwise)?
>>> 
>> 
>> If someone requests a given file format, we can do it. That's how we
> always
>> proceed.
> 
> Okay.  When people ask about higher order geometry for unstructured
> finite elements, I think that about 90% of the time they're really
> asking whether it can read quadratic geometry from a file.  I hate that
> ExodusII is a cumbersome dependency, but it might be the most useful to
> add.  This wouldn't be just cosmetically checking a box because this
> can
> make a big accuracy difference -- quadratic elements have a really hard
> time paying off for engineering problems if you don't also have
> quadratic geometry.
> 
 
 ExodusII is perhaps the shittiest mesh format in existence.
>>> 
>>> NASTRAN, ABAQUS, and the like are a pleasure by comparison?
>> 
>> 
>> It seems there is room at the top of the mountain of shit.
>> 
>>> 
 For example, if we start reading ExodusII files with high order
 geometry, that fucks up their definition of the topology because now
 they only report C, the number of cells, and V+E+F, the number of
 vertices and edges and faces. We could get lucky and have vertices
 contiguous, but I cannot find anything in the manual that mandates
 this. So we would overallocate, then reduce down to the right
 topology, screwing up our fairly straightforward code right now.
 
 I would recommend the only non-stupid format I can name right now, the
 MED format from the French CAD guys. Gmsh has switched over to using
 it since their own format sucked worse than ExodusII. That is the only
 one that it makes sense to write new code for.
>>> 
>>> Can Cubit produce MED or be converted to MED?  I haven't used it, but it
>>> sounds like there is some mesh generation software available for it.
>> 
>> 
>> Gmsh can convert anything it can read to MED I believe.
>> 
>>   Matt
>> 
>> --
>> What most experimenters take for granted before they begin their 

[petsc-dev] Missing fortran type

[Blaise A Bourdin]

Hi,

It looks like the tMatStencil fortran data type does not exist. Is it an 
oversight or is there a reason?

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

Re: [petsc-dev] fortran literals

[Blaise A Bourdin]

Neat.
I was not aware of this.

Blaise

> On Sep 1, 2016, at 9:26 PM, Jeff Hammond <jeff.scie...@gmail.com> wrote:
> 
> https://gcc.gnu.org/onlinedocs/gfortran/ISO_005fFORTRAN_005fENV.htmlhas 
> real{32,64,128} that does a nice job for this situation. 
> 
> Jeff
> 
> Sent from my iPhone
> 
>> On Sep 1, 2016, at 4:15 PM, Blaise A Bourdin <bour...@lsu.edu> wrote:
>> 
>> Hi,
>> 
>> If I recall correctly, fortran does not mandate that "selected_real_kind(5)" 
>> means the same across compilers, so that hardcoding kind values may not be 
>> portable.
>> 
>> 
>> Instead, I would recommend the following (not my idea, it was proposed by 
>> Michael Metcalf in comp.lang.fortran a _long_ time ago) in a top-level 
>> module.
>> 
>>  ! The following ensures that mef90 and PETSC real types are compatible:
>>  ! thanks to Michael Metcalf in comp.lang.fortran
>>  PetscReal,Parameter :: PReal = 1.0
>>  Integer,Parameter,Public:: Kr = 
>> Selected_Real_Kind(Precision(PReal))
>> 
>>  PetscInt,Parameter  :: PInt = 1
>>  Integer,Parameter,Public:: Ki = Selected_Int_Kind(PInt)
>> 
>>  PetscLogDouble,Parameter:: flop = 1.0
>>  Integer,Parameter,Public:: PFlop = 
>> Selected_Real_Kind(Precision(flop))
>> 
>> so that Real(Kind = Kr) is the same as PetscReal, and literals can be 
>> written 1.234_Kr or 23_flop.
>> 
>> I guess PETSc could define them in the petsc module and inherited from "use 
>> petsc”. 
>> 
>> Blaise
>> 
>> 
>> 
>>> On Sep 1, 2016, at 5:37 PM, Barry Smith <bsm...@mcs.anl.gov> wrote:
>>> 
>>> 
>>>> On Sep 1, 2016, at 5:28 PM, Munson, Todd <tmun...@mcs.anl.gov> wrote:
>>>> 
>>>> 
>>>> Which platforms do not define PETSC_USE_FORTRANKIND?
>>> 
>>> It uses it everywhere the Fortran compiler supports it. 
>>> 
>>> # reverse of the above - but more standard thing to do for F90 compilers
>>> def checkFortranKind(self):
>>>  '''Checks whether selected_int_kind etc work USE_FORTRANKIND'''
>>>  self.pushLanguage('FC')
>>>  body = '''
>>>  integer(kind=selected_int_kind(10)) i
>>>  real(kind=selected_real_kind(10)) d
>>> '''
>>>  if self.checkCompile('', body):
>>>self.addDefine('USE_FORTRANKIND', 1)
>>>  self.popLanguage()
>>>  return
>>> 
>>> Presumably any Fortran compiler that supports F90 supports it so it is not 
>>> unreasonable for us to just require it and simplify PETSc in a few places.
>>> 
>>> 
>>> 
>>> 
>>>> Are they important
>>>> or can we drop support for them?
>>>> 
>>>> I could probably hack the D or Q for the others, but it would probably
>>>> be ugly.
>>>> 
>>>> Or I could just overrule my OCD today...
>>>> 
>>>> Todd.
>>>> 
>>>>> On Sep 1, 2016, at 5:08 PM, Barry Smith <bsm...@mcs.anl.gov> wrote:
>>>>> 
>>>>> 
>>>>>> On Sep 1, 2016, at 4:37 PM, Munson, Todd <tmun...@mcs.anl.gov> wrote:
>>>>>> 
>>>>>> 
>>>>>> Cool!
>>>>>> 
>>>>>> For what its worth, that only works when PETSC_USE_FORTRANKIND is true.
>>>>>> I'm not sure how many of the Petsc builds have this flag set.
>>>>> 
>>>>> in the other case could you try to tack on the D or Q business? 
>>>>> 
>>>>> Barry
>>>>> 
>>>>>> 
>>>>>> Any idea how to do the same thing in C?
>>>>>> 
>>>>>> Todd.
>>>>>> 
>>>>>>> On Sep 1, 2016, at 4:13 PM, Lisandro Dalcin <dalc...@gmail.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On 1 September 2016 at 23:05, Barry Smith <bsm...@mcs.anl.gov> wrote:
>>>>>>> I didn't have a solution to this
>>>>>>> 
>>>>>>> ! These lines should be added to 
>>>>>>> $PETSC_DIR/include/petsc/finclude/petscsysdef.h
>>>>>>> #if defined(PETSC_USE_REAL_SINGLE)
>>>>>>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(5)
>>>>>>> #elif defined(PETSC_USE_REAL_DOUBLE)
>>>>>>> integer, parame

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS

[Blaise A Bourdin]

> On Sep 22, 2015, at 11:16 PM, Satish Balay <ba...@mcs.anl.gov> wrote:
> 
> On Tue, 22 Sep 2015, Blaise A Bourdin wrote:
> 
>> With the later configuration, it looks like what matters is the order in 
>> which  -lmpifort and -lifcore are listed:
>> This one works:
>> mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress 
>> -Wl,-commons,use_dylibs -Wl,-search_paths_first   -g -O0  
>> -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o 
>> -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib 
>> -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib  -lpetsc 
>> -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib
>>  -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
>> -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib 
>> -lifcore -lmpifort
>> 
>> This one does not:
>> mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress 
>> -Wl,-commons,use_dylibs -Wl,-search_paths_first   -g -O0  
>> -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o 
>> -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib 
>> -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib  -lpetsc 
>> -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib
>>  -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
>> -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib 
>> -lmpifort -lifcore
> 
> Does linking with -lifcore vs
> /opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a
> make a difference?
It does. When I specify the path explicitly, the build works, regardless of the 
order in which libmpifort and libifcore are listed. 
> 
> And what do you have for:
> 
> cd /opt/HPC/mpich-3.1.4-intel16.0/lib
> ls
> nm -Ao libmpiifort.* |grep get_command_argument
This gives nothing at all:
bourdin@galerkin:lib $ nm -Ao lib* |grep -i command
bourdin@galerkin:lib $ 


> 
> BTW: I'm assuming you have sept 20 or newer petsc master branch.

Yes. I have checked out your changes before testing.

Out of curiosity: it looks like linking with -lpetsc is enough, so why use this 
very complicated link command?
i.e. this is enough to produce a perfectly fine binary:
mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress 
-Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0  
-I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o 
-Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib 
-L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib  -lpetsc


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

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS

[Blaise A Bourdin]

_2016.0.083/mac/compiler/lib 
-L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
-Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
-L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -limf 
-Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
-L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -lsvml 
-Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
-L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -lirng 
-Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
-L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -lipgo 
-Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
-L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -ldecimal 
-lc++ -lSystem 
-Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
-L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -lirc 
-Wl,-rpath,/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin
 
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin
 -lclang_rt.osx -Wl,-rpath,/opt/HPC/mpich-3.1.4-intel16.0/lib 
-L/opt/HPC/mpich-3.1.4-intel16.0/lib 
-Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
-L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
-Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib 
-L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib 
-Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib 
-L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -ldl

this works, but switch the order of libmpifort and libifcore, and it does not 
anymore. (don’t ask me how I noticed!)

Blaise



Intel compilers (esp on Mac) had workarrounds to system issues encoded
in the link command. [I remember the first generation of intel
compilers on Mac had such issues]. And the way PETSc configure, and
checkFortranLibraries() process/use this 'ifort -v' info can break
these encoded workarrounds.. [Its a hacky piece of code - and not easy
to get right]

Ideally compilers should provide equivalent of 'mpicc -show' - so that
configure tools can grab and use this info for language interoperable
linking.

[Jed suggested we should 'always use FC as linker' and not do any such
detection.  But then we still have to worry about C++. Previously we
had machines where we had to use C++ linker - but perhaps such
machines don't exist anymore]

Satish


On Tue, 22 Sep 2015, Richard Mills wrote:

Blaise and Satish,

I'm a bit slow to pick up on this thread as I was busy traveling, but since
I use a Mac and work for Intel, I thought I should see if I could reproduce
the problems that Blaise is seeing.  I installed the 16.0 compilers and
built a simple configuration ('--with-debugging=1 COPTFLAGS="-g -O0"
FOPTFLAGS="-g -O0" CXXOPTFLAGS="-g -O0"
--with-blas-lapack-dir=/opt/intel/compilers_and_libraries_2016/mac/mkl
--with-mpi-dir=/Users/rtmills/packages/mpich-3.1.4-intel') using a very
recent revision of 'master' (09b4d96fa5749f82a0af9a914729f77a4ef2b2fd, Sun
Sep 20 22:51:31 2015 -0500).  When I try running SNES ex5f and passing
various command-line options, everything appears to work fine.  Any
suggestions for digging deeping into this to try to determine the
difference between what Blaise and I are seeing?

Best regards,
Richard

On Mon, Sep 21, 2015 at 10:21 AM, Blaise A Bourdin 
<bour...@lsu.edu<mailto:bour...@lsu.edu>> wrote:


On Sep 20, 2015, at 9:04 AM, Satish Balay 
<ba...@mcs.anl.gov<mailto:ba...@mcs.anl.gov>> wrote:

Hm - I would suggest doing a minimal build build with:

--with-cxx=0
--with-clib-autodetect=0 --with-fortranlib-autodetect=0
LIBS="/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a"

And see if that makes a difference.
Satish,

It does help.
Turning off auto detect leads to a functional build, turning it back on
leads to a non-functioning one.

The configure.log without auto detect is here:

https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/61967j4XaVp
The one with auto detect there:
  https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/691pPOSRU

The petscconf.h are attached





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

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS

[Blaise A Bourdin]

Hi,

I was traveling and did not have time to finish investigating, but there seems 
to be an issue with fortran get_command_argument and friends in mixed language 
mode. I will continue to investigate and will report back.

Blaise

> On Sep 19, 2015, at 10:18 AM, Satish Balay <ba...@mcs.anl.gov> wrote:
> 
> [from the available logs] its not clear what the issue is.
> 
> PETSc fortran interface attempts to use getarg_() and iargc_() [fortran
> library functions] - or its variants - directly from C.
> 
> This usage is non-standard and messy [and some compiler folks - said -
> its unsupported usage].
> 
> Also - configure attempts to guess the fortran link libraries - and
> constructs a link command cCompilerLibs + cxxCompilerLibs +
> fortranCompilerLibs.
> 
> Perhaps there is a bug in this detection code - thats triggering this
> error. Its verifyable by attempting to use:
> 
> --with-clib-autodetect=0 --with-clib-autodetect=0 --with-cxxlib-autodetect=0 
> LIBS='liblist'
> 
> where 'liblist' should be determined manually - for the linking of
> C/fortran/CXX to work correctly.
> 
> My fix attempts to call command_argument_count(),
> get_command_argument() directly from fortran - and if that doesn't
> work - then its likely a compiler bug..
> 
> [which one can try to replicate with a simple test code]
> 
> Satish
> 
> On Thu, 17 Sep 2015, Jeff Hammond wrote:
> 
>> Please report this via premier.intel.com.
>> 
>> Jeff
>> 
>> On Wed, Sep 16, 2015 at 11:13 AM, Blaise A Bourdin <bour...@lsu.edu> wrote:
>> 
>>> Hi,
>>> 
>>> I am testing intel 16 compilers under mac OS, and notice that options
>>> handling for all past and current versions of petsc is broken in fortran
>>> (options are not parsed).
>>> I narrowed it down to *argc at start.c:168 always being 0 when intel 16 is
>>> used (but taking the right value using intel 15 or gcc 5), but I can’t find
>>> my way through the multiple macros to figure out what is really the matter…
>>> The problem does not seem to arise under linux with the same compilers.
>>> 
>>> Any idea of what is going on? Any test I can run to help (I assume that
>>> you don’t have a test box with the latest intel compilers)? Is it a petsc
>>> bug or an intel bug?
>>> 
>>> I use an up to date pets-dev master, and the configure.log file is
>>> available at
>>> https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/89329uFByT9
>>> 
>>> Thanks,
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 

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

[petsc-dev] broken options handling with intel 16.0 compilers on mac OS

[Blaise A Bourdin]

Hi,

I am testing intel 16 compilers under mac OS, and notice that options handling 
for all past and current versions of petsc is broken in fortran (options are 
not parsed).
I narrowed it down to *argc at start.c:168 always being 0 when intel 16 is used 
(but taking the right value using intel 15 or gcc 5), but I can’t find my way 
through the multiple macros to figure out what is really the matter…
The problem does not seem to arise under linux with the same compilers.

Any idea of what is going on? Any test I can run to help (I assume that you 
don’t have a test box with the latest intel compilers)? Is it a petsc bug or an 
intel bug?

I use an up to date pets-dev master, and the configure.log file is available at 
https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/89329uFByT9

Thanks,

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

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS

[Blaise A Bourdin]

Hi Satish,

It is at 
https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/38806CDddLJ

> On Sep 16, 2015, at 10:34 AM, Satish Balay <ba...@mcs.anl.gov> wrote:
> 
> Do you have configure.log fr intel-15 compiler - on the same machine?
> 
> It would be good to compare petscconf.h between intel-15 and intel-16.

bourdin@galerkin:petsc-dev (master)$ diff 
Darwin-intel15.0-g//include/petscconf.h Darwin-intel16.0-g//include/petscconf.h
85c85
< #define PETSC_LIB_DIR "/opt/HPC/petsc-dev/Darwin-intel15.0-g/lib"
---
> #define PETSC_LIB_DIR "/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib"
489c489
< #define PETSC_ARCH "Darwin-intel15.0-g"
---
> #define PETSC_ARCH "Darwin-intel16.0-g”
Not very exciting!

I am attaching the one for intel16



petscconf.h
Description: petscconf.h


Regards,

Blaise

> 
> Satish
> 
> On Wed, 16 Sep 2015, Blaise A Bourdin wrote:
> 
>> Hi,
>> 
>> I am testing intel 16 compilers under mac OS, and notice that options 
>> handling for all past and current versions of petsc is broken in fortran 
>> (options are not parsed).
>> I narrowed it down to *argc at start.c:168 always being 0 when intel 16 is 
>> used (but taking the right value using intel 15 or gcc 5), but I can’t 
>> find my way through the multiple macros to figure out what is really the 
>> matter…
>> The problem does not seem to arise under linux with the same compilers.
>> 
>> Any idea of what is going on? Any test I can run to help (I assume that you 
>> don’t have a test box with the latest intel compilers)? Is it a petsc bug 
>> or an intel bug?
>> 
>> I use an up to date pets-dev master, and the configure.log file is available 
>> at https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/89329uFByT9
>> 
>> Thanks,
>> 
>> 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

[petsc-dev] PetscSF vs VecScatter

[Blaise A Bourdin]

Hi,

What is PETSc’s vision for VecScatter and PetscSF?

It seems that the only thing that prevents PetscSF from completely replacing 
VecScatter right now is that it does not support operations (ADD_VALUES, 
INSERT_VALUES). Is this an inherent restriction to SF that will force it to 
coexists with VecScatter, or is there a plan to add support for operations and 
gradually replace VecScatter with PetscSF?

Regards,
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

Re: [petsc-dev] gmake does not make

[Blaise A Bourdin]

I have 3.81. Which version is known to work? It is on a RHEL 5.10 machine (not 
mine...)

Blaise

On Jun 17, 2014, at 4:39 PM, Satish Balay ba...@mcs.anl.gov wrote:

 I thought this issue was fixed - but perhaps you have an ancient make.
 
 What do you have for 'gmake --version'
 
 does '--download-make' solve this issue?
 
 Perhaps we need version check somewhere..
 
 Satish
 
 On Tue, 17 Jun 2014, Blaise A Bourdin wrote:
 
 Hi,
 
 I am running into another problem with petsc-dev (master) where make exits 
 without error but also without building petsc. I tried make all-legacy but 
 it seems broken (perhaps because of the prefix install) an dtries to build 
 the target tree that does not exist
 
 Any idea?
 
 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

Re: [petsc-dev] gmake does not make

[Blaise A Bourdin]

On Jun 17, 2014, at 4:54 PM, Satish Balay ba...@mcs.anl.gov wrote:

 I just tried a simple build on a centos 5.2 [rhel 5.2 clone] - and the
 build went through fine..
 
 Does it work for you with --download-make?
 

It seems to be working, yes. I don’t know (and don’t want to know) what is 
wrong with the system’s make.

Thanks,

Blaise

 Satish
 
 -
 [balay@login01 ~]$ cat /etc/issue
 CentOS release 5.2 (Final)
 Kernel \r on an \m
 
 [balay@login01 ~]$ gmake --version
 GNU Make 3.81
 Copyright (C) 2006  Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.
 There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
 PARTICULAR PURPOSE.
 
 This program built for x86_64-redhat-linux-gnu
 
 [balay@login01 petsc-dev]$ ./configure --with-mpi=0 --download-fblaslapack=1
 
 snip
 
 [balay@login01 petsc-dev]$make PETSC_DIR=/home/balay/petsc-dev 
 PETSC_ARCH=arch-linux2-c-debug all 
 gmake[1]: Entering directory `/home/balay/petsc-dev'
 ==
 
 snip
 
  FC arch-linux2-c-debug/obj/src/ksp/f90-mod/petsckspmod.o
  FC arch-linux2-c-debug/obj/src/snes/f90-mod/petscsnesmod.o
  FC arch-linux2-c-debug/obj/src/ts/f90-mod/petsctsmod.o
 CLINKER /home/balay/petsc-dev/arch-linux2-c-debug/lib/libpetsc.so.3.04.4
 gmake[2]: Leaving directory `/home/balay/petsc-dev'
 =
 gmake[1]: Leaving directory `/home/balay/petsc-dev'
 Now to check if the libraries are working do:
 make PETSC_DIR=/home/balay/petsc-dev PETSC_ARCH=arch-linux2-c-debug test
 =
 [balay@login01 petsc-dev]$ 
 
 
 On Tue, 17 Jun 2014, Satish Balay wrote:
 
 3.81 should work. Its on all our test boxes [ubuntu 12.04]
 
 Satish
 
 On Tue, 17 Jun 2014, Blaise A Bourdin wrote:
 
 I have 3.81. Which version is known to work? It is on a RHEL 5.10 machine 
 (not mine...)
 
 Blaise
 
 On Jun 17, 2014, at 4:39 PM, Satish Balay ba...@mcs.anl.gov wrote:
 
 I thought this issue was fixed - but perhaps you have an ancient make.
 
 What do you have for 'gmake --version'
 
 does '--download-make' solve this issue?
 
 Perhaps we need version check somewhere..
 
 Satish
 
 On Tue, 17 Jun 2014, Blaise A Bourdin wrote:
 
 Hi,
 
 I am running into another problem with petsc-dev (master) where make 
 exits without error but also without building petsc. I tried make 
 all-legacy but it seems broken (perhaps because of the prefix install) an 
 dtries to build the target tree that does not exist
 
 Any idea?
 
 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

Re: [petsc-dev] possible problem with prefixed build in master

[Blaise A Bourdin]

On Jun 17, 2014, at 4:43 PM, Satish Balay ba...@mcs.anl.gov wrote:

 On Tue, 17 Jun 2014, Blaise A Bourdin wrote:
 
 
 On Jun 17, 2014, at 4:26 PM, Satish Balay ba...@mcs.anl.gov wrote:
 
 It was my attempt to partly fix this issue that broke for Blaise.
 
 I've pushed a revert for this partial/broken fix..
Great, it works now

Blaise


 
 Wrt the issue Barry referes to - I still think 'prefix install for
 --download-package with shared libraries' is difficult. I'm not sure
 how to deal with it.
 
 Thanks.
 Why not link with libraries in $PETSC_DIR/$ETSC_ARCH/lib during make, and do 
 a chrpath during make install?
 
 previous discussion:
 
 satish
 
 There is this thing
 http://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary
 
 but the tools mentioned are not available on default system installs
 [linux] - so we would have to carry them arround? And I'm not sure if
 they would work portably.
 
 jed
 Only ELF on x86 and ppc.  This is the non-portable tool I was thinking of.
 
  http://nixos.org/patchelf.html
 
 
 satish

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

Re: [petsc-dev] getting ready for PETSc release

[Blaise A Bourdin]

Resending to the list:


I saw that. Does it mean that all heavy data is duplicated in the hdf5 file, 
i.e. that /fields contains values that petsc understands and /viz is for 
visualization?

Yes, this is controlled by the viewer format. I saw no way to get xmf to look 
at scattered data, so duplication was inevitable.

There are two issues:
projection into linear / bilinear elements that xdmf understands and scattered 
data.
I think that one way to deal with the later is to create one grid per cell set. 
the hierarchy should be
Grid Name=TimeSeries GridType=Collection CollectionType=Temporal
  Time TimeType=HyperSlab”
:
:
  /Time
  Grid Name=Mesh GridType=Collection CollectionType=Spatial
Grid Name=cellset01 GridType=Uniform
:
:
/Grid
Grid Name=cellset02 GridType=Uniform
:
:
/Grid
/Grid
i.e. one connectivity table per cell set instead of a global one. This also 
addresses the issue of different element types
Lastly, when no interpolation is needed, we do not need to duplicate results in 
the hdf5 file this way.

How hard would it be to split the connectivity table in the hdf5 file? Once 
this is done, I can try to write a xmd file by hand for reference.

The xmf generation script fails on it, most likely because I don’t have a /time 
section in the file. My workaround is to replace l. 209 with time = [0,1].

The xmf script works on it now.

Did you push your changes? I have switched to next but still get an error:
bourdin@galerkin:DMComplex $ $PETSC_DIR/bin/pythonscripts/petsc_gen_xdmf.py 
TwoSquares.h5
Traceback (most recent call last):
  File /opt/HPC/petsc-dev/bin/pythonscripts/petsc_gen_xdmf.py, line 220, in 
module
generateXdmf(sys.argv[1])
  File /opt/HPC/petsc-dev/bin/pythonscripts/petsc_gen_xdmf.py, line 215, in 
generateXdmf
Xdmf(xdmfFilename).write(hdfFilename, topoPath, numCells, numCorners, 
cellDim, geomPath, numVertices, spaceDim, time, vfields, cfields)
  File /opt/HPC/petsc-dev/bin/pythonscripts/petsc_gen_xdmf.py, line 176, in 
write
self.writeSpaceGridHeader(fp, numCells, numCorners, cellDim, spaceDim)
  File /opt/HPC/petsc-dev/bin/pythonscripts/petsc_gen_xdmf.py, line 75, in 
writeSpaceGridHeader
''' % (self.cellMap[cellDim][numCorners], numCells, XYZ if spaceDim  2 
else XY))
KeyError: 1

I need to understand how xmf treats these mixes meshes. This is where help 
would be useful.
The checkpointing works with them however.

I struggled with the same problem until Jinghua Ge, our viz expert and xmf / 
hdf5 guru, suggested to use a spatial collection of spatial grids.

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

Re: [petsc-dev] getting ready for PETSc release

[Blaise A Bourdin]

Hi,

I hate to be the party pooper, especially when I don’t have code to contribute, 
but I/O with DMComplex is still far from release ready. Is it reasonable that 
having functional I/O in a stable release is going to wait until 3.6?

I still can’t figure out how to deal with cell sets of different types (say 
quads and tri). 
All cell and vertex sets seem to be contained in the hdf5 file, but not in a 
way that is usable by post processing tools (visit, paraview, ensight).
The xdmf generation script bin/pythonscripts/petsc_gen_xdmf.py is quite fragile.

I understand that it is probably too late to get this fixed and tested in 3.5. 
What is the best course of action?

Blaise 

 
   We’ll be making a PETSc release in a few days so please get anything you 
 need into next for testing and movement over to master.
 
  Barry
 
 Tentative plan for release Wed June 11
 

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

Re: [petsc-dev] getting ready for PETSc release

[Blaise A Bourdin]

On Jun 8, 2014, at 4:58 PM, Barry Smith bsm...@mcs.anl.gov wrote:

 
  Delaying the release is unlikely to get that I/O “fixed” faster so I don’t 
 want to block on it.
 
   If the “fixes” for the I/O don’t require current API changes (but could 
 require some new functions) then it is reasonable to include them as in a 
 “patch” release so it need not wait for a full release. If the I/O requires 
 total restructuring then I guess you stuck working off master for the new I/O 
 until the next release.
 
   We’ve been over a year since a release which is too long.

That’s fair.

As a matter of fact, if the releases are not as far apart, skipping one is not 
a big deal.

Blaise


 
   Barry
 
 On Jun 8, 2014, at 3:02 PM, Blaise A Bourdin bour...@lsu.edu wrote:
 
 Hi,
 
 I hate to be the party pooper, especially when I don’t have code to 
 contribute, but I/O with DMComplex is still far from release ready. Is it 
 reasonable that having functional I/O in a stable release is going to wait 
 until 3.6?
 
 I still can’t figure out how to deal with cell sets of different types (say 
 quads and tri). 
 All cell and vertex sets seem to be contained in the hdf5 file, but not in a 
 way that is usable by post processing tools (visit, paraview, ensight).
 The xdmf generation script bin/pythonscripts/petsc_gen_xdmf.py is quite 
 fragile.
 
 I understand that it is probably too late to get this fixed and tested in 
 3.5. What is the best course of action?
 
 Blaise 
 
 
 We’ll be making a PETSc release in a few days so please get anything you 
 need into next for testing and movement over to master.
 
 Barry
 
 Tentative plan for release Wed June 11
 
 
 -- 
 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
 
 
 
 
 
 
 
 

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

Re: [petsc-dev] Natural numbering for unstructured meshes

[Blaise A Bourdin]

On Feb 17, 2014, at 6:21 PM, Jed Brown j...@jedbrown.org wrote:

 Matthew Knepley knep...@gmail.com writes:
 
 On Mon, Feb 17, 2014 at 5:14 PM, Jed Brown j...@jedbrown.org wrote:
 
 Andrés Alessandro León Baldelli a.leon.balde...@gmail.com writes:
 
 Hi all,
 I am working with Blaise Bourdin on implementing a concept of natural
 numbering for unstructured meshes using DMplex.
 Such natural numbering can be, e.g., that of the mesh prior to parallel
 distribution.
 I have a working example in which I compute a field on the distributed
 DM and I scatter it back to the serial DM on rank0 but I would like to
 create a more general interface. To this regard I ask your advice:
 1) Is it reasonable to add an SF within the DM typedef for this natural
 to global scatter?
 
 Surely you don't want the (necessarily non-scalable) serial DM to be a
 necessary part of this interface?  What do you want to do with this
 natural numbering?  Just write output files?
 
 
 Jed, No, no, no. This is not an SF for a serial DM.
 
 I was responding to the question above.  Yes, we need a genuine parallel
 reader (naive partition) and a way to write back in that ordering.  But
 my question remains: do you want to do something other than IO with that
 natural ordering?

At this point, no. We want to do I/O and respect the ordering of the data on 
the disk. 
Note that this “natural” ordering may not be all on cpu with rank 0. One could 
easily imagine reading a mesh partitioned on p processors, then repartition it 
on n tasks.

 
 Note that in the natural ordering, you likely have elements for which
 you own zero of the vertices, and vice-versa, so it would be _really_
 bad to compute on it.

Let’s not make any assumption on what the natural ordering is.
Another application that comes to my mind would be to do load balancing for 
iterative coupling of a pde formulated on a domain and on on its boundary.


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

[petsc-dev] Show download URL

[Blaise A Bourdin]

Hi,

I recently came across an issue with a segfault in ddot. It turns out that the 
problem was not at all in petsc, but rather that the machine I was compiling 
PETSc from had no direct access to the internet (quite common in industry HPC 
clusters), and that the admin was downloading chaco from sandia directly 
instead of the patched tarball hosted on petsc servers. (I could also elaborate 
on the sanity of redefining ddot in a LIBRARY...)

This brings my first request: the chaco tarball on MCS and sandia have the same 
name. Would it make sense to clearly indicate when a packaged hosted by petsc 
is different from the upstream package? It would have made it clear from the 
beginning that the admin was not using the PETSc patched tarball.

Secondly: right now, short of knowing that the url are in the python config 
files in $PETSC_DIR/config/PETSc/packages (or 
config/BuildSYstem/config/packages, for some reason), the workflow to download 
packages on a machine with no direct internet access is to configure with 
--download-coolpackage, wait a long time for configure to run, wait until 
download fails, and a message
Unable to download package Chaco from: 
http://ftp.mcs.anl.gov/pub/petsc/externalpackages/coolpackage.tar.gz
to pop up

Would it be possible to 
1. print the download url _before_ trying to download a package
2. add a configure options that would print the url of all packages for which a 
download has been requested?

Not understanding the logic of BuildSystem, I don’t know if 2. is even 
possible, but it sure would be nice...


Regards,

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

Re: [petsc-dev] How do I build a shared library for exodus?

[Blaise A Bourdin]

On Jan 21, 2014, at 11:01 PM, Jed Brown j...@jedbrown.org wrote:

 Blaise A Bourdin bour...@lsu.edu writes:
 
 Hi,
 
 For some reason, I would need to generate a shared library for
 exodusII, but the Makefile included in the source distribution does
 not have a rule for this. Is there an easy way to modify the build
 system package in order to generate the shared library?
 
 The Makefile.standalone does not have rules for shared.  Perhaps
 upstream exodus (now at version 6.02) is recommending the CMake build?
 I'd rather not have exodusii.py depend on CMake if we can help it
 (buggy, bad logging, another thing to compile), so maybe we need to add
 a shared rule?  Or embrace the beast?

let’s say we do want to mess with cmake. What is the typical way to add the 
shared rule?
   - patch Makefile.standalone in exodusii.py?
   - repackage exodus and serve it from the petsc servers?
Is there a BuildSystem way to know that the linker flag to build a shared 
library is -shared under linux and -dynamiclib under mac OS? If so, can we 
simply build the shared library in exodusii.py?

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

Re: [petsc-dev] DMplex reader / viewers

[Blaise A Bourdin]

On Jan 22, 2014, at 10:57 AM, Jed Brown j...@jedbrown.org wrote:

 Moving back to list.
sorry, muscle memory prevents me from hitting that reply-to button

 
 Blaise A Bourdin bour...@lsu.edu writes:
 
 On Jan 21, 2014, at 11:20 AM, Jed Brown j...@jedbrown.org wrote:
 
 Matthew Knepley knep...@gmail.com writes:
  - Reading from or writing to exodus files is not supported.
 
 
 Yes, I think this is the best target. It should be similar to writing HDF5
 that we do for PyLith.
 
 How are we going to represent high-order elements in Exodus?  Doesn't it
 only support quadratic continuous spaces?  What about DG spaces, H(div)
 spaces, or higher than second order?
 
 It only supports first and second order elements. I don’t think that 
 continuity is an issue. Nothing prevents you to alter the connectivity table.
 Element types is set by blocks, so mixing polynomial orders is not possible 
 without some trickery
 
 Do we consider this an acceptable long-term solution?

hell no!

Does anybody knows of any open and widespread format supporting elements of 
order 2? I checked quickly, and according to their documentation it seems that 
none of exodusii, silo 4.7, or xdmf support them...

Incidentally, exodus docs last update is from 2006,silo’s from 2010, and 
http://www.xdmf.org has seen minor edits after 2009... I seem to recall that 
the project is now hosted with visit. Not sure.

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

Re: [petsc-dev] DMplex reader / viewers

[Blaise A Bourdin]

On Jan 22, 2014, at 11:37 AM, Jed Brown j...@jedbrown.org wrote:

 Blaise A Bourdin bour...@lsu.edu writes:
 Does anybody knows of any open and widespread format supporting
 elements of order 2? I checked quickly, and according to their
 documentation it seems that none of exodusii, silo 4.7, or xdmf
 support them...
 
 No, I looked hard and everyone I know rolled their own, so that's what I
 did (I only needed hexes).
Did you write a whole new format? How about simply extendinf xdmf to add higher 
order element and send patches supporting these extensions to visit / paraview?

 How important is it to support hanging nodes?  Is 2-1 refinement
 sufficient?
Can hanging nodes be handled through cell sets of various element types?

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

Re: [petsc-dev] DMplex reader / viewers

[Blaise A Bourdin]

On Jan 21, 2014, at 10:23 AM, Gorman, Gerard J g.gor...@imperial.ac.uk wrote:

 Hi Blaise
 
 This is pretty much music to my ears. Interoperability is a major headache, 
 most file formats are rubbish (e.g. cannot support for boundaries, limited 
 meta data etc etc) most lack reasonable parallel IO solutions (i.e. something 
 other than 1 file per process)…and so on. At the moment a few groups here at 
 IC (this mostly means Michael Lange ;) are integrating DMPlex with a range of 
 FEM codes to try to rationalise this. There are certainly some features 
 missing (we’ve bumped into most of that you’ve listed below) but all 
 indications are that DMPlex has the right design to be expanded to cover 
 these use cases. 
 
 On 21 Jan 2014, at 15:30, Blaise A Bourdin bour...@lsu.edu wrote:
 
 Hi,
 
 It looks like DMplex is steadily gaining maturity but I/O is lagging behind. 
 As far as I understand, right now, PETSc can _read_ a mesh in exodus format, 
 and  write binary VTS format, but many issues remain, IMHO:
  - The exodus reader relies on a hard-coded nodeset named “marker”. 
 Generating such a nodeset is not trivial
(at least not for complex meshes generated with Cubit / Trelis).
  - Reading from or writing to exodus files is not supported.
 
 So we *really* want this as well for the purpose of dumping results and 
 checkpointing. Trying to shoehorn high order and DG data into VTK is complete 
 crap. I love VTK because its got loads of functionality and it is easy to 
 throw stuff together, but we are getting ourselves into the position that we 
 are just layering hack after hack to deal with the fact that we cannot write 
 all required data into a vtk file. These days VTK/paraview has its own 
 ExodusII reader so we have a route to nice seamless integration.
 
 
  - The VTS viewer only allows to read and write _all_ fields in a DM. This 
 may be overkill if one only 
wants to read boundary values, for instance.
 
 or only writing out prognostic fields for example. 
 
  - The VTS viewer loses all informations on exodus nodesets and cell sets. 
 These may have some significance
and may be required to exploit the output of a computations.
 
 Right - this includes boundary labels, and it is just a fluff to have to 
 write this out into VTK. You would have to write a separate vtu or something 
 resulting in more messiness (and I already have enough problems on LUSTER 
 from having too many files).
 
 
  - VTS seems to have a concept of “blocks”. My understanding is that the 
 parallel VTS viewer uses blocks to
save subdomains, and that continuity of piecewise linear fields across 
 subdomain boundaries is lost. 
It is not entirely clear to me if with this layout, it would be possible 
 to reopen a file with a 
different processor count.
 
 I think you just do not want to go there… For a start your vtk file would not 
 be a valid checkpoint to consider restarting on a different number of 
 processes. And secondly, it would just be a mess to program.
 
 
 I can dedicate some resources to improving DMplex I/O. Perhaps we can start 
 a discussion by listing the desired features such readers / writers should 
 have. I will pitch in by listing what matters to me:
 
 Keep talking…we have also an FTE working on this currently but this is a long 
 wish list and a lot of effort is required if this is to be done within a 
 reasonable time frame. It would be great if more people were working on this.
I have a postdoc here who will devote some of his time to this task.

 
  - A well documented and adopted file format that most post-processors / 
 visualization tools can use
 
 ExodusII appears to be the current favoured option.
Sadly yes… But SILO may be a close second and has a more modern interface. 


 
  - Ability to read / write individual fields
  - Preserve _all_ information from the exodus file (node / side / cell 
 sets), do not lose continuity of fields
across subdomain boundaries.
  - Ability to reopen file on a different cpu count
 
 So this is where we need to have parallel IO support. Quoting from petcs’s 
 exodus.py
 ””
 # ExodusII does not call HDF5 directly, but it does call 
 nc_def_var_deflate(), which is only
 # part of libnetcdf when built using --enable-netcdf-4.  Currently 
 --download-netcdf (netcdf.py)
 # sets --enable-netcdf-4 only when HDF5 is enabled.
 “”
 So, there may be some rebuilding required to ensure that all the dependencies 
 are built properly but it’s clearly there.

I am not sure if Exodus has a good solution here. As far as I understand, 
exodus is inherently sequential, even when implemented with HDF5 instead of 
netcdf. I would also worry about third party support for exodus files using 
HDF5 as their storage format.
Exodus has an parallel extension called nemesis, but I can’t figure out how how 
their concept of ghost point and cells works. The documentation on this point 
is really unclear.

Considering the dismal state of parallel FE formats

[petsc-dev] How do I build a shared library for exodus?

[Blaise A Bourdin]

Hi,

For some reason, I would need to generate a shared library for exodusII, but 
the Makefile included in the source distribution does not have a rule for this. 
Is there an easy way to modify the build system package in order to generate 
the shared library?

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

Re: [petsc-dev] make all PETSc Fortran examples modern freeform?

[Blaise A Bourdin]

Yes please!

And also, it would be nice if make test could use an example that works with 
--with-fortran-datatypes .

Blaise
On Nov 7, 2013, at 7:08 AM, Barry Smith bsm...@mcs.anl.gov wrote:

 
   For many years we tried to make all Fortran examples except one or two be 
 very backwards compatible, no free form etc etc.
 
   Should we switch and now just make PETSc by default use modern approaches? 
 freeform with no continuation characters?
 
   Barry
 
 

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

Re: [petsc-dev] make all PETSc Fortran examples modern freeform?

[Blaise A Bourdin]

I haven’t use fixed-form in a long time, but isn’t free-form a superset of 
fixed-form? Are there situation where a fixed form code cannot be compiled as 
free form source code?

Blaise

On Nov 7, 2013, at 8:12 AM, Jed Brown jedbr...@mcs.anl.gov wrote:

 Barry Smith bsm...@mcs.anl.gov writes:
   Is there any reason we cannot force everyone to use
   free-form. Aside from the fact that they are FORTRAN programmers
   and will never change their way.
 
 I don't know.  I don't imagine Nek is the only fixed-form Fortran still
 in existence.

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

Re: [petsc-dev] make all PETSc Fortran examples modern freeform?

[Blaise A Bourdin]

Damn it! Considering that fixed form was declared obsolete 10 years ago, and if 
this is the only incompatibility, is it too much to ask that fortran people 
replace a C in first col with a ! (which is also compatible with fixed 
form)?

Blaise 


On Nov 7, 2013, at 8:42 AM, Jed Brown jedbr...@mcs.anl.gov wrote:

 Blaise A Bourdin bour...@lsu.edu writes:
 
 I haven’t use fixed-form in a long time, but isn’t free-form a
 superset of fixed-form? Are there situation where a fixed form code
 cannot be compiled as free form source code?
 
 $ cat foo.f
  program foo
 c a silly comment
  end program
 $ gfortran foo.f
 $ gfortran -ffree-form foo.f 
 foo.f:2:
 
 c a silly comment
 1
 Error: Unclassifiable statement at (1)

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

Re: [petsc-dev] make all PETSc Fortran examples modern freeform?

[Blaise A Bourdin]

Would it be possible to remove all instance of the PARAMETER” keyword from the 
petsc source code? I would like to compile a FORTRAN IV boundary element 
program I wrote in 1963 for the structural analysis of 8 track cartridges.
Also, where do I get a punch-card version of petsc source code? I cannot 
compile git on my IBM 7030.

Blaise
On Nov 7, 2013, at 9:07 AM, Jed Brown jedbr...@mcs.anl.gov wrote:

 Satish Balay ba...@mcs.anl.gov writes:
 
 On Thu, 7 Nov 2013, Blaise A Bourdin wrote:
 
 I haven’t use fixed-form in a long time, but isn’t free-form a superset of 
 fixed-form?
 
 In essence all current petsc code complies with this.
 
 [i.e its syntactically corect both free form and fixed form]
 
 Current PETSc requires polyglot Fortran, written in a peculiar
 intersection of the two dialects.
 
 Are there situation where a fixed form code cannot be compiled as free form 
 source code?
 
 Not sure if its the fixed/free form issue - [its perhaps f77 vs f90] - some
 external packages use 'C' for comment - which some f90 compilers barf on.
 
 c  = 1
 
 is a valid statement in free-form, but a comment in fixed-form.

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

[petsc-dev] PetscSF vs. VecScatter

[Blaise A Bourdin]

Hi,

I am looking at adding full support for exodus to DMPlex (input and output).
Until I can understand better the nemesis format (a parallel extension of 
exodusII), my goal is to be able to scatter data back to cpu 0, re-use the 
pre-distribution ordering and use the sequential exo library.

I can figure out how to do that using VecScatter but I am intrigued by PetscSF.
Is there any documentation available, beside 
src/vec/is/sf/examples/tutorials/ex1.c?
In particular a short description of the basic concepts would be helpful.

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

[petsc-dev] [patch] PetscBoolRegisterArray

[Blaise A Bourdin]

Hi,

The attached patch adds a PetscBoolRegisterArray function. I need it to specify 
boundary conditions on each component of a vector valued field. Can somebody 
have a look at it and apply it, if it is OK?

Thanks,
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









PetscBagRegisterBoolArray.patch
Description: PetscBagRegisterBoolArray.patch

[petsc-dev] removing sieve

[Blaise A Bourdin]

Can we keep it in 3.4 with a warning? I have a lot more work to do before I can 
switch to dmplex.

Blaise

On May 11, 2013, at 6:18 PM, Jed Brown jedbrown at mcs.anl.gov
 wrote:

 Matt, I take it that you intend for this removal to be merged for
 petsc-3.4 so that users are not distracted by something we aren't
 supporting.  An alternative would be to add a #warning to petscdmmesh.h.
 
 If we are deleting it from petsc-3.4, there are a few files that can
 have more stuff deleted:
 
 $ git grep -l 'ALE::' 
   
 bin/processSummary.py
 config/PETSc/FEM.py
 src/dm/impls/plex/plexfem.c
 src/docs/doxygen/Doxyfile
 src/snes/examples/tutorials/ex72.c
 
 
 We can delete the sieve-dev mailing list and reference to it.
 
 src/docs/website/miscellaneous/mailing-lists.html:  td: For Sieve 
 users/td
 
 
 Update the FAQ to recommend DMPlex.
 
 src/docs/website/documentation/faq.html:  use the Sieve construct in 
 PETSc, this is a high
 
 Remove src/docs/tex/manual/sieve.tex
 
 
 Sieve is also referenced from src/docs/strategy.tex, which is an
 outdated personal fragment that should probably also be deleted.
 

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

[petsc-dev] removing sieve

[Blaise A Bourdin]

Great.

Thanks a lot. The timeline should be fine.

Blaise

Sent from a handheld device.

On May 11, 2013, at 8:17 PM, Jed Brown jedbrown at 
mcs.anl.govmailto:jedbrown at mcs.anl.gov wrote:


Matt and I just talked offline. We'll leave it in for the release, but remove 
it from master. So it will be in 3.4.x (deprecated), but not in 'master' and 
gone in 3.5.

On May 11, 2013 7:57 PM, Blaise A Bourdin bourdin at lsu.edumailto:bourdin 
at lsu.edu wrote:
Can we keep it in 3.4 with a warning? I have a lot more work to do before I can 
switch to dmplex.

Blaise

On May 11, 2013, at 6:18 PM, Jed Brown jedbrown at mcs.anl.govmailto:jedbrown 
at mcs.anl.gov
 wrote:

 Matt, I take it that you intend for this removal to be merged for
 petsc-3.4 so that users are not distracted by something we aren't
 supporting.  An alternative would be to add a #warning to petscdmmesh.h.

 If we are deleting it from petsc-3.4, there are a few files that can
 have more stuff deleted:

 $ git grep -l 'ALE::'
 bin/processSummary.py
 config/PETSc/FEM.py
 src/dm/impls/plex/plexfem.c
 src/docs/doxygen/Doxyfile
 src/snes/examples/tutorials/ex72.c


 We can delete the sieve-dev mailing list and reference to it.

 src/docs/website/miscellaneous/mailing-lists.html:  td: For Sieve 
 users/td


 Update the FAQ to recommend DMPlex.

 src/docs/website/documentation/faq.html:  use the Sieve construct in 
 PETSc, this is a high

 Remove src/docs/tex/manual/sieve.tex


 Sieve is also referenced from src/docs/strategy.tex, which is an
 outdated personal fragment that should probably also be deleted.


--
Department of Mathematics and Center for Computation  Technology
Louisiana State University, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612tel:%2B1%20%28225%29%20578%201612, Fax  +1 (225) 578 
4276tel:%2B1%20%28225%29%20578%204276 http://www.math.lsu.edu/~bourdin








-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130512/23cad694/attachment.html

[petsc-dev] Making a PetSc Roll and Rocks Module

[Blaise A Bourdin]

the usual naming scheme is just the version number, but for petsc, most 
supercomputing centers use %version-%arch
the installer will copy the file into $MODULEPATH/petsc/%version-%arch, or the 
user to $HOME/.modulefiles

Of course,  %version-%arch is a really silly name out of context. How about 
petsc-%version-%arch, somewhere within $PETSC_DIR/$PETSC_ARCH, or 
$PETSC_DIR/$PETSC_ARCH/modulefiles/%version-%arch ?

Blaise


On Jan 24, 2013, at 6:19 PM, Satish Balay balay at mcs.anl.gov
 wrote:

 On Thu, 24 Jan 2013, Matthew Knepley wrote:
 
 On Thu, Jan 24, 2013 at 3:42 PM, Blaise A Bourdin bourdin at lsu.edu wrote:
 
 I am attaching a very basic module file for reference. One would need to
 update petsc_dir and petsc_arch upon deploying these, or perhaps configure
 can do it.
 
 I actually use this to easily switch between builds and debug / optimized
 versions
 
 
 Pushed something that writes your simple module file to
 lib/modules/PETSc.mod. It would now be good to get feedback
 to make this the right thing.
 
 The name conflists with f90 modules. Perhaps there is a different
 notation for software modules?
 
 Also for prefix install we should set PETSC_ARCH=
 
 And for inplace install - do we also add PETSC_DIR/bin to PATH?
 
 Satish
 

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

[petsc-dev] Making a PetSc Roll and Rocks Module

[Blaise A Bourdin]

On Jan 24, 2013, at 6:37 PM, Satish Balay balay at mcs.anl.gov
 wrote:

 On Fri, 25 Jan 2013, Blaise A Bourdin wrote:
 
 the usual naming scheme is just the version number, but for petsc, most 
 supercomputing centers use %version-%arch
 the installer will copy the file into $MODULEPATH/petsc/%version-%arch, or 
 the user to $HOME/.modulefiles
 
 Of course,  %version-%arch is a really silly name out of context. How about 
 petsc-%version-%arch, somewhere within $PETSC_DIR/$PETSC_ARCH, or 
 $PETSC_DIR/$PETSC_ARCH/modulefiles/%version-%arch ?
 
 And PETSC_ARCH has no singificance with prefix install [the
 significant text is in the prefix-path - and one doesn't have to match
 PETSC_ARCH to this significant text]

True. I actually realized that as I was hitting send

 BTW: Is the following notation ok? [google didn't help]
 
 prepend-path PATH /home/balay/spetsc/asterix64/bin:/home/balay/spetsc/bin

It seems to work, but 
prepend-path PATH /home/balay/spetsc/asterix64/bin
prepend-path PATH /home/balay/spetsc/bin
may be safer. 
Both will break under windows, but I don't think it is a problem, really

Blaise




 
 I have some fixes [except for the modfile name] which I can push.
 
 thanks,
 Satish
 
 
 Blaise
 
 
 On Jan 24, 2013, at 6:19 PM, Satish Balay balay at mcs.anl.gov
 wrote:
 
 On Thu, 24 Jan 2013, Matthew Knepley wrote:
 
 On Thu, Jan 24, 2013 at 3:42 PM, Blaise A Bourdin bourdin at lsu.edu 
 wrote:
 
 I am attaching a very basic module file for reference. One would need to
 update petsc_dir and petsc_arch upon deploying these, or perhaps configure
 can do it.
 
 I actually use this to easily switch between builds and debug / optimized
 versions
 
 
 Pushed something that writes your simple module file to
 lib/modules/PETSc.mod. It would now be good to get feedback
 to make this the right thing.
 
 The name conflists with f90 modules. Perhaps there is a different
 notation for software modules?
 
 Also for prefix install we should set PETSC_ARCH=
 
 And for inplace install - do we also add PETSC_DIR/bin to PATH?
 
 Satish
 
 
 
 
 

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

[petsc-dev] Making a PetSc Roll and Rocks Module

[Blaise A Bourdin]

I am attaching a very basic module file for reference. One would need to update 
petsc_dir and petsc_arch upon deploying these, or perhaps configure can do it.

I actually use this to easily switch between builds and debug / optimized 
versions

Blaise


 wrote:

 On Thu, 24 Jan 2013, Matthew Knepley wrote:

 We do support this install with DESTDIR. It might have rough edges -
 but its supporsed to work the same way any other package that supports
 it.

 One difference though is - since we also suppor the alternate
 orngaization [default] for inplace install with PETSC_ARCH - one has
 to use this PETSC_ARCH during the prefix build process aswell.  [but
 then PETSC_ARCH is nolonger used/needed after that]

 i.e
 configure
 --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1
 PETSC_ARCH=build1
 make PETSC_ARCH=build1 all
 make install PETSC_ARCH=build1 install DESTDIR=/tmp/dest1
 package up from DESTDIR, and install as root:
 Now user does:
 make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 ex1

 configure [different options]
 --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2
 PETSC_ARCH=build2
 make PETSC_ARCH=build2 all
 make install PETSC_ARCH=build2 install DESTDIR=/tmp/dest2
 package up from DESTDIR, and install as root:
 Now user does:
 make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 ex1


 Satish, would you mind putting this little blurb on the installation page
 in the section about
 using prefix? I could not find this anywhere in our documentation.

 pushed 
 https://bitbucket.org/petsc/petsc-3.3/commits/74a42cc43dcfbd1850b7689385b6f1b5
 [and updated website with it]

 Satish


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







-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130124/1c1710b1/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: 3.3
Type: application/octet-stream
Size: 493 bytes
Desc: 3.3
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130124/1c1710b1/attachment.obj

[petsc-dev] exodusii.py

[Blaise A Bourdin]

Hi,

I have updated the exodusII module for BuildSystem. The updated module uses the 
latest official tarball, but it still has to be repackaged in order to make its 
file layout compatible with BuildSystem.

It it's OK, can somebody push it to BuildSystem? The repackaged exodus tarball 
is available at
 https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/6453H4M0ae


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







-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121122/50681cd1/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: exodusii.py
Type: text/x-python-script
Size: 3456 bytes
Desc: exodusii.py
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121122/50681cd1/attachment-0001.bin

[petsc-dev] petsc.cs.iit.edu down?

[Blaise A Bourdin]

Hi,

I can't pull petsc dev or 3.3 from petsc.cs.iit.edu anymore
At the risk of restarting a flamewar, has bitbucket become the official / main 
repository? should the petsc web pages be updated to reflect this?

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

[petsc-dev] PetscSection

[Blaise A Bourdin]

Hi,

Let me make sure I understand the consensus, since I have a vested interest in 
the unstructured mesh business:

A DM does double duty by describing the geometry of the mesh, and the data 
layout associated with the finite element space. I liked the model where the 
mesh geometry and the data layout on the mesh was split in two objects, but I 
understand the convenience of having everything in the DM, and DMClone works 
just fine. Since I may have to handle scalar, vector, 2nd and 4th order tensor 
on 2 different finite element spaces, in an assembly loop, I may end up dealing 
with as many as 8 DM. I stick all these DM's in the user context of each DM 
associated with a unknown (a Vec on which I may have to call SNESSolve or 
TSSolve), hoping that this is not creating some aliasing problem which as  a 
fortran programmer I can not possibly understand. 

Everything is an IS. I suspect that this means that the Set/GetCone, 
Set/GetClosure operations would return an IS that could be used in 
VecSetValuesIS, but may not even be needed if an equivalent of  DMMesh' 
SectionRealRestrict / RestrictClosure /Update / UpdateCLosure is implemented

Setting Values is good, but getting values is needed too! 

Also, in addition to the Barry's simple pseudo-code, I need to be able to get 
an IS for the i^th dof of a field at a given point (think of applying a 
Dirichlet boundary conditions to only one component of a field, for instance). 
It's always been the messy part. How would that fit within the proposed model?

Finally, just a comment on stratum vs topological dimension. There is no reason 
why all elements in a mesh should have the same topological dimension. I 
actually find it much easier to have a single mesh where some sets of elements 
have codimension 0 and others codimension 1 and dispatching my assembly 
depending on the physics associated with each block, and the codimension of the 
element rather than having to deal with side sets / boundary mesh / whatever 
you want to call it.

Blaise

On Nov 9, 2012, at 9:02 PM, Barry Smith bsmith at mcs.anl.gov
 wrote:

 
  We have a users manual?
 
 On Nov 9, 2012, at 8:56 PM, Matthew Knepley knepley at gmail.com wrote:
 
 On Fri, Nov 9, 2012 at 9:46 PM, Barry Smith bsmith at mcs.anl.gov wrote:
 
 On Nov 9, 2012, at 8:42 PM, Jed Brown jedbrown at mcs.anl.gov wrote:
 
 On Fri, Nov 9, 2012 at 8:39 PM, Matthew Knepley knepley at gmail.com 
 wrote:
 You are both right :) I don't care where we put them, but I want BCs
 and fields. However, this is no problem.
 Right now I do BCs and fields as PetscSections held inside the primary
 section. If IS can do what PetscSection
 can do, I can jsut use another IS for each one.
 
 Convergence!
 
 
  Write it up!   :-)
 
 In the manual section on Unstructured Grids :)
 
  Matt
 
 
 I actually like it where it is. Stick with DMComplexVecGetClosure()
 with no section argument, and then
 the DM holds an IS++.
 
 Cool, now the normal user doesn't even see the ++IS.
 
 
 
 
 --
 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
 
 

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

[petsc-dev] PetscSection

[Blaise A Bourdin]

Sent from a handheld device.

On Nov 10, 2012, at 12:38 AM, Jed Brown jedbrown at 
mcs.anl.govmailto:jedbrown at mcs.anl.gov wrote:

On Fri, Nov 9, 2012 at 10:20 PM, Blaise A Bourdin bourdin at 
lsu.edumailto:bourdin at lsu.edu wrote:
A DM does double duty by describing the geometry of the mesh, and the data 
layout associated with the finite element space. I liked the model where the 
mesh geometry and the data layout on the mesh was split in two objects, but I 
understand the convenience of having everything in the DM, and DMClone works 
just fine. Since I may have to handle scalar, vector, 2nd and 4th order tensor 
on 2 different finite element spaces, in an assembly loop, I may end up dealing 
with as many as 8 DM. I stick all these DM's in the user context of each DM 
associated with a unknown (a Vec on which I may have to call SNESSolve or 
TSSolve), hoping that this is not creating some aliasing problem which as  a 
fortran programmer I can not possibly understand.

;-)

Everything is an IS. I suspect that this means that the Set/GetCone,

I think these just return a range or (offset,size).

Set/GetClosure operations

Closure needs to do orientation, so it's not direct access from the Vec. 
Regardless, I don't think the plan would be to create an IS for that 
granularity.

would return an IS that could be used in VecSetValuesIS, but may not even be 
needed if an equivalent of  DMMesh' SectionRealRestrict / RestrictClosure 
/Update / UpdateCLosure is implemented

I think these are DMCompletVecGet/SetClosure.


Setting Values is good, but getting values is needed too!

Also, in addition to the Barry's simple pseudo-code, I need to be able to get 
an IS for the i^th dof of a field at a given point (think of applying a 
Dirichlet boundary conditions to only one component of a field, for instance). 
It's always been the messy part. How would that fit within the proposed model?

I think you would get an index set for those points on the feature you wanted 
to do something special for.

Finally, just a comment on stratum vs topological dimension. There is no reason 
why all elements in a mesh should have the same topological dimension. I 
actually find it much easier to have a single mesh where some sets of elements 
have codimension 0 and others codimension 1 and dispatching my assembly 
depending on the physics associated with each block, and the codimension of the 
element rather than having to deal with side sets / boundary mesh / whatever 
you want to call it.

I don't mind that, but can't you have an index set describing the codim 0 
elements (maybe all of them) and another index set for the codim 1 elements on 
the features you care about? You can take their union (or concatenate) for your 
assembly loop if you like. Is there something wrong with this approach?
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/fb0588ca/attachment.html

[petsc-dev] PetscSection

[Blaise A Bourdin]

Sorry, for the empty message earlier. Fat fingers on a small keyboard...


On Fri, Nov 9, 2012 at 10:20 PM, Blaise A Bourdin bourdin at 
lsu.edumailto:bourdin at lsu.edu wrote:
A DM does double duty by describing the geometry of the mesh, and the data 
layout associated with the finite element space. I liked the model where the 
mesh geometry and the data layout on the mesh was split in two objects, but I 
understand the convenience of having everything in the DM, and DMClone works 
just fine. Since I may have to handle scalar, vector, 2nd and 4th order tensor 
on 2 different finite element spaces, in an assembly loop, I may end up dealing 
with as many as 8 DM. I stick all these DM's in the user context of each DM 
associated with a unknown (a Vec on which I may have to call SNESSolve or 
TSSolve), hoping that this is not creating some aliasing problem which as  a 
fortran programmer I can not possibly understand.

;-)

Actually, I am really not sure if passing a dm and a pointer to a user context 
containing this dm is legit or not...

Everything is an IS. I suspect that this means that the Set/GetCone,

I think these just return a range or (offset,size).

Set/GetClosure operations

Closure needs to do orientation, so it's not direct access from the Vec. 
Regardless, I don't think the plan would be to create an IS for that 
granularity.
Fine.  It should be done from the DM anyways.



would return an IS that could be used in VecSetValuesIS, but may not even be 
needed if an equivalent of  DMMesh' SectionRealRestrict / RestrictClosure 
/Update / UpdateCLosure is implemented

I think these are DMCompletVecGet/SetClosure.

Great




Setting Values is good, but getting values is needed too!

Also, in addition to the Barry's simple pseudo-code, I need to be able to get 
an IS for the i^th dof of a field at a given point (think of applying a 
Dirichlet boundary conditions to only one component of a field, for instance). 
It's always been the messy part. How would that fit within the proposed model?

I think you would get an index set for those points on the feature you wanted 
to do something special for.

That's pretty much what I do now. With DMMesh, it required quite a bit of work. 
It looks much easier with DMComplex

Finally, just a comment on stratum vs topological dimension. There is no reason 
why all elements in a mesh should have the same topological dimension. I 
actually find it much easier to have a single mesh where some sets of elements 
have codimension 0 and others codimension 1 and dispatching my assembly 
depending on the physics associated with each block, and the codimension of the 
element rather than having to deal with side sets / boundary mesh / whatever 
you want to call it.

I don't mind that, but can't you have an index set describing the codim 0 
elements (maybe all of them) and another index set for the codim 1 elements on 
the features you care about? You can take their union (or concatenate) for your 
assembly loop if you like. Is there something wrong with this approach?

Thats a very good point. In the end it doesn't really matter. As far as I 
remember, the main reason I ended with my current scheme is that DMMesh did not 
play well with partially interpolated meshes. I don't know what the current 
status of DMComplex is.

Blaise
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/6c3a76bf/attachment-0001.html

[petsc-dev] PetscSection

[Blaise A Bourdin]

Ah, okay. To confirm, you have a DM that you are solving for, and in its user 
context, you have several other DMs, each with a Vec, describing the problem 
data like coefficients, forcing terms, and internal discontinuities?
Yes, but because of the structure of my problem, the application context also 
contains a link to the original DM.
Think solving F(u,v) = 0 where and v don't have the same layout, or the same 
dimensionality, without field split.
My iterate is
u_{n+1} = argmin_w F(w,v_n)
   v_{n+1} = argmin_w F(u_{n+1},w)
The DM associated with u is DMu and the one with v is DMv
For the application context, I can either a create AppCtx with components 
(pointer to u, pointer to v, pointed to DMu, pointer to DMu), or
AppCtxu with components (pointer to v, pointer to DMv) and AppCtxv with 
components (pointer to u, pointer to DMu)
In this setting, is calling SNESSolve with Vec u and Application Context AppCtx 
legal, or do I have to use AppCtxu / AppCtxv?


That is completely fine, and not aliasing, but it does not play well with 
geometric multigrid because coarse grids reference the same application 
context. We have a system of hooks for managing such resolution-dependent data, 
though only with a C interface so far. (We needed this to get geometric 
multigrid and FAS to work with TS. Most non-toy applications need it too.)

Can you point me to an example? Are interfaces C only because nobody has ever 
needed fortran versions, or is there a technical reason.


I'm not sure if there is a way to make this easier. We have been using 
PetscObjectCompose() to attach things to the DM on different levels. We could 
have a slightly friendlier user interface for that.
I debated AppCtx vs. ObjectCompose for quite a bit. As far as I understand, 
PetscCompose/Query uses object names to reference objects, so I would have 
ended passing the name of the coefficients DM and Vecs in the appctx. I opted 
to put pointers to them in the appctx instead of names. It looked a bit simpler 
at the time. Now I have two good reasons I should have gone the PetscObject 
way. Oh well...


So keeping those things in the app context is just fine, but if you want to use 
geometric multigrid, you'll have to take them out of the app context and put 
them in a different structure attached to the DM that is not transparently 
propagated under coarsening and refinement. If you think you might do this 
eventually, I recommend commenting/organizing your app context so that 
resolution-dependent stuff is easily identifiable.

I had not thought about it, but it is quite feasible. I store all coefficients 
that are constant per block of cells or Dof in PetscBags, and everything that 
has variation at the scale of the finite element space in Vecs.  How would the 
creation of the coarse DMs be handled, though? The geometry part is trivial to 
propagate using DMClone, but you may need to user feedback for the data layout 
part, unless you have a scheme that describes it (i.e. for this IS of cells, n 
dof at the vertices, p at the faces etc)


I don't mind that, but can't you have an index set describing the codim 0 
elements (maybe all of them) and another index set for the codim 1 elements on 
the features you care about? You can take their union (or concatenate) for your 
assembly loop if you like. Is there something wrong with this approach?

Thats a very good point. In the end it doesn't really matter. As far as I 
remember, the main reason I ended with my current scheme is that DMMesh did not 
play well with partially interpolated meshes. I don't know what the current 
status of DMComplex is.

Okay, I think it's important to eventually support partially interpolated 
meshes to avoid using a lot of memory when used with low-order discretizations. 
I see no reason why there can't also be a direct cache for closure. For a P1 
basis, that amounts to a point range

[cells, boundary faces, vertices]

closure: [cells - vertices, faces - vertices]

So cell - face need not be stored anywhere. Presumably there is a reason why 
Matt didn't write it this way. Is it just uniformity of data structure?

Do we mean the same by partially interpolated mesh? What I mean is a mesh the 
only faces that are explicitly stored are the one we are interested in 
(typically the boundary mesh). For P1 elements, we need only to know of [cells, 
some faces, vertices]. I tried to manually build partially interpolated sieves 
with only some of the faces, and distribution would fail. That's how I ended up 
with a mix of cells of co-dimension 0 and 1. If one wants access to ALL faces / 
edges or none of them, there is no problem in the current implementation.

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







-- next part --
An HTML attachment was scrubbed...
URL: 

[petsc-dev] PetscSection

[Blaise A Bourdin]

On Nov 10, 2012, at 1:44 PM, Matthew Knepley knepley at gmail.com
 wrote:

 On Sat, Nov 10, 2012 at 2:33 PM, Jed Brown jedbrown at mcs.anl.gov wrote:
 On Sat, Nov 10, 2012 at 1:26 PM, Matthew Knepley knepley at gmail.com 
 wrote:
 
 I do not understand. Codim 0 and 1 are handled in an identical way.
 
 
 The user doesn't do the same thing with them. Your data structure treats
 them the same way (though I'm not sure how you distinguish between a tet and
 a quad if both are height 0 and you don't store intermediate levels), but
 that seems like an implementation detail to me.
 
 Yes, I agree that they are different geometrically, and in PyLith we
 make Labels to
 distinguish, which I think is the right way.

I actually disagree they may or may not be treated different. It all depends on 
what you want to do. If all you are interested in is computing integrals, 
elements are elements are elements. There is no fundamental difference between 
computing integrals over surfaces or volumes. And the user already needs to 
keep track of the polynomial order, interpolation type, integration type etc on 
a per element or per block of elements basis, right? If you cache the values of 
your FE basis functions at integration points and integration weights, 
integrating over a surface or an element is _exactly_ the same thing.

 
 
 I am not against some convenience interface for dim/co-dim, however it
 would
 just be implemented by making a label, since we have many equivalent
 structural
 things which would map to it.
 
 
 Fine, I care much more about conceptual simplicity in the interface. I think
 adoption will be higher if 95% of users don't see the word stratum.
 
 Note that this will have to be set explicitly somehow, since you cannot tell
 from the DAG that something has a given dimension/co-dim.

You can also not say anything about the element type from the DAG either. Is 
this a problem? Of course no. My point is that if a mesh has cells with 
different codimension, this information is something in the description from 
which the DM was created, and was probably imported somewhere in an IS, right?

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

[petsc-dev] PetscSection

[Blaise A Bourdin]

On Nov 10, 2012, at 1:54 PM, Jed Brown jedbrown at mcs.anl.govmailto:jedbrown 
at mcs.anl.gov wrote:

On Sat, Nov 10, 2012 at 1:44 PM, Matthew Knepley knepley at 
gmail.commailto:knepley at gmail.com wrote:
Yes, I agree that they are different geometrically, and in PyLith we
make Labels to
distinguish, which I think is the right way.

Cool. Of course you have to create the labels somehow. Do you currently make 
labels for all the sidesets in the mesh you load (e.g., from exodus)?

For exodus, I don't read side sets. The exodus interface for side set is really 
crappy, and does not allow an side set _inside_ the domain. Instead, I do not 
assume that all elements have the same codimension.


Labels in their current form seem to do two things (denote sets and associate 
values with points in those sets). Don't you frequently want one or the other?

 Fine, I care much more about conceptual simplicity in the interface. I think
 adoption will be higher if 95% of users don't see the word stratum.

Note that this will have to be set explicitly somehow, since you cannot tell
from the DAG that something has a given dimension/co-dim.

Are your points not sorted by dimension? (Most of the code I've seen in the 
examples assumes homogeneous strata.)

Nope... and please, don't break that...

Here is an example of a mesh with 4 element blocks. In an analysis code, for 
each block , I would specify the element type, type of physics, coefficients 
etc in a petscBag. That said, I may be doing it wrong...

block 10 is made of tri
block 22 is made of quad
blocks 100 and 102 are made of bars
iMac:Exodus blaise$ ./test1 -i Square-mixed2.gen

dm:
Mesh in 2 dimensions:
  0-cells: 9
  2-cells: 12
[0]: Number of vertices in mesh: 9
[0]: Number of cells in mesh: 12
viewing Mesh 'mesh'
Max sizes cone: 4 support: 5
viewing IFSieve 'mesh sieve'
cap -- base:
[0]: 12  0
[0]: 12  1
[0]: 12  4
[0]: 12  3
[0]: 12  5
[0]: 13  6
[0]: 13  0
[0]: 13  7
[0]: 13  5
[0]: 14  1
[0]: 14  6
[0]: 14  0
[0]: 15  2
[0]: 15  3
[0]: 15  1
[0]: 16  11
[0]: 16  2
[0]: 17  10
[0]: 17  3
[0]: 17  4
[0]: 17  11
[0]: 17  2
[0]: 18  8
[0]: 18  10
[0]: 18  4
[0]: 19  5
[0]: 19  9
[0]: 19  8
[0]: 19  4
[0]: 20  7
[0]: 20  5
[0]: 20  9
base -- cap:
[0]: 012
[0]: 013
[0]: 014
[0]: 112
[0]: 114
[0]: 115
[0]: 215
[0]: 216
[0]: 217
[0]: 315
[0]: 317
[0]: 312
[0]: 412
[0]: 417
[0]: 418
[0]: 419
[0]: 519
[0]: 520
[0]: 513
[0]: 512
[0]: 613
[0]: 614
[0]: 720
[0]: 713
[0]: 818
[0]: 819
[0]: 919
[0]: 920
[0]: 1017
[0]: 1018
[0]: 1116
[0]: 1117
Orientation:
[0]: 012: 0
[0]: 013: 0
[0]: 014: 0
[0]: 112: 0
[0]: 114: 0
[0]: 115: 0
[0]: 215: 0
[0]: 216: 0
[0]: 217: 0
[0]: 315: 0
[0]: 317: 0
[0]: 312: 0
[0]: 412: 0
[0]: 417: 0
[0]: 418: 0
[0]: 419: 0
[0]: 519: 0
[0]: 520: 0
[0]: 513: 0
[0]: 512: 0
[0]: 613: 0
[0]: 614: 0
[0]: 720: 0
[0]: 713: 0
[0]: 818: 0
[0]: 819: 0
[0]: 919: 0
[0]: 920: 0
[0]: 1017: 0
[0]: 1018: 0
[0]: 1116: 0
[0]: 1117: 0
viewing GeneralSection 'coordinates'
  Fields: 0
[0]:   12 dim 2 offset 0   0 0
[0]:   13 dim 2 offset 2   -0.5 0
[0]:   14 dim 2 offset 4   -0.5 -0.5
[0]:   15 dim 2 offset 6   0 -0.5
[0]:   16 dim 2 offset 8   0.5 -0.5
[0]:   17 dim 2 offset 10   0.5 0
[0]:   18 dim 2 offset 12   0.5 0.5
[0]:   19 dim 2 offset 14   0 0.5
[0]:   20 dim 2 offset 16   -0.5 0.5
viewing LabelSifter: 'Cell sets'
cap -- base:
[0]: 100
[0]: 101
[0]: 102
[0]: 103
[0]: 224
[0]: 225
[0]: 1006
[0]: 1007
[0]: 1028
[0]: 1029
[0]: 10210
[0]: 10211
viewing LabelSifter: 'Vertex sets'
cap -- base:
[0]: 116
[0]: 117
[0]: 118


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







-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/41b921c0/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: test1.c
Type: application/octet-stream
Size: 2711 bytes
Desc: test1.c
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/41b921c0/attachment-0002.obj
-- next part --
A non-text attachment was scrubbed...
Name: Square-mixed2.gen
Type: application/octet-stream
Size: 2572 bytes
Desc: Square-mixed2.gen
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/41b921c0/attachment-0003.obj

[petsc-dev] PetscSection

[Blaise A Bourdin]

On Nov 10, 2012, at 2:29 PM, Jed Brown jedbrown at mcs.anl.govmailto:jedbrown 
at mcs.anl.gov
 wrote:

On Sat, Nov 10, 2012 at 2:09 PM, Blaise A Bourdin bourdin at 
lsu.edumailto:bourdin at lsu.edu wrote:
Nope... and please, don't break that...

Here is an example of a mesh with 4 element blocks. In an analysis code, for 
each block , I would specify the element type, type of physics, coefficients 
etc in a petscBag. That said, I may be doing it wrong...

block 10 is made of tri
block 22 is made of quad
blocks 100 and 102 are made of bars

I'm not suggesting any demotion of this ability. I'm trying to understand what 
is the advantage of having a stratum with unsorted mixed dimension. If the 
blocks were sorted by dimension, you would still access them using a label 
(which gives you an index set, perhaps contiguous). You would still be able to 
do all the normal operations with those points. If you want to have one loop 
over all elements of the various types, you would union or concatenate the 
index sets of each type. Am I missing something?

No, you are absolutely right. I get your point now.

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







-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/ae12d685/attachment.html

[petsc-dev] MatZeroRowsColumnsStencil does not have a fortran binding

[Blaise A Bourdin]

On Nov 4, 2012, at 1:28 PM, Jed Brown jedbrown at mcs.anl.govmailto:jedbrown 
at mcs.anl.gov
 wrote:

Pushed to 3.3.
Thanks

In the future, can you make patches by committing locally and using hg export 
(or even hg email)? This patch had DOS-style formatting that needed to be 
converted before applying.

Weird... the patch I sent shows up as unix (LF) line endings in bbedit. It 
looks like LSU's exchange server is doing something funky with line endings.

Blaise


http://petsc.cs.iit.edu/petsc/releases/petsc-3.3/rev/ca8b914ed071


On Sun, Nov 4, 2012 at 12:52 PM, Blaise A Bourdin bourdin at 
lsu.edumailto:bourdin at lsu.edu wrote:
Hi,

Right now, MatZeroRowsStencil has a fortran binding, but 
MatZeroRowsColumnsStencil does not.
Is it possible to add the binding for MatZeroRowsColumnsStencil in petsc-3.3 
and petsc-dev?

I am attaching a patch for 3.3

Blaise


--
Department of Mathematics and Center for Computation  Technology
Louisiana State University, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612tel:%2B1%20%28225%29%20578%201612, Fax  +1 (225) 578 
4276tel:%2B1%20%28225%29%20578%204276 http://www.math.lsu.edu/~bourdin









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







-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121105/4aea2046/attachment.html

[petsc-dev] MatZeroRowsColumnsStencil does not have a fortran binding

[Blaise A Bourdin]

Hi,

Right now, MatZeroRowsStencil has a fortran binding, but 
MatZeroRowsColumnsStencil does not.
Is it possible to add the binding for MatZeroRowsColumnsStencil in petsc-3.3 
and petsc-dev?

I am attaching a patch for 3.3

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







-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121104/8252e65a/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: MatZeroRowsColumnsStencil.patch
Type: application/octet-stream
Size: 1730 bytes
Desc: MatZeroRowsColumnsStencil.patch
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121104/8252e65a/attachment.obj

[petsc-dev] PetscFindInt

[Blaise A Bourdin]

I'm not sure if I'm following the whole discussion but isn't the index fortran 
intrinsic the equivalent of this PetscFindInt? (Modulo returning a negative 
value) In which case, not having a fortran binding would not be a big deal.

Blaise

Sent from a mobile device

On Sep 22, 2012, at 11:36 PM, Jed Brown jedbrown at mcs.anl.gov wrote:

 On Sat, Sep 22, 2012 at 4:10 PM, Matthew Knepley knepley at gmail.com wrote:
 I am fine with overloading the return value. It won't change how I use it.
 
 http://petsc.cs.iit.edu/petsc/petsc-dev/rev/4abec2d5e3ad
 
 It's a shame we can't have C99-style inline semantics. I'd like to give the 
 compiler the option of inlining it, but I don't know how to do Fortran 
 bindings for that (other than write it custom) if I make it a 
 PETSC_STATIC_INLINE. Oh well, that can wait.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120923/a6aa025e/attachment.html

[petsc-dev] PetscFindInt

[Blaise A Bourdin]

Nvm, int, not string. My bad...


Sent from a mobile device

On Sep 23, 2012, at 12:37 AM, Blaise A Bourdin bourdin at lsu.edu wrote:

 I'm not sure if I'm following the whole discussion but isn't the index 
 fortran intrinsic the equivalent of this PetscFindInt? (Modulo returning a 
 negative value) In which case, not having a fortran binding would not be a 
 big deal.
 
 Blaise
 
 Sent from a mobile device
 
 On Sep 22, 2012, at 11:36 PM, Jed Brown jedbrown at mcs.anl.gov wrote:
 
 On Sat, Sep 22, 2012 at 4:10 PM, Matthew Knepley knepley at gmail.com 
 wrote:
 I am fine with overloading the return value. It won't change how I use it.
 
 http://petsc.cs.iit.edu/petsc/petsc-dev/rev/4abec2d5e3ad
 
 It's a shame we can't have C99-style inline semantics. I'd like to give 
 the compiler the option of inlining it, but I don't know how to do Fortran 
 bindings for that (other than write it custom) if I make it a 
 PETSC_STATIC_INLINE. Oh well, that can wait.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120923/9f12525b/attachment.html