- firedrake - imperial.ac.uk

Re: [firedrake] Solving this system of nonlinear equations
by David Ham 04 Sep '15

04 Sep '15

OK. I think I understand. In essence, assembling PETSc matrices is a core PyOP2 competence, so it *can* do this, although it'll be a little clunky because we don't have the full glory of Firedrake on top. I think it would help if you try to read some of the PyOP2 documentation for a bit of background: http://op2.github.io/PyOP2/concepts.html http://op2.github.io/PyOP2/kernels.html http://op2.github.io/PyOP2/linear_algebra.html http://op2.github.io/PyOP2/mixed.html The last one is important in this case because you're actually solving a mixed system over the mixed function space (A, B, C). Inconveniently, that means we need 3 kernels to assemble the residual and 7 kernels (one for each nonzero entry) to assemble the Jacobian. Once you have the code for assembling, I think it should be straightforward to provide PETSc4py with the right callbacks so that its variational inequality solver works. (Another possibility would be to bypass PyOP2 and write your own code accessing PETSc4py directly. That might actually be easier but assembly will be slower - which you may or may not care about). I don't have time right this instant to start writing out the Kernels (I have to teach on Monday and I'm not ready yet.) I'll try to get back to this later, or maybe someone else on the list will dive in and save me ;) Cheers, David On Fri, 4 Sep 2015 at 09:37 Justin Chang <jychang48(a)gmail.com> wrote: > Hi everyone, > > Thanks for the input. So I was leaning more towards employing the newton > method for solving this. And yes, all the vectors live in the same function > space. If the system of equations were solved at each node i, the residual > algebraic vector of size 3x1 would be: > > r = [c_A(i)+c_C(i)-psi_A(i); > c_B(i)+c_C(i)-psi_B(i); > k1*c_A(i)*c_B(i)-c_C(i)] > > and the Jacobian 3x3 matrix would be: > > J = [1, 0, 1; > 0, 1, 1; > k1*c_B(i), k1*c_A(i), -1] > > Ideally I would like to have these expressed as a PETSc matrix and vector > because I would like to employ PETSc’s variational inequality solver to > enforce lower/upper bounds for c_A/B/C. > > As for the pyop2 option: > > void solve_system(double *c_A, double *c_B, double *c_C, double *k1, >>> double *psi_A, double *psi_B) >>> { >>> >>> // In here, you can dereference these variables to get the components >>> // of each variable at the node, e.g. >>> >>> // Set first component of c_A to sum of first two components of psi_A. >>> c_A[0] = psi_A[0] + psi_A[1]; >>> } >>> >>> I guess you can either write the newton (or fixed point) iteration out >>> by hand in the kernel (it shouldn't be too difficult), or else make library >>> calls (getting the correct link lines is possible I think). >>> >>> Now in your code you do: >>> >>> solve_kernel = op2.Kernel(kernel_code, "solve_system") >>> >>> op2.par_loop(solve_kernel, >>> c_A.dof_dset.node_set, >>> c_A.dat(op2.WRITE), >>> c_B.dat(op2.WRITE), >>> c_C.dat(op2.WRITE), >>> k1.dat(op2.READ), >>> psi_A.dat(op2.READ), >>> psi_B.dat(op2.READ)) >>> >>> >>> Does this make sense? >>> >> > I am guessing void solve_system(…) is a separate C file called > solve_system.c but how exactly do I get the components of each variable at > the node? So here’s how I did this with scipy: > > ================================ > > # Advection-diffusion firedrake code > # Compute psi_A, psi_B, and k1 ... > … > > from scipy.optimize import solve > import math > > # Solve system of nonlinear reactions > def equations(p,psi_A,psi_B,k_1): > c_A,c_B,c_C = p > return (c_A+c_C-psi_A, c_B+c_C-psi_B, c_C-k_1*c_A*c_B) > > # define vectors for primary species > c_A_vec = np.zeros(len(psi_A.vector())) > c_B_vec = np.zeros(len(psi_A.vector())) > > # define vector for secondary species > c_C_vec = np.zeros(len(psi_A.vector())) > > # Iterate through each node > for i in range(len(psi_A.vector())): > c_A_i,c_B_i,c_C_i = > fsolve(equations,(0.0,0.0,0.0),args=(psi_A.vector()[i],psi_B.vector()[i],k1) > c_A_vec[i] = c_A_i > c_B_vec[i] = c_B_i > c_C_vec[i] = c_C_i > > # Output > c_A = Function(Q) > c_B = Function(Q) > c_C = Function(Q) > c_A.vector()[:] = c_A_vec > c_B.vector()[:] = c_B_vec > c_C.vector()[:] = c_C_vec > File(“Solution_c_A.pvd”) << c_A > File(“Solution_c_B.pvd”) << c_B > File(“Solution_c_C.pvd”) << c_C > > =================================== > > The PyOP2 equivalent of the above would be a good starting point I suppose. > > Thanks all, > Justin > >

1 0

Re: [firedrake] The wonderful world of firedrake-install
by David Ham 04 Sep '15

04 Sep '15

Hi Justin, Ah yes. I saw something like this when attempting to set up travis. The problem appears to be that the dependency analysis in pip is broken so it doesn't realise it has to build and install Cython before it builds h5py. I think the workaround is to force Cython installation in the install script before looking at the requirements file. I will push a branch presently and merge it as soon as it passes tests. Cheers, David On Fri, 4 Sep 2015 at 08:17 Justin Chang <jychang48(a)gmail.com> wrote: > Hi David > > Thanks for the updated script. So I am using the system provided > openmpi/1.8.3 module but built my own Python 2.7.10 and pip from source. I > am getting an error as shown in the attached firedrake-install.log > > I also got a similar issue when I built my own openmpi library, although > in that case I didn’t have the cython related errors and only had the ones > related to hdf5/h5py > > Any idea what this is? > > Thanks, > Justin > > > On Sep 3, 2015, at 8:54 AM, David Ham <David.Ham(a)imperial.ac.uk> wrote: > > The branch is merged now so I believe this is now fixed. > > David > > On Thu, 3 Sep 2015 at 12:09 David Ham <David.Ham(a)imperial.ac.uk> wrote: > > It turns out that this is for the usual reason: I am an idiot. A fix for > this is in the further-install-fixes branch and I will merge the branch as > soon as tests pass. > > (What's actually going on is that I am abusing CalledProcessError when I > should really raise a special exception for this case. I have now created a > new exception and raised that instead). > > Cheers, > > David > > On Thu, 3 Sep 2015 at 01:56 Justin Chang <jychang48(a)gmail.com> wrote: > > Thanks David, > > I actually forgot about the --no_package_manager option. But when I tried > installing with it, i get this error: > > $ python firedrake-install --no_package_manager > Traceback (most recent call last): > File "firedrake-install", line 265, in <module> > raise subprocess.CalledProcessError > TypeError: __init__() takes at least 3 arguments (1 given) > > Even if I add the --disable_ssh and --developer tags I get the above > error. Am I suppose to do something else with this? > > Thanks, > Justin > > On Tue, Sep 1, 2015 at 3:57 AM, David Ham <David.Ham(a)imperial.ac.uk> > wrote: > > Thanks, > > On Sun, 30 Aug 2015 at 08:15 Justin Chang <jychang48(a)gmail.com> wrote: > > I agree that hype and a sparse direct solver like mumps is necessary. > The latter needs --download-metis --download-parmetis > --download-scalapack. > > > Added and currently testing. > > > More comments: > > 4) If mumps is to be included, the install script has to ensure that > one has cmake >=2.5 when configuring metis, otherwise PETSc configure > will return an error. Perhaps include "brew install cmake" and "sudo > apt-get install cmake" in the script? > > > Also added. Thanks for catching this. > > > 5) Should --download-exodusii (and it's dependencies --download-netcdf > --download-hdf5) also be included in the PETSC_CONFIGURE_OPTIONS? I > imagine that if one wants to solve problems on large-scale > unstructured grids, .exo files would be more feasible to use over .msh > files. Or is exodusii already accounted for in firedrake/PyOP2/etc? > > > And this. > > > 6) If I run the script on a pristine MacOSX, I get an error saying > "OSError: Unable to find SWIG installation. Please install SWIG > version 2.0.0 or higher." I am guessing "brew install swig" was > somehow missed in the firedrake-install script? > > Ah yes. Fecking swig. I've added the dependency to the new branch. > Hopefully the swig dependency is going away very soon. > > > > 7) Perhaps not as important, but do y'all think it's possible to make > this script more non-Ubuntu HPC system friendly? For isntance, either > a) require the user to install his or her own local OpenMPI and Python > libraries from source, b) let script download the tarballs/git > repositories remotely and install it for you (kind of like how PETSc > handles external packages through --download-<package>), or c) enable > the user to point to the system provided OpenMPI and Python libraries. > Same would need to be done for CMake, SWIG, and PCRE as these packages > cannot simply be obtained from pip. > > > I think (c) is the case right now. If you run the script on a non-Ubuntu > system or pass the --no_package_manager option then it will just assume > that you have installed the dependencies somewhere visible and will get on > with pip. > > I think (b) is [a] hard and [b] in the case of MPI probably a bad idea. > Supercomputers are such a diverse bunch of hacked up distributions that I > think that installing the compiled dependencies automatically in a way > which is portable would require a lot of install script work. In the case > of MPI, you really need to use the MPI build which talks to the fast > interconnect on your supercomputer, so automatically building vanilla > OpenMPI is a Bad Thing. > > Cheers, > > David > > > > > Thanks, > Justin > > On Fri, Aug 28, 2015 at 7:20 AM, Lawrence Mitchell > <lawrence.mitchell(a)imperial.ac.uk> wrote: > > > >> On 28 Aug 2015, at 14:01, David Ham <David.Ham(a)imperial.ac.uk> wrote: > >> > >> Hi All, > >> > >> I have a branch going through testing now which will handle > PETSC_CONFIGURE_OPTIONS in a smarter way. Basically we'll just make sure > that the things which are required are there, and we'll also honour > anything the user has already set. I've also updated docs to say that > that's what happens. > >> > >> I am also open to the suggestion that we could add more configuration > options to the default set. Would anyone like to suggest what they should > be? > > > > I think --download-hypre=1 at least. Maybe also a sparse direct solver > (mumps?) which I think needs --download-metis --download-parmetis > --download-mumps (maybe some others?) > > > > Lawrence > > > > > > _______________________________________________ > > firedrake mailing list > > firedrake(a)imperial.ac.uk > > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > > > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > > >

1 0

Re: [firedrake] Solving this system of nonlinear equations
by Colin Cotter 04 Sep '15

04 Sep '15

If the two roots are always distinct, there is also Weierstrass iteration. cheers --cjc On 3 September 2015 at 12:42, McRae, Andrew <a.mcrae12(a)imperial.ac.uk> wrote: > Or, if you don't want to do Newton iterations > <http://www.wolframalpha.com/input/?i=solve+x+%2B+z+%3D+a%2C+y+%2B+z+%3D+b%2…>... > (it may well be the case the Newton iterations are faster, I don't know. > But you do have two solutions, so be careful). > > This still assumes that everything lives in the same functionspace, of > course. > > On 3 September 2015 at 12:29, Mitchell, Lawrence < > lawrence.mitchell(a)imperial.ac.uk> wrote: > >> >> > On 3 Sep 2015, at 01:20, Justin Chang <jychang48(a)gmail.com> wrote: >> > >> > Hi all, >> > >> > I need to solve the following system of chemical reaction equations: >> > >> > psi_A = c_A + c_C >> > psi_B = c_B + c_C >> > c_C = k1*c_A*c_B >> > >> > where psi_A, psi_B, and k1 are known. c_A, c_B, and c_C are the >> unknowns I need to solve. >> > >> > k1 is a scalar and psi_A, psi_B, c_A, c_B, and c_C are vectors of size >> N. >> > >> > psi_A and psi_B have been obtained through advection-diffusion >> equations. I need to "post-process" these solutions such that I get c_A, >> c_B, and c_C. The above system of equations are on a node-to-node basis >> (i.e., the reactions of node i are independent of node i+1). >> >> I assume that all the variables live in the same functionspace. So >> effectively you need to do a little nonlinear iteration on a group of dofs >> to determine c_{A,B,C}. One approach you could use is to use the >> PyOP2-level kernel iteration to express this, and use a direct loop over >> the dofs. >> >> This would look something like: >> >> void solve_system(double *c_A, double *c_B, double *c_C, double *k1, >> double *psi_A, double *psi_B) >> { >> >> // In here, you can dereference these variables to get the components >> // of each variable at the node, e.g. >> >> // Set first component of c_A to sum of first two components of psi_A. >> c_A[0] = psi_A[0] + psi_A[1]; >> } >> >> I guess you can either write the newton (or fixed point) iteration out by >> hand in the kernel (it shouldn't be too difficult), or else make library >> calls (getting the correct link lines is possible I think). >> >> Now in your code you do: >> >> solve_kernel = op2.Kernel(kernel_code, "solve_system") >> >> op2.par_loop(solve_kernel, >> c_A.dof_dset.node_set, >> c_A.dat(op2.WRITE), >> c_B.dat(op2.WRITE), >> c_C.dat(op2.WRITE), >> k1.dat(op2.READ), >> psi_A.dat(op2.READ), >> psi_B.dat(op2.READ)) >> >> >> Does this make sense? >> >> Lawrence >> > I could use scipy's fsolve to solve the above equations but I was >> wondering if there's an easy way to express and solve the above using the >> features of firedrake and/or its dependencies (e.g., petsc, petsc4py, etc). >> >> > -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

2 1

Re: [firedrake] The wonderful world of firedrake-install
by David Ham 04 Sep '15

04 Sep '15

It turns out that this is for the usual reason: I am an idiot. A fix for this is in the further-install-fixes branch and I will merge the branch as soon as tests pass. (What's actually going on is that I am abusing CalledProcessError when I should really raise a special exception for this case. I have now created a new exception and raised that instead). Cheers, David On Thu, 3 Sep 2015 at 01:56 Justin Chang <jychang48(a)gmail.com> wrote: > Thanks David, > > I actually forgot about the --no_package_manager option. But when I tried > installing with it, i get this error: > > $ python firedrake-install --no_package_manager > Traceback (most recent call last): > File "firedrake-install", line 265, in <module> > raise subprocess.CalledProcessError > TypeError: __init__() takes at least 3 arguments (1 given) > > Even if I add the --disable_ssh and --developer tags I get the above > error. Am I suppose to do something else with this? > > Thanks, > Justin > > On Tue, Sep 1, 2015 at 3:57 AM, David Ham <David.Ham(a)imperial.ac.uk> > wrote: > >> Thanks, >> >> On Sun, 30 Aug 2015 at 08:15 Justin Chang <jychang48(a)gmail.com> wrote: >> >>> I agree that hype and a sparse direct solver like mumps is necessary. >>> The latter needs --download-metis --download-parmetis >>> --download-scalapack. >>> >> >> Added and currently testing. >> >>> >>> More comments: >>> >>> 4) If mumps is to be included, the install script has to ensure that >>> one has cmake >=2.5 when configuring metis, otherwise PETSc configure >>> will return an error. Perhaps include "brew install cmake" and "sudo >>> apt-get install cmake" in the script? >>> >> >> Also added. Thanks for catching this. >> >>> >>> 5) Should --download-exodusii (and it's dependencies --download-netcdf >>> --download-hdf5) also be included in the PETSC_CONFIGURE_OPTIONS? I >>> imagine that if one wants to solve problems on large-scale >>> unstructured grids, .exo files would be more feasible to use over .msh >>> files. Or is exodusii already accounted for in firedrake/PyOP2/etc? >>> >> >> And this. >> >>> >>> 6) If I run the script on a pristine MacOSX, I get an error saying >>> "OSError: Unable to find SWIG installation. Please install SWIG >>> version 2.0.0 or higher." I am guessing "brew install swig" was >>> somehow missed in the firedrake-install script? >>> >> Ah yes. Fecking swig. I've added the dependency to the new branch. >> Hopefully the swig dependency is going away very soon. >> >> >>> >>> 7) Perhaps not as important, but do y'all think it's possible to make >>> this script more non-Ubuntu HPC system friendly? For isntance, either >>> a) require the user to install his or her own local OpenMPI and Python >>> libraries from source, b) let script download the tarballs/git >>> repositories remotely and install it for you (kind of like how PETSc >>> handles external packages through --download-<package>), or c) enable >>> the user to point to the system provided OpenMPI and Python libraries. >>> Same would need to be done for CMake, SWIG, and PCRE as these packages >>> cannot simply be obtained from pip. >>> >> >> I think (c) is the case right now. If you run the script on a non-Ubuntu >> system or pass the --no_package_manager option then it will just assume >> that you have installed the dependencies somewhere visible and will get on >> with pip. >> >> I think (b) is [a] hard and [b] in the case of MPI probably a bad idea. >> Supercomputers are such a diverse bunch of hacked up distributions that I >> think that installing the compiled dependencies automatically in a way >> which is portable would require a lot of install script work. In the case >> of MPI, you really need to use the MPI build which talks to the fast >> interconnect on your supercomputer, so automatically building vanilla >> OpenMPI is a Bad Thing. >> >> Cheers, >> >> David >> >> >> >>> >>> Thanks, >>> Justin >>> >>> On Fri, Aug 28, 2015 at 7:20 AM, Lawrence Mitchell >>> <lawrence.mitchell(a)imperial.ac.uk> wrote: >>> > >>> >> On 28 Aug 2015, at 14:01, David Ham <David.Ham(a)imperial.ac.uk> wrote: >>> >> >>> >> Hi All, >>> >> >>> >> I have a branch going through testing now which will handle >>> PETSC_CONFIGURE_OPTIONS in a smarter way. Basically we'll just make sure >>> that the things which are required are there, and we'll also honour >>> anything the user has already set. I've also updated docs to say that >>> that's what happens. >>> >> >>> >> I am also open to the suggestion that we could add more configuration >>> options to the default set. Would anyone like to suggest what they should >>> be? >>> > >>> > I think --download-hypre=1 at least. Maybe also a sparse direct >>> solver (mumps?) which I think needs --download-metis --download-parmetis >>> --download-mumps (maybe some others?) >>> > >>> > Lawrence >>> > >>> > >>> > _______________________________________________ >>> > firedrake mailing list >>> > firedrake(a)imperial.ac.uk >>> > https://mailman.ic.ac.uk/mailman/listinfo/firedrake >>> > >>> >>> _______________________________________________ >>> firedrake mailing list >>> firedrake(a)imperial.ac.uk >>> https://mailman.ic.ac.uk/mailman/listinfo/firedrake >>> >> >> _______________________________________________ >> firedrake mailing list >> firedrake(a)imperial.ac.uk >> https://mailman.ic.ac.uk/mailman/listinfo/firedrake >> >> >

2 2

Re: [firedrake] Solving this system of nonlinear equations
by Andrew McRae 03 Sep '15

03 Sep '15

Or, if you don't want to do Newton iterations <http://www.wolframalpha.com/input/?i=solve+x+%2B+z+%3D+a%2C+y+%2B+z+%3D+b%2…>... (it may well be the case the Newton iterations are faster, I don't know. But you do have two solutions, so be careful). This still assumes that everything lives in the same functionspace, of course. On 3 September 2015 at 12:29, Mitchell, Lawrence < lawrence.mitchell(a)imperial.ac.uk> wrote: > > > On 3 Sep 2015, at 01:20, Justin Chang <jychang48(a)gmail.com> wrote: > > > > Hi all, > > > > I need to solve the following system of chemical reaction equations: > > > > psi_A = c_A + c_C > > psi_B = c_B + c_C > > c_C = k1*c_A*c_B > > > > where psi_A, psi_B, and k1 are known. c_A, c_B, and c_C are the unknowns > I need to solve. > > > > k1 is a scalar and psi_A, psi_B, c_A, c_B, and c_C are vectors of size N. > > > > psi_A and psi_B have been obtained through advection-diffusion > equations. I need to "post-process" these solutions such that I get c_A, > c_B, and c_C. The above system of equations are on a node-to-node basis > (i.e., the reactions of node i are independent of node i+1). > > I assume that all the variables live in the same functionspace. So > effectively you need to do a little nonlinear iteration on a group of dofs > to determine c_{A,B,C}. One approach you could use is to use the > PyOP2-level kernel iteration to express this, and use a direct loop over > the dofs. > > This would look something like: > > void solve_system(double *c_A, double *c_B, double *c_C, double *k1, > double *psi_A, double *psi_B) > { > > // In here, you can dereference these variables to get the components > // of each variable at the node, e.g. > > // Set first component of c_A to sum of first two components of psi_A. > c_A[0] = psi_A[0] + psi_A[1]; > } > > I guess you can either write the newton (or fixed point) iteration out by > hand in the kernel (it shouldn't be too difficult), or else make library > calls (getting the correct link lines is possible I think). > > Now in your code you do: > > solve_kernel = op2.Kernel(kernel_code, "solve_system") > > op2.par_loop(solve_kernel, > c_A.dof_dset.node_set, > c_A.dat(op2.WRITE), > c_B.dat(op2.WRITE), > c_C.dat(op2.WRITE), > k1.dat(op2.READ), > psi_A.dat(op2.READ), > psi_B.dat(op2.READ)) > > > Does this make sense? > > Lawrence > > I could use scipy's fsolve to solve the above equations but I was > wondering if there's an easy way to express and solve the above using the > features of firedrake and/or its dependencies (e.g., petsc, petsc4py, etc). > >

1 0

Solving this system of nonlinear equations
by Justin Chang 03 Sep '15

03 Sep '15

Hi all, I need to solve the following system of chemical reaction equations: psi_A = c_A + c_C psi_B = c_B + c_C c_C = k1*c_A*c_B where psi_A, psi_B, and k1 are known. c_A, c_B, and c_C are the unknowns I need to solve. k1 is a scalar and psi_A, psi_B, c_A, c_B, and c_C are vectors of size N. psi_A and psi_B have been obtained through advection-diffusion equations. I need to "post-process" these solutions such that I get c_A, c_B, and c_C. The above system of equations are on a node-to-node basis (i.e., the reactions of node i are independent of node i+1). I could use scipy's fsolve to solve the above equations but I was wondering if there's an easy way to express and solve the above using the features of firedrake and/or its dependencies (e.g., petsc, petsc4py, etc). Thanks, Justin

2 1

Re: [firedrake] The wonderful world of firedrake-install
by David Ham 03 Sep '15

03 Sep '15

Thanks, On Sun, 30 Aug 2015 at 08:15 Justin Chang <jychang48(a)gmail.com> wrote: > I agree that hype and a sparse direct solver like mumps is necessary. > The latter needs --download-metis --download-parmetis > --download-scalapack. > Added and currently testing. > > More comments: > > 4) If mumps is to be included, the install script has to ensure that > one has cmake >=2.5 when configuring metis, otherwise PETSc configure > will return an error. Perhaps include "brew install cmake" and "sudo > apt-get install cmake" in the script? > Also added. Thanks for catching this. > > 5) Should --download-exodusii (and it's dependencies --download-netcdf > --download-hdf5) also be included in the PETSC_CONFIGURE_OPTIONS? I > imagine that if one wants to solve problems on large-scale > unstructured grids, .exo files would be more feasible to use over .msh > files. Or is exodusii already accounted for in firedrake/PyOP2/etc? > And this. > > 6) If I run the script on a pristine MacOSX, I get an error saying > "OSError: Unable to find SWIG installation. Please install SWIG > version 2.0.0 or higher." I am guessing "brew install swig" was > somehow missed in the firedrake-install script? > Ah yes. Fecking swig. I've added the dependency to the new branch. Hopefully the swig dependency is going away very soon. > > 7) Perhaps not as important, but do y'all think it's possible to make > this script more non-Ubuntu HPC system friendly? For isntance, either > a) require the user to install his or her own local OpenMPI and Python > libraries from source, b) let script download the tarballs/git > repositories remotely and install it for you (kind of like how PETSc > handles external packages through --download-<package>), or c) enable > the user to point to the system provided OpenMPI and Python libraries. > Same would need to be done for CMake, SWIG, and PCRE as these packages > cannot simply be obtained from pip. > I think (c) is the case right now. If you run the script on a non-Ubuntu system or pass the --no_package_manager option then it will just assume that you have installed the dependencies somewhere visible and will get on with pip. I think (b) is [a] hard and [b] in the case of MPI probably a bad idea. Supercomputers are such a diverse bunch of hacked up distributions that I think that installing the compiled dependencies automatically in a way which is portable would require a lot of install script work. In the case of MPI, you really need to use the MPI build which talks to the fast interconnect on your supercomputer, so automatically building vanilla OpenMPI is a Bad Thing. Cheers, David > > Thanks, > Justin > > On Fri, Aug 28, 2015 at 7:20 AM, Lawrence Mitchell > <lawrence.mitchell(a)imperial.ac.uk> wrote: > > > >> On 28 Aug 2015, at 14:01, David Ham <David.Ham(a)imperial.ac.uk> wrote: > >> > >> Hi All, > >> > >> I have a branch going through testing now which will handle > PETSC_CONFIGURE_OPTIONS in a smarter way. Basically we'll just make sure > that the things which are required are there, and we'll also honour > anything the user has already set. I've also updated docs to say that > that's what happens. > >> > >> I am also open to the suggestion that we could add more configuration > options to the default set. Would anyone like to suggest what they should > be? > > > > I think --download-hypre=1 at least. Maybe also a sparse direct solver > (mumps?) which I think needs --download-metis --download-parmetis > --download-mumps (maybe some others?) > > > > Lawrence > > > > > > _______________________________________________ > > firedrake mailing list > > firedrake(a)imperial.ac.uk > > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > > > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake >

2 1

Computational scientist positions at ECMWF: research into exascale (closing 15 Sep)
by Florian Rathgeber 02 Sep '15

02 Sep '15

[Apologies for cross-posting, I hope these positions are of interest] ECMWF has 2 exascale research openings [1] for computational scientists, which are part of the NextGenIO H2020 EU project. One role will involve developing a new I/O software layer capable of harnessing the NVRAM technology developed within NextGenIO to integrate it with the ECMWF model (IFS) via an I/O server infrastructure. The other role will require the successful candidate to develop a model of ECMWF’s compute and I/O workflow. He or she will use this model to develop a scalable software suite that can simulate the daily workflow of an HPC facility, to be used as a more comprehensive benchmark and procurement tool. Further details at http://www.ecmwf.int/en/about/jobs/jobs-ecmwf. Best wishes, Florian [1] http://www.ecmwf.int/sites/default/files/vacancies/_VNVN15-46_en.pdf

1 0

Re: [firedrake] Few questions
by David Ham 01 Sep '15

01 Sep '15

On Tue, 1 Sep 2015 at 09:09 Justin Chang <jychang48(a)gmail.com> wrote: > Hi Lawrence, > > Ah yes I meant to say pass in SNESVISetVariableBounds > <http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/SNES/SNESVISetVaria…> > if that's what you're patch handles. I will try this out. > > And thanks Andrew for your help. I ended up porting the undocumented SUPG > advection-diffusion FEniCS example to Firedrake. > > If you feel like documenting it, we'd love to have it on the Firedrake website ;). > One more question: > > 4 I also want to work with a tensor diffusion coefficient. In FEniCS I > could normally do something like > > D = as_matrix([[1.0],[0,1]]) > > but i specifically want tensorial dispersion from velocity. E.g., > > D = alpha_t*norm(velocity)*Identity + (alpha_L-alpha_t)*outer(v,v)/norm(v) > > Where alpha_t and alpha_L are the transverse and longitudinal dispersivity > respectively (ignoring molecular diffusion for the moment). How would do I > express this D matrix? > > Thanks, > Justin > > On Tue, Sep 1, 2015 at 1:39 AM, Lawrence Mitchell < > lawrence.mitchell(a)imperial.ac.uk> wrote: > >> >> > On 31 Aug 2015, at 22:31, Justin Chang <jychang48(a)gmail.com> wrote: >> > >> > Hi all, >> > >> > 2) I want to play around with PETSc's Variational Inequality solver. In >> my own PETSc code all I had to do was provide a Jacobian matrix, a residual >> vector, pass in the options -snes_type vinewtonssls (or it might be >> vinewotnrsls), and pass in SNESVINEWTONSSLS . From my last discussion with >> some PETSc folks it seems this VI feature is relatively now, so I was >> wondering if that last item can be invoked through the version of petsc4py >> you guys are using? >> >> >> If it's just as simple as passing -snes_type vinewtonssls, then I think >> you're good to go. But presumably you also need to provide the SNES with >> the variable bounds. I think the DOLFIN interface for this (which we >> should mimic) is to do: >> >> solver = NLVSolver(...) >> >> solver.solve(lower_bound, upper_bound) >> >> where you provide Functions in the solution space defining your variable >> bounds (and can omit one or the other if you don't have a bound in that >> direction). >> >> The SNES solver needs to be informed of these, so if they're provided one >> must do: >> >> solver.snes.setVariableBounds(lb, ub) >> >> >> Here's a sketch patch (untested): >> >> Use it like: >> >> solver = ... >> >> lb = Function(V) >> lb.assign(-10) >> >> # Ensure solution is bounded below by -10. >> solver.solve(lb=lb) >> >> >> diff --git a/firedrake/variational_solver.py >> b/firedrake/variational_solver.py >> index ec47ce7..342c3e9 100644 >> --- a/firedrake/variational_solver.py >> +++ b/firedrake/variational_solver.py >> @@ -155,7 +155,18 @@ class NonlinearVariationalSolver(object): >> >> @timed_function("SNES solver execution") >> @profile >> - def solve(self): >> + def solve(self, lb=None, ub=None): >> + """Solve the variational problem. >> + >> + You can provide optional lower and upper bounds on the >> + solution vector if using PETSc's variational inequality >> + solvers. >> + >> + :arg lb: An optional lower bound on the solution vector. If >> + not provided, use -inf. >> + :arg ub: An optional upper bound on the solution vector. If >> + not provided, use +inf. >> + """ >> dm = self.snes.getDM() >> dm.setAppCtx(weakref.proxy(self._ctx)) >> dm.setCreateMatrix(self._ctx.create_matrix) >> @@ -168,6 +179,20 @@ class NonlinearVariationalSolver(object): >> # solve, ensure these are passed through to the snes. >> solving_utils.update_parameters(self, self.snes) >> >> + if lb is not None or ub is not None: >> + if ub: >> + with ub.dat.vec_ro as v: >> + ub_vec = v >> + else: >> + ub_vec = dm.createGlobalVector() >> + ub_vec.set(PETSc.INFINITY) >> + if lb: >> + with lb.dat.vec_ro as v: >> + lb_vec = v >> + else: >> + lb_vec = dm.createGlobalVector() >> + lb_vec.set(PETSc.NINFINITY) >> + self.snes.setVariableBounds(lb_vec, ub_vec) >> with self._problem.u.dat.vec as v: >> self.snes.solve(None, v) >> >> >> >> >> >> _______________________________________________ >> firedrake mailing list >> firedrake(a)imperial.ac.uk >> https://mailman.ic.ac.uk/mailman/listinfo/firedrake >> >> >

1 0

Few questions
by Justin Chang 01 Sep '15

01 Sep '15

Hi all, 1) How do I define a volumetric source/sink for a specific region? For example, if I am solving a diffusion equation with homogeneous BCs and have a volumetric source f(x,y) such that if (x[0] >= 0.25 && x[0] <= 0.30 && x[1] >= 0.25 && x[1] <= 0.30): f == 1 else: f == 0 2) I want to play around with PETSc's Variational Inequality <http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/SNES/SNESVINEWTONSS…> solver. In my own PETSc code all I had to do was provide a Jacobian matrix, a residual vector, pass in the options -snes_type vinewtonssls (or it might be vinewotnrsls), and pass in SNESVINEWTONSSLS <http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/SNES/SNESVINEWTONSS…> . >From my last discussion with some PETSc folks it seems this VI feature is relatively now, so I was wondering if that last item can be invoked through the version of petsc4py you guys are using? 3) Is it possible to employ the SUPG formulation for advection-diffusion problems in firedrake? Thanks, Justin

2 3