Expansions and IterativeSolverTolerance in Nektar++
******************* This email originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address. ******************* Hi all, Sorry to disturb you. I have a full 3D simulation with large number of DOF, so I have to do something to reduce the computation cost. Could you please answer my questions on it? 1) The default number of iterative solver tolerance is 1e-10 for velocity components and 1e-9 for pressure components. Under the circumstance where the number of DOF is large, the tolerance is too small and the computation will be costly. So I alternatively use a larger tolerance with 1e-5 for velocity components and 1e-4 for pressure components. Is it accurate enough for simulations? Larger tolerance means less accuracy, but I have to take the computation time into consideration. So Could you please tell me is my set reasonable? 2) When the order expansion for pressure "p" is larger than 1, the CPU time will rise suddenly. I used to set the pressure space order one lower than velocity, but when the order I need is larger than 3 or 4, the cost is still unbearable. So could I set the pressure space order 3 or 4(maybe larger) lower than the velocity? Will it cause some numerical oscillations and incorrect solutions? 3) In user guide, I see that the expansion basis can be specified in detail as a combination of one-dimensional bases. So the heterogeneous polynomial order can be used to increase the resolution in a specified direction like spanwise. Similarly, could I use more quadrature points in a direction without increasing the polynomial order to make the result more accurate? I also encounter a problem when I set the expansions as follow: <EXPANSIONS> <E COMPOSITE="C[6]" BASISTYPE="Modified_A,Modified_A,Modified_A" NUMMODES="5,5,6" POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre,GaussLobattoLegendre" NUMPOINTS="6,6,7" FIELDS="u,v,w" /> <E COMPOSITE="C[6]" BASISTYPE="Modified_A,Modified_A,Modified_A" NUMMODES="2,2,2" POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre,GaussLobattoLegendre" NUMPOINTS="6,6,7"FIELDS="p" /> </EXPANSIONS> My mesh type is hexahedron and the simulation can't start with a error "NaN found during time integration". I don't konw how to solve it. 4) When I apply variable polynomial order in my field, the use of preconditioner may cause CFL number rise rapidly and the simulation will soon break down. Since the preconditioner is a good choice to reduce the CPU time, could you please tell me how to solve it? I will be very grateful to your reply. Many thanks, Zhaoyu Wang Shanghai Jiao Tong University
Hi,
Sorry to disturb you. I have a full 3D simulation with large number of DOF, so I have to do something to reduce the computation cost. Could you please answer my questions on it?
1) The default number of iterative solver tolerance is 1e-10 for velocity components and 1e-9 for pressure components. Under the circumstance where the number of DOF is large, the tolerance is too small and the computation will be costly. So I alternatively use a larger tolerance with 1e-5 for velocity components and 1e-4 for pressure components. Is it accurate enough for simulations? Larger tolerance means less accuracy, but I have to take the computation time into consideration. So Could you please tell me is my set reasonable?
This is reasonable and is often what we do. If you observe pressure oscillations you many need to tighten the tolerance a bit however. What precondition are you using. The default is a diagonal preconditioner but often we observe the LowEnergyBlock preconditioner is better.
2) When the order expansion for pressure "p" is larger than 1, the CPU time will rise suddenly. I used to set the pressure space order one lower than velocity, but when the order I need is larger than 3 or 4, the cost is still unbearable. So could I set the pressure space order 3 or 4(maybe larger) lower than the velocity? Will it cause some numerical oscillations and incorrect solutions?
I would not expect this to cause numerical oscillations or an incorrect solution. However if the pressure is much lower than the velocity I would expect the solution to be less accurate. Typically just reducing the order by 1 is the most appropriate/accurate space.
3) In user guide, I see that the expansion basis can be specified in detail as a combination of one-dimensional bases. So the heterogeneous polynomial order can be used to increase the resolution in a specified direction like spanwise. Similarly, could I use more quadrature points in a direction without increasing the polynomial order to make the result more accurate? I also encounter a problem when I set the expansions as follow:
<EXPANSIONS> <E COMPOSITE="C[6]" BASISTYPE="Modified_A,Modified_A,Modified_A" NUMMODES="5,5,6" POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre,GaussLobattoLegendre" NUMPOINTS="6,6,7" FIELDS="u,v,w" />
<E COMPOSITE="C[6]" BASISTYPE="Modified_A,Modified_A,Modified_A" NUMMODES="2,2,2" POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre,GaussLobattoLegendre" NUMPOINTS="6,6,7"FIELDS="p" /> </EXPANSIONS>
My mesh type is hexahedron and the simulation can't start with a error "NaN found during time integration". I don't konw how to solve it.
We have had a few problems recently with the LowEnergyBlock preconditioner but I do not know if that is what you have been using. I am cc’ing Ankang to see if he might be able to help. Also specifying such a big difference in velocity and pressure space may not be very accurate but I do not know why i would blow up.
4) When I apply variable polynomial order in my field, the use of preconditioner may cause CFL number rise rapidly and the simulation will soon break down. Since the preconditioner is a good choice to reduce the CPU time, could you please tell me how to solve it?
I am not sure what to suggest here. It could be that we have a bug in the variable polynomial preconditioner but we would need a small test case to debug this. If you try solving a Helmholtz problem with a known or analytic answer do you find errors. This would identify that there is a bug. Regards, Spencer.
I will be very grateful to your reply.
Many thanks, Zhaoyu Wang Shanghai Jiao Tong University
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
Hi Spencer and Zhaoyu, (3) the bug in LowEnergyBlock preconditioner occurs when there are prism and hex elements (only these two kinds elements), and expansion mode >=4. There is a merge request to this bug now, and will be fixed in a short time. These suggestions are also very helpful to me. Thanks a lot Ankang ________________________________ From: Sherwin, Spencer J <s.sherwin@imperial.ac.uk> Sent: 08 July 2020 13:55 To: 王昭予 <clemden@sjtu.edu.cn> Cc: nektar-users <nektar-users@imperial.ac.uk>; Gao, Ankang <ankang.gao@imperial.ac.uk> Subject: Re: [Nektar-users] Expansions and IterativeSolverTolerance in Nektar++ Hi,
Sorry to disturb you. I have a full 3D simulation with large number of DOF, so I have to do something to reduce the computation cost. Could you please answer my questions on it?
1) The default number of iterative solver tolerance is 1e-10 for velocity components and 1e-9 for pressure components. Under the circumstance where the number of DOF is large, the tolerance is too small and the computation will be costly. So I alternatively use a larger tolerance with 1e-5 for velocity components and 1e-4 for pressure components. Is it accurate enough for simulations? Larger tolerance means less accuracy, but I have to take the computation time into consideration. So Could you please tell me is my set reasonable?
This is reasonable and is often what we do. If you observe pressure oscillations you many need to tighten the tolerance a bit however. What precondition are you using. The default is a diagonal preconditioner but often we observe the LowEnergyBlock preconditioner is better.
2) When the order expansion for pressure "p" is larger than 1, the CPU time will rise suddenly. I used to set the pressure space order one lower than velocity, but when the order I need is larger than 3 or 4, the cost is still unbearable. So could I set the pressure space order 3 or 4(maybe larger) lower than the velocity? Will it cause some numerical oscillations and incorrect solutions?
I would not expect this to cause numerical oscillations or an incorrect solution. However if the pressure is much lower than the velocity I would expect the solution to be less accurate. Typically just reducing the order by 1 is the most appropriate/accurate space.
3) In user guide, I see that the expansion basis can be specified in detail as a combination of one-dimensional bases. So the heterogeneous polynomial order can be used to increase the resolution in a specified direction like spanwise. Similarly, could I use more quadrature points in a direction without increasing the polynomial order to make the result more accurate? I also encounter a problem when I set the expansions as follow:
<EXPANSIONS> <E COMPOSITE="C[6]" BASISTYPE="Modified_A,Modified_A,Modified_A" NUMMODES="5,5,6" POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre,GaussLobattoLegendre" NUMPOINTS="6,6,7" FIELDS="u,v,w" />
<E COMPOSITE="C[6]" BASISTYPE="Modified_A,Modified_A,Modified_A" NUMMODES="2,2,2" POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre,GaussLobattoLegendre" NUMPOINTS="6,6,7"FIELDS="p" /> </EXPANSIONS>
My mesh type is hexahedron and the simulation can't start with a error "NaN found during time integration". I don't konw how to solve it.
We have had a few problems recently with the LowEnergyBlock preconditioner but I do not know if that is what you have been using. I am cc’ing Ankang to see if he might be able to help. Also specifying such a big difference in velocity and pressure space may not be very accurate but I do not know why i would blow up.
4) When I apply variable polynomial order in my field, the use of preconditioner may cause CFL number rise rapidly and the simulation will soon break down. Since the preconditioner is a good choice to reduce the CPU time, could you please tell me how to solve it?
I am not sure what to suggest here. It could be that we have a bug in the variable polynomial preconditioner but we would need a small test case to debug this. If you try solving a Helmholtz problem with a known or analytic answer do you find errors. This would identify that there is a bug. Regards, Spencer.
I will be very grateful to your reply.
Many thanks, Zhaoyu Wang Shanghai Jiao Tong University
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
participants (3)
-
Gao, Ankang
-
Sherwin, Spencer J
-
王昭予