Locally installed FFC not found on ARCHER
Dear firedrakers, I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use: RuntimeError: Incompatible Firedrake version 0.12.0 and FFC version unknown. So I installed FFC locally and added it to PYTHONPATH: /work/n02/n02/eike//git_workspace//firedrake-helmholtzsolver/source:/work/n02/n02/eike//git_workspace//firedrake-bench:/work/n02/n02/eike//git_workspace//pybench:/work/n02/n02/eike//git_workspace//firedrake:/work/n02/n02/eike//git_workspace//PyOP2:/work/n02/n02/eike//git_workspace//petsc4py/cray-gnu-shared/lib/python2.7/site-packages/:/work/n02/n02/eike//git_workspace//COFFEE/build/lib:/work/n02/n02/eike//git_workspace//ffc/build/lib.linux-x86_64-2.7/:/work/n02/n02/eike//Library:/work/y07/y07/fdrake/ufl/lib/python2.7/site-packages:/work/y07/y07/fdrake/scientificpython/lib/python2.7/site-packages:/work/y07/y07/fdrake/psutil/lib/python2.7/site-packages:/work/y07/y07/fdrake/mpi4py/lib/python2.7/site-packages:/work/y07/y07/fdrake/instant/lib/python2.7/site-packages:/work/y07/y07/fdrake/fiat/lib/python2.7/site-packages:/work/y07/y07/fdrake/ffc/lib/python2.7/site-packages:/work/y07/y07/fdrake/decorator-3.4.0/lib/python2.7/site-packages:/work/y07/y07/fdrake/petsc/arch-linux2-cxx-opt/lib/pyth on2.7/site-packages:/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages:/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7:/usr/local/packages/cse/bolt/0.6/modules However, in python, the /work/y07/y07/fdrake version comes *first*, so it always picked up when I import ffc and I keep getting the error message above: eike@eslogin008 $ python Python 2.7.6 |Anaconda 1.9.2 (64-bit)| (default, Jan 17 2014, 10:13:17) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys print sys.path ['', '/work/y07/y07/fdrake/ffc/lib/python2.7/site-packages/FFC-1.4.0_-py2.7-linux-x86_64.egg', '/work/y07/y07/fdrake/decorator-3.4.0/lib/python2.7/site-packages/decorator-3.4.0-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/python_hostlist-1.14-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/GridDataFormats-0.2.4-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/setuptools-2.2-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/extasy.coco-0.1-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/MDAnalysis-0.8.1-py2.7-linux-x86_64.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/python_hostlist-1.14-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/GridDataFormats-0.2.4-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/apache_libcloud-0.15.1-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/setuptools-2.2-py2.7.egg', '/work/n02/n02/eike/git_workspace/firedrake-helmholtzsolver/source', '/work/n02/n02/eike/git_workspace/firedrake-bench', '/work/n02/n02/eike/git_workspace/pybench', '/work/n02/n02/eike/git_workspace/firedrake', '/work/n02/n02/eike/git_workspace/PyOP2', '/work/n02/n02/eike/git_workspace/petsc4py/cray-gnu-shared/lib/python2.7/site-packages', '/work/n02/n02/eike/git_workspace/COFFEE/build/lib', '/work/n02/n02/eike/git_workspace/ffc/build/lib.linux-x86_64-2.7', '/work/n02/n02/eike/Library', '/work/y07/y07/fdrake/ufl/lib/python2.7/site-packages', '/work/y07/y07/fdrake/scientificpython/lib/python2.7/site-packages', '/work/y07/y07/fdrake/psutil/lib/python2.7/site-packages', '/work/y07/y07/fdrake/mpi4py/lib/python2.7/site-packages', '/work/y07/y07/fdrake/instant/lib/python2.7/site-packages', '/work/y07/y07/fdrake/fiat/lib/python2.7/site-packages', '/work/y07/y07/fdrake/ffc/lib/python2.7/site-packages', '/work/y07/y07/fdrake/decorator-3.4.0/lib/python2.7/site-packages', '/work/y07/y07/fdrake/petsc/arch-linux2-cxx-opt/lib/python2.7/site-packages', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7', '/usr/local/packages/cse/bolt/0.6/modules', '/work/y07/y07/cse/anaconda/1.9.2/lib/python27.zip', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/plat-linux2', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/lib-tk', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/lib-old', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/lib-dynload', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/PIL']
Any idea what is going on here? I can of course remove the unwanted FFC path, but there must be a more obvious solution. Thanks a lot, Eike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/01/15 10:23, Eike Mueller wrote:
Dear firedrakers,
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use:
RuntimeError: Incompatible Firedrake version 0.12.0 and FFC version unknown.
So I installed FFC locally and added it to PYTHONPATH:
/work/n02/n02/eike//git_workspace//firedrake-helmholtzsolver/source:/work/n02/n02/eike//git_workspace//firedrake-bench:/work/n02/n02/eike//git_workspace//pybench:/work/n02/n02/eike//git_workspace//firedrake:/work/n02/n02/eike//git_workspace//PyOP2:/work/n02/n02/eike//git_workspace//petsc4py/cray-gnu-shared/lib/python2.7/site-packages/:/work/n02/n02/eike//git_workspace//COFFEE/build/lib:/work/n02/n02/eike//git_workspace//ffc/build/lib.linux-x86_64-2.7/:/work/n02/n02/eike//Library:/work/y07/y07/fdrake/ufl/lib/python2.7/site-packages:/work/y07/y07/fdrake/scientificpython/lib/python2.7/site-packages:/work/y07/y07/fdrake/psutil/lib/python2.7/site-packages:/work/y07/y07/fdrake/mpi4py/lib/python2.7/site-packages:/work/y07/y07/fdrake/instant/lib/python2.7/site-packages:/work/y07/y07/fdrake/fiat/lib/python2.7/site-packages:/work/y07/y07/fdrake/ffc/lib/python2.7/site-packages:/work/y07/y07/fdrake/decorator-3.4.0/lib/python2.7/site-packages:/work/y07/y07/fdrake/petsc/arch-linux2-cxx-opt/lib/py th
on2.7/site-packages:/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages:/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7:/usr/local/packages/cse/bolt/0.6/modules
However, in python, the /work/y07/y07/fdrake version comes *first*, so it always picked up when I import ffc and I keep getting the error message above:
This looks like the standard easy_install disaster. I never know how to fix this unfortunately. Lawrence -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUyg1oAAoJECOc1kQ8PEYvb9AIAM+5I1kkqWoEqyToKc/hv5tc pxTZ76N+0/oIAy+L0c7BDefn10ws8X/zC3dH6fuAaNeT+YPSXwGrapAp/atG0+I/ tbxULZnJgxaPRiwWz58Lz7j0nv9mvIatcQSSWaW4SjWU3uH2lsRegPiJHyy3wkZL 3jcCICx8Wj/0jyKGDkdkk8QXlYMJLp2m848oUDdZUy55tsmU7tWc6chsS5NdBVHw /Z6cY0RuG1fzL67RWU7O3pxuj8bmqyWBjc1NmWLikDR7eslykx2wjmHFRO+uHMtE E68Kfs5tw3nEdQbAO6hXNPs9HEzjbjKkoVLu855QPNg5JmIGiRFnFfNRA4ZMrVg= =+7qF -----END PGP SIGNATURE-----
Hi Lawrence, ok, adding import sys sys.path.remove('/work/y07/y07/fdrake/ffc/lib/python2.7/site-packages/FFC-1.4.0_-py2.7-linux-x86_64.egg') at the top of firedrake/__init__.py seems to fix it for me. Thanks, Eike On 29/01/15 10:37, Lawrence Mitchell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/01/15 10:23, Eike Mueller wrote:
Dear firedrakers,
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use:
RuntimeError: Incompatible Firedrake version 0.12.0 and FFC version unknown.
So I installed FFC locally and added it to PYTHONPATH:
/work/n02/n02/eike//git_workspace//firedrake-helmholtzsolver/source:/work/n02/n02/eike//git_workspace//firedrake-bench:/work/n02/n02/eike//git_workspace//pybench:/work/n02/n02/eike//git_workspace//firedrake:/work/n02/n02/eike//git_workspace//PyOP2:/work/n02/n02/eike//git_workspace//petsc4py/cray-gnu-shared/lib/python2.7/site-packages/:/work/n02/n02/eike//git_workspace//COFFEE/build/lib:/work/n02/n02/eike//git_workspace//ffc/build/lib.linux-x86_64-2.7/:/work/n02/n02/eike//Library:/work/y07/y07/fdrake/ufl/lib/python2.7/site-packages:/work/y07/y07/fdrake/scientificpython/lib/python2.7/site-packages:/work/y07/y07/fdrake/psutil/lib/python2.7/site-packages:/work/y07/y07/fdrake/mpi4py/lib/python2.7/site-packages:/work/y07/y07/fdrake/instant/lib/python2.7/site-packages:/work/y07/y07/fdrake/fiat/lib/python2.7/site-packages:/work/y07/y07/fdrake/ffc/lib/python2.7/site-packages:/work/y07/y07/fdrake/decorator-3.4.0/lib/python2.7/site-packages:/work/y07/y07/fdrake/petsc/arch-linux2-cxx-opt/lib/p y th
on2.7/site-packages:/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages:/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7:/usr/local/packages/cse/bolt/0.6/modules
However, in python, the /work/y07/y07/fdrake version comes *first*, so it always picked up when I import ffc and I keep getting the error message above:
This looks like the standard easy_install disaster. I never know how to fix this unfortunately.
Lawrence -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEcBAEBAgAGBQJUyg1oAAoJECOc1kQ8PEYvb9AIAM+5I1kkqWoEqyToKc/hv5tc pxTZ76N+0/oIAy+L0c7BDefn10ws8X/zC3dH6fuAaNeT+YPSXwGrapAp/atG0+I/ tbxULZnJgxaPRiwWz58Lz7j0nv9mvIatcQSSWaW4SjWU3uH2lsRegPiJHyy3wkZL 3jcCICx8Wj/0jyKGDkdkk8QXlYMJLp2m848oUDdZUy55tsmU7tWc6chsS5NdBVHw /Z6cY0RuG1fzL67RWU7O3pxuj8bmqyWBjc1NmWLikDR7eslykx2wjmHFRO+uHMtE E68Kfs5tw3nEdQbAO6hXNPs9HEzjbjKkoVLu855QPNg5JmIGiRFnFfNRA4ZMrVg= =+7qF -----END PGP SIGNATURE-----
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
Eike, I have fixed this, so you should be able to remove your hack. For reference: the problem is the following file: /work/y07/y07/fdrake/ffc/lib/python2.7/site-packages/easy-install.pth This file is (re)created *every time* the FFC installation is updated since FFC uses the setuptools egg installation. Due to a setuptools "feature" all the eggs contained in this file are *prepended* to sys.path and end up *before* anything in PYTHONPATH and there is *nothing* you can do to prevent this. The only fix is to edit this .pth file and remove or comment the offending lines (first and last). What we might be able to do is not actually install FFC but point the module at the source try and build the extension modules in place. Thoughts? On 29/01/15 11:25, Eike Mueller wrote:
Hi Lawrence,
ok, adding
import sys sys.path.remove('/work/y07/y07/fdrake/ffc/lib/python2.7/site-packages/FFC-1.4.0_-py2.7-linux-x86_64.egg')
at the top of firedrake/__init__.py seems to fix it for me.
Thanks,
Eike
On 29/01/15 10:37, Lawrence Mitchell wrote: On 29/01/15 10:23, Eike Mueller wrote:
Dear firedrakers,
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use:
RuntimeError: Incompatible Firedrake version 0.12.0 and FFC version unknown.
So I installed FFC locally and added it to PYTHONPATH:
/work/n02/n02/eike//git_workspace//firedrake-helmholtzsolver/source:/work/n02/n02/eike//git_workspace//firedrake-bench:/work/n02/n02/eike//git_workspace//pybench:/work/n02/n02/eike//git_workspace//firedrake:/work/n02/n02/eike//git_workspace//PyOP2:/work/n02/n02/eike//git_workspace//petsc4py/cray-gnu-shared/lib/python2.7/site-packages/:/work/n02/n02/eike//git_workspace//COFFEE/build/lib:/work/n02/n02/eike//git_workspace//ffc/build/lib.linux-x86_64-2.7/:/work/n02/n02/eike//Library:/work/y07/y07/fdrake/ufl/lib/python2.7/site-packages:/work/y07/y07/fdrake/scientificpython/lib/python2.7/site-packages:/work/y07/y07/fdrake/psutil/lib/python2.7/site-packages:/work/y07/y07/fdrake/mpi4py/lib/python2.7/site-packages:/work/y07/y07/fdrake/instant/lib/python2.7/site-packages:/work/y07/y07/fdrake/fiat/lib/python2.7/site-packages:/work/y07/y07/fdrake/ffc/lib/python2.7/site-packages:/work/y07/y07/fdrake/decorator-3.4.0/lib/python2.7/site-packages:/work/y07/y07/fdrake/petsc/arch-linux2-cxx-opt/lib /p
y th
on2.7/site-packages:/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages:/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7:/usr/local/packages/cse/bolt/0.6/modules
However, in python, the /work/y07/y07/fdrake version comes *first*, so it always picked up when I import ffc and I keep getting the error message above:
This looks like the standard easy_install disaster. I never know how to fix this unfortunately.
Lawrence
On 29/01/15 10:23, Eike Mueller wrote:
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use
I had a go at updating the "official" firedrake package on ARCHER and dependencies. I updated PETSc and petsc4py to the latest revision of the respective firedrake branch. Then I failed however building the firedrake extension modules due to the following error: /work/y07/y07/fdrake/petsc/include/petscsys.h:124:6: error: #error "PETSc was configured with one MPICH mpi.h v ersion but now appears to be compiling using a different MPICH mpi.h version" afaict we always use cray-mpich/7.0.3 for building petsc and everything else. No idea what triggers this error. On another note: I *really* don't have time to continue maintaining the fdrake modules on ARCHER and appreciate if someone else (Michael? Lawrence?) could take on this task. I also don't have time to sort out this current issue, sorry about that. Florian
Hi Florian, I recall having similar issues with incompatible MPI versions before, but can't find anything in my emails which points to a solution. I think the reason in my case was that the CRAY MPICH was updated at some point after the original /work/y07/y07/fdrake installation, but before I installed my own version. Could it be that mpi4py is still using the old MPICH and needs to be reinstalled? Cheers, Eike On 29/01/15 11:51, Florian Rathgeber wrote:
On 29/01/15 10:23, Eike Mueller wrote:
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use
I had a go at updating the "official" firedrake package on ARCHER and dependencies. I updated PETSc and petsc4py to the latest revision of the respective firedrake branch. Then I failed however building the firedrake extension modules due to the following error:
/work/y07/y07/fdrake/petsc/include/petscsys.h:124:6: error: #error "PETSc was configured with one MPICH mpi.h v ersion but now appears to be compiling using a different MPICH mpi.h version"
afaict we always use cray-mpich/7.0.3 for building petsc and everything else. No idea what triggers this error.
On another note: I *really* don't have time to continue maintaining the fdrake modules on ARCHER and appreciate if someone else (Michael? Lawrence?) could take on this task. I also don't have time to sort out this current issue, sorry about that.
Florian
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
On 1/29/2015 12:04 PM, Eike Mueller wrote:
Hi Florian,
I recall having similar issues with incompatible MPI versions before, but can't find anything in my emails which points to a solution. I think the reason in my case was that the CRAY MPICH was updated at some point after the original /work/y07/y07/fdrake installation, but before I installed my own version.
I would have expected something like this, but afaict we were using mpich 7.0.3 throughout.
Could it be that mpi4py is still using the old MPICH and needs to be reinstalled?
That is indeed a possibility. I wonder if you could get access to the fdrake account since you're pretty much the main user. Michael? Florian
Cheers,
Eike
On 29/01/15 11:51, Florian Rathgeber wrote:
On 29/01/15 10:23, Eike Mueller wrote:
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use
I had a go at updating the "official" firedrake package on ARCHER and dependencies. I updated PETSc and petsc4py to the latest revision of the respective firedrake branch. Then I failed however building the firedrake extension modules due to the following error:
/work/y07/y07/fdrake/petsc/include/petscsys.h:124:6: error: #error "PETSc was configured with one MPICH mpi.h v ersion but now appears to be compiling using a different MPICH mpi.h version"
afaict we always use cray-mpich/7.0.3 for building petsc and everything else. No idea what triggers this error.
On another note: I *really* don't have time to continue maintaining the fdrake modules on ARCHER and appreciate if someone else (Michael? Lawrence?) could take on this task. I also don't have time to sort out this current issue, sorry about that.
Florian
Hi Eike, I just updated the "firedrake" module on Archer and it should be fully functional again. Can you please give this a try and let me know if it works for you? The PETSc problem was due to fdrake-build-env pointing at a very old petsc build (petsc/dev), not the one Florian re-built yesterday (petsc/shared). I also pulled the entire mapdes stack forward, so we should be up-to-date with current master versions. Also, as a heads up, I am currently working with Tim Bond and Rupert Nash from EPCC on rolling out separate petsc-master and petsc4py-master packages that use the centrally installed (and supported) Python stack. This is possible after several updates to the Python environment on Archer and should allow us to get off the relatively unsupported Anaconda module to avoid more binary incompatibilities in the future. I'll post to the list once we're ready to switch. Thanks, Michael On 29/01/15 22:54, Florian Rathgeber wrote:
On 1/29/2015 12:04 PM, Eike Mueller wrote:
Hi Florian,
I recall having similar issues with incompatible MPI versions before, but can't find anything in my emails which points to a solution. I think the reason in my case was that the CRAY MPICH was updated at some point after the original /work/y07/y07/fdrake installation, but before I installed my own version. I would have expected something like this, but afaict we were using mpich 7.0.3 throughout.
Could it be that mpi4py is still using the old MPICH and needs to be reinstalled? That is indeed a possibility. I wonder if you could get access to the fdrake account since you're pretty much the main user. Michael?
Florian
Cheers,
Eike
On 29/01/15 11:51, Florian Rathgeber wrote:
On 29/01/15 10:23, Eike Mueller wrote:
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use I had a go at updating the "official" firedrake package on ARCHER and dependencies. I updated PETSc and petsc4py to the latest revision of the respective firedrake branch. Then I failed however building the firedrake extension modules due to the following error:
/work/y07/y07/fdrake/petsc/include/petscsys.h:124:6: error: #error "PETSc was configured with one MPICH mpi.h v ersion but now appears to be compiling using a different MPICH mpi.h version"
afaict we always use cray-mpich/7.0.3 for building petsc and everything else. No idea what triggers this error.
On another note: I *really* don't have time to continue maintaining the fdrake modules on ARCHER and appreciate if someone else (Michael? Lawrence?) could take on this task. I also don't have time to sort out this current issue, sorry about that.
Florian
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
Hi Michael, I'm using quite a few non-standard branches (petsc->knepley/fix-plex-1d-refinement, PyOP2->columnwise_kernels, firedrake->multigrid-extrusion) to get my extruded multigrid working. The dependency on the non-default PETSc required me to install both this and petsc4py locally. I also installed FFC, UFL, FIAT and COFFEE locally, since the central versions were still out-out-of-date yesterday. But to test your changes, I can try running a basic firedrake code and use the centrally installed firdrake version. Just to be clear: You updated both PyOP2 and firdrake centrally, so in the instructions here https://github.com/firedrakeproject/firedrake-bench/wiki/Archer I do not need to build a local firedrake version and can leave out the following in firedrake.env and my jobscript: export PYTHONPATH=$WORK/firedrake-bench:$WORK/pybench:$WORK/firedrake:$WORK/PyOP2:$PYTHONPATH Thanks, Eike On 30/01/15 07:21, Michael Lange wrote:
Hi Eike,
I just updated the "firedrake" module on Archer and it should be fully functional again. Can you please give this a try and let me know if it works for you?
The PETSc problem was due to fdrake-build-env pointing at a very old petsc build (petsc/dev), not the one Florian re-built yesterday (petsc/shared). I also pulled the entire mapdes stack forward, so we should be up-to-date with current master versions.
Also, as a heads up, I am currently working with Tim Bond and Rupert Nash from EPCC on rolling out separate petsc-master and petsc4py-master packages that use the centrally installed (and supported) Python stack. This is possible after several updates to the Python environment on Archer and should allow us to get off the relatively unsupported Anaconda module to avoid more binary incompatibilities in the future. I'll post to the list once we're ready to switch.
Thanks, Michael
On 29/01/15 22:54, Florian Rathgeber wrote:
On 1/29/2015 12:04 PM, Eike Mueller wrote:
Hi Florian,
I recall having similar issues with incompatible MPI versions before, but can't find anything in my emails which points to a solution. I think the reason in my case was that the CRAY MPICH was updated at some point after the original /work/y07/y07/fdrake installation, but before I installed my own version. I would have expected something like this, but afaict we were using mpich 7.0.3 throughout.
Could it be that mpi4py is still using the old MPICH and needs to be reinstalled? That is indeed a possibility. I wonder if you could get access to the fdrake account since you're pretty much the main user. Michael?
Florian
Cheers,
Eike
On 29/01/15 11:51, Florian Rathgeber wrote:
On 29/01/15 10:23, Eike Mueller wrote:
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use I had a go at updating the "official" firedrake package on ARCHER and dependencies. I updated PETSc and petsc4py to the latest revision of the respective firedrake branch. Then I failed however building the firedrake extension modules due to the following error:
/work/y07/y07/fdrake/petsc/include/petscsys.h:124:6: error: #error "PETSc was configured with one MPICH mpi.h v ersion but now appears to be compiling using a different MPICH mpi.h version"
afaict we always use cray-mpich/7.0.3 for building petsc and everything else. No idea what triggers this error.
On another note: I *really* don't have time to continue maintaining the fdrake modules on ARCHER and appreciate if someone else (Michael? Lawrence?) could take on this task. I also don't have time to sort out this current issue, sorry about that.
Florian
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
On 30/01/15 10:13, Eike Mueller wrote:
Hi Michael,
I'm using quite a few non-standard branches (petsc->knepley/fix-plex-1d-refinement, PyOP2->columnwise_kernels, firedrake->multigrid-extrusion) to get my extruded multigrid working. The dependency on the non-default PETSc required me to install both this and petsc4py locally. I also installed FFC, UFL, FIAT and COFFEE locally, since the central versions were still out-out-of-date yesterday. In that case I suggest creating your own local module file for the python env, starting from fdrake-python-env as a template, where you can explicitly select the branch builds you require. The central module, however, should always always be self-contained.
But to test your changes, I can try running a basic firedrake code and use the centrally installed firdrake version.
Just to be clear: You updated both PyOP2 and firdrake centrally, so in the instructions here https://github.com/firedrakeproject/firedrake-bench/wiki/Archer I do not need to build a local firedrake version and can leave out the following in firedrake.env and my jobscript:
export PYTHONPATH=$WORK/firedrake-bench:$WORK/pybench:$WORK/firedrake:$WORK/PyOP2:$PYTHONPATH Yes, it should work without this line now. I don't know why these components had been disabled in the central module.
Thanks, Michael
Thanks,
Eike
On 30/01/15 07:21, Michael Lange wrote:
Hi Eike,
I just updated the "firedrake" module on Archer and it should be fully functional again. Can you please give this a try and let me know if it works for you?
The PETSc problem was due to fdrake-build-env pointing at a very old petsc build (petsc/dev), not the one Florian re-built yesterday (petsc/shared). I also pulled the entire mapdes stack forward, so we should be up-to-date with current master versions.
Also, as a heads up, I am currently working with Tim Bond and Rupert Nash from EPCC on rolling out separate petsc-master and petsc4py-master packages that use the centrally installed (and supported) Python stack. This is possible after several updates to the Python environment on Archer and should allow us to get off the relatively unsupported Anaconda module to avoid more binary incompatibilities in the future. I'll post to the list once we're ready to switch.
Thanks, Michael
On 29/01/15 22:54, Florian Rathgeber wrote:
On 1/29/2015 12:04 PM, Eike Mueller wrote:
Hi Florian,
I recall having similar issues with incompatible MPI versions before, but can't find anything in my emails which points to a solution. I think the reason in my case was that the CRAY MPICH was updated at some point after the original /work/y07/y07/fdrake installation, but before I installed my own version. I would have expected something like this, but afaict we were using mpich 7.0.3 throughout.
Could it be that mpi4py is still using the old MPICH and needs to be reinstalled? That is indeed a possibility. I wonder if you could get access to the fdrake account since you're pretty much the main user. Michael?
Florian
Cheers,
Eike
On 29/01/15 11:51, Florian Rathgeber wrote:
On 29/01/15 10:23, Eike Mueller wrote:
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use I had a go at updating the "official" firedrake package on ARCHER and dependencies. I updated PETSc and petsc4py to the latest revision of the respective firedrake branch. Then I failed however building the firedrake extension modules due to the following error:
/work/y07/y07/fdrake/petsc/include/petscsys.h:124:6: error: #error "PETSc was configured with one MPICH mpi.h v ersion but now appears to be compiling using a different MPICH mpi.h version"
afaict we always use cray-mpich/7.0.3 for building petsc and everything else. No idea what triggers this error.
On another note: I *really* don't have time to continue maintaining the fdrake modules on ARCHER and appreciate if someone else (Michael? Lawrence?) could take on this task. I also don't have time to sort out this current issue, sorry about that.
Florian
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
Hi Michael, ok, so you suggest I still use the central fdrake-build-env (which adds swig to PYTHONPATH), but create my own copy of fdrake-python-env, where I replace $root by my installation directory? Would it make sense to still use some of the centrally installed packages such as prepend-path PYTHONPATH "$root/decorator-3.4.0/lib/python2.7/site-packages" prepend-path PYTHONPATH "$root/instant/lib/python2.7/site-packages" prepend-path PYTHONPATH "$root/mpi4py/lib/python2.7/site-packages" prepend-path PYTHONPATH "$root/psutil/lib/python2.7/site-packages" prepend-path PYTHONPATH "$root/scientificpython/lib/python2.7/site-packages" (and swig) and only install the following locally: prepend-path PYTHONPATH "$root/ffc/lib/python2.7/site-packages" prepend-path PYTHONPATH "$root/fiat/lib/python2.7/site-packages" prepend-path PYTHONPATH "$root/ufl/lib/python2.7/site-packages" prepend-path PYTHONPATH "$root/coffee/lib/python2.7/site-packages" prepend-path PYTHONPATH "$root/PyOP2/lib/python2.7/site-packages" prepend-path PYTHONPATH "$root/firedrake/lib/python2.7/site-packages" ? Why are there two files (fdrake-build-env and fdrake-python-env) in the first place, if they are always loaded together? Wouldn't it make sense if I just create one file (i.e. add everything in fdrake-build-env at the top of my local fdrake-python-env? Thanks, Eike On 30/01/15 10:29, Michael Lange wrote:
On 30/01/15 10:13, Eike Mueller wrote:
Hi Michael,
I'm using quite a few non-standard branches (petsc->knepley/fix-plex-1d-refinement, PyOP2->columnwise_kernels, firedrake->multigrid-extrusion) to get my extruded multigrid working. The dependency on the non-default PETSc required me to install both this and petsc4py locally. I also installed FFC, UFL, FIAT and COFFEE locally, since the central versions were still out-out-of-date yesterday. In that case I suggest creating your own local module file for the python env, starting from fdrake-python-env as a template, where you can explicitly select the branch builds you require. The central module, however, should always always be self-contained.
But to test your changes, I can try running a basic firedrake code and use the centrally installed firdrake version.
Just to be clear: You updated both PyOP2 and firdrake centrally, so in the instructions here https://github.com/firedrakeproject/firedrake-bench/wiki/Archer I do not need to build a local firedrake version and can leave out the following in firedrake.env and my jobscript:
export PYTHONPATH=$WORK/firedrake-bench:$WORK/pybench:$WORK/firedrake:$WORK/PyOP2:$PYTHONPATH
Yes, it should work without this line now. I don't know why these components had been disabled in the central module.
Thanks, Michael
Thanks,
Eike
On 30/01/15 07:21, Michael Lange wrote:
Hi Eike,
I just updated the "firedrake" module on Archer and it should be fully functional again. Can you please give this a try and let me know if it works for you?
The PETSc problem was due to fdrake-build-env pointing at a very old petsc build (petsc/dev), not the one Florian re-built yesterday (petsc/shared). I also pulled the entire mapdes stack forward, so we should be up-to-date with current master versions.
Also, as a heads up, I am currently working with Tim Bond and Rupert Nash from EPCC on rolling out separate petsc-master and petsc4py-master packages that use the centrally installed (and supported) Python stack. This is possible after several updates to the Python environment on Archer and should allow us to get off the relatively unsupported Anaconda module to avoid more binary incompatibilities in the future. I'll post to the list once we're ready to switch.
Thanks, Michael
On 29/01/15 22:54, Florian Rathgeber wrote:
On 1/29/2015 12:04 PM, Eike Mueller wrote:
Hi Florian,
I recall having similar issues with incompatible MPI versions before, but can't find anything in my emails which points to a solution. I think the reason in my case was that the CRAY MPICH was updated at some point after the original /work/y07/y07/fdrake installation, but before I installed my own version. I would have expected something like this, but afaict we were using mpich 7.0.3 throughout.
Could it be that mpi4py is still using the old MPICH and needs to be reinstalled? That is indeed a possibility. I wonder if you could get access to the fdrake account since you're pretty much the main user. Michael?
Florian
Cheers,
Eike
On 29/01/15 11:51, Florian Rathgeber wrote:
On 29/01/15 10:23, Eike Mueller wrote: > I need to install my own version of FFC, since the one already > installed > in /work/y07/y07/fdrake appears not to be compatible with the > firedrake > version I use I had a go at updating the "official" firedrake package on ARCHER and dependencies. I updated PETSc and petsc4py to the latest revision of the respective firedrake branch. Then I failed however building the firedrake extension modules due to the following error:
/work/y07/y07/fdrake/petsc/include/petscsys.h:124:6: error: #error "PETSc was configured with one MPICH mpi.h v ersion but now appears to be compiling using a different MPICH mpi.h version"
afaict we always use cray-mpich/7.0.3 for building petsc and everything else. No idea what triggers this error.
On another note: I *really* don't have time to continue maintaining the fdrake modules on ARCHER and appreciate if someone else (Michael? Lawrence?) could take on this task. I also don't have time to sort out this current issue, sorry about that.
Florian
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
Hi Michael,
In that case I suggest creating your own local module file for the python env, starting from fdrake-python-env as a template, where you can explicitly select the branch builds you require. The central module, however, should always always be self-contained.
I've done that now, and it all works fine again. I.e. if I use my locally build firedrake installation I can run the 3d solver code for the gravity wave system. I still use decorator-3.4.0, instant, psutil and scientificpython from the central firedrake installation since I can't be bothered to reinstall these locally, and it doesn't seem necessary.
Yes, it should work without this line now. I don't know why these components had been disabled in the central module.
I took the firedrake.env and firedrake.tpl from the webpage (https://github.com/firedrakeproject/firedrake-bench/wiki/Archer) and removed the references to the local PyOP2, petsc4py, firedrake, ufl, fiat and ffc. To be precise, the files I use are attached. I then tried to run the Poisson testcase as described on the webpage and it goes through fine. Note that I had to add export LD_LIBRARY_PATH=$ANACONDA_LIB:${LD_LIBRARY_PATH} in firedrake.tpl, otherwise I get python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory Application 12817509 exit codes: 127 Application 12817509 resources: utime ~0s, stime ~0s, Rss ~4296, inblocks ~15, outblocks ~19 Do you have to uncomment prepend-path LD_LIBRARY_PATH $env(ANACONDA_LIB) in the central fdrake-python-env again? That's what I did in my local module file (i.e. the one I use to run with my local firedrake installation) and it doesn't seem to break the module command any more. Are you happy for me to go ahead and update the firedrake.tpl and firedrake.env on the webpage? Thanks, Eike
Thanks,
Eike
On 30/01/15 07:21, Michael Lange wrote:
Hi Eike,
I just updated the "firedrake" module on Archer and it should be fully functional again. Can you please give this a try and let me know if it works for you?
The PETSc problem was due to fdrake-build-env pointing at a very old petsc build (petsc/dev), not the one Florian re-built yesterday (petsc/shared). I also pulled the entire mapdes stack forward, so we should be up-to-date with current master versions.
Also, as a heads up, I am currently working with Tim Bond and Rupert Nash from EPCC on rolling out separate petsc-master and petsc4py-master packages that use the centrally installed (and supported) Python stack. This is possible after several updates to the Python environment on Archer and should allow us to get off the relatively unsupported Anaconda module to avoid more binary incompatibilities in the future. I'll post to the list once we're ready to switch.
Thanks, Michael
On 29/01/15 22:54, Florian Rathgeber wrote:
On 1/29/2015 12:04 PM, Eike Mueller wrote:
Hi Florian,
I recall having similar issues with incompatible MPI versions before, but can't find anything in my emails which points to a solution. I think the reason in my case was that the CRAY MPICH was updated at some point after the original /work/y07/y07/fdrake installation, but before I installed my own version. I would have expected something like this, but afaict we were using mpich 7.0.3 throughout.
Could it be that mpi4py is still using the old MPICH and needs to be reinstalled? That is indeed a possibility. I wonder if you could get access to the fdrake account since you're pretty much the main user. Michael?
Florian
Cheers,
Eike
On 29/01/15 11:51, Florian Rathgeber wrote:
On 29/01/15 10:23, Eike Mueller wrote: > I need to install my own version of FFC, since the one already > installed > in /work/y07/y07/fdrake appears not to be compatible with the > firedrake > version I use I had a go at updating the "official" firedrake package on ARCHER and dependencies. I updated PETSc and petsc4py to the latest revision of the respective firedrake branch. Then I failed however building the firedrake extension modules due to the following error:
/work/y07/y07/fdrake/petsc/include/petscsys.h:124:6: error: #error "PETSc was configured with one MPICH mpi.h v ersion but now appears to be compiling using a different MPICH mpi.h version"
afaict we always use cray-mpich/7.0.3 for building petsc and everything else. No idea what triggers this error.
On another note: I *really* don't have time to continue maintaining the fdrake modules on ARCHER and appreciate if someone else (Michael? Lawrence?) could take on this task. I also don't have time to sort out this current issue, sorry about that.
Florian
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
Hi Michael, my current configuration broke with the recent update of the central installation. The centrally installed modules end up in the Python path in front of the locally installed ones: sys.path=['/fs2/n02/n02/eike/git_workspace/firedrake-helmholtzsolver/source', '/fs2/y07/y07/fdrake/decorator-3.4.0/lib/python2.7/site-packages/decorator-3.4.0-py2.7.egg', '/work/y07/y07/fdrake/PyOP2/lib/python2.7/site-packages/PyOP2-0.11.0_153_g63f5afb_dirty-py2.7-linux-x86_64.egg', '/fs2/y07/y07/fdrake/coffee/lib/python2.7/site-packages/COFFEE-0.1.0-py2.7.egg', '/work/y07/y07/fdrake/coffee/lib/python2.7/site-packages/COFFEE-0.1.0-py2.7.egg', '/work/y07/y07/fdrake/ffc/lib/python2.7/site-packages/FFC-1.5.0_-py2.7-linux-x86_64.egg', '/work/y07/y07/fdrake/decorator-3.4.0/lib/python2.7/site-packages/decorator-3.4.0-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/python_hostlist-1.14-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/GridDataFormats-0.2.4-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/setuptools-2.2-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/extasy.coco-0.1-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/MDAnalysis-0.8.1-py2.7-linux-x86_64.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/python_hostlist-1.14-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/GridDataFormats-0.2.4-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/apache_libcloud-0.15.1-py2.7.egg', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/setuptools-2.2-py2.7.egg', '/work/n02/n02/eike/git_workspace/firedrake-helmholtzsolver/source', '/work/n02/n02/eike/git_workspace/ufl/build/lib', '/work/n02/n02/eike/git_workspace/fiat/build/lib', '/work/n02/n02/eike/git_workspace/ffc/build/lib.linux-x86_64-2.7', '/work/n02/n02/eike/git_workspace/COFFEE/build/lib', '/work/n02/n02/eike/git_workspace/firedrake', '/work/n02/n02/eike/git_workspace/PyOP2', '/work/n02/n02/eike/git_workspace/petsc4py/cray-gnu-shared/lib/python2.7/site-packages', '/work/n02/n02/eike/Library/mpi4py/lib/python2.7/site-packages', '/work/n02/n02/eike/git_workspace/pybench', '/work/n02/n02/eike/git_workspace/firedrake-bench', '/work/y07/y07/fdrake/firedrake/lib/python2.7/site-packages', '/work/y07/y07/fdrake/PyOP2/lib/python2.7/site-packages', '/work/y07/y07/fdrake/coffee/lib/python2.7/site-packages', '/work/y07/y07/fdrake/ufl/lib/python2.7/site-packages', '/work/y07/y07/fdrake/scientificpython/lib/python2.7/site-packages', '/work/y07/y07/fdrake/psutil/lib/python2.7/site-packages', '/work/y07/y07/fdrake/mpi4py/lib/python2.7/site-packages', '/work/y07/y07/fdrake/instant/lib/python2.7/site-packages', '/work/y07/y07/fdrake/fiat/lib/python2.7/site-packages', '/work/y07/y07/fdrake/ffc/lib/python2.7/site-packages', '/work/y07/y07/fdrake/decorator-3.4.0/lib/python2.7/site-packages', '/work/y07/y07/fdrake/petsc/cray-gnu-shared/lib/python2.7/site-packages', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7', '/opt/cray/sdb/1.0-1.0501.48084.4.48.ari/lib64/py', '/work/y07/y07/cse/anaconda/1.9.2/lib/python27.zip', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/plat-linux2', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/lib-tk', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/lib-old', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/lib-dynload', '/work/y07/y07/cse/anaconda/1.9.2/lib/python2.7/site-packages/PIL', '/opt/cray/sdb/1.0-1.0501.48084.4.48.ari/lib64/py'] Thanks, Eike On 30/01/15 07:21, Michael Lange wrote:
Hi Eike,
I just updated the "firedrake" module on Archer and it should be fully functional again. Can you please give this a try and let me know if it works for you?
The PETSc problem was due to fdrake-build-env pointing at a very old petsc build (petsc/dev), not the one Florian re-built yesterday (petsc/shared). I also pulled the entire mapdes stack forward, so we should be up-to-date with current master versions.
Also, as a heads up, I am currently working with Tim Bond and Rupert Nash from EPCC on rolling out separate petsc-master and petsc4py-master packages that use the centrally installed (and supported) Python stack. This is possible after several updates to the Python environment on Archer and should allow us to get off the relatively unsupported Anaconda module to avoid more binary incompatibilities in the future. I'll post to the list once we're ready to switch.
Thanks, Michael
On 29/01/15 22:54, Florian Rathgeber wrote:
On 1/29/2015 12:04 PM, Eike Mueller wrote:
Hi Florian,
I recall having similar issues with incompatible MPI versions before, but can't find anything in my emails which points to a solution. I think the reason in my case was that the CRAY MPICH was updated at some point after the original /work/y07/y07/fdrake installation, but before I installed my own version. I would have expected something like this, but afaict we were using mpich 7.0.3 throughout.
Could it be that mpi4py is still using the old MPICH and needs to be reinstalled? That is indeed a possibility. I wonder if you could get access to the fdrake account since you're pretty much the main user. Michael?
Florian
Cheers,
Eike
On 29/01/15 11:51, Florian Rathgeber wrote:
On 29/01/15 10:23, Eike Mueller wrote:
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use I had a go at updating the "official" firedrake package on ARCHER and dependencies. I updated PETSc and petsc4py to the latest revision of the respective firedrake branch. Then I failed however building the firedrake extension modules due to the following error:
/work/y07/y07/fdrake/petsc/include/petscsys.h:124:6: error: #error "PETSc was configured with one MPICH mpi.h v ersion but now appears to be compiling using a different MPICH mpi.h version"
afaict we always use cray-mpich/7.0.3 for building petsc and everything else. No idea what triggers this error.
On another note: I *really* don't have time to continue maintaining the fdrake modules on ARCHER and appreciate if someone else (Michael? Lawrence?) could take on this task. I also don't have time to sort out this current issue, sorry about that.
Florian
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
Hi, I'm having problems with my local PETSc (which I rebuild) now. When I compile code I get: eike@eslogin002 $ mpicc -std=c99 -fPIC -Wall -g -O3 -fno-tree-vectorize -I/work/n02/n02/eike/git_workspace/petsc/cray-gnu-shared/include -I/work/n02/n02/eike/git_workspace/petsc/include -I/work/n02/n02/eike/git_workspace/PyOP2/pyop2 -mavx -o /work/n02/n02/eike//pyop2-cache/d3a8b4069edd657dc6695d0d9e9e260c.so.tmp /work/n02/n02/eike//pyop2-cache/d3a8b4069edd657dc6695d0d9e9e260c.c -shared -L/work/n02/n02/eike/git_workspace/petsc/lib -L/work/n02/n02/eike/git_workspace/petsc/cray-gnu-shared/lib -Wl,-rpath,/work/n02/n02/eike/git_workspace/petsc/lib -Wl,-rpath,/work/n02/n02/eike/git_workspace/petsc/cray-gnu-shared/lib -lpetsc -lmIn file included from /work/n02/n02/eike/git_workspace/petsc/include/petscis.h:7:0, from /work/n02/n02/eike/git_workspace/petsc/include/petscvec.h:9, from /work/n02/n02/eike/git_workspace/petsc/include/petscmat.h:6, from /work/n02/n02/eike/git_workspace/PyOP2/pyop2/mat_utils.h:4, from /work/n02/n02/eike//pyop2-cache/d3a8b4069edd657dc6695d0d9e9e260c.c:2: /work/n02/n02/eike/git_workspace/petsc/include/petscsys.h:122:6: error: #error "PETSc was configured with MPICH but now appears to be compiling using a non-MPICH mpi.h" # error "PETSc was configured with MPICH but now appears to be compiling using a non-MPICH mpi.h" ^ I have the same issue on the login node and when running through a firedrake batch job. Could it be the mpi.h file in /work/n02/n02/eike/git_workspace/petsc/include/petsc-mpiuni that causes the problem? It's odd because it all worked yesterday. Thanks, Eike On 30/01/15 07:21, Michael Lange wrote:
Hi Eike,
I just updated the "firedrake" module on Archer and it should be fully functional again. Can you please give this a try and let me know if it works for you?
The PETSc problem was due to fdrake-build-env pointing at a very old petsc build (petsc/dev), not the one Florian re-built yesterday (petsc/shared). I also pulled the entire mapdes stack forward, so we should be up-to-date with current master versions.
Also, as a heads up, I am currently working with Tim Bond and Rupert Nash from EPCC on rolling out separate petsc-master and petsc4py-master packages that use the centrally installed (and supported) Python stack. This is possible after several updates to the Python environment on Archer and should allow us to get off the relatively unsupported Anaconda module to avoid more binary incompatibilities in the future. I'll post to the list once we're ready to switch.
Thanks, Michael
On 29/01/15 22:54, Florian Rathgeber wrote:
On 1/29/2015 12:04 PM, Eike Mueller wrote:
Hi Florian,
I recall having similar issues with incompatible MPI versions before, but can't find anything in my emails which points to a solution. I think the reason in my case was that the CRAY MPICH was updated at some point after the original /work/y07/y07/fdrake installation, but before I installed my own version. I would have expected something like this, but afaict we were using mpich 7.0.3 throughout.
Could it be that mpi4py is still using the old MPICH and needs to be reinstalled? That is indeed a possibility. I wonder if you could get access to the fdrake account since you're pretty much the main user. Michael?
Florian
Cheers,
Eike
On 29/01/15 11:51, Florian Rathgeber wrote:
On 29/01/15 10:23, Eike Mueller wrote:
I need to install my own version of FFC, since the one already installed in /work/y07/y07/fdrake appears not to be compatible with the firedrake version I use I had a go at updating the "official" firedrake package on ARCHER and dependencies. I updated PETSc and petsc4py to the latest revision of the respective firedrake branch. Then I failed however building the firedrake extension modules due to the following error:
/work/y07/y07/fdrake/petsc/include/petscsys.h:124:6: error: #error "PETSc was configured with one MPICH mpi.h v ersion but now appears to be compiling using a different MPICH mpi.h version"
afaict we always use cray-mpich/7.0.3 for building petsc and everything else. No idea what triggers this error.
On another note: I *really* don't have time to continue maintaining the fdrake modules on ARCHER and appreciate if someone else (Michael? Lawrence?) could take on this task. I also don't have time to sort out this current issue, sorry about that.
Florian
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/01/15 13:59, Eike Mueller wrote:
Hi,
I'm having problems with my local PETSc (which I rebuild) now. When I compile code I get:
eike@eslogin002 $ mpicc -std=c99 -fPIC -Wall -g -O3 -fno-tree-vectorize -I/work/n02/n02/eike/git_workspace/petsc/cray-gnu-shared/include -I/work/n02/n02/eike/git_workspace/petsc/include -I/work/n02/n02/eike/git_workspace/PyOP2/pyop2 -mavx -o /work/n02/n02/eike//pyop2-cache/d3a8b4069edd657dc6695d0d9e9e260c.so.tmp
/work/n02/n02/eike//pyop2-cache/d3a8b4069edd657dc6695d0d9e9e260c.c
-shared -L/work/n02/n02/eike/git_workspace/petsc/lib -L/work/n02/n02/eike/git_workspace/petsc/cray-gnu-shared/lib -Wl,-rpath,/work/n02/n02/eike/git_workspace/petsc/lib -Wl,-rpath,/work/n02/n02/eike/git_workspace/petsc/cray-gnu-shared/lib
- -lpetsc -lmIn file included from
/work/n02/n02/eike/git_workspace/petsc/include/petscis.h:7:0, from /work/n02/n02/eike/git_workspace/petsc/include/petscvec.h:9, from /work/n02/n02/eike/git_workspace/petsc/include/petscmat.h:6, from /work/n02/n02/eike/git_workspace/PyOP2/pyop2/mat_utils.h:4, from /work/n02/n02/eike//pyop2-cache/d3a8b4069edd657dc6695d0d9e9e260c.c:2:
/work/n02/n02/eike/git_workspace/petsc/include/petscsys.h:122:6: error:
#error "PETSc was configured with MPICH but now appears to be compiling using a non-MPICH mpi.h" # error "PETSc was configured with MPICH but now appears to be compiling using a non-MPICH mpi.h" ^
I have the same issue on the login node and when running through a firedrake batch job. Could it be the mpi.h file in
PETSc bakes in, *at configure time* the MPI it was configured with. Then at compile time it checks that this matches what it now sees. I think the problem here is that you're using "mpicc" as the compiler rather than "cc" with the result that you're getting the wrong MPI. You need to do something like: CC=cc export CC CXX=CC export CXX in your run script so that PyOP2 uses the right compiler. Lawrence -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUy5DNAAoJECOc1kQ8PEYvK6MH/jmjYJhwye+6I+Qsmym5kj+/ jZ9YwqwC2o5YA+Pp0oL3hb57TjA61Ev4Vjv+RhIwwR6IOTMWuYuqXsJ9YkkLuB4V 1DDf/XFMwMHMRdHeOp3pG5DU/d7GEafARsh2cLD3YsWEHeMc+7seHneFGgoirw7e v7BqyPLpkDeR9UatGqpMFhjdKVqzY+oNJ9JngRZGjlx+/2cVwsZVGvjfNdHugg/q WsZ4FnPdMNMzpsHUoJ6DwsRheAL8V9d/zg2dafXug5xX8ZvwGVYveH9t2a0FxOpW Aux9j9wJE2akQgVg0VAZS9fd16HlkspoVgWr4yeXtnOU41xCyuTet7AEoKg8Hxs= =Xec7 -----END PGP SIGNATURE-----
participants (4)
- 
                
                Eike Mueller
- 
                
                Florian Rathgeber
- 
                
                Lawrence Mitchell
- 
                
                Michael Lange