From nek5000-users at lists.mcs.anl.gov Thu May 1 13:40:29 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 1 May 2014 14:40:29 -0400 Subject: [Nek5000-users] Pn-Pn formulation problem with accl_outflow() Message-ID: Hello Nek, I tried to use "accl_outflow()" subroutine for a turbulent outflow in my simulation. I noticed that there is an issue in this subroutine when using Pn-Pn formulation. In fact, the user defined divergence is added to all nodes beyond those of the outflow elements. Similar problem was noticed before as I searched the mailing list (see the following link): https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2010-July/ 000862.html Pn-Pn-2 formulation is not supported in my case in which I use Moab. I wondered if anyone came up with a solution to this issue. Thanks, Mohsen From nek5000-users at lists.mcs.anl.gov Thu May 1 19:51:29 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 2 May 2014 00:51:29 +0000 Subject: [Nek5000-users] Pn-Pn formulation problem with accl_outflow() In-Reply-To: References: Message-ID: Hi Mohsen, I suggest the turb_outflow() subroutine call. The routine is in navier5.f --- You need to declare two arrarys in userchk and then call turb_outflow on each step. subroutine turb_outflow(d,m1,rq,uin) c . Set div U > 0 in elements with 'O ' bc. c c . rq is nominally the ratio of Qout/Qin and is typically 1.5 c c . d and m1 are work arrays of size (lx1,ly1,lz1,lelt), assumed persistant d and m1 should be declared "real" ... A typical call would be: c real m1(lx1,ly1,lz1,lelt),d(lx1,ly1,lz1,lelt) c c uin = 1. ! Default characteristic velocity scale c rq = 1.5 ! Outflow/Inflow ratio c c call turb_outflow(d,m1,rq,uin) ... (without the "c" in the 1st column) Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Thursday, May 01, 2014 1:40 PM To: Nek 5000 Subject: [Nek5000-users] Pn-Pn formulation problem with accl_outflow() Hello Nek, I tried to use "accl_outflow()" subroutine for a turbulent outflow in my simulation. I noticed that there is an issue in this subroutine when using Pn-Pn formulation. In fact, the user defined divergence is added to all nodes beyond those of the outflow elements. Similar problem was noticed before as I searched the mailing list (see the following link): https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2010-July/ 000862.html Pn-Pn-2 formulation is not supported in my case in which I use Moab. I wondered if anyone came up with a solution to this issue. Thanks, Mohsen _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri May 2 09:40:21 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 2 May 2014 10:40:21 -0400 Subject: [Nek5000-users] Pn-Pn formulation problem with accl_outflow() In-Reply-To: References: Message-ID: Hi Paul, Thanks for your reply. I will look into it. Mohsen On 1-May-14, at 8:51 PM, wrote: > Hi Mohsen, > > I suggest the turb_outflow() subroutine call. The routine is in > navier5.f --- > > You need to declare two arrarys in userchk and then call > turb_outflow on each step. > > subroutine turb_outflow(d,m1,rq,uin) > > c . Set div U > 0 in elements with 'O ' bc. > c > c . rq is nominally the ratio of Qout/Qin and is typically 1.5 > c > c . d and m1 are work arrays of size (lx1,ly1,lz1,lelt), > assumed persistant > > d and m1 should be declared "real" ... A typical call would be: > > c real m1(lx1,ly1,lz1,lelt),d(lx1,ly1,lz1,lelt) > c > c uin = 1. ! Default characteristic velocity scale > c rq = 1.5 ! Outflow/Inflow ratio > c > c call turb_outflow(d,m1,rq,uin) > > ... (without the "c" in the 1st column) > > Paul > > > > ________________________________________ > From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users- > bounces at lists.mcs.anl.gov] on behalf of nek5000- > users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] > Sent: Thursday, May 01, 2014 1:40 PM > To: Nek 5000 > Subject: [Nek5000-users] Pn-Pn formulation problem with accl_outflow() > > Hello Nek, > I tried to use "accl_outflow()" subroutine for a turbulent outflow in > my simulation. I noticed that there is an issue in this subroutine > when using Pn-Pn formulation. In fact, the user defined divergence is > added to all nodes beyond those of the outflow elements. Similar > problem was noticed before as I searched the mailing list (see the > following link): > > https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2010-July/ > 000862.html > > Pn-Pn-2 formulation is not supported in my case in which I use Moab. > I wondered if anyone came up with a solution to this issue. > > Thanks, > Mohsen > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Sun May 4 05:23:21 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 04 May 2014 12:23:21 +0200 Subject: [Nek5000-users] Rules of thumb for element aspect ratio limits In-Reply-To: References: Message-ID: Hi Matt, I see that you found a similar approach by manually fixing the GLL points. Do you have experience with the Moab interface in Nek? It seems that the geometry of spectral elements is supported. Then probably, the manual fix in nek could be replaced by the readin of a curved mesh format via moab. What do you think? Florian Am 28.04.2014 12:16, schrieb nek5000-users at lists.mcs.anl.gov: > Hi Wei and Florian, > > In general you can first generate a 2D grid for flow past a wing if it > is a straight wing (of if you represent the 3 dimensionality by a > forcing in the z direction to indicate a fixed sweep angle). This is > not optimal though for a larger problem even if you have periodic > boundary conditions because your dz spacing will be fixed at a small > value by the BL region requirements. > > For DNS of the boundary layer region close to the wing you generally want > dx+~10 > dy+ ~ 0.5 next to the wall, less than dz+ away from the wall > dz+ ~ dx+/2 > > This gives a maximum aspect ratio of about 20 near the wall (dx/dz). > > In the wake / separated flow region you generally want > max(dx,dy,dz)/eta < 4 where eta is the kolmogorov lengthscale. > > The problem is that with a wake calculation such as an airofil you > generally also want the boundaries to be far away. You can do this by > growing dx and dy away from the airfoil. However, you will eventually > reach a point where your aspect ratio is 10-1,000 far away from the > wing as well since dz is small. The problem with doing this is that > when you are far away from the wing then dz will still be very small. > With a structured mesh there appears to be no way to fix this issue > without a multiblock method. For an unstructured mesh there is a > possibility of coarsening more in all 3 directions but this is quite > challenging to generate. > > Also, it is not as simple as just thinking about the maximum value of > (dx,dy,dz) divided by the minimum value of (dx,dy,dz). The relative > ratios of dx,dy,dz all matter and with a wake you generally have > regions where you have all 6 cases of > dx < dy < dz > dx < dz < dy, > dy < dx < dz > dy < dz < dx > dz < dx < dy > dz < dy < dx > > All these areas create problems for an iterative solver. You can write > a more robust / complex solver (such as a semi-coarsening multigrid > algorithm) to handle these different aspect ratio regions but then > much more work is required per iteration. It is a trade-off between # > of iterations required and computing time per iteration. > > For generating the mesh itself. > We have an inhouse generated method based on gridgen-c. > https://code.google.com/p/gridgen-c/ . It is not ideal but it can be > made to work. We also looked into using cubit for unstructured meshes > but we are still testing that. With cubit you can either use moab to > load in the mesh to nek but then you have some limitations. For both > options you can write your own converter as well... we do this for now. > > To curve the boundary layer elements we first generate the element > locations themselves and then the GLL points are created on straight > line segments. We go back in and manually correct the location of the > GLL points located closest to the wall using a spline of the wing. > Then we solve a laplace equation to smooth out the GLL points in the > rest of the domain. > > Matt > > > On Fri, Apr 25, 2014 at 10:17 PM, > wrote: > > Hi matt, > Sorry that I cannot fully answer your question, I know that at > least the smallest edge length in the mesh is a measure for the > stiffness of the full problem, so maybe you should avoid too small > element heights in the boundary layer. > However, I also would like to know how you are generating the > airfoil mesh, since the mesh has to be coarser than a standard > meshes and the boundary layer elements need to have curved > boundaries, no? Which mesh generator you use and how do you > convert the mesh to Nek format? > The 3d problem should boil down to a 2d problem, since I assume > that you want simulate a small part of the wing with periodic > boundary conditions in spanwise direction... But wei, for the 2d > mesh, did you resolve the issue to curve the boundary layer elements? > > Florian > > Am 25.04.2014 um 18:02 schrieb nek5000-users at lists.mcs.anl.gov > : > >> ?HI Matt, >> >> Till now I have no experiments on 3D problem, what I am >> interested in is how you generate the 3D or 2D airfoil mesh for >> nek5000? I spend 2 weeks in generated a 2d airfoil flow mesh >> without any good results. would you like tell me some >> informations? thank you a lot! >> >> Wei >> >> >> 2014-04-25 17:00 GMT+02:00 > >: >> >> Hello, >> >> I am looking to do simulations of flow past a wing in 3D >> using nek5000 and I have been thinking more about potential >> issues with high aspect ratio elements. In general we have >> very fine resolution near the wing and then as we get further >> away the wall normal and wall parallel spacing increases. As >> a first try we will extend the domain in the cross stream >> direction which will result in small dz values. I know that >> in general the best performance is obtained with elements >> having dx=dy=dz and that as the aspect ratio increases the >> performance will degrade. >> >> I'm wondering if there are general rules of thumb for the >> performance degradation with increased aspect ratio. For >> example, is an aspect ratio of 10 ok but an aspect ratio of >> 100 unacceptable? Is this even something we can estimate in >> general or does it vary so much problem to problem that no >> general estimate is possible? >> >> I saw an earlier post that referred to the paper "An >> Overlapping Schwarz Method for Spectral Element Solution of >> the Incompressible Navier-Stokes Equations", P. Fischer JCP >> 1997. From the paper I see two general strategies. >> 1. limit the maximum aspect ratio to a critical value >> 2. design a grid for our case, run it for a short time and >> then iteratively add more grid points to decrease the aspect >> ratio until optimal performance is achieved. >> >> Does anyone have a general or specific suggestion regarding >> how we should handle the grid generation in terms of >> selecting the largest aspect ratio possible with low >> computational cost? >> >> Thanks, >> >> Matt >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- ----------------------------------------------------------------------------- Dipl. Ing. Florian Hindenlang Institut fuer Aerodynamik und Gasdynamik Phone: 0049 (0)711-685 63413 office 1.14 Pfaffenwaldring 21 70569 Stuttgart E-Mail: hindenlang at iag.uni-stuttgart.de --------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 5 02:32:09 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 5 May 2014 09:32:09 +0200 Subject: [Nek5000-users] Rules of thumb for element aspect ratio limits In-Reply-To: References: Message-ID: Hi Florian, Moab does allow you to read meshes made in a variety of formats. We were able to make a mesh in cubit and read it in to nek5000 but we didn't get much further than preliminary tests. I'm not sure how well moab does with the curved mesh format. We never tested that. However there are some limitations with using nek with moab, including that as of now you have to use the PN-PN variant, PN-PN-2 is not supported. Matt On Sun, May 4, 2014 at 12:23 PM, wrote: > Hi Matt, > I see that you found a similar approach by manually fixing the GLL points. > Do you have experience with the Moab interface in Nek? It seems that the > geometry of spectral elements is supported. Then probably, the manual fix > in nek could be replaced by the readin of a curved mesh format via moab. > What do you think? > > Florian > > Am 28.04.2014 12:16, schrieb nek5000-users at lists.mcs.anl.gov: > > Hi Wei and Florian, > > In general you can first generate a 2D grid for flow past a wing if it is > a straight wing (of if you represent the 3 dimensionality by a forcing in > the z direction to indicate a fixed sweep angle). This is not optimal > though for a larger problem even if you have periodic boundary conditions > because your dz spacing will be fixed at a small value by the BL region > requirements. > > For DNS of the boundary layer region close to the wing you generally want > dx+~10 > dy+ ~ 0.5 next to the wall, less than dz+ away from the wall > dz+ ~ dx+/2 > > This gives a maximum aspect ratio of about 20 near the wall (dx/dz). > > In the wake / separated flow region you generally want max(dx,dy,dz)/eta > < 4 where eta is the kolmogorov lengthscale. > > The problem is that with a wake calculation such as an airofil you > generally also want the boundaries to be far away. You can do this by > growing dx and dy away from the airfoil. However, you will eventually reach > a point where your aspect ratio is 10-1,000 far away from the wing as well > since dz is small. The problem with doing this is that when you are far > away from the wing then dz will still be very small. With a structured mesh > there appears to be no way to fix this issue without a multiblock method. > For an unstructured mesh there is a possibility of coarsening more in all 3 > directions but this is quite challenging to generate. > > Also, it is not as simple as just thinking about the maximum value of > (dx,dy,dz) divided by the minimum value of (dx,dy,dz). The relative ratios > of dx,dy,dz all matter and with a wake you generally have regions where you > have all 6 cases of > dx < dy < dz > dx < dz < dy, > dy < dx < dz > dy < dz < dx > dz < dx < dy > dz < dy < dx > > All these areas create problems for an iterative solver. You can write a > more robust / complex solver (such as a semi-coarsening multigrid > algorithm) to handle these different aspect ratio regions but then much > more work is required per iteration. It is a trade-off between # of > iterations required and computing time per iteration. > > For generating the mesh itself. > We have an inhouse generated method based on gridgen-c. > https://code.google.com/p/gridgen-c/ . It is not ideal but it can be made > to work. We also looked into using cubit for unstructured meshes but we are > still testing that. With cubit you can either use moab to load in the mesh > to nek but then you have some limitations. For both options you can write > your own converter as well... we do this for now. > > To curve the boundary layer elements we first generate the element > locations themselves and then the GLL points are created on straight line > segments. We go back in and manually correct the location of the GLL points > located closest to the wall using a spline of the wing. Then we solve a > laplace equation to smooth out the GLL points in the rest of the domain. > > Matt > > > On Fri, Apr 25, 2014 at 10:17 PM, wrote: > >> Hi matt, >> Sorry that I cannot fully answer your question, I know that at least the >> smallest edge length in the mesh is a measure for the stiffness of the >> full problem, so maybe you should avoid too small element heights in the >> boundary layer. >> However, I also would like to know how you are generating the airfoil >> mesh, since the mesh has to be coarser than a standard meshes and the >> boundary layer elements need to have curved boundaries, no? Which mesh >> generator you use and how do you convert the mesh to Nek format? >> The 3d problem should boil down to a 2d problem, since I assume that you >> want simulate a small part of the wing with periodic boundary conditions in >> spanwise direction... But wei, for the 2d mesh, did you resolve the issue >> to curve the boundary layer elements? >> >> Florian >> >> Am 25.04.2014 um 18:02 schrieb nek5000-users at lists.mcs.anl.gov: >> >> ?HI Matt, >> >> Till now I have no experiments on 3D problem, what I am interested in >> is how you generate the 3D or 2D airfoil mesh for nek5000? I spend 2 weeks >> in generated a 2d airfoil flow mesh without any good results. would you >> like tell me some informations? thank you a lot! >> >> Wei >> >> >> 2014-04-25 17:00 GMT+02:00 : >> >>> Hello, >>> >>> I am looking to do simulations of flow past a wing in 3D using nek5000 >>> and I have been thinking more about potential issues with high aspect ratio >>> elements. In general we have very fine resolution near the wing and then as >>> we get further away the wall normal and wall parallel spacing increases. As >>> a first try we will extend the domain in the cross stream direction which >>> will result in small dz values. I know that in general the best performance >>> is obtained with elements having dx=dy=dz and that as the aspect ratio >>> increases the performance will degrade. >>> >>> I'm wondering if there are general rules of thumb for the performance >>> degradation with increased aspect ratio. For example, is an aspect ratio of >>> 10 ok but an aspect ratio of 100 unacceptable? Is this even something we >>> can estimate in general or does it vary so much problem to problem that no >>> general estimate is possible? >>> >>> I saw an earlier post that referred to the paper "An Overlapping >>> Schwarz Method for Spectral Element Solution of the Incompressible >>> Navier-Stokes Equations", P. Fischer JCP 1997. From the paper I see two >>> general strategies. >>> 1. limit the maximum aspect ratio to a critical value >>> 2. design a grid for our case, run it for a short time and then >>> iteratively add more grid points to decrease the aspect ratio until optimal >>> performance is achieved. >>> >>> Does anyone have a general or specific suggestion regarding how we >>> should handle the grid generation in terms of selecting the largest aspect >>> ratio possible with low computational cost? >>> >>> Thanks, >>> >>> Matt >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> > > > _______________________________________________ > Nek5000-users mailing listNek5000-users at lists.mcs.anl.govhttps://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > -- > ----------------------------------------------------------------------------- > Dipl. Ing. Florian Hindenlang > Institut fuer Aerodynamik und Gasdynamik > Phone: 0049 (0)711-685 63413 > office 1.14 > Pfaffenwaldring 21 > 70569 Stuttgart > E-Mail: hindenlang at iag.uni-stuttgart.de > --------------------------------------------------------------------------- > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 7 10:39:24 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 May 2014 15:39:24 +0000 Subject: [Nek5000-users] Rules of thumb for element aspect ratio limits In-Reply-To: References: , Message-ID: Hi Matt, Our strategy with getting meshes from MOAB to Nek so far has been to run one case with N=2 (lx1=3) in Pn-Pn and call gen_rea(2) from usrdat2() which outpost the mesh and BC portion of .rea file in newrea.out Aleks ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Monday, May 05, 2014 2:32 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Rules of thumb for element aspect ratio limits Hi Florian, Moab does allow you to read meshes made in a variety of formats. We were able to make a mesh in cubit and read it in to nek5000 but we didn't get much further than preliminary tests. I'm not sure how well moab does with the curved mesh format. We never tested that. However there are some limitations with using nek with moab, including that as of now you have to use the PN-PN variant, PN-PN-2 is not supported. Matt On Sun, May 4, 2014 at 12:23 PM, > wrote: Hi Matt, I see that you found a similar approach by manually fixing the GLL points. Do you have experience with the Moab interface in Nek? It seems that the geometry of spectral elements is supported. Then probably, the manual fix in nek could be replaced by the readin of a curved mesh format via moab. What do you think? Florian Am 28.04.2014 12:16, schrieb nek5000-users at lists.mcs.anl.gov: Hi Wei and Florian, In general you can first generate a 2D grid for flow past a wing if it is a straight wing (of if you represent the 3 dimensionality by a forcing in the z direction to indicate a fixed sweep angle). This is not optimal though for a larger problem even if you have periodic boundary conditions because your dz spacing will be fixed at a small value by the BL region requirements. For DNS of the boundary layer region close to the wing you generally want dx+~10 dy+ ~ 0.5 next to the wall, less than dz+ away from the wall dz+ ~ dx+/2 This gives a maximum aspect ratio of about 20 near the wall (dx/dz). In the wake / separated flow region you generally want max(dx,dy,dz)/eta < 4 where eta is the kolmogorov lengthscale. The problem is that with a wake calculation such as an airofil you generally also want the boundaries to be far away. You can do this by growing dx and dy away from the airfoil. However, you will eventually reach a point where your aspect ratio is 10-1,000 far away from the wing as well since dz is small. The problem with doing this is that when you are far away from the wing then dz will still be very small. With a structured mesh there appears to be no way to fix this issue without a multiblock method. For an unstructured mesh there is a possibility of coarsening more in all 3 directions but this is quite challenging to generate. Also, it is not as simple as just thinking about the maximum value of (dx,dy,dz) divided by the minimum value of (dx,dy,dz). The relative ratios of dx,dy,dz all matter and with a wake you generally have regions where you have all 6 cases of dx < dy < dz dx < dz < dy, dy < dx < dz dy < dz < dx dz < dx < dy dz < dy < dx All these areas create problems for an iterative solver. You can write a more robust / complex solver (such as a semi-coarsening multigrid algorithm) to handle these different aspect ratio regions but then much more work is required per iteration. It is a trade-off between # of iterations required and computing time per iteration. For generating the mesh itself. We have an inhouse generated method based on gridgen-c. https://code.google.com/p/gridgen-c/ . It is not ideal but it can be made to work. We also looked into using cubit for unstructured meshes but we are still testing that. With cubit you can either use moab to load in the mesh to nek but then you have some limitations. For both options you can write your own converter as well... we do this for now. To curve the boundary layer elements we first generate the element locations themselves and then the GLL points are created on straight line segments. We go back in and manually correct the location of the GLL points located closest to the wall using a spline of the wing. Then we solve a laplace equation to smooth out the GLL points in the rest of the domain. Matt On Fri, Apr 25, 2014 at 10:17 PM, > wrote: Hi matt, Sorry that I cannot fully answer your question, I know that at least the smallest edge length in the mesh is a measure for the stiffness of the full problem, so maybe you should avoid too small element heights in the boundary layer. However, I also would like to know how you are generating the airfoil mesh, since the mesh has to be coarser than a standard meshes and the boundary layer elements need to have curved boundaries, no? Which mesh generator you use and how do you convert the mesh to Nek format? The 3d problem should boil down to a 2d problem, since I assume that you want simulate a small part of the wing with periodic boundary conditions in spanwise direction... But wei, for the 2d mesh, did you resolve the issue to curve the boundary layer elements? Florian Am 25.04.2014 um 18:02 schrieb nek5000-users at lists.mcs.anl.gov: ?HI Matt, Till now I have no experiments on 3D problem, what I am interested in is how you generate the 3D or 2D airfoil mesh for nek5000? I spend 2 weeks in generated a 2d airfoil flow mesh without any good results. would you like tell me some informations? thank you a lot! Wei 2014-04-25 17:00 GMT+02:00 >: Hello, I am looking to do simulations of flow past a wing in 3D using nek5000 and I have been thinking more about potential issues with high aspect ratio elements. In general we have very fine resolution near the wing and then as we get further away the wall normal and wall parallel spacing increases. As a first try we will extend the domain in the cross stream direction which will result in small dz values. I know that in general the best performance is obtained with elements having dx=dy=dz and that as the aspect ratio increases the performance will degrade. I'm wondering if there are general rules of thumb for the performance degradation with increased aspect ratio. For example, is an aspect ratio of 10 ok but an aspect ratio of 100 unacceptable? Is this even something we can estimate in general or does it vary so much problem to problem that no general estimate is possible? I saw an earlier post that referred to the paper "An Overlapping Schwarz Method for Spectral Element Solution of the Incompressible Navier-Stokes Equations", P. Fischer JCP 1997. From the paper I see two general strategies. 1. limit the maximum aspect ratio to a critical value 2. design a grid for our case, run it for a short time and then iteratively add more grid points to decrease the aspect ratio until optimal performance is achieved. Does anyone have a general or specific suggestion regarding how we should handle the grid generation in terms of selecting the largest aspect ratio possible with low computational cost? Thanks, Matt _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- ----------------------------------------------------------------------------- Dipl. Ing. Florian Hindenlang Institut fuer Aerodynamik und Gasdynamik Phone: 0049 (0)711-685 63413 office 1.14 Pfaffenwaldring 21 70569 Stuttgart E-Mail: hindenlang at iag.uni-stuttgart.de --------------------------------------------------------------------------- _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri May 9 03:36:08 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 09 May 2014 09:36:08 +0100 Subject: [Nek5000-users] Compiling the First 2D Example in a Cray machine using the Cray compiler Message-ID: Hi Neks, I am trying to build Nek5000 for the first time and I am doing it in a Cray machine using the Cray compiler. So, after changing *ftn*) P="-r8 -Mpreprocess -fast" by *ftn*) P="-ra -s real64 -eZ -em -rm " in makenek.inc I have tried to build this first example: makenek eddy_uv Unfortunately I am getting an error : ftn-1295 crayftn: ERROR MFI_PREPARE, File = ../../../work/z01/z01/lcebaman/nek5000/nek5_svn/trunk/nek/ic.f, Line = 2676, Column = 13 "MFI_PARSE_HDR" is defined or referenced at line 2281 (/work/z01/z01/lcebaman/nek5000/nek5_svn/trunk/nek/ic.f) and here. The number of arguments do not match. Expected 2, but found 1. make: *** [obj/ic.o] Error 1 make: *** Waiting for unfinished jobs... and I was wondering if someone has experience something similar in the past so I could get some hints of how to proceed here. I would appreciate any ideas. Best regards, Luis -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From nek5000-users at lists.mcs.anl.gov Fri May 9 06:46:15 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 May 2014 11:46:15 +0000 Subject: [Nek5000-users] Compiling the First 2D Example in a Cray machine using the Cray compiler In-Reply-To: References: Message-ID: Hi Luis, Thanks for bringing this to our attention. In fact, the change in argument list was overlooked in a couple of places and this was a bug. I've just updated the repo, so if you rm ic.f and postpro.f, then svn update these files you should be good to go. Best, Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Friday, May 09, 2014 3:36 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Compiling the First 2D Example in a Cray machine using the Cray compiler Hi Neks, I am trying to build Nek5000 for the first time and I am doing it in a Cray machine using the Cray compiler. So, after changing *ftn*) P="-r8 -Mpreprocess -fast" by *ftn*) P="-ra -s real64 -eZ -em -rm " in makenek.inc I have tried to build this first example: makenek eddy_uv Unfortunately I am getting an error : ftn-1295 crayftn: ERROR MFI_PREPARE, File = ../../../work/z01/z01/lcebaman/nek5000/nek5_svn/trunk/nek/ic.f, Line = 2676, Column = 13 "MFI_PARSE_HDR" is defined or referenced at line 2281 (/work/z01/z01/lcebaman/nek5000/nek5_svn/trunk/nek/ic.f) and here. The number of arguments do not match. Expected 2, but found 1. make: *** [obj/ic.o] Error 1 make: *** Waiting for unfinished jobs... and I was wondering if someone has experience something similar in the past so I could get some hints of how to proceed here. I would appreciate any ideas. Best regards, Luis -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri May 9 07:44:55 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 09 May 2014 13:44:55 +0100 Subject: [Nek5000-users] Compiling the First 2D Example in a Cray machine using the Cray compiler In-Reply-To: References: Message-ID: Hi Paul, Thanks for doing so, that error is now gone and I get the next one: C -c -O2 -DPTRSIZE8 -DMPI -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /work/z01/z01/lcebaman/nek5000/nek5_svn/trunk/nek/nek_comm.c -o obj/nek_comm.o CC-35 crayc++: ERROR File = /opt/cray/mpt/6.3.1/gni/mpich2-cray/81/include/mpicxx.h, Line = 12 #error directive: "You cannot define MPI; that name is reserved for the MPI namespace" #error "You cannot define MPI; that name is reserved for the MPI namespace" make: *** [obj/nek_comm.o] Error 1 make: *** Waiting for unfinished jobs.... On 09/05/14 12:46, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Luis, > > Thanks for bringing this to our attention. > > In fact, the change in argument list was overlooked in a couple of places > and this was a bug. > > I've just updated the repo, so if you rm ic.f and postpro.f, then svn update > these files you should be good to go. > > Best, > > Paul > > ________________________________________ > From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] > Sent: Friday, May 09, 2014 3:36 AM > To: nek5000-users at lists.mcs.anl.gov > Subject: [Nek5000-users] Compiling the First 2D Example in a Cray machine using the Cray compiler > > Hi Neks, > > I am trying to build Nek5000 for the first time and I am doing it in a > Cray machine using the Cray compiler. So, after changing > > *ftn*) P="-r8 -Mpreprocess -fast" by *ftn*) P="-ra -s > real64 -eZ -em -rm " in makenek.inc I have tried to build this first > example: > > makenek eddy_uv > > Unfortunately I am getting an error : > > ftn-1295 crayftn: ERROR MFI_PREPARE, File = > ../../../work/z01/z01/lcebaman/nek5000/nek5_svn/trunk/nek/ic.f, Line = > 2676, Column = 13 > "MFI_PARSE_HDR" is defined or referenced at line 2281 > (/work/z01/z01/lcebaman/nek5000/nek5_svn/trunk/nek/ic.f) and here. The > number of arguments do not match. Expected 2, but found 1. > > make: *** [obj/ic.o] Error 1 > make: *** Waiting for unfinished jobs... > > > and I was wondering if someone has experience something similar in the > past so I could get some hints of how to proceed here. > > I would appreciate any ideas. > > Best regards, > > Luis > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From nek5000-users at lists.mcs.anl.gov Fri May 9 08:25:52 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 May 2014 15:25:52 +0200 Subject: [Nek5000-users] Implementing magnetic boundary conditions Message-ID: Hi everyone, I am currently trying to implement the quasi vacuum boundary conditions (n x B=0) for an ellipsoidal shell. My understanding from earlier threads is that I can only set Bx=By=dBz/dz=0 via the string ?ddn? , restricting me to boundaries orthogonal to the cartesian axis. Has anyone tried some workarounds to this problem? And are the same restrictions applying to the flux boundary conditions of the add. scalars? If not, it might be possible to use 3 additional passive scalars to model the magnetic field (instead of the standard implementation). Or, as another idea, is it possible to use something like the conjugate heat transfer implementation for the magnetic field: Having some larger Elements on the outside with u=0, where only laplace B=0 is solved. My current approach, which is not working yet, is to transfer the boundary conditions to Dirichlet conditions via an interpolation algorithm, but this seems a bit dubious to me, both from a numerical and a physical perspective. Any suggestions would be appreciated. Best regards, Jan From nek5000-users at lists.mcs.anl.gov Fri May 9 13:24:56 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 May 2014 18:24:56 +0000 Subject: [Nek5000-users] Implementing magnetic boundary conditions In-Reply-To: References: Message-ID: Hi Jan, Excellent questions and we have thought of implementing MHD in a two-domain manner similar to conjugate heat transfer approach but we are currently tied up with other projects. Let us discuss your questions offline -- my email is obabko at mcs.anl.gov Aleks ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Friday, May 09, 2014 8:25 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Implementing magnetic boundary conditions Hi everyone, I am currently trying to implement the quasi vacuum boundary conditions (n x B=0) for an ellipsoidal shell. My understanding from earlier threads is that I can only set Bx=By=dBz/dz=0 via the string ?ddn? , restricting me to boundaries orthogonal to the cartesian axis. Has anyone tried some workarounds to this problem? And are the same restrictions applying to the flux boundary conditions of the add. scalars? If not, it might be possible to use 3 additional passive scalars to model the magnetic field (instead of the standard implementation). Or, as another idea, is it possible to use something like the conjugate heat transfer implementation for the magnetic field: Having some larger Elements on the outside with u=0, where only laplace B=0 is solved. My current approach, which is not working yet, is to transfer the boundary conditions to Dirichlet conditions via an interpolation algorithm, but this seems a bit dubious to me, both from a numerical and a physical perspective. Any suggestions would be appreciated. Best regards, Jan _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue May 13 10:23:53 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 May 2014 16:23:53 +0100 Subject: [Nek5000-users] eddy_uv: Error in generalev Message-ID: Hi all, I have run the first Nek5000 example [Nek5000 total beginner] using MPI with 4 processors. Nek5000 seems to run, however I get this runtime error: $grep -i err logfile | tail Error in generalev, info= 14, 8, -6 Error in generalev, info= 14, 8, -6 Error in generalev, info= 14, 8, -6 Error in generalev, info= 14, 8, -6 I have not modified SIZE or any other files. I just run it as it is from the svn. Any ideas of what can be causing that error? Have you ever seen that before? Cheers, -- Luis The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From nek5000-users at lists.mcs.anl.gov Tue May 13 12:10:00 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 May 2014 17:10:00 +0000 Subject: [Nek5000-users] Nek5000-users Digest, Vol 63, Issue 7 In-Reply-To: References: Message-ID: Hi Luis, The error is related to a bug in the cray cce compiler that I reported one year ago. It seems that they still did not fix the issue in the new release. Regards, Jing Gong /PDC, KTH ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users-request at lists.mcs.anl.gov [nek5000-users-request at lists.mcs.anl.gov] Sent: Tuesday, May 13, 2014 19:00 To: nek5000-users at lists.mcs.anl.gov Subject: Nek5000-users Digest, Vol 63, Issue 7 Send Nek5000-users mailing list submissions to nek5000-users at lists.mcs.anl.gov To subscribe or unsubscribe via the World Wide Web, visit https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users or, via email, send a message with subject or body 'help' to nek5000-users-request at lists.mcs.anl.gov You can reach the person managing the list at nek5000-users-owner at lists.mcs.anl.gov When replying, please edit your Subject line so it is more specific than "Re: Contents of Nek5000-users digest..." Today's Topics: 1. eddy_uv: Error in generalev (nek5000-users at lists.mcs.anl.gov) ---------------------------------------------------------------------- Message: 1 Date: Tue, 13 May 2014 16:23:53 +0100 From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] eddy_uv: Error in generalev Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have run the first Nek5000 example [Nek5000 total beginner] using MPI with 4 processors. Nek5000 seems to run, however I get this runtime error: $grep -i err logfile | tail Error in generalev, info= 14, 8, -6 Error in generalev, info= 14, 8, -6 Error in generalev, info= 14, 8, -6 Error in generalev, info= 14, 8, -6 I have not modified SIZE or any other files. I just run it as it is from the svn. Any ideas of what can be causing that error? Have you ever seen that before? Cheers, -- Luis The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ------------------------------ _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users End of Nek5000-users Digest, Vol 63, Issue 7 ******************************************** From nek5000-users at lists.mcs.anl.gov Thu May 15 03:19:18 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 May 2014 10:19:18 +0200 Subject: [Nek5000-users] Computing a slice Message-ID: Hello Neks, I would like to know If there is a sub-routine which will help me to make a slice in x-y plane. I am planning to compute the integral of the velocity distribution for finding the centroid. Thanks in advance, Kamal. From nek5000-users at lists.mcs.anl.gov Thu May 15 08:55:27 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 May 2014 13:55:27 +0000 Subject: [Nek5000-users] Computing a slice In-Reply-To: References: Message-ID: Hi Kamal, In the hemi example there is a routine subroutine interp_v(uvw,xyz,n) that will interpolate the velocity at an arbitrary set of points. You could use that to interrogate your planar slice. An example calling sequence from userchk (say) would be: common /myjunk/ uvw(ldim,2),xyz(ldim,2) if (nid.eq.0) then ! load points on node 0 n=2 xyz(1,1) = 5. ! x_1 xyz(2,1) = 0. ! y_1 xyz(3,1) = 0. ! z_1 xyz(1,2) = 0. ! x_2 xyz(2,2) = 5. ! y_2 xyz(3,2) = 0. ! z_2 else n=0 endif call interp_v(uvw,xyz,n) ! All nodes must call this routine Note that you can also have other processors supply points but it is detrimental to have multiple processors supply the _same_ interpolation points. The following example would be disastrous on anything over 1000 processors: xyz(1,1) = 5. ! x_1 xyz(2,1) = 0. ! y_1 xyz(3,1) = 0. ! z_1 xyz(1,2) = 0. ! x_2 xyz(2,2) = 5. ! y_2 xyz(3,2) = 0. ! z_2 n=2 ! BAD EXAMPLE call interp_v(uvw,xyz,n) ! BAD EXAMPLE This, however, is OK n=2 if (nid.gt.0) n=0 ! Good example call interp_v(uvw,xyz,n) ! Good example If your list is really long (i.e., > 10000, say) then it's potentially worthwhile to split the points specification across processors. Again, that depends on the calling frequency, etc. Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Thursday, May 15, 2014 3:19 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Computing a slice Hello Neks, I would like to know If there is a sub-routine which will help me to make a slice in x-y plane. I am planning to compute the integral of the velocity distribution for finding the centroid. Thanks in advance, Kamal. _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri May 16 21:45:27 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 16 May 2014 22:45:27 -0400 Subject: [Nek5000-users] Initial condition problem Message-ID: Hi, Neks I want to start Nek5000 from an initial condition in Cartesian coordinate which is from other software so it is not fld format. What I need to do to transform my initial condition to fld format. Mu Xu -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 19 13:42:59 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 May 2014 20:42:59 +0200 Subject: [Nek5000-users] merging two meshes Message-ID: Dear neks I am trying to merge two meshes as in ext_cyl example. Do the two meshes have to have matching grid lines for the merge to work ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 19 14:10:12 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 May 2014 21:10:12 +0200 Subject: [Nek5000-users] merging two meshes In-Reply-To: References: Message-ID: Yes, you should have matching grid lines. Zhenlan On Mon, May 19, 2014 at 8:42 PM, wrote: > Dear neks > I am trying to merge two meshes as in ext_cyl example. Do the two meshes > have to have matching grid lines for the merge to work ? > Thanks > praveen > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- Universit? Pierre et Marie Curie CNRS-LIMSI Campus d'Orsay 91403 ORSAY -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 20 07:11:45 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 May 2014 14:11:45 +0200 Subject: [Nek5000-users] merging two meshes In-Reply-To: References: Message-ID: On Mon, May 19, 2014 at 9:10 PM, wrote: > Yes, you should have matching grid lines. > > Zhenlan > Thank you. I am trying to merge a cylinder mesh with a box mesh. E.g., my cylinder is defined like this import.rea 2 1 Y 5 -32 1 0.25 0.20 cccobb 0.05 0.055 0.06 0.07 0.08 0.1 0 1 1 v ,E ,E ,E , I am getting only circles and boxes. The specification "o" does not seem to do anything. What is the meaning of "o" ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 20 07:40:04 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 May 2014 14:40:04 +0200 Subject: [Nek5000-users] merging two meshes In-Reply-To: References: Message-ID: try my scripts attached here I do not think it is a O, it is a zero, see the user guide, it is explained there about prex. Cheers On Tue, May 20, 2014 at 2:11 PM, wrote: > > On Mon, May 19, 2014 at 9:10 PM, wrote: > >> Yes, you should have matching grid lines. >> >> Zhenlan >> > > Thank you. > > I am trying to merge a cylinder mesh with a box mesh. E.g., my cylinder is > defined like this > > import.rea > > 2 > > 1 > > Y > > 5 -32 1 > > 0.25 0.20 > > cccobb > > 0.05 0.055 0.06 0.07 0.08 0.1 > > 0 1 1 > > v ,E ,E ,E , > > I am getting only circles and boxes. The specification "o" does not seem > to do anything. What is the meaning of "o" ? > > Thanks > praveen > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: box7.2d Type: application/octet-stream Size: 450 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mkmesh Type: application/octet-stream Size: 655 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fpcyl.box Type: application/octet-stream Size: 1216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: base.rea Type: application/octet-stream Size: 6854 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Tue May 20 07:57:45 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 May 2014 14:57:45 +0200 Subject: [Nek5000-users] merging two meshes In-Reply-To: References: Message-ID: On Tue, May 20, 2014 at 2:40 PM, wrote: > try my scripts attached here > > I do not think it is a O, it is a zero, see the user guide, it is > explained there about prex. > > Cheers > Thank you. Your box7.2d file has ccccoob and it gives 6 circles and one box. The "o" seems to generate a circle. praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 20 07:58:57 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 May 2014 14:58:57 +0200 Subject: [Nek5000-users] merging two meshes In-Reply-To: References: Message-ID: o should give a polygone but it turns out to be a circle in my case. On Tue, May 20, 2014 at 2:57 PM, wrote: > > On Tue, May 20, 2014 at 2:40 PM, wrote: > >> try my scripts attached here >> >> I do not think it is a O, it is a zero, see the user guide, it is >> explained there about prex. >> >> Cheers >> > > Thank you. Your box7.2d file has > > ccccoob > > and it gives 6 circles and one box. The "o" seems to generate a circle. > > praveen > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 20 08:09:53 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 May 2014 15:09:53 +0200 Subject: [Nek5000-users] merging two meshes In-Reply-To: References: Message-ID: On Tue, May 20, 2014 at 2:58 PM, wrote: > o should give a polygone > but it turns out to be a circle in my case. yes, "o" gives a circle. The transition from "c" to "b" is too drastic at the corners of the box; Adjacent element sizes are very different. How can I make it smoother ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 21 09:50:54 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 May 2014 16:50:54 +0200 Subject: [Nek5000-users] Regarding Resolution Message-ID: Hello Neks, I am running simulation on expansion pipe with perturbation at inlet. with normal mesh of 14000 elements I find turbulence that stays forever inside the pipe at Re = 2000 and it quiet matches with previous articles and numerical study. When I tried to increase the resolution by 25000 elements for the same parameter the turbulence decayed completely and the flow became steady. Even when I increase the polynomial order from N=5 to N=7 the turbulence decays down completely. Could some tell me why I couldn't reproduce the result on a higher mesh resolution ?? Thanks in advance. Best, Kamal From nek5000-users at lists.mcs.anl.gov Wed May 21 13:11:53 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 May 2014 13:11:53 -0500 (CDT) Subject: [Nek5000-users] Nek5000 Users Meeting, Aug. 21-22, Thessaloniki, Greece Message-ID: We are pleased to invite you to attend the third Nek5000 User and Development Meeting, to be hosted by the University of Western Macedonia at the Aristotle University Conference Center in Thessaloniki, Greece, August 21-22, 2014. The registration site is now up on the meeting homepage: http://nek5000meeting.web.uowm.gr/ Registration is open until June 30 but please register as soon as possible; there are several optional events that we hope will be of interest to all. Description: The objective of the meeting is to bring developers and users of Nek5000 together to promote collaborative activities, exchange information, and share experiences in using Nek5000 in areas of common interest. The schedule is under development, but we are planning to have technical sessions on Thursday, August. 21 and Friday, August 22, including hands-on sessions in the use of Nek5000 and VisIt. One objective of the meeting is to assist users in defining their simulation problems and to address technical issues that they may face. Attendees are invited to contribute short (15 min.) presentations on their applications of Nek5000. Contributions should consist of an abstract (1-2 pages) and presentation slides. We look forward to your attendance! Sincerely, Nek5000 Development Team From nek5000-users at lists.mcs.anl.gov Wed May 21 11:30:47 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 May 2014 18:30:47 +0200 Subject: [Nek5000-users] Natural convection, parameters BETAG, GTHETA Message-ID: Dear all, we would like to simulate natural convection using the Boussinesq approximation. In the example rayleigh the buoyancy force is implemented in userf, however there are the parameters BETAG and GTHETA, which appear not to be used. Is there any reason for that? Regards, clio From nek5000-users at lists.mcs.anl.gov Wed May 21 18:53:38 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 May 2014 23:53:38 +0000 Subject: [Nek5000-users] Natural convection, parameters BETAG, GTHETA In-Reply-To: References: Message-ID: Dear Clio, We dropped betag and gtheta because they didn't provide sufficient flexibility. They still exist in the .rea files but are not used in the code. Best regards, Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 21, 2014 11:30 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Natural convection, parameters BETAG, GTHETA Dear all, we would like to simulate natural convection using the Boussinesq approximation. In the example rayleigh the buoyancy force is implemented in userf, however there are the parameters BETAG and GTHETA, which appear not to be used. Is there any reason for that? Regards, clio _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu May 22 09:11:45 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 May 2014 14:11:45 +0000 Subject: [Nek5000-users] CVODE and IOFS Message-ID: Dear nek5000 team, I have set-up a test case that consist of a free convection of a 2D vortex in a periodic domain. In the initial condition, I have put a line of passive scalars superimposed onto the vortex. If I use the standard solver for temperature and PS (p16 = 0 or 1), everything works fine. My vortex is convected and the line of passive scalars is distorted by the vortex and diffused progressivly. It works well even with IFCHAR= T or F. Perfect. However when I switch to the CVODE solver (p16 = 3) for time integration of temperature and PS, it works only with IFCHAR=F. When IFCHAR is T, my line of passive scalars is not convected by the flow and doesn?t interact with the vortex. Only the progressive diffusion is taken into account. A quick look at the routine makeq.f confirms this behaviour. If IFCHAR is F, the routine convab is called to compute the convective operator, and then the diffusion operator is computed with the call of the routine wlapacian. If IFCHAR is T, only this latter diffusion part is computed. In that case I didn?t find where the convection part is computed. It seems that it is missing. My question is just: is this normal? Why only the diffusion operator is computed when CVODE and IOFS are used together? Is it a bug? Am I missing something in the theory? Than you in advance for your explanations ! Best regards, Emmanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 22 21:55:35 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 May 2014 02:55:35 +0000 Subject: [Nek5000-users] CVODE and IOFS In-Reply-To: References: Message-ID: Dear nek5000 team, I have modified the makeq.f routine to include the line ?call convab? into the condition ?ifcvode?, just before "call wlaplacian?". According to the test I performed with my vortex convection case as well as the ?lowMach_test? case from the example directory of nek, now it seems to works as it should. I get the same results as with no-CVODE, or CVODE without the characteristic method. If I am right, with that change, now convective and diffusive terms of heat and scalar equations are solved within CVODE, while the velocity in the hydrodynamic system is computed with the characteristic method (OIFS, sorry for the mistake in my previous email). Could you confirm me that it is an appropriate fix for the problem (supposing it was initially a bug)? Thank you for your help! Best regards, Emmanuel On 22 May 2014, at 23:41, nek5000-users at lists.mcs.anl.gov wrote: Dear nek5000 team, I have set-up a test case that consist of a free convection of a 2D vortex in a periodic domain. In the initial condition, I have put a line of passive scalars superimposed onto the vortex. If I use the standard solver for temperature and PS (p16 = 0 or 1), everything works fine. My vortex is convected and the line of passive scalars is distorted by the vortex and diffused progressivly. It works well even with IFCHAR= T or F. Perfect. However when I switch to the CVODE solver (p16 = 3) for time integration of temperature and PS, it works only with IFCHAR=F. When IFCHAR is T, my line of passive scalars is not convected by the flow and doesn?t interact with the vortex. Only the progressive diffusion is taken into account. A quick look at the routine makeq.f confirms this behaviour. If IFCHAR is F, the routine convab is called to compute the convective operator, and then the diffusion operator is computed with the call of the routine wlapacian. If IFCHAR is T, only this latter diffusion part is computed. In that case I didn?t find where the convection part is computed. It seems that it is missing. My question is just: is this normal? Why only the diffusion operator is computed when CVODE and IOFS are used together? Is it a bug? Am I missing something in the theory? Than you in advance for your explanations ! Best regards, Emmanuel _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 24 01:11:45 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 24 May 2014 08:11:45 +0200 Subject: [Nek5000-users] Solving linearized Navier-Stokes Message-ID: Dear neks I want to solve linearized NS about a stationary base flow. Is there an example I can learn from to setup such a simulation ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 26 16:39:06 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 May 2014 17:39:06 -0400 Subject: [Nek5000-users] Object definition for surface integrals Message-ID: Dean NEK Users, I am looking for some sort of help or documentation explaining the object definitions for evaluating surface integrals. My eventual application will be to evaluate the drag and lift forces for the case of a 2D flow past a cylinder, supported on elastic foundation, i.e., vortex-induced vibration simulations using NEK5000. So far, the examples available in the repository and the NEK mailing list have enabled me to simulate the motionless cylinder and the case of cylinder moving with a prescribed motion. However, I have hard time decoding the surface integral evaluation in subroutine "set_obj" available in the "ext_cyl.usr". Overall, I understand that there is a conditional statement to find all the elements (or element edges) with "W" boundary condition and then an object is created for each of those elements. It would be very helpful is someone could point me to a documentation/help, which gives an explanation for the following functions or variables which have been used in the "set_obj" subroutine. 1. variable "hcode" 2. variable "lochis" 3. variable "nhis" 4. function or variable "cbc" 5. variable "nmember" 6. function or variable "object" Any hints to understand this subroutine "set_obj" of the example model "ext_cyl" would be of great help for me to understand and develop the model for vortex-induced vibration. In addition, if there is already an example model to perform vortex-induced vibration, please let me know. Thanks in advance. Any hints and tips are much appreciated. Regards, Ravi -- Ravi Kumar T R University of Illinois at Urbana-Champaign ph : +1 217 778 7538 http://lndvl.mechse.illinois.edu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 26 16:59:02 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 May 2014 21:59:02 +0000 Subject: [Nek5000-users] Object definition for surface integrals In-Reply-To: References: Message-ID: Hi Ravi, Inspection of the source routine navier5.f will reveal most of the answers to your questions. That is where drag and torque are calculated. (I recommend torque_calc, which gives the drag as well and is somewhat superior to drag_calc.) hcode = history code --- there are several codes used (the convention follows the Nekton 2.0 convention established in the 80s). Of relevance to drag/lift/torque are hcode(10,.), which must be 'I' for Integral quantity, and 1,2,3, which must be 'F' for force. Just follow the convention in the ext_cyl.usr example. Note that the 2nd argument of hcode indicates how many objects you have. An Object is a collection of faces. So, you might have more than one cylinder on which to compute drag, in which case you would have more than one object. Each object comprises "nmember(iobj)" faces. nhis is the number of history elements you are tracking. It is normally zero, plus the number of objects. It is a measure of the number of lines of information dumped to the .sch file per timestep. cbc is the character array holding the boundary condition specifier - one per face per field (velocity, temperature, etc.) object is a pointer to the members of an object. A member of an object is a given face (1-6) of a given element. The element id is global -- (i.e., not the local element number which is specific to a given mpi rank). Paul ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Monday, May 26, 2014 4:39 PM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Object definition for surface integrals Dean NEK Users, I am looking for some sort of help or documentation explaining the object definitions for evaluating surface integrals. My eventual application will be to evaluate the drag and lift forces for the case of a 2D flow past a cylinder, supported on elastic foundation, i.e., vortex-induced vibration simulations using NEK5000. So far, the examples available in the repository and the NEK mailing list have enabled me to simulate the motionless cylinder and the case of cylinder moving with a prescribed motion. However, I have hard time decoding the surface integral evaluation in subroutine "set_obj" available in the "ext_cyl.usr". Overall, I understand that there is a conditional statement to find all the elements (or element edges) with "W" boundary condition and then an object is created for each of those elements. It would be very helpful is someone could point me to a documentation/help, which gives an explanation for the following functions or variables which have been used in the "set_obj" subroutine. 1. variable "hcode" 2. variable "lochis" 3. variable "nhis" 4. function or variable "cbc" 5. variable "nmember" 6. function or variable "object" Any hints to understand this subroutine "set_obj" of the example model "ext_cyl" would be of great help for me to understand and develop the model for vortex-induced vibration. In addition, if there is already an example model to perform vortex-induced vibration, please let me know. Thanks in advance. Any hints and tips are much appreciated. Regards, Ravi -- Ravi Kumar T R University of Illinois at Urbana-Champaign ph : +1 217 778 7538 http://lndvl.mechse.illinois.edu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 27 09:01:44 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 16:01:44 +0200 Subject: [Nek5000-users] Outflow bc and pressure Message-ID: Dear neks When we specify a boundary as outflow "O", I thought we take the normal stress to be zero -p*n + mu*(grad(u) + grad(u)^T)*n = 0 which is a natural boundary condition and where n = normal vector. But it seems that nek sets p=0 on the outflow boundary. So does this mean we on outflow boundary we take both normal stress to be zero and pressure to be zero ? Is it possible to use the normal stress condition without specifying a pressure ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 27 10:43:48 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 15:43:48 +0000 Subject: [Nek5000-users] Outflow bc and pressure In-Reply-To: References: Message-ID: Hi Praveen, For Pn-Pn-2, it uses the natural bc, which is the one you showed. For Pn-Pn, it is p=0 at outflow, du/dn=0 at outflow. Paul ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Tuesday, May 27, 2014 9:01 AM To: nek5000 Subject: [Nek5000-users] Outflow bc and pressure Dear neks When we specify a boundary as outflow "O", I thought we take the normal stress to be zero -p*n + mu*(grad(u) + grad(u)^T)*n = 0 which is a natural boundary condition and where n = normal vector. But it seems that nek sets p=0 on the outflow boundary. So does this mean we on outflow boundary we take both normal stress to be zero and pressure to be zero ? Is it possible to use the normal stress condition without specifying a pressure ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 27 11:02:40 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 18:02:40 +0200 Subject: [Nek5000-users] Outflow bc and pressure In-Reply-To: References: Message-ID: On Tue, May 27, 2014 at 5:43 PM, wrote: > For Pn-Pn-2, it uses the natural bc, which is the one you showed. > Is this true whether I use IFSTRS = T or F When I run the ext_cyl example which is setup to use Pn/Pn-2 and IFSTRS=F, I find that pressure at outflow boundary is near zero. Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 27 11:07:11 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 16:07:11 +0000 Subject: [Nek5000-users] Outflow bc and pressure In-Reply-To: References: , Message-ID: Both cases... Indeed, you will find p near to zero. ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Tuesday, May 27, 2014 11:02 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Outflow bc and pressure On Tue, May 27, 2014 at 5:43 PM, > wrote: For Pn-Pn-2, it uses the natural bc, which is the one you showed. Is this true whether I use IFSTRS = T or F When I run the ext_cyl example which is setup to use Pn/Pn-2 and IFSTRS=F, I find that pressure at outflow boundary is near zero. Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 27 11:23:14 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 18:23:14 +0200 Subject: [Nek5000-users] Effect of CFL number. Message-ID: Dear Neks, I would like to know what is the effect of CFL number on a turbulence simulation in SEM. I use polynomial order of lx1 = 5 and lxd = 8 and get a C = 0.176 for a Re = 2000 with dt = 0.001 in pipe flow where I find a transition to turbulence. when I decrease my time step 'dt = 0.0001 ' further my pipe becomes fully turbulent for the same mesh. When I increase the order lx1 = 7 and lxd = 10, I find a completely steady solution, instead of a transition to turbulence. It would be nice what if some could please tell me what parameter determines the accuracy of the simulation in terms of a turbulent flow because I am not able to reproduce the result with a different mesh or with higher order. Thank you, Kamal From nek5000-users at lists.mcs.anl.gov Tue May 27 11:35:02 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 16:35:02 +0000 Subject: [Nek5000-users] Effect of CFL number. In-Reply-To: References: Message-ID: Hi Kamal, In my view, you are trying to run in a regime that is actually not reproducible. You are right at the transition Re, which implies strong sensitivity to initial conditions and under such circumstances you should not expect two simulations at two different resolutions to converge to the same result, just as you would not expect two turbulent simulations to follow the same trajectory point-by-point, only on average. Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Tuesday, May 27, 2014 11:23 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Effect of CFL number. Dear Neks, I would like to know what is the effect of CFL number on a turbulence simulation in SEM. I use polynomial order of lx1 = 5 and lxd = 8 and get a C = 0.176 for a Re = 2000 with dt = 0.001 in pipe flow where I find a transition to turbulence. when I decrease my time step 'dt = 0.0001 ' further my pipe becomes fully turbulent for the same mesh. When I increase the order lx1 = 7 and lxd = 10, I find a completely steady solution, instead of a transition to turbulence. It would be nice what if some could please tell me what parameter determines the accuracy of the simulation in terms of a turbulent flow because I am not able to reproduce the result with a different mesh or with higher order. Thank you, Kamal _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue May 27 16:01:09 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 23:01:09 +0200 Subject: [Nek5000-users] Effect of CFL number. In-Reply-To: References: Message-ID: Dear all, just to add also the domain length to Paul's answer; Re=2000 for pipe flow is in fact slightly below the "critical" Reynolds number for sustained turbulence. In a shorter pipe, turbulence will decay even faster. This indicates, as Paul mentions, the sensitivity to initial conditions and geometry, even though I would expect all DNS to eventually decay to laminar at that Re. Best regards, Philipp On 2014-05-27 18:35, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Kamal, > > In my view, you are trying to run in a regime that is actually not > reproducible. You are right at the transition Re, which implies > strong sensitivity to initial conditions and under such circumstances > you should not expect two simulations at two different resolutions to > converge to the same result, just as you would not expect two > turbulent simulations to follow the same trajectory point-by-point, > only on average. > > Paul > > ________________________________________ From: > nek5000-users-bounces at lists.mcs.anl.gov > [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of > nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] > Sent: Tuesday, May 27, 2014 11:23 AM To: > nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Effect of > CFL number. > > Dear Neks, > > I would like to know what is the effect of CFL number on a > turbulence simulation in SEM. > > I use polynomial order of lx1 = 5 and lxd = 8 and get a C = 0.176 for > a Re = 2000 with dt = 0.001 in pipe flow where I find a transition > to turbulence. when I decrease my time step 'dt = 0.0001 ' further my > pipe becomes fully turbulent for the same mesh. > > When I increase the order lx1 = 7 and lxd = 10, I find a completely > steady solution, instead of a transition to turbulence. > > It would be nice what if some could please tell me what parameter > determines the accuracy of the simulation in terms of a turbulent > flow because I am not able to reproduce the result with a different > mesh or with higher order. > > Thank you, > > Kamal _______________________________________________ Nek5000-users > mailing list Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing > list Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue May 27 16:11:46 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 23:11:46 +0200 Subject: [Nek5000-users] Effect of CFL number. In-Reply-To: References: Message-ID: Thanks Paul and Philipp. I have small cross wise velocity of v = 0.001 as a perturbation at the inlet to trigger the turbulence but as you said the sensitivity of the system determines the transition. Mr.phillip If you don't mind, could you please tell me at above which Re I can expect a sustained turbulence independent of the Mesh and order , Because I tend to see different Numerical methods (FVM,FEM) have different critical point of transition for a similar case . Thanks in advance for your replies Kamal On 27 May 2014, at 23:01, nek5000-users at lists.mcs.anl.gov wrote: > Dear all, > just to add also the domain length to Paul's answer; Re=2000 for pipe flow is in fact slightly below the "critical" Reynolds number for sustained turbulence. In a shorter pipe, turbulence will decay even faster. This indicates, as Paul mentions, the sensitivity to initial conditions and geometry, even though I would expect all DNS to eventually decay to laminar at that Re. > > Best regards, > Philipp > > On 2014-05-27 18:35, nek5000-users at lists.mcs.anl.gov wrote: >> >> Hi Kamal, >> >> In my view, you are trying to run in a regime that is actually not >> reproducible. You are right at the transition Re, which implies >> strong sensitivity to initial conditions and under such circumstances >> you should not expect two simulations at two different resolutions to >> converge to the same result, just as you would not expect two >> turbulent simulations to follow the same trajectory point-by-point, >> only on average. >> >> Paul >> >> ________________________________________ From: >> nek5000-users-bounces at lists.mcs.anl.gov >> [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of >> nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] >> Sent: Tuesday, May 27, 2014 11:23 AM To: >> nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Effect of >> CFL number. >> >> Dear Neks, >> >> I would like to know what is the effect of CFL number on a >> turbulence simulation in SEM. >> >> I use polynomial order of lx1 = 5 and lxd = 8 and get a C = 0.176 for >> a Re = 2000 with dt = 0.001 in pipe flow where I find a transition >> to turbulence. when I decrease my time step 'dt = 0.0001 ' further my >> pipe becomes fully turbulent for the same mesh. >> >> When I increase the order lx1 = 7 and lxd = 10, I find a completely >> steady solution, instead of a transition to turbulence. >> >> It would be nice what if some could please tell me what parameter >> determines the accuracy of the simulation in terms of a turbulent >> flow because I am not able to reproduce the result with a different >> mesh or with higher order. >> >> Thank you, >> >> Kamal _______________________________________________ Nek5000-users >> mailing list Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ Nek5000-users mailing >> list Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue May 27 16:27:15 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 23:27:15 +0200 Subject: [Nek5000-users] Effect of CFL number. In-Reply-To: References: Message-ID: Hi Kamal, Depending on what you want to do, I would stay away from the transitional region altogether, as you also might see spatial localisation which is maybe not what you want. The standard case for low-Re turbulence, which is sustained even in small boxes, is the Re_tau=180 case, which corresponds to Re_b=5300 or ReD=3464 (approximately). At that Re you also have a good deal of data to compare to. Best regards, Philipp On 2014-05-27 23:11, nek5000-users at lists.mcs.anl.gov wrote: > Thanks Paul and Philipp. I have small cross wise velocity of v = > 0.001 as a perturbation at the inlet to trigger the turbulence but as > you said the sensitivity of the system determines the transition. > > Mr.phillip If you don't mind, could you please tell me at above which > Re I can expect a sustained turbulence independent of the Mesh and > order , Because I tend to see different Numerical methods (FVM,FEM) > have different critical point of transition for a similar case . > > Thanks in advance for your replies > > Kamal > > On 27 May 2014, at 23:01, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear all, just to add also the domain length to Paul's answer; >> Re=2000 for pipe flow is in fact slightly below the "critical" >> Reynolds number for sustained turbulence. In a shorter pipe, >> turbulence will decay even faster. This indicates, as Paul >> mentions, the sensitivity to initial conditions and geometry, even >> though I would expect all DNS to eventually decay to laminar at >> that Re. >> >> Best regards, Philipp >> >> On 2014-05-27 18:35, nek5000-users at lists.mcs.anl.gov wrote: >>> >>> Hi Kamal, >>> >>> In my view, you are trying to run in a regime that is actually >>> not reproducible. You are right at the transition Re, which >>> implies strong sensitivity to initial conditions and under such >>> circumstances you should not expect two simulations at two >>> different resolutions to converge to the same result, just as you >>> would not expect two turbulent simulations to follow the same >>> trajectory point-by-point, only on average. >>> >>> Paul >>> >>> ________________________________________ From: >>> nek5000-users-bounces at lists.mcs.anl.gov >>> [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of >>> nek5000-users at lists.mcs.anl.gov >>> [nek5000-users at lists.mcs.anl.gov] Sent: Tuesday, May 27, 2014 >>> 11:23 AM To: nek5000-users at lists.mcs.anl.gov Subject: >>> [Nek5000-users] Effect of CFL number. >>> >>> Dear Neks, >>> >>> I would like to know what is the effect of CFL number on a >>> turbulence simulation in SEM. >>> >>> I use polynomial order of lx1 = 5 and lxd = 8 and get a C = 0.176 >>> for a Re = 2000 with dt = 0.001 in pipe flow where I find a >>> transition to turbulence. when I decrease my time step 'dt = >>> 0.0001 ' further my pipe becomes fully turbulent for the same >>> mesh. >>> >>> When I increase the order lx1 = 7 and lxd = 10, I find a >>> completely steady solution, instead of a transition to >>> turbulence. >>> >>> It would be nice what if some could please tell me what >>> parameter determines the accuracy of the simulation in terms of a >>> turbulent flow because I am not able to reproduce the result with >>> a different mesh or with higher order. >>> >>> Thank you, >>> >>> Kamal _______________________________________________ >>> Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> _______________________________________________ Nek5000-users >>> mailing list Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ Nek5000-users >> mailing list Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing > list Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue May 27 17:43:05 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 22:43:05 +0000 Subject: [Nek5000-users] Effect of CFL number. In-Reply-To: References: , Message-ID: Hi Kamal, Not only different numerical methods have different transitions, but different experiments as well. The point here is that the sensitivity you observe (across numerical methods, or across spatial/temporal resolution for a given method, or across the initial condition, or across different experiments) is due to physical phenomena, modulated by the method of investigation. If we take, say, an experiment as a gold standard, the question is: which one? Even Osborne Reynolds experimental apparatus does not give the same transition point today as it did when he did his experiments in the 1800s. Why? Vibrations due to truck traffic in the street... That input is not accounted for in any numerical simulations of pipe flow. The problem of course is that this is a subcritical bifurcation, unlike Rayleigh-Benard, for which the transition is triggered by a classic linear instability and is therefore repeatable. Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Tuesday, May 27, 2014 4:27 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Effect of CFL number. Hi Kamal, Depending on what you want to do, I would stay away from the transitional region altogether, as you also might see spatial localisation which is maybe not what you want. The standard case for low-Re turbulence, which is sustained even in small boxes, is the Re_tau=180 case, which corresponds to Re_b=5300 or ReD=3464 (approximately). At that Re you also have a good deal of data to compare to. Best regards, Philipp On 2014-05-27 23:11, nek5000-users at lists.mcs.anl.gov wrote: > Thanks Paul and Philipp. I have small cross wise velocity of v = > 0.001 as a perturbation at the inlet to trigger the turbulence but as > you said the sensitivity of the system determines the transition. > > Mr.phillip If you don't mind, could you please tell me at above which > Re I can expect a sustained turbulence independent of the Mesh and > order , Because I tend to see different Numerical methods (FVM,FEM) > have different critical point of transition for a similar case . > > Thanks in advance for your replies > > Kamal > > On 27 May 2014, at 23:01, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear all, just to add also the domain length to Paul's answer; >> Re=2000 for pipe flow is in fact slightly below the "critical" >> Reynolds number for sustained turbulence. In a shorter pipe, >> turbulence will decay even faster. This indicates, as Paul >> mentions, the sensitivity to initial conditions and geometry, even >> though I would expect all DNS to eventually decay to laminar at >> that Re. >> >> Best regards, Philipp >> >> On 2014-05-27 18:35, nek5000-users at lists.mcs.anl.gov wrote: >>> >>> Hi Kamal, >>> >>> In my view, you are trying to run in a regime that is actually >>> not reproducible. You are right at the transition Re, which >>> implies strong sensitivity to initial conditions and under such >>> circumstances you should not expect two simulations at two >>> different resolutions to converge to the same result, just as you >>> would not expect two turbulent simulations to follow the same >>> trajectory point-by-point, only on average. >>> >>> Paul >>> >>> ________________________________________ From: >>> nek5000-users-bounces at lists.mcs.anl.gov >>> [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of >>> nek5000-users at lists.mcs.anl.gov >>> [nek5000-users at lists.mcs.anl.gov] Sent: Tuesday, May 27, 2014 >>> 11:23 AM To: nek5000-users at lists.mcs.anl.gov Subject: >>> [Nek5000-users] Effect of CFL number. >>> >>> Dear Neks, >>> >>> I would like to know what is the effect of CFL number on a >>> turbulence simulation in SEM. >>> >>> I use polynomial order of lx1 = 5 and lxd = 8 and get a C = 0.176 >>> for a Re = 2000 with dt = 0.001 in pipe flow where I find a >>> transition to turbulence. when I decrease my time step 'dt = >>> 0.0001 ' further my pipe becomes fully turbulent for the same >>> mesh. >>> >>> When I increase the order lx1 = 7 and lxd = 10, I find a >>> completely steady solution, instead of a transition to >>> turbulence. >>> >>> It would be nice what if some could please tell me what >>> parameter determines the accuracy of the simulation in terms of a >>> turbulent flow because I am not able to reproduce the result with >>> a different mesh or with higher order. >>> >>> Thank you, >>> >>> Kamal _______________________________________________ >>> Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> _______________________________________________ Nek5000-users >>> mailing list Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ Nek5000-users >> mailing list Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing > list Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue May 27 22:35:12 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 23:35:12 -0400 Subject: [Nek5000-users] Object definition for surface integrals In-Reply-To: References: Message-ID: Dear Prof. Fischer Thanks for the detailed reply. I will use your description and understand the relevant subroutines of navier5.f routine in detail. Regards, Ravi On Mon, May 26, 2014 at 5:39 PM, Ravi Tumkur wrote: > Dean NEK Users, > > I am looking for some sort of help or documentation explaining the object > definitions for evaluating surface integrals. > > My eventual application will be to evaluate the drag and lift forces for > the case of a 2D flow past a cylinder, supported on elastic foundation, > i.e., vortex-induced vibration simulations using NEK5000. > > So far, the examples available in the repository and the NEK mailing list > have enabled me to simulate the motionless cylinder and the case of > cylinder moving with a prescribed motion. > > However, I have hard time decoding the surface integral evaluation in > subroutine "set_obj" available in the "ext_cyl.usr". Overall, I understand > that there is a conditional statement to find all the elements (or element > edges) with "W" boundary condition and then an object is created for each > of those elements. It would be very helpful is someone could point me to a > documentation/help, which gives an explanation for the following functions > or variables which have been used in the "set_obj" subroutine. > > 1. variable "hcode" > 2. variable "lochis" > 3. variable "nhis" > 4. function or variable "cbc" > 5. variable "nmember" > 6. function or variable "object" > > Any hints to understand this subroutine "set_obj" of the example model > "ext_cyl" would be of great help for me to understand and develop the model > for vortex-induced vibration. > > In addition, if there is already an example model to perform > vortex-induced vibration, please let me know. > > Thanks in advance. Any hints and tips are much appreciated. > > Regards, > Ravi > > > -- > Ravi Kumar T R > > University of Illinois at Urbana-Champaign > ph : +1 217 778 7538 > http://lndvl.mechse.illinois.edu/ > -- Ravi Kumar T R University of Illinois at Urbana-Champaign ph : +1 217 778 7538 http://lndvl.mechse.illinois.edu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 28 03:21:48 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 May 2014 10:21:48 +0200 Subject: [Nek5000-users] Effect of CFL number. In-Reply-To: References: , Message-ID: Thanks Mr.Fischer and Mr.Schlatter for your brief explanation. Best Regards, Kamal On 28/05/2014 00:43, nek5000-users at lists.mcs.anl.gov wrote: > Hi Kamal, > > Not only different numerical methods have different transitions, but different > experiments as well. The point here is that the sensitivity you observe > (across numerical methods, or across spatial/temporal resolution for a > given method, or across the initial condition, or across different experiments) > is due to physical phenomena, modulated by the method of investigation. > > If we take, say, an experiment as a gold standard, the question is: which one? > > Even Osborne Reynolds experimental apparatus does not give the same > transition point today as it did when he did his experiments in the 1800s. > Why? Vibrations due to truck traffic in the street... That input is not > accounted for in any numerical simulations of pipe flow. > > The problem of course is that this is a subcritical bifurcation, unlike > Rayleigh-Benard, for which the transition is triggered by a classic > linear instability and is therefore repeatable. > > Paul > > ________________________________________ > From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] > Sent: Tuesday, May 27, 2014 4:27 PM > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Effect of CFL number. > > Hi Kamal, > Depending on what you want to do, I would stay away from the > transitional region altogether, as you also might see spatial > localisation which is maybe not what you want. The standard case for > low-Re turbulence, which is sustained even in small boxes, is the > Re_tau=180 case, which corresponds to Re_b=5300 or ReD=3464 > (approximately). At that Re you also have a good deal of data to compare to. > Best regards, > Philipp > > On 2014-05-27 23:11, nek5000-users at lists.mcs.anl.gov wrote: >> Thanks Paul and Philipp. I have small cross wise velocity of v = >> 0.001 as a perturbation at the inlet to trigger the turbulence but as >> you said the sensitivity of the system determines the transition. >> >> Mr.phillip If you don't mind, could you please tell me at above which >> Re I can expect a sustained turbulence independent of the Mesh and >> order , Because I tend to see different Numerical methods (FVM,FEM) >> have different critical point of transition for a similar case . >> >> Thanks in advance for your replies >> >> Kamal >> >> On 27 May 2014, at 23:01, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear all, just to add also the domain length to Paul's answer; >>> Re=2000 for pipe flow is in fact slightly below the "critical" >>> Reynolds number for sustained turbulence. In a shorter pipe, >>> turbulence will decay even faster. This indicates, as Paul >>> mentions, the sensitivity to initial conditions and geometry, even >>> though I would expect all DNS to eventually decay to laminar at >>> that Re. >>> >>> Best regards, Philipp >>> >>> On 2014-05-27 18:35, nek5000-users at lists.mcs.anl.gov wrote: >>>> Hi Kamal, >>>> >>>> In my view, you are trying to run in a regime that is actually >>>> not reproducible. You are right at the transition Re, which >>>> implies strong sensitivity to initial conditions and under such >>>> circumstances you should not expect two simulations at two >>>> different resolutions to converge to the same result, just as you >>>> would not expect two turbulent simulations to follow the same >>>> trajectory point-by-point, only on average. >>>> >>>> Paul >>>> >>>> ________________________________________ From: >>>> nek5000-users-bounces at lists.mcs.anl.gov >>>> [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of >>>> nek5000-users at lists.mcs.anl.gov >>>> [nek5000-users at lists.mcs.anl.gov] Sent: Tuesday, May 27, 2014 >>>> 11:23 AM To: nek5000-users at lists.mcs.anl.gov Subject: >>>> [Nek5000-users] Effect of CFL number. >>>> >>>> Dear Neks, >>>> >>>> I would like to know what is the effect of CFL number on a >>>> turbulence simulation in SEM. >>>> >>>> I use polynomial order of lx1 = 5 and lxd = 8 and get a C = 0.176 >>>> for a Re = 2000 with dt = 0.001 in pipe flow where I find a >>>> transition to turbulence. when I decrease my time step 'dt = >>>> 0.0001 ' further my pipe becomes fully turbulent for the same >>>> mesh. >>>> >>>> When I increase the order lx1 = 7 and lxd = 10, I find a >>>> completely steady solution, instead of a transition to >>>> turbulence. >>>> >>>> It would be nice what if some could please tell me what >>>> parameter determines the accuracy of the simulation in terms of a >>>> turbulent flow because I am not able to reproduce the result with >>>> a different mesh or with higher order. >>>> >>>> Thank you, >>>> >>>> Kamal _______________________________________________ >>>> Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> _______________________________________________ Nek5000-users >>>> mailing list Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>> _______________________________________________ Nek5000-users >>> mailing list Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ Nek5000-users mailing >> list Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon May 26 19:27:49 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 May 2014 08:27:49 +0800 (CST) Subject: [Nek5000-users] About LELGEC in 'SIZE' file Message-ID: In turbChannel example, the 'SIZE' file, line 44, a note reads'Note: In the new code, LELGEC should be about sqrt(LELG)', in this example,lelg=520(line 20), while, 'LELGEC=1' (line 46), so is the version of code not the new code? I have just downloaded it from the official site. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 27 21:45:57 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 May 2014 10:45:57 +0800 (CST) Subject: [Nek5000-users] How to add Coriolis force Message-ID: Dear Neks; I want to add Coriolis force to do a rotating simulation. As known, the Coriolis term is defined as 2*omega(cross product)U, so how can I add it to the N-S equation? Is there any example of similar case? Thank you Xianbei -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 28 10:53:58 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 May 2014 09:53:58 -0600 Subject: [Nek5000-users] How to add Coriolis force In-Reply-To: References: Message-ID: Xianbel, You can add the Coriolis term in the userf routine: omega = something c add coriolis forces ffx = + 2.0*omega*uy ffy = - 2.0*omega*ux ffz = 0. Mike On May 27, 2014, at 8:45 PM, > > wrote: Dear Neks; I want to add Coriolis force to do a rotating simulation. As known, the Coriolis term is defined as 2*omega(cross product)U, so how can I add it to the N-S equation? Is there any example of similar case? Thank you Xianbei ?????????????? _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed May 28 18:48:39 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 May 2014 19:48:39 -0400 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) Message-ID: Hello all, I am working on a problem consisting of an axially-horizontal cylindrical tank with an inlet (an opening) at its top and a connected pipe to its bottom as an outlet. The boundary conditions are set accordingly, i.e., inflow and outflow, respectively. Gravity is in vertical direction. I need to use Pn-Pn formulation as I use Moab for this problem. Assuming a steady-state condition with a full tank, this problem can be solved using single-phase NS solver. However, I noticed that there is large mass conservation error, as indicated by warning of "DIV(V)- QTL too large", when I run the case with a zero initial velocity field. I expected that this error decreased as the time evolved, but, it increased. Also a back-flow gradually starts to grow at the outflow boundary as well. I thought that this problem may be solved if I start from a realistic initial condition, however, it is not trivial for this problem. I am also skeptical about the zero pressure BC which is imposed at the outflow in Pn-Pn formulation. The other solution might be having an inlet (but outward) velocity at the outlet. So I wondered if anyone can give me a hint on this problem or the solutions proposed. Thanks, Mohsen From nek5000-users at lists.mcs.anl.gov Wed May 28 19:39:00 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 00:39:00 +0000 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) In-Reply-To: References: Message-ID: Hi Mosen, I'm assuming that gravity points in the -z direction for you? If so, what is the value of the unit normal vector on your outflow plane? Is it (0,0,-1), i.e., in the negative z direction? Or something else? Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 6:48 PM To: Nek 5000 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) Hello all, I am working on a problem consisting of an axially-horizontal cylindrical tank with an inlet (an opening) at its top and a connected pipe to its bottom as an outlet. The boundary conditions are set accordingly, i.e., inflow and outflow, respectively. Gravity is in vertical direction. I need to use Pn-Pn formulation as I use Moab for this problem. Assuming a steady-state condition with a full tank, this problem can be solved using single-phase NS solver. However, I noticed that there is large mass conservation error, as indicated by warning of "DIV(V)- QTL too large", when I run the case with a zero initial velocity field. I expected that this error decreased as the time evolved, but, it increased. Also a back-flow gradually starts to grow at the outflow boundary as well. I thought that this problem may be solved if I start from a realistic initial condition, however, it is not trivial for this problem. I am also skeptical about the zero pressure BC which is imposed at the outflow in Pn-Pn formulation. The other solution might be having an inlet (but outward) velocity at the outlet. So I wondered if anyone can give me a hint on this problem or the solutions proposed. Thanks, Mohsen _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed May 28 20:09:16 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 09:09:16 +0800 (CST) Subject: [Nek5000-users] How to add Coriolis force In-Reply-To: References: Message-ID: Hi,Mike Thank you very much for you help. Now I have a question about the built-in variables. As the help document is not so sufficient, there are so many variables not introduced, so how can I find what's the meaning of the variables? I'm sorry to trouble you for this simple question, but it's really important to me. Thank you Xianbei ? 2014-05-28 11:53:58?nek5000-users at lists.mcs.anl.gov ??? >Xianbel, > >You can add the Coriolis term in the userf routine: > > omega = something > >c add coriolis forces > ffx = + 2.0*omega*uy > ffy = - 2.0*omega*ux > ffz = 0. > >Mike > > >On May 27, 2014, at 8:45 PM, > > wrote: > >Dear Neks; > I want to add Coriolis force to do a rotating simulation. As known, the Coriolis term is defined as 2*omega(cross product)U, so how can I add it to the N-S equation? Is there any example of similar case? > >Thank you >Xianbei > > >?????????????? >_______________________________________________ >Nek5000-users mailing list >Nek5000-users at lists.mcs.anl.gov >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >_______________________________________________ >Nek5000-users mailing list >Nek5000-users at lists.mcs.anl.gov >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 28 20:35:56 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 01:35:56 +0000 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) In-Reply-To: References: , Message-ID: Hi Paul, Thanks for your response. In my coordinate, gravity points in -y direction. Nevertheless, the unit normal of the outflow is not exactly (0, -1, 0), since the outflow plane is a little tilted (i.e., n ~ (0, -0.99, -0.1). Should this plan be parallel to a coordinate plane? Mohsen ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 8:39 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Problem w/ outflow and DIV(V) Hi Mosen, I'm assuming that gravity points in the -z direction for you? If so, what is the value of the unit normal vector on your outflow plane? Is it (0,0,-1), i.e., in the negative z direction? Or something else? Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 6:48 PM To: Nek 5000 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) Hello all, I am working on a problem consisting of an axially-horizontal cylindrical tank with an inlet (an opening) at its top and a connected pipe to its bottom as an outlet. The boundary conditions are set accordingly, i.e., inflow and outflow, respectively. Gravity is in vertical direction. I need to use Pn-Pn formulation as I use Moab for this problem. Assuming a steady-state condition with a full tank, this problem can be solved using single-phase NS solver. However, I noticed that there is large mass conservation error, as indicated by warning of "DIV(V)- QTL too large", when I run the case with a zero initial velocity field. I expected that this error decreased as the time evolved, but, it increased. Also a back-flow gradually starts to grow at the outflow boundary as well. I thought that this problem may be solved if I start from a realistic initial condition, however, it is not trivial for this problem. I am also skeptical about the zero pressure BC which is imposed at the outflow in Pn-Pn formulation. The other solution might be having an inlet (but outward) velocity at the outlet. So I wondered if anyone can give me a hint on this problem or the solutions proposed. Thanks, Mohsen _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed May 28 20:51:23 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 01:51:23 +0000 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) In-Reply-To: References: , , Message-ID: Hi Mohsen, For incompressible Navier-Stokes, you can add a body force such that the pressure will be uniform at outflow in the no-flow configuration. It's important to do this --- see Eq. (13) on p. 9 of http://www.mcs.anl.gov/~fischer/nek5000/examples.pdf (which is accessible from the Nek5000 documentation page). If you don't compensate for the variance in pressure force due to the hydrostatic load then you will indeed find backflow coming in via the outflow boundary. Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 8:35 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Problem w/ outflow and DIV(V) Hi Paul, Thanks for your response. In my coordinate, gravity points in -y direction. Nevertheless, the unit normal of the outflow is not exactly (0, -1, 0), since the outflow plane is a little tilted (i.e., n ~ (0, -0.99, -0.1). Should this plan be parallel to a coordinate plane? Mohsen ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 8:39 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Problem w/ outflow and DIV(V) Hi Mosen, I'm assuming that gravity points in the -z direction for you? If so, what is the value of the unit normal vector on your outflow plane? Is it (0,0,-1), i.e., in the negative z direction? Or something else? Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 6:48 PM To: Nek 5000 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) Hello all, I am working on a problem consisting of an axially-horizontal cylindrical tank with an inlet (an opening) at its top and a connected pipe to its bottom as an outlet. The boundary conditions are set accordingly, i.e., inflow and outflow, respectively. Gravity is in vertical direction. I need to use Pn-Pn formulation as I use Moab for this problem. Assuming a steady-state condition with a full tank, this problem can be solved using single-phase NS solver. However, I noticed that there is large mass conservation error, as indicated by warning of "DIV(V)- QTL too large", when I run the case with a zero initial velocity field. I expected that this error decreased as the time evolved, but, it increased. Also a back-flow gradually starts to grow at the outflow boundary as well. I thought that this problem may be solved if I start from a realistic initial condition, however, it is not trivial for this problem. I am also skeptical about the zero pressure BC which is imposed at the outflow in Pn-Pn formulation. The other solution might be having an inlet (but outward) velocity at the outlet. So I wondered if anyone can give me a hint on this problem or the solutions proposed. Thanks, Mohsen _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed May 28 22:13:45 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 03:13:45 +0000 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) In-Reply-To: References: , , , Message-ID: Thanks Paul. So I think I can also modify the geometry of outflow plane such that to be exactly horizontal. Therefore, the hydrostatic pressure would be uniform at the outlet. Am I right? Mohsen ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 9:51 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Problem w/ outflow and DIV(V) Hi Mohsen, For incompressible Navier-Stokes, you can add a body force such that the pressure will be uniform at outflow in the no-flow configuration. It's important to do this --- see Eq. (13) on p. 9 of http://www.mcs.anl.gov/~fischer/nek5000/examples.pdf (which is accessible from the Nek5000 documentation page). If you don't compensate for the variance in pressure force due to the hydrostatic load then you will indeed find backflow coming in via the outflow boundary. Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 8:35 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Problem w/ outflow and DIV(V) Hi Paul, Thanks for your response. In my coordinate, gravity points in -y direction. Nevertheless, the unit normal of the outflow is not exactly (0, -1, 0), since the outflow plane is a little tilted (i.e., n ~ (0, -0.99, -0.1). Should this plan be parallel to a coordinate plane? Mohsen ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 8:39 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Problem w/ outflow and DIV(V) Hi Mosen, I'm assuming that gravity points in the -z direction for you? If so, what is the value of the unit normal vector on your outflow plane? Is it (0,0,-1), i.e., in the negative z direction? Or something else? Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 6:48 PM To: Nek 5000 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) Hello all, I am working on a problem consisting of an axially-horizontal cylindrical tank with an inlet (an opening) at its top and a connected pipe to its bottom as an outlet. The boundary conditions are set accordingly, i.e., inflow and outflow, respectively. Gravity is in vertical direction. I need to use Pn-Pn formulation as I use Moab for this problem. Assuming a steady-state condition with a full tank, this problem can be solved using single-phase NS solver. However, I noticed that there is large mass conservation error, as indicated by warning of "DIV(V)- QTL too large", when I run the case with a zero initial velocity field. I expected that this error decreased as the time evolved, but, it increased. Also a back-flow gradually starts to grow at the outflow boundary as well. I thought that this problem may be solved if I start from a realistic initial condition, however, it is not trivial for this problem. I am also skeptical about the zero pressure BC which is imposed at the outflow in Pn-Pn formulation. The other solution might be having an inlet (but outward) velocity at the outlet. So I wondered if anyone can give me a hint on this problem or the solutions proposed. Thanks, Mohsen _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu May 29 01:24:34 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 14:24:34 +0800 (CST) Subject: [Nek5000-users] About the iobj in the drag calculation Message-ID: Hi,all: I read Paul's reply in this mail https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2014-May/002756.html And got to know something about objects. As you say, the object is a collection of faces, here , I have a question about the iboj, how could I know which face it represent with iboj? As in turbChannel.usr, dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) I think it means to do the time-average of the average dragx on planey1 and planey2, as 0.5*(dragx(1)+dragx(2)) indicates, while how to calculate the dragx on the planex1, planex2, planez1 and planez2? for the maxobj in this example is only 4 and dragx is defined as dragx(0:maxobj) Thank you Xianbei -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 29 01:45:34 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 14:45:34 +0800 (CST) Subject: [Nek5000-users] About the iobj in the drag calculation In-Reply-To: References: Message-ID: Hi, I'm sorry to trouble. I find these lines in set_obj subroutine if (f.eq.1) iobj=1 ! lower wall if (f.eq.3) iobj=2 ! upper wall so this defines which wall to be represented. Another question comes that why the urms is calculate like do i=1,m write(56,3) yy(i)+1 & ,(yy(i)+1)*Re_tau & , (urms_pl(i)-(uavg_pl(i))**2)/u_tau**2 & , vrms_pl(i)/u_tau**2 & , wrms_pl(i)/u_tau**2 & , uvms_pl(i)/u_tau**2 write(57,3) yy(i) + 1. & , (yy(i)+1.)*Re_tau & , uavg_pl(i)/u_tau 3 format(1p15e17.9) enddo As can be seen,R_uu=(urms_pl(i)-(uavg_pl(i))**2)/u_tau**2, while R_vv=vrms_pl(i)/u_tau**2,why? ? 2014-05-29 02:24:34?nek5000-users at lists.mcs.anl.gov ??? Hi,all: I read Paul's reply in this mail https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2014-May/002756.html And got to know something about objects. As you say, the object is a collection of faces, here , I have a question about the iboj, how could I know which face it represent with iboj? As in turbChannel.usr, dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) I think it means to do the time-average of the average dragx on planey1 and planey2, as 0.5*(dragx(1)+dragx(2)) indicates, while how to calculate the dragx on the planex1, planex2, planez1 and planez2? for the maxobj in this example is only 4 and dragx is defined as dragx(0:maxobj) Thank you Xianbei ?????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 29 05:33:24 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 10:33:24 +0000 Subject: [Nek5000-users] Questions in AXHELM and WLAPLACIAN Message-ID: Dear nek5000 team, Could you help me with the 2 questions below? Thank you very much ! 1) Concerning the routine ?axhelm? in hmholtz.f. If I am right, one possibility of this routine can be the discretisation of the diffusion operator. However it is not clear to me if axhelm performs: a) vdiff x Laplacian(phi) or b) grad ( vdiff x grad (phi) ) phi being the variable solved for (T or PS for example). So, is it actually a) or b) ? 2) In the routine wlaplacian in navier1.f, I am not sure to understand the consequence of the line: call sub2 (out,wrk,ntot) after the lines: call bcneusc(out,1) call axhelm(wrk,a,diff,h2,imesh,1) If I am right, this will change the sign in front of the diffusion operator, right? Because in makeq.f, I am not sure that the line call add2(bq(1,1,1,1,ifield-1),w1,ntot) will actually assemble the RHS of the transport equation : - (vtrans) x U grad (phi) + grad ( vdiff x grad (phi) ) Thank you for your help ! Best regards, Emmanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 29 05:35:37 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 10:35:37 +0000 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) In-Reply-To: References: , , , , Message-ID: Yes - if your outflow plane is orthogonal to your gravity vector, then you are set. If this is not the case, you need to modify the forcing. A common strategy for std. Boussinesq is: ffy = -beta*g*(temp-tbar) where tbar is the average temperature in the domain. This effectively removes the hydrostatic component from the computed pressure. For stratified flow you need something more sophisticated, as indicated in the reference I mentioned earlier. Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 10:13 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Problem w/ outflow and DIV(V) Thanks Paul. So I think I can also modify the geometry of outflow plane such that to be exactly horizontal. Therefore, the hydrostatic pressure would be uniform at the outlet. Am I right? Mohsen ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 9:51 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Problem w/ outflow and DIV(V) Hi Mohsen, For incompressible Navier-Stokes, you can add a body force such that the pressure will be uniform at outflow in the no-flow configuration. It's important to do this --- see Eq. (13) on p. 9 of http://www.mcs.anl.gov/~fischer/nek5000/examples.pdf (which is accessible from the Nek5000 documentation page). If you don't compensate for the variance in pressure force due to the hydrostatic load then you will indeed find backflow coming in via the outflow boundary. Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 8:35 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Problem w/ outflow and DIV(V) Hi Paul, Thanks for your response. In my coordinate, gravity points in -y direction. Nevertheless, the unit normal of the outflow is not exactly (0, -1, 0), since the outflow plane is a little tilted (i.e., n ~ (0, -0.99, -0.1). Should this plan be parallel to a coordinate plane? Mohsen ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 8:39 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Problem w/ outflow and DIV(V) Hi Mosen, I'm assuming that gravity points in the -z direction for you? If so, what is the value of the unit normal vector on your outflow plane? Is it (0,0,-1), i.e., in the negative z direction? Or something else? Paul ________________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Wednesday, May 28, 2014 6:48 PM To: Nek 5000 Subject: [Nek5000-users] Problem w/ outflow and DIV(V) Hello all, I am working on a problem consisting of an axially-horizontal cylindrical tank with an inlet (an opening) at its top and a connected pipe to its bottom as an outlet. The boundary conditions are set accordingly, i.e., inflow and outflow, respectively. Gravity is in vertical direction. I need to use Pn-Pn formulation as I use Moab for this problem. Assuming a steady-state condition with a full tank, this problem can be solved using single-phase NS solver. However, I noticed that there is large mass conservation error, as indicated by warning of "DIV(V)- QTL too large", when I run the case with a zero initial velocity field. I expected that this error decreased as the time evolved, but, it increased. Also a back-flow gradually starts to grow at the outflow boundary as well. I thought that this problem may be solved if I start from a realistic initial condition, however, it is not trivial for this problem. I am also skeptical about the zero pressure BC which is imposed at the outflow in Pn-Pn formulation. The other solution might be having an inlet (but outward) velocity at the outlet. So I wondered if anyone can give me a hint on this problem or the solutions proposed. Thanks, Mohsen _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu May 29 05:50:09 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 05:50:09 -0500 (CDT) Subject: [Nek5000-users] Questions in AXHELM and WLAPLACIAN In-Reply-To: References: Message-ID: Hi Emmanuel, axhelm effects the weak Laplacian plus the mass matrix. Specifically, if you wanted to solve: (1) -nabla . [ h1 * nabla ] u + h2 * u = f with h1, h2, and f all functions of X=(x,y,z), the discrete form would be: (2) A(h1) u + B(h2) u = B f or (3) H u = B f where A is the (h1-dependent stiffness matrix and B(h2) is the h2-dependent mass matrix. For the SEM, B is diagonal, so B(h2) = h2*B, where we view h2 as a diagonal matrix. In Nek5000, a matrix-vector product w = Hu is effected via call axhelm (w,u,h1,h2,imesh,isd) with w,u,h1,h2 being arrarys. Here, imesh indicates if you are on the fluid mesh or thermal mesh. The fluid mesh is a subset of the thermal mesh in the case of conjugate heat transfer between a fluid and a solid. isd indicates which spatial direction is considered in axisymmetric applications where u is a component of a vector field. Notice the sign of the Laplacian in Eq. (1) -- that may help resolve your second question? (There is a sign change that ariss from the standard integration-by-parts stepin the weak form.) Paul On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: > Dear nek5000 team, > > Could you help me with the 2 questions below? Thank you very much ! > > 1) Concerning the routine ?axhelm? in hmholtz.f. If I am right, one > possibility of this routine can be the discretisation of the diffusion > operator. However it is not clear to me if axhelm performs: > > a) vdiff x Laplacian(phi) > > or > > b) grad ( vdiff x grad (phi) ) > > phi being the variable solved for (T or PS for example). > > So, is it actually a) or b) ? > > > 2) In the routine wlaplacian in navier1.f, I am not sure to understand the > consequence of the line: > > call sub2 (out,wrk,ntot) > > after the lines: > > call bcneusc(out,1) call axhelm(wrk,a,diff,h2,imesh,1) > > If I am right, this will change the sign in front of the diffusion operator, > right? Because in makeq.f, I am not sure that the line call > add2(bq(1,1,1,1,ifield-1),w1,ntot) > > will actually assemble the RHS of the transport equation : - (vtrans) x U > grad (phi) + grad ( vdiff x grad (phi) ) > > > Thank you for your help ! > > Best regards, Emmanuel > > From nek5000-users at lists.mcs.anl.gov Thu May 29 05:54:10 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 05:54:10 -0500 (CDT) Subject: [Nek5000-users] About the iobj in the drag calculation In-Reply-To: References: Message-ID: Hi Xianbei, You can define more objects by picking your own surface discriminators (which will be dependent on your particular application). If you need more than 4 objects, you can increase maxobj in SIZE. Typically, dragx(0) would be the sum of the drag on all the objects --- this is sometimes useful. If you have (say) a 4-sided channel, you can just define one object instead of 4, and set it to be the collection of all faces for which cbc(f,e,1)='W '. Paul On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: > Hi,all: I read Paul's reply in this mail https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2014-May/002756.html And got to know something about objects. As you say, the object is a collection of faces, here , I have a question about the iboj, how could I know which face it represent with iboj? As in turbChannel.usr, dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) I think it means to do the time-average of the average dragx on planey1 and planey2, as 0.5*(dragx(1)+dragx(2)) indicates, while how to calculate the dragx on the planex1, planex2, planez1 and planez2? for the maxobj in this example is only 4 and dragx is defined as dragx(0:maxobj) Thank you Xianbei From nek5000-users at lists.mcs.anl.gov Thu May 29 05:56:56 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 05:56:56 -0500 (CDT) Subject: [Nek5000-users] About the iobj in the drag calculation In-Reply-To: References: Message-ID: These are just rescalings of turbulent fluctuations in terms of wall units, which allows them to be compared with other data in the literature. On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: > Hi, I'm sorry to trouble. I find these lines in set_obj subroutine if (f.eq.1) iobj=1 ! lower wall if (f.eq.3) iobj=2 ! upper wall so this defines which wall to be represented. Another question comes that why the urms is calculate like do i=1,m write(56,3) yy(i)+1 & ,(yy(i)+1)*Re_tau & , (urms_pl(i)-(uavg_pl(i))**2)/u_tau**2 & , vrms_pl(i)/u_tau**2 & , wrms_pl(i)/u_tau**2 & , uvms_pl(i)/u_tau**2 write(57,3) yy(i) + 1. & , (yy(i)+1.)*Re_tau & , uavg_pl(i)/u_tau 3 format(1p15e17.9) enddo As can be seen,R_uu=(urms_pl(i)-(uavg_pl(i))**2)/u_tau**2, while R_vv=vrms_pl(i)/u_tau**2,why? ?? 2014-05-29 02:24:34??nek5000-users at lists.mcs.anl.gov ?????? Hi,all: I read Paul's reply in this mail https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2014-May/002756.html And got to know something about objects. As you say, the object is a collection of faces, here , I have a question about the iboj, how could I know which face it represent with iboj? As in turbChannel.usr, dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) I think it means to do the time-average of the average dragx on planey1 and planey2, as 0.5*(dragx(1)+dragx(2)) indicates, while how to calculate the dragx on the planex1, planex2, planez1 and planez2? for the maxobj in this example is only 4 and dragx is defined as dragx(0:maxobj) Thank you Xianbei ???????????????????????????? From nek5000-users at lists.mcs.anl.gov Thu May 29 06:25:15 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 19:25:15 +0800 (CST) Subject: [Nek5000-users] About the iobj in the drag calculation In-Reply-To: References: Message-ID: Thank you very much,Paul. Now I get stuck in the Energy spectrum and two-point correlation, I'll go through the code first, if a problem occurs, I'll show it. Xianbei At 2014-05-29 06:54:10, nek5000-users at lists.mcs.anl.gov wrote: > >Hi Xianbei, > >You can define more objects by picking your >own surface discriminators (which will >be dependent on your particular application). > >If you need more than 4 objects, you can increase maxobj >in SIZE. > >Typically, dragx(0) would be the sum of the drag on all >the objects --- this is sometimes useful. > >If you have (say) a 4-sided channel, you can just define >one object instead of 4, and set it to be the collection >of all faces for which cbc(f,e,1)='W '. > >Paul > > > >On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi,all: > I read Paul's reply in this mail https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2014-May/002756.html > And got to know something about objects. As you say, the object is a collection of faces, here , I have a question about the iboj, how could I know which face it represent with iboj? As in turbChannel.usr, > dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) > I think it means to do the time-average of the average dragx on planey1 and planey2, as > 0.5*(dragx(1)+dragx(2)) > indicates, while how to calculate the dragx on the planex1, planex2, planez1 and planez2? for the maxobj in this example is only 4 and dragx is defined as > dragx(0:maxobj) > >Thank you >Xianbei >_______________________________________________ >Nek5000-users mailing list >Nek5000-users at lists.mcs.anl.gov >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 29 06:27:48 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 19:27:48 +0800 (CST) Subject: [Nek5000-users] About the iobj in the drag calculation In-Reply-To: References: Message-ID: Thank you, I know the urms/u_tau**2 is to rescale the data, but why (urms_pl(i)-(uavg_pl(i))**2) but the other components are not? I mean minus the uavg_pl(i). At 2014-05-29 06:56:56, nek5000-users at lists.mcs.anl.gov wrote: > >These are just rescalings of turbulent fluctuations >in terms of wall units, which allows them to be compared with >other data in the literature. > > > >On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, > I'm sorry to trouble. I find these lines in set_obj subroutine > if (f.eq.1) iobj=1 ! lower wall > if (f.eq.3) iobj=2 ! upper wall > so this defines which wall to be represented. Another question comes that why the urms is calculate like > do i=1,m > write(56,3) yy(i)+1 > & ,(yy(i)+1)*Re_tau > & , (urms_pl(i)-(uavg_pl(i))**2)/u_tau**2 > & , vrms_pl(i)/u_tau**2 > & , wrms_pl(i)/u_tau**2 > & , uvms_pl(i)/u_tau**2 > write(57,3) yy(i) + 1. > & , (yy(i)+1.)*Re_tau > & , uavg_pl(i)/u_tau > 3 format(1p15e17.9) > enddo > >As can be seen,R_uu=(urms_pl(i)-(uavg_pl(i))**2)/u_tau**2, while R_vv=vrms_pl(i)/u_tau**2,why? > > > > > > >? 2014-05-29 02:24:34?nek5000-users at lists.mcs.anl.gov ??? > >Hi,all: > I read Paul's reply in this mail https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2014-May/002756.html > And got to know something about objects. As you say, the object is a collection of faces, here , I have a question about the iboj, how could I know which face it represent with iboj? As in turbChannel.usr, > dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) > I think it means to do the time-average of the average dragx on planey1 and planey2, as > 0.5*(dragx(1)+dragx(2)) > indicates, while how to calculate the dragx on the planex1, planex2, planez1 and planez2? for the maxobj in this example is only 4 and dragx is defined as > dragx(0:maxobj) > >Thank you >Xianbei > > > > >?????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 29 07:22:28 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 20:22:28 +0800 (CST) Subject: [Nek5000-users] About the iobj in the drag calculation In-Reply-To: References: Message-ID: Hi,Paul: I'm confused about part of the subroutine userchk in turbChannel.usr if(icalld.eq.0) then call rzero(uavg,n) call rzero(urms,n) call rzero(vrms,n) call rzero(wrms,n) call rzero(uvms,n) atime = 0. timel = time call planar_average_s(yy ,ym1 ,w1,w2) icalld = 1 endif dtime = time - timel atime = atime + dtime if (atime.ne.0. .and. dtime.ne.0.) then beta = dtime/atime alpha = 1.-beta ifverbose = .false. call avg1(uavg,vx ,alpha,beta,n,'uavg',ifverbose) call avg2(urms,vx ,alpha,beta,n,'urms',ifverbose) call avg2(vrms,vy ,alpha,beta,n,'vrms',ifverbose) call avg2(wrms,vz ,alpha,beta,n,'wrms',ifverbose) call avg3(uvms,vx,vy,alpha,beta,n,'uvmm',ifverbose) dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) ! averaging over statistical homogeneous directions (r-t) call planar_average_s(uavg_pl,uavg,w1,w2) call planar_average_s(urms_pl,urms,w1,w2) call planar_average_s(vrms_pl,vrms,w1,w2) call planar_average_s(wrms_pl,wrms,w1,w2) call planar_average_s(uvms_pl,uvms,w1,w2) ! average over half the channel height m = ny1*nely do i=1,ny1*nely/2 uavg_pl(i) = 0.5 * (uavg_pl(i) + uavg_pl(m-i+1)) urms_pl(i) = 0.5 * (urms_pl(i) + urms_pl(m-i+1)) vrms_pl(i) = 0.5 * (vrms_pl(i) + vrms_pl(m-i+1)) wrms_pl(i) = 0.5 * (wrms_pl(i) + wrms_pl(m-i+1)) enddo endif tw = dragx_avg/A_w + 1.e-50 u_tau = sqrt(tw/rho) Re_tau = u_tau*delta/dnu diff = (tw-ffx_new)/tw if(nid.eq.0) write(6,1) istep,time,e2,ffx_new,diff 1 format(i6,1p4e17.9,' err2') ! write statistics to file iostep_avg = param(68) if(nid.eq.0 .and. istep.gt.0 .and. & mod(istep,iostep_avg).eq.0) then write(6,*) 'Dumping statistics ...' open(unit=56,file='reystresses.dat') write(56,'(A,1pe14.7)') '#time = ', time write(56,'(A)') & '# y y+ R_uu R_vv R_ww R_uv' open(unit=57,file='means.dat') write(57,'(A,1pe14.7)') '#time = ', time write(57,'(A)') & '# y y+ Umean' m = ny1*nely/2 do i=1,m write(56,3) yy(i)+1 & ,(yy(i)+1)*Re_tau & , (urms_pl(i)-(uavg_pl(i))**2)/u_tau**2 & , vrms_pl(i)/u_tau**2 & , wrms_pl(i)/u_tau**2 & , uvms_pl(i)/u_tau**2 write(57,3) yy(i) + 1. & , (yy(i)+1.)*Re_tau & , uavg_pl(i)/u_tau 3 format(1p15e17.9) enddo close(56) close(57) endif return end I look into the code of navier5.f and find that avg1, avg2 returns the time average of vx and vx**2 in this example, so if we want to calculate the Reynolds stress, the formulation should be : R_uu=urms-uavg**2 also, if normalized, R_uu=(urms-uavg**2)/u_tau**2 so are the other components I think this is the right way instead of that in the example At 2014-05-29 06:54:10, nek5000-users at lists.mcs.anl.gov wrote: > >Hi Xianbei, > >You can define more objects by picking your >own surface discriminators (which will >be dependent on your particular application). > >If you need more than 4 objects, you can increase maxobj >in SIZE. > >Typically, dragx(0) would be the sum of the drag on all >the objects --- this is sometimes useful. > >If you have (say) a 4-sided channel, you can just define >one object instead of 4, and set it to be the collection >of all faces for which cbc(f,e,1)='W '. > >Paul > > > >On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi,all: > I read Paul's reply in this mail https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2014-May/002756.html > And got to know something about objects. As you say, the object is a collection of faces, here , I have a question about the iboj, how could I know which face it represent with iboj? As in turbChannel.usr, > dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) > I think it means to do the time-average of the average dragx on planey1 and planey2, as > 0.5*(dragx(1)+dragx(2)) > indicates, while how to calculate the dragx on the planex1, planex2, planez1 and planez2? for the maxobj in this example is only 4 and dragx is defined as > dragx(0:maxobj) > >Thank you >Xianbei >_______________________________________________ >Nek5000-users mailing list >Nek5000-users at lists.mcs.anl.gov >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 29 12:00:15 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 May 2014 10:00:15 -0700 Subject: [Nek5000-users] About the iobj in the drag calculation In-Reply-To: References: Message-ID: Hi Xianbi, You are right in defining the Reynolds Stresses. However, if you look carefully, this is an example of fully developed turbulent Channel. Hence the statistics is independant of the x direction (streamwise). Also, the statistics is taken independant of z direction (no wall in z). x and z both have periodic BC. Hence before calculating R_uu, R_vv etc, we just do the spatial planar averaging in the xz plane. Since for homogeneous flow, that should equal an ensemble average. You can modify the turbChannel to a non-homogeneous flow, in which case you can define Reynolds stresses just like you said, and they would spatially varying. Thanks, Tanmoy On Thu, May 29, 2014 at 5:22 AM, wrote: > Hi,Paul: > I'm confused about part of the subroutine userchk in turbChannel.usr > if(icalld.eq.0) then > call rzero(uavg,n) > call rzero(urms,n) > call rzero(vrms,n) > call rzero(wrms,n) > call rzero(uvms,n) > atime = 0. > timel = time > call planar_average_s(yy ,ym1 ,w1,w2) > icalld = 1 > endif > > dtime = time - timel > atime = atime + dtime > > if (atime.ne.0. .and. dtime.ne.0.) then > beta = dtime/atime > alpha = 1.-beta > ifverbose = .false. > > call avg1(uavg,vx ,alpha,beta,n,'uavg',ifverbose) > call avg2(urms,vx ,alpha,beta,n,'urms',ifverbose) > call avg2(vrms,vy ,alpha,beta,n,'vrms',ifverbose) > call avg2(wrms,vz ,alpha,beta,n,'wrms',ifverbose) > call avg3(uvms,vx,vy,alpha,beta,n,'uvmm',ifverbose) > > > dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) > > ! averaging over statistical homogeneous directions (r-t) > call planar_average_s(uavg_pl,uavg,w1,w2) > call planar_average_s(urms_pl,urms,w1,w2) > call planar_average_s(vrms_pl,vrms,w1,w2) > call planar_average_s(wrms_pl,wrms,w1,w2) > call planar_average_s(uvms_pl,uvms,w1,w2) > > ! average over half the channel height > m = ny1*nely > do i=1,ny1*nely/2 > uavg_pl(i) = 0.5 * (uavg_pl(i) + uavg_pl(m-i+1)) > urms_pl(i) = 0.5 * (urms_pl(i) + urms_pl(m-i+1)) > vrms_pl(i) = 0.5 * (vrms_pl(i) + vrms_pl(m-i+1)) > wrms_pl(i) = 0.5 * (wrms_pl(i) + wrms_pl(m-i+1)) > enddo > endif > > tw = dragx_avg/A_w + 1.e-50 > u_tau = sqrt(tw/rho) > Re_tau = u_tau*delta/dnu > > diff = (tw-ffx_new)/tw > if(nid.eq.0) write(6,1) istep,time,e2,ffx_new,diff > 1 format(i6,1p4e17.9,' err2') > > ! write statistics to file > iostep_avg = param(68) > if(nid.eq.0 .and. istep.gt.0 .and. > & mod(istep,iostep_avg).eq.0) then > write(6,*) 'Dumping statistics ...' > open(unit=56,file='reystresses.dat') > write(56,'(A,1pe14.7)') '#time = ', time > write(56,'(A)') > & '# y y+ R_uu R_vv R_ww R_uv' > open(unit=57,file='means.dat') > write(57,'(A,1pe14.7)') '#time = ', time > write(57,'(A)') > & '# y y+ Umean' > > m = ny1*nely/2 > > do i=1,m > write(56,3) yy(i)+1 > & ,(yy(i)+1)*Re_tau > & , (urms_pl(i)-(uavg_pl(i))**2)/u_tau**2 > & , vrms_pl(i)/u_tau**2 > & , wrms_pl(i)/u_tau**2 > & , uvms_pl(i)/u_tau**2 > write(57,3) yy(i) + 1. > & , (yy(i)+1.)*Re_tau > & , uavg_pl(i)/u_tau > 3 format(1p15e17.9) > enddo > > close(56) > close(57) > endif > > return > end > > I look into the code of navier5.f and find that avg1, avg2 returns the > time average of vx and vx**2 in this example, so if we want to calculate > the Reynolds stress, the formulation should be : > R_uu=urms-uavg**2 > also, if normalized, > R_uu=(urms-uavg**2)/u_tau**2 > so are the other components > I think this is the right way instead of that in the example > > > > > > > At 2014-05-29 06:54:10, nek5000-users at lists.mcs.anl.gov > wrote: > > > >Hi Xianbei, > > > >You can define more objects by picking your > >own surface discriminators (which will > >be dependent on your particular application). > > > >If you need more than 4 objects, you can increase maxobj > >in SIZE. > > > >Typically, dragx(0) would be the sum of the drag on all > >the objects --- this is sometimes useful. > > > >If you have (say) a 4-sided channel, you can just define > >one object instead of 4, and set it to be the collection > >of all faces for which cbc(f,e,1)='W '. > > > >Paul > > > > > > > >On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Hi,all: > > I read Paul's reply in this mail https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2014-May/002756.html > > > And got to know something about objects. As you say, the object is a collection of faces, here , I have a question about the iboj, how could I know which face it represent with iboj? As in turbChannel.usr, > > dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) > > I think it means to do the time-average of the average dragx on planey1 and planey2, as > > 0.5*(dragx(1)+dragx(2)) > > indicates, while how to calculate the dragx on the planex1, planex2, planez1 and planez2? for the maxobj in this example is only 4 and dragx is defined as > > dragx(0:maxobj) > > > >Thank you > >Xianbei > >_______________________________________________ > >Nek5000-users mailing list > >Nek5000-users at lists.mcs.anl.gov > >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > ?????????????? > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 29 19:24:24 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 May 2014 08:24:24 +0800 (CST) Subject: [Nek5000-users] About the iobj in the drag calculation In-Reply-To: References: Message-ID: Hi,Tanmoy: Thank you for your reply. Yes, the x and z are the homogenous directions, so vy_avg and vz_avg should be 0 in this way. I have another question on the output. I want to output the instaneous velocity field in the x y z vx vy vz format, so that I can do the energy spectrum and two-point correlation in the Matlab(in Nek5000, it's not so convenient to output Ek and two-point correlation directly, in my opinion). So I search the mailist and find a subroutine named 'sem2lex' which can convert us(ix,iy,iz,le) to ul(ix,ie,iy,je,iz,ke), my question is: how can I output this with a different timestep interval?I need more sample point of the instaneous velocity than the means. Xianbei At 2014-05-30 01:00:15, nek5000-users at lists.mcs.anl.gov wrote: Hi Xianbi, You are right in defining the Reynolds Stresses. However, if you look carefully, this is an example of fully developed turbulent Channel. Hence the statistics is independant of the x direction (streamwise). Also, the statistics is taken independant of z direction (no wall in z). x and z both have periodic BC. Hence before calculating R_uu, R_vv etc, we just do the spatial planar averaging in the xz plane. Since for homogeneous flow, that should equal an ensemble average. You can modify the turbChannel to a non-homogeneous flow, in which case you can define Reynolds stresses just like you said, and they would spatially varying. Thanks, Tanmoy On Thu, May 29, 2014 at 5:22 AM, wrote: Hi,Paul: I'm confused about part of the subroutine userchk in turbChannel.usr if(icalld.eq.0) then call rzero(uavg,n) call rzero(urms,n) call rzero(vrms,n) call rzero(wrms,n) call rzero(uvms,n) atime = 0. timel = time call planar_average_s(yy ,ym1 ,w1,w2) icalld = 1 endif dtime = time - timel atime = atime + dtime if (atime.ne.0. .and. dtime.ne.0.) then beta = dtime/atime alpha = 1.-beta ifverbose = .false. call avg1(uavg,vx ,alpha,beta,n,'uavg',ifverbose) call avg2(urms,vx ,alpha,beta,n,'urms',ifverbose) call avg2(vrms,vy ,alpha,beta,n,'vrms',ifverbose) call avg2(wrms,vz ,alpha,beta,n,'wrms',ifverbose) call avg3(uvms,vx,vy,alpha,beta,n,'uvmm',ifverbose) dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) ! averaging over statistical homogeneous directions (r-t) call planar_average_s(uavg_pl,uavg,w1,w2) call planar_average_s(urms_pl,urms,w1,w2) call planar_average_s(vrms_pl,vrms,w1,w2) call planar_average_s(wrms_pl,wrms,w1,w2) call planar_average_s(uvms_pl,uvms,w1,w2) ! average over half the channel height m = ny1*nely do i=1,ny1*nely/2 uavg_pl(i) = 0.5 * (uavg_pl(i) + uavg_pl(m-i+1)) urms_pl(i) = 0.5 * (urms_pl(i) + urms_pl(m-i+1)) vrms_pl(i) = 0.5 * (vrms_pl(i) + vrms_pl(m-i+1)) wrms_pl(i) = 0.5 * (wrms_pl(i) + wrms_pl(m-i+1)) enddo endif tw = dragx_avg/A_w + 1.e-50 u_tau = sqrt(tw/rho) Re_tau = u_tau*delta/dnu diff = (tw-ffx_new)/tw if(nid.eq.0) write(6,1) istep,time,e2,ffx_new,diff 1 format(i6,1p4e17.9,' err2') ! write statistics to file iostep_avg = param(68) if(nid.eq.0 .and. istep.gt.0 .and. & mod(istep,iostep_avg).eq.0) then write(6,*) 'Dumping statistics ...' open(unit=56,file='reystresses.dat') write(56,'(A,1pe14.7)') '#time = ', time write(56,'(A)') & '# y y+ R_uu R_vv R_ww R_uv' open(unit=57,file='means.dat') write(57,'(A,1pe14.7)') '#time = ', time write(57,'(A)') & '# y y+ Umean' m = ny1*nely/2 do i=1,m write(56,3) yy(i)+1 & ,(yy(i)+1)*Re_tau & , (urms_pl(i)-(uavg_pl(i))**2)/u_tau**2 & , vrms_pl(i)/u_tau**2 & , wrms_pl(i)/u_tau**2 & , uvms_pl(i)/u_tau**2 write(57,3) yy(i) + 1. & , (yy(i)+1.)*Re_tau & , uavg_pl(i)/u_tau 3 format(1p15e17.9) enddo close(56) close(57) endif return end I look into the code of navier5.f and find that avg1, avg2 returns the time average of vx and vx**2 in this example, so if we want to calculate the Reynolds stress, the formulation should be : R_uu=urms-uavg**2 also, if normalized, R_uu=(urms-uavg**2)/u_tau**2 so are the other components I think this is the right way instead of that in the example At 2014-05-29 06:54:10, nek5000-users at lists.mcs.anl.gov wrote: > >Hi Xianbei, > >You can define more objects by picking your >own surface discriminators (which will >be dependent on your particular application). > >If you need more than 4 objects, you can increase maxobj >in SIZE. > >Typically, dragx(0) would be the sum of the drag on all >the objects --- this is sometimes useful. > >If you have (say) a 4-sided channel, you can just define >one object instead of 4, and set it to be the collection >of all faces for which cbc(f,e,1)='W '. > >Paul > > > >On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi,all: > I read Paul's reply in this mail https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2014-May/002756.html > And got to know something about objects. As you say, the object is a collection of faces, here , I have a question about the iboj, how could I know which face it represent with iboj? As in turbChannel.usr, > dragx_avg = alpha*dragx_avg + beta*0.5*(dragx(1)+dragx(2)) > I think it means to do the time-average of the average dragx on planey1 and planey2, as > 0.5*(dragx(1)+dragx(2)) > indicates, while how to calculate the dragx on the planex1, planex2, planez1 and planez2? for the maxobj in this example is only 4 and dragx is defined as > dragx(0:maxobj) > >Thank you >Xianbei >_______________________________________________ >Nek5000-users mailing list >Nek5000-users at lists.mcs.anl.gov >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users ?????????????? _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 29 19:47:16 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 May 2014 00:47:16 +0000 Subject: [Nek5000-users] Questions in AXHELM and WLAPLACIAN In-Reply-To: References: Message-ID: Hi Paul, Thank you for your quick answer, this is really helpful. I still have a question concerning the computation of a gradient. Why did you construct the diffusion operator with the helmholtz routine? Why not using directly the routines gradm1 ? By the way I am not sure to understand the differences between gradm1 (navier5.f), wgradm1 (navier1.f) , gradm11 (navier2.f) and gradm11ts (navier2.f). I guess that the w letter refers to the weak formulation, but I don?t understand in which cases we need to choose a formulation instead of others. In summary, if I want to modify the temperature/passive scalar equations to add a term that contains a gradient of the solved temperature/PS variable, for example, which ?gradm? routine do I need to use? Thank you for your help ! Best regards, Emmanuel On 29 May 2014, at 20:20, nek5000-users at lists.mcs.anl.gov wrote: Hi Emmanuel, axhelm effects the weak Laplacian plus the mass matrix. Specifically, if you wanted to solve: (1) -nabla . [ h1 * nabla ] u + h2 * u = f with h1, h2, and f all functions of X=(x,y,z), the discrete form would be: (2) A(h1) u + B(h2) u = B f or (3) H u = B f where A is the (h1-dependent stiffness matrix and B(h2) is the h2-dependent mass matrix. For the SEM, B is diagonal, so B(h2) = h2*B, where we view h2 as a diagonal matrix. In Nek5000, a matrix-vector product w = Hu is effected via call axhelm (w,u,h1,h2,imesh,isd) with w,u,h1,h2 being arrarys. Here, imesh indicates if you are on the fluid mesh or thermal mesh. The fluid mesh is a subset of the thermal mesh in the case of conjugate heat transfer between a fluid and a solid. isd indicates which spatial direction is considered in axisymmetric applications where u is a component of a vector field. Notice the sign of the Laplacian in Eq. (1) -- that may help resolve your second question? (There is a sign change that ariss from the standard integration-by-parts stepin the weak form.) Paul On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: Dear nek5000 team, Could you help me with the 2 questions below? Thank you very much ! 1) Concerning the routine ?axhelm? in hmholtz.f. If I am right, one possibility of this routine can be the discretisation of the diffusion operator. However it is not clear to me if axhelm performs: a) vdiff x Laplacian(phi) or b) grad ( vdiff x grad (phi) ) phi being the variable solved for (T or PS for example). So, is it actually a) or b) ? 2) In the routine wlaplacian in navier1.f, I am not sure to understand the consequence of the line: call sub2 (out,wrk,ntot) after the lines: call bcneusc(out,1) call axhelm(wrk,a,diff,h2,imesh,1) If I am right, this will change the sign in front of the diffusion operator, right? Because in makeq.f, I am not sure that the line call add2(bq(1,1,1,1,ifield-1),w1,ntot) will actually assemble the RHS of the transport equation : - (vtrans) x U grad (phi) + grad ( vdiff x grad (phi) ) Thank you for your help ! Best regards, Emmanuel _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 29 19:55:39 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 May 2014 00:55:39 +0000 Subject: [Nek5000-users] Questions in AXHELM and WLAPLACIAN In-Reply-To: References: , Message-ID: Hi Emmanuel, Strictly speaking, our functions are only once differentiable -- they are C0, not C1. The test functions are also in H1 (i.e., are C0) and therefor the standard Galerkin approach is to transfer one derivative to the test functions via integration by parts and thus avoid twice differentiating a function. If you just want the gradient of something, you would use gradm1 (gradient for a quantity on mesh 1). Paul ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Thursday, May 29, 2014 7:47 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Questions in AXHELM and WLAPLACIAN Hi Paul, Thank you for your quick answer, this is really helpful. I still have a question concerning the computation of a gradient. Why did you construct the diffusion operator with the helmholtz routine? Why not using directly the routines gradm1 ? By the way I am not sure to understand the differences between gradm1 (navier5.f), wgradm1 (navier1.f) , gradm11 (navier2.f) and gradm11ts (navier2.f). I guess that the w letter refers to the weak formulation, but I don?t understand in which cases we need to choose a formulation instead of others. In summary, if I want to modify the temperature/passive scalar equations to add a term that contains a gradient of the solved temperature/PS variable, for example, which ?gradm? routine do I need to use? Thank you for your help ! Best regards, Emmanuel On 29 May 2014, at 20:20, nek5000-users at lists.mcs.anl.gov wrote: Hi Emmanuel, axhelm effects the weak Laplacian plus the mass matrix. Specifically, if you wanted to solve: (1) -nabla . [ h1 * nabla ] u + h2 * u = f with h1, h2, and f all functions of X=(x,y,z), the discrete form would be: (2) A(h1) u + B(h2) u = B f or (3) H u = B f where A is the (h1-dependent stiffness matrix and B(h2) is the h2-dependent mass matrix. For the SEM, B is diagonal, so B(h2) = h2*B, where we view h2 as a diagonal matrix. In Nek5000, a matrix-vector product w = Hu is effected via call axhelm (w,u,h1,h2,imesh,isd) with w,u,h1,h2 being arrarys. Here, imesh indicates if you are on the fluid mesh or thermal mesh. The fluid mesh is a subset of the thermal mesh in the case of conjugate heat transfer between a fluid and a solid. isd indicates which spatial direction is considered in axisymmetric applications where u is a component of a vector field. Notice the sign of the Laplacian in Eq. (1) -- that may help resolve your second question? (There is a sign change that ariss from the standard integration-by-parts stepin the weak form.) Paul On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: Dear nek5000 team, Could you help me with the 2 questions below? Thank you very much ! 1) Concerning the routine ?axhelm? in hmholtz.f. If I am right, one possibility of this routine can be the discretisation of the diffusion operator. However it is not clear to me if axhelm performs: a) vdiff x Laplacian(phi) or b) grad ( vdiff x grad (phi) ) phi being the variable solved for (T or PS for example). So, is it actually a) or b) ? 2) In the routine wlaplacian in navier1.f, I am not sure to understand the consequence of the line: call sub2 (out,wrk,ntot) after the lines: call bcneusc(out,1) call axhelm(wrk,a,diff,h2,imesh,1) If I am right, this will change the sign in front of the diffusion operator, right? Because in makeq.f, I am not sure that the line call add2(bq(1,1,1,1,ifield-1),w1,ntot) will actually assemble the RHS of the transport equation : - (vtrans) x U grad (phi) + grad ( vdiff x grad (phi) ) Thank you for your help ! Best regards, Emmanuel _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri May 30 07:35:16 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 May 2014 20:35:16 +0800 (CST) Subject: [Nek5000-users] strange output-duplicate points Message-ID: Hi,all: I run the turbChannel example, and find a strange thing related to output. In the means.dat, #time = 8.0000000E+01 # y y+ Umean 0.000000000E+00 0.000000000E+00 0.000000000E+00 2.565198406E-03 1.235928661E+00 1.240919300E+00 8.166000752E-03 3.934430317E+00 3.853070992E+00 1.581402413E-02 7.619295888E+00 6.748781538E+00 2.418599733E-02 1.165296502E+01 8.841965326E+00 3.183402071E-02 1.533783060E+01 1.011635642E+01 3.743482305E-02 1.803633225E+01 1.084184821E+01 4.000002146E-02 1.927226091E+01 1.113974222E+01 4.000002146E-02 1.927226091E+01 1.113974222E+01 take a look at the last two lines, it's same! So the solver output the duplicate values, how can I correct this strange behaviour? Have a nice weekend Xianbei -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri May 30 10:57:57 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 May 2014 15:57:57 +0000 Subject: [Nek5000-users] Questions in AXHELM and WLAPLACIAN In-Reply-To: References: , Message-ID: Hi Paul, Thank you for your answer, this is more clear now. Actually, as an exercice, I would like to try to replace in the routine wlaplacian the line call axhelm(wrk,a,diff,h2,imesh,1) by something which will looks like call gradm1(grad_ax,grad_ay,grad_az,a) call add4(sum_grad,grad_ax,grad_ay,grad_az,n) call col3(diff_grad_a,vdiff,sum_grad,n) call gradm1(lapac_x,laplac_y,laplac_z, diff_grad_a) call add4(laplacian, lapac_x, laplac_y, laplac_z,n) Does it makes sense or I?m going into a wrong direction? Best regards, Emmanuel On 30 May 2014, at 10:25, nek5000-users at lists.mcs.anl.gov wrote: Hi Emmanuel, Strictly speaking, our functions are only once differentiable -- they are C0, not C1. The test functions are also in H1 (i.e., are C0) and therefor the standard Galerkin approach is to transfer one derivative to the test functions via integration by parts and thus avoid twice differentiating a function. If you just want the gradient of something, you would use gradm1 (gradient for a quantity on mesh 1). Paul ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Thursday, May 29, 2014 7:47 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Questions in AXHELM and WLAPLACIAN Hi Paul, Thank you for your quick answer, this is really helpful. I still have a question concerning the computation of a gradient. Why did you construct the diffusion operator with the helmholtz routine? Why not using directly the routines gradm1 ? By the way I am not sure to understand the differences between gradm1 (navier5.f), wgradm1 (navier1.f) , gradm11 (navier2.f) and gradm11ts (navier2.f). I guess that the w letter refers to the weak formulation, but I don?t understand in which cases we need to choose a formulation instead of others. In summary, if I want to modify the temperature/passive scalar equations to add a term that contains a gradient of the solved temperature/PS variable, for example, which ?gradm? routine do I need to use? Thank you for your help ! Best regards, Emmanuel On 29 May 2014, at 20:20, nek5000-users at lists.mcs.anl.gov wrote: Hi Emmanuel, axhelm effects the weak Laplacian plus the mass matrix. Specifically, if you wanted to solve: (1) -nabla . [ h1 * nabla ] u + h2 * u = f with h1, h2, and f all functions of X=(x,y,z), the discrete form would be: (2) A(h1) u + B(h2) u = B f or (3) H u = B f where A is the (h1-dependent stiffness matrix and B(h2) is the h2-dependent mass matrix. For the SEM, B is diagonal, so B(h2) = h2*B, where we view h2 as a diagonal matrix. In Nek5000, a matrix-vector product w = Hu is effected via call axhelm (w,u,h1,h2,imesh,isd) with w,u,h1,h2 being arrarys. Here, imesh indicates if you are on the fluid mesh or thermal mesh. The fluid mesh is a subset of the thermal mesh in the case of conjugate heat transfer between a fluid and a solid. isd indicates which spatial direction is considered in axisymmetric applications where u is a component of a vector field. Notice the sign of the Laplacian in Eq. (1) -- that may help resolve your second question? (There is a sign change that ariss from the standard integration-by-parts stepin the weak form.) Paul On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: Dear nek5000 team, Could you help me with the 2 questions below? Thank you very much ! 1) Concerning the routine ?axhelm? in hmholtz.f. If I am right, one possibility of this routine can be the discretisation of the diffusion operator. However it is not clear to me if axhelm performs: a) vdiff x Laplacian(phi) or b) grad ( vdiff x grad (phi) ) phi being the variable solved for (T or PS for example). So, is it actually a) or b) ? 2) In the routine wlaplacian in navier1.f, I am not sure to understand the consequence of the line: call sub2 (out,wrk,ntot) after the lines: call bcneusc(out,1) call axhelm(wrk,a,diff,h2,imesh,1) If I am right, this will change the sign in front of the diffusion operator, right? Because in makeq.f, I am not sure that the line call add2(bq(1,1,1,1,ifield-1),w1,ntot) will actually assemble the RHS of the transport equation : - (vtrans) x U grad (phi) + grad ( vdiff x grad (phi) ) Thank you for your help ! Best regards, Emmanuel _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri May 30 11:17:44 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 May 2014 11:17:44 -0500 Subject: [Nek5000-users] About LELGEC in 'SIZE' file In-Reply-To: References: Message-ID: Hi, LELGEC is no longer being used in the current version of the code. Sorry for the confusion. Katherine On Mon, May 26, 2014 at 7:27 PM, wrote: > In turbChannel example, the 'SIZE' file, line 44, a note reads'Note: In > the new code, LELGEC should be about sqrt(LELG)', in this > example,lelg=520(line 20), while, 'LELGEC=1' (line 46), so is the version > of code not the new code? I have just downloaded it from the official site. > > > ?????????????? > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 31 03:47:15 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 31 May 2014 08:47:15 +0000 Subject: [Nek5000-users] Questions in AXHELM and WLAPLACIAN In-Reply-To: References: , Message-ID: Hi Paul I have some difficulties to compute a simple gradient of a variable. I think I?m confusing something. Basically I would like to modify the temperature and species equations to add a new term in order to take into account a velocity correction related to mass conservation and species diffusion coefficients. For temperature the equation is: d T /dt = term1 + term2 + term3 with term1 = - U grad (T) term2 = 1/rho Cp * grad ( lambda * grad (T)) term3 = 1/rho Cp * (rho * sum_k [Cp,k * (Y_k * D_k * grad(Y_k) - Y_k * sum_j [D_j * grad(Y_j )] ) ] ) * grad(T) and for species equation : d Y /dt = term1 + term2 + term3 with term1 = - U grad (Y) term2 = 1/rho Cp * grad ( lambda * grad (Y)) term3 = - 1/rho * grad (Y * sum_k [D_k * grad (Y_k) ] ) where D_k or D_j are the species diffusion coefficients, T the temperature and Y the species mass fraction. I am using the low-Mach number formulation and solving the equations with CVODE. Basically term1 is computed by the routine convab while term2 is computed by routine wlapacian. This is the current official nek implementation. Now I would like to add the term3, which involves some gradients of temperature or species variables. I think the simplest way is to modify the routine convab or maybe makeq.f However I tried a simple call gradm1 (Tx,Ty,Tz,T) but NEK crashes with a segmentation fault error. I tried to debug the routine gradm1, and it appears that it crashes during the loop do i=1,lxyz ux(i,e) =jacmi(i,e)*(ur(i)*rxm1(i,1,1,e) $ + us(i)*sxm1(i,1,1,e) ) uy(i,e) =jacmi(i,e)*(ur(i)*rym1(i,1,1,e) $ + us(i)*sym1(i,1,1,e) ) enddo after reaching a particular element e (in my case it crashes for element 9). So my questions are just: 1) According to the implementation of term3 in temperature and species equations, what is the best way to proceed? I have think about modifying convab or makeq but is it a good idea? 2) Is it a good idea to use gradm1? Why does it crash for a particular element? Should I pay attention to something in particular when using this routine? Thank you very much for your help ! Best regards, Emmanuel On 30 May 2014, at 10:25, nek5000-users at lists.mcs.anl.gov wrote: Hi Emmanuel, Strictly speaking, our functions are only once differentiable -- they are C0, not C1. The test functions are also in H1 (i.e., are C0) and therefor the standard Galerkin approach is to transfer one derivative to the test functions via integration by parts and thus avoid twice differentiating a function. If you just want the gradient of something, you would use gradm1 (gradient for a quantity on mesh 1). Paul ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Thursday, May 29, 2014 7:47 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Questions in AXHELM and WLAPLACIAN Hi Paul, Thank you for your quick answer, this is really helpful. I still have a question concerning the computation of a gradient. Why did you construct the diffusion operator with the helmholtz routine? Why not using directly the routines gradm1 ? By the way I am not sure to understand the differences between gradm1 (navier5.f), wgradm1 (navier1.f) , gradm11 (navier2.f) and gradm11ts (navier2.f). I guess that the w letter refers to the weak formulation, but I don?t understand in which cases we need to choose a formulation instead of others. In summary, if I want to modify the temperature/passive scalar equations to add a term that contains a gradient of the solved temperature/PS variable, for example, which ?gradm? routine do I need to use? Thank you for your help ! Best regards, Emmanuel On 29 May 2014, at 20:20, nek5000-users at lists.mcs.anl.gov wrote: Hi Emmanuel, axhelm effects the weak Laplacian plus the mass matrix. Specifically, if you wanted to solve: (1) -nabla . [ h1 * nabla ] u + h2 * u = f with h1, h2, and f all functions of X=(x,y,z), the discrete form would be: (2) A(h1) u + B(h2) u = B f or (3) H u = B f where A is the (h1-dependent stiffness matrix and B(h2) is the h2-dependent mass matrix. For the SEM, B is diagonal, so B(h2) = h2*B, where we view h2 as a diagonal matrix. In Nek5000, a matrix-vector product w = Hu is effected via call axhelm (w,u,h1,h2,imesh,isd) with w,u,h1,h2 being arrarys. Here, imesh indicates if you are on the fluid mesh or thermal mesh. The fluid mesh is a subset of the thermal mesh in the case of conjugate heat transfer between a fluid and a solid. isd indicates which spatial direction is considered in axisymmetric applications where u is a component of a vector field. Notice the sign of the Laplacian in Eq. (1) -- that may help resolve your second question? (There is a sign change that ariss from the standard integration-by-parts stepin the weak form.) Paul On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: Dear nek5000 team, Could you help me with the 2 questions below? Thank you very much ! 1) Concerning the routine ?axhelm? in hmholtz.f. If I am right, one possibility of this routine can be the discretisation of the diffusion operator. However it is not clear to me if axhelm performs: a) vdiff x Laplacian(phi) or b) grad ( vdiff x grad (phi) ) phi being the variable solved for (T or PS for example). So, is it actually a) or b) ? 2) In the routine wlaplacian in navier1.f, I am not sure to understand the consequence of the line: call sub2 (out,wrk,ntot) after the lines: call bcneusc(out,1) call axhelm(wrk,a,diff,h2,imesh,1) If I am right, this will change the sign in front of the diffusion operator, right? Because in makeq.f, I am not sure that the line call add2(bq(1,1,1,1,ifield-1),w1,ntot) will actually assemble the RHS of the transport equation : - (vtrans) x U grad (phi) + grad ( vdiff x grad (phi) ) Thank you for your help ! Best regards, Emmanuel _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 31 08:47:16 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 31 May 2014 21:47:16 +0800 (CST) Subject: [Nek5000-users] How to add Coriolis force In-Reply-To: References: Message-ID: Hi,Mike: Is there any difference by using ux and vx? As in the help, most frequently used is vx. However, when I use vx in the formulation, the compile turn out error. Xianbei At 2014-05-29 09:09:16, nek5000-users at lists.mcs.anl.gov wrote: Hi,Mike Thank you very much for you help. Now I have a question about the built-in variables. As the help document is not so sufficient, there are so many variables not introduced, so how can I find what's the meaning of the variables? I'm sorry to trouble you for this simple question, but it's really important to me. Thank you Xianbei ? 2014-05-28 11:53:58?nek5000-users at lists.mcs.anl.gov ??? >Xianbel, > >You can add the Coriolis term in the userf routine: > > omega = something > >c add coriolis forces > ffx = + 2.0*omega*uy > ffy = - 2.0*omega*ux > ffz = 0. > >Mike > > >On May 27, 2014, at 8:45 PM, > > wrote: > >Dear Neks; > I want to add Coriolis force to do a rotating simulation. As known, the Coriolis term is defined as 2*omega(cross product)U, so how can I add it to the N-S equation? Is there any example of similar case? > >Thank you >Xianbei > > >?????????????? >_______________________________________________ >Nek5000-users mailing list >Nek5000-users at lists.mcs.anl.gov >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >_______________________________________________ >Nek5000-users mailing list >Nek5000-users at lists.mcs.anl.gov >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users ?????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 31 09:04:11 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 31 May 2014 16:04:11 +0200 Subject: [Nek5000-users] How to add Coriolis force In-Reply-To: References: Message-ID: vx is the solution array, see the include file trunk/nek/SOLN whereas ux is just a real number which is filled with the velocity at the current evaluation point. So you should use ux in userf. Best praveen On Sat, May 31, 2014 at 3:47 PM, wrote: > Hi,Mike: > Is there any difference by using ux and vx? As in the help, most > frequently used is vx. However, when I use vx in the formulation, the > compile turn out error. > > Xianbei > > > > > > At 2014-05-29 09:09:16, nek5000-users at lists.mcs.anl.gov wrote: > > Hi,Mike > Thank you very much for you help. Now I have a question about the > built-in variables. As the help document is not so sufficient, there are so > many variables not introduced, so how can I find what's the meaning of the > variables? I'm sorry to trouble you for this simple question, but it's > really important to me. > > Thank you > Xianbei > > > > > > > ? 2014-05-28 11:53:58?nek5000-users at lists.mcs.anl.gov ??? > >Xianbel, > > > >You can add the Coriolis term in the userf routine: > > > > omega = something > > > >c add coriolis forces > > ffx = + 2.0*omega*uy > > ffy = - 2.0*omega*ux > > ffz = 0. > > > >Mike > > > > > >On May 27, 2014, at 8:45 PM, > > wrote: > > > >Dear Neks; > > I want to add Coriolis force to do a rotating simulation. As known, the Coriolis term is defined as 2*omega(cross product)U, so how can I add it to the N-S equation? Is there any example of similar case? > > > >Thank you > >Xianbei > > > > > >?????????????? > >_______________________________________________ > >Nek5000-users mailing list > >Nek5000-users at lists.mcs.anl.gov > >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > >_______________________________________________ > >Nek5000-users mailing list > >Nek5000-users at lists.mcs.anl.gov > >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > ?????????????? > > > > ?????????????? > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 31 09:18:44 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 31 May 2014 22:18:44 +0800 (CST) Subject: [Nek5000-users] How to add Coriolis force In-Reply-To: References: Message-ID: Hi,praveen: Thank you for your explaination, it's really helpful. By the way, I have two more questions(sorry, I'm really newer to Nek): 1/ Is there any way to map a coarse mesh solution to a finer mesh solution? 2/ When the "0 RESTART OPTIONS FOLLOW" is changed to '1 RESTART OPTIONS FOLLOW' with a specified field, is the average field been loaded in the starting? Because I do have some variables in the subroutine userchk, such as 'common /plane/ uavg_pl(ly1*lely)' At 2014-05-31 10:04:11, nek5000-users at lists.mcs.anl.gov wrote: vx is the solution array, see the include file trunk/nek/SOLN whereas ux is just a real number which is filled with the velocity at the current evaluation point. So you should use ux in userf. Best praveen On Sat, May 31, 2014 at 3:47 PM, wrote: Hi,Mike: Is there any difference by using ux and vx? As in the help, most frequently used is vx. However, when I use vx in the formulation, the compile turn out error. Xianbei At 2014-05-29 09:09:16, nek5000-users at lists.mcs.anl.gov wrote: Hi,Mike Thank you very much for you help. Now I have a question about the built-in variables. As the help document is not so sufficient, there are so many variables not introduced, so how can I find what's the meaning of the variables? I'm sorry to trouble you for this simple question, but it's really important to me. Thank you Xianbei ? 2014-05-28 11:53:58?nek5000-users at lists.mcs.anl.gov ??? >Xianbel, > >You can add the Coriolis term in the userf routine: > > omega = something > >c add coriolis forces > ffx = + 2.0*omega*uy > ffy = - 2.0*omega*ux > ffz = 0. > >Mike > > >On May 27, 2014, at 8:45 PM, > > wrote: > >Dear Neks; > I want to add Coriolis force to do a rotating simulation. As known, the Coriolis term is defined as 2*omega(cross product)U, so how can I add it to the N-S equation? Is there any example of similar case? > >Thank you >Xianbei > > >?????????????? >_______________________________________________ >Nek5000-users mailing list >Nek5000-users at lists.mcs.anl.gov >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >_______________________________________________ >Nek5000-users mailing list >Nek5000-users at lists.mcs.anl.gov >https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users ?????????????? ?????????????? _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 31 14:03:16 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 31 May 2014 21:03:16 +0200 Subject: [Nek5000-users] Checking convergence to steady solution Message-ID: Hello neks I am computing flow past 2d cylinder at Re=100. To get steady solution I run the unsteady solver with selective frequency damping. Looking at the forces on the cylinder and visualizing the solution I can see that I am getting a steady solution. But I would like to also quantitatively measure the convergence to the steady state. Is there a way that I can compute some residual to measure convergence to steady state ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 31 14:22:21 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 31 May 2014 21:22:21 +0200 Subject: [Nek5000-users] Checking convergence to steady solution In-Reply-To: References: Message-ID: Hi praveen, Yes you can .. call opsub2(uo,vo,wo,vx,vy,vz) call normvc(H1,SEMI,L2,LINF,uo,vo,wo) residu = L2/dt call opcopy(uo,vo,wo,vx,vy,vz) The subroutine 1) opsub2 computes the difference between the previous time-step and the current for velocity uo = uo - vx .. 2) Normvc computes the L2-norm. 3) opcopy copies the [vx,vy,vz] to [uo,vo,wo] to use it for next time step you can write the the value of residu to a separate file or to the logfile to see it. Best regards, Kamal On 31 May 2014, at 21:03, nek5000-users at lists.mcs.anl.gov wrote: > Hello neks > I am computing flow past 2d cylinder at Re=100. To get steady solution I run the unsteady solver with selective frequency damping. Looking at the forces on the cylinder and visualizing the solution I can see that I am getting a steady solution. But I would like to also quantitatively measure the convergence to the steady state. Is there a way that I can compute some residual to measure convergence to steady state ? > Thanks > praveen > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Sat May 31 18:19:50 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 31 May 2014 23:19:50 +0000 Subject: [Nek5000-users] Questions in AXHELM and WLAPLACIAN In-Reply-To: References: , , Message-ID: Hi Emmanuel, Regarding the gradm1() crash, did you declare Tx,Ty, and Tz in a new common block of your own creation? This would be important to do. Regarding where to modify the code - the most common approach is to create a new routine (say, "subroutine make_term3") which generates the required source terms when called once per timestep from userchk. You would store these source terms in an array and then load from this array in the userq() routine, which is called point-by-point, field-by-field, by nek as needed. Regarding your earlier email about replacing axhelm, the strategy you propose would not give the desired result. My suggestion would be to look carefully at some of the FEM/SEM literature. There are a couple of JCP papers by Tomboulides & Orszag (for low Mach), my 97 JCP paper (on Schwarz, but generally on the SEM discretization), and the book High Order Methods for Incompressible Flow with Deville & Mund. Please let me know if you have further questions. Best, Paul ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Saturday, May 31, 2014 3:47 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Questions in AXHELM and WLAPLACIAN Hi Paul I have some difficulties to compute a simple gradient of a variable. I think I?m confusing something. Basically I would like to modify the temperature and species equations to add a new term in order to take into account a velocity correction related to mass conservation and species diffusion coefficients. For temperature the equation is: d T /dt = term1 + term2 + term3 with term1 = - U grad (T) term2 = 1/rho Cp * grad ( lambda * grad (T)) term3 = 1/rho Cp * (rho * sum_k [Cp,k * (Y_k * D_k * grad(Y_k) - Y_k * sum_j [D_j * grad(Y_j )] ) ] ) * grad(T) and for species equation : d Y /dt = term1 + term2 + term3 with term1 = - U grad (Y) term2 = 1/rho Cp * grad ( lambda * grad (Y)) term3 = - 1/rho * grad (Y * sum_k [D_k * grad (Y_k) ] ) where D_k or D_j are the species diffusion coefficients, T the temperature and Y the species mass fraction. I am using the low-Mach number formulation and solving the equations with CVODE. Basically term1 is computed by the routine convab while term2 is computed by routine wlapacian. This is the current official nek implementation. Now I would like to add the term3, which involves some gradients of temperature or species variables. I think the simplest way is to modify the routine convab or maybe makeq.f However I tried a simple call gradm1 (Tx,Ty,Tz,T) but NEK crashes with a segmentation fault error. I tried to debug the routine gradm1, and it appears that it crashes during the loop do i=1,lxyz ux(i,e) =jacmi(i,e)*(ur(i)*rxm1(i,1,1,e) $ + us(i)*sxm1(i,1,1,e) ) uy(i,e) =jacmi(i,e)*(ur(i)*rym1(i,1,1,e) $ + us(i)*sym1(i,1,1,e) ) enddo after reaching a particular element e (in my case it crashes for element 9). So my questions are just: 1) According to the implementation of term3 in temperature and species equations, what is the best way to proceed? I have think about modifying convab or makeq but is it a good idea? 2) Is it a good idea to use gradm1? Why does it crash for a particular element? Should I pay attention to something in particular when using this routine? Thank you very much for your help ! Best regards, Emmanuel On 30 May 2014, at 10:25, nek5000-users at lists.mcs.anl.gov wrote: Hi Emmanuel, Strictly speaking, our functions are only once differentiable -- they are C0, not C1. The test functions are also in H1 (i.e., are C0) and therefor the standard Galerkin approach is to transfer one derivative to the test functions via integration by parts and thus avoid twice differentiating a function. If you just want the gradient of something, you would use gradm1 (gradient for a quantity on mesh 1). Paul ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Thursday, May 29, 2014 7:47 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Questions in AXHELM and WLAPLACIAN Hi Paul, Thank you for your quick answer, this is really helpful. I still have a question concerning the computation of a gradient. Why did you construct the diffusion operator with the helmholtz routine? Why not using directly the routines gradm1 ? By the way I am not sure to understand the differences between gradm1 (navier5.f), wgradm1 (navier1.f) , gradm11 (navier2.f) and gradm11ts (navier2.f). I guess that the w letter refers to the weak formulation, but I don?t understand in which cases we need to choose a formulation instead of others. In summary, if I want to modify the temperature/passive scalar equations to add a term that contains a gradient of the solved temperature/PS variable, for example, which ?gradm? routine do I need to use? Thank you for your help ! Best regards, Emmanuel On 29 May 2014, at 20:20, nek5000-users at lists.mcs.anl.gov wrote: Hi Emmanuel, axhelm effects the weak Laplacian plus the mass matrix. Specifically, if you wanted to solve: (1) -nabla . [ h1 * nabla ] u + h2 * u = f with h1, h2, and f all functions of X=(x,y,z), the discrete form would be: (2) A(h1) u + B(h2) u = B f or (3) H u = B f where A is the (h1-dependent stiffness matrix and B(h2) is the h2-dependent mass matrix. For the SEM, B is diagonal, so B(h2) = h2*B, where we view h2 as a diagonal matrix. In Nek5000, a matrix-vector product w = Hu is effected via call axhelm (w,u,h1,h2,imesh,isd) with w,u,h1,h2 being arrarys. Here, imesh indicates if you are on the fluid mesh or thermal mesh. The fluid mesh is a subset of the thermal mesh in the case of conjugate heat transfer between a fluid and a solid. isd indicates which spatial direction is considered in axisymmetric applications where u is a component of a vector field. Notice the sign of the Laplacian in Eq. (1) -- that may help resolve your second question? (There is a sign change that ariss from the standard integration-by-parts stepin the weak form.) Paul On Thu, 29 May 2014, nek5000-users at lists.mcs.anl.gov wrote: Dear nek5000 team, Could you help me with the 2 questions below? Thank you very much ! 1) Concerning the routine ?axhelm? in hmholtz.f. If I am right, one possibility of this routine can be the discretisation of the diffusion operator. However it is not clear to me if axhelm performs: a) vdiff x Laplacian(phi) or b) grad ( vdiff x grad (phi) ) phi being the variable solved for (T or PS for example). So, is it actually a) or b) ? 2) In the routine wlaplacian in navier1.f, I am not sure to understand the consequence of the line: call sub2 (out,wrk,ntot) after the lines: call bcneusc(out,1) call axhelm(wrk,a,diff,h2,imesh,1) If I am right, this will change the sign in front of the diffusion operator, right? Because in makeq.f, I am not sure that the line call add2(bq(1,1,1,1,ifield-1),w1,ntot) will actually assemble the RHS of the transport equation : - (vtrans) x U grad (phi) + grad ( vdiff x grad (phi) ) Thank you for your help ! Best regards, Emmanuel _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 31 21:58:25 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 1 Jun 2014 10:58:25 +0800 (CST) Subject: [Nek5000-users] test of the time average of turbChannel--what's wrong? Message-ID: Hi, all: I read about the time average method in the turbChannel.usr/userchk,here is the origin codes: if(icalld.eq.0) then call rzero(uavg,n) call rzero(urms,n) call rzero(vrms,n) call rzero(wrms,n) call rzero(uvms,n) atime = 0. timel = time call planar_average_s(yy ,ym1 ,w1,w2) icalld = 1 endif dtime = time - timel atime = atime + dtime if (atime.ne.0. .and. dtime.ne.0.) then beta = dtime/atime alpha = 1.-beta ifverbose = .false. call avg1(uavg,vx ,alpha,beta,n,'uavg',ifverbose) As seen , atime and timel is initialized by 0 and time, so when time=time+DT, dtime=DT, atime=DT, so the first average value is vx(t=DT), when time=time+2*DT, dtime=2*DT(timel is not changed, just equal to the initial value ),atime=3*DT, here question comes: this will lead to vxmean(t=2*DT)=2/3*vx(t=DT)+1/3*vx(t=2*DT), this is not what we respect. The right one is make sure that dtime=DT all the time. Also, I do a test to verify this.In order to be more reliable, the velocity isn't nomorlized by u_tau. First, calculate by 1 step and output the means.dat, so the value equal to the time=DT's #time = 2.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.031155153E-02 0.000000000E+00 2.565198406E-03 2.031155153E-02 1.285886819E-02 then restart with the field from previous calculation and output the means.dat, this will output the value of time=2*DT's, #time = 4.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.072569248E-02 0.000000000E+00 2.565205097E-03 2.072569248E-02 1.288671376E-02 At last, restart the calculation and run 2 steps to calculate the average of vx(time=DT) and vx(time=2*DT) #time = 4.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.061649552E-02 0.000000000E+00 2.565198406E-03 2.061649552E-02 1.287524390E-02 As can be seen, the 2 step average is almost equal to the average of step 1 and step 2. So what's wrong with my understanding? Is timel alway updated to the previous time and make sure that dtime=constant? How? Can anyone help? Xianbei -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 31 22:28:43 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 1 Jun 2014 11:28:43 +0800 (CST) Subject: [Nek5000-users] test of the time average of turbChannel--what's wrong? In-Reply-To: References: Message-ID: By the way, I output the beta and alpha at time=2*DT, #time = 4.0000000E-02 # y alpha Umean 0.000000000E+00 3.333333333E-01 0.000000000E+00 #time = 4.0000000E-02 # y beta R_uu R_vv R_ww R_uv 0.000000000E+00 6.666666667E-01 0.000000000E+00 0.000000000E+00 0.000000000E+00 0.000000000E+00 Here, alpha=1/3 and beta=2/3, just as I mentioned before. ? 2014-06-01 10:58:25?nek5000-users at lists.mcs.anl.gov ??? Hi, all: I read about the time average method in the turbChannel.usr/userchk,here is the origin codes: if(icalld.eq.0) then call rzero(uavg,n) call rzero(urms,n) call rzero(vrms,n) call rzero(wrms,n) call rzero(uvms,n) atime = 0. timel = time call planar_average_s(yy ,ym1 ,w1,w2) icalld = 1 endif dtime = time - timel atime = atime + dtime if (atime.ne.0. .and. dtime.ne.0.) then beta = dtime/atime alpha = 1.-beta ifverbose = .false. call avg1(uavg,vx ,alpha,beta,n,'uavg',ifverbose) As seen , atime and timel is initialized by 0 and time, so when time=time+DT, dtime=DT, atime=DT, so the first average value is vx(t=DT), when time=time+2*DT, dtime=2*DT(timel is not changed, just equal to the initial value ),atime=3*DT, here question comes: this will lead to vxmean(t=2*DT)=2/3*vx(t=DT)+1/3*vx(t=2*DT), this is not what we respect. The right one is make sure that dtime=DT all the time. Also, I do a test to verify this.In order to be more reliable, the velocity isn't nomorlized by u_tau. First, calculate by 1 step and output the means.dat, so the value equal to the time=DT's #time = 2.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.031155153E-02 0.000000000E+00 2.565198406E-03 2.031155153E-02 1.285886819E-02 then restart with the field from previous calculation and output the means.dat, this will output the value of time=2*DT's, #time = 4.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.072569248E-02 0.000000000E+00 2.565205097E-03 2.072569248E-02 1.288671376E-02 At last, restart the calculation and run 2 steps to calculate the average of vx(time=DT) and vx(time=2*DT) #time = 4.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.061649552E-02 0.000000000E+00 2.565198406E-03 2.061649552E-02 1.287524390E-02 As can be seen, the 2 step average is almost equal to the average of step 1 and step 2. So what's wrong with my understanding? Is timel alway updated to the previous time and make sure that dtime=constant? How? Can anyone help? Xianbei ?????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 31 22:38:01 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 1 Jun 2014 03:38:01 +0000 Subject: [Nek5000-users] test of the time average of turbChannel--what's wrong? In-Reply-To: References: Message-ID: Hi Xianbei, The usr files are meant to be modified by the users, so you can adjust it to suit your needs. Paul ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Saturday, May 31, 2014 9:58 PM To: Nek5000 Subject: [Nek5000-users] test of the time average of turbChannel--what's wrong? Hi, all: I read about the time average method in the turbChannel.usr/userchk,here is the origin codes: if(icalld.eq.0) then call rzero(uavg,n) call rzero(urms,n) call rzero(vrms,n) call rzero(wrms,n) call rzero(uvms,n) atime = 0. timel = time call planar_average_s(yy ,ym1 ,w1,w2) icalld = 1 endif dtime = time - timel atime = atime + dtime if (atime.ne.0. .and. dtime.ne.0.) then beta = dtime/atime alpha = 1.-beta ifverbose = .false. call avg1(uavg,vx ,alpha,beta,n,'uavg',ifverbose) As seen , atime and timel is initialized by 0 and time, so when time=time+DT, dtime=DT, atime=DT, so the first average value is vx(t=DT), when time=time+2*DT, dtime=2*DT(timel is not changed, just equal to the initial value ),atime=3*DT, here question comes: this will lead to vxmean(t=2*DT)=2/3*vx(t=DT)+1/3*vx(t=2*DT), this is not what we respect. The right one is make sure that dtime=DT all the time. Also, I do a test to verify this.In order to be more reliable, the velocity isn't nomorlized by u_tau. First, calculate by 1 step and output the means.dat, so the value equal to the time=DT's #time = 2.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.031155153E-02 0.000000000E+00 2.565198406E-03 2.031155153E-02 1.285886819E-02 then restart with the field from previous calculation and output the means.dat, this will output the value of time=2*DT's, #time = 4.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.072569248E-02 0.000000000E+00 2.565205097E-03 2.072569248E-02 1.288671376E-02 At last, restart the calculation and run 2 steps to calculate the average of vx(time=DT) and vx(time=2*DT) #time = 4.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.061649552E-02 0.000000000E+00 2.565198406E-03 2.061649552E-02 1.287524390E-02 As can be seen, the 2 step average is almost equal to the average of step 1 and step 2. So what's wrong with my understanding? Is timel alway updated to the previous time and make sure that dtime=constant? How? Can anyone help? Xianbei ?????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat May 31 23:31:52 2014 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 1 Jun 2014 04:31:52 +0000 Subject: [Nek5000-users] test of the time average of turbChannel--what's wrong? In-Reply-To: References: , Message-ID: Hi Xianbei, You are correct that dtime should be equal to DT. If you look at avg_all() in navier5.f in the main nek source directory, this is what happens because timel is updated after the averaging. In the turbchannel case, this was not done - so I've now modified the .usr file to reflect this. I would suggest to simply use the avg_all code to do the time averaging and then to use those average fields to generate profiles. Thanks for pointing out the problem with the turbChannel example. Paul ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Saturday, May 31, 2014 10:38 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] test of the time average of turbChannel--what's wrong? Hi Xianbei, The usr files are meant to be modified by the users, so you can adjust it to suit your needs. Paul ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Saturday, May 31, 2014 9:58 PM To: Nek5000 Subject: [Nek5000-users] test of the time average of turbChannel--what's wrong? Hi, all: I read about the time average method in the turbChannel.usr/userchk,here is the origin codes: if(icalld.eq.0) then call rzero(uavg,n) call rzero(urms,n) call rzero(vrms,n) call rzero(wrms,n) call rzero(uvms,n) atime = 0. timel = time call planar_average_s(yy ,ym1 ,w1,w2) icalld = 1 endif dtime = time - timel atime = atime + dtime if (atime.ne.0. .and. dtime.ne.0.) then beta = dtime/atime alpha = 1.-beta ifverbose = .false. call avg1(uavg,vx ,alpha,beta,n,'uavg',ifverbose) As seen , atime and timel is initialized by 0 and time, so when time=time+DT, dtime=DT, atime=DT, so the first average value is vx(t=DT), when time=time+2*DT, dtime=2*DT(timel is not changed, just equal to the initial value ),atime=3*DT, here question comes: this will lead to vxmean(t=2*DT)=2/3*vx(t=DT)+1/3*vx(t=2*DT), this is not what we respect. The right one is make sure that dtime=DT all the time. Also, I do a test to verify this.In order to be more reliable, the velocity isn't nomorlized by u_tau. First, calculate by 1 step and output the means.dat, so the value equal to the time=DT's #time = 2.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.031155153E-02 0.000000000E+00 2.565198406E-03 2.031155153E-02 1.285886819E-02 then restart with the field from previous calculation and output the means.dat, this will output the value of time=2*DT's, #time = 4.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.072569248E-02 0.000000000E+00 2.565205097E-03 2.072569248E-02 1.288671376E-02 At last, restart the calculation and run 2 steps to calculate the average of vx(time=DT) and vx(time=2*DT) #time = 4.0000000E-02 # y uup_tau Umean 0.000000000E+00 2.061649552E-02 0.000000000E+00 2.565198406E-03 2.061649552E-02 1.287524390E-02 As can be seen, the 2 step average is almost equal to the average of step 1 and step 2. So what's wrong with my understanding? Is timel alway updated to the previous time and make sure that dtime=constant? How? Can anyone help? Xianbei ?????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: