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