April 2017 - Nek5000-users - mailman3.cels.anl.gov

prenek
by nek5000-users＠lists.mcs.anl.gov 19 Apr '17

19 Apr '17

Hi nek, I want to generate a 2d pipe mesh using prenek and add 3 elements in first quadrant using [(0, 0), (0.0045, 0), (0.003536, 0.003536), (0, 0.0045)], [(0.0125, 0), (0.00884, 0.00884), (0.003536, 0.003536), (0.0045, 0)], and [(0, 0.0125), (0.00884, 0.00884), (0.003536, 0.003536), (0, 0.00045)] for 3 elements respectively. But I usually add the element of [(0, 0.0125), (0.00884, 0.00884), (0.003536, 0.003536), (0, 0.00045)] with some difference which would happened on the first point I select. Do you know how could I click the points very accurately? Kind regards, Jian

1 1

Re: [Nek5000-users] Problem with intp_rstd
by nek5000-users＠lists.mcs.anl.gov 11 Apr '17

11 Apr '17

Dear Paul, I am confused about something. I realize now that for the components of B_{ij} to be exact, quadrature for \int_\Omega \phi_i \phi_j dx = (\phi_i, \phi_j ). Since in Nek5000 we have (N+1)^dim GLL points for the velocity grid, does that mean every time an inner product is being evaluated in the code this is not exact? If I want B_{ij} to be exact, do I need to evaluate the basis functions on more GLL quadrature points (say, N+2)? I'm just wondering if I am understanding the problem correctly. For now, multiplying "rhs" by "binvm1" like you suggested produced accurate results for my dummy problem (vx**2), I may have to do exact integration in the long run. Thank you, Juan Diego

1 0

Re: [Nek5000-users] Problem with intp_rstd
by nek5000-users＠lists.mcs.anl.gov 10 Apr '17

10 Apr '17

Dear Paul, Thank you for your detailed answer. I understand now what needs to be done. Also, you mentioned that you had a code that could help me solve the B u = b problem exactly. If it is not too much trouble, I would really appreciate it if you shared it with me. It would save me a lot of time. Thank you, Juan Diego

1 0

Re: [Nek5000-users] proj_ortho error in pipe flow
by nek5000-users＠lists.mcs.anl.gov 10 Apr '17

10 Apr '17

Hi Paul & Philipp, thanks for your quick replies and suggestions. I started the simulation again with a slightly perturbed laminar flow field as initial conditions and there are no proj_ortho errors anymore. For now, this perturbation is more or less random and probably not ideal for tripping the laminar flow to turbulence. Therefore, I might try to implement a more effective numerical tripping method in the future. I can let you know when (and if) I succeed. The parameters p94 and p95 are set to "9" just because I have found that in another simulation somewhere. Do you suggest trying different values here? The Nek5000 version was downloaded as a zip file on 21/03/2017 so I suppose it is the commit 95b42f08c960d522679e0f0881d284ec841ae09 \Steffen On 09/04/17 19:00, nek5000-users-request(a)lists.mcs.anl.gov wrote: > Message: 1 > Date: Sat, 8 Apr 2017 19:55:36 +0200 > From: nek5000-users(a)lists.mcs.anl.gov > To: nek5000-users(a)lists.mcs.anl.gov > Subject: Re: [Nek5000-users] proj_ortho error in pipe flow > Message-ID: > <mailman.4792.1491674149.2967.nek5000-users(a)lists.mcs.anl.gov> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hi Steffen, > which revision of the code are you using? Is the initial field you are > using already turbulent, or are you going through transition? Any > special reason why you have 9 for p94/95? > > Philipp > > On 2017-04-07 19:54, nek5000-users(a)lists.mcs.anl.gov wrote: >> Hi Steffen, >> >> It looks like your solution is hitting a steady-state condition and that the >> projection onto prior solutions is thus projecting in to a set of linearly-dependent >> vectors. >> >> In principle, the code is supposed to correct for this condition but apparently >> it is not doing so correctly. >> >> I see you're running at Re > 5000, so presumably you are interested in turbulence, >> rather than laminar steady state. I would recommend adding a random perturbation >> to the initial condition or, better still, adding something with bound vorticity near the >> walls that will get stretched and bring about a more rapid transition. >> >> I find that something like the attached works well with channel flow (snap through within >> about 10 convective time units). I was disappointed that it didn't work as well with pipe >> flow, where I had to go up to Re=40k to get the thing started and then bring it down. >> I assume this has something to do with the lack of linear transition in Hagen-Poiseuille flow. >> If you find a better mechanism to speed transition, I'd be interested to find out about it. >> >> Best, >> >> Paul >> >> ________________________________________ >> From: nek5000-users-bounces(a)lists.mcs.anl.gov [nek5000-users-bounces(a)lists.mcs.anl.gov] on behalf of nek5000-users(a)lists.mcs.anl.gov [nek5000-users(a)lists.mcs.anl.gov] >> Sent: Friday, April 07, 2017 10:18 AM >> To: nek5000-users(a)lists.mcs.anl.gov >> Subject: [Nek5000-users] proj_ortho error in pipe flow >> >> Dear Nek users, >> >> I am running a simple pipe flow on a Cray XC40 (Hazel Hen). After 32 >> steps, I get this problem (see attachment for complete logfile): >> >> Step 32, t= 3.2000000E-02, DT= 1.0000000E-03, C= 0.025 3.2660E-01 >> 1.0526E-02 >> Solving for fluid >> 32 Project velx 6.6444E-09 2.4759E-09 >> 2.6836E+00 8 0 >> 32 Hmholtz velx 1 3.9238E-09 6.7918E-07 1.0000E-08 >> 32 Project vely 6.8730E-09 2.1046E-09 >> 3.2656E+00 8 0 >> 32 Hmholtz vely 1 3.6166E-09 5.9974E-07 1.0000E-08 >> 32 Project velz 5.2396E-03 2.5121E-06 >> 2.0858E+03 8 0 >> 32 Hmholtz velz 3 7.6028E-10 9.3795E-04 1.0000E-08 >> 32proj_ortho: 2 8 velz Detect rank deficiency: NaN >> 1.0000E+00 >> 32proj_ortho: 1 8 velz Detect rank deficiency: NaN >> 1.0000E+00 >> 32 U-PRES gmres 29 9.9376E-09 5.2213E-04 >> 1.0000E-08 8.7926E-03 1.7780E-02 >> 32 DNORM, DIVEX 2.704668739973178E-005 9.937641774554489E-009 >> 32 0.3200000E-01 1.61568E-01 6.88948E-05 7.85330E-01 >> 7.85399E-01 volflow Z >> 32 Fluid done 3.2000E-02 2.4042E-02 >> >> In the next step I get CFL, CTarg! and the simulation exits. >> >> This problem does neither show up on my local machine nor on another >> smaller cluster. Moreover, when I set either parameter 94 or 95 to 0, I >> do not see this error. It only appears when p94 and p95 are both unequal >> 0. In my case I set them to 9. >> >> Do you know what might be causing this issue and how to solve it for the >> Cray XC40 system? >> >> >> Best Regards >> Steffen >> >> >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users(a)lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >>

1 1

Inconsistent Periodic BC in Prenek
by nek5000-users＠lists.mcs.anl.gov 09 Apr '17

09 Apr '17

Hello Neks, I am making a rectangular domain with two sides periodic and 2 sides no-slip. I am having problems after the global refine. If I refine my domain to 48 elements, it's fine, but if I refine it to 192 elements (which is better, with a grid size =1 ), it returns "Inconsistent Periodic BCs" and "Reset el/face1". As a result the "genmap" does not work due to Periodic Mismatch. Please note that there is no problems if no. of elements = 48. I don't understand what the problem is. Any help is appreciated. Thanks for reading. Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech.

1 2

Problem with intp_rstd
by nek5000-users＠lists.mcs.anl.gov 09 Apr '17

09 Apr '17

Dear all, I've been playing around with the 'intp_rstd' subroutine to do calculations on the dealiasing grid (lxd*lxy*lzd). I can map the velocity field onto the fine grid (vx --> vxd) and when I print out values it seems fine. Then I try to calculate vxd**2, and still seems fine. However, when I try to map back to the original grid, the results are complete garbage. Here is a snippet of my code. do e=1,nelv ! mapping to fine grid call intp_rstd(vxd(1,1,1,e),vx(1,1,1,e),nx1,nxd,if3d,0) ! 0 --> forward enddo call vsq(vxd,ntotd) ! calculating vxd**2 do e=1,nelv ! mapping back to original grid call intp_rstd(vx(1,1,1,e),vxd(1,1,1,e),nx1,nxd,if3d,1) ! 0 --> backwards enddo Am I doing something wrong? Thanks, Juan Diego

1 1

proj_ortho error in pipe flow
by nek5000-users＠lists.mcs.anl.gov 08 Apr '17

08 Apr '17

Dear Nek users, I am running a simple pipe flow on a Cray XC40 (Hazel Hen). After 32 steps, I get this problem (see attachment for complete logfile): Step 32, t= 3.2000000E-02, DT= 1.0000000E-03, C= 0.025 3.2660E-01 1.0526E-02 Solving for fluid 32 Project velx 6.6444E-09 2.4759E-09 2.6836E+00 8 0 32 Hmholtz velx 1 3.9238E-09 6.7918E-07 1.0000E-08 32 Project vely 6.8730E-09 2.1046E-09 3.2656E+00 8 0 32 Hmholtz vely 1 3.6166E-09 5.9974E-07 1.0000E-08 32 Project velz 5.2396E-03 2.5121E-06 2.0858E+03 8 0 32 Hmholtz velz 3 7.6028E-10 9.3795E-04 1.0000E-08 32proj_ortho: 2 8 velz Detect rank deficiency: NaN 1.0000E+00 32proj_ortho: 1 8 velz Detect rank deficiency: NaN 1.0000E+00 32 U-PRES gmres 29 9.9376E-09 5.2213E-04 1.0000E-08 8.7926E-03 1.7780E-02 32 DNORM, DIVEX 2.704668739973178E-005 9.937641774554489E-009 32 0.3200000E-01 1.61568E-01 6.88948E-05 7.85330E-01 7.85399E-01 volflow Z 32 Fluid done 3.2000E-02 2.4042E-02 In the next step I get CFL, CTarg! and the simulation exits. This problem does neither show up on my local machine nor on another smaller cluster. Moreover, when I set either parameter 94 or 95 to 0, I do not see this error. It only appears when p94 and p95 are both unequal 0. In my case I set them to 9. Do you know what might be causing this issue and how to solve it for the Cray XC40 system? Best Regards Steffen

1 2