time dependent navier stokes (gallery) does not work

[hgbk...@gmail.com]

Hello

I would like to report that the time dependent Navier Stokes example in 

https://dealii.org/developer/doxygen/deal.II/code_gallery_time_dependent_navier_stokes.html

compile but does not run correctly with deal.II 9.2.0 . The analysis can run until step 204 and then diverge. Would it be possible changes in preconditioner destroy the convergence?

************************************************************************************************

Time step = 201, at t = 2.010000e-01

 GMRES_ITR = 8   GMRES_RES = 4.052763e-10

************************************************************************************************

Time step = 202, at t = 2.020000e-01

 GMRES_ITR = 8   GMRES_RES = 7.194398e-10

************************************************************************************************

Time step = 203, at t = 2.030000e-01

 GMRES_ITR = 8   GMRES_RES = 1.361073e-09

************************************************************************************************

Time step = 204, at t = 2.040000e-01

 GMRES_ITR = 8   GMRES_RES = 4.896128e-09

************************************************************************************************

Time step = 205, at t = 2.050000e-01

 GMRES_ITR = 8   GMRES_RES = 3.220123e-08

************************************************************************************************

Time step = 206, at t = 2.060000e-01

 GMRES_ITR = 8   GMRES_RES = 7.647033e-07

************************************************************************************************

Time step = 207, at t = 2.070000e-01

 GMRES_ITR = 8   GMRES_RES = 3.355695e-04

************************************************************************************************

Time step = 208, at t = 2.080000e-01

 GMRES_ITR = 8   GMRES_RES = 5.007715e+01

************************************************************************************************

Time step = 209, at t = 2.090000e-01

 GMRES_ITR = 8   GMRES_RES = 1.262003e+12

************************************************************************************************

Time step = 210, at t = 2.100000e-01

 GMRES_ITR = 8   GMRES_RES = 1.279221e+33

Best

Giang

[hgbk...@gmail.com]

Does anyone know which version of deal.II that this example run perfectly?

Best

Giang

[Jean-Paul Pelteret]

Hi Giang,

Does anyone know which version of deal.II that this example run perfectly?

To answer your immediate question:

It looks like the last major change to the code happened in Apr/May 2018 which, in conjunction with the version of deal.II that it previously used to target in the CMakeLists.txt file, means that it was most likely written for deal.II version 9.0.

I would like to report that the time dependent Navier Stokes example in 

https://dealii.org/developer/doxygen/deal.II/code_gallery_time_dependent_navier_stokes.html

compile but does not run correctly with deal.II 9.2.0 

That’s frustrating. Thanks for reporting this; I’ve opened up an issue for this problem (see https://github.com/dealii/code-gallery/issues/88 ). If you do test it against an older version and find that it works, perhaps you could let us know and we could then try to investigate further. It might be possible to bisect the problem if we know what a good version of the library is (it could also be due to some subtle change related to the parallel partitioning, the PETSc interface, etc. which might have been a bug before and has since been fixed, but breaks this code. Hard to say exactly.). The next release of deal.II is imminent, so it would also be interesting to see if whatever is causing the issue has been fixed between 9.2 and 9.3. 

Thanks again!

Jean-Paul

-- 
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 dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/4263fa68-e89f-4748-90cf-4d84980102c6n%40googlegroups.com.

[Wolfgang Bangerth]

It looks like the GMRES solver converged just fine, but that the solution
diverges anyway.

Could you try to run the program with previous versions of deal.II? Did it
work correctly back then? What version is the last one that worked? We may
also want to rope in the author of the program, Jie Cheng (CC:ed), maybe he knows!

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[hgbk...@gmail.com]

Well I could try to reproduce this example with older version of deal.II but this also requires a specific version of Petsc. I forgot to mention above that deal.II is compiled with petsc-3.15.0. A hint on the timeline, e.g. the day the results are produced, could be useful.

Best

Giang

[Wolfgang Bangerth]

On 6/2/21 4:42 PM, hgbk...@gmail.com wrote:
> Well I could try to reproduce this example with older version of deal.II but
> this also requires a specific version of Petsc. I forgot to mention above that
> deal.II is compiled with petsc-3.15.0. A hint on the timeline, e.g. the day
> the results are produced, could be useful.

The best I can offer is to point to the fact that the original program was
proposed in 2017:
https://github.com/dealii/code-gallery/pull/32

I don't think that the problem lies with PETSc, given that the linear solver
converges just fine. I think it computes the correct solution to the wrong
linear system.

[hgbk...@gmail.com]

I tried to reproduce this example with deal.II 9.0.0 but have a compilation problem. This problem occurs only when Petsc is enabled. Does anyone have idea to fix it?

Best

Giang

[hgbk...@gmail.com]

Hello

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>

Therefore I think the problem might lie somewhere between 9.0.1 and 9.1.0. However, I did not see any other tags except 9.1.0-rc1,2,3.

Best

Giang

[Wolfgang Bangerth]

On 6/5/21 9:02 AM, hgbk...@gmail.com 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

[hgbk...@gmail.com]

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

[Marc Fehling]

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 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

[hgbk...@gmail.com]

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