Also record the average number, min and max number of iterations. ________________________________________ From: firedrake-bounces@imperial.ac.uk <firedrake-bounces@imperial.ac.uk> on behalf of Floriane Gidel [RPG] <mmfg@leeds.ac.uk> Sent: Thursday, March 17, 2016 10:29 AM To: firedrake@imperial.ac.uk Subject: Re: [firedrake] Debug and Optimised mode Dear Lawrence, Using linear solvers indeed improved a bit the running time. Would you like me to send you the new formulations to update the demo? Concerning the non linear solver, how can I change the tolerance so that it iterates less when possible? I have another question concerning the pvd/vtu files: when saving the data with the command "<<", what is the operation applied? Is it only a linear interpolation? Because when I observe the data on Paraview and scale the colorbar to the data range for a given snapshot, the maximum value is different from the maximum value that I get if I save max(eta.dat.data), and this difference is really high (for instance, the amplitude of my wave is 2.45 with max(eta.dat.data), and 2.7 with paraview, while for this study I look at variations of order 0.01). My mesh resolution is 0.2, which is much smaller than my wave length, so even if max(eta.dat.data) takes the maximum at the grid points, I do not expect such a difference... Do you know where this difference could come from? Best wishes, Floriane ________________________________________ From: firedrake-bounces@imperial.ac.uk <firedrake-bounces@imperial.ac.uk> on behalf of Floriane Gidel [RPG] <mmfg@leeds.ac.uk> Sent: Monday, March 14, 2016 2:22 PM To: firedrake@imperial.ac.uk Subject: Re: [firedrake] Debug and Optimised mode Thanks a lot Lawrence! I'll try to reformulate using linear solvers and I'll let you know how it goes. My domain has the shape of the domain attached, where the horizontal side has to be 100-300m (while the wave length is of order 1m which requires a mesh refinement of order 0.1 max). I tried to run the simulations on a faster machine but it did not improve much. But it might indeed after I linearise the solvers. I'll come back to you when it's done. Thanks a lot, Floriane ________________________________________ De : firedrake-bounces@imperial.ac.uk <firedrake-bounces@imperial.ac.uk> de la part de Lawrence Mitchell <lawrence.mitchell@imperial.ac.uk> Envoyé : lundi 14 mars 2016 13:20 À : firedrake@imperial.ac.uk Objet : Re: [firedrake] Debug and Optimised mode On 14/03/16 12:30, Floriane Gidel [RPG] wrote:
Dear Lawrence,
I actually solve the Benney-Luke equations so my code is very similar to the Benney-Luke demo. I define the same functions, weak formulations, problems and variational solvers. They are defined out of my time loop. Only the domain, mesh and initial conditions are different from the demo. In the time loop, I only call the solvers (e.g. eta.solve() ) and save the data. I solve it on my laptop which is a MacBook Pro with OSX version 10.9.5, and processor 2.5 GHz Intel Core i5.
OK. So one thing that may well speed things up (assuming you are not already doing so) is not to output the data at every time step. I also note that the benney-luke demo uses nonlinear solvers to compute the updates: \phi^{n+1/2}, \eta^{n+1} and then \phi^{n+1}. However, the implicit equations defining these problems look to be linear in the respective implicit variables. So I think you should be able to get away with using linear solvers instead. This will mean you won't need to assemble the Jacobians all the time, but just once, which should signficantly reduce the run time. Notice that given the residual form, you can compute the appropriate Jacobian simply: Fphi_h = ... Jphi_h = derivative(Fphi_h, phi_h) If you can reformulate using linear solvers the jacobian evaluation time should drop significantly (run with -log_summary to confirm). If this turns out to be correct, we'd love a patch to the existing benney-luke demo updating it! Finally, how large is the domain? It's possible that if you want this to go much faster, once we've addressed the issues above, you'll need to run on a slightly beefier machine. Cheers, Lawrence _______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake _______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake