On 24 Apr 2018, at 22:00, Ed Bueler <elbueler@alaska.edu> wrote:

It looks like I have found part of my confusion.

I have now reinstalled firedrake with PETSC_DIR unset, so there is an old PETSc (i.e. 3.4.2) inside the firedrake directory. But if I run activate later it seems to use the value of PETSC_DIR at that time.

I'll reiterate that firedrake runs with (basically) petsc master. However, we had issues with changes not being made simultaneously in petsc and petsc4py. Hence we maintain a fork with known good branch pointers for both (and slepc and slepc4py). These are the "firedrake" branches you can see at github.com/firedrakeproject/petsc etc... firedrake-install clones and builds these packages. If you have PETSC_DIR set then it complains (or it should). You can run with your prebuilt petsc: run the install with --honour-petsc-dir. But we don't guarantee that you will get all the different bits matching.

This is my working explanation for why I get seg faults and why "gdb --args python3 MYSCRIPT.py" shows backtraces with the wrong PETSc (i.e. the 3.9 version I am using for other purposes).

So it looks like I should do

$ unset PETSC_DIR $ source firedrake/bin/activate

every time I start firedrake? Is this the correct action if one has PETSC_DIR set?

I think so yes. It's possible that this env variable interferes with the library that petsc4py loads, and if things have changed, maybe you get issues. Make sense? Cheers, Lawrence