Re: [Nek5000-users] Project a solution onto a polynomial space
Dear Paul, Thank you for answering so quickly. Yes, the polynomial spaces I'm using are the standard Nek5000 basis functions. To understand the problem a little better: I am conducting DNS of a shear flow and I need to compute higher-order velocity moments. I've implemented some subroutines based on the "avg2" and "avg3" subroutines from Nek, but for higher order moments, i.e. <U^3>, <U^2 V>, etc. The problem is that I need to de-alias the non-linear quantities, i.e. U^3, before doing the averaging. Since the flow is planar, I also take the spanwise average using the "z_average" subroutine. I checked out the "convect.f" file to see how dealiasing is applied by mapping onto the finer grid (lxd), but I'm not quite sure how to project these results back onto the original grid. Thank you, Juan Diego
Hi, just out of interest, are you sure that you need dealiasing for statistics? Some long time ago, I tried it as well, and compared it to non-dealiased statistics, and I could not really see a difference. I guess my argument at the time was that you are interested in the low-frequency content of the statistics anyway, so that the aliasing errors would not show up. Are you then planning to increase the polynomial order such that you can completely eliminate the qudrature errors even for third order terms? Best regards, Philipp On 2017-03-22 18:21, [email protected] wrote:
Dear Paul,
Thank you for answering so quickly. Yes, the polynomial spaces I'm using are the standard Nek5000 basis functions.
To understand the problem a little better:
I am conducting DNS of a shear flow and I need to compute higher-order velocity moments. I've implemented some subroutines based on the "avg2" and "avg3" subroutines from Nek, but for higher order moments, i.e. <U^3>, <U^2 V>, etc. The problem is that I need to de-alias the non-linear quantities, i.e. U^3, before doing the averaging. Since the flow is planar, I also take the spanwise average using the "z_average" subroutine.
I checked out the "convect.f" file to see how dealiasing is applied by mapping onto the finer grid (lxd), but I'm not quite sure how to project these results back onto the original grid.
Thank you,
Juan Diego
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
Hi Philipp, I guess to answer your question: we are not sure if de-aliasing is needed, and my impression was that it is only needed for computation, since non-dealiased terms would contaminate the solution, but not so much for post-processing. But to be certain: we wanted to do both approaches and compare. It is very likely we will come to the same conclusions as you did long time ago. I do not believe we were planning to increase the polynomial order at this point, but we might consider it if it is necessary for accurate higher-order statistics. Best regards, Yulia On Mar 22, 2017, at 2:10 PM, [email protected] wrote:
Hi, just out of interest, are you sure that you need dealiasing for statistics? Some long time ago, I tried it as well, and compared it to non-dealiased statistics, and I could not really see a difference. I guess my argument at the time was that you are interested in the low-frequency content of the statistics anyway, so that the aliasing errors would not show up.
Are you then planning to increase the polynomial order such that you can completely eliminate the qudrature errors even for third order terms?
Best regards, Philipp
On 2017-03-22 18:21, [email protected] wrote:
Dear Paul,
Thank you for answering so quickly. Yes, the polynomial spaces I'm using are the standard Nek5000 basis functions.
To understand the problem a little better:
I am conducting DNS of a shear flow and I need to compute higher-order velocity moments. I've implemented some subroutines based on the "avg2" and "avg3" subroutines from Nek, but for higher order moments, i.e. <U^3>, <U^2 V>, etc. The problem is that I need to de-alias the non-linear quantities, i.e. U^3, before doing the averaging. Since the flow is planar, I also take the spanwise average using the "z_average" subroutine.
I checked out the "convect.f" file to see how dealiasing is applied by mapping onto the finer grid (lxd), but I'm not quite sure how to project these results back onto the original grid.
Thank you,
Juan Diego
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
Hi Yulia and Juan Diego, thanks a lot for the answer. This is interesting, and let us know if it is really needed! With "increase the polynomial order" I essentially meant the overintegration, sorry if I was unclear. I wanted to ask whether you plan to use 3 times lx1 for third-order terms. Best, Philipp On 2017-03-22 22:50, [email protected] wrote:
Hi Philipp,
I guess to answer your question: we are not sure if de-aliasing is needed, and my impression was that it is only needed for computation, since non-dealiased terms would contaminate the solution, but not so much for post-processing. But to be certain: we wanted to do both approaches and compare. It is very likely we will come to the same conclusions as you did long time ago.
I do not believe we were planning to increase the polynomial order at this point, but we might consider it if it is necessary for accurate higher-order statistics.
Best regards, Yulia
On Mar 22, 2017, at 2:10 PM, [email protected] wrote:
Hi, just out of interest, are you sure that you need dealiasing for statistics? Some long time ago, I tried it as well, and compared it to non-dealiased statistics, and I could not really see a difference. I guess my argument at the time was that you are interested in the low-frequency content of the statistics anyway, so that the aliasing errors would not show up.
Are you then planning to increase the polynomial order such that you can completely eliminate the qudrature errors even for third order terms?
Best regards, Philipp
On 2017-03-22 18:21, [email protected] wrote:
Dear Paul,
Thank you for answering so quickly. Yes, the polynomial spaces I'm using are the standard Nek5000 basis functions.
To understand the problem a little better:
I am conducting DNS of a shear flow and I need to compute higher-order velocity moments. I've implemented some subroutines based on the "avg2" and "avg3" subroutines from Nek, but for higher order moments, i.e. <U^3>, <U^2 V>, etc. The problem is that I need to de-alias the non-linear quantities, i.e. U^3, before doing the averaging. Since the flow is planar, I also take the spanwise average using the "z_average" subroutine.
I checked out the "convect.f" file to see how dealiasing is applied by mapping onto the finer grid (lxd), but I'm not quite sure how to project these results back onto the original grid.
Thank you,
Juan Diego
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
Dear All, Thanks for the clarification. I think there are two (or three, maybe) issues here: 1) Presentation of a profile of w=<u^3> (say) 2) Computation of w=<u^3> Let's take a 2D case u=u(x,y), w=w(y), < f > := 1/L * \int_0^L f dx. , (x,y) \in [0,L]^2 For example 1, consider u(x,y)=y. Then, w(y) = u(x,y)^3 for all x, and w=y^3. Suppose we have only two points in x and y directions, so that u \in P_1. If w(y) is also only represented as a linear function (say, given by values at the GLL points of the mesh), then: a) The values at the 2 GLL points will be correct (i.e., w=y^3 at y=0 and y=L). b) For the case N=, there are not enough GLL points to represent w=y^3. You will need to interpolate u(x,y) onto a fine mesh prior to cubing the result, and you will need to retain w(y) on this mesh when you print it, if you want to see this. In a similar way, as noted before, if u(x,y)=x (say), then when you integrate u^3, then you'll need a higher-order quadrature, which means interpolating onto a finer mesh in the x direction. One cool thing, for quadrature, you need fewer points in the integration direction than you do in the "presentation" direction (i.e., fewer in x than in y in this example). That's because the Gauss rules allow you to accurately integrate a polynomial of degree 2M with ~M points. Regarding the possible third issue, the same rules apply in time, but might be less severe (or maybe not). The reason that they should be less of an issue in time is that we tend to not push the resolution so hard in time --- I think of it this way: Suppose I had a function that is growing in time. I want to compute it's integral (in time). I'm effectively using trapezoidal rule. I now cube that function, still using trapezoidal rule. If you look at the time history of any point in the domain, we generally have enough points that the trapezoidal rule will do a pretty good job. Otherwise, you will need to interpolate in time as well to accurately integrate u^3(y,t). Note also that of course all of the integration tends to smooth things out, which diminishes the number of modes that will not be accurately integrated (per Philipp's observation about low-frequency content). So, I think what you would want to do for your tests would be to interpolate into space to a higher polynomial, integrate in the planar directions using a higher-order Gauss rule (e.g., GL or GLL, with GL being most common), and present your wall normal profile on a finer set of GLL points. This is just a suggestion of course... Like the rest, I'm interested to know what you find! Thanks! Paul ________________________________________ From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]] Sent: Thursday, March 23, 2017 7:39 AM To: [email protected] Subject: Re: [Nek5000-users] Project a solution onto a polynomial space Hi Yulia and Juan Diego, thanks a lot for the answer. This is interesting, and let us know if it is really needed! With "increase the polynomial order" I essentially meant the overintegration, sorry if I was unclear. I wanted to ask whether you plan to use 3 times lx1 for third-order terms. Best, Philipp On 2017-03-22 22:50, [email protected] wrote:
Hi Philipp,
I guess to answer your question: we are not sure if de-aliasing is needed, and my impression was that it is only needed for computation, since non-dealiased terms would contaminate the solution, but not so much for post-processing. But to be certain: we wanted to do both approaches and compare. It is very likely we will come to the same conclusions as you did long time ago.
I do not believe we were planning to increase the polynomial order at this point, but we might consider it if it is necessary for accurate higher-order statistics.
Best regards, Yulia
On Mar 22, 2017, at 2:10 PM, [email protected] wrote:
Hi, just out of interest, are you sure that you need dealiasing for statistics? Some long time ago, I tried it as well, and compared it to non-dealiased statistics, and I could not really see a difference. I guess my argument at the time was that you are interested in the low-frequency content of the statistics anyway, so that the aliasing errors would not show up.
Are you then planning to increase the polynomial order such that you can completely eliminate the qudrature errors even for third order terms?
Best regards, Philipp
On 2017-03-22 18:21, [email protected] wrote:
Dear Paul,
Thank you for answering so quickly. Yes, the polynomial spaces I'm using are the standard Nek5000 basis functions.
To understand the problem a little better:
I am conducting DNS of a shear flow and I need to compute higher-order velocity moments. I've implemented some subroutines based on the "avg2" and "avg3" subroutines from Nek, but for higher order moments, i.e. <U^3>, <U^2 V>, etc. The problem is that I need to de-alias the non-linear quantities, i.e. U^3, before doing the averaging. Since the flow is planar, I also take the spanwise average using the "z_average" subroutine.
I checked out the "convect.f" file to see how dealiasing is applied by mapping onto the finer grid (lxd), but I'm not quite sure how to project these results back onto the original grid.
Thank you,
Juan Diego
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
Hi Juan, At first I would just try truncating the fully de-alised product for all the modes above lx1 since the first lx1 modes are accurately solved for. Aleks ________________________________ From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]] Sent: Wednesday, March 22, 2017 12:21 PM To: [email protected] Subject: Re: [Nek5000-users] Project a solution onto a polynomial space Dear Paul, Thank you for answering so quickly. Yes, the polynomial spaces I'm using are the standard Nek5000 basis functions. To understand the problem a little better: I am conducting DNS of a shear flow and I need to compute higher-order velocity moments. I've implemented some subroutines based on the "avg2" and "avg3" subroutines from Nek, but for higher order moments, i.e. <U^3>, <U^2 V>, etc. The problem is that I need to de-alias the non-linear quantities, i.e. U^3, before doing the averaging. Since the flow is planar, I also take the spanwise average using the "z_average" subroutine. I checked out the "convect.f" file to see how dealiasing is applied by mapping onto the finer grid (lxd), but I'm not quite sure how to project these results back onto the original grid. Thank you, Juan Diego
participants (1)
-
nek5000-users＠lists.mcs.anl.gov