Hi Marc The issue propagates up to master. The commit right before 0eeeec59a54d7385a8e862fa114201e91c0f3c53, which is a36c5bc5fe032abff1ded245d3bfb2bd4af1bbb8 still runs fine (in this particular example). Could you or someone verify this two particular commits and confirm my findings, and maybe with the example I attached?
On the time, it seems some fixes have been made after 51c7b294f5f81c5c0f1ac1aa09670ea1729f563e so the time got back to normal in a36c5bc5fe032abff1ded245d3bfb2bd4af1bbb8. Therefore I would like to take this one back :) For a36c5bc5fe032abff1ded245d3bfb2bd4af1bbb8: +---------------------------------------------+------------+------------+ | Total wallclock time elapsed since start | 1.153e+04s | | | | | | | Section | no. calls | wall time | % of total | +---------------------------------+-----------+------------+------------+ | Assemble system | 1000 | 1.346e+02s | 1.17e+00% | | CG for A | 7278 | 1.108e+04s | 9.61e+01% | | CG for Mp | 7278 | 1.302e+01s | 1.13e-01% | | CG for Sm | 7379 | 2.360e+02s | 2.05e+00% | | Output results | 101 | 1.375e+01s | 1.19e-01% | | Refine mesh | 100 | 2.851e+01s | 2.47e-01% | +---------------------------------+-----------+------------+------------+ For 51c7b294f5f81c5c0f1ac1aa09670ea1729f563e (slow) +---------------------------------------------+------------+------------+ | Total wallclock time elapsed since start | 7.339e+04s | | | | | | | Section | no. calls | wall time | % of total | +---------------------------------+-----------+------------+------------+ | Assemble system | 1000 | 1.486e+02s | 2.03e-01% | | CG for A | 7268 | 5.602e+04s | 7.63e+01% | | CG for Mp | 7268 | 6.499e+02s | 8.86e-01% | | CG for Sm | 7369 | 1.608e+04s | 2.19e+01% | | Output results | 101 | 9.217e+00s | 0.000e+00% | | Refine mesh | 100 | 1.345e+02s | 1.83e-01% | +---------------------------------+-----------+------------+------------+ For d5ab9e084ae9aae301b121c22a5548539df7032e (slow) +---------------------------------------------+------------+------------+ | Total wallclock time elapsed since start | 8.309e+04s | | | | | | | Section | no. calls | wall time | % of total | +---------------------------------+-----------+------------+------------+ | Assemble system | 1000 | 1.562e+02s | 1.88e-01% | | CG for A | 7268 | 6.681e+04s | 8.04e+01% | | CG for Mp | 7268 | 7.448e+02s | 8.96e-01% | | CG for Sm | 7369 | 1.489e+04s | 1.79e+01% | | Output results | 101 | 1.231e+01s | 0.000e+00% | | Refine mesh | 100 | 7.927e+01s | 0.000e+00% | +---------------------------------+-----------+------------+------------+ For 3c2a09881baa2a55f19e47586b5914babe1b145d: +---------------------------------------------+------------+------------+ | Total wallclock time elapsed since start | 1.328e+04s | | | | | | | Section | no. calls | wall time | % of total | +---------------------------------+-----------+------------+------------+ | Assemble system | 1000 | 1.769e+02s | 1.33e+00% | | CG for A | 7278 | 1.135e+04s | 8.55e+01% | | CG for Mp | 7278 | 7.197e+01s | 5.42e-01% | | CG for Sm | 7379 | 1.256e+03s | 9.45e+00% | | Output results | 101 | 2.279e+01s | 1.72e-01% | | Refine mesh | 100 | 3.357e+02s | 2.53e+00% | +---------------------------------+-----------+------------+------------+ Best Giang On Monday, June 14, 2021 at 10:27:44 PM UTC+2 [email protected] wrote: > Hi Giang, > > > I did the git bisect (14 iterations) and it reveals that the commit > 0eeeec59a54d7385a8e862fa114201e91c0f3c53 gives the problem. > > For convenience, I linked to the commit > <https://github.com/dealii/dealii/commit/0eeeec59a54d7385a8e862fa114201e91c0f3c53> > > with that specific hash. This commit is not part of the deal.ii 9.2 > release, so it can not be the cause of the diverging solution as you found > it with version 9.2. Further, that commit only changes parts of the > `MatrixFree` implementation, which the code-gallery program does not use. > > I'm confused: So your solution was fine right before that particular > commit? > > > > In addition somewhere between > commit d5ab9e084ae9aae301b121c22a5548539df7032e > and 51c7b294f5f81c5c0f1ac1aa09670ea1729f563e makes the code run > significantly slower. > > Did you notice the slowdown only in `Debug` mode or also in `Release` mode? > > Best, > Marc > > On Monday, June 14, 2021 at 11:06:02 AM UTC-6 [email protected] wrote: > >> Hi Wolfgang >> >> Thanks for the hint. Luckily the old code compiled and runs fine with >> v9.0.0. >> >> I did the git bisect (14 iterations) and it reveals that the commit >> 0eeeec59a54d7385a8e862fa114201e91c0f3c53 gives the problem. >> >> In addition somewhere between >> commit d5ab9e084ae9aae301b121c22a5548539df7032e >> and 51c7b294f5f81c5c0f1ac1aa09670ea1729f563e makes the code run >> significantly slower. >> >> Unfortunately, I could not thoroughly go into the code and investigate >> the problem. This is only to find out which commit has an issue. >> >> The test is performed with a slightly modified version of the original >> example (see attached file) in which >> >> KellyErrorEstimator<dim>::estimate(dof_handler, >> face_quad_formula, >> typename FunctionMap<dim>::type(), >> present_solution, >> estimated_error_per_cell, >> fe.component_mask(velocity)); >> >> is replaced by >> >> KellyErrorEstimator<dim>::estimate(dof_handler, >> face_quad_formula, >> {}, >> present_solution, >> estimated_error_per_cell, >> fe.component_mask(velocity)); >> >> This is because the FunctionMap is deprecated. I hope that it does not >> affect the results. >> >> Best >> Giang >> >> On Wednesday, June 9, 2021 at 10:43:44 PM UTC+2 Wolfgang Bangerth wrote: >> >>> On 6/5/21 9:02 AM, [email protected] wrote: >>> > >>> > I have tried to run this example with deal.II 9.1.0 and this problem >>> still >>> > persists. With deal.II 9.0.0/9.0.1 the example fails to compile >>> because it >>> > requires affine_constraints.h, which is not yet introduced: >>> > >>> > >>> /home/hbui/workspace2/deal.II/time_dependent_navier_stokes/time_dependent_navier_stokes.cc:9:10: >>> >>> >>> > fatal error: deal.II/lac/affine_constraints.h: No such file or >>> directory >>> > #include <deal.II/lac/affine_constraints.h> >>> >>> This class used to be called ConstraintMatrix and was defined in >>> deal.II/lac/constraint_matrix.h. >>> >>> You could go back in the history of the NS gallery program to match the >>> 9.0 >>> release. The github repository for the code gallery is here: >>> https://github.com/dealii/code-gallery >>> The history of the .cc file is here: >>> >>> >>> https://github.com/dealii/code-gallery/commits/master/time_dependent_navier_stokes/time_dependent_navier_stokes.cc >>> >>> >>> Best >>> W. >>> >>> -- >>> ------------------------------------------------------------------------ >>> Wolfgang Bangerth email: [email protected] >>> www: http://www.math.colostate.edu/~bangerth/ >>> >>> -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/23727c2b-98f1-4990-9d52-7a56589f2ba8n%40googlegroups.com.
