unphysical wiggles in Reynolds stress
******************* 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. ******************* Dear All, I hope everyone is all rights! Once I raised this issue before but I wasn't able to resolve it. I get unphysical oscillation in Reynolds stress calculated by Nektar++. The footprints of elements are so much that render the results useless. Below is an example: [image: image.png] On the contrary, the time-averaged fields are so smooth: [image: image.png] I am using a quite fine mesh with a p-order of 4: [image: image.png] The case is quasi-3D with a homogenous z-direction. I am wondering what can be done to mitigate the spurious oscillations. Please share your thoughts with me. I appreciate any help you can provide. Kind regards syavash
Hi Syavash, This does seem to have been a problem for a while. What I believe is going on is that we construct the Reynolds stresses (which is a square of the velocity) at the elemental level and then do a local projection to the coefficient space which would likely lead to jumps at element interfaces that is evident in your images. We are also in this case taking a non-linear product and then projecting it down to the original polynomial space which could mean we have aliasing. So ideally what we perhaps should be doing is: 1. After we do a FwdTransLocalElmt() we could do an assemble call (which would add together the coefficients at the interfaces, divide this value by the multiplicity of the degree of freedom and then scatter these values back using a GlobalToLocal() call. In an ideal world we might to a FwdTrans call but this would require the global inverse of the mass matrix so the alternative above is just a cheaper approximation to this. This would require us to calculate the multiplicity (which we do in other parts of the code). 2. Since this is a non-linear projection we should perhaps be dealiasing the (u-u_bar)(u-u_bar) terms. So if dealiasing were turned on then we should be interpolating the (u-u_bar) to a higher set of quadrature points using the PhysInterp1D routines take the products of the (u-u_bar) terms and then use the GalerkinProject1D routine to take them back to the original quadrature points. This is what we do in the non-linear advection terms and this might also help get a better estimate. Talking to Chi Hin he mentioned that in the past when he has had this problem increasing resolution has sorted it which means the routine is robust when convergence but at higher Re it will be harder to just throw resolution at the problem. So the above modifications might help a lot. As always not sure when we can get this all implemented and tested but thought I would share my views on what we could do! Cheers, Spencer. From: nektar-users-bounces@imperial.ac.uk <nektar-users-bounces@imperial.ac.uk> on behalf of Ehsan Asgari <eh.asgari@gmail.com> Date: Wednesday, 10 April 2024 at 01:05 To: nektar-users <nektar-users@imperial.ac.uk> Subject: [Nektar-users] unphysical wiggles in Reynolds stress This email from eh.asgari@gmail.com 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. Dear All, I hope everyone is all rights! Once I raised this issue before but I wasn't able to resolve it. I get unphysical oscillation in Reynolds stress calculated by Nektar++. The footprints of elements are so much that render the results useless. Below is an example: [cid:ii_lut1h1tm0] On the contrary, the time-averaged fields are so smooth: [cid:ii_lut1kmjy1] I am using a quite fine mesh with a p-order of 4: [cid:ii_lut1mc3y2] The case is quasi-3D with a homogenous z-direction. I am wondering what can be done to mitigate the spurious oscillations. Please share your thoughts with me. I appreciate any help you can provide. Kind regards syavash
Hi Spencer Thank you so much for the elaboration. I had some speculation that it has something to do with the projection into local space. At least I know it's not a problem with my setup. In a recent paper published in JFM, the authors showed very smooth contours of Reynolds stresses. I wonder how they managed to do it since their mesh was quite coarse. I hope that this issue will be addressed in an upcoming update! Kind regards syavash On Wed, Apr 10, 2024, 12:20 PM Sherwin, Spencer J <s.sherwin@imperial.ac.uk> wrote:
Hi Syavash,
This does seem to have been a problem for a while. What I believe is going on is that we construct the Reynolds stresses (which is a square of the velocity) at the elemental level and then do a local projection to the coefficient space which would likely lead to jumps at element interfaces that is evident in your images. We are also in this case taking a non-linear product and then projecting it down to the original polynomial space which could mean we have aliasing.
So ideally what we perhaps should be doing is:
1. After we do a FwdTransLocalElmt() we could do an assemble call (which would add together the coefficients at the interfaces, divide this value by the multiplicity of the degree of freedom and then scatter these values back using a GlobalToLocal() call. In an ideal world we might to a FwdTrans call but this would require the global inverse of the mass matrix so the alternative above is just a cheaper approximation to this. This would require us to calculate the multiplicity (which we do in other parts of the code). 2. Since this is a non-linear projection we should perhaps be dealiasing the (u-u_bar)(u-u_bar) terms. So if dealiasing were turned on then we should be interpolating the (u-u_bar) to a higher set of quadrature points using the PhysInterp1D routines take the products of the (u-u_bar) terms and then use the GalerkinProject1D routine to take them back to the original quadrature points. This is what we do in the non-linear advection terms and this might also help get a better estimate.
Talking to Chi Hin he mentioned that in the past when he has had this problem increasing resolution has sorted it which means the routine is robust when convergence but at higher Re it will be harder to just throw resolution at the problem. So the above modifications might help a lot.
As always not sure when we can get this all implemented and tested but thought I would share my views on what we could do!
Cheers,
Spencer.
*From: *nektar-users-bounces@imperial.ac.uk < nektar-users-bounces@imperial.ac.uk> on behalf of Ehsan Asgari < eh.asgari@gmail.com> *Date: *Wednesday, 10 April 2024 at 01:05 *To: *nektar-users <nektar-users@imperial.ac.uk> *Subject: *[Nektar-users] unphysical wiggles in Reynolds stress
This email from eh.asgari@gmail.com 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.
Dear All,
I hope everyone is all rights!
Once I raised this issue before but I wasn't able to resolve it.
I get unphysical oscillation in Reynolds stress calculated by Nektar++.
The footprints of elements are so much that render the results useless.
Below is an example:
On the contrary, the time-averaged fields are so smooth:
I am using a quite fine mesh with a p-order of 4:
The case is quasi-3D with a homogenous z-direction. I am wondering what can be done to mitigate the spurious oscillations.
Please share your thoughts with me. I appreciate any help you can provide.
Kind regards
syavash
Which JFM paper was it you mentioned? Cheers, Spener. From: Syavash Asgari <s.airyaman@gmail.com> Date: Wednesday, 10 April 2024 at 17:56 To: Sherwin, Spencer J <s.sherwin@imperial.ac.uk> Cc: Ehsan Asgari <eh.asgari@gmail.com>, nektar-users <nektar-users@imperial.ac.uk> Subject: Re: [Nektar-users] unphysical wiggles in Reynolds stress Hi Spencer Thank you so much for the elaboration. I had some speculation that it has something to do with the projection into local space. At least I know it's not a problem with my setup. In a recent paper published in JFM, the authors showed very smooth contours of Reynolds stresses. I wonder how they managed to do it since their mesh was quite coarse. I hope that this issue will be addressed in an upcoming update! Kind regards syavash On Wed, Apr 10, 2024, 12:20 PM Sherwin, Spencer J <s.sherwin@imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk>> wrote: Hi Syavash, This does seem to have been a problem for a while. What I believe is going on is that we construct the Reynolds stresses (which is a square of the velocity) at the elemental level and then do a local projection to the coefficient space which would likely lead to jumps at element interfaces that is evident in your images. We are also in this case taking a non-linear product and then projecting it down to the original polynomial space which could mean we have aliasing. So ideally what we perhaps should be doing is: 1. After we do a FwdTransLocalElmt() we could do an assemble call (which would add together the coefficients at the interfaces, divide this value by the multiplicity of the degree of freedom and then scatter these values back using a GlobalToLocal() call. In an ideal world we might to a FwdTrans call but this would require the global inverse of the mass matrix so the alternative above is just a cheaper approximation to this. This would require us to calculate the multiplicity (which we do in other parts of the code). 2. Since this is a non-linear projection we should perhaps be dealiasing the (u-u_bar)(u-u_bar) terms. So if dealiasing were turned on then we should be interpolating the (u-u_bar) to a higher set of quadrature points using the PhysInterp1D routines take the products of the (u-u_bar) terms and then use the GalerkinProject1D routine to take them back to the original quadrature points. This is what we do in the non-linear advection terms and this might also help get a better estimate. Talking to Chi Hin he mentioned that in the past when he has had this problem increasing resolution has sorted it which means the routine is robust when convergence but at higher Re it will be harder to just throw resolution at the problem. So the above modifications might help a lot. As always not sure when we can get this all implemented and tested but thought I would share my views on what we could do! Cheers, Spencer. From: nektar-users-bounces@imperial.ac.uk<mailto:nektar-users-bounces@imperial.ac.uk> <nektar-users-bounces@imperial.ac.uk<mailto:nektar-users-bounces@imperial.ac.uk>> on behalf of Ehsan Asgari <eh.asgari@gmail.com<mailto:eh.asgari@gmail.com>> Date: Wednesday, 10 April 2024 at 01:05 To: nektar-users <nektar-users@imperial.ac.uk<mailto:nektar-users@imperial.ac.uk>> Subject: [Nektar-users] unphysical wiggles in Reynolds stress This email from eh.asgari@gmail.com<mailto:eh.asgari@gmail.com> 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. Dear All, I hope everyone is all rights! Once I raised this issue before but I wasn't able to resolve it. I get unphysical oscillation in Reynolds stress calculated by Nektar++. The footprints of elements are so much that render the results useless. Below is an example: [cid:ii_lut1h1tm0] On the contrary, the time-averaged fields are so smooth: [cid:ii_lut1kmjy1] I am using a quite fine mesh with a p-order of 4: [cid:ii_lut1mc3y2] The case is quasi-3D with a homogenous z-direction. I am wondering what can be done to mitigate the spurious oscillations. Please share your thoughts with me. I appreciate any help you can provide. Kind regards syavash
The title is "Pressure drag reduction via imposition of spanwise wall oscillations on a rough wall" by Deshpande et al. JFM 2024. In Fig. 3 of the named paper you may see Reynolds shear stress contours. Kind regards syavash On Sat, Apr 13, 2024 at 2:46 PM Sherwin, Spencer J <s.sherwin@imperial.ac.uk> wrote:
Which JFM paper was it you mentioned?
Cheers,
Spener.
*From: *Syavash Asgari <s.airyaman@gmail.com> *Date: *Wednesday, 10 April 2024 at 17:56 *To: *Sherwin, Spencer J <s.sherwin@imperial.ac.uk> *Cc: *Ehsan Asgari <eh.asgari@gmail.com>, nektar-users < nektar-users@imperial.ac.uk> *Subject: *Re: [Nektar-users] unphysical wiggles in Reynolds stress
Hi Spencer
Thank you so much for the elaboration.
I had some speculation that it has something to do with the projection into local space.
At least I know it's not a problem with my setup.
In a recent paper published in JFM, the authors showed very smooth contours of Reynolds stresses. I wonder how they managed to do it since their mesh was quite coarse.
I hope that this issue will be addressed in an upcoming update!
Kind regards
syavash
On Wed, Apr 10, 2024, 12:20 PM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Syavash,
This does seem to have been a problem for a while. What I believe is going on is that we construct the Reynolds stresses (which is a square of the velocity) at the elemental level and then do a local projection to the coefficient space which would likely lead to jumps at element interfaces that is evident in your images. We are also in this case taking a non-linear product and then projecting it down to the original polynomial space which could mean we have aliasing.
So ideally what we perhaps should be doing is:
1. After we do a FwdTransLocalElmt() we could do an assemble call (which would add together the coefficients at the interfaces, divide this value by the multiplicity of the degree of freedom and then scatter these values back using a GlobalToLocal() call. In an ideal world we might to a FwdTrans call but this would require the global inverse of the mass matrix so the alternative above is just a cheaper approximation to this. This would require us to calculate the multiplicity (which we do in other parts of the code). 2. Since this is a non-linear projection we should perhaps be dealiasing the (u-u_bar)(u-u_bar) terms. So if dealiasing were turned on then we should be interpolating the (u-u_bar) to a higher set of quadrature points using the PhysInterp1D routines take the products of the (u-u_bar) terms and then use the GalerkinProject1D routine to take them back to the original quadrature points. This is what we do in the non-linear advection terms and this might also help get a better estimate.
Talking to Chi Hin he mentioned that in the past when he has had this problem increasing resolution has sorted it which means the routine is robust when convergence but at higher Re it will be harder to just throw resolution at the problem. So the above modifications might help a lot.
As always not sure when we can get this all implemented and tested but thought I would share my views on what we could do!
Cheers,
Spencer.
*From: *nektar-users-bounces@imperial.ac.uk < nektar-users-bounces@imperial.ac.uk> on behalf of Ehsan Asgari < eh.asgari@gmail.com> *Date: *Wednesday, 10 April 2024 at 01:05 *To: *nektar-users <nektar-users@imperial.ac.uk> *Subject: *[Nektar-users] unphysical wiggles in Reynolds stress
This email from eh.asgari@gmail.com 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.
Dear All,
I hope everyone is all rights!
Once I raised this issue before but I wasn't able to resolve it.
I get unphysical oscillation in Reynolds stress calculated by Nektar++.
The footprints of elements are so much that render the results useless.
Below is an example:
On the contrary, the time-averaged fields are so smooth:
I am using a quite fine mesh with a p-order of 4:
The case is quasi-3D with a homogenous z-direction. I am wondering what can be done to mitigate the spurious oscillations.
Please share your thoughts with me. I appreciate any help you can provide.
Kind regards
syavash
Hi Syavash, Have you tried converting your wall shear stresses files to tecplot or vtk using more quadrature points? You can use the FieldConvert -n NumberOfPoints option to select the number of quadrature points that you use when converting your fields. Also, as a sanity check is the polynomial order of your simulation at least one order higher than your mesh? We have seen in other simulations that we have similar artifacts when the polynomial order of the geometry is the same as the polynomial order of the simulation. Kind regards, Alexandra On Sat, 13 Apr 2024 at 20:13, Ehsan Asgari <eh.asgari@gmail.com> wrote:
The title is "Pressure drag reduction via imposition of spanwise wall oscillations on a rough wall" by Deshpande et al. JFM 2024. In Fig. 3 of the named paper you may see Reynolds shear stress contours.
Kind regards syavash
On Sat, Apr 13, 2024 at 2:46 PM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Which JFM paper was it you mentioned?
Cheers,
Spener.
*From: *Syavash Asgari <s.airyaman@gmail.com> *Date: *Wednesday, 10 April 2024 at 17:56 *To: *Sherwin, Spencer J <s.sherwin@imperial.ac.uk> *Cc: *Ehsan Asgari <eh.asgari@gmail.com>, nektar-users < nektar-users@imperial.ac.uk> *Subject: *Re: [Nektar-users] unphysical wiggles in Reynolds stress
Hi Spencer
Thank you so much for the elaboration.
I had some speculation that it has something to do with the projection into local space.
At least I know it's not a problem with my setup.
In a recent paper published in JFM, the authors showed very smooth contours of Reynolds stresses. I wonder how they managed to do it since their mesh was quite coarse.
I hope that this issue will be addressed in an upcoming update!
Kind regards
syavash
On Wed, Apr 10, 2024, 12:20 PM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Syavash,
This does seem to have been a problem for a while. What I believe is going on is that we construct the Reynolds stresses (which is a square of the velocity) at the elemental level and then do a local projection to the coefficient space which would likely lead to jumps at element interfaces that is evident in your images. We are also in this case taking a non-linear product and then projecting it down to the original polynomial space which could mean we have aliasing.
So ideally what we perhaps should be doing is:
1. After we do a FwdTransLocalElmt() we could do an assemble call (which would add together the coefficients at the interfaces, divide this value by the multiplicity of the degree of freedom and then scatter these values back using a GlobalToLocal() call. In an ideal world we might to a FwdTrans call but this would require the global inverse of the mass matrix so the alternative above is just a cheaper approximation to this. This would require us to calculate the multiplicity (which we do in other parts of the code). 2. Since this is a non-linear projection we should perhaps be dealiasing the (u-u_bar)(u-u_bar) terms. So if dealiasing were turned on then we should be interpolating the (u-u_bar) to a higher set of quadrature points using the PhysInterp1D routines take the products of the (u-u_bar) terms and then use the GalerkinProject1D routine to take them back to the original quadrature points. This is what we do in the non-linear advection terms and this might also help get a better estimate.
Talking to Chi Hin he mentioned that in the past when he has had this problem increasing resolution has sorted it which means the routine is robust when convergence but at higher Re it will be harder to just throw resolution at the problem. So the above modifications might help a lot.
As always not sure when we can get this all implemented and tested but thought I would share my views on what we could do!
Cheers,
Spencer.
*From: *nektar-users-bounces@imperial.ac.uk < nektar-users-bounces@imperial.ac.uk> on behalf of Ehsan Asgari < eh.asgari@gmail.com> *Date: *Wednesday, 10 April 2024 at 01:05 *To: *nektar-users <nektar-users@imperial.ac.uk> *Subject: *[Nektar-users] unphysical wiggles in Reynolds stress
This email from eh.asgari@gmail.com 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.
Dear All,
I hope everyone is all rights!
Once I raised this issue before but I wasn't able to resolve it.
I get unphysical oscillation in Reynolds stress calculated by Nektar++.
The footprints of elements are so much that render the results useless.
Below is an example:
On the contrary, the time-averaged fields are so smooth:
I am using a quite fine mesh with a p-order of 4:
The case is quasi-3D with a homogenous z-direction. I am wondering what can be done to mitigate the spurious oscillations.
Please share your thoughts with me. I appreciate any help you can provide.
Kind regards
syavash
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
Hi Alexandra Thanks for your reply. I have issues with the Reynolds stress tensor calculated by the Reynolds stress filter (a Quasi-3D case). I don't know if what you suggested for the wall shear stress would help. And yes, I have a cubic mesh but as mentioned before I am using a p-order of 4. Though I didn't know it could cause such artifacts. I appreciate it. Kind regards syavash On Sun, Apr 14, 2024, 8:41 AM Alexandra Liosi <liosi.alex@gmail.com> wrote:
Hi Syavash,
Have you tried converting your wall shear stresses files to tecplot or vtk using more quadrature points?
You can use the FieldConvert -n NumberOfPoints option to select the number of quadrature points that you use when converting your fields.
Also, as a sanity check is the polynomial order of your simulation at least one order higher than your mesh? We have seen in other simulations that we have similar artifacts when the polynomial order of the geometry is the same as the polynomial order of the simulation.
Kind regards, Alexandra
On Sat, 13 Apr 2024 at 20:13, Ehsan Asgari <eh.asgari@gmail.com> wrote:
The title is "Pressure drag reduction via imposition of spanwise wall oscillations on a rough wall" by Deshpande et al. JFM 2024. In Fig. 3 of the named paper you may see Reynolds shear stress contours.
Kind regards syavash
On Sat, Apr 13, 2024 at 2:46 PM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Which JFM paper was it you mentioned?
Cheers,
Spener.
*From: *Syavash Asgari <s.airyaman@gmail.com> *Date: *Wednesday, 10 April 2024 at 17:56 *To: *Sherwin, Spencer J <s.sherwin@imperial.ac.uk> *Cc: *Ehsan Asgari <eh.asgari@gmail.com>, nektar-users < nektar-users@imperial.ac.uk> *Subject: *Re: [Nektar-users] unphysical wiggles in Reynolds stress
Hi Spencer
Thank you so much for the elaboration.
I had some speculation that it has something to do with the projection into local space.
At least I know it's not a problem with my setup.
In a recent paper published in JFM, the authors showed very smooth contours of Reynolds stresses. I wonder how they managed to do it since their mesh was quite coarse.
I hope that this issue will be addressed in an upcoming update!
Kind regards
syavash
On Wed, Apr 10, 2024, 12:20 PM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Syavash,
This does seem to have been a problem for a while. What I believe is going on is that we construct the Reynolds stresses (which is a square of the velocity) at the elemental level and then do a local projection to the coefficient space which would likely lead to jumps at element interfaces that is evident in your images. We are also in this case taking a non-linear product and then projecting it down to the original polynomial space which could mean we have aliasing.
So ideally what we perhaps should be doing is:
1. After we do a FwdTransLocalElmt() we could do an assemble call (which would add together the coefficients at the interfaces, divide this value by the multiplicity of the degree of freedom and then scatter these values back using a GlobalToLocal() call. In an ideal world we might to a FwdTrans call but this would require the global inverse of the mass matrix so the alternative above is just a cheaper approximation to this. This would require us to calculate the multiplicity (which we do in other parts of the code). 2. Since this is a non-linear projection we should perhaps be dealiasing the (u-u_bar)(u-u_bar) terms. So if dealiasing were turned on then we should be interpolating the (u-u_bar) to a higher set of quadrature points using the PhysInterp1D routines take the products of the (u-u_bar) terms and then use the GalerkinProject1D routine to take them back to the original quadrature points. This is what we do in the non-linear advection terms and this might also help get a better estimate.
Talking to Chi Hin he mentioned that in the past when he has had this problem increasing resolution has sorted it which means the routine is robust when convergence but at higher Re it will be harder to just throw resolution at the problem. So the above modifications might help a lot.
As always not sure when we can get this all implemented and tested but thought I would share my views on what we could do!
Cheers,
Spencer.
*From: *nektar-users-bounces@imperial.ac.uk < nektar-users-bounces@imperial.ac.uk> on behalf of Ehsan Asgari < eh.asgari@gmail.com> *Date: *Wednesday, 10 April 2024 at 01:05 *To: *nektar-users <nektar-users@imperial.ac.uk> *Subject: *[Nektar-users] unphysical wiggles in Reynolds stress
This email from eh.asgari@gmail.com 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.
Dear All,
I hope everyone is all rights!
Once I raised this issue before but I wasn't able to resolve it.
I get unphysical oscillation in Reynolds stress calculated by Nektar++.
The footprints of elements are so much that render the results useless.
Below is an example:
On the contrary, the time-averaged fields are so smooth:
I am using a quite fine mesh with a p-order of 4:
The case is quasi-3D with a homogenous z-direction. I am wondering what can be done to mitigate the spurious oscillations.
Please share your thoughts with me. I appreciate any help you can provide.
Kind regards
syavash
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
participants (4)
-
Alexandra Liosi
-
Ehsan Asgari
-
Sherwin, Spencer J
-
Syavash Asgari