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