How could finer meshes end up with wrong answers? #1045
Replies: 4 comments
-
It turned out that the above problem was due to the solver settings. The PETSc developers suggested adding the code below and my problem is solved:
|
Beta Was this translation helpful? Give feedback.
-
I'm glad the 'gamg' preconditioner works for you, although you don't need all that. Just do solver = fp.solvers.petsc.linearGMRESSolver.LinearGMRESSolver(iterations=1000, tolerance=1e-10, precon='gamg') I think you earlier had a comment that it was doing 1000 iterations no matter what? That's because you create eq.solve(var=phi, solver=solver) As it is, you're just getting the default solver, which is GMRES with ILU preconditioning and 1000 iterations. You can override the defaults with direction petsc4py calls, but that's not the way FiPy was designed to be used. |
Beta Was this translation helpful? Give feedback.
-
I'd prefer you didn't delete comments and information that you gave earlier. It makes it really hard to follow and diagnose what's going on. |
Beta Was this translation helpful? Give feedback.
-
Thank you for the response. Do you have any ideas about my other issue (#1043) about getting the top and bottom surfaces by any chances? |
Beta Was this translation helpful? Give feedback.
-
I am wondering if there are some settings or considerations that I need to include when setting a proper mesh size for the model? Such as the lower and upper limit for the mesh size.
Problem description:
Below is the Python code using Fipy and Gmsh and can run with different solvers.
This code describes an object with an initial temperature equal to the ambient temperature and stays there with no external heat.
The solution which shows the temperature map of this object in the steady state should always be equal to the ambient temperature.
However, if I change the mesh size, the results can be very different:
If I change the mesh size
dx
(in the Gmsh code) to 5.e-3 or bigger, the final result equals the ambient value.If I change it to 1.e-3 or smaller, the answers suddenly become very small, such as 1.845, for all petsc solvers, while scipy LU & GMRES still can return the correct results.
(I thought a smaller mesh size should usually end up with a more accurate solution but takes a longer time. I did not expect that it could end up with a very different solution.)
Python code:
Gmsh code:
Beta Was this translation helpful? Give feedback.
All reactions