- firedrake - imperial.ac.uk

Using matplotlib to plot 1d solution
by William Booker 15 Sep '16

15 Sep '16

Hi Firedrakers, I've been trying to follow the Camassa Holm example to use matplotlib, but I get the following error: firedrake:WARNING Cannot plot figure. Error msg: 'Unsupported Functionality' Is it because of the DG space or have I missed something else? Thanks Will

2 1

(no subject)
by William Booker 15 Sep '16

15 Sep '16

Hi firedrakers, I had this script working on an older version of firedrake (24th Aug), but when I updated today I now get the following error when I try to run it: Traceback (most recent call last): File "compressible_stratified.py", line 77, in <module> solve ( a_u_project == L_u_project , dHdu0 , solver_parameters={'ksp_rtol': 1e-14} ) File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/firedrake/solving.py", line 119, in solve _solve_varproblem(*args, **kwargs) File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/firedrake/solving.py", line 147, in _solve_varproblem solver.solve() File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/firedrake/variational_solver.py", line 198, in solve self.snes.solve(None, v) File "PETSc/SNES.pyx", line 537, in petsc4py.PETSc.SNES.solve (src/petsc4py.PETSc.c:170168) File "PETSc/petscsnes.pxi", line 261, in petsc4py.PETSc.SNES_Function (src/petsc4py.PETSc.c:33322) File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", line 216, in form_function form_compiler_parameters=problem.form_compiler_parameters) File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", line 81, in assemble inverse=inverse, mat_type=mat_type, appctx=appctx) File "<decorator-gen-295>", line 2, in _assemble File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/firedrake/utils.py", line 62, in wrapper return f(*args, **kwargs) File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", line 444, in _assemble return thunk(bcs) File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/firedrake/assembly_cache.py", line 357, in inner r = thunk(bcs) File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", line 394, in thunk op2.par_loop(*args, **kwargs) File "<decorator-gen-269>", line 2, in par_loop File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/pyop2/versioning.py", line 154, in modifies_arguments retval = func(*args, **kwargs) File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/pyop2/op2.py", line 269, in par_loop return backends._BackendSelector._backend.par_loop(kernel, iterset, *args, **kwargs) File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/pyop2/base.py", line 4369, in par_loop return _make_object('ParLoop', kernel, it_space, *args, **kwargs).enqueue() File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/pyop2/backends.py", line 72, in _make_object return _BackendSelector._backend.__dict__[obj](*args, **kwargs) File "<decorator-gen-262>", line 2, in __init__ File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/pyop2/utils.py", line 130, in wrapper return f(*args, **kwargs) File "/usr/not-backed-up/firedrake/2016-09-15/firedrake/lib/python2.7/site-packages/pyop2/base.py", line 3999, in __init__ fundecl = kernel._attached_info['fundecl'] TypeError: 'bool' object has no attribute '__getitem__' What needs to be changed to get it to compile again? Thanks Will

2 2

Re: [firedrake] Mixed system
by Andrew McRae 14 Sep '16

14 Sep '16

Probably related to installing Firedrake in development mode or not. I can't help any further here; I don't know if someone else can. On 14 September 2016 at 16:13, Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> wrote: > Ok, so I replace line 3366 in file “/Users/matak/firedrake/lib/ > python2.7/site-packages/pyop2/base.py” with the suggested patch, but I > now get the error below. > > Note that the error I get comes from file firedrake/lib/python2.7/ > site-packages/pyop2/base.py > while in the reported issue the error comes from firedrake/src/PyOP2/ > pyop2/base.py > so the two might not be related after all. > > Thanks, > Anna. > > > Traceback (most recent call last): > File "buoy-swe.py", line 89, in <module> > F_solver = solver_F(phi0_5, eta1, mu0_5, I, w, phi0, eta0, Z0, W0, > step_b, etaR, phi_t, eta_t, mu_t, I_t, v1, v2, v3, v4, dt, Hb, H0, L, > dR_dt, g, rho, Mass, solvers_print); > File "/Users/matak/Documents/Simulations/Firedrake/Ship/Modules/Mixed > system/solvers.py", line 41, in solver_F > F_solver = LinearVariationalSolver(F_problem, > solver_parameters=solvers_print) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ > firedrake/variational_solver.py", line 264, in __init__ > super(LinearVariationalSolver, self).__init__(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ > firedrake/variational_solver.py", line 127, in __init__ > ctx = solving_utils._SNESContext(problem) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", > line 107, in __init__ > for problem in problems) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", > line 107, in <genexpr> > for problem in problems) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", > line 67, in assemble > inverse=inverse, nest=nest) > File "<decorator-gen-294>", line 2, in _assemble > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/utils.py", > line 62, in wrapper > return f(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", > line 179, in _assemble > nest=nest) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/backends.py", > line 118, in __call__ > return t(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", > line 122, in __new__ > args, kwargs = cls._process_args(*args, **kwargs) > File "<decorator-gen-258>", line 2, in _process_args > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/utils.py", > line 130, in wrapper > return f(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", > line 3592, in _process_args > if not (pair[0].toset == dsets[0].set and > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/utils.py", > line 64, in __get__ > obj.__dict__[self.__name__] = result = self.fget(obj) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", > line 3373, in toset > m.toset for m in self._maps)) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", > line 156, in __new__ > obj = make_obj() > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", > line 137, in make_obj > obj.__init__(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", > line 977, in __init__ > "All components of a MixedSet must have the same number of layers." > AssertionError: All components of a MixedSet must have the same number of > layers. > > ********************************************************** > Dr Anna Kalogirou > Research Fellow > Department of Applied Mathematics > University of Leeds > > Web: http://www1.maths.leeds.ac.uk/~matak/ > Youtube: https://www.youtube.com/channel/UCUZAYHtVoiMqepQflisp66g > > ********************************************************** > Leverhulme Trust Early Career Fellow 2017-2019 > > ********************************************************** > > > > On 14 Sep 2016, at 16:00, Andrew McRae <A.T.T.McRae(a)bath.ac.uk> wrote: > > Not as a branch, but you can change PyOP2 locally using the code at the > bottom of that post, "Suggested patch" > > On 14 September 2016 at 15:54, Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> > wrote: > >> Hi Andrew, >> >> Yes indeed, the two might be related. Was there a fix for the issue >> reported on github? >> >> Best, Anna. >> >> >> ********************************************************** >> Dr Anna Kalogirou >> Research Fellow >> Department of Applied Mathematics >> University of Leeds >> >> Web: http://www1.maths.leeds.ac.uk/~matak/ >> Youtube: https://www.youtube.com/channel/UCUZAYHtVoiMqepQflisp66g >> >> ********************************************************** >> Leverhulme Trust Early Career Fellow 2017-2019 >> >> ********************************************************** >> >> >> >> On 13 Sep 2016, at 16:34, Andrew McRae <A.T.T.McRae(a)bath.ac.uk> wrote: >> >> Probably related to https://github.com/firedrakepr >> oject/firedrake/issues/862 (third post, not first). You might be able >> to adapt the fix; I haven't looked in detail. >> >> On 12 September 2016 at 16:34, Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> >> wrote: >> >>> Dear all, >>> >>> Regarding the problem described in my email sent of Friday, I fixed a >>> minor typo and now get the error below. Any ideas what might be causing it? >>> Thanks! >>> >>> Best, Anna. >>> >>> Traceback (most recent call last): >>> File "buoy-swe.py", line 89, in <module> >>> F_solver = solver_F(phi0_5, eta1, mu0_5, I, w, phi0, eta0, Z0, W0, >>> step_b, etaR, phi_t, eta_t, mu_t, I_t, v1, v2, v3, v4, dt, Hb, H0, L, >>> dR_dt, g, rho, Mass, solvers_print); >>> File "/Users/matak/Documents/Simulations/Firedrake/Ship/Modules/Mixed >>> system/solvers.py", line 41, in solver_F >>> F_solver = LinearVariationalSolver(F_problem, >>> solver_parameters=solvers_print) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/variational_solver.py", >>> line 264, in __init__ >>> super(LinearVariationalSolver, self).__init__(*args, **kwargs) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/variational_solver.py", >>> line 127, in __init__ >>> ctx = solving_utils._SNESContext(problem) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", >>> line 107, in __init__ >>> for problem in problems) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", >>> line 107, in <genexpr> >>> for problem in problems) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", >>> line 67, in assemble >>> inverse=inverse, nest=nest) >>> File "<decorator-gen-294>", line 2, in _assemble >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/utils.py", >>> line 62, in wrapper >>> return f(*args, **kwargs) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", >>> line 163, in _assemble >>> map_pairs.append((op2.DecoratedMap(test.cell_node_map(), >>> cell_domains), >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/functionspaceimpl.py", >>> line 646, in cell_node_map >>> for i, s in enumerate(self._spaces)) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/backends.py", >>> line 118, in __call__ >>> return t(*args, **kwargs) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", >>> line 156, in __new__ >>> obj = make_obj() >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", >>> line 137, in make_obj >>> obj.__init__(*args, **kwargs) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", >>> line 3342, in __init__ >>> if not all(m is None or m.iterset == self.iterset for m in >>> self._maps): >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", >>> line 3342, in <genexpr> >>> if not all(m is None or m.iterset == self.iterset for m in >>> self._maps): >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/utils.py", >>> line 64, in __get__ >>> obj.__dict__[self.__name__] = result = self.fget(obj) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", >>> line 3366, in iterset >>> return reduce(lambda a, b: a if a is None else a.iterset or b if b >>> is None else b.iterset, self._maps) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", >>> line 3366, in <lambda> >>> return reduce(lambda a, b: a if a is None else a.iterset or b if b >>> is None else b.iterset, self._maps) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", >>> line 799, in __getattr__ >>> return getattr(self._parent, name) >>> AttributeError: 'Set' object has no attribute ‘iterset' >>> >>> >>> ********************************************************** >>> Dr Anna Kalogirou >>> Research Fellow >>> Department of Applied Mathematics >>> University of Leeds >>> >>> Web: http://www1.maths.leeds.ac.uk/~matak/ >>> Youtube: https://www.youtube.com/channel/UCUZAYHtVoiMqepQflisp66g >>> >>> ********************************************************** >>> Leverhulme Trust Early Career Fellow 2017-2019 >>> >>> ********************************************************** >>> >>> >>> >>> On 9 Sep 2016, at 17:37, Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> wrote: >>> >>> Hi David, >>> >>> I have tried to implement my problem (attached) using the real function >>> spaces but I get the error below. The code can be found here >>> <https://bitbucket.org/annakalog/buoy2d/src/d6a805b6a8d0/Mixed%20system/?at=…> >>> . >>> >>> I define the real space by V_R = FunctionSpace(mesh, "R", 0). Is that >>> correct? >>> Also, is it a problem that the linear part of the variational form does >>> not depend on one of the test functions from the mixed function space (only >>> depends on v1, v2, v3 and not v4)? >>> >>> Best, >>> >>> Anna. >>> >>> >>> >>> Traceback (most recent call last): >>> File "buoy-swe.py", line 89, in <module> >>> F_solver = solver_F(phi0_5, eta1, mu0_5, I, w, phi0, eta0, Z0, W0, >>> step_b, etaR, phi_t, eta_t, mu_t, I_t, v1, v2, v3, v4, dt, Hb, H0, L, >>> dR_dt, g, rho, Mass, solvers_print); >>> File "/Users/matak/Documents/Simulations/Firedrake/Ship/Modules/Mixed >>> system/solvers.py", line 41, in solver_F >>> F_solver = LinearVariationalSolver(F_problem, >>> solver_parameters=solvers_print) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/variational_solver.py", >>> line 264, in __init__ >>> super(LinearVariationalSolver, self).__init__(*args, **kwargs) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/variational_solver.py", >>> line 127, in __init__ >>> ctx = solving_utils._SNESContext(problem) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", >>> line 107, in __init__ >>> for problem in problems) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", >>> line 107, in <genexpr> >>> for problem in problems) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", >>> line 67, in assemble >>> inverse=inverse, nest=nest) >>> File "<decorator-gen-294>", line 2, in _assemble >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/utils.py", >>> line 62, in wrapper >>> return f(*args, **kwargs) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", >>> line 101, in _assemble >>> inverse=inverse) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/tsfc_interface.py", >>> line 307, in compile_form >>> number_map).kernels >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", >>> line 198, in __new__ >>> obj = make_obj() >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", >>> line 188, in make_obj >>> obj.__init__(*args, **kwargs) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/tsfc_interface.py", >>> line 212, in __init__ >>> tree = tsfc_compile_form(form, prefix=name, parameters=parameters) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/tsfc/driver.py", >>> line 47, in compile_form >>> do_estimate_degrees=True) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/compute_form_data.py", >>> line 386, in compute_form_data >>> check_form_arity(preprocessed_form, self.original_form.arguments()) >>> # Currently testing how fast this is >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/check_arities.py", >>> line 152, in check_form_arity >>> check_integrand_arity(itg.integrand(), arguments) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/check_arities.py", >>> line 145, in check_integrand_arity >>> args = map_expr_dag(rules, expr, compress=False) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/corealg/map_dag.py", >>> line 37, in map_expr_dag >>> result, = map_expr_dags(function, [expression], compress=compress) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/corealg/map_dag.py", >>> line 86, in map_expr_dags >>> r = handlers[v._ufl_typecode_](v, *[vcache[u] for u in >>> v.ufl_operands]) >>> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/check_arities.py", >>> line 42, in sum >>> raise ArityMismatch("Adding expressions with non-matching form >>> arguments {0} vs {1}.".format(a, b)) >>> ufl.algorithms.check_arities.ArityMismatch: Adding expressions with >>> non-matching form arguments () vs (Argument(WithGeometry(Indexed >>> ProxyFunctionSpace(<firedrake.mesh.ExtrudedMeshTopology object at >>> 0x113e6b890>, TensorProductElement(FiniteElement('Lagrange', interval, >>> 1), FiniteElement('Lagrange', interval, 1), cell=TensorProductCell(interval, >>> interval)), name=None, index=0, component=None), >>> Mesh(VectorElement(TensorProductElement(FiniteElement('Lagrange', >>> interval, 1), FiniteElement('Lagrange', interval, 1), >>> cell=TensorProductCell(interval, interval)), dim=2), 4)), 1, None),). >>> <coupled_system.pdf> >>> >>> On 18 Aug 2016, at 16:03, David Ham <david.ham(a)imperial.ac.uk> wrote: >>> >>> Hi Anna, >>> >>> Real function spaces now pass some simple tests, at least on my machine. >>> You need the real-function-space branch of firedrake, and the >>> globals_matrices branch of PyOP2. It's not going to get merged before I >>> disappear for a week - not least because I need to update documentation. >>> However you should be able to test it out on the branches. >>> >>> Regards, >>> >>> David >>> >>> On Wed, 10 Aug 2016 at 16:58 David Ham <David.Ham(a)imperial.ac.uk> wrote: >>> >>>> Unfortunately, It isn't as simple as saying "no mpi". MPI pervades >>>> Firedrake. Unless real function spaces play nicely with communicators, >>>> Firedrake will simply crash. I'm sorry that this feature is not available >>>> right now, but it actually does require significant work. >>>> >>>> On Wed, 10 Aug 2016 at 16:51 Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> >>>> wrote: >>>> >>>>> Yes indeed, but I believe David would want to make it work for all >>>>> cases. The merge is necessary in order to proceed with my simulations, so >>>>> an update as soon as possible would be greatly appreciated. >>>>> >>>>> Best, Anna. >>>>> >>>>> >>>>> On 10 Aug 2016, at 16:29, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>>>> >>>>> We would already be helped for the case without MPI, I think that is >>>>> correct, Anna? >>>>> >>>>> >>>>> *From:* firedrake-bounces(a)imperial.ac.uk < >>>>> firedrake-bounces(a)imperial.ac.uk> on behalf of David Ham < >>>>> David.Ham(a)imperial.ac.uk> >>>>> >>>>> *Sent:* Wednesday, August 10, 2016 10:01 AM >>>>> >>>>> >>>>> *To:* firedrake >>>>> *Subject:* Re: [firedrake] Mixed system >>>>> >>>>> The short version is it depends on when I find some time to work on >>>>> it. It is not simply the case that we have new features lying around >>>>> waiting to be merged. The current proximate issue is to make the real >>>>> spaces work properly with MPI communicators. I can't guarantee that will be >>>>> the last issue. >>>>> >>>>> >>>>> On Tue, 9 Aug 2016 at 17:37 Onno Bokhove <O.Bokhove(a)leeds.ac.uk> >>>>> wrote: >>>>> >>>>>> It is possible to merge the branch for the mixed system >>>>>> relatively soon? >>>>>> Anna's results are relevant for the grant application Colin and I aim >>>>>> to submit in Sept. on further wave-ship modelling. >>>>>> Sorry for asking! >>>>>> ------------------------------ >>>>>> *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces@im >>>>>> perial.ac.uk> on behalf of David Ham <David.Ham(a)imperial.ac.uk> >>>>>> *Sent:* Friday, August 5, 2016 11:37:23 AM >>>>>> *To:* firedrake >>>>>> *Subject:* Re: [firedrake] Mixed system >>>>>> >>>>>> >>>>>> >>>>>> On Fri, 5 Aug 2016 at 11:31 Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> >>>>>> wrote: >>>>>> >>>>>>> Hi Kramer, >>>>>>> >>>>>>> Thank you for the reply. >>>>>>> >>>>>>> The only problem I see with the solution you suggest, is that both I >>>>>>> and >>>>>>> lambda will be trial functions, so both terms should be on the >>>>>>> bilinear >>>>>>> part of the variational form. >>>>>>> >>>>>> >>>>>> Not quite. I and lambda together form a Function in a mixed finite >>>>>> element space. You solve for both of them together, just like pressure and >>>>>> velocity in a fluid simulation. >>>>>> >>>>>> >>>>>>> >>>>>>> I could, of course, define a residual and solve everything using >>>>>>> nonlinear solvers, but I don't know how efficient that would be. >>>>>>> >>>>>> >>>>>> I think you are confused. None of the relevant issues change in the >>>>>> nonlinear case. After all, the nonlinear solver will differentiate the >>>>>> residual to create a bilinear form anyway. >>>>>> >>>>>> Incidentally, there is no particular reason to believe that writing >>>>>> the problem in nonlinear form would be inefficient. >>>>>> >>>>>> Regards, >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Anna. >>>>>>> >>>>>>> Dr Anna Kalogirou >>>>>>> Research Fellow >>>>>>> School of Mathematics >>>>>>> University of Leeds >>>>>>> >>>>>>> http://www1.maths.leeds.ac.uk/~matak/ >>>>>>> >>>>>>> On 04/08/16 17:29, Stephan Kramer wrote: >>>>>>> > On 27/07/16 11:01, Anna Kalogirou wrote: >>>>>>> >> Dear all, >>>>>>> >> >>>>>>> >> I am trying to solve the system found in the attached pdf as a >>>>>>> mixed >>>>>>> >> system. I want to solve the same >>>>>>> >> problem as the one found here >>>>>>> >> <https://bitbucket.org/annakalog/buoy2d/src/14334d3c20b9f10e >>>>>>> d7c1246cde9e3cb60b1c75e4/Inequality%20constraint/?at=master>, >>>>>>> >> >>>>>>> >> but with the use of Schur complements and not linear algebra. >>>>>>> >> >>>>>>> >> In a previous discussion about this problem, Lawrence mentioned >>>>>>> that the >>>>>>> >> test function for integral(lambda*Theta(x-Lp)dx) needs to be >>>>>>> considered >>>>>>> >> as coming from the real space of constant functions. Could you >>>>>>> please >>>>>>> >> elaborate on this? >>>>>>> > >>>>>>> > My guess at what Lawrence means is (it's how I would probably >>>>>>> approach >>>>>>> > it), is that you add an additional equation that says >>>>>>> > >>>>>>> > (1) I = integral(lambda*Theta(x-Lp)dx) >>>>>>> > >>>>>>> > and then substitute I in your third equation. Equation (1) can >>>>>>> > be turned into a finite element weak formulation by considering the >>>>>>> > function space of functions that are constant over the entire >>>>>>> domain >>>>>>> > This function space is just 1-dimensional and therefore equivalent >>>>>>> to >>>>>>> > the space of reals R and hence we denote this function space of >>>>>>> > constants simply as R. Then we can consider I to be a trial >>>>>>> function >>>>>>> > in R, and with a test function v4 in R, we can write: >>>>>>> > >>>>>>> > v4*lambda*Theta(x-Lp)*dx == v4*I*dx/area(domain) >>>>>>> > >>>>>>> > This is a proper finite element equation that you could solve in >>>>>>> > conjuction with the other equations. I believe however that this >>>>>>> > function space R is not currently implemented in Firedrake. It is >>>>>>> > available in fenics, and is on the wishlist. >>>>>>> > >>>>>>> > Cheers >>>>>>> > Stephan >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > 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 >>> >>> >>> _______________________________________________ >>> 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] Mixed system
by Andrew McRae 14 Sep '16

14 Sep '16

Not as a branch, but you can change PyOP2 locally using the code at the bottom of that post, "Suggested patch" On 14 September 2016 at 15:54, Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> wrote: > Hi Andrew, > > Yes indeed, the two might be related. Was there a fix for the issue > reported on github? > > Best, Anna. > > > ********************************************************** > Dr Anna Kalogirou > Research Fellow > Department of Applied Mathematics > University of Leeds > > Web: http://www1.maths.leeds.ac.uk/~matak/ > Youtube: https://www.youtube.com/channel/UCUZAYHtVoiMqepQflisp66g > > ********************************************************** > Leverhulme Trust Early Career Fellow 2017-2019 > > ********************************************************** > > > > On 13 Sep 2016, at 16:34, Andrew McRae <A.T.T.McRae(a)bath.ac.uk> wrote: > > Probably related to https://github.com/firedrakepr > oject/firedrake/issues/862 (third post, not first). You might be able to > adapt the fix; I haven't looked in detail. > > On 12 September 2016 at 16:34, Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> > wrote: > >> Dear all, >> >> Regarding the problem described in my email sent of Friday, I fixed a >> minor typo and now get the error below. Any ideas what might be causing it? >> Thanks! >> >> Best, Anna. >> >> Traceback (most recent call last): >> File "buoy-swe.py", line 89, in <module> >> F_solver = solver_F(phi0_5, eta1, mu0_5, I, w, phi0, eta0, Z0, W0, >> step_b, etaR, phi_t, eta_t, mu_t, I_t, v1, v2, v3, v4, dt, Hb, H0, L, >> dR_dt, g, rho, Mass, solvers_print); >> File "/Users/matak/Documents/Simulations/Firedrake/Ship/Modules/Mixed >> system/solvers.py", line 41, in solver_F >> F_solver = LinearVariationalSolver(F_problem, >> solver_parameters=solvers_print) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/variational_solver.py", >> line 264, in __init__ >> super(LinearVariationalSolver, self).__init__(*args, **kwargs) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/variational_solver.py", >> line 127, in __init__ >> ctx = solving_utils._SNESContext(problem) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", >> line 107, in __init__ >> for problem in problems) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", >> line 107, in <genexpr> >> for problem in problems) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", >> line 67, in assemble >> inverse=inverse, nest=nest) >> File "<decorator-gen-294>", line 2, in _assemble >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/utils.py", >> line 62, in wrapper >> return f(*args, **kwargs) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", >> line 163, in _assemble >> map_pairs.append((op2.DecoratedMap(test.cell_node_map(), >> cell_domains), >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/functionspaceimpl.py", >> line 646, in cell_node_map >> for i, s in enumerate(self._spaces)) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/backends.py", >> line 118, in __call__ >> return t(*args, **kwargs) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", >> line 156, in __new__ >> obj = make_obj() >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", >> line 137, in make_obj >> obj.__init__(*args, **kwargs) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", >> line 3342, in __init__ >> if not all(m is None or m.iterset == self.iterset for m in >> self._maps): >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", >> line 3342, in <genexpr> >> if not all(m is None or m.iterset == self.iterset for m in >> self._maps): >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/utils.py", >> line 64, in __get__ >> obj.__dict__[self.__name__] = result = self.fget(obj) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", >> line 3366, in iterset >> return reduce(lambda a, b: a if a is None else a.iterset or b if b is >> None else b.iterset, self._maps) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", >> line 3366, in <lambda> >> return reduce(lambda a, b: a if a is None else a.iterset or b if b is >> None else b.iterset, self._maps) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", >> line 799, in __getattr__ >> return getattr(self._parent, name) >> AttributeError: 'Set' object has no attribute ‘iterset' >> >> >> ********************************************************** >> Dr Anna Kalogirou >> Research Fellow >> Department of Applied Mathematics >> University of Leeds >> >> Web: http://www1.maths.leeds.ac.uk/~matak/ >> Youtube: https://www.youtube.com/channel/UCUZAYHtVoiMqepQflisp66g >> >> ********************************************************** >> Leverhulme Trust Early Career Fellow 2017-2019 >> >> ********************************************************** >> >> >> >> On 9 Sep 2016, at 17:37, Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> wrote: >> >> Hi David, >> >> I have tried to implement my problem (attached) using the real function >> spaces but I get the error below. The code can be found here >> <https://bitbucket.org/annakalog/buoy2d/src/d6a805b6a8d0/Mixed%20system/?at=…> >> . >> >> I define the real space by V_R = FunctionSpace(mesh, "R", 0). Is that >> correct? >> Also, is it a problem that the linear part of the variational form does >> not depend on one of the test functions from the mixed function space (only >> depends on v1, v2, v3 and not v4)? >> >> Best, >> >> Anna. >> >> >> >> Traceback (most recent call last): >> File "buoy-swe.py", line 89, in <module> >> F_solver = solver_F(phi0_5, eta1, mu0_5, I, w, phi0, eta0, Z0, W0, >> step_b, etaR, phi_t, eta_t, mu_t, I_t, v1, v2, v3, v4, dt, Hb, H0, L, >> dR_dt, g, rho, Mass, solvers_print); >> File "/Users/matak/Documents/Simulations/Firedrake/Ship/Modules/Mixed >> system/solvers.py", line 41, in solver_F >> F_solver = LinearVariationalSolver(F_problem, >> solver_parameters=solvers_print) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/variational_solver.py", >> line 264, in __init__ >> super(LinearVariationalSolver, self).__init__(*args, **kwargs) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/variational_solver.py", >> line 127, in __init__ >> ctx = solving_utils._SNESContext(problem) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", >> line 107, in __init__ >> for problem in problems) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", >> line 107, in <genexpr> >> for problem in problems) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", >> line 67, in assemble >> inverse=inverse, nest=nest) >> File "<decorator-gen-294>", line 2, in _assemble >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/utils.py", >> line 62, in wrapper >> return f(*args, **kwargs) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", >> line 101, in _assemble >> inverse=inverse) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/tsfc_interface.py", >> line 307, in compile_form >> number_map).kernels >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", >> line 198, in __new__ >> obj = make_obj() >> File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", >> line 188, in make_obj >> obj.__init__(*args, **kwargs) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/tsfc_interface.py", >> line 212, in __init__ >> tree = tsfc_compile_form(form, prefix=name, parameters=parameters) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/tsfc/driver.py", >> line 47, in compile_form >> do_estimate_degrees=True) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/compute_form_data.py", >> line 386, in compute_form_data >> check_form_arity(preprocessed_form, self.original_form.arguments()) >> # Currently testing how fast this is >> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/check_arities.py", >> line 152, in check_form_arity >> check_integrand_arity(itg.integrand(), arguments) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/check_arities.py", >> line 145, in check_integrand_arity >> args = map_expr_dag(rules, expr, compress=False) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/corealg/map_dag.py", >> line 37, in map_expr_dag >> result, = map_expr_dags(function, [expression], compress=compress) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/corealg/map_dag.py", >> line 86, in map_expr_dags >> r = handlers[v._ufl_typecode_](v, *[vcache[u] for u in >> v.ufl_operands]) >> File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/check_arities.py", >> line 42, in sum >> raise ArityMismatch("Adding expressions with non-matching form >> arguments {0} vs {1}.".format(a, b)) >> ufl.algorithms.check_arities.ArityMismatch: Adding expressions with >> non-matching form arguments () vs (Argument(WithGeometry(Indexed >> ProxyFunctionSpace(<firedrake.mesh.ExtrudedMeshTopology object at >> 0x113e6b890>, TensorProductElement(FiniteElement('Lagrange', interval, >> 1), FiniteElement('Lagrange', interval, 1), cell=TensorProductCell(interval, >> interval)), name=None, index=0, component=None), >> Mesh(VectorElement(TensorProductElement(FiniteElement('Lagrange', >> interval, 1), FiniteElement('Lagrange', interval, 1), >> cell=TensorProductCell(interval, interval)), dim=2), 4)), 1, None),). >> <coupled_system.pdf> >> >> On 18 Aug 2016, at 16:03, David Ham <david.ham(a)imperial.ac.uk> wrote: >> >> Hi Anna, >> >> Real function spaces now pass some simple tests, at least on my machine. >> You need the real-function-space branch of firedrake, and the >> globals_matrices branch of PyOP2. It's not going to get merged before I >> disappear for a week - not least because I need to update documentation. >> However you should be able to test it out on the branches. >> >> Regards, >> >> David >> >> On Wed, 10 Aug 2016 at 16:58 David Ham <David.Ham(a)imperial.ac.uk> wrote: >> >>> Unfortunately, It isn't as simple as saying "no mpi". MPI pervades >>> Firedrake. Unless real function spaces play nicely with communicators, >>> Firedrake will simply crash. I'm sorry that this feature is not available >>> right now, but it actually does require significant work. >>> >>> On Wed, 10 Aug 2016 at 16:51 Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> >>> wrote: >>> >>>> Yes indeed, but I believe David would want to make it work for all >>>> cases. The merge is necessary in order to proceed with my simulations, so >>>> an update as soon as possible would be greatly appreciated. >>>> >>>> Best, Anna. >>>> >>>> >>>> On 10 Aug 2016, at 16:29, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>>> >>>> We would already be helped for the case without MPI, I think that is >>>> correct, Anna? >>>> >>>> >>>> *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac >>>> .uk> on behalf of David Ham <David.Ham(a)imperial.ac.uk> >>>> >>>> *Sent:* Wednesday, August 10, 2016 10:01 AM >>>> >>>> >>>> *To:* firedrake >>>> *Subject:* Re: [firedrake] Mixed system >>>> >>>> The short version is it depends on when I find some time to work on it. >>>> It is not simply the case that we have new features lying around waiting to >>>> be merged. The current proximate issue is to make the real spaces work >>>> properly with MPI communicators. I can't guarantee that will be the last >>>> issue. >>>> >>>> >>>> On Tue, 9 Aug 2016 at 17:37 Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>>> >>>>> It is possible to merge the branch for the mixed system >>>>> relatively soon? >>>>> Anna's results are relevant for the grant application Colin and I aim >>>>> to submit in Sept. on further wave-ship modelling. >>>>> Sorry for asking! >>>>> ------------------------------ >>>>> *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces@im >>>>> perial.ac.uk> on behalf of David Ham <David.Ham(a)imperial.ac.uk> >>>>> *Sent:* Friday, August 5, 2016 11:37:23 AM >>>>> *To:* firedrake >>>>> *Subject:* Re: [firedrake] Mixed system >>>>> >>>>> >>>>> >>>>> On Fri, 5 Aug 2016 at 11:31 Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> >>>>> wrote: >>>>> >>>>>> Hi Kramer, >>>>>> >>>>>> Thank you for the reply. >>>>>> >>>>>> The only problem I see with the solution you suggest, is that both I >>>>>> and >>>>>> lambda will be trial functions, so both terms should be on the >>>>>> bilinear >>>>>> part of the variational form. >>>>>> >>>>> >>>>> Not quite. I and lambda together form a Function in a mixed finite >>>>> element space. You solve for both of them together, just like pressure and >>>>> velocity in a fluid simulation. >>>>> >>>>> >>>>>> >>>>>> I could, of course, define a residual and solve everything using >>>>>> nonlinear solvers, but I don't know how efficient that would be. >>>>>> >>>>> >>>>> I think you are confused. None of the relevant issues change in the >>>>> nonlinear case. After all, the nonlinear solver will differentiate the >>>>> residual to create a bilinear form anyway. >>>>> >>>>> Incidentally, there is no particular reason to believe that writing >>>>> the problem in nonlinear form would be inefficient. >>>>> >>>>> Regards, >>>>> >>>>> David >>>>> >>>>> >>>>>> >>>>>> Best, >>>>>> >>>>>> Anna. >>>>>> >>>>>> Dr Anna Kalogirou >>>>>> Research Fellow >>>>>> School of Mathematics >>>>>> University of Leeds >>>>>> >>>>>> http://www1.maths.leeds.ac.uk/~matak/ >>>>>> >>>>>> On 04/08/16 17:29, Stephan Kramer wrote: >>>>>> > On 27/07/16 11:01, Anna Kalogirou wrote: >>>>>> >> Dear all, >>>>>> >> >>>>>> >> I am trying to solve the system found in the attached pdf as a >>>>>> mixed >>>>>> >> system. I want to solve the same >>>>>> >> problem as the one found here >>>>>> >> <https://bitbucket.org/annakalog/buoy2d/src/14334d3c20b9f10e >>>>>> d7c1246cde9e3cb60b1c75e4/Inequality%20constraint/?at=master>, >>>>>> >> >>>>>> >> but with the use of Schur complements and not linear algebra. >>>>>> >> >>>>>> >> In a previous discussion about this problem, Lawrence mentioned >>>>>> that the >>>>>> >> test function for integral(lambda*Theta(x-Lp)dx) needs to be >>>>>> considered >>>>>> >> as coming from the real space of constant functions. Could you >>>>>> please >>>>>> >> elaborate on this? >>>>>> > >>>>>> > My guess at what Lawrence means is (it's how I would probably >>>>>> approach >>>>>> > it), is that you add an additional equation that says >>>>>> > >>>>>> > (1) I = integral(lambda*Theta(x-Lp)dx) >>>>>> > >>>>>> > and then substitute I in your third equation. Equation (1) can >>>>>> > be turned into a finite element weak formulation by considering the >>>>>> > function space of functions that are constant over the entire domain >>>>>> > This function space is just 1-dimensional and therefore equivalent >>>>>> to >>>>>> > the space of reals R and hence we denote this function space of >>>>>> > constants simply as R. Then we can consider I to be a trial function >>>>>> > in R, and with a test function v4 in R, we can write: >>>>>> > >>>>>> > v4*lambda*Theta(x-Lp)*dx == v4*I*dx/area(domain) >>>>>> > >>>>>> > This is a proper finite element equation that you could solve in >>>>>> > conjuction with the other equations. I believe however that this >>>>>> > function space R is not currently implemented in Firedrake. It is >>>>>> > available in fenics, and is on the wishlist. >>>>>> > >>>>>> > Cheers >>>>>> > Stephan >>>>>> > >>>>>> > _______________________________________________ >>>>>> > 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 >> >> >> _______________________________________________ >> 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

Re: [firedrake] Mixed system
by Andrew McRae 14 Sep '16

14 Sep '16

Probably related to https://github.com/firedrakeproject/firedrake/issues/862 (third post, not first). You might be able to adapt the fix; I haven't looked in detail. On 12 September 2016 at 16:34, Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> wrote: > Dear all, > > Regarding the problem described in my email sent of Friday, I fixed a > minor typo and now get the error below. Any ideas what might be causing it? > Thanks! > > Best, Anna. > > Traceback (most recent call last): > File "buoy-swe.py", line 89, in <module> > F_solver = solver_F(phi0_5, eta1, mu0_5, I, w, phi0, eta0, Z0, W0, > step_b, etaR, phi_t, eta_t, mu_t, I_t, v1, v2, v3, v4, dt, Hb, H0, L, > dR_dt, g, rho, Mass, solvers_print); > File "/Users/matak/Documents/Simulations/Firedrake/Ship/Modules/Mixed > system/solvers.py", line 41, in solver_F > F_solver = LinearVariationalSolver(F_problem, > solver_parameters=solvers_print) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ > firedrake/variational_solver.py", line 264, in __init__ > super(LinearVariationalSolver, self).__init__(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ > firedrake/variational_solver.py", line 127, in __init__ > ctx = solving_utils._SNESContext(problem) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", > line 107, in __init__ > for problem in problems) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", > line 107, in <genexpr> > for problem in problems) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", > line 67, in assemble > inverse=inverse, nest=nest) > File "<decorator-gen-294>", line 2, in _assemble > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/utils.py", > line 62, in wrapper > return f(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", > line 163, in _assemble > map_pairs.append((op2.DecoratedMap(test.cell_node_map(), > cell_domains), > File "/Users/matak/firedrake/lib/python2.7/site-packages/ > firedrake/functionspaceimpl.py", line 646, in cell_node_map > for i, s in enumerate(self._spaces)) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/backends.py", > line 118, in __call__ > return t(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", > line 156, in __new__ > obj = make_obj() > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", > line 137, in make_obj > obj.__init__(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", > line 3342, in __init__ > if not all(m is None or m.iterset == self.iterset for m in self._maps): > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", > line 3342, in <genexpr> > if not all(m is None or m.iterset == self.iterset for m in self._maps): > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/utils.py", > line 64, in __get__ > obj.__dict__[self.__name__] = result = self.fget(obj) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", > line 3366, in iterset > return reduce(lambda a, b: a if a is None else a.iterset or b if b is > None else b.iterset, self._maps) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", > line 3366, in <lambda> > return reduce(lambda a, b: a if a is None else a.iterset or b if b is > None else b.iterset, self._maps) > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/base.py", > line 799, in __getattr__ > return getattr(self._parent, name) > AttributeError: 'Set' object has no attribute ‘iterset' > > > ********************************************************** > Dr Anna Kalogirou > Research Fellow > Department of Applied Mathematics > University of Leeds > > Web: http://www1.maths.leeds.ac.uk/~matak/ > Youtube: https://www.youtube.com/channel/UCUZAYHtVoiMqepQflisp66g > > ********************************************************** > Leverhulme Trust Early Career Fellow 2017-2019 > > ********************************************************** > > > > On 9 Sep 2016, at 17:37, Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> wrote: > > Hi David, > > I have tried to implement my problem (attached) using the real function > spaces but I get the error below. The code can be found here > <https://bitbucket.org/annakalog/buoy2d/src/d6a805b6a8d0/Mixed%20system/?at=…> > . > > I define the real space by V_R = FunctionSpace(mesh, "R", 0). Is that > correct? > Also, is it a problem that the linear part of the variational form does > not depend on one of the test functions from the mixed function space (only > depends on v1, v2, v3 and not v4)? > > Best, > > Anna. > > > > Traceback (most recent call last): > File "buoy-swe.py", line 89, in <module> > F_solver = solver_F(phi0_5, eta1, mu0_5, I, w, phi0, eta0, Z0, W0, > step_b, etaR, phi_t, eta_t, mu_t, I_t, v1, v2, v3, v4, dt, Hb, H0, L, > dR_dt, g, rho, Mass, solvers_print); > File "/Users/matak/Documents/Simulations/Firedrake/Ship/Modules/Mixed > system/solvers.py", line 41, in solver_F > F_solver = LinearVariationalSolver(F_problem, > solver_parameters=solvers_print) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ > firedrake/variational_solver.py", line 264, in __init__ > super(LinearVariationalSolver, self).__init__(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ > firedrake/variational_solver.py", line 127, in __init__ > ctx = solving_utils._SNESContext(problem) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", > line 107, in __init__ > for problem in problems) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/solving_utils.py", > line 107, in <genexpr> > for problem in problems) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", > line 67, in assemble > inverse=inverse, nest=nest) > File "<decorator-gen-294>", line 2, in _assemble > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/utils.py", > line 62, in wrapper > return f(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/assemble.py", > line 101, in _assemble > inverse=inverse) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/tsfc_interface.py", > line 307, in compile_form > number_map).kernels > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", > line 198, in __new__ > obj = make_obj() > File "/Users/matak/firedrake/lib/python2.7/site-packages/pyop2/caching.py", > line 188, in make_obj > obj.__init__(*args, **kwargs) > File "/Users/matak/firedrake/lib/python2.7/site-packages/firedrake/tsfc_interface.py", > line 212, in __init__ > tree = tsfc_compile_form(form, prefix=name, parameters=parameters) > File "/Users/matak/firedrake/lib/python2.7/site-packages/tsfc/driver.py", > line 47, in compile_form > do_estimate_degrees=True) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/ > algorithms/compute_form_data.py", line 386, in compute_form_data > check_form_arity(preprocessed_form, self.original_form.arguments()) > # Currently testing how fast this is > File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/check_arities.py", > line 152, in check_form_arity > check_integrand_arity(itg.integrand(), arguments) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/check_arities.py", > line 145, in check_integrand_arity > args = map_expr_dag(rules, expr, compress=False) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/corealg/map_dag.py", > line 37, in map_expr_dag > result, = map_expr_dags(function, [expression], compress=compress) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/corealg/map_dag.py", > line 86, in map_expr_dags > r = handlers[v._ufl_typecode_](v, *[vcache[u] for u in v.ufl_operands]) > File "/Users/matak/firedrake/lib/python2.7/site-packages/ufl/algorithms/check_arities.py", > line 42, in sum > raise ArityMismatch("Adding expressions with non-matching form > arguments {0} vs {1}.".format(a, b)) > ufl.algorithms.check_arities.ArityMismatch: Adding expressions with > non-matching form arguments () vs (Argument(WithGeometry( > IndexedProxyFunctionSpace(<firedrake.mesh.ExtrudedMeshTopology object at > 0x113e6b890>, TensorProductElement(FiniteElement('Lagrange', interval, > 1), FiniteElement('Lagrange', interval, 1), cell=TensorProductCell(interval, > interval)), name=None, index=0, component=None), Mesh(VectorElement( > TensorProductElement(FiniteElement('Lagrange', interval, 1), > FiniteElement('Lagrange', interval, 1), cell=TensorProductCell(interval, > interval)), dim=2), 4)), 1, None),). > <coupled_system.pdf> > > On 18 Aug 2016, at 16:03, David Ham <david.ham(a)imperial.ac.uk> wrote: > > Hi Anna, > > Real function spaces now pass some simple tests, at least on my machine. > You need the real-function-space branch of firedrake, and the > globals_matrices branch of PyOP2. It's not going to get merged before I > disappear for a week - not least because I need to update documentation. > However you should be able to test it out on the branches. > > Regards, > > David > > On Wed, 10 Aug 2016 at 16:58 David Ham <David.Ham(a)imperial.ac.uk> wrote: > >> Unfortunately, It isn't as simple as saying "no mpi". MPI pervades >> Firedrake. Unless real function spaces play nicely with communicators, >> Firedrake will simply crash. I'm sorry that this feature is not available >> right now, but it actually does require significant work. >> >> On Wed, 10 Aug 2016 at 16:51 Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> >> wrote: >> >>> Yes indeed, but I believe David would want to make it work for all >>> cases. The merge is necessary in order to proceed with my simulations, so >>> an update as soon as possible would be greatly appreciated. >>> >>> Best, Anna. >>> >>> >>> On 10 Aug 2016, at 16:29, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>> >>> We would already be helped for the case without MPI, I think that is >>> correct, Anna? >>> >>> >>> *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces@imperial. >>> ac.uk> on behalf of David Ham <David.Ham(a)imperial.ac.uk> >>> >>> *Sent:* Wednesday, August 10, 2016 10:01 AM >>> >>> >>> *To:* firedrake >>> *Subject:* Re: [firedrake] Mixed system >>> >>> The short version is it depends on when I find some time to work on it. >>> It is not simply the case that we have new features lying around waiting to >>> be merged. The current proximate issue is to make the real spaces work >>> properly with MPI communicators. I can't guarantee that will be the last >>> issue. >>> >>> >>> On Tue, 9 Aug 2016 at 17:37 Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>> >>>> It is possible to merge the branch for the mixed system relatively soon? >>>> Anna's results are relevant for the grant application Colin and I aim >>>> to submit in Sept. on further wave-ship modelling. >>>> Sorry for asking! >>>> ------------------------------ >>>> *From:* firedrake-bounces(a)imperial.ac.uk <firedrake- >>>> bounces(a)imperial.ac.uk> on behalf of David Ham < >>>> David.Ham(a)imperial.ac.uk> >>>> *Sent:* Friday, August 5, 2016 11:37:23 AM >>>> *To:* firedrake >>>> *Subject:* Re: [firedrake] Mixed system >>>> >>>> >>>> >>>> On Fri, 5 Aug 2016 at 11:31 Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> >>>> wrote: >>>> >>>>> Hi Kramer, >>>>> >>>>> Thank you for the reply. >>>>> >>>>> The only problem I see with the solution you suggest, is that both I >>>>> and >>>>> lambda will be trial functions, so both terms should be on the bilinear >>>>> part of the variational form. >>>>> >>>> >>>> Not quite. I and lambda together form a Function in a mixed finite >>>> element space. You solve for both of them together, just like pressure and >>>> velocity in a fluid simulation. >>>> >>>> >>>>> >>>>> I could, of course, define a residual and solve everything using >>>>> nonlinear solvers, but I don't know how efficient that would be. >>>>> >>>> >>>> I think you are confused. None of the relevant issues change in the >>>> nonlinear case. After all, the nonlinear solver will differentiate the >>>> residual to create a bilinear form anyway. >>>> >>>> Incidentally, there is no particular reason to believe that writing the >>>> problem in nonlinear form would be inefficient. >>>> >>>> Regards, >>>> >>>> David >>>> >>>> >>>>> >>>>> Best, >>>>> >>>>> Anna. >>>>> >>>>> Dr Anna Kalogirou >>>>> Research Fellow >>>>> School of Mathematics >>>>> University of Leeds >>>>> >>>>> http://www1.maths.leeds.ac.uk/~matak/ >>>>> >>>>> On 04/08/16 17:29, Stephan Kramer wrote: >>>>> > On 27/07/16 11:01, Anna Kalogirou wrote: >>>>> >> Dear all, >>>>> >> >>>>> >> I am trying to solve the system found in the attached pdf as a mixed >>>>> >> system. I want to solve the same >>>>> >> problem as the one found here >>>>> >> <https://bitbucket.org/annakalog/buoy2d/src/ >>>>> 14334d3c20b9f10ed7c1246cde9e3cb60b1c75e4/Inequality% >>>>> 20constraint/?at=master>, >>>>> >> >>>>> >> but with the use of Schur complements and not linear algebra. >>>>> >> >>>>> >> In a previous discussion about this problem, Lawrence mentioned >>>>> that the >>>>> >> test function for integral(lambda*Theta(x-Lp)dx) needs to be >>>>> considered >>>>> >> as coming from the real space of constant functions. Could you >>>>> please >>>>> >> elaborate on this? >>>>> > >>>>> > My guess at what Lawrence means is (it's how I would probably >>>>> approach >>>>> > it), is that you add an additional equation that says >>>>> > >>>>> > (1) I = integral(lambda*Theta(x-Lp)dx) >>>>> > >>>>> > and then substitute I in your third equation. Equation (1) can >>>>> > be turned into a finite element weak formulation by considering the >>>>> > function space of functions that are constant over the entire domain >>>>> > This function space is just 1-dimensional and therefore equivalent to >>>>> > the space of reals R and hence we denote this function space of >>>>> > constants simply as R. Then we can consider I to be a trial function >>>>> > in R, and with a test function v4 in R, we can write: >>>>> > >>>>> > v4*lambda*Theta(x-Lp)*dx == v4*I*dx/area(domain) >>>>> > >>>>> > This is a proper finite element equation that you could solve in >>>>> > conjuction with the other equations. I believe however that this >>>>> > function space R is not currently implemented in Firedrake. It is >>>>> > available in fenics, and is on the wishlist. >>>>> > >>>>> > Cheers >>>>> > Stephan >>>>> > >>>>> > _______________________________________________ >>>>> > 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 > > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > > >

2 1

Re: [firedrake] Mixed system
by David Ham 12 Sep '16

12 Sep '16

Unfortunately, It isn't as simple as saying "no mpi". MPI pervades Firedrake. Unless real function spaces play nicely with communicators, Firedrake will simply crash. I'm sorry that this feature is not available right now, but it actually does require significant work. On Wed, 10 Aug 2016 at 16:51 Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> wrote: > Yes indeed, but I believe David would want to make it work for all cases. > The merge is necessary in order to proceed with my simulations, so an > update as soon as possible would be greatly appreciated. > > Best, Anna. > > > On 10 Aug 2016, at 16:29, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > > We would already be helped for the case without MPI, I think that is > correct, Anna? > > > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of David Ham <David.Ham(a)imperial.ac.uk> > > *Sent:* Wednesday, August 10, 2016 10:01 AM > > > *To:* firedrake > *Subject:* Re: [firedrake] Mixed system > > The short version is it depends on when I find some time to work on it. It > is not simply the case that we have new features lying around waiting to be > merged. The current proximate issue is to make the real spaces work > properly with MPI communicators. I can't guarantee that will be the last > issue. > > > On Tue, 9 Aug 2016 at 17:37 Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > >> It is possible to merge the branch for the mixed system relatively soon? >> Anna's results are relevant for the grant application Colin and I aim to >> submit in Sept. on further wave-ship modelling. >> Sorry for asking! >> ------------------------------ >> *From:* firedrake-bounces(a)imperial.ac.uk < >> firedrake-bounces(a)imperial.ac.uk> on behalf of David Ham < >> David.Ham(a)imperial.ac.uk> >> *Sent:* Friday, August 5, 2016 11:37:23 AM >> *To:* firedrake >> *Subject:* Re: [firedrake] Mixed system >> >> >> >> On Fri, 5 Aug 2016 at 11:31 Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> >> wrote: >> >>> Hi Kramer, >>> >>> Thank you for the reply. >>> >>> The only problem I see with the solution you suggest, is that both I and >>> lambda will be trial functions, so both terms should be on the bilinear >>> part of the variational form. >>> >> >> Not quite. I and lambda together form a Function in a mixed finite >> element space. You solve for both of them together, just like pressure and >> velocity in a fluid simulation. >> >> >>> >>> I could, of course, define a residual and solve everything using >>> nonlinear solvers, but I don't know how efficient that would be. >>> >> >> I think you are confused. None of the relevant issues change in the >> nonlinear case. After all, the nonlinear solver will differentiate the >> residual to create a bilinear form anyway. >> >> Incidentally, there is no particular reason to believe that writing the >> problem in nonlinear form would be inefficient. >> >> Regards, >> >> David >> >> >>> >>> Best, >>> >>> Anna. >>> >>> Dr Anna Kalogirou >>> Research Fellow >>> School of Mathematics >>> University of Leeds >>> >>> http://www1.maths.leeds.ac.uk/~matak/ >>> >>> On 04/08/16 17:29, Stephan Kramer wrote: >>> > On 27/07/16 11:01, Anna Kalogirou wrote: >>> >> Dear all, >>> >> >>> >> I am trying to solve the system found in the attached pdf as a mixed >>> >> system. I want to solve the same >>> >> problem as the one found here >>> >> < >>> https://bitbucket.org/annakalog/buoy2d/src/14334d3c20b9f10ed7c1246cde9e3cb6… >>> >, >>> >> >>> >> but with the use of Schur complements and not linear algebra. >>> >> >>> >> In a previous discussion about this problem, Lawrence mentioned that >>> the >>> >> test function for integral(lambda*Theta(x-Lp)dx) needs to be >>> considered >>> >> as coming from the real space of constant functions. Could you please >>> >> elaborate on this? >>> > >>> > My guess at what Lawrence means is (it's how I would probably approach >>> > it), is that you add an additional equation that says >>> > >>> > (1) I = integral(lambda*Theta(x-Lp)dx) >>> > >>> > and then substitute I in your third equation. Equation (1) can >>> > be turned into a finite element weak formulation by considering the >>> > function space of functions that are constant over the entire domain >>> > This function space is just 1-dimensional and therefore equivalent to >>> > the space of reals R and hence we denote this function space of >>> > constants simply as R. Then we can consider I to be a trial function >>> > in R, and with a test function v4 in R, we can write: >>> > >>> > v4*lambda*Theta(x-Lp)*dx == v4*I*dx/area(domain) >>> > >>> > This is a proper finite element equation that you could solve in >>> > conjuction with the other equations. I believe however that this >>> > function space R is not currently implemented in Firedrake. It is >>> > available in fenics, and is on the wishlist. >>> > >>> > Cheers >>> > Stephan >>> > >>> > _______________________________________________ >>> > 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 3

flood drake query
by Onno Bokhove 08 Sep '16

08 Sep '16

Hi, Using/adapting flood drake: - has there been an update with a gmsh example in which solid walls and inflow/outflow/specified flow conditions have been imposed at the boundaries - has the time step been made adaptable based on flood/signal speeds. - I tried daybreak over uniform beach and lowered the time step (adaptable one preferred) but am not sure whether the slope limiter causes some spurious oscillations. Does the Ern slope limiter approach add an extra time step restriction above and beyond the normal CFL* min_dx/|lambda| with CFL<1 and lambda = |u|+ sort (g h)? - Also the speed seems a bit low although I aim to run it against a 2D c-code I once made. Thank you, Onno See code snippet below. """ demo file for simple 2d shallow water equations flooding on a slope """ from __future__ import division from firedrake import * from flooddrake import * # Meshsize n = 5 mesh = UnitSquareMesh(10*n, n) # mixed function space v_h = FunctionSpace(mesh, "DG", 1) v_mu = FunctionSpace(mesh, "DG", 1) v_mv = FunctionSpace(mesh, "DG", 1) V = v_h*v_mu*v_mv # for slope limiter v_hcg = FunctionSpace(mesh, "CG", 1) v_mucg = FunctionSpace(mesh, "CG", 1) v_mvcg = FunctionSpace(mesh, "CG", 1) VCG = v_hcg*v_mucg*v_mvcg # setup free surface depth g = Function(V) x = SpatialCoordinate(V.mesh()) g.sub(0).interpolate(conditional(x[0] < 0.2, 3.0/9.8, 0.0)) # setup bed bed = Function(V) # setup actual depth w = g.assign(g - bed) x = SpatialCoordinate(V.mesh()) bed.sub(0).interpolate(0.25*x[0]) # setup source (is only a depth function) source = Function(v_h) # timestep solution = Timestepper(V, VCG, bed, source, 0.0065) solution.stepper(0, 2, w, 0.025)

3 8

Re: [firedrake] flood drake query
by Colin Cotter 08 Sep '16

08 Sep '16

Hi Onno, Regarding (ii), please can you add this as an issue on Github. all the best --cjc On 8 September 2016 at 16:26, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > Hi flooddrakers, > > > (i) Has flood drake been updated yet wrt the error in the slope limiter? > > The github link is still old it seems? > > > (ii) Also would it be possible to update the boundaries (numbered I > guess) with > > an outside (left flux) which is a function of (a) specified functions and > (b) the > > inside (right) values of the variables (h, mu and mv) such that the user > can specify complicated bc's, including a solid wall, influx/outflux > determined by the numerical flux, etc.? Per our discussion yesterday in > Edinburgh? That would be awesome. > > > Best, > > > Onno > > > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Onno Bokhove <O.Bokhove(a)leeds.ac.uk> > *Sent:* Wednesday, August 10, 2016 4:51 PM > > *To:* firedrake > *Subject:* Re: [firedrake] flood drake query > > > No worries. I had making my Wetropolis mesh on my agenda first so I could > wait. But have not found time yet. > > Obviously then I would need the gmsh option in flood drake but when I have > the mesh for Wetropolis made then I will tell you. > > Thanks. > > > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Gregory, Alastair C A <a.gregory14(a)imperial.ac.uk> > *Sent:* Wednesday, August 10, 2016 4:43 PM > *To:* firedrake > *Subject:* Re: [firedrake] flood drake query > > > Hi Onno, > > > When the checks for this pull request have passed (very soon), I will > merge. However there are some still some bugs (highlighted in the flooding > example you queried about) so I advise you to wait another day before > pulling master until I have pushed some changes that sort these out. This > fix will come alongside adaptive time-stepping which I have done today. > Apologies for the delay. > > > Many Thanks, > > Ali > > > *Alastair Gregory* > ------------------------------------------------------------------- > > *Research Assistant (Maths Foresees Grant) Imperial College London* > Office 759 Huxley Building, South Kensington > *(Tel: 07794 243913) | (Email: a.gregory14(a)imperial.ac.uk > <a.gregory14(a)imperial.ac.uk>)* > ------------------------------------------------------------ > ------------------------ > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Onno Bokhove <O.Bokhove(a)leeds.ac.uk> > *Sent:* 09 August 2016 14:32:05 > *To:* firedrake > *Subject:* Re: [firedrake] flood drake query > > > Waiting for the merge! > > > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Gregory, Alastair C A <a.gregory14(a)imperial.ac.uk> > *Sent:* Tuesday, August 9, 2016 1:31 PM > *To:* firedrake > *Subject:* Re: [firedrake] flood drake query > > > Hi Onno, > > > "- has there been an update with a gmsh example in which solid walls and > inflow/outflow/specified flow conditions have been imposed at the > boundaries" > > > There has not as of yet. The current set-up conditions are only for > firedrake Mesh's and for reflective boundary conditions off of solid walls. > > > "has the time step been made adaptable based on flood/signal speeds" > > > Again not as yet, this will definitely be done though. At the moment, we > specify a value of dt/dx and this dictates the timestep. This is an > argument labelled as Courant in Timestepper class. See help(Timestepper). > > > "I tried daybreak over uniform beach and lowered the time step (adaptable > one preferred) but am not sure whether > > the slope limiter causes some spurious oscillations. Does the Ern slope > limiter approach add an extra time step restriction above and beyond > > the normal CFL* min_dx/|lambda| with CFL<1 and lambda = |u|+ sort (g h)?" > > > So this was a bug that came about from not slope limiting the momentum as > well as the depth. This is in the latest pull request of the package but > hasn't yet been accepted to merge. If you want to try this out, you may > just copy straight off of the branch in which this update is on. There > isn't an extra condition as I know of. > > > "Also the speed seems a bit low although I aim to run it against a 2D > c-code I once made." > > > The speed is slow for 2D but this is as fast as I can get it for the time > being. I will continue to look further into why this could be. > > > Hope this helps and gives you an update. > > > Many Thanks, > > Ali > > > *Alastair Gregory* > ------------------------------------------------------------------- > > *Research Assistant (Maths Foresees Grant) Imperial College London* > Office 759 Huxley Building, South Kensington > *(Tel: 07794 243913) | (Email: a.gregory14(a)imperial.ac.uk > <a.gregory14(a)imperial.ac.uk>)* > ------------------------------------------------------------ > ------------------------ > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Onno Bokhove <O.Bokhove(a)leeds.ac.uk> > *Sent:* 09 August 2016 12:56:03 > *To:* firedrake > *Subject:* [firedrake] flood drake query > > > Hi, > > > Using/adapting flood drake: > > - has there been an update with a gmsh example in which solid walls and > inflow/outflow/specified flow conditions have been imposed at the boundaries > > - has the time step been made adaptable based on flood/signal speeds. > > - I tried daybreak over uniform beach and lowered the time step (adaptable > one preferred) but am not sure whether > > the slope limiter causes some spurious oscillations. Does the Ern slope > limiter approach add an extra time step restriction above and beyond > > the normal CFL* min_dx/|lambda| with CFL<1 and lambda = |u|+ sort (g h)? > > - Also the speed seems a bit low although I aim to run it against a 2D > c-code I once made. > > > Thank you, > > > Onno > > > See code snippet below. > > > """ demo file for simple 2d shallow water equations flooding on a slope """ > > > from __future__ import division > > > from firedrake import * > > from flooddrake import * > > > # Meshsize > > n = 5 > > mesh = UnitSquareMesh(10*n, n) > > > # mixed function space > > v_h = FunctionSpace(mesh, "DG", 1) > > v_mu = FunctionSpace(mesh, "DG", 1) > > v_mv = FunctionSpace(mesh, "DG", 1) > > V = v_h*v_mu*v_mv > > > # for slope limiter > > v_hcg = FunctionSpace(mesh, "CG", 1) > > v_mucg = FunctionSpace(mesh, "CG", 1) > > v_mvcg = FunctionSpace(mesh, "CG", 1) > > VCG = v_hcg*v_mucg*v_mvcg > > > # setup free surface depth > > g = Function(V) > > x = SpatialCoordinate(V.mesh()) > > g.sub(0).interpolate(conditional(x[0] < 0.2, 3.0/9.8, 0.0)) > > > # setup bed > > bed = Function(V) > > > # setup actual depth > > w = g.assign(g - bed) > > x = SpatialCoordinate(V.mesh()) > > bed.sub(0).interpolate(0.25*x[0]) > > > # setup source (is only a depth function) > > source = Function(v_h) > > > # timestep > > solution = Timestepper(V, VCG, bed, source, 0.0065) > > > solution.stepper(0, 2, w, 0.025) > > -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

1 0

Re: [firedrake] Mixed system DirichletBC - mismatching function spaces
by Colin Cotter 07 Sep '16

07 Sep '16

Yes, I would always try weak BCs first. On 6 September 2016 at 17:37, Ham, David A <david.ham(a)imperial.ac.uk> wrote: > At a random guess, I think it might work to apply that BC weakly (ie > (u1-u2)*dx). However one would need to see the code. > > On Tue, 6 Sep 2016 at 17:31, Mitchell, Lawrence < > lawrence.mitchell(a)imperial.ac.uk> wrote: > >> Dear Anna, >> >> On 06/09/16 17:19, Anna Kalogirou wrote: >> > Dear all, >> > >> > I have the following sample code which gives a ValueError: Mismatching >> > function spaces. >> > >> > ## >> > >> > V = FunctionSpace(mesh, "CG", 1) >> > W = V*V >> > >> > w = Function(W) >> > v1, v2 = TestFunctions(W) >> > u1, u2 = split(w) >> > >> > F1 = F(u1, u2) # function of u1 and u2 >> > >> > F2 = F(u2) # function of u2 only >> > >> > bc = DirichletBC(W.sub(1), u1, 'top’) # BC for F2 >> > >> > u_problem = NonlinearVariationalProblem(F1 + F2, w, bcs=[bc]) >> > >> > ## >> > >> > Note that the second equation depends on u1 through the DirichletBC >> > only. Is the error generated due to the fact that u1 comes from >> > W.sub(0) and it is given as a BC on W.sub(0)? >> >> There are two problems here. >> >> 1. u1 is indexed with component 0, but you're trying to apply it to >> component 1 (which is why you get the proximate error). >> >> 2. This is the bigger problem. >> >> The way you've formulated the problem, even if you removed the error >> from (1), which would be possible I think, doesn't do what you think >> it does. We don't support problems where the solution is coupled to >> itself through the boundary condition. So what would happen is you >> would end up minimising the residual for F2 subject to the value of u1 >> on the boundary, *when you started the solve* (i.e. whatever initial >> guess you had for u1). >> >> I think it might be possible to vary how firedrake works to do what >> you want, but one would have to work out what's going on on paper >> first. http://firedrakeproject.org/boundary_conditions.html describes >> the maths (and the implementation strategy) for applying boundary >> conditions. Can you see how to modify it so that it still works if >> the boundary condition value depends on the state variable? >> >> Lawrence >> >> -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

1 0

Re: [firedrake] Mixed system DirichletBC - mismatching function spaces
by David Ham 06 Sep '16

06 Sep '16

At a random guess, I think it might work to apply that BC weakly (ie (u1-u2)*dx). However one would need to see the code. On Tue, 6 Sep 2016 at 17:31, Mitchell, Lawrence < lawrence.mitchell(a)imperial.ac.uk> wrote: > Dear Anna, > > On 06/09/16 17:19, Anna Kalogirou wrote: > > Dear all, > > > > I have the following sample code which gives a ValueError: Mismatching > > function spaces. > > > > ## > > > > V = FunctionSpace(mesh, "CG", 1) > > W = V*V > > > > w = Function(W) > > v1, v2 = TestFunctions(W) > > u1, u2 = split(w) > > > > F1 = F(u1, u2) # function of u1 and u2 > > > > F2 = F(u2) # function of u2 only > > > > bc = DirichletBC(W.sub(1), u1, 'top’) # BC for F2 > > > > u_problem = NonlinearVariationalProblem(F1 + F2, w, bcs=[bc]) > > > > ## > > > > Note that the second equation depends on u1 through the DirichletBC > > only. Is the error generated due to the fact that u1 comes from > > W.sub(0) and it is given as a BC on W.sub(0)? > > There are two problems here. > > 1. u1 is indexed with component 0, but you're trying to apply it to > component 1 (which is why you get the proximate error). > > 2. This is the bigger problem. > > The way you've formulated the problem, even if you removed the error > from (1), which would be possible I think, doesn't do what you think > it does. We don't support problems where the solution is coupled to > itself through the boundary condition. So what would happen is you > would end up minimising the residual for F2 subject to the value of u1 > on the boundary, *when you started the solve* (i.e. whatever initial > guess you had for u1). > > I think it might be possible to vary how firedrake works to do what > you want, but one would have to work out what's going on on paper > first. http://firedrakeproject.org/boundary_conditions.html describes > the maths (and the implementation strategy) for applying boundary > conditions. Can you see how to modify it so that it still works if > the boundary condition value depends on the state variable? > > Lawrence > >

1 0