From nek5000-users at lists.mcs.anl.gov Fri Sep 2 10:27:01 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 2 Sep 2011 10:27:01 -0500 Subject: [Nek5000-users] Explicit Viscosity for Pn-Pn Message-ID: Howdy Neks, I had a question about using variable viscosity with the Pn-Pn formulation. I know I need to have ifuservp and ifexplvis set to TRUE. Looking through the source code, I see that how it works is the viscosity is split into an implicit part (nu_star) and explicit. My question is, how is nu_star set? Doing a grep on the source code, I don't see where it is set anywhere. So, is this something left up to the user? Thank you, -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Fri Sep 2 10:52:14 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 2 Sep 2011 10:52:14 -0500 (CDT) Subject: [Nek5000-users] Explicit Viscosity for Pn-Pn In-Reply-To: References: Message-ID: Hi Josh, Yes nu_star can be set by the user. A cautionary note --- I've tested this on some semi-analytic cases and it gives the same results as the Pn-Pn-2 formulation, which has a well-tested variable viscosity formulation for the full stress tensor. Consequently, I was happy with it. On the other hand, it seems that it does not work as well as the explicit viscosity formulation set up by Stefan for the dynamic Smagorinsky model applied to turbulent flows. I've not had time to sort this out yet. Thus, there'd be some benefit to testing beforehand... I'll be happy to work with you on this. Paul On Fri, 2 Sep 2011, nek5000-users at lists.mcs.anl.gov wrote: > Howdy Neks, > > I had a question about using variable viscosity with the Pn-Pn formulation. > > I know I need to have ifuservp and ifexplvis set to TRUE. Looking > through the source code, I see that how it works is the viscosity is > split into an implicit part (nu_star) and explicit. > > My question is, how is nu_star set? Doing a grep on the source code, > I don't see where it is set anywhere. So, is this something left up > to the user? > > Thank you, > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > 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 Sep 2 10:53:23 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 2 Sep 2011 17:53:23 +0200 Subject: [Nek5000-users] Explicit Viscosity for Pn-Pn In-Reply-To: References: Message-ID: Hi Josh Looks like this has changed. I thing you are right, the constant implicit part (nu_star) defined in the SOLN CB has to be provided by the user now. -Stefan On 9/2/11, nek5000-users at lists.mcs.anl.gov wrote: > Howdy Neks, > > I had a question about using variable viscosity with the Pn-Pn formulation. > > I know I need to have ifuservp and ifexplvis set to TRUE. Looking > through the source code, I see that how it works is the viscosity is > split into an implicit part (nu_star) and explicit. > > My question is, how is nu_star set? Doing a grep on the source code, > I don't see where it is set anywhere. So, is this something left up > to the user? > > Thank you, > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > 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 Sep 6 12:13:45 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 6 Sep 2011 11:13:45 -0600 Subject: [Nek5000-users] Non-Newtonian flows: nek options Message-ID: <82DB21E9-3D02-471D-ABAB-C2F0D7F88DAA@nrel.gov> Hi Neks. I'm trying to get Nek to work for a non-Newtonian incompressible fluid. I'm considering a Herschel-Bulkley fluid, whose yield-stress behavior I model with a regularized representation (defined as udiff in subroutine uservp). In this approach, the viscosity gets HUGE (e.g. 1e7) as the strain rate goes to zero. The two main challenges that I face are (i) an excessive number of Helmholtz-solve iterations and (ii) torque-magnitude calculations that are several orders of magnitude greater than I was expecting. Below is my understanding of what I can and should do with nek. Please verify that this is all correct, and please clarify if I have any misunderstanding: 1) I must use the stress formulation: IFSTRS = T 2) The stress formulation only works with PN/PN-2, not PN-PN, e.g. ABORT: Stress formulation in Pn-Pn is not supported 3) The viscous term in the stress formulation is treated implicitly; there's no nu_star option for the stress formulation, where one can treat a portion of the viscous term explicitly. 4) The torque_calc routine should work with this variable viscosity setup. A few more notes: -- I found my velocity system to be difficult to solve, and I had to increase the maximum iterations for the solve: I increased NMXH from 100 to 1000 (or greater) in drive2.f -- Per Paul's advice, I've set 0.000000E-05 p021 DIVERGENCE <--- set these to zero 0.000000E-08 p022 HELMHOLTZ <--- set these to zero 0.00000 p023 NPSCAL 0.100000E-01 p024 TOLREL <--- this is the important one 0.100000E-01 p025 TOLABS Does anyone have any additional tips or insights that might be helpful in solving such a system? Thanks. --Mike From nek5000-users at lists.mcs.anl.gov Thu Sep 8 09:56:55 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 8 Sep 2011 16:56:55 +0200 Subject: [Nek5000-users] possibly starting to use nekton, questions Message-ID: Hi all, I'm considering to start using Nekton. I would like to simulate a spatially evolving 3D boundary layer with a spanwise array of cylinders poking out of the flat wall. The cylinders would also move up and down in the wall normal direction, generating a time-varying disturbance. My goal is to delay bypass transition by dampening this disturbance via feedback control of localized body forces near the wall. Does Nekton currently have these aspects implemented, namely: 1. spatially evolving boundary layer at transitional Re (Re based on displacement thickness of at least ~1000) 2. cylinders independently poking up and down with prescribed height as function of time 3. feedback control with multiple inputs and outputs 4. multiple arbitrary body forces, with independent magnitudes given by the feedback controller or as a function of time 5. ability to calculate the perturbation velocity from laminar for feedback control 6. linear and nonlinear cases (for 1-5) If the control and/or body force parts are not implemented, I'm considering using Nekton to get the wake behind the cylinders and feeding this to a simpler code that can't simulate them directly but would have control and body force aspects. Thanks for your guidance! Brandt -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Sep 8 11:25:09 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 8 Sep 2011 11:25:09 -0500 (CDT) Subject: [Nek5000-users] Non-Newtonian flows: nek options In-Reply-To: <82DB21E9-3D02-471D-ABAB-C2F0D7F88DAA@nrel.gov> Message-ID: <1711501739.285860.1315499109521.JavaMail.root@zimbra.anl.gov> Hi Mike, I have not worked with stress formulation yet but I wanted to point out that torque_calc routine in the current form won't work for variable viscosity since vdiff array for viscosity in drqtrq() is filled by constant param(2) -- navier5.f:3586 if (istep.lt.1) call cfill(vdiff,param(2),n) ... call drgtrq(dgtq,xm0,ym0,zm0,sij,pm1,vdiff,ifc,ie) ... subroutine drgtrq(dgtq,xm0,ym0,zm0,sij,pm1,visc,f,e) Have you also checked the demonstration example nek5_svn/examples/var_vis/st2.* ? Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Tuesday, September 6, 2011 12:13:45 PM Subject: [Nek5000-users] Non-Newtonian flows: nek options Hi Neks. I'm trying to get Nek to work for a non-Newtonian incompressible fluid. I'm considering a Herschel-Bulkley fluid, whose yield-stress behavior I model with a regularized representation (defined as udiff in subroutine uservp). In this approach, the viscosity gets HUGE (e.g. 1e7) as the strain rate goes to zero. The two main challenges that I face are (i) an excessive number of Helmholtz-solve iterations and (ii) torque-magnitude calculations that are several orders of magnitude greater than I was expecting. Below is my understanding of what I can and should do with nek. Please verify that this is all correct, and please clarify if I have any misunderstanding: 1) I must use the stress formulation: IFSTRS = T 2) The stress formulation only works with PN/PN-2, not PN-PN, e.g. ABORT: Stress formulation in Pn-Pn is not supported 3) The viscous term in the stress formulation is treated implicitly; there's no nu_star option for the stress formulation, where one can treat a portion of the viscous term explicitly. 4) The torque_calc routine should work with this variable viscosity setup. A few more notes: -- I found my velocity system to be difficult to solve, and I had to increase the maximum iterations for the solve: I increased NMXH from 100 to 1000 (or greater) in drive2.f -- Per Paul's advice, I've set 0.000000E-05 p021 DIVERGENCE <--- set these to zero 0.000000E-08 p022 HELMHOLTZ <--- set these to zero 0.00000 p023 NPSCAL 0.100000E-01 p024 TOLREL <--- this is the important one 0.100000E-01 p025 TOLABS Does anyone have any additional tips or insights that might be helpful in solving such a system? Thanks. --Mike _______________________________________________ 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 Sep 8 11:39:06 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 8 Sep 2011 10:39:06 -0600 Subject: [Nek5000-users] Non-Newtonian flows: nek options In-Reply-To: <1711501739.285860.1315499109521.JavaMail.root@zimbra.anl.gov> References: <1711501739.285860.1315499109521.JavaMail.root@zimbra.anl.gov> Message-ID: Aleks, Thanks for the response. In regard to the torque_calc routine and variable viscosity, vdiff is filled with param(2) for the first calculation, but isn't vdiff then defined by udiff (as defined in uservp) for all subsequent steps? Yes, my current implementation is closely related to the example in var_vis. --Mike On Sep 8, 2011, at 10:25 AM, wrote: > Hi Mike, > > I have not worked with stress formulation yet but I wanted to point out that torque_calc routine in the current form won't work for variable viscosity since vdiff array for viscosity in drqtrq() is filled by constant param(2) -- navier5.f:3586 > > if (istep.lt.1) call cfill(vdiff,param(2),n) > ... > call drgtrq(dgtq,xm0,ym0,zm0,sij,pm1,vdiff,ifc,ie) > ... > subroutine drgtrq(dgtq,xm0,ym0,zm0,sij,pm1,visc,f,e) > > Have you also checked the demonstration example nek5_svn/examples/var_vis/st2.* ? > > Best, > Aleks > > > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Tuesday, September 6, 2011 12:13:45 PM > Subject: [Nek5000-users] Non-Newtonian flows: nek options > > Hi Neks. > > I'm trying to get Nek to work for a non-Newtonian incompressible fluid. I'm considering a Herschel-Bulkley fluid, whose yield-stress behavior I model with a regularized representation (defined as udiff in subroutine uservp). > > In this approach, the viscosity gets HUGE (e.g. 1e7) as the strain rate goes to zero. > > The two main challenges that I face are (i) an excessive number of Helmholtz-solve iterations and (ii) torque-magnitude calculations that are several orders of magnitude greater than I was expecting. > > Below is my understanding of what I can and should do with nek. Please verify that this is all correct, and please clarify if I have any misunderstanding: > > 1) I must use the stress formulation: IFSTRS = T > > 2) The stress formulation only works with PN/PN-2, not PN-PN, e.g. > > ABORT: Stress formulation in Pn-Pn is not supported > > 3) The viscous term in the stress formulation is treated implicitly; there's no nu_star option for the stress formulation, where one can treat a portion of the viscous term explicitly. > > 4) The torque_calc routine should work with this variable viscosity setup. > > A few more notes: > > -- I found my velocity system to be difficult to solve, and I had to increase the maximum iterations for the solve: I increased NMXH from 100 to 1000 (or greater) in drive2.f > > -- Per Paul's advice, I've set > 0.000000E-05 p021 DIVERGENCE <--- set these to zero > 0.000000E-08 p022 HELMHOLTZ <--- set these to zero > 0.00000 p023 NPSCAL > 0.100000E-01 p024 TOLREL <--- this is the important one > 0.100000E-01 p025 TOLABS > > Does anyone have any additional tips or insights that might be helpful in solving such a system? > > Thanks. > --Mike > > _______________________________________________ > 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 Sep 8 13:35:34 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 8 Sep 2011 13:35:34 -0500 (CDT) Subject: [Nek5000-users] Non-Newtonian flows: nek options In-Reply-To: Message-ID: <1859769699.286434.1315506934805.JavaMail.root@zimbra.anl.gov> Good point, Mike -- you are right, vdiff(*,*,*,*,1) is overwritten by udiff in uservp of .usr once you set ifuservp = .true. Have you tried more moderate conditions when viscosity does not get so large? Thanks, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Thursday, September 8, 2011 11:39:06 AM Subject: Re: [Nek5000-users] Non-Newtonian flows: nek options Aleks, Thanks for the response. In regard to the torque_calc routine and variable viscosity, vdiff is filled with param(2) for the first calculation, but isn't vdiff then defined by udiff (as defined in uservp) for all subsequent steps? Yes, my current implementation is closely related to the example in var_vis. --Mike On Sep 8, 2011, at 10:25 AM, wrote: > Hi Mike, > > I have not worked with stress formulation yet but I wanted to point out that torque_calc routine in the current form won't work for variable viscosity since vdiff array for viscosity in drqtrq() is filled by constant param(2) -- navier5.f:3586 > > if (istep.lt.1) call cfill(vdiff,param(2),n) > ... > call drgtrq(dgtq,xm0,ym0,zm0,sij,pm1,vdiff,ifc,ie) > ... > subroutine drgtrq(dgtq,xm0,ym0,zm0,sij,pm1,visc,f,e) > > Have you also checked the demonstration example nek5_svn/examples/var_vis/st2.* ? > > Best, > Aleks > > > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Tuesday, September 6, 2011 12:13:45 PM > Subject: [Nek5000-users] Non-Newtonian flows: nek options > > Hi Neks. > > I'm trying to get Nek to work for a non-Newtonian incompressible fluid. I'm considering a Herschel-Bulkley fluid, whose yield-stress behavior I model with a regularized representation (defined as udiff in subroutine uservp). > > In this approach, the viscosity gets HUGE (e.g. 1e7) as the strain rate goes to zero. > > The two main challenges that I face are (i) an excessive number of Helmholtz-solve iterations and (ii) torque-magnitude calculations that are several orders of magnitude greater than I was expecting. > > Below is my understanding of what I can and should do with nek. Please verify that this is all correct, and please clarify if I have any misunderstanding: > > 1) I must use the stress formulation: IFSTRS = T > > 2) The stress formulation only works with PN/PN-2, not PN-PN, e.g. > > ABORT: Stress formulation in Pn-Pn is not supported > > 3) The viscous term in the stress formulation is treated implicitly; there's no nu_star option for the stress formulation, where one can treat a portion of the viscous term explicitly. > > 4) The torque_calc routine should work with this variable viscosity setup. > > A few more notes: > > -- I found my velocity system to be difficult to solve, and I had to increase the maximum iterations for the solve: I increased NMXH from 100 to 1000 (or greater) in drive2.f > > -- Per Paul's advice, I've set > 0.000000E-05 p021 DIVERGENCE <--- set these to zero > 0.000000E-08 p022 HELMHOLTZ <--- set these to zero > 0.00000 p023 NPSCAL > 0.100000E-01 p024 TOLREL <--- this is the important one > 0.100000E-01 p025 TOLABS > > Does anyone have any additional tips or insights that might be helpful in solving such a system? > > Thanks. > --Mike > > _______________________________________________ > 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 Sep 8 13:43:57 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 8 Sep 2011 13:43:57 -0500 (CDT) Subject: [Nek5000-users] possibly starting to use nekton, questions In-Reply-To: Message-ID: <1106361226.286514.1315507437233.JavaMail.root@zimbra.anl.gov> Hi Brandt, I am not aware of any feedback control implementation but the rest of your aspects Nek5000 can do it including moving meshes. More precisely, Nek5000 is 3D Navier-Stokes equation solver for appropriate initial and boundary conditions and you can have time and spacial dependent forcing/BCs. I would recommend to start with a simple example like 2D flow over a cylinder: nek5_svn/examples/ext_cyl/README Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Thursday, September 8, 2011 9:56:55 AM Subject: [Nek5000-users] possibly starting to use nekton, questions Hi all, I'm considering to start using Nekton. I would like to simulate a spatially evolving 3D boundary layer with a spanwise array of cylinders poking out of the flat wall. The cylinders would also move up and down in the wall normal direction, generating a time-varying disturbance. My goal is to delay bypass transition by dampening this disturbance via feedback control of localized body forces near the wall. Does Nekton currently have these aspects implemented, namely: 1. spatially evolving boundary layer at transitional Re (Re based on displacement thickness of at least ~1000) 2. cylinders independently poking up and down with prescribed height as function of time 3. feedback control with multiple inputs and outputs 4. multiple arbitrary body forces, with independent magnitudes given by the feedback controller or as a function of time 5. ability to calculate the perturbation velocity from laminar for feedback control 6. linear and nonlinear cases (for 1-5) If the control and/or body force parts are not implemented, I'm considering using Nekton to get the wake behind the cylinders and feeding this to a simpler code that can't simulate them directly but would have control and body force aspects. Thanks for your guidance! Brandt _______________________________________________ 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 Sep 10 01:40:42 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 10 Sep 2011 01:40:42 -0500 Subject: [Nek5000-users] Generating a 2D circular mesh Message-ID: Hi Neks, I'm having a little trouble with my first foray into circular geometries. I tried to construct a 2D annular mesh using genbox with the following .box file: ----------------------------------------------------------------------- an.rea 2 spatial dimension 2 number of fields Y -4 -12 nelr,nel_theta 0 0 x0 y0 ccbb 1 2 1 0 1 1 SYM,SYM, V bc's ! NB: 3 characters each ! f ,f , T bc's ! You must have 2 spaces!! ----------------------------------------------------------------------- genbox seems to work properly, with the exception of the fact that nothing after the boundary data gets copied over from the old .rea file. Nonethess, I copy that chunk over manually and run nek5000, which exits with the following error: WARNINGa: Detected non-right-handed element. Number 1 C1-4: 0.6667E+00 0.8333E+00 -0.2083E+00 -0.4167E-01 Any guidance would be much appreciated. Best, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat Sep 10 10:45:03 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 10 Sep 2011 10:45:03 -0500 (CDT) Subject: [Nek5000-users] Generating a 2D circular mesh In-Reply-To: References: Message-ID: Hi David, It's been awhile since I tested this option in genbox. I would suggest the alternative route of simply wrapping the box geometry in usrdat2, as is done for the 2D Taylor Couette example in nek5_svn/examples/Taylor Please let me know if that approach works for you. Paul On Sat, 10 Sep 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > I'm having a little trouble with my first foray into circular geometries. I > tried to construct a 2D annular mesh using genbox with the following .box > file: > > ----------------------------------------------------------------------- > an.rea > 2 spatial dimension > 2 number of fields > Y vi > -4 -12 nelr,nel_theta > 0 0 x0 y0 > ccbb > 1 2 1 > 0 1 1 > SYM,SYM, V bc's ! NB: 3 characters each ! > f ,f , T bc's ! You must have 2 spaces!! > ----------------------------------------------------------------------- > > genbox seems to work properly, with the exception of the fact that nothing > after the boundary data gets copied over from the old .rea file. Nonethess, > I copy that chunk over manually and run nek5000, which exits with the > following error: > > WARNINGa: Detected non-right-handed element. > Number 1 C1-4: 0.6667E+00 0.8333E+00 -0.2083E+00 -0.4167E-01 > > > Any guidance would be much appreciated. > > Best, > > David > From nek5000-users at lists.mcs.anl.gov Sun Sep 11 10:21:20 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 11 Sep 2011 17:21:20 +0200 Subject: [Nek5000-users] genmap error: "infinite loop" Message-ID: Dear Nek devs, I get the following error when using genmap to generate the .map file from a mesh involving a large number of elements, in this case 157464 elements. infinite loop not connected 1 2 1 0 I have attached the full log file from genmap along with the .box file used to generate the mesh. How does one fix this error? Thanks, Mani -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: genmap.log Type: text/x-log Size: 2467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: high_ray.box Type: application/octet-stream Size: 4067 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Sun Sep 11 20:59:03 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 11 Sep 2011 20:59:03 -0500 (CDT) Subject: [Nek5000-users] =?utf-8?q?genmap_error=3A_=22infinite_loop=22?= In-Reply-To: References: Message-ID: Hi Mani, It's not a fatal flaw... particularly for the values shown. It simply means that recursive spectral bisection could not find a split that would yield connected subgraphs in the domain partitioning scheme. At the leaves of the graph (indicated by the small values 1 2 1), this is not a big deal. Elsewhere, it could be detrimental to performance, but the code would still run correctly. Paul On Sun, 11 Sep 2011, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nek devs, > > I get the following error when using genmap to generate the .map file from a > mesh involving a large number of elements, in this case 157464 elements. > > infinite loop > not connected 1 2 1 0 > > I have attached the full log file from genmap along with the .box file used > to generate the mesh. How does one fix this error? > > Thanks, > Mani > From nek5000-users at lists.mcs.anl.gov Mon Sep 12 07:56:51 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Sep 2011 14:56:51 +0200 Subject: [Nek5000-users] genmap error: "infinite loop" In-Reply-To: References: Message-ID: Hi Paul, Thanks for explaining the error. Regards, Mani On Mon, Sep 12, 2011 at 3:59 AM, wrote: > > Hi Mani, > > It's not a fatal flaw... particularly for the values shown. > > It simply means that recursive spectral bisection could not > find a split that would yield connected subgraphs in the > domain partitioning scheme. At the leaves of the graph > (indicated by the small values 1 2 1), this is not a big > deal. Elsewhere, it could be detrimental to performance, > but the code would still run correctly. > > Paul > > > > On Sun, 11 Sep 2011, nek5000-users at lists.mcs.anl.**govwrote: > > Dear Nek devs, >> >> I get the following error when using genmap to generate the .map file from >> a >> mesh involving a large number of elements, in this case 157464 elements. >> >> infinite loop >> not connected 1 2 1 0 >> >> I have attached the full log file from genmap along with the .box file >> used >> to generate the mesh. How does one fix this error? >> >> Thanks, >> Mani >> >> ______________________________**_________________ > 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 Mon Sep 12 16:17:19 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Sep 2011 15:17:19 -0600 Subject: [Nek5000-users] set obj for internal fluid surface Message-ID: All, I'm working with the calc_torque routine, and I want to calculate the torque/drag along a surface within the fluid domain (not on the boundary). Is there a straight-forward way to "set_obj" for such a surface? It's straightforward for external fluid boundaries, as you can just search on certain boundary conditions and grab those element faces. It's not so clear for me how to do the same for some internal surface. Thanks. --Mike From nek5000-users at lists.mcs.anl.gov Mon Sep 12 16:21:10 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Sep 2011 16:21:10 -0500 (CDT) Subject: [Nek5000-users] set obj for internal fluid surface In-Reply-To: References: Message-ID: Hi Mike, I normally would do this by some geometric marker, coupled with the direction of the outward facing normal. Presumably you have some idea of what fluid surface you have in mind (and hopefully it coincides with a mesh surface). With this information you should be able to pick off the faces of interest and identify them as belonging to an object? Let me know if this helps or if I can clarify further. Best, Paul On Mon, 12 Sep 2011, nek5000-users at lists.mcs.anl.gov wrote: > All, > > I'm working with the calc_torque routine, and I want to calculate the > torque/drag along a surface within the fluid domain (not on the boundary). > Is there a straight-forward way to "set_obj" for such a surface? It's > straightforward for external fluid boundaries, as you can just search on > certain boundary conditions and grab those element faces. It's not so clear > for me how to do the same for some internal surface. > > Thanks. > --Mike > > _______________________________________________ > 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 Sep 12 16:23:14 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Sep 2011 15:23:14 -0600 Subject: [Nek5000-users] set obj for internal fluid surface In-Reply-To: References: Message-ID: <5F3ECA1E-8A78-4C0D-B0F2-A3935A43E5B3@nrel.gov> Paul, I plan to have the mesh have an easily findable surface. Is there any example code in the distribution for setting objects based on geometry plus normals? Thanks, --Mike On Sep 12, 2011, at 3:21 PM, wrote: > > Hi Mike, > > I normally would do this by some geometric marker, coupled > with the direction of the outward facing normal. > > Presumably you have some idea of what fluid surface > you have in mind (and hopefully it coincides with a > mesh surface). With this information you should be > able to pick off the faces of interest and identify > them as belonging to an object? > > Let me know if this helps or if I can clarify further. > > Best, > > Paul > > > On Mon, 12 Sep 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> All, >> >> I'm working with the calc_torque routine, and I want to calculate the >> torque/drag along a surface within the fluid domain (not on the boundary). >> Is there a straight-forward way to "set_obj" for such a surface? It's >> straightforward for external fluid boundaries, as you can just search on >> certain boundary conditions and grab those element faces. It's not so clear >> for me how to do the same for some internal surface. >> >> Thanks. >> --Mike >> >> _______________________________________________ >> 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 Sep 12 16:38:04 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Sep 2011 16:38:04 -0500 (CDT) Subject: [Nek5000-users] set obj for internal fluid surface In-Reply-To: <5F3ECA1E-8A78-4C0D-B0F2-A3935A43E5B3@nrel.gov> References: <5F3ECA1E-8A78-4C0D-B0F2-A3935A43E5B3@nrel.gov> Message-ID: Hi Mike, If the geometry were a sphere and I new (roughly) that my elements were of size 0.1 in thickness, I would use something like: nxyz = nx1*ny1*nz1 nface = 2*ndim do e=1,nelv f = 6 ! top z surfae x=xm1(2,2,nz1,e) ! spherical face is on top "z" surface y=ym1(2,2,nz1,e) ! spherical face is on top "z" surface z=zm1(2,2,nz1,e) ! spherical face is on top "z" surface rad = x*x+y*y+z*z if (rad.gt.0) rad=sqrt(rad) if (abs(rad-rad_sph).lt.0.2*thickness) then ! on the sphere c check normal also (superflous for this example) nx = unx(2,2,f,e) ny = uny(2,2,f,e) nz = unz(2,2,f,e) rn = nx*x + ny*y + nz*z ! N.X if (rn.gt.0) then ! we have the outward pointing face, add obj iobj = 1 nmember(iobj) = nmember(iobj) + 1 mem = nmember(iobj) eg = lglel(e) object(iobj,mem,1) = eg object(iobj,mem,2) = f endif endif enddo This code was extracted from the "ext_cyl" example as a starting point. Another approach --- if you know a lot about your surface at the time of mesh creation (e.g., the element and face numbers), you can just store this in a list and read it in. Paul From nek5000-users at lists.mcs.anl.gov Tue Sep 13 09:24:06 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Sep 2011 08:24:06 -0600 Subject: [Nek5000-users] Generating a 2D circular mesh In-Reply-To: References: Message-ID: <2BBB2A4A-BDCE-4A90-9C6B-BB6E53628D23@nrel.gov> Hello all. Just to add bit, I had the same problem as David with genbox. --Mike On Sep 10, 2011, at 9:45 AM, wrote: > > > Hi David, > > It's been awhile since I tested this option in genbox. > > I would suggest the alternative route of simply > wrapping the box geometry in usrdat2, as is done > for the 2D Taylor Couette example in > > nek5_svn/examples/Taylor > > Please let me know if that approach works for you. > > Paul > > > > On Sat, 10 Sep 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Neks, >> >> I'm having a little trouble with my first foray into circular geometries. I >> tried to construct a 2D annular mesh using genbox with the following .box >> file: >> >> ----------------------------------------------------------------------- >> an.rea >> 2 spatial dimension >> 2 number of fields >> Y > > vi >> -4 -12 nelr,nel_theta >> 0 0 x0 y0 >> ccbb >> 1 2 1 >> 0 1 1 >> SYM,SYM, V bc's ! NB: 3 characters each ! >> f ,f , T bc's ! You must have 2 spaces!! >> ----------------------------------------------------------------------- >> >> genbox seems to work properly, with the exception of the fact that nothing >> after the boundary data gets copied over from the old .rea file. Nonethess, >> I copy that chunk over manually and run nek5000, which exits with the >> following error: >> >> WARNINGa: Detected non-right-handed element. >> Number 1 C1-4: 0.6667E+00 0.8333E+00 -0.2083E+00 -0.4167E-01 >> >> >> Any guidance would be much appreciated. >> >> Best, >> >> David >> > _______________________________________________ > 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 Sep 13 09:35:51 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Sep 2011 16:35:51 +0200 Subject: [Nek5000-users] Selective frequency damping Message-ID: Hi Nek's, I've been trying to implement the selective frequency damping (Akervik E., Brandt L., Henningson D.S., Hoepffner J., Marxen O., Schlatter P. 2006. *Steady solutions of the Navier-Stokes equations by selective frequency damping.*Physics of fluids *18*) which enables to compute stationnary solution. Here is what I have written in my .usr file: In userchk: common /vxold/ vxold(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) common /vyold/ vyold(size(vy,1),size(vy,2),size(vy,3),size(vy,4)) common /vzold/ vzold(size(vz,1),size(vz,2),size(vz,3),size(vz,4)) common /qxold/ qxold(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) common /qyold/ qyold(size(vy,1),size(vy,2),size(vy,3),size(vy,4)) common /qzold/ qzold(size(vz,1),size(vz,2),size(vz,3),size(vz,4)) common /for_x/ f_x(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) common /for_y/ f_y(size(vy,1),size(vy,2),size(vy,3),size(vy,4)) common /for_z/ f_z(size(vz,1),size(vz,2),size(vz,3),size(vz,4)) real chi, omega_c integer step_filtr chi = .25 omega_c = .1 step_filtr = 020000 if(istep.EQ.step_filtr.AND.nid.EQ.0) write(*,*) 'Filtrage' if(istep.EQ.0) then vxold = 0.0D+00 vyold = 0.0D+00 vzold = 0.0D+00 endif if(istep.LT.step_filtr) then qxold = 0.0D+00 qyold = 0.0D+00 qzold = 0.0D+00 f_x = 0.0D+00 f_y = 0.0D+00 f_z = 0.0D+00 call opcopy(vxold,vyold,vzold,vx,vy,vz) endif if(istep.GE.step_filtr) then qxold = qxold + dt*omega_c * (vxold - qxold) qyold = qyold + dt*omega_c * (vyold - qyold) qzold = qzold + dt*omega_c * (vzold - qzold) f_x = -chi * (vxold - qxold) f_y = -chi * (vyold - qyold) f_z = -chi * (vzold - qzold) call opcopy(vxxold,vyyold,vzzold,vxold,vyold,vzold) call opcopy(vxold,vyold,vzold,vx,vy,vz) endif and in userf: common /for_x/ f_x(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) common /for_y/ f_y(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) common /for_z/ f_z(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) integer e,f,eg c e = gllel(eg) c Note: this is an acceleration term, NOT a force! c Thus, ffx will subsequently be multiplied by rho(x,t). ffx = f_x(ix,iy,iz,eg) ffy = f_y(ix,iy,iz,eg) ffz = f_z(ix,iy,iz,eg) I have tried to compute with such routines the base flow for a 2D lid-driven cavity flow at Re = 8500, however depending on the number of spectral elements I use, I sometimes get a stationnary solution that looks slightly as the one I'm looking for (but some differences near the lid) and sometimes I get one which is actually not stationnary. I applied the same algorithm for a finite-difference code and encountered no problem, so I was wondering then if I missed something specific to spectral elements or Nek 5000 (such as a mass matrix multplication for instance) or to F77 (which I'm not at ease with, see my definition of the common for instance)? Sincerely yours, -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Sep 13 09:56:44 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Sep 2011 09:56:44 -0500 (CDT) Subject: [Nek5000-users] Selective frequency damping In-Reply-To: References: Message-ID: Hi Jean-Christophe, A couple of comments. 1). I would use declaration of arrays vxold,...,qxold,...,f_x,... similar to declaration of vx, vy,... in nek5_svn/trunk/nek/SOLN : COMMON /VPTSOL/ ... $ , VX (LX1,LY1,LZ1,LELV) ... 2). To set an array on velocity mesh to zero, please use ntot = nx1*ny1*nz1*nelv call rzero(vxold,ntot) instead of vxold = 0.0D+00 3). You do need local element number for setting the forcing in userf, namely e = gllel(eg) ffx = f_x(ix,iy,iz,e) Otherwise it will work correctly only on one core. Let me know if it helps. Best, Aleks On Tue, 13 Sep 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > I've been trying to implement the selective frequency damping (Akervik E., > Brandt L., Henningson D.S., Hoepffner J., Marxen O., Schlatter P. 2006. *Steady > solutions of the Navier-Stokes equations by selective frequency > damping.*Physics of fluids > *18*) which enables to compute stationnary solution. Here is what I have > written in my .usr file: > > In userchk: > > common /vxold/ vxold(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > common /vyold/ vyold(size(vy,1),size(vy,2),size(vy,3),size(vy,4)) > common /vzold/ vzold(size(vz,1),size(vz,2),size(vz,3),size(vz,4)) > > common /qxold/ qxold(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > common /qyold/ qyold(size(vy,1),size(vy,2),size(vy,3),size(vy,4)) > common /qzold/ qzold(size(vz,1),size(vz,2),size(vz,3),size(vz,4)) > > common /for_x/ f_x(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > common /for_y/ f_y(size(vy,1),size(vy,2),size(vy,3),size(vy,4)) > common /for_z/ f_z(size(vz,1),size(vz,2),size(vz,3),size(vz,4)) > > real chi, omega_c > integer step_filtr > > > chi = .25 > omega_c = .1 > step_filtr = 020000 > > if(istep.EQ.step_filtr.AND.nid.EQ.0) write(*,*) 'Filtrage' > > if(istep.EQ.0) then > vxold = 0.0D+00 > vyold = 0.0D+00 > vzold = 0.0D+00 > endif > > if(istep.LT.step_filtr) then > qxold = 0.0D+00 > qyold = 0.0D+00 > qzold = 0.0D+00 > > f_x = 0.0D+00 > f_y = 0.0D+00 > f_z = 0.0D+00 > > call opcopy(vxold,vyold,vzold,vx,vy,vz) > endif > > if(istep.GE.step_filtr) then > qxold = qxold + dt*omega_c * (vxold - qxold) > qyold = qyold + dt*omega_c * (vyold - qyold) > qzold = qzold + dt*omega_c * (vzold - qzold) > > f_x = -chi * (vxold - qxold) > f_y = -chi * (vyold - qyold) > f_z = -chi * (vzold - qzold) > > call opcopy(vxxold,vyyold,vzzold,vxold,vyold,vzold) > call opcopy(vxold,vyold,vzold,vx,vy,vz) > endif > > and in userf: > > common /for_x/ f_x(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > common /for_y/ f_y(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > common /for_z/ f_z(size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > > > integer e,f,eg > c e = gllel(eg) > > > c Note: this is an acceleration term, NOT a force! > c Thus, ffx will subsequently be multiplied by rho(x,t). > > > ffx = f_x(ix,iy,iz,eg) > ffy = f_y(ix,iy,iz,eg) > ffz = f_z(ix,iy,iz,eg) > > > I have tried to compute with such routines the base flow for a 2D lid-driven > cavity flow at Re = 8500, however depending on the number of spectral > elements I use, I sometimes get a stationnary solution that looks slightly > as the one I'm looking for (but some differences near the lid) and sometimes > I get one which is actually not stationnary. I applied the same algorithm > for a finite-difference code and encountered no problem, so I was wondering > then if I missed something specific to spectral elements or Nek 5000 (such > as a mass matrix multplication for instance) or to F77 (which I'm not at > ease with, see my definition of the common for instance)? > > Sincerely yours, > > -- > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Tue Sep 13 13:28:48 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Sep 2011 13:28:48 -0500 Subject: [Nek5000-users] Generating a 2D circular mesh In-Reply-To: References: Message-ID: Hi Paul, Thanks for pointing me to the taylor example. I'm now successfully running simulations on an annulus, but the part of my code in userchk that computed volume averages and inner products is no longer working properly. e.g., (glsc3(vx,bm1,vx,n) returns NaN. Is this to be expected? Best, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Sep 13 13:33:12 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Sep 2011 13:33:12 -0500 (CDT) Subject: [Nek5000-users] Generating a 2D circular mesh In-Reply-To: References: Message-ID: David, That should not be an issue... something else is wrong. If you want to tar it and send it to me off-line, I can take a look. Paul On Tue, 13 Sep 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Thanks for pointing me to the taylor example. I'm now successfully running > simulations on an annulus, but the part of my code in userchk that computed > volume averages and inner products is no longer working properly. > > e.g., (glsc3(vx,bm1,vx,n) returns NaN. Is this to be expected? > > Best, > > David > From nek5000-users at lists.mcs.anl.gov Thu Sep 15 03:27:50 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Sep 2011 10:27:50 +0200 Subject: [Nek5000-users] Selective frequency damping In-Reply-To: References: Message-ID: It indeed solved my problems. Thanks a lot. On 13 September 2011 16:56, wrote: > Hi Jean-Christophe, > > A couple of comments. > > 1). I would use declaration of arrays vxold,...,qxold,...,f_x,... > similar to declaration of vx, vy,... in > > nek5_svn/trunk/nek/SOLN : > > > COMMON /VPTSOL/ > ... > $ , VX (LX1,LY1,LZ1,LELV) > ... > > > 2). To set an array on velocity mesh to zero, please use > > ntot = nx1*ny1*nz1*nelv > call rzero(vxold,ntot) > > instead of > > vxold = 0.0D+00 > > > 3). You do need local element number for setting the forcing in userf, > namely > > e = gllel(eg) > ffx = f_x(ix,iy,iz,e) > > Otherwise it will work correctly only on one core. > > > Let me know if it helps. > Best, > Aleks > > > > > > On Tue, 13 Sep 2011, nek5000-users at lists.mcs.anl.**govwrote: > > Hi Nek's, >> >> I've been trying to implement the selective frequency damping (Akervik E., >> Brandt L., Henningson D.S., Hoepffner J., Marxen O., Schlatter P. 2006. >> *Steady >> solutions of the Navier-Stokes equations by selective frequency >> damping.*Physics of fluids >> *18*) which enables to compute stationnary solution. Here is what I have >> written in my .usr file: >> >> In userchk: >> >> common /vxold/ vxold(size(vx,1),size(vx,2),**size(vx,3),size(vx,4)) >> common /vyold/ vyold(size(vy,1),size(vy,2),**size(vy,3),size(vy,4)) >> common /vzold/ vzold(size(vz,1),size(vz,2),**size(vz,3),size(vz,4)) >> >> common /qxold/ qxold(size(vx,1),size(vx,2),**size(vx,3),size(vx,4)) >> common /qyold/ qyold(size(vy,1),size(vy,2),**size(vy,3),size(vy,4)) >> common /qzold/ qzold(size(vz,1),size(vz,2),**size(vz,3),size(vz,4)) >> >> common /for_x/ f_x(size(vx,1),size(vx,2),**size(vx,3),size(vx,4)) >> common /for_y/ f_y(size(vy,1),size(vy,2),**size(vy,3),size(vy,4)) >> common /for_z/ f_z(size(vz,1),size(vz,2),**size(vz,3),size(vz,4)) >> >> real chi, omega_c >> integer step_filtr >> >> >> chi = .25 >> omega_c = .1 >> step_filtr = 020000 >> >> if(istep.EQ.step_filtr.AND.**nid.EQ.0) write(*,*) 'Filtrage' >> >> if(istep.EQ.0) then >> vxold = 0.0D+00 >> vyold = 0.0D+00 >> vzold = 0.0D+00 >> endif >> >> if(istep.LT.step_filtr) then >> qxold = 0.0D+00 >> qyold = 0.0D+00 >> qzold = 0.0D+00 >> >> f_x = 0.0D+00 >> f_y = 0.0D+00 >> f_z = 0.0D+00 >> >> call opcopy(vxold,vyold,vzold,vx,**vy,vz) >> endif >> >> if(istep.GE.step_filtr) then >> qxold = qxold + dt*omega_c * (vxold - qxold) >> qyold = qyold + dt*omega_c * (vyold - qyold) >> qzold = qzold + dt*omega_c * (vzold - qzold) >> >> f_x = -chi * (vxold - qxold) >> f_y = -chi * (vyold - qyold) >> f_z = -chi * (vzold - qzold) >> >> call opcopy(vxxold,vyyold,vzzold,**vxold,vyold,vzold) >> call opcopy(vxold,vyold,vzold,vx,**vy,vz) >> endif >> >> and in userf: >> >> common /for_x/ f_x(size(vx,1),size(vx,2),**size(vx,3),size(vx,4)) >> common /for_y/ f_y(size(vx,1),size(vx,2),**size(vx,3),size(vx,4)) >> common /for_z/ f_z(size(vx,1),size(vx,2),**size(vx,3),size(vx,4)) >> >> >> integer e,f,eg >> c e = gllel(eg) >> >> >> c Note: this is an acceleration term, NOT a force! >> c Thus, ffx will subsequently be multiplied by rho(x,t). >> >> >> ffx = f_x(ix,iy,iz,eg) >> ffy = f_y(ix,iy,iz,eg) >> ffz = f_z(ix,iy,iz,eg) >> >> >> I have tried to compute with such routines the base flow for a 2D >> lid-driven >> cavity flow at Re = 8500, however depending on the number of spectral >> elements I use, I sometimes get a stationnary solution that looks slightly >> as the one I'm looking for (but some differences near the lid) and >> sometimes >> I get one which is actually not stationnary. I applied the same algorithm >> for a finite-difference code and encountered no problem, so I was >> wondering >> then if I missed something specific to spectral elements or Nek 5000 (such >> as a mass matrix multplication for instance) or to F77 (which I'm not at >> ease with, see my definition of the common for instance)? >> >> Sincerely yours, >> >> -- >> Jean-Christophe >> >> ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Sep 15 04:45:41 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Sep 2011 11:45:41 +0200 Subject: [Nek5000-users] Cylindrical mesh Message-ID: Hi Nek's, I've just started to look at the cylindrical meshing capabilities of genbox, and I have one question regarding the boundary conditions. Here is the exemple in Nek Primer just for recall: 2 spatial dimension 1 number of fields # # # Y cYlinder 3 -24 1 nelr,nel_theta,nelz .5 .3 x0,y0 - center of cylinder ccbb descriptors .5 .55 .7 .8 r0 r1 .... r_nelr 0 1 1 v ,W ,E ,E , I am not sure though I correctly understood where are applied the boundary conditions. Indeed we now have five "physical" boundaries (the four edges of the box + the cylinder itself), however we specified only four conditions. Regards, -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Sep 15 09:16:03 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Sep 2011 08:16:03 -0600 Subject: [Nek5000-users] Cylindrical mesh In-Reply-To: References: Message-ID: <6AF60C57-5B77-414A-B9A8-CE664BAA5E65@nrel.gov> Jean-Christophe, I was having trouble with the cylindrical meshing in genbox. However, I made the switch to prex, and I've found that easier than genbox. Just my 2 cents. --Mike On Sep 15, 2011, at 3:45 AM, wrote: > Hi Nek's, > > I've just started to look at the cylindrical meshing capabilities of genbox, and I have one question regarding the boundary conditions. Here is the exemple in Nek Primer just for recall: > > 2 spatial dimension > 1 number of fields > # > # > # > Y cYlinder > 3 -24 1 nelr,nel_theta,nelz > .5 .3 x0,y0 - center of cylinder > ccbb descriptors > .5 .55 .7 .8 r0 r1 .... r_nelr > 0 1 1 > v ,W ,E ,E , > > I am not sure though I correctly understood where are applied the boundary conditions. Indeed we now have five "physical" boundaries (the four edges of the box + the cylinder itself), however we specified only four conditions. > > Regards, > > -- > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Thu Sep 15 10:45:20 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Sep 2011 17:45:20 +0200 Subject: [Nek5000-users] Cylindrical mesh In-Reply-To: <6AF60C57-5B77-414A-B9A8-CE664BAA5E65@nrel.gov> References: <6AF60C57-5B77-414A-B9A8-CE664BAA5E65@nrel.gov> Message-ID: Alright then, Thanks for the tip, I'll give it a try. On 15 September 2011 16:16, wrote: > Jean-Christophe, > > I was having trouble with the cylindrical meshing in genbox. However, I > made the switch to prex, and I've found that easier than genbox. Just my 2 > cents. > > --Mike > > On Sep 15, 2011, at 3:45 AM, wrote: > > > Hi Nek's, > > > > I've just started to look at the cylindrical meshing capabilities of > genbox, and I have one question regarding the boundary conditions. Here is > the exemple in Nek Primer just for recall: > > > > 2 spatial dimension > > 1 number of fields > > # > > # > > # > > Y cYlinder > > 3 -24 1 nelr,nel_theta,nelz > > .5 .3 x0,y0 - center of cylinder > > ccbb descriptors > > .5 .55 .7 .8 r0 r1 .... r_nelr > > 0 1 1 > > v ,W ,E ,E , > > > > I am not sure though I correctly understood where are applied the > boundary conditions. Indeed we now have five "physical" boundaries (the four > edges of the box + the cylinder itself), however we specified only four > conditions. > > > > Regards, > > > > -- > > Jean-Christophe > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Sep 19 12:33:44 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Sep 2011 12:33:44 -0500 Subject: [Nek5000-users] CUBIT/Moab Message-ID: Neks, We are interested in using CUBIT meshes in our Nek runs. I took a look at the "moab" example in the source, but I'm still unsure of the proper process of getting a CUBIT-generated mesh into Nek. I have created a CUBIT mesh (.cub), and have also downloaded, compiled, and installed MOAB. I see in the example that a .h5m file is used (the native format of MOAB), but I don't know how to generate it through MOAB (from my .cub file). I realize that this is probably more of a MOAB question than a Nek question, but are there some simple instructions/examples to help me in understanding how to use a CUBIT mesh in Nek? Any help would be appreciated! Thanks, -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Tue Sep 20 13:19:11 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 Sep 2011 23:49:11 +0530 Subject: [Nek5000-users] Problems with grid. Nek gets stuck. Message-ID: Hi Paul, I'm having trouble with a run involving a box with dimensions 5:5:1 (length:breadth:height), for which I would like to go to a Rayleigh number of 10^8. I generated the grid (.rea and .map) using the attached .box file, but the run gets stuck as shown in the log. I think that there is a problem with the grid and the .map file. Could you please look into it? Thanks, Mani -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: high_ray.box Type: application/octet-stream Size: 4065 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: log Type: application/octet-stream Size: 65562 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Tue Sep 20 13:39:32 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 Sep 2011 13:39:32 -0500 (CDT) Subject: [Nek5000-users] CUBIT/Moab In-Reply-To: Message-ID: <158857221.22662.1316543972711.JavaMail.root@zimbra.anl.gov> Hi Josh, I have been told that the way to convert .cub file into MOAB's native .h5m file is using mbconvert utility which should be in MOAB's bin directory. (https://svn.mcs.anl.gov/repos/ITAPS/MOAB/tags/preVersion4.0/README.IO). Please, try mbconvert blah.cub blah.h5m Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "nek5000-users" Sent: Monday, September 19, 2011 12:33:44 PM Subject: [Nek5000-users] CUBIT/Moab Neks, We are interested in using CUBIT meshes in our Nek runs. I took a look at the "moab" example in the source, but I'm still unsure of the proper process of getting a CUBIT-generated mesh into Nek. I have created a CUBIT mesh (.cub), and have also downloaded, compiled, and installed MOAB. I see in the example that a .h5m file is used (the native format of MOAB), but I don't know how to generate it through MOAB (from my .cub file). I realize that this is probably more of a MOAB question than a Nek question, but are there some simple instructions/examples to help me in understanding how to use a CUBIT mesh in Nek? Any help would be appreciated! Thanks, -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke _______________________________________________ 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 Sep 20 13:50:02 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 Sep 2011 13:50:02 -0500 Subject: [Nek5000-users] CUBIT/Moab In-Reply-To: <158857221.22662.1316543972711.JavaMail.root@zimbra.anl.gov> References: <158857221.22662.1316543972711.JavaMail.root@zimbra.anl.gov> Message-ID: <4E78E05A.6010401@mcs.anl.gov> I sent these instructions to a different Nek user a few days back: Ok. I think in the repo version of Nek, you have to name your mesh input "input.h5m", which you get by translating from .cub to .h5m (the latter is the hdf5-based native file representation MOAB uses). If you want to run this in parallel, you also need to run a partitioner on the file (using tools/mbzoltan in moab), and change the code at the beginning of nek/3rd_party/moab.f, nekMOAB_load subroutine, to use PARTITION=PARALLEL_PARTITION option. Finally, you'll need to change the value used for lelt in the SIZE file (set it to the number of elements in the mesh). - tim On 09/20/2011 01:39 PM, Aleksandr Obabko wrote: > Hi Josh, > > I have been told that the way to convert .cub file into MOAB's native .h5m file is using mbconvert utility which should be in MOAB's bin directory. > > (https://svn.mcs.anl.gov/repos/ITAPS/MOAB/tags/preVersion4.0/README.IO). > > > Please, try > > mbconvert blah.cub blah.h5m > > Best, > Aleks > > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: "nek5000-users" > Sent: Monday, September 19, 2011 12:33:44 PM > Subject: [Nek5000-users] CUBIT/Moab > > Neks, > > We are interested in using CUBIT meshes in our Nek runs. I took a > look at the "moab" example in the source, but I'm still unsure of the > proper process of getting a CUBIT-generated mesh into Nek. > > I have created a CUBIT mesh (.cub), and have also downloaded, > compiled, and installed MOAB. I see in the example that a .h5m file > is used (the native format of MOAB), but I don't know how to generate > it through MOAB (from my .cub file). > > I realize that this is probably more of a MOAB question than a Nek > question, but are there some simple instructions/examples to help me > in understanding how to use a CUBIT mesh in Nek? Any help would be > appreciated! > > Thanks, > -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (tautges at mcs.anl.gov) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706 From nek5000-users at lists.mcs.anl.gov Wed Sep 21 17:00:16 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Sep 2011 17:00:16 -0500 Subject: [Nek5000-users] CUBIT/Moab In-Reply-To: <4E78E05A.6010401@mcs.anl.gov> References: <158857221.22662.1316543972711.JavaMail.root@zimbra.anl.gov> <4E78E05A.6010401@mcs.anl.gov> Message-ID: Hi Tim,Aleks: I was able to successfully convert our test mesh from a .cub to a .h5m using mbconvert. Now the issue is running it with Nekton. I am trying to run the "moab" example in the nek repo (I'm using 724), which appears to be a simple pipe. In the makenek file, I put "MOAB" in the PPLIST, and I specify the moab directory (see attached makenek file). When I try to compile, I get issues with moab.f--essentially, variables such as iBase_REGION, iMesh_HEXAHEDRON, etc have no implicit type, which makes me think it is not finding these variables like it should... I found where these variables are defined (iMesh_f.h), and it looks like the compiler is looking in the correct include directory (for me, this is ${HOME}/moab/trunk/TRIAL1/include ), so I'm not sure why my compilation of Nek is not seeing these variables. As a sanity check, I copied all the include files from moab to the nek/3rd_party directory, but I get the same result. I included my makenek file and the compiler logfile, Any help here would be greatly appreciated! Thanks, and let me know if you need any more information Josh On Tue, Sep 20, 2011 at 1:50 PM, wrote: > I sent these instructions to a different Nek user a few days back: > > Ok. ?I think in the repo version of Nek, you have to name your mesh input > "input.h5m", which you get by translating from .cub to .h5m (the latter is > the hdf5-based native file representation MOAB uses). ?If you want to run > this in parallel, you also need to run a partitioner on the file (using > tools/mbzoltan in moab), and change the code at the beginning of > nek/3rd_party/moab.f, nekMOAB_load subroutine, to use > PARTITION=PARALLEL_PARTITION option. ?Finally, you'll need to change the > value used for lelt in the SIZE file (set it to the number of elements in > the mesh). > > > - tim > > > On 09/20/2011 01:39 PM, Aleksandr Obabko wrote: >> >> Hi Josh, >> >> I have been told that the way to convert .cub file into MOAB's native .h5m >> file is using mbconvert utility which should be in MOAB's bin directory. >> >> (https://svn.mcs.anl.gov/repos/ITAPS/MOAB/tags/preVersion4.0/README.IO). >> >> >> Please, try >> >> mbconvert blah.cub blah.h5m >> >> Best, >> Aleks >> >> >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: "nek5000-users" >> Sent: Monday, September 19, 2011 12:33:44 PM >> Subject: [Nek5000-users] CUBIT/Moab >> >> Neks, >> >> We are interested in using CUBIT meshes in our Nek runs. ?I took a >> look at the "moab" example in the source, but I'm still unsure of the >> proper process of getting a CUBIT-generated mesh into Nek. >> >> I have created a CUBIT mesh (.cub), and have also downloaded, >> compiled, and installed MOAB. ?I see in the example that a .h5m file >> is used (the native format of MOAB), but I don't know how to generate >> it through MOAB (from my .cub file). >> >> I realize that this is probably more of a MOAB question than a Nek >> question, but are there some simple instructions/examples to help me >> in understanding how to use a CUBIT mesh in Nek? ?Any help would be >> appreciated! >> >> Thanks, >> > > -- > ================================================================ > "You will keep in perfect peace him whose mind is > ?steadfast, because he trusts in you." ? ? ? ? ? ? ? Isaiah 26:3 > > ? ? ? ? ? ? Tim Tautges ? ? ? ? ? ?Argonne National Laboratory > ? ? ? ? (tautges at mcs.anl.gov) ? ? ?(telecommuting from UW-Madison) > ? ? ? ? phone: (608) 263-8485 ? ? ?1500 Engineering Dr. > ? ? ? ? ? fax: (608) 263-4499 ? ? ?Madison, WI 53706 > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke -------------- next part -------------- A non-text attachment was scrubbed... Name: compiler.out Type: application/octet-stream Size: 34199 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: makenek Type: application/octet-stream Size: 1432 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Tue Sep 27 09:13:37 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 Sep 2011 16:13:37 +0200 Subject: [Nek5000-users] Running Simulations in Parallel with nekbmpi In-Reply-To: References: Message-ID: Hi Neks, I do get the same error when I try to run nek on my laptop. Did you find any way to solve the problem John? Regards, On 11 May 2011 21:25, wrote: > Hi, > > I have lp=512 in SIZE, and I did compile with IFMPI=true. I recompiled > yesterday because I thought this may be the case, but I was still getting > the same error. When I first start a simulation and run top, it shows four > processors running nek5000, but this changes to one processor after a few > seconds. > > Thanks, > > John > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Sep 27 10:40:44 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 Sep 2011 17:40:44 +0200 Subject: [Nek5000-users] Running Simulations in Parallel with nekbmpi In-Reply-To: References: Message-ID: Hi, Do you get any output printed to the screen when you launch Nek? Please provide the output of the following command: ulimit -a (in case you are using bash) size nek5000 cat SIZE Can you post the command you are using to launch Nek in parallel? Cheers, Stefan On 9/27/11, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > I do get the same error when I try to run nek on my laptop. Did you find any > way to solve the problem John? > > Regards, > > On 11 May 2011 21:25, wrote: > >> Hi, >> >> I have lp=512 in SIZE, and I did compile with IFMPI=true. I recompiled >> yesterday because I thought this may be the case, but I was still getting >> the same error. When I first start a simulation and run top, it shows >> four >> processors running nek5000, but this changes to one processor after a few >> seconds. >> >> Thanks, >> >> John >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> > > > -- > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Fri Sep 30 11:15:50 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 Sep 2011 18:15:50 +0200 Subject: [Nek5000-users] nek tools bug ? Message-ID: <4E85EB36.6020907@lav.mavt.ethz.ch> hi all, I had problems merging grids with the nek tools. When the final merged grid was having more than 100000 elements genmap was failing. I think the problem was due to an inconsistency between the writing formats for the BC section in n2to3,nekmerge and genmap (at least in my version, see below). In my case i have solved the problem by changing the formats in nekmerge.f. just my 2 cents francesco ------------------------------ n2to3.f lines 441-... ------------------------------ if (neln.lt.1000) then write(11,20) cbc(k,e),id,k,(bc(j,k,e),j=1,5) elseif (neln.lt.100000) then write(11,21) cbc(k,e),id,k,(bc(j,k,e),j=1,5) else write(11,22) cbc(k,e),id,k,(bc(j,k,e),j=1,5) endif .... 20 FORMAT(1x,A3,2I3,5G14.7) 21 FORMAT(1x,A3,i5,i1,5G14.7) 22 FORMAT(1x,A3,i6,i1,5G14.7) ---------------------------------- nekmerge.f lines 664-... ---------------------------------- if (nel.lt.1000) then write(11,20) cbc(f,e,fld),e,f,(bc(j,f,e,fld),j=1,5) elseif (nel.lt.100000) then write(11,21) cbc(f,e,fld),e,f,(bc(j,f,e,fld),j=1,5) else write(11,22) cbc(f,e,fld),e,(bc(j,f,e,fld),j=1,5) endif ... 20 format(1x,a3,2i3,5g14.6) 21 format(1x,a3,i5,i1,5g14.6) 22 format(1x,a3,i10,5g14.6) -------------------------------- genmap.f lines 507-... -------------------------------- if (nel.lt.1000) then read(io,50,err=510,end=600) $ chtemp, $ cbc(f,e),id1,id2, $ (bc(ii,f,e),ii=1,nbcrea) 50 format(a1,a3,2i3,5g14.7) elseif (nel.lt.100 000) then read(io,51,err=520,end=600) $ chtemp, $ cbc(f,e),id1,id2, $ (bc(ii,f,e),ii=1,nbcrea) 51 format(a1,a3,i5,i1,5g14.7) elseif (nel.lt.1 000 000) then read(io,52,err=530,end=600) $ cbc(f,e),id1,(bc(ii,f,e),ii=1,nbcrea) 52 format(1x,a3,i7,5g14.6) elseif (nel.lt.10 000 000) then read(io,53,err=540,end=600) $ cbc(f,e),id1,(bc(ii,f,e),ii=1,nbcrea) 53 format(1x,a3,i7,5e20.12) else read(io,*,err=550,end=600) $ cbc(f,e),id1,(bc(ii,f,e),ii=1,nbcrea) endif -------------- next part -------------- An HTML attachment was scrubbed... URL: