From nek5000-users at lists.mcs.anl.gov Mon Jul 2 09:40:53 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 2 Jul 2018 14:40:53 +0000 Subject: [Nek5000-users] Stream function In-Reply-To: References: , Message-ID: Hi JC, Yes, the mv_wall example computes the streamfunction, but it applies tmask, tmult that I could not find where they are defined in the file. I was experimenting with different masks. Do you know how postnek compute the streamfunction? I think it is computed in the subroutine strfct(psi) in postnek2.f, but I am not sure what happens in the routine? Thanks, Hannah ________________________________________ From: Nek5000-users [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, June 29, 2018 3:47 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Stream function Hi Hannah, I tried to implement the streamfunction as well (for a 2D cylinder flow) and it would appear that, doing na?vely, the tmask is set to zero everywhere. Hence, when rhs * tmask is computed in the hmholtz subroutine, rhs is set to zero everywhere and it then makes sense that the returned streamfunction is zero everywhere as well. Not sure how to do fix this properly though. Any help would be appreciated indeed :) ++ JC On 06/28/2018 09:41 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Philipp, > > Thanks very much for your comments. Yes, the delta* works only for the parallel plate. > > The streamfunction computation with the Blasius example is still not working. I suspect I am not using the correct mask (vmult /tmult, imsh as well). > > Using the Blasius example, v1mask, vmult (imsh = 1), I dumped the streamfuntion to the temperature field. However, it only contains negative values and does not look physical (I pasted userchk below). > > Another Nek Example, ?mv_wall?, computes the streamfunction from the Possison equation using vorticity. It uses tmask, tmult, and imsh = 2. > > I tried implementing what was done in the ?mv_wall? example in the Blasius example, but the computed streamfunction is zero everywhere. > > Any ideas what I might be doing wrong? > > Any advice would be appreciated! > > Thanks again, > > Hannah > > c----------------------------------------------------------------------- > subroutine userchk > include 'SIZE' > include 'TOTAL' > > common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) > > common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) > common /blasiusg/ bin(lx1,ly1,lz1,lelv) > common /scrns/ dum(lx1*ly1*lz1*lelv) > > common /xtream/ psi(lx1*ly1*lz1*lelt) > $ , rhs(lx1*ly1*lz1*lelt) > $ , h1 (lx1*ly1*lz1*lelt) > $ , h2 (lx1*ly1*lz1*lelt) > > parameter (lt=lx1*ly1*lz1*lelt) > common /scrns/ vort(lt,3),w1(lt),w2(lt) > > integer bin > real normu(50),normv(50) > > real xmax,xmin,dx > save xmax,xmin,dx > > n = nx1*ny1*nz1*nelv > ifheat=.false. > call comp_vort3(vort , w1, w2, vx, vy, vz) > call copy (t,vort,n) ! Vorticity --> T > ifto = .true. ! Dump vorticity as T > c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > c Compute streamfunction from vorticity > call col3 (rhs,t,bm1,n) ! B*omega > call rone (h1,n) > call rzero(h2,n) > > ifield = 1 > tol = param(22) > imsh = 1 > call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh, > $ tol,200,1) > call copy (t,psi,n) ! Psi --> T (for output) > c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > > nfldt = 1 + npscal > > if (istep.eq.0) call outpost2(vx,vy,vz,pr,t,nfldt,' ') > > do i=1,n > dum(i) = 1.-vx(i,1,1,1) > enddo > tot_deficit = glsc2(dum,bm1,n) > xmin = glmin(xm1,n) > xmax = glmax(xm1,n) > delta_star = tot_deficit/(xmax-xmin) > tmin = glmin(t,n) > tmax = glmax(t,n) > vortmin = glmin(vort,n) > vortmax = glmax(vort,n) > if (nid.eq.0) write(6,1) istep,time,delta_star,vortmin,vortmax > if (nid.eq.0) write(6,1) istep,tmin,tmax > 1 format(i8,1p4e13.5,' blasius: delta*') > > return > end > c----------------------------------------------------------------------- > > > ________________________________________ > From: Nek5000-users [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, June 26, 2018 1:22 PM > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Stream function > > Hi, > To correctly compute the stream function, the rhs of the Poisson > equation needs to be the (negative) vorticity. Therefore, the line > > call col2(rhs,bm1,n) > > is wrong, and should be something like > > call col3(rhs, vorticity, bm1, n) > > where vorticity should be the computed vorticity using comp_vort. > > I guess your calculation of delta* only works for parallel boundary layers. > > Philipp > > > > On 2018-06-26 18:35, nek5000-users at lists.mcs.anl.gov wrote: >> Hi Phillip, >> >> I am using the ?Blasius? example test outputting the streamfunction as a >> scalar. >> >> I included my code below. I am not sure what I am doing wrong. >> >> In userchk, I added ?compute streamfunction from vorticity? from the >> psi_omega example, but it does not compute the psi properly? (max_psi = >> min_psi = 0 in every step) >> >> c----------------------------------------------------------------------- >> >> subroutine userchk >> >> include 'SIZE' >> >> include 'TOTAL' >> >> common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >> >> common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >> >> common /blasiusg/ bin(lx1,ly1,lz1,lelv) >> >> common /scrns/ dum(lx1*ly1*lz1*lelv) >> >> common /xtream/ psi(lx1*ly1*lz1*lelt) >> >> $ , rhs(lx1*ly1*lz1*lelt) >> >> $ , h1 (lx1*ly1*lz1*lelt) >> >> $ , h2 (lx1*ly1*lz1*lelt) >> >> integer bin >> >> real normu(50),normv(50) >> >> real xmax,xmin,dx >> >> save xmax,xmin,dx >> >> n = nx1*ny1*nz1*nelv >> >> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >> >> c Compute streamfunction from vorticity >> >> call col2(rhs,bm1,n) >> >> call rone (h1 ,n) >> >> call rzero(h2 ,n) >> >> tol = param(22) >> >> imsh = 1 >> >> call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh,tol,200,1) >> >> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >> >> if (istep.eq.0) call outpost(vx,vy,vz,pr,psi,' ') >> >> c Compute delta* >> >> do i=1,n >> >> dum(i) = 1.-vx(i,1,1,1) >> >> enddo >> >> tot_deficit = glsc2(dum,bm1,n) >> >> xmin = glmin(xm1,n) >> >> xmax = glmax(xm1,n) >> >> delta_star = tot_deficit/(xmax-xmin) >> >> psimin = glmin(psi,n) >> >> psimax = glmax(psi,n) >> >> if (nid.eq.0) write(6,1) istep,time,delta_star,psimin,psimax >> >> 1 format(i8,1p4e13.5,' blasius: delta*') >> >> return >> >> end >> >> >> >> _______________________________________________ >> 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 Wed Jul 4 17:27:07 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 4 Jul 2018 18:27:07 -0400 Subject: [Nek5000-users] Visualizing avg_all outputs Message-ID: Dear Neks, I'm running some cases of natural convection flows inside a box domain and I want to compute and visualize turbulent statistics of the velocity fields. I tried this workflow: - Call avg_all on every usrchk execution, thus I got a avg/rms/rm2-blah0.f* file for each iostep. - Execute visnek for each series of *blah0.f* files - Open the *.nek5000 files on paraview. blah.nek5000 works fine, showing all fields on every timestep, but for the avg,rms and rm2 series I only a few timesteps 'frames' out of all the *blah0.f* files. Last test I ran was: p010 = 100 seconds p015 = 50 p068 = 0 which outputted 200 *blah0.f* from where I got 200 timesteps frames for regular blah0.f* and only 4 timesteps for the avg_all fields. I would like some advice on how to properly generate the avg_all files or the post-processing workflow requiered to get a 'smooth' visualizing of the statistics. Regards, Nicol?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 5 09:04:17 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 5 Jul 2018 10:04:17 -0400 Subject: [Nek5000-users] Using a finite difference look up table as forcing in Nekton Message-ID: Hey all, This is a slightly long question and I appreciate your patience. I wanted to use a finite difference lookup table as my forcing, specifically 'ffx'. For this, I read in the finite difference array from a text file and used a piecewise linear interpolant routine to interpolate onto the SEM grid given by xm1(i,1,1,1) and ym1(i,1,1,1), where i=1,lx1*ly1*lz1*lelt. Now, this worked fine in my smaller test domain having 6 elements, calculated in just 1 processor. However, my actual problem size is big, having 252 elements on 48 processors and I am having trouble with parallelization. I tried to load the input finite difference forcing onto each mpi rank and then use the interpolation routine by using a previous suggestion by Paul. subroutine usrdat2 include 'SIZE' include 'TOTAL' parameter (my_array_size=10000) real my_array(my_array_size), work(my_array_size) n = my_array_size call rzero(my_array,n) call rzero(work. ,n) if (nid.eq.0) then open (unit=49,file='myfile') read(49,*) (my_array(k),k=1,n) close(49) endif call gop(my_array,work,'+ ',n) ! Sum over all processors return end However, I get a bunch of NaN s in the output log. I believe my troubles are related to the parallelization part. Would like to know how to proceed. Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 5 10:26:08 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 5 Jul 2018 15:26:08 +0000 Subject: [Nek5000-users] Visualizing avg_all outputs In-Reply-To: References: Message-ID: Hi Nicolas, Frequency of the average output is controlled by param 68. Default I believe is 500 if p68=0. Note that if you output avg files every time step it will look just like a regular f0000 file because each avg file is just an average over the steps from the previous avg output step. So, in the case of p68=500, avgx0.f00001 would have the average for steps 1-500; ...02 would have 501 to 1000; etc. hth, Paul ________________________________ From: Nek5000-users on behalf of nek5000-users at lists.mcs.anl.gov Sent: Wednesday, July 4, 2018 5:27:07 PM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Visualizing avg_all outputs Dear Neks, I'm running some cases of natural convection flows inside a box domain and I want to compute and visualize turbulent statistics of the velocity fields. I tried this workflow: - Call avg_all on every usrchk execution, thus I got a avg/rms/rm2-blah0.f* file for each iostep. - Execute visnek for each series of *blah0.f* files - Open the *.nek5000 files on paraview. blah.nek5000 works fine, showing all fields on every timestep, but for the avg,rms and rm2 series I only a few timesteps 'frames' out of all the *blah0.f* files. Last test I ran was: p010 = 100 seconds p015 = 50 p068 = 0 which outputted 200 *blah0.f* from where I got 200 timesteps frames for regular blah0.f* and only 4 timesteps for the avg_all fields. I would like some advice on how to properly generate the avg_all files or the post-processing workflow requiered to get a 'smooth' visualizing of the statistics. Regards, Nicol?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 5 12:49:21 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 5 Jul 2018 13:49:21 -0400 Subject: [Nek5000-users] Visualizing avg_all outputs Message-ID: Hi Paul, I have avg_all dump frequency defined as equal to iostep so on every run i got the same amount of blah0.f**** and avgblah0.f**** files. The thing is, after I execute visnek and open the *.nek5000 with paraview, the blah.nek5000 has, let's say, 50 timesteps and the avgblah.nek5000 only shows 3 timesteps out of the same amount of files. I tried with p68=0 (wich makes iastep=iostep) and p68=10 with the same result. Nicol?s Hi Nicolas, > > > Frequency of the average output is controlled by param 68. > > Default I believe is 500 if p68=0. > > > Note that if you output avg files every time step it will look just like > > a regular f0000 file because each avg file is just an average over the > > steps from the previous avg output step. So, in the case of p68=500, > > avgx0.f00001 would have the average for steps 1-500; ...02 would have > > 501 to 1000; etc. > > > hth, > > > Paul > > Dear Neks, >> >> I'm running some cases of natural convection flows inside a box domain and I want to compute and visualize turbulent statistics of the velocity fields. >> >> I tried this workflow: >> - Call avg_all on every usrchk execution, thus I got a avg/rms/rm2-blah0.f* file for each iostep. >> - Execute visnek for each series of *blah0.f* files >> - Open the *.nek5000 files on paraview. >> >> blah.nek5000 works fine, showing all fields on every timestep, but for the avg,rms and rm2 series I only a few timesteps 'frames' out of all the *blah0.f* files. >> >> >> Last test I ran was: >> >> p010 = 100 seconds >> p015 = 50 >> p068 = 0 >> >> which outputted 200 *blah0.f* from where I got 200 timesteps frames for regular blah0.f* and only 4 timesteps for the avg_all fields. >> >> I would like some advice on how to properly generate the avg_all files or the post-processing workflow requiered to get a 'smooth' visualizing of the statistics. >> >> >> Regards, >> >> Nicol?s >> >> *Nicol?s Andr?s ?rdenes Leiva* Estudiante de Ingenier?a Civil Mec?nica Universidad T?cnica Federico Santa Mar?a Tel: +56 9 7619 2857 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jul 6 03:48:27 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 6 Jul 2018 10:48:27 +0200 Subject: [Nek5000-users] Meshing Rounded Rectangle Message-ID: Good morning community, I am having trouble converting a Mesh from Gabit to Nek5000. I've tried using a Matlab code that I found here in this community, but there seems to be some issues with the Periodic Boundary Conditions. Anyway, I am trying to model the following geometry: [image: image.png] As you can see, it's pretty much a rectangle, only that the corners are slightly rounded (2.5% every corner). The mesh has several boxes that I could easily mesh using genbox, but I don't know how to proceed with the rounded part. This picture is 2D but the model should be extruded to 3D (I believe n2to3 can perform that action. Thank you very much, Roger -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 3885 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RoundedRectangle.PNG Type: image/png Size: 2102 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Sun Jul 8 01:30:06 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 8 Jul 2018 14:30:06 +0800 Subject: [Nek5000-users] Extruding 2D .fld file to 3D Message-ID: Dear Paul and Neks, I followed your instructions to extrude a 2D field results to 3D: What I did are: 1. run the 2D simulation to get a 2D ascii field. I actived UPT, there should be 6 columns. as followed: 1874 6 6 1 6.0000000E+02 0 X Y U P T NELT,NX,NY,N 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 ...... ....... 0.000 0.000 0.000 0.000 0.000 0.000 * 0.000 0.000* 1.000000E+00 1.550000E+01 9.999999E-01 1.290108E-02 8.919954E-08 0.000000E+00 8.825276E-01 1.550000E+01 9.999999E-01 1.281575E-02 1.081013E-07 0.000000E+00 6.426157E-01 1.550000E+01 9.999999E-01 1.264053E-02 1.421044E-07 0.000000E+00 3.573842E-01 1.550000E+01 1.000000E+00 1.243110E-02 1.706964E-07 0.000000E+00 ........... .......... 2. I get rid the first line, and the row only contains two-column 3. generated a 3D mesh by n2to3, using 4 levels in 1-spanwise length 4. setup a 3D simulation by a modified SIZE parameter (lelx=1874,lely=1,lelz=4) ! global tensor mesh dimensions 5. define usrdat2 as follows subroutine usrdat2 include 'SIZE' include 'TOTAL' parameter (l2d=lx1*ly1*lelx) ! Number of points in 2D field common /mystuff/ u2d(l2d),v2d(l2d) nelx=lelx nely=lely nelz=lelz if (nid.eq.0) then open(33,file='2D.dat') do i=1,l2d read(33,*) u2d(i),v2d(i) enddo close(33) endif nbytes = 8*l2d call bcast(u2d,nbytes) call bcast(v2d,nbytes) call z_average_transpose(vx,u2d) ! distribute u2d to each plane vx call z_average_transpose(vy,v2d) call outpost(vx,vy,vz,pr,t,' ') call exitti('Quit in usrdat2.$',nelgt) return end 6 run the 3D simulation, and it appears call usrdat2 Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: Backtrace for this error: #0 0x7FB31EDF4407 #1 0x7FB31EDF4A1E #2 0x7FB31E0F40DF #0 0x7F66D6B5B407 #1 0x7F66D6B5BA1E #2 0x7F66D5E5B0DF #3 0x4ADA8B in get_exyz_ #3 0x4ADA8B in get_exyz_ #4 0x4AE100 in z_average_transpose_ #4 0x4AE100 in z_average_transpose_ #5 0x40381B in usrdat2_ #5 0x40381B in usrdat2_ #6 0x404017 in nek_init_ #6 0x404017 in nek_init_ #0 0x7F9A77280407 #1 0x7F9A77280A1E #2 0x7F9A765800DF #3 0x4ADA8B in get_exyz_ #4 0x4AE100 in z_average_transpose_ #5 0x40381B in usrdat2_ #6 0x404017 in nek_init_ #0 0x7FD15A1FE407 #1 0x7FD15A1FEA1E #2 0x7FD1594FE0DF #3 0x4ADA8B in get_exyz_ #4 0x4AE100 in z_average_transpose_ #5 0x40381B in usrdat2_ #6 0x404017 in nek_init_ ------------------------------------------------------- Primary job terminated normally, but 1 process returne I tried different parameters, unfortunately none of them works, Would anyone like to help me? Thanks! Wei -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Jul 8 14:16:35 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 8 Jul 2018 19:16:35 +0000 Subject: [Nek5000-users] Extruding 2D .fld file to 3D Message-ID: Hi Wei, Try using the attached usr file.. Make sure the following parameters are set correctly in userchk: resname = 'ext_cyl.fld17' nel2m = 1472 where nel2m is the number of elements in 2D mesh (3d mesh should be n2to3 of this 2D mesh, and lx1 should stay the same), and resname is the name of the ascii fld file. This usr file DOES NOT utilize lelx,lely,lelz etc... If this does not work, we can connect via email and I can try to help you do this. Ketan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fld2to3.usr Type: application/octet-stream Size: 10143 bytes Desc: fld2to3.usr URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: README Type: application/octet-stream Size: 4666 bytes Desc: README URL: From nek5000-users at lists.mcs.anl.gov Mon Jul 9 12:47:15 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 9 Jul 2018 17:47:15 +0000 Subject: [Nek5000-users] CFL's impact on data & 3D without .rea Message-ID: Hello NekGurus, I have been studying Nek5000 this summer as part of a project investigating it's viability as a replacement/alternative to other commercial codes. My two test cases, natural circulation & convective pipe flow, are producing nice results with the only issue being a 'WARNING: DIV(V)-QTL too large!' after X time steps. I've increased my targetCFL, from 0.4 to 4.0, and changed dt from variable to fixed. This has eliminated the warning, at the cost of a longer runtime. My first question is; will the changes to the CFL value effect the accuracy of temperature or velocity results? Second, I would like to expand one (or both) of the cases to 3d, do I need to create .rea file to do this, or is it better to import a 3d .STEP file? I've tried using n2to3 and re2torea, but the later outputs the following: 'At line 70 of file re2torea.f Fortran runtime error: End of file.' With an empty .rea file. It is my impression that the .rea file is no longer necessary. Is this incorrect? Please advise on the best way to proceed. Thank you very much, Mario Mario R. Naranjo Computational Sciences and Engineering Los Alamos National Laboratory naranjom at lanl.gov | W: 505-664-0978 | M: 505-980-4187 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jul 10 12:02:41 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 10 Jul 2018 17:02:41 +0000 Subject: [Nek5000-users] Nek5000-users Digest, Vol 113, Issue 6 In-Reply-To: References: Message-ID: Hello NekFolks, Please remove my phone numbers and work email from public view Thanks, Mario -----Original Message----- From: Nek5000-users On Behalf Of nek5000-users-request at lists.mcs.anl.gov Sent: Tuesday, July 10, 2018 11:00 AM To: nek5000-users at lists.mcs.anl.gov Subject: Nek5000-users Digest, Vol 113, Issue 6 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. CFL's impact on data & 3D without .rea (nek5000-users at lists.mcs.anl.gov) ---------------------------------------------------------------------- Message: 1 Date: Mon, 9 Jul 2018 17:47:15 +0000 From: nek5000-users at lists.mcs.anl.gov To: "nek5000-users at lists.mcs.anl.gov" Subject: [Nek5000-users] CFL's impact on data & 3D without .rea Message-ID: Content-Type: text/plain; charset="us-ascii" Hello NekGurus, I have been studying Nek5000 this summer as part of a project investigating it's viability as a replacement/alternative to other commercial codes. My two test cases, natural circulation & convective pipe flow, are producing nice results with the only issue being a 'WARNING: DIV(V)-QTL too large!' after X time steps. I've increased my targetCFL, from 0.4 to 4.0, and changed dt from variable to fixed. This has eliminated the warning, at the cost of a longer runtime. My first question is; will the changes to the CFL value effect the accuracy of temperature or velocity results? Second, I would like to expand one (or both) of the cases to 3d, do I need to create .rea file to do this, or is it better to import a 3d .STEP file? I've tried using n2to3 and re2torea, but the later outputs the following: 'At line 70 of file re2torea.f Fortran runtime error: End of file.' With an empty .rea file. It is my impression that the .rea file is no longer necessary. Is this incorrect? Please advise on the best way to proceed. Thank you very much, Mario Mario R. Naranjo Computational Sciences and Engineering Los Alamos National Laboratory naranjom at lanl.gov | W: 505-664-0978 | M: 505-980-4187 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ 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 113, Issue 6 ********************************************* From nek5000-users at lists.mcs.anl.gov Tue Jul 10 12:42:33 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 10 Jul 2018 17:42:33 +0000 Subject: [Nek5000-users] CFL's impact on data & 3D without .rea In-Reply-To: References: Message-ID: Hi Mario, Please contact me offline at obabko at mcs.anl.gov Aleks ________________________________ From: Nek5000-users on behalf of nek5000-users at lists.mcs.anl.gov Sent: Monday, July 9, 2018 12:47:15 PM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] CFL's impact on data & 3D without .rea Hello NekGurus, I have been studying Nek5000 this summer as part of a project investigating it?s viability as a replacement/alternative to other commercial codes. My two test cases, natural circulation & convective pipe flow, are producing nice results with the only issue being a ?WARNING: DIV(V)-QTL too large!? after X time steps. I?ve increased my targetCFL, from 0.4 to 4.0, and changed dt from variable to fixed. This has eliminated the warning, at the cost of a longer runtime. My first question is; will the changes to the CFL value effect the accuracy of temperature or velocity results? Second, I would like to expand one (or both) of the cases to 3d, do I need to create .rea file to do this, or is it better to import a 3d .STEP file? I?ve tried using n2to3 and re2torea, but the later outputs the following: ?At line 70 of file re2torea.f Fortran runtime error: End of file.? With an empty .rea file. It is my impression that the .rea file is no longer necessary. Is this incorrect? Please advise on the best way to proceed. Thank you very much, Mario Mario R. Naranjo Computational Sciences and Engineering Los Alamos National Laboratory naranjom at lanl.gov | W: 505-664-0978 | M: 505-980-4187 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jul 10 15:33:14 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 10 Jul 2018 22:33:14 +0200 Subject: [Nek5000-users] Stream function In-Reply-To: References: Message-ID: Dear Hannah, sorry that I only see the post now. Are you still having problems with the stream function, or does it work now? Best regards, Philipp On 2018-07-02 16:40, nek5000-users at lists.mcs.anl.gov wrote: > Hi JC, > > Yes, the mv_wall example computes the streamfunction, but it applies tmask, tmult that I could not find where they are defined in the file. I was experimenting with different masks. > > Do you know how postnek compute the streamfunction? > > I think it is computed in the subroutine strfct(psi) in postnek2.f, but I am not sure what happens in the routine? > > Thanks, > > Hannah > ________________________________________ > From: Nek5000-users [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, June 29, 2018 3:47 AM > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Stream function > > Hi Hannah, > > I tried to implement the streamfunction as well (for a 2D cylinder flow) > and it would appear that, doing na?vely, the tmask is set to zero > everywhere. Hence, when rhs * tmask is computed in the hmholtz > subroutine, rhs is set to zero everywhere and it then makes sense that > the returned streamfunction is zero everywhere as well. > > Not sure how to do fix this properly though. Any help would be > appreciated indeed :) > > > ++ > JC > > > On 06/28/2018 09:41 PM, nek5000-users at lists.mcs.anl.gov wrote: >> Hi Philipp, >> >> Thanks very much for your comments. Yes, the delta* works only for the parallel plate. >> >> The streamfunction computation with the Blasius example is still not working. I suspect I am not using the correct mask (vmult /tmult, imsh as well). >> >> Using the Blasius example, v1mask, vmult (imsh = 1), I dumped the streamfuntion to the temperature field. However, it only contains negative values and does not look physical (I pasted userchk below). >> >> Another Nek Example, ?mv_wall?, computes the streamfunction from the Possison equation using vorticity. It uses tmask, tmult, and imsh = 2. >> >> I tried implementing what was done in the ?mv_wall? example in the Blasius example, but the computed streamfunction is zero everywhere. >> >> Any ideas what I might be doing wrong? >> >> Any advice would be appreciated! >> >> Thanks again, >> >> Hannah >> >> c----------------------------------------------------------------------- >> subroutine userchk >> include 'SIZE' >> include 'TOTAL' >> >> common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >> >> common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >> common /blasiusg/ bin(lx1,ly1,lz1,lelv) >> common /scrns/ dum(lx1*ly1*lz1*lelv) >> >> common /xtream/ psi(lx1*ly1*lz1*lelt) >> $ , rhs(lx1*ly1*lz1*lelt) >> $ , h1 (lx1*ly1*lz1*lelt) >> $ , h2 (lx1*ly1*lz1*lelt) >> >> parameter (lt=lx1*ly1*lz1*lelt) >> common /scrns/ vort(lt,3),w1(lt),w2(lt) >> >> integer bin >> real normu(50),normv(50) >> >> real xmax,xmin,dx >> save xmax,xmin,dx >> >> n = nx1*ny1*nz1*nelv >> ifheat=.false. >> call comp_vort3(vort , w1, w2, vx, vy, vz) >> call copy (t,vort,n) ! Vorticity --> T >> ifto = .true. ! Dump vorticity as T >> c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >> c Compute streamfunction from vorticity >> call col3 (rhs,t,bm1,n) ! B*omega >> call rone (h1,n) >> call rzero(h2,n) >> >> ifield = 1 >> tol = param(22) >> imsh = 1 >> call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh, >> $ tol,200,1) >> call copy (t,psi,n) ! Psi --> T (for output) >> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >> >> nfldt = 1 + npscal >> >> if (istep.eq.0) call outpost2(vx,vy,vz,pr,t,nfldt,' ') >> >> do i=1,n >> dum(i) = 1.-vx(i,1,1,1) >> enddo >> tot_deficit = glsc2(dum,bm1,n) >> xmin = glmin(xm1,n) >> xmax = glmax(xm1,n) >> delta_star = tot_deficit/(xmax-xmin) >> tmin = glmin(t,n) >> tmax = glmax(t,n) >> vortmin = glmin(vort,n) >> vortmax = glmax(vort,n) >> if (nid.eq.0) write(6,1) istep,time,delta_star,vortmin,vortmax >> if (nid.eq.0) write(6,1) istep,tmin,tmax >> 1 format(i8,1p4e13.5,' blasius: delta*') >> >> return >> end >> c----------------------------------------------------------------------- >> >> >> ________________________________________ >> From: Nek5000-users [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, June 26, 2018 1:22 PM >> To: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] Stream function >> >> Hi, >> To correctly compute the stream function, the rhs of the Poisson >> equation needs to be the (negative) vorticity. Therefore, the line >> >> call col2(rhs,bm1,n) >> >> is wrong, and should be something like >> >> call col3(rhs, vorticity, bm1, n) >> >> where vorticity should be the computed vorticity using comp_vort. >> >> I guess your calculation of delta* only works for parallel boundary layers. >> >> Philipp >> >> >> >> On 2018-06-26 18:35, nek5000-users at lists.mcs.anl.gov wrote: >>> Hi Phillip, >>> >>> I am using the ?Blasius? example test outputting the streamfunction as a >>> scalar. >>> >>> I included my code below. I am not sure what I am doing wrong. >>> >>> In userchk, I added ?compute streamfunction from vorticity? from the >>> psi_omega example, but it does not compute the psi properly? (max_psi = >>> min_psi = 0 in every step) >>> >>> c----------------------------------------------------------------------- >>> >>> subroutine userchk >>> >>> include 'SIZE' >>> >>> include 'TOTAL' >>> >>> common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >>> >>> common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >>> >>> common /blasiusg/ bin(lx1,ly1,lz1,lelv) >>> >>> common /scrns/ dum(lx1*ly1*lz1*lelv) >>> >>> common /xtream/ psi(lx1*ly1*lz1*lelt) >>> >>> $ , rhs(lx1*ly1*lz1*lelt) >>> >>> $ , h1 (lx1*ly1*lz1*lelt) >>> >>> $ , h2 (lx1*ly1*lz1*lelt) >>> >>> integer bin >>> >>> real normu(50),normv(50) >>> >>> real xmax,xmin,dx >>> >>> save xmax,xmin,dx >>> >>> n = nx1*ny1*nz1*nelv >>> >>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>> >>> c Compute streamfunction from vorticity >>> >>> call col2(rhs,bm1,n) >>> >>> call rone (h1 ,n) >>> >>> call rzero(h2 ,n) >>> >>> tol = param(22) >>> >>> imsh = 1 >>> >>> call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh,tol,200,1) >>> >>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>> >>> if (istep.eq.0) call outpost(vx,vy,vz,pr,psi,' ') >>> >>> c Compute delta* >>> >>> do i=1,n >>> >>> dum(i) = 1.-vx(i,1,1,1) >>> >>> enddo >>> >>> tot_deficit = glsc2(dum,bm1,n) >>> >>> xmin = glmin(xm1,n) >>> >>> xmax = glmax(xm1,n) >>> >>> delta_star = tot_deficit/(xmax-xmin) >>> >>> psimin = glmin(psi,n) >>> >>> psimax = glmax(psi,n) >>> >>> if (nid.eq.0) write(6,1) istep,time,delta_star,psimin,psimax >>> >>> 1 format(i8,1p4e13.5,' blasius: delta*') >>> >>> return >>> >>> end >>> >>> >>> >>> _______________________________________________ >>> 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 Jul 10 16:11:04 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 10 Jul 2018 21:11:04 +0000 Subject: [Nek5000-users] Stream function In-Reply-To: References: , Message-ID: Hi Philipp, No, I could not get it to work in Nek... :( Any advice would be appreciated! Thanks very much, Hannah ________________________________________ From: Nek5000-users [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, July 10, 2018 3:33 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Stream function Dear Hannah, sorry that I only see the post now. Are you still having problems with the stream function, or does it work now? Best regards, Philipp On 2018-07-02 16:40, nek5000-users at lists.mcs.anl.gov wrote: > Hi JC, > > Yes, the mv_wall example computes the streamfunction, but it applies tmask, tmult that I could not find where they are defined in the file. I was experimenting with different masks. > > Do you know how postnek compute the streamfunction? > > I think it is computed in the subroutine strfct(psi) in postnek2.f, but I am not sure what happens in the routine? > > Thanks, > > Hannah > ________________________________________ > From: Nek5000-users [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, June 29, 2018 3:47 AM > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Stream function > > Hi Hannah, > > I tried to implement the streamfunction as well (for a 2D cylinder flow) > and it would appear that, doing na?vely, the tmask is set to zero > everywhere. Hence, when rhs * tmask is computed in the hmholtz > subroutine, rhs is set to zero everywhere and it then makes sense that > the returned streamfunction is zero everywhere as well. > > Not sure how to do fix this properly though. Any help would be > appreciated indeed :) > > > ++ > JC > > > On 06/28/2018 09:41 PM, nek5000-users at lists.mcs.anl.gov wrote: >> Hi Philipp, >> >> Thanks very much for your comments. Yes, the delta* works only for the parallel plate. >> >> The streamfunction computation with the Blasius example is still not working. I suspect I am not using the correct mask (vmult /tmult, imsh as well). >> >> Using the Blasius example, v1mask, vmult (imsh = 1), I dumped the streamfuntion to the temperature field. However, it only contains negative values and does not look physical (I pasted userchk below). >> >> Another Nek Example, ?mv_wall?, computes the streamfunction from the Possison equation using vorticity. It uses tmask, tmult, and imsh = 2. >> >> I tried implementing what was done in the ?mv_wall? example in the Blasius example, but the computed streamfunction is zero everywhere. >> >> Any ideas what I might be doing wrong? >> >> Any advice would be appreciated! >> >> Thanks again, >> >> Hannah >> >> c----------------------------------------------------------------------- >> subroutine userchk >> include 'SIZE' >> include 'TOTAL' >> >> common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >> >> common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >> common /blasiusg/ bin(lx1,ly1,lz1,lelv) >> common /scrns/ dum(lx1*ly1*lz1*lelv) >> >> common /xtream/ psi(lx1*ly1*lz1*lelt) >> $ , rhs(lx1*ly1*lz1*lelt) >> $ , h1 (lx1*ly1*lz1*lelt) >> $ , h2 (lx1*ly1*lz1*lelt) >> >> parameter (lt=lx1*ly1*lz1*lelt) >> common /scrns/ vort(lt,3),w1(lt),w2(lt) >> >> integer bin >> real normu(50),normv(50) >> >> real xmax,xmin,dx >> save xmax,xmin,dx >> >> n = nx1*ny1*nz1*nelv >> ifheat=.false. >> call comp_vort3(vort , w1, w2, vx, vy, vz) >> call copy (t,vort,n) ! Vorticity --> T >> ifto = .true. ! Dump vorticity as T >> c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >> c Compute streamfunction from vorticity >> call col3 (rhs,t,bm1,n) ! B*omega >> call rone (h1,n) >> call rzero(h2,n) >> >> ifield = 1 >> tol = param(22) >> imsh = 1 >> call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh, >> $ tol,200,1) >> call copy (t,psi,n) ! Psi --> T (for output) >> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >> >> nfldt = 1 + npscal >> >> if (istep.eq.0) call outpost2(vx,vy,vz,pr,t,nfldt,' ') >> >> do i=1,n >> dum(i) = 1.-vx(i,1,1,1) >> enddo >> tot_deficit = glsc2(dum,bm1,n) >> xmin = glmin(xm1,n) >> xmax = glmax(xm1,n) >> delta_star = tot_deficit/(xmax-xmin) >> tmin = glmin(t,n) >> tmax = glmax(t,n) >> vortmin = glmin(vort,n) >> vortmax = glmax(vort,n) >> if (nid.eq.0) write(6,1) istep,time,delta_star,vortmin,vortmax >> if (nid.eq.0) write(6,1) istep,tmin,tmax >> 1 format(i8,1p4e13.5,' blasius: delta*') >> >> return >> end >> c----------------------------------------------------------------------- >> >> >> ________________________________________ >> From: Nek5000-users [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, June 26, 2018 1:22 PM >> To: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] Stream function >> >> Hi, >> To correctly compute the stream function, the rhs of the Poisson >> equation needs to be the (negative) vorticity. Therefore, the line >> >> call col2(rhs,bm1,n) >> >> is wrong, and should be something like >> >> call col3(rhs, vorticity, bm1, n) >> >> where vorticity should be the computed vorticity using comp_vort. >> >> I guess your calculation of delta* only works for parallel boundary layers. >> >> Philipp >> >> >> >> On 2018-06-26 18:35, nek5000-users at lists.mcs.anl.gov wrote: >>> Hi Phillip, >>> >>> I am using the ?Blasius? example test outputting the streamfunction as a >>> scalar. >>> >>> I included my code below. I am not sure what I am doing wrong. >>> >>> In userchk, I added ?compute streamfunction from vorticity? from the >>> psi_omega example, but it does not compute the psi properly? (max_psi = >>> min_psi = 0 in every step) >>> >>> c----------------------------------------------------------------------- >>> >>> subroutine userchk >>> >>> include 'SIZE' >>> >>> include 'TOTAL' >>> >>> common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >>> >>> common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >>> >>> common /blasiusg/ bin(lx1,ly1,lz1,lelv) >>> >>> common /scrns/ dum(lx1*ly1*lz1*lelv) >>> >>> common /xtream/ psi(lx1*ly1*lz1*lelt) >>> >>> $ , rhs(lx1*ly1*lz1*lelt) >>> >>> $ , h1 (lx1*ly1*lz1*lelt) >>> >>> $ , h2 (lx1*ly1*lz1*lelt) >>> >>> integer bin >>> >>> real normu(50),normv(50) >>> >>> real xmax,xmin,dx >>> >>> save xmax,xmin,dx >>> >>> n = nx1*ny1*nz1*nelv >>> >>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>> >>> c Compute streamfunction from vorticity >>> >>> call col2(rhs,bm1,n) >>> >>> call rone (h1 ,n) >>> >>> call rzero(h2 ,n) >>> >>> tol = param(22) >>> >>> imsh = 1 >>> >>> call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh,tol,200,1) >>> >>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>> >>> if (istep.eq.0) call outpost(vx,vy,vz,pr,psi,' ') >>> >>> c Compute delta* >>> >>> do i=1,n >>> >>> dum(i) = 1.-vx(i,1,1,1) >>> >>> enddo >>> >>> tot_deficit = glsc2(dum,bm1,n) >>> >>> xmin = glmin(xm1,n) >>> >>> xmax = glmax(xm1,n) >>> >>> delta_star = tot_deficit/(xmax-xmin) >>> >>> psimin = glmin(psi,n) >>> >>> psimax = glmax(psi,n) >>> >>> if (nid.eq.0) write(6,1) istep,time,delta_star,psimin,psimax >>> >>> 1 format(i8,1p4e13.5,' blasius: delta*') >>> >>> return >>> >>> end >>> >>> >>> >>> _______________________________________________ >>> 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 Wed Jul 11 02:25:19 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 11 Jul 2018 15:25:19 +0800 Subject: [Nek5000-users] Extruding 2D .fld file to 3D In-Reply-To: References: Message-ID: Dear Ketan, Thanks for your quick response! I tried your subroutine, and found that the output results as followed: 1. the coordinates is correctly written as I want. 2. while the u- and v-velocity is replaced by the coordinates values of x and y, respectively. 3. The u component is stored in the "pressure variable". no v and pressure is stored. I tried to change the *usr setup, but make it more worse, would you like to help me to solve it? Thanks! regards, Wei On Mon, Jul 9, 2018 at 3:16 AM, wrote: > Hi Wei, > > Try using the attached usr file.. Make sure the following parameters are > set correctly in userchk: > > resname = 'ext_cyl.fld17' > nel2m = 1472 > > where nel2m is the number of elements in 2D mesh (3d mesh should be n2to3 > of this 2D mesh, and lx1 should stay the same), and resname is the name of > the ascii fld file. This usr file DOES NOT utilize lelx,lely,lelz etc... > > If this does not work, we can connect via email and I can try to help you > do this. > > Ketan > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- Wei HE ?? School of Aeronautics Universidad Polit?cnica de Madrid http://www.cfm.upm.es/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jul 11 08:22:43 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 11 Jul 2018 13:22:43 +0000 Subject: [Nek5000-users] Pipe Roughness Message-ID: Dear all, Can anybody tell me how to take into account the roughness of the pipe? Do I have to change the geometry or there is something easier? Any help would be greatly appreciated, Ali Embry-Riddle Aeronautical University -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jul 11 10:25:50 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 11 Jul 2018 15:25:50 +0000 Subject: [Nek5000-users] Extruding 2D .fld file to 3D Message-ID: Hi Wei, Sure, send me your 2D fld file and rea file via email: k m i t t a l 2 at i l l i n o i s . e d u Ketan From nek5000-users at lists.mcs.anl.gov Wed Jul 11 10:34:26 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 11 Jul 2018 11:34:26 -0400 Subject: [Nek5000-users] Using an external file for forcing in 'ffx' Message-ID: Hey All, I have been stuck in this problem for a while now but I think it should be simple and probably you can tell where I am going wrong. - So I have a forcing function on a finite difference X-Y grid, which I am reading in as a text file in the 'userdat2' subroutine. - I am then parallelizing it using a previous suggestion by Paul, here is a snippet of the routine. ------------------------------------------------------------ -------------------------------------------- subroutine usrdat2 include 'SIZE' include 'TOTAL' double precision :: my_array(651) integer m common /myarray/ my_array parameter (my_array_size=651) real work(my_array_size) n = my_array_size call rzero(my_array,n) call rzero(work,n) if (nid.eq.0) then open (unit=49,file='fint41.txt') do k = 1,n read(49,*) my_array(k) enddo close(49) endif call gop(my_array,work,'+ ',n) ! Sum over all processors return end ------------------------------------------------------------ --------------------------------------------- - Next I am interpolating this forcing function to the GLL grid points in the userf routine, by a piecewise linear interpolant, here's how, ------------------------------------------------------------ ---------------------------------------------- subroutine userf (ix,iy,iz,ieg) include 'SIZE' include 'TOTAL' include 'NEKUSE' EQUIVALENCE (prandtl,param(2)) double precision :: my_array(651) double precision :: shaped_array(31,21) real new_array(nx1,ny1,nz1,nelv) double precision :: xin(21),yin(31) double precision :: xn(nx1*ny1*nelv),yn(nx1*ny1*nelv) double precision :: fo(nx1*ny1*nelv) integer i,j,k,l,p,q integer e,eg common /myarray/ my_array open(16,file='xin.txt') do p=1,21 read(16,*) xin(p) end do close(16) open(12,file='yin.txt') do q=1,31 read(12,*) yin(q) end do close(12) shaped_array = reshape(my_array,(/31,21/)) do i=1,nx1*ny1*nelv xn(i) = xm1(i,1,1,1) yn(i) = ym1(i,1,1,1) end do call pwl_interp_2d(31,21,yin,xin,shaped_array,nx1*ny1*nelv,yn,xn, fo) new_array=reshape(fo,(/nx1,ny1,nz1,nelv/)) do e=1,nelv eg = lglel(e) ffx = new_array(ix,iy,iz,eg) end do ffy = 0.0 ffz = 0.0 return end ------------------------------------------------------------ --------------------------------------------------------------------------- This is a test domain I made, with 6 elements. It seems to be working when I am using only 1 core, i.e., in series. In parallel, it seems to be giving me a different flowfield. My actual domain has 252 elements which I intend to parallelize with 48 cores. So would like to ask you how to proceed. I think I am close but I am slightly confused about part of the code that I have made red. When I am trying this in my actual domain, I get an error, "Segmentation fault occurred." I think the key here is parallelization and identifying the elements correctly which I am not sure I am doing right. Thanks for reading this lengthy email. Will be eager to hear from you. Thanks, Saikat -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jul 11 13:58:41 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 11 Jul 2018 14:58:41 -0400 Subject: [Nek5000-users] Number of Elements per Characteristic Length for DNS Message-ID: Hello All, I am currently investigating the turbulence in a pipe with periodic boundary conditions. I am working on building my mesh and was planning on using Re^(3/4) as the number of elements per characteristic length, but I have found differing methods in literature detailing the number of elements used for DNS. One paper in particular (G.K. El Khoury et al, Direct Numerical Simulation of Turbulent Pipe Flow at Moderately High Reynolds Numbers, Flow Turbulence Combust, 2013) uses Nek5000 to simulate turbulent flow in a pipe at different Reynolds numbers. The number of elements calculated in this paper seem to be in between the LES and DNS suggested number of elements (element size between the Taylor microscale and the Kolmogorov scale). Turbulent Flows by Pope however suggests a number of elements that is slightly larger than Re^(3/4), and is dependent on the Taylor microscale Reynolds number. Any suggestions on the correct way to determine the number of spectral elements in a characteristic length would be appreciated. Regards, Tommy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 12 03:07:59 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 13:37:59 +0530 Subject: [Nek5000-users] Problem in obtaining eigenvalues through Arnoldi (using NEK5000 with the ARPACK library) Message-ID: Hi Neks I am running a 3D simulation for a flow over a cylinder. My domain size for simulation is 100Dx100D. where D is the diameter of a cylinder. We have obtained the base flow through SFD. The base flow is used to calculate the stability analysis through NEK5000 with the ARPACK library (Implemented by A. Peplinski). we have used the following parameters..... 90.0000 p111 : ARNOLDI: size of Krylov space 30.0000 p112 : ARNOLDI: number of eigenvectors We have run the Arnoldi with restart but we are not able to get the output file (eigenvalues.txt and egvext_cyl0.f0..) even after almost 20 restarts. Also, we tried to run with increasing the size of Krylov space but the eigenvalues are not converging. The log file shows no changes in converged ritz values after around 20-22 values. The part of the log file is shown below........... Kindly, help me out and let me know where I am going wrong..... Alok Mishra --------------------------------------------------------------------------------------------------------------- ARNOLDI: after 520 stepper phase _naup2: Corresponding B-norm of the residual -------------------------------------------- 1 - 1: 6.623D-01 _naup2: no. of "converged" Ritz values at this iter. ---------------------------------------------------- 1 - 1: 22 _naup2: NEV and NP are ---------------------- 1 - 2: 52 128 _naup2: "wanted" Ritz values -- real part ----------------------------------------- 1 - 5: 9.905D-01 9.905D-01 9.854D-01 9.854D-01 9.855D-01 6 - 10: 9.855D-01 9.897D-01 9.897D-01 9.924D-01 9.930D-01 11 - 15: 9.930D-01 9.905D-01 9.905D-01 9.943D-01 9.943D-01 16 - 20: 9.938D-01 9.938D-01 9.948D-01 9.948D-01 9.949D-01 21 - 25: 9.949D-01 9.951D-01 9.958D-01 9.960D-01 9.962D-01 26 - 30: 9.962D-01 9.966D-01 9.970D-01 9.970D-01 9.969D-01 31 - 35: 9.969D-01 9.973D-01 9.974D-01 9.975D-01 9.976D-01 36 - 40: 9.976D-01 9.971D-01 9.971D-01 9.978D-01 9.979D-01 41 - 45: 9.979D-01 9.982D-01 9.982D-01 1.000D+00 9.908D-01 46 - 50: 9.908D-01 1.004D+00 1.004D+00 1.005D+00 1.005D+00 51 - 52: 1.006D+00 1.006D+00 _naup2: "wanted" Ritz values -- imag part ----------------------------------------- 1 - 5: 5.038D-02 -5.038D-02 -1.127D-01 1.127D-01 -1.119D-01 6 - 10: 1.119D-01 6.954D-02 -6.954D-02 0.000D+00 3.705D-03 11 - 15: -3.705D-03 -7.103D-02 7.103D-02 -9.233D-04 9.233D-04 16 - 20: 4.345D-02 -4.345D-02 6.799D-04 -6.799D-04 -1.821D-02 21 - 25: 1.821D-02 0.000D+00 0.000D+00 0.000D+00 -2.047D-03 26 - 30: 2.047D-03 0.000D+00 7.200D-05 -7.200D-05 2.386D-02 31 - 35: -2.386D-02 0.000D+00 0.000D+00 0.000D+00 -1.140D-04 36 - 40: 1.140D-04 3.125D-02 -3.125D-02 0.000D+00 -1.248D-04 41 - 45: 1.248D-04 -1.673D-03 1.673D-03 0.000D+00 -1.508D-01 46 - 50: 1.508D-01 -1.863D-02 1.863D-02 -2.109D-02 2.109D-02 51 - 52: -1.152D-02 1.152D-02 _naup2: Ritz estimates of the "wanted" values ---------------------------------------------- 1 - 5: 3.315D-02 3.315D-02 3.244D-05 3.244D-05 7.035D-05 6 - 10: 7.035D-05 6.072D-11 6.072D-11 1.314D-02 2.772D-06 11 - 15: 2.772D-06 6.796D-15 6.796D-15 9.719D-04 9.719D-04 16 - 20: 7.467D-17 7.467D-17 5.506D-04 5.506D-04 2.437D-16 21 - 25: 2.437D-16 2.977D-03 7.238D-04 6.054D-04 3.914D-11 26 - 30: 3.914D-11 1.827D-04 1.138D-04 1.138D-04 1.048D-16 31 - 35: 1.048D-16 1.198D-04 6.358D-05 3.013D-05 3.490D-07 36 - 40: 3.490D-07 9.960D-18 9.960D-18 1.340D-07 2.518D-10 41 - 45: 2.518D-10 1.827D-16 1.827D-16 1.781D-16 7.278D-17 46 - 50: 7.278D-17 0.000D+00 0.000D+00 0.000D+00 0.000D+00 51 - 52: 0.000D+00 0.000D+00 Reached max iteration number; settingido=-2 for checkpointing. ARNOLDI: IDOARP = -2 Writing checkpoint 0 40 OPEN: ARPm11800.f00002 0 40 OPEN: ARVm11800.f00002 40 2.0000E-01 done :: Write checkpoint file size = 621.E+00MB avg data-throughput = 624.1MB/s io-nodes = 1 ARNOLDI: finalize Number of stepper cycles 520 Time spent in ARNOLDI 60.3302609920502 Average stepper phase time 10.9141681075096 call outfld: ifpsco: F 40 2.0000E-01 Write checkpoint: 0 40 OPEN: m11800.f00001 40 2.0000E-01 done :: Write checkpoint file size = 4.0 MB avg data-throughput = 303.2MB/s io-nodes = 1 end of time-step loop -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 12 03:20:08 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 10:20:08 +0200 Subject: [Nek5000-users] Pipe Roughness In-Reply-To: References: Message-ID: The typical way would be to change explicitly the surface geometry, either by changing the location of the mesh (i.e. "surface" fitted) or by some type of immersed boundary method. For the first method, the approach certainly depends on the type (and scale) of the intended roughness, for instance there might be the possibility to use a neknek approach to decouple the mesh in the pipe centre and the one close to the surface. For the immersed boundary method, there is a simple, but apparently quite efficient way that could be suitable for dissimilar roughness (i.e. small scale), see e.g. here: https://journals.aps.org/prfluids/abstract/10.1103/PhysRevFluids.3.044605 You might also try out approaches based on wall models with a specific slip velocity as e.g. done in atmospheric boundary layers, as e.g. https://aip.scitation.org/doi/10.1063/1.4994603 Hope this helps, PHilipp On 2018-07-11 15:22, nek5000-users at lists.mcs.anl.gov wrote: > > Dear all, > > Can anybody tell me how to take into account the roughness of the pipe? > Do I have to change the geometry or there is something easier? > > Any help would be greatly appreciated, > > Ali > Embry-Riddle Aeronautical University > > > > > > _______________________________________________ > 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 Jul 12 03:25:09 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 10:25:09 +0200 Subject: [Nek5000-users] Number of Elements per Characteristic Length for DNS In-Reply-To: References: Message-ID: Hi, typically, in wall bounded turbulence you would design the mesh based on inner scaled quantities (i.e. based on the viscous length scale l*). This is what we have done in the paper by El Khoury, in accordance to studies in channel flow. TOwards the centre, one can then also use Kolmogorov units (not sure whether Taylor units are so useful). I am quite convinced that the El Khoury simulations are well-resolved DNS, which can also be seen when looking at spectra. Philipp On 2018-07-11 20:58, nek5000-users at lists.mcs.anl.gov wrote: > Hello All, > > I am currently investigating the turbulence in a pipe with periodic > boundary conditions. I am working on building my mesh and was planning > on using Re^(3/4) as the number of elements per characteristic length, > but I have found differing methods in literature detailing the number of > elements used for DNS. One paper in particular (G.K. El Khoury et al, > Direct Numerical Simulation of Turbulent Pipe Flow at Moderately High > Reynolds Numbers,? Flow Turbulence Combust, 2013) uses Nek5000 to > simulate turbulent flow in a pipe at different Reynolds numbers. The > number of elements calculated in this paper seem to be in between the > LES and DNS suggested number of elements (element size between the > Taylor microscale and the Kolmogorov scale). Turbulent Flows by Pope > however suggests a number of elements that is slightly larger than > Re^(3/4), and is dependent on the Taylor microscale Reynolds number. > > Any suggestions on the correct way to determine the number of spectral > elements in a characteristic length would be appreciated. > > Regards, > > Tommy > > > > _______________________________________________ > 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 Jul 12 03:33:44 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 10:33:44 +0200 (CEST) Subject: [Nek5000-users] BCs on moving bodies Message-ID: Hi Neks, I was doing an FSI problem on Naca0012. I had already validated an FSI problem on a cylinder. Here I confued a bit with BC's applied thourgh usr file. Here is an example of the BCs on the cylinder from your examples -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 12 03:35:30 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 16:35:30 +0800 Subject: [Nek5000-users] Extruding 2D .fld file to 3D In-Reply-To: References: Message-ID: Dear Ketan, Finally I rerun the 2D simulation with ascii field output from the beginning and found the reason why I failed: To ensure the subroutine works, one should pay attention to prepare the ascii fld files. It is safe if the 2D simulation dump *fld field at the beginning and take the last time slice to be used. But usually we run the 2D simulation with binary data output, so we can take one slice as restart file and dump out a fld data by setting param(66) =0 in *usr. But be careful not only run one step, at least two steps, and choose any one of 2D.fld02, or 2Dfld03,... as the base field. then run the 2dTo3Dextrude simulation, every thing will go happily. Again thanks your subroutine!! all the best, Wei On Wed, Jul 11, 2018 at 11:25 PM, wrote: > Hi Wei, > > Sure, send me your 2D fld file and rea file via email: k m i t t a l 2 at > i l l i n o i s . e d u > > Ketan > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Wei HE ?? School of Aeronautics Universidad Polit?cnica de Madrid http://www.cfm.upm.es/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 12 03:37:29 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 10:37:29 +0200 Subject: [Nek5000-users] Stream function In-Reply-To: <72604073-3f81-bd54-b576-b87613f0f133@mech.kth.se> References: <72604073-3f81-bd54-b576-b87613f0f133@mech.kth.se> Message-ID: Ok, so can you please just try the attached code in userchck? It should work (at least does for us) in 2D. Essentially, the steps are: 1. copmute z-vorticity in a new array vorticity 2. construct the rhs by multiplying with -bm1 3. setup the Helmholtz problem and tolerances 4. solve the Helmholtz problem and storing the results in a new array phi 5. write out everything in two files. In this code you do not use the temperature at all, which I guess is fine for a 2D case (which I guess is what you look at). best regards, Philipp On 2018-07-10 22:33, Philipp Schlatter wrote: > Dear Hannah, > sorry that I only see the post now. Are you still having problems with > the stream function, or does it work now? > Best regards, > Philipp > > On 2018-07-02 16:40, nek5000-users at lists.mcs.anl.gov wrote: >> Hi JC, >> >> Yes, the mv_wall example computes the streamfunction, but it applies >> tmask, tmult that I could not find where they are defined in the >> file.? I was experimenting with different masks. >> >> Do you know how postnek compute the streamfunction? >> >> I think it is computed in the subroutine strfct(psi) in postnek2.f, >> but I am not sure what happens in the routine? >> >> Thanks, >> >> Hannah >> ________________________________________ >> From: Nek5000-users [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, June 29, 2018 3:47 AM >> To: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] Stream function >> >> Hi Hannah, >> >> I tried to implement the streamfunction as well (for a 2D cylinder flow) >> and it would appear that, doing na?vely, the tmask is set to zero >> everywhere. Hence, when rhs * tmask is computed in the hmholtz >> subroutine, rhs is set to zero everywhere and it then makes sense that >> the returned streamfunction is zero everywhere as well. >> >> Not sure how to do fix this properly though. Any help would be >> appreciated indeed :) >> >> >> ++ >> JC >> >> >> On 06/28/2018 09:41 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> Hi Philipp, >>> >>> Thanks very much for your comments.? Yes, the delta* works only for >>> the parallel plate. >>> >>> The streamfunction computation with the Blasius example is still not >>> working. I suspect I am not using the correct mask (vmult /tmult, >>> imsh as well). >>> >>> Using the Blasius example, v1mask, vmult (imsh = 1), I dumped the >>> streamfuntion to the temperature field. However, it only contains >>> negative values and does not look physical (I pasted userchk below). >>> >>> Another Nek Example, ?mv_wall?, computes the streamfunction from the >>> Possison equation using vorticity. It uses tmask, tmult, and imsh = 2. >>> >>> I tried implementing what was done in the ?mv_wall? example in the >>> Blasius example, but the computed streamfunction is zero everywhere. >>> >>> Any ideas what I might be doing wrong? >>> >>> Any advice would be appreciated! >>> >>> Thanks again, >>> >>> Hannah >>> >>> c----------------------------------------------------------------------- >>> ??????? subroutine userchk >>> ??????? include 'SIZE' >>> ??????? include 'TOTAL' >>> >>> ??????? common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >>> >>> ??????? common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >>> ??????? common /blasiusg/ bin(lx1,ly1,lz1,lelv) >>> ??????? common /scrns/??? dum(lx1*ly1*lz1*lelv) >>> >>> ??????? common /xtream/ psi(lx1*ly1*lz1*lelt) >>> ?????? $????????????? , rhs(lx1*ly1*lz1*lelt) >>> ?????? $????????????? , h1 (lx1*ly1*lz1*lelt) >>> ?????? $????????????? , h2 (lx1*ly1*lz1*lelt) >>> >>> ??????? parameter (lt=lx1*ly1*lz1*lelt) >>> ??????? common /scrns/ vort(lt,3),w1(lt),w2(lt) >>> >>> ??????? integer bin >>> ??????? real normu(50),normv(50) >>> >>> ??????? real xmax,xmin,dx >>> ??????? save xmax,xmin,dx >>> >>> ??????? n = nx1*ny1*nz1*nelv >>> ??????? ifheat=.false. >>> ??????? call comp_vort3(vort , w1, w2, vx, vy, vz) >>> ??????? call copy (t,vort,n)?? ! Vorticity --> T >>> ??????? ifto = .true.????????? ! Dump vorticity as T >>> c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>> c???? Compute streamfunction from vorticity >>> ??????? call col3 (rhs,t,bm1,n) ! B*omega >>> ??????? call rone (h1,n) >>> ??????? call rzero(h2,n) >>> >>> ??????? ifield = 1 >>> ??????? tol??? = param(22) >>> ??????? imsh?? = 1 >>> ??????? call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh, >>> ?????? $??????? tol,200,1) >>> ??????? call copy (t,psi,n)??? ! Psi --> T (for output) >>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>> >>> ??????? nfldt = 1 + npscal >>> >>> ??????? if (istep.eq.0) call outpost2(vx,vy,vz,pr,t,nfldt,'?? ') >>> >>> ??????? do i=1,n >>> ?????????? dum(i) = 1.-vx(i,1,1,1) >>> ??????? enddo >>> ??????? tot_deficit = glsc2(dum,bm1,n) >>> ??????? xmin??????? = glmin(xm1,n) >>> ??????? xmax??????? = glmax(xm1,n) >>> ??????? delta_star? = tot_deficit/(xmax-xmin) >>> ??????? tmin??????? = glmin(t,n) >>> ??????? tmax??????? = glmax(t,n) >>> ??????? vortmin????? = glmin(vort,n) >>> ??????? vortmax????? = glmax(vort,n) >>> ??????? if (nid.eq.0) write(6,1) istep,time,delta_star,vortmin,vortmax >>> ??????? if (nid.eq.0) write(6,1) istep,tmin,tmax >>> ????? 1 format(i8,1p4e13.5,'? blasius: delta*') >>> >>> ??????? return >>> ??????? end >>> c----------------------------------------------------------------------- >>> >>> >>> ________________________________________ >>> From: Nek5000-users [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, June 26, 2018 1:22 PM >>> To: nek5000-users at lists.mcs.anl.gov >>> Subject: Re: [Nek5000-users] Stream function >>> >>> Hi, >>> To correctly compute the stream function, the rhs of the Poisson >>> equation needs to be the (negative) vorticity. Therefore, the line >>> >>> ????? call col2(rhs,bm1,n) >>> >>> is wrong, and should be something like >>> >>> ????? call col3(rhs, vorticity, bm1, n) >>> >>> where vorticity should be the computed vorticity using comp_vort. >>> >>> I guess your calculation of delta* only works for parallel boundary >>> layers. >>> >>> Philipp >>> >>> >>> >>> On 2018-06-26 18:35, nek5000-users at lists.mcs.anl.gov wrote: >>>> Hi Phillip, >>>> >>>> I am using the ?Blasius? example test outputting the streamfunction >>>> as a >>>> scalar. >>>> >>>> I included my code below. I am not sure what I am doing wrong. >>>> >>>> In userchk, I added ?compute streamfunction from vorticity? from the >>>> psi_omega example, but it does not compute the psi properly? (max_psi = >>>> min_psi = 0 in every step) >>>> >>>> c----------------------------------------------------------------------- >>>> >>>> >>>> ???????? subroutine userchk >>>> >>>> ???????? include 'SIZE' >>>> >>>> ???????? include 'TOTAL' >>>> >>>> ???????? common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >>>> >>>> ???????? common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >>>> >>>> ???????? common /blasiusg/ bin(lx1,ly1,lz1,lelv) >>>> >>>> ???????? common /scrns/??? dum(lx1*ly1*lz1*lelv) >>>> >>>> ???????? common /xtream/ psi(lx1*ly1*lz1*lelt) >>>> >>>> ??????? $????????????? , rhs(lx1*ly1*lz1*lelt) >>>> >>>> ??????? $????????????? , h1 (lx1*ly1*lz1*lelt) >>>> >>>> ??????? $????????????? , h2 (lx1*ly1*lz1*lelt) >>>> >>>> ???????? integer bin >>>> >>>> ???????? real normu(50),normv(50) >>>> >>>> ???????? real xmax,xmin,dx >>>> >>>> ???????? save xmax,xmin,dx >>>> >>>> ???????? n = nx1*ny1*nz1*nelv >>>> >>>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>>> >>>> c???? Compute streamfunction from vorticity >>>> >>>> ???????? call col2(rhs,bm1,n) >>>> >>>> ???????? call rone (h1 ,n) >>>> >>>> ???????? call rzero(h2 ,n) >>>> >>>> ???????? tol = param(22) >>>> >>>> ???????? imsh?? = 1 >>>> >>>> ???????? call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh,tol,200,1) >>>> >>>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>>> >>>> ???????? if (istep.eq.0) call outpost(vx,vy,vz,pr,psi,'?? ') >>>> >>>> c???? Compute delta* >>>> >>>> ???????? do i=1,n >>>> >>>> ??????????? dum(i) = 1.-vx(i,1,1,1) >>>> >>>> ???????? enddo >>>> >>>> ???????? tot_deficit = glsc2(dum,bm1,n) >>>> >>>> ???????? xmin??????? = glmin(xm1,n) >>>> >>>> ???????? xmax??????? = glmax(xm1,n) >>>> >>>> ???????? delta_star? = tot_deficit/(xmax-xmin) >>>> >>>> ???????? psimin????? = glmin(psi,n) >>>> >>>> ???????? psimax????? = glmax(psi,n) >>>> >>>> ???????? if (nid.eq.0) write(6,1) istep,time,delta_star,psimin,psimax >>>> >>>> ?????? 1 format(i8,1p4e13.5,'? blasius: delta*') >>>> >>>> ???????? return >>>> >>>> ???????? end >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> -------------- next part -------------- c----------------------------------------------------------------------- C C USER SPECIFIED ROUTINES: C C - boundary conditions C - initial conditions C - variable properties C - local acceleration for fluid (a) C - forcing function for passive scalar (q) C - general purpose routine for checking errors etc. C c----------------------------------------------------------------------- subroutine uservp (ix,iy,iz,eg) return end c----------------------------------------------------------------------- subroutine userf (ix,iy,iz,ieg) return end c----------------------------------------------------------------------- subroutine userq (ix,iy,iz,eg) return end c----------------------------------------------------------------------- subroutine userchk include 'SIZE' include 'INPUT' ! param include 'SOLN' ! vx, vy, vz, pr, t, v2mask, vmult include 'MASS' ! bm1 real dummy1(lx1,ly1,lz1,lelv) real dummy2(lx1,ly1,lz1,lelv) real vorticity(lx1,ly1,lz1,lelv) real phi(lx1,ly1,lz1,lelv) real h1(lx1,ly1,lz1,lelv) real h2(lx1,ly1,lz1,lelv) real rhs(lx1,ly1,lz1,lelv) integer n, maxit real toler, p22 n = nelv*lx1*ly1*lz1 c c Compute streamfunction phi for a 2D velocity field with c all Dirichlet boundary conditions (i.e. phi=0 along all boundaries) c c Solve the Poisson equation \/^2 phi = -w c with w the vorticity. c c initialize the vectors to zero call rzero(vorticity,n) c compute vorticity call comp_vort3(vorticity,dummy1,dummy2,vx,vy,vz) call chsign(vorticity,n) c multiply with the mass matrix call col3(rhs,vorticity,bm1,n) c setup Poisson problem: h2=0, h1=1 call rzero(h2,n) call rone(h1,n) c set solver tolerance toler = 1e-14 p22 = param(22) param(22) = toler maxit = 10000 c Solve Poisson equation: call hmholtz('PHI ',phi,rhs,h1,h2,v2mask,vmult,1, $ toler,maxit,1) c reset tolerance param(22) = p22 c output streamfunction phi call outpost(rhs,phi,vz,pr,t,'stf') c output normal velocity field call outpost(vx,vy,vz,pr,t,' ') call exitt() return end c----------------------------------------------------------------------- subroutine userbc (ix,iy,iz,iside,ieg) return end c----------------------------------------------------------------------- subroutine useric (ix,iy,iz,ieg) return end c----------------------------------------------------------------------- subroutine usrdat return end c----------------------------------------------------------------------- subroutine usrdat2 c return end c----------------------------------------------------------------------- subroutine usrdat3 c return end c----------------------------------------------------------------------- From nek5000-users at lists.mcs.anl.gov Thu Jul 12 04:00:43 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 11:00:43 +0200 (CEST) Subject: [Nek5000-users] BS's on moving domain problem Message-ID: Hi Neks, I was doing an FSI problem on Naca0012. I had already validated an FSI problem on a cylinder. Here I confued a bit with BC's applied thourgh usr file. Here is an example of the BCs on the cylinder from your examples c----------------------------------------------------------------------- subroutine userbc (ix,iy,iz,f,eg) include 'SIZE' include 'TOTAL' include 'NEKUSE' integer e,eg,f common /c_mybc/ umesh lx1,ly1,lz1,lelt) $ , umeshy(lx1,ly1,lz1,lelt) $ , umeshz(lx1,ly1,lz1,lelt) if (x .lt. -1.1) then ux=1 uy=0. uz=0. else e = gllel(eg) ux = umesh ix,iy,iz,e) uy = umeshy(ix,iy,iz,e) uz = umeshz(ix,iy,iz,e) endif return end c----------------------------------------------------------------------- My doubt is why there is an else condition in the BC's. Is it something related with the initial perturbation? When I apply this BC on NACA0012 I get some strange boundary layer flow. Could you please help me to solve this? Thank you have a nice day Sijo -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 12 06:18:24 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 13:18:24 +0200 Subject: [Nek5000-users] Problem in obtaining eigenvalues through Arnoldi (using NEK5000 with the ARPACK library) In-Reply-To: References: Message-ID: I believe this extension is not part of Nek5000. You may want to contact the author directly. Stefan On 12 Jul 2018, at 10:10, "nek5000-users at lists.mcs.anl.gov " > wrote: Hi Neks ??? I am running a 3D simulation for a flow over a cylinder. My domain size for simulation is 100Dx100D. where D is the diameter?of a cylinder. We have obtained the base flow through SFD. The base flow is used to calculate the stability analysis through NEK5000 with the ARPACK library?(Implemented by A.? Peplinski). we have used the following parameters..... ? 90.0000? ? ?p111 : ARNOLDI: size of Krylov space ? ?30.0000? ? ?p112 : ARNOLDI: number of eigenvectors We have run the Arnoldi with restart but we are not able to get the output file (eigenvalues.txt and?egvext_cyl0.f0..) even after almost 20 restarts. Also, we tried to run with increasing the?size of Krylov space but the eigenvalues are not converging. The log file shows no changes?in converged ritz values after around 20-22 values. The part of the log file is shown below........... Kindly,? help me out and let me know where I am going wrong..... Alok Mishra --------------------------------------------------------------------------------------------------------------- ARNOLDI: after? 520 stepper phase ?_naup2: Corresponding B-norm of the residual ?-------------------------------------------- ? ? 1 -? ? 1:? ?6.623D-01 ?? ?_naup2: no. of "converged" Ritz values at this iter. ?---------------------------------------------------- ? ? 1 -? ? 1:? ? 22 ?? ?_naup2: NEV and NP are ?---------------------- ? ? 1 -? ? 2:? ? 52? ?128 ?? ?_naup2: "wanted" Ritz values -- real part ?----------------------------------------- ? ? 1 -? ? 5:? ?9.905D-01? ?9.905D-01? ?9.854D-01? ?9.854D-01? ?9.855D-01 ? ? 6 -? ?10:? ?9.855D-01? ?9.897D-01? ?9.897D-01? ?9.924D-01? ?9.930D-01 ? ?11 -? ?15:? ?9.930D-01? ?9.905D-01? ?9.905D-01? ?9.943D-01? ?9.943D-01 ? ?16 -? ?20:? ?9.938D-01? ?9.938D-01? ?9.948D-01? ?9.948D-01? ?9.949D-01 ? ?21 -? ?25:? ?9.949D-01? ?9.951D-01? ?9.958D-01? ?9.960D-01? ?9.962D-01 ? ?26 -? ?30:? ?9.962D-01? ?9.966D-01? ?9.970D-01? ?9.970D-01? ?9.969D-01 ? ?31 -? ?35:? ?9.969D-01? ?9.973D-01? ?9.974D-01? ?9.975D-01? ?9.976D-01 ? ?36 -? ?40:? ?9.976D-01? ?9.971D-01? ?9.971D-01? ?9.978D-01? ?9.979D-01 ? ?41 -? ?45:? ?9.979D-01? ?9.982D-01? ?9.982D-01? ?1.000D+00? ?9.908D-01 ? ?46 -? ?50:? ?9.908D-01? ?1.004D+00? ?1.004D+00? ?1.005D+00? ?1.005D+00 ? ?51 -? ?52:? ?1.006D+00? ?1.006D+00 ?? ?_naup2: "wanted" Ritz values -- imag part ?----------------------------------------- ? ? 1 -? ? 5:? ?5.038D-02? -5.038D-02? -1.127D-01? ?1.127D-01? -1.119D-01 ? ? 6 -? ?10:? ?1.119D-01? ?6.954D-02? -6.954D-02? ?0.000D+00? ?3.705D-03 ? ?11 -? ?15:? -3.705D-03? -7.103D-02? ?7.103D-02? -9.233D-04? ?9.233D-04 ? ?16 -? ?20:? ?4.345D-02? -4.345D-02? ?6.799D-04? -6.799D-04? -1.821D-02 ? ?21 -? ?25:? ?1.821D-02? ?0.000D+00? ?0.000D+00? ?0.000D+00? -2.047D-03 ? ?26 -? ?30:? ?2.047D-03? ?0.000D+00? ?7.200D-05? -7.200D-05? ?2.386D-02 ? ?31 -? ?35:? -2.386D-02? ?0.000D+00? ?0.000D+00? ?0.000D+00? -1.140D-04 ? ?36 -? ?40:? ?1.140D-04? ?3.125D-02? -3.125D-02? ?0.000D+00? -1.248D-04 ? ?41 -? ?45:? ?1.248D-04? -1.673D-03? ?1.673D-03? ?0.000D+00? -1.508D-01 ? ?46 -? ?50:? ?1.508D-01? -1.863D-02? ?1.863D-02? -2.109D-02? ?2.109D-02 ? ?51 -? ?52:? -1.152D-02? ?1.152D-02 ?? ?_naup2: Ritz estimates of the "wanted" values? ?---------------------------------------------- ? ? 1 -? ? 5:? ?3.315D-02? ?3.315D-02? ?3.244D-05? ?3.244D-05? ?7.035D-05 ? ? 6 -? ?10:? ?7.035D-05? ?6.072D-11? ?6.072D-11? ?1.314D-02? ?2.772D-06 ? ?11 -? ?15:? ?2.772D-06? ?6.796D-15? ?6.796D-15? ?9.719D-04? ?9.719D-04 ? ?16 -? ?20:? ?7.467D-17? ?7.467D-17? ?5.506D-04? ?5.506D-04? ?2.437D-16 ? ?21 -? ?25:? ?2.437D-16? ?2.977D-03? ?7.238D-04? ?6.054D-04? ?3.914D-11 ? ?26 -? ?30:? ?3.914D-11? ?1.827D-04? ?1.138D-04? ?1.138D-04? ?1.048D-16 ? ?31 -? ?35:? ?1.048D-16? ?1.198D-04? ?6.358D-05? ?3.013D-05? ?3.490D-07 ? ?36 -? ?40:? ?3.490D-07? ?9.960D-18? ?9.960D-18? ?1.340D-07? ?2.518D-10 ? ?41 -? ?45:? ?2.518D-10? ?1.827D-16? ?1.827D-16? ?1.781D-16? ?7.278D-17 ? ?46 -? ?50:? ?7.278D-17? ?0.000D+00? ?0.000D+00? ?0.000D+00? ?0.000D+00 ? ?51 -? ?52:? ?0.000D+00? ?0.000D+00 ???Reached max iteration number; settingido=-2 for checkpointing. ?ARNOLDI:? ?IDOARP? =? ? ? ? ? ?-2 ?Writing checkpoint ? ? ? ?0? ? ? 40 OPEN: ARPm11800.f00002 ? ? ? ?0? ? ? 40 OPEN: ARVm11800.f00002 ? ? ? ?40? 2.0000E-01 done :: Write checkpoint ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? file size =? ? ?621.E+00MB ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? avg data-throughput =? ?624.1MB/s ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? io-nodes =? ? ?1 ??ARNOLDI: finalize ? ? Number of stepper cycles? ? ? ? ? ? 520 ? ? Time spent in ARNOLDI? ? ? ? ?60.3302609920502? ? ? ? ? Average stepper phase time? ? 10.9141681075096? ? ? ?call outfld: ifpsco: F ? ? ? ?40? 2.0000E-01 Write checkpoint: ? ? ? ?0? ? ? 40 OPEN: m11800.f00001 ? ? ? ?40? 2.0000E-01 done :: Write checkpoint ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? file size =? ? ? 4.0? ? MB ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? avg data-throughput =? ?303.2MB/s ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? io-nodes =? ? ?1 end of time-step loop ? _______________________________________________ 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 Jul 12 07:07:42 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 12:07:42 +0000 Subject: [Nek5000-users] array reshape Message-ID: Hi all, How can I reshape this array uvag(lx1,ly1,lz1,lelt) into abc(lx1*ly1*lz1,lelt)? The following array reshape which works for fortran didn't work: reshape(uavg, ( \ lx1*ly1*lz1 , lelt \ )) Any suggestions? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 12 07:13:18 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 14:13:18 +0200 Subject: [Nek5000-users] array reshape In-Reply-To: References: Message-ID: I dont think you need to do anything as the first index is the faster varying in Fortran. Philipp On 2018-07-12 14:07, nek5000-users at lists.mcs.anl.gov wrote: > Hi all, > > > How can I reshape this array?uvag(lx1,ly1,lz1,lelt) into > abc(lx1*ly1*lz1,lelt)? > > > > The following array reshape which works for fortran didn't work: > > > reshape(uavg, (? \ lx1*ly1*lz1?,?lelt?\?)) > > > > Any suggestions? > > > Thanks. > > > > _______________________________________________ > 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 Jul 12 07:56:18 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 08:56:18 -0400 Subject: [Nek5000-users] Number of Elements per Characteristic Length for DNS In-Reply-To: References: Message-ID: Hi Philipp, Thank you for getting back to me. Do you have any references that you could provide so that I can look into this further? Thanks, Tommy On Thu, Jul 12, 2018 at 4:25 AM, wrote: > Hi, > typically, in wall bounded turbulence you would design the mesh based on > inner scaled quantities (i.e. based on the viscous length scale l*). This > is what we have done in the paper by El Khoury, in accordance to studies in > channel flow. TOwards the centre, one can then also use Kolmogorov units > (not sure whether Taylor units are so useful). I am quite convinced that > the El Khoury simulations are well-resolved DNS, which can also be seen > when looking at spectra. > > Philipp > > > On 2018-07-11 20:58, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello All, >> >> I am currently investigating the turbulence in a pipe with periodic >> boundary conditions. I am working on building my mesh and was planning on >> using Re^(3/4) as the number of elements per characteristic length, but I >> have found differing methods in literature detailing the number of elements >> used for DNS. One paper in particular (G.K. El Khoury et al, Direct >> Numerical Simulation of Turbulent Pipe Flow at Moderately High Reynolds >> Numbers, Flow Turbulence Combust, 2013) uses Nek5000 to simulate turbulent >> flow in a pipe at different Reynolds numbers. The number of elements >> calculated in this paper seem to be in between the LES and DNS suggested >> number of elements (element size between the Taylor microscale and the >> Kolmogorov scale). Turbulent Flows by Pope however suggests a number of >> elements that is slightly larger than Re^(3/4), and is dependent on the >> Taylor microscale Reynolds number. >> >> Any suggestions on the correct way to determine the number of spectral >> elements in a characteristic length would be appreciated. >> >> Regards, >> >> Tommy >> >> >> >> _______________________________________________ >> 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 Jul 12 08:07:49 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 15:07:49 +0200 Subject: [Nek5000-users] Number of Elements per Characteristic Length for DNS In-Reply-To: References: Message-ID: I guess the El Khoury paper might be a good starting point; we really tried to make sure that the resolution is sufficient for good DNS. Otherwise, there is a resolution discussion for spectral methods in the paper by Coleman, Johnstone and Spalart: https://aip.scitation.org/doi/abs/10.1063/1.3247176 Philipp On 2018-07-12 14:56, nek5000-users at lists.mcs.anl.gov wrote: > Hi Philipp, > > Thank you for getting back to me. Do you have any references that you > could provide so that I can look into this further? > > Thanks, > > Tommy > > On Thu, Jul 12, 2018 at 4:25 AM, > wrote: > > Hi, > typically, in wall bounded turbulence you would design the mesh > based on inner scaled quantities (i.e. based on the viscous length > scale l*). This is what we have done in the paper by El Khoury, in > accordance to studies in channel flow. TOwards the centre, one can > then also use Kolmogorov units (not sure whether Taylor units are so > useful). I am quite convinced that the El Khoury simulations are > well-resolved DNS, which can also be seen when looking at spectra. > > Philipp > > > On 2018-07-11 20:58, nek5000-users at lists.mcs.anl.gov > wrote: > > Hello All, > > I am currently investigating the turbulence in a pipe with > periodic boundary conditions. I am working on building my mesh > and was planning on using Re^(3/4) as the number of elements per > characteristic length, but I have found differing methods in > literature detailing the number of elements used for DNS. One > paper in particular (G.K. El Khoury et al, Direct Numerical > Simulation of Turbulent Pipe Flow at Moderately High Reynolds > Numbers,? Flow Turbulence Combust, 2013) uses Nek5000 to > simulate turbulent flow in a pipe at different Reynolds numbers. > The number of elements calculated in this paper seem to be in > between the LES and DNS suggested number of elements (element > size between the Taylor microscale and the Kolmogorov scale). > Turbulent Flows by Pope however suggests a number of elements > that is slightly larger than Re^(3/4), and is dependent on the > Taylor microscale Reynolds number. > > Any suggestions on the correct way to determine the number of > spectral elements in a characteristic length would be appreciated. > > Regards, > > Tommy > > > > _______________________________________________ > 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 Jul 12 09:22:15 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 10:22:15 -0400 Subject: [Nek5000-users] Number of Elements per Characteristic Length for DNS In-Reply-To: References: Message-ID: Hello Philipp, Thanks again for getting back to me and for sending these references. Regards, Tommy On Thu, Jul 12, 2018 at 9:07 AM, wrote: > I guess the El Khoury paper might be a good starting point; we really > tried to make sure that the resolution is sufficient for good DNS. > Otherwise, there is a resolution discussion for spectral methods in the > paper by Coleman, Johnstone and Spalart: > > https://aip.scitation.org/doi/abs/10.1063/1.3247176 > > Philipp > > On 2018-07-12 14:56, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Philipp, >> >> Thank you for getting back to me. Do you have any references that you >> could provide so that I can look into this further? >> >> Thanks, >> >> Tommy >> >> On Thu, Jul 12, 2018 at 4:25 AM, > > wrote: >> >> Hi, >> typically, in wall bounded turbulence you would design the mesh >> based on inner scaled quantities (i.e. based on the viscous length >> scale l*). This is what we have done in the paper by El Khoury, in >> accordance to studies in channel flow. TOwards the centre, one can >> then also use Kolmogorov units (not sure whether Taylor units are so >> useful). I am quite convinced that the El Khoury simulations are >> well-resolved DNS, which can also be seen when looking at spectra. >> >> Philipp >> >> >> On 2018-07-11 20:58, nek5000-users at lists.mcs.anl.gov >> wrote: >> >> Hello All, >> >> I am currently investigating the turbulence in a pipe with >> periodic boundary conditions. I am working on building my mesh >> and was planning on using Re^(3/4) as the number of elements per >> characteristic length, but I have found differing methods in >> literature detailing the number of elements used for DNS. One >> paper in particular (G.K. El Khoury et al, Direct Numerical >> Simulation of Turbulent Pipe Flow at Moderately High Reynolds >> Numbers, Flow Turbulence Combust, 2013) uses Nek5000 to >> simulate turbulent flow in a pipe at different Reynolds numbers. >> The number of elements calculated in this paper seem to be in >> between the LES and DNS suggested number of elements (element >> size between the Taylor microscale and the Kolmogorov scale). >> Turbulent Flows by Pope however suggests a number of elements >> that is slightly larger than Re^(3/4), and is dependent on the >> Taylor microscale Reynolds number. >> >> Any suggestions on the correct way to determine the number of >> spectral elements in a characteristic length would be appreciated. >> >> Regards, >> >> Tommy >> >> >> >> _______________________________________________ >> 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 > s.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 Wed Jul 11 09:39:40 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 11 Jul 2018 14:39:40 +0000 Subject: [Nek5000-users] Getting an error when compiling makenek Message-ID: Dear Nek Users, I am trying to compile new Nek5000 on SuperMUC but getting an error when compiling makenek. A few initial lines of the error are: gfortran: unrecognized option '-cpp' Warning: genmap.f:57: Illegal preprocessor directive Warning: genmap.f:190: Illegal preprocessor directive Warning: genmap.f:356: Illegal preprocessor directive Warning: genmap.f:1349: Illegal preprocessor directive Warning: genmap.f:1491: Illegal preprocessor directive Warning: genmap.f:1648: Illegal preprocessor directive Warning: genmap.f:1949: Illegal preprocessor directive Warning: genmap.f:3064: Illegal preprocessor directive Warning: genmap.f:3101: Illegal preprocessor directive Warning: genmap.f:3158: Illegal preprocessor directive Warning: genmap.f:3921: Illegal preprocessor directive I am attaching the detailed error output with this mail. Could you please suggest a solution to this problem? I want to use both the svn and new version of the code. Thanks. With best regards, Ambrish ------------------------------------------------------ Ambrish Pandey Post Doctoral Researcher Institut f?r Thermo- und Fluiddynamik Technische Universit?t Ilmenau Ilmenau 98693 Germany Phone: +49 3677 69-2424 Emails: ambrish.pandey at tu-ilmenau.de ambrishiitk at gmail.com ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: error.txt URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 12 09:57:06 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 14:57:06 +0000 Subject: [Nek5000-users] array reshape In-Reply-To: References: Message-ID: Hi Philipp, If I have common /avg/ uvag(lx1,ly1,lz1,lelt) in one subroutine, then can I call all data stored in that array as common /avg/ uvag(lx1*ly1*lz1,lelt) in another subroutine? Will this subroutine be able to read the data stored in this (common /avg/ uvag(lx1*ly1*lz1,lelt) ) array? > On 12 Jul 2018, at 15:23, nek5000-users-request at lists.mcs.anl.gov wrote: > > 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. array reshape (nek5000-users at lists.mcs.anl.gov) > 2. Re: array reshape (nek5000-users at lists.mcs.anl.gov) > 3. Re: Number of Elements per Characteristic Length for DNS > (nek5000-users at lists.mcs.anl.gov) > 4. Re: Number of Elements per Characteristic Length for DNS > (nek5000-users at lists.mcs.anl.gov) > 5. Re: Number of Elements per Characteristic Length for DNS > (nek5000-users at lists.mcs.anl.gov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Jul 2018 12:07:42 +0000 > From: nek5000-users at lists.mcs.anl.gov > To: "nek5000-users at lists.mcs.anl.gov" > > Subject: [Nek5000-users] array reshape > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > > > How can I reshape this array uvag(lx1,ly1,lz1,lelt) into abc(lx1*ly1*lz1,lelt)? > > > > The following array reshape which works for fortran didn't work: > > > reshape(uavg, ( \ lx1*ly1*lz1 , lelt \ )) > > > > Any suggestions? > > > Thanks. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Thu, 12 Jul 2018 14:13:18 +0200 > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] array reshape > Message-ID: > > Content-Type: text/plain; charset=windows-1252; format=flowed > > I dont think you need to do anything as the first index is the faster > varying in Fortran. > Philipp > > On 2018-07-12 14:07, nek5000-users at lists.mcs.anl.gov wrote: >> Hi all, >> >> >> How can I reshape this array?uvag(lx1,ly1,lz1,lelt) into >> abc(lx1*ly1*lz1,lelt)? >> >> >> >> The following array reshape which works for fortran didn't work: >> >> >> reshape(uavg, (? \ lx1*ly1*lz1?,?lelt?\?)) >> >> >> >> Any suggestions? >> >> >> Thanks. >> >> >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > > > ------------------------------ > > Message: 3 > Date: Thu, 12 Jul 2018 08:56:18 -0400 > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Number of Elements per Characteristic > Length for DNS > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi Philipp, > > Thank you for getting back to me. Do you have any references that you could > provide so that I can look into this further? > > Thanks, > > Tommy > > On Thu, Jul 12, 2018 at 4:25 AM, wrote: > >> Hi, >> typically, in wall bounded turbulence you would design the mesh based on >> inner scaled quantities (i.e. based on the viscous length scale l*). This >> is what we have done in the paper by El Khoury, in accordance to studies in >> channel flow. TOwards the centre, one can then also use Kolmogorov units >> (not sure whether Taylor units are so useful). I am quite convinced that >> the El Khoury simulations are well-resolved DNS, which can also be seen >> when looking at spectra. >> >> Philipp >> >> >> On 2018-07-11 20:58, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello All, >>> >>> I am currently investigating the turbulence in a pipe with periodic >>> boundary conditions. I am working on building my mesh and was planning on >>> using Re^(3/4) as the number of elements per characteristic length, but I >>> have found differing methods in literature detailing the number of elements >>> used for DNS. One paper in particular (G.K. El Khoury et al, Direct >>> Numerical Simulation of Turbulent Pipe Flow at Moderately High Reynolds >>> Numbers, Flow Turbulence Combust, 2013) uses Nek5000 to simulate turbulent >>> flow in a pipe at different Reynolds numbers. The number of elements >>> calculated in this paper seem to be in between the LES and DNS suggested >>> number of elements (element size between the Taylor microscale and the >>> Kolmogorov scale). Turbulent Flows by Pope however suggests a number of >>> elements that is slightly larger than Re^(3/4), and is dependent on the >>> Taylor microscale Reynolds number. >>> >>> Any suggestions on the correct way to determine the number of spectral >>> elements in a characteristic length would be appreciated. >>> >>> Regards, >>> >>> Tommy >>> >>> >>> >>> _______________________________________________ >>> 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: > > ------------------------------ > > Message: 4 > Date: Thu, 12 Jul 2018 15:07:49 +0200 > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Number of Elements per Characteristic > Length for DNS > Message-ID: > > Content-Type: text/plain; charset=utf-8; format=flowed > > I guess the El Khoury paper might be a good starting point; we really > tried to make sure that the resolution is sufficient for good DNS. > Otherwise, there is a resolution discussion for spectral methods in the > paper by Coleman, Johnstone and Spalart: > > https://aip.scitation.org/doi/abs/10.1063/1.3247176 > > Philipp > > On 2018-07-12 14:56, nek5000-users at lists.mcs.anl.gov wrote: >> Hi Philipp, >> >> Thank you for getting back to me. Do you have any references that you >> could provide so that I can look into this further? >> >> Thanks, >> >> Tommy >> >> On Thu, Jul 12, 2018 at 4:25 AM, > > wrote: >> >> Hi, >> typically, in wall bounded turbulence you would design the mesh >> based on inner scaled quantities (i.e. based on the viscous length >> scale l*). This is what we have done in the paper by El Khoury, in >> accordance to studies in channel flow. TOwards the centre, one can >> then also use Kolmogorov units (not sure whether Taylor units are so >> useful). I am quite convinced that the El Khoury simulations are >> well-resolved DNS, which can also be seen when looking at spectra. >> >> Philipp >> >> >> On 2018-07-11 20:58, nek5000-users at lists.mcs.anl.gov >> wrote: >> >> Hello All, >> >> I am currently investigating the turbulence in a pipe with >> periodic boundary conditions. I am working on building my mesh >> and was planning on using Re^(3/4) as the number of elements per >> characteristic length, but I have found differing methods in >> literature detailing the number of elements used for DNS. One >> paper in particular (G.K. El Khoury et al, Direct Numerical >> Simulation of Turbulent Pipe Flow at Moderately High Reynolds >> Numbers,? Flow Turbulence Combust, 2013) uses Nek5000 to >> simulate turbulent flow in a pipe at different Reynolds numbers. >> The number of elements calculated in this paper seem to be in >> between the LES and DNS suggested number of elements (element >> size between the Taylor microscale and the Kolmogorov scale). >> Turbulent Flows by Pope however suggests a number of elements >> that is slightly larger than Re^(3/4), and is dependent on the >> Taylor microscale Reynolds number. >> >> Any suggestions on the correct way to determine the number of >> spectral elements in a characteristic length would be appreciated. >> >> Regards, >> >> Tommy >> >> >> >> _______________________________________________ >> 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 >> > > > ------------------------------ > > Message: 5 > Date: Thu, 12 Jul 2018 10:22:15 -0400 > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Number of Elements per Characteristic > Length for DNS > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hello Philipp, > > Thanks again for getting back to me and for sending these references. > > Regards, > > Tommy > > On Thu, Jul 12, 2018 at 9:07 AM, wrote: > >> I guess the El Khoury paper might be a good starting point; we really >> tried to make sure that the resolution is sufficient for good DNS. >> Otherwise, there is a resolution discussion for spectral methods in the >> paper by Coleman, Johnstone and Spalart: >> >> https://aip.scitation.org/doi/abs/10.1063/1.3247176 >> >> Philipp >> >> On 2018-07-12 14:56, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Philipp, >>> >>> Thank you for getting back to me. Do you have any references that you >>> could provide so that I can look into this further? >>> >>> Thanks, >>> >>> Tommy >>> >>> On Thu, Jul 12, 2018 at 4:25 AM, >> > wrote: >>> >>> Hi, >>> typically, in wall bounded turbulence you would design the mesh >>> based on inner scaled quantities (i.e. based on the viscous length >>> scale l*). This is what we have done in the paper by El Khoury, in >>> accordance to studies in channel flow. TOwards the centre, one can >>> then also use Kolmogorov units (not sure whether Taylor units are so >>> useful). I am quite convinced that the El Khoury simulations are >>> well-resolved DNS, which can also be seen when looking at spectra. >>> >>> Philipp >>> >>> >>> On 2018-07-11 20:58, nek5000-users at lists.mcs.anl.gov >>> wrote: >>> >>> Hello All, >>> >>> I am currently investigating the turbulence in a pipe with >>> periodic boundary conditions. I am working on building my mesh >>> and was planning on using Re^(3/4) as the number of elements per >>> characteristic length, but I have found differing methods in >>> literature detailing the number of elements used for DNS. One >>> paper in particular (G.K. El Khoury et al, Direct Numerical >>> Simulation of Turbulent Pipe Flow at Moderately High Reynolds >>> Numbers, Flow Turbulence Combust, 2013) uses Nek5000 to >>> simulate turbulent flow in a pipe at different Reynolds numbers. >>> The number of elements calculated in this paper seem to be in >>> between the LES and DNS suggested number of elements (element >>> size between the Taylor microscale and the Kolmogorov scale). >>> Turbulent Flows by Pope however suggests a number of elements >>> that is slightly larger than Re^(3/4), and is dependent on the >>> Taylor microscale Reynolds number. >>> >>> Any suggestions on the correct way to determine the number of >>> spectral elements in a characteristic length would be appreciated. >>> >>> Regards, >>> >>> Tommy >>> >>> >>> >>> _______________________________________________ >>> 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 >> s.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: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 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 113, Issue 11 > ********************************************** From nek5000-users at lists.mcs.anl.gov Thu Jul 12 10:06:18 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 17:06:18 +0200 Subject: [Nek5000-users] array reshape In-Reply-To: References: Message-ID: yes, this is the beauty (or ugliness) of Fortran 77. The same holds for arrays passed in the argument list, for instance. In fact, you could simply just increase the first index beyond lx1 even having your first definition. Philipp On 2018-07-12 16:57, nek5000-users at lists.mcs.anl.gov wrote: > Hi Philipp, > > If I have > > common /avg/ uvag(lx1,ly1,lz1,lelt) > > > in one subroutine, then can I call all data stored in that array as > > > common /avg/ uvag(lx1*ly1*lz1,lelt) > > > in another subroutine? Will this subroutine be able to read the data stored in this > > (common /avg/ uvag(lx1*ly1*lz1,lelt) ) array? > > > >> On 12 Jul 2018, at 15:23, nek5000-users-request at lists.mcs.anl.gov wrote: >> >> 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. array reshape (nek5000-users at lists.mcs.anl.gov) >> 2. Re: array reshape (nek5000-users at lists.mcs.anl.gov) >> 3. Re: Number of Elements per Characteristic Length for DNS >> (nek5000-users at lists.mcs.anl.gov) >> 4. Re: Number of Elements per Characteristic Length for DNS >> (nek5000-users at lists.mcs.anl.gov) >> 5. Re: Number of Elements per Characteristic Length for DNS >> (nek5000-users at lists.mcs.anl.gov) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 12 Jul 2018 12:07:42 +0000 >> From: nek5000-users at lists.mcs.anl.gov >> To: "nek5000-users at lists.mcs.anl.gov" >> >> Subject: [Nek5000-users] array reshape >> Message-ID: >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Hi all, >> >> >> How can I reshape this array uvag(lx1,ly1,lz1,lelt) into abc(lx1*ly1*lz1,lelt)? >> >> >> >> The following array reshape which works for fortran didn't work: >> >> >> reshape(uavg, ( \ lx1*ly1*lz1 , lelt \ )) >> >> >> >> Any suggestions? >> >> >> Thanks. >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 12 Jul 2018 14:13:18 +0200 >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] array reshape >> Message-ID: >> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> I dont think you need to do anything as the first index is the faster >> varying in Fortran. >> Philipp >> >> On 2018-07-12 14:07, nek5000-users at lists.mcs.anl.gov wrote: >>> Hi all, >>> >>> >>> How can I reshape this array?uvag(lx1,ly1,lz1,lelt) into >>> abc(lx1*ly1*lz1,lelt)? >>> >>> >>> >>> The following array reshape which works for fortran didn't work: >>> >>> >>> reshape(uavg, (? \ lx1*ly1*lz1?,?lelt?\?)) >>> >>> >>> >>> Any suggestions? >>> >>> >>> Thanks. >>> >>> >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Thu, 12 Jul 2018 08:56:18 -0400 >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] Number of Elements per Characteristic >> Length for DNS >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Philipp, >> >> Thank you for getting back to me. Do you have any references that you could >> provide so that I can look into this further? >> >> Thanks, >> >> Tommy >> >> On Thu, Jul 12, 2018 at 4:25 AM, wrote: >> >>> Hi, >>> typically, in wall bounded turbulence you would design the mesh based on >>> inner scaled quantities (i.e. based on the viscous length scale l*). This >>> is what we have done in the paper by El Khoury, in accordance to studies in >>> channel flow. TOwards the centre, one can then also use Kolmogorov units >>> (not sure whether Taylor units are so useful). I am quite convinced that >>> the El Khoury simulations are well-resolved DNS, which can also be seen >>> when looking at spectra. >>> >>> Philipp >>> >>> >>> On 2018-07-11 20:58, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hello All, >>>> >>>> I am currently investigating the turbulence in a pipe with periodic >>>> boundary conditions. I am working on building my mesh and was planning on >>>> using Re^(3/4) as the number of elements per characteristic length, but I >>>> have found differing methods in literature detailing the number of elements >>>> used for DNS. One paper in particular (G.K. El Khoury et al, Direct >>>> Numerical Simulation of Turbulent Pipe Flow at Moderately High Reynolds >>>> Numbers, Flow Turbulence Combust, 2013) uses Nek5000 to simulate turbulent >>>> flow in a pipe at different Reynolds numbers. The number of elements >>>> calculated in this paper seem to be in between the LES and DNS suggested >>>> number of elements (element size between the Taylor microscale and the >>>> Kolmogorov scale). Turbulent Flows by Pope however suggests a number of >>>> elements that is slightly larger than Re^(3/4), and is dependent on the >>>> Taylor microscale Reynolds number. >>>> >>>> Any suggestions on the correct way to determine the number of spectral >>>> elements in a characteristic length would be appreciated. >>>> >>>> Regards, >>>> >>>> Tommy >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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: >> >> ------------------------------ >> >> Message: 4 >> Date: Thu, 12 Jul 2018 15:07:49 +0200 >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] Number of Elements per Characteristic >> Length for DNS >> Message-ID: >> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> I guess the El Khoury paper might be a good starting point; we really >> tried to make sure that the resolution is sufficient for good DNS. >> Otherwise, there is a resolution discussion for spectral methods in the >> paper by Coleman, Johnstone and Spalart: >> >> https://aip.scitation.org/doi/abs/10.1063/1.3247176 >> >> Philipp >> >> On 2018-07-12 14:56, nek5000-users at lists.mcs.anl.gov wrote: >>> Hi Philipp, >>> >>> Thank you for getting back to me. Do you have any references that you >>> could provide so that I can look into this further? >>> >>> Thanks, >>> >>> Tommy >>> >>> On Thu, Jul 12, 2018 at 4:25 AM, >> > wrote: >>> >>> Hi, >>> typically, in wall bounded turbulence you would design the mesh >>> based on inner scaled quantities (i.e. based on the viscous length >>> scale l*). This is what we have done in the paper by El Khoury, in >>> accordance to studies in channel flow. TOwards the centre, one can >>> then also use Kolmogorov units (not sure whether Taylor units are so >>> useful). I am quite convinced that the El Khoury simulations are >>> well-resolved DNS, which can also be seen when looking at spectra. >>> >>> Philipp >>> >>> >>> On 2018-07-11 20:58, nek5000-users at lists.mcs.anl.gov >>> wrote: >>> >>> Hello All, >>> >>> I am currently investigating the turbulence in a pipe with >>> periodic boundary conditions. I am working on building my mesh >>> and was planning on using Re^(3/4) as the number of elements per >>> characteristic length, but I have found differing methods in >>> literature detailing the number of elements used for DNS. One >>> paper in particular (G.K. El Khoury et al, Direct Numerical >>> Simulation of Turbulent Pipe Flow at Moderately High Reynolds >>> Numbers,? Flow Turbulence Combust, 2013) uses Nek5000 to >>> simulate turbulent flow in a pipe at different Reynolds numbers. >>> The number of elements calculated in this paper seem to be in >>> between the LES and DNS suggested number of elements (element >>> size between the Taylor microscale and the Kolmogorov scale). >>> Turbulent Flows by Pope however suggests a number of elements >>> that is slightly larger than Re^(3/4), and is dependent on the >>> Taylor microscale Reynolds number. >>> >>> Any suggestions on the correct way to determine the number of >>> spectral elements in a characteristic length would be appreciated. >>> >>> Regards, >>> >>> Tommy >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Thu, 12 Jul 2018 10:22:15 -0400 >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] Number of Elements per Characteristic >> Length for DNS >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> Hello Philipp, >> >> Thanks again for getting back to me and for sending these references. >> >> Regards, >> >> Tommy >> >> On Thu, Jul 12, 2018 at 9:07 AM, wrote: >> >>> I guess the El Khoury paper might be a good starting point; we really >>> tried to make sure that the resolution is sufficient for good DNS. >>> Otherwise, there is a resolution discussion for spectral methods in the >>> paper by Coleman, Johnstone and Spalart: >>> >>> https://aip.scitation.org/doi/abs/10.1063/1.3247176 >>> >>> Philipp >>> >>> On 2018-07-12 14:56, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi Philipp, >>>> >>>> Thank you for getting back to me. Do you have any references that you >>>> could provide so that I can look into this further? >>>> >>>> Thanks, >>>> >>>> Tommy >>>> >>>> On Thu, Jul 12, 2018 at 4:25 AM, >>> > wrote: >>>> >>>> Hi, >>>> typically, in wall bounded turbulence you would design the mesh >>>> based on inner scaled quantities (i.e. based on the viscous length >>>> scale l*). This is what we have done in the paper by El Khoury, in >>>> accordance to studies in channel flow. TOwards the centre, one can >>>> then also use Kolmogorov units (not sure whether Taylor units are so >>>> useful). I am quite convinced that the El Khoury simulations are >>>> well-resolved DNS, which can also be seen when looking at spectra. >>>> >>>> Philipp >>>> >>>> >>>> On 2018-07-11 20:58, nek5000-users at lists.mcs.anl.gov >>>> wrote: >>>> >>>> Hello All, >>>> >>>> I am currently investigating the turbulence in a pipe with >>>> periodic boundary conditions. I am working on building my mesh >>>> and was planning on using Re^(3/4) as the number of elements per >>>> characteristic length, but I have found differing methods in >>>> literature detailing the number of elements used for DNS. One >>>> paper in particular (G.K. El Khoury et al, Direct Numerical >>>> Simulation of Turbulent Pipe Flow at Moderately High Reynolds >>>> Numbers, Flow Turbulence Combust, 2013) uses Nek5000 to >>>> simulate turbulent flow in a pipe at different Reynolds numbers. >>>> The number of elements calculated in this paper seem to be in >>>> between the LES and DNS suggested number of elements (element >>>> size between the Taylor microscale and the Kolmogorov scale). >>>> Turbulent Flows by Pope however suggests a number of elements >>>> that is slightly larger than Re^(3/4), and is dependent on the >>>> Taylor microscale Reynolds number. >>>> >>>> Any suggestions on the correct way to determine the number of >>>> spectral elements in a characteristic length would be appreciated. >>>> >>>> Regards, >>>> >>>> Tommy >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> s.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: >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> 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 113, Issue 11 >> ********************************************** > > _______________________________________________ > 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 Jul 12 10:22:30 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 17:22:30 +0200 Subject: [Nek5000-users] Getting an error when compiling makenek In-Reply-To: References: Message-ID: What version of gfortran is this? On 12 Jul 2018, at 16:47, "nek5000-users at lists.mcs.anl.gov " > wrote: Dear Nek Users, I am trying to compile new Nek5000 on SuperMUC but getting an error when compiling makenek. A few initial lines of the error are: gfortran: unrecognized option '-cpp' Warning: genmap.f:57: Illegal preprocessor directive Warning: genmap.f:190: Illegal preprocessor directive Warning: genmap.f:356: Illegal preprocessor directive Warning: genmap.f:1349: Illegal preprocessor directive Warning: genmap.f:1491: Illegal preprocessor directive Warning: genmap.f:1648: Illegal preprocessor directive Warning: genmap.f:1949: Illegal preprocessor directive Warning: genmap.f:3064: Illegal preprocessor directive Warning: genmap.f:3101: Illegal preprocessor directive Warning: genmap.f:3158: Illegal preprocessor directive Warning: genmap.f:3921: Illegal preprocessor directive I am attaching the detailed error output with this mail. Could you please suggest a solution to this problem? I want to use both the svn and new version of the code. Thanks. With best regards, Ambrish ------------------------------------------------------ Ambrish Pandey Post Doctoral Researcher Institut f?r Thermo- und Fluiddynamik Technische Universit?t Ilmenau Ilmenau 98693 Germany Phone: +49 3677 69-2424 Emails: ambrish.pandey at tu-ilmenau.de ambrishiitk at gmail.com ------------------------------------------------------ _______________________________________________ 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 Jul 12 11:11:05 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 18:11:05 +0200 Subject: [Nek5000-users] Problem in obtaining eigenvalues through Arnoldi (using NEK5000 with the ARPACK library) In-Reply-To: References: Message-ID: Hi; What is your tolerance for eigenvalue convergence? I'm unable to answer your question directly, as there can be number of problems. One of the obvious ones could be mesh resolution. You have pretty big mesh. What is the resolution in cylinder vicinity? What is the polynomial order? You have number of eigenvalues converged to machine accuracy and a few of the order 10**-4 in between. Those could be some spurious modes related to insufficient resolution. What is your Reynolds number? Regards Adam On 12/07/18 10:07, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks > > I am running a 3D simulation for a flow over a cylinder. My domain > size for simulation is 100Dx100D. where D is the diameter?of a > cylinder. We have obtained the base flow through SFD. The base flow is > used to calculate the stability analysis through NEK5000 with the > ARPACK library?(Implemented by A. Peplinski). > > we have used the following parameters..... > > ? 90.0000? ? ?p111 : ARNOLDI: size of Krylov space > ? ?30.0000? ? ?p112 : ARNOLDI: number of eigenvectors > > We have run the Arnoldi with restart but we are not able to get the > output file (eigenvalues.txt and?egvext_cyl0.f0..) even after almost > 20 restarts. > Also, we tried to run with increasing the size of Krylov space but the > eigenvalues are not converging. > > The log file shows no changes?in converged ritz values after around > 20-22 values. > > The part of the log file is shown below........... > > Kindly,? help me out and let me know where I am going wrong..... > > Alok Mishra > > > > --------------------------------------------------------------------------------------------------------------- > > ARNOLDI: after? 520 stepper phase > > ?_naup2: Corresponding B-norm of the residual > ?-------------------------------------------- > ? ? 1 -? ? 1: ?6.623D-01 > > ?_naup2: no. of "converged" Ritz values at this iter. > ?---------------------------------------------------- > ? ? 1 -? ? 1:? ? 22 > > ?_naup2: NEV and NP are > ?---------------------- > ? ? 1 -? ? 2:? ? 52 ?128 > > ?_naup2: "wanted" Ritz values -- real part > ?----------------------------------------- > ? ? 1 -? ? 5: ?9.905D-01? ?9.905D-01? ?9.854D-01? ?9.854D-01 ?9.855D-01 > ? ? 6 -? ?10: ?9.855D-01? ?9.897D-01? ?9.897D-01? ?9.924D-01 ?9.930D-01 > ? ?11 -? ?15: ?9.930D-01? ?9.905D-01? ?9.905D-01? ?9.943D-01 ?9.943D-01 > ? ?16 -? ?20: ?9.938D-01? ?9.938D-01? ?9.948D-01? ?9.948D-01 ?9.949D-01 > ? ?21 -? ?25: ?9.949D-01? ?9.951D-01? ?9.958D-01? ?9.960D-01 ?9.962D-01 > ? ?26 -? ?30: ?9.962D-01? ?9.966D-01? ?9.970D-01? ?9.970D-01 ?9.969D-01 > ? ?31 -? ?35: ?9.969D-01? ?9.973D-01? ?9.974D-01? ?9.975D-01 ?9.976D-01 > ? ?36 -? ?40: ?9.976D-01? ?9.971D-01? ?9.971D-01? ?9.978D-01 ?9.979D-01 > ? ?41 -? ?45: ?9.979D-01? ?9.982D-01? ?9.982D-01? ?1.000D+00 ?9.908D-01 > ? ?46 -? ?50: ?9.908D-01? ?1.004D+00? ?1.004D+00? ?1.005D+00 ?1.005D+00 > ? ?51 -? ?52: ?1.006D+00? ?1.006D+00 > > ?_naup2: "wanted" Ritz values -- imag part > ?----------------------------------------- > ? ? 1 -? ? 5: ?5.038D-02? -5.038D-02? -1.127D-01? ?1.127D-01 -1.119D-01 > ? ? 6 -? ?10: ?1.119D-01? ?6.954D-02? -6.954D-02? ?0.000D+00 ?3.705D-03 > ? ?11 -? ?15: -3.705D-03? -7.103D-02? ?7.103D-02? -9.233D-04 ?9.233D-04 > ? ?16 -? ?20: ?4.345D-02? -4.345D-02? ?6.799D-04? -6.799D-04 -1.821D-02 > ? ?21 -? ?25: ?1.821D-02? ?0.000D+00? ?0.000D+00? ?0.000D+00 -2.047D-03 > ? ?26 -? ?30: ?2.047D-03? ?0.000D+00? ?7.200D-05? -7.200D-05 ?2.386D-02 > ? ?31 -? ?35: -2.386D-02? ?0.000D+00? ?0.000D+00? ?0.000D+00 -1.140D-04 > ? ?36 -? ?40: ?1.140D-04? ?3.125D-02? -3.125D-02? ?0.000D+00 -1.248D-04 > ? ?41 -? ?45: ?1.248D-04? -1.673D-03? ?1.673D-03? ?0.000D+00 -1.508D-01 > ? ?46 -? ?50: ?1.508D-01? -1.863D-02? ?1.863D-02? -2.109D-02 ?2.109D-02 > ? ?51 -? ?52: -1.152D-02? ?1.152D-02 > > ?_naup2: Ritz estimates of the "wanted" values > ?---------------------------------------------- > ? ? 1 -? ? 5: ?3.315D-02? ?3.315D-02? ?3.244D-05? ?3.244D-05 ?7.035D-05 > ? ? 6 -? ?10: ?7.035D-05? ?6.072D-11? ?6.072D-11? ?1.314D-02 ?2.772D-06 > ? ?11 -? ?15: ?2.772D-06? ?6.796D-15? ?6.796D-15? ?9.719D-04 ?9.719D-04 > ? ?16 -? ?20: ?7.467D-17? ?7.467D-17? ?5.506D-04? ?5.506D-04 ?2.437D-16 > ? ?21 -? ?25: ?2.437D-16? ?2.977D-03? ?7.238D-04? ?6.054D-04 ?3.914D-11 > ? ?26 -? ?30: ?3.914D-11? ?1.827D-04? ?1.138D-04? ?1.138D-04 ?1.048D-16 > ? ?31 -? ?35: ?1.048D-16? ?1.198D-04? ?6.358D-05? ?3.013D-05 ?3.490D-07 > ? ?36 -? ?40: ?3.490D-07? ?9.960D-18? ?9.960D-18? ?1.340D-07 ?2.518D-10 > ? ?41 -? ?45: ?2.518D-10? ?1.827D-16? ?1.827D-16? ?1.781D-16 ?7.278D-17 > ? ?46 -? ?50: ?7.278D-17? ?0.000D+00? ?0.000D+00? ?0.000D+00 ?0.000D+00 > ? ?51 -? ?52: ?0.000D+00? ?0.000D+00 > ?Reached max iteration number; settingido=-2 for checkpointing. > ?ARNOLDI: > ?IDOARP? =? ? ? ? ? ?-2 > ?Writing checkpoint > ? ? ? ?0? ? ? 40 OPEN: ARPm11800.f00002 > ? ? ? ?0? ? ? 40 OPEN: ARVm11800.f00002 > > ? ? ? ?40? 2.0000E-01 done :: Write checkpoint > ? ? ? file size =? ? ?621.E+00MB > ? ? ? avg data-throughput =? ?624.1MB/s > ? ? ? io-nodes =? ? ?1 > > ?ARNOLDI: finalize > ? ? Number of stepper cycles? ? ? ? ? ? 520 > ? ? Time spent in ARNOLDI? ? ? ? ?60.3302609920502 > ? ? Average stepper phase time? ? 10.9141681075096 > ?call outfld: ifpsco: F > > ? ? ? ?40? 2.0000E-01 Write checkpoint: > ? ? ? ?0? ? ? 40 OPEN: m11800.f00001 > > ? ? ? ?40? 2.0000E-01 done :: Write checkpoint > ? ? ? file size =? ? ? 4.0? ? MB > ? ? ? avg data-throughput =? ?303.2MB/s > ? ? ? io-nodes =? ? ?1 > > > end of time-step loop > > > > > > _______________________________________________ > 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 Jul 12 13:47:10 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 12 Jul 2018 18:47:10 +0000 Subject: [Nek5000-users] Stream function In-Reply-To: References: <72604073-3f81-bd54-b576-b87613f0f133@mech.kth.se>, Message-ID: Hi Philipp, Thanks very much for the userchk routine. I have been testing this with the Blasius example in Nek. I am hoping to implement this with my geometry (a 2-D backward facing step with the Blasius profile at the inlet upstream from the step). For the Blasius example in Nek, I used VisIt and checked rhs and psi from the stfc0.f* file, but psi does not look physical. 1. What is the purpose of using v2mask? I wonder whether I should specify a different mask... 2. Including declarations from 'INPUT', 'SOLN', and 'MASS' produced a long list of errors (please see below). To run the code, I commented three lines related to including 'INPUT', 'SOLN', and 'MASS'so that these are not included, but I wonder whether that would create problems? Any advice would be appreciated. Thanks very much. Hannah INPUT:14:16: Error: Symbol ?param? at (1) already has basic type of REAL INPUT:22:27: Error: Symbol ?param? at (1) is already in a COMMON block INPUT:25:20: Error: Symbol ?matype? at (1) already has basic type of INTEGER INPUT:30:28: Error: Symbol ?matype? at (1) is already in a COMMON block INPUT:34:26: Error: Symbol ?if3d? at (1) already has basic type of LOGICAL INPUT:50:26: Error: Symbol ?if3d? at (1) is already in a COMMON block INPUT:66:27: Error: Symbol ?ifnav? at (1) already has basic type of LOGICAL INPUT:69:27: Error: Symbol ?hcode? at (1) already has basic type of CHARACTER INPUT:70:27: Error: Symbol ?ocode? at (1) already has basic type of CHARACTER INPUT:71:27: Error: Symbol ?drivc? at (1) already has basic type of CHARACTER INPUT:72:26: Error: Symbol ?rstv? at (1) already has basic type of CHARACTER INPUT:73:28: Error: Symbol ?textsw? at (1) already has basic type of CHARACTER INPUT:74:27: Error: Symbol ?initc? at (1) already has basic type of CHARACTER INPUT:75:27: Error: Symbol ?hcode? at (1) is already in a COMMON block INPUT:77:29: Error: Symbol ?turbmod? at (1) already has basic type of CHARACTER INPUT:80:28: Error: Symbol ?reafle? at (1) already has basic type of CHARACTER INPUT:81:28: Error: Symbol ?reafle? at (1) is already in a COMMON block INPUT:83:29: Error: Symbol ?session? at (1) already has basic type of CHARACTER INPUT:84:29: Error: Symbol ?session? at (1) is already in a COMMON block INPUT:86:20: Error: Symbol ?cr_re2? at (1) already has basic type of INTEGER INPUT:87:33: Error: Symbol ?cr_re2? at (1) is already in a COMMON block INPUT:89:24: Error: Symbol ?re2off_b? at (1) already has basic type of INTEGER INPUT:90:31: Error: Symbol ?re2off_b? at (1) is already in a COMMON block INPUT:94:13: Error: Symbol ?xc? at (1) already has basic type of REAL INPUT:98:24: Error: Symbol ?xc? at (1) is already in a COMMON block INPUT:100:20: Error: Symbol ?igroup? at (1) already has basic type of INTEGER INPUT:101:28: Error: Symbol ?igroup? at (1) is already in a COMMON block INPUT:103:28: Error: Symbol ?ccurve? at (1) already has basic type of CHARACTER INPUT:104:25: Error: Symbol ?cbc? at (1) already has basic type of CHARACTER INPUT:105:25: Error: Symbol ?cbc? at (1) is already in a COMMON block INPUT:107:19: Error: Symbol ?ieact? at (1) already has basic type of INTEGER INPUT:108:27: Error: Symbol ?ieact? at (1) is already in a COMMON block INPUT:112:20: Error: Symbol ?numsts? at (1) already has basic type of INTEGER INPUT:113:26: Error: PARAMETER attribute of ?numsts? conflicts with PARAMETER attribute at (1) INPUT:115:20: Error: Symbol ?numflu? at (1) already has basic type of INTEGER INPUT:118:29: Error: Symbol ?numflu? at (1) is already in a COMMON block INPUT:121:17: Error: Symbol ?bcf? at (1) already has basic type of INTEGER INPUT:122:26: Error: Symbol ?bcf? at (1) is already in a COMMON block INPUT:124:24: Error: Symbol ?bctyps? at (1) already has basic type of CHARACTER INPUT:125:29: Error: Symbol ?bctyps? at (1) is already in a COMMON block SOLN:4:18: Error: Symbol ?lvt1? at (1) already has basic type of INTEGER SOLN:5:41: Error: PARAMETER attribute of ?lvt1? conflicts with PARAMETER attribute at (1) SOLN:6:41: Error: PARAMETER attribute of ?lvt2? conflicts with PARAMETER attribute at (1) SOLN:7:45: Error: PARAMETER attribute of ?lbt1? conflicts with PARAMETER attribute at (1) SOLN:8:45: Error: PARAMETER attribute of ?lbt2? conflicts with PARAMETER attribute at (1) SOLN:10:42: Error: PARAMETER attribute of ?lorder2? conflicts with PARAMETER attribute at (1) SOLN:14:13: Error: Symbol ?bq? at (1) already has basic type of REAL SOLN:15:22: Error: Symbol ?bq? at (1) is already in a COMMON block SOLN:18:16: Error: Symbol ?vxlag? at (1) already has basic type of REAL SOLN:33:13: Error: Symbol ?vx? at (1) already has basic type of REAL SOLN:52:27: Error: Symbol ?vxlag? at (1) is already in a COMMON block SOLN:59:13: Error: Symbol ?bx? at (1) already has basic type of REAL SOLN:78:13: Error: Symbol ?bx? at (1) is already in a COMMON block SOLN:82:18: Error: Symbol ?nu_star? at (1) already has basic type of REAL SOLN:83:29: Error: Symbol ?nu_star? at (1) is already in a COMMON block SOLN:85:13: Error: Symbol ?pr? at (1) already has basic type of REAL SOLN:86:22: Error: Symbol ?pr? at (1) is already in a COMMON block SOLN:88:14: Error: Symbol ?qtl? at (1) already has basic type of REAL SOLN:89:25: Error: Symbol ?qtl? at (1) is already in a COMMON block SOLN:91:15: Error: Symbol ?p0th? at (1) already has basic type of REAL SOLN:92:27: Error: Symbol ?p0th? at (1) is already in a COMMON block SOLN:94:18: Error: Symbol ?v1mask? at (1) already has basic type of REAL SOLN:106:28: Error: Symbol ?v1mask? at (1) is already in a COMMON block SOLN:111:15: Error: Symbol ?vxp? at (1) already has basic type of REAL SOLN:133:25: Error: Symbol ?vxp? at (1) is already in a COMMON block SOLN:138:16: Error: Symbol ?jp? at (1) already has basic type of INTEGER SOLN:139:25: Error: Symbol ?jp? at (1) is already in a COMMON block MASS:4:14: Error: Symbol ?bm1? at (1) already has basic type of REAL MASS:11:23: Error: Symbol ?bm1? at (1) is already in a COMMON block /home/Hannah/NekExamples/blasius/c3.f:360:25: call compute_f (f1,w ,t ) 1 Warning: Actual argument contains too few elements for dummy argument ?w? (1/4) at (1) makefile:119: recipe for target 'nek5000' failed make: *** [nek5000] Error 1 ________________________________________ From: Nek5000-users [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, July 12, 2018 3:37 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Stream function Ok, so can you please just try the attached code in userchck? It should work (at least does for us) in 2D. Essentially, the steps are: 1. copmute z-vorticity in a new array vorticity 2. construct the rhs by multiplying with -bm1 3. setup the Helmholtz problem and tolerances 4. solve the Helmholtz problem and storing the results in a new array phi 5. write out everything in two files. In this code you do not use the temperature at all, which I guess is fine for a 2D case (which I guess is what you look at). best regards, Philipp On 2018-07-10 22:33, Philipp Schlatter wrote: > Dear Hannah, > sorry that I only see the post now. Are you still having problems with > the stream function, or does it work now? > Best regards, > Philipp > > On 2018-07-02 16:40, nek5000-users at lists.mcs.anl.gov wrote: >> Hi JC, >> >> Yes, the mv_wall example computes the streamfunction, but it applies >> tmask, tmult that I could not find where they are defined in the >> file. I was experimenting with different masks. >> >> Do you know how postnek compute the streamfunction? >> >> I think it is computed in the subroutine strfct(psi) in postnek2.f, >> but I am not sure what happens in the routine? >> >> Thanks, >> >> Hannah >> ________________________________________ >> From: Nek5000-users [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, June 29, 2018 3:47 AM >> To: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] Stream function >> >> Hi Hannah, >> >> I tried to implement the streamfunction as well (for a 2D cylinder flow) >> and it would appear that, doing na?vely, the tmask is set to zero >> everywhere. Hence, when rhs * tmask is computed in the hmholtz >> subroutine, rhs is set to zero everywhere and it then makes sense that >> the returned streamfunction is zero everywhere as well. >> >> Not sure how to do fix this properly though. Any help would be >> appreciated indeed :) >> >> >> ++ >> JC >> >> >> On 06/28/2018 09:41 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> Hi Philipp, >>> >>> Thanks very much for your comments. Yes, the delta* works only for >>> the parallel plate. >>> >>> The streamfunction computation with the Blasius example is still not >>> working. I suspect I am not using the correct mask (vmult /tmult, >>> imsh as well). >>> >>> Using the Blasius example, v1mask, vmult (imsh = 1), I dumped the >>> streamfuntion to the temperature field. However, it only contains >>> negative values and does not look physical (I pasted userchk below). >>> >>> Another Nek Example, ?mv_wall?, computes the streamfunction from the >>> Possison equation using vorticity. It uses tmask, tmult, and imsh = 2. >>> >>> I tried implementing what was done in the ?mv_wall? example in the >>> Blasius example, but the computed streamfunction is zero everywhere. >>> >>> Any ideas what I might be doing wrong? >>> >>> Any advice would be appreciated! >>> >>> Thanks again, >>> >>> Hannah >>> >>> c----------------------------------------------------------------------- >>> subroutine userchk >>> include 'SIZE' >>> include 'TOTAL' >>> >>> common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >>> >>> common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >>> common /blasiusg/ bin(lx1,ly1,lz1,lelv) >>> common /scrns/ dum(lx1*ly1*lz1*lelv) >>> >>> common /xtream/ psi(lx1*ly1*lz1*lelt) >>> $ , rhs(lx1*ly1*lz1*lelt) >>> $ , h1 (lx1*ly1*lz1*lelt) >>> $ , h2 (lx1*ly1*lz1*lelt) >>> >>> parameter (lt=lx1*ly1*lz1*lelt) >>> common /scrns/ vort(lt,3),w1(lt),w2(lt) >>> >>> integer bin >>> real normu(50),normv(50) >>> >>> real xmax,xmin,dx >>> save xmax,xmin,dx >>> >>> n = nx1*ny1*nz1*nelv >>> ifheat=.false. >>> call comp_vort3(vort , w1, w2, vx, vy, vz) >>> call copy (t,vort,n) ! Vorticity --> T >>> ifto = .true. ! Dump vorticity as T >>> c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>> c Compute streamfunction from vorticity >>> call col3 (rhs,t,bm1,n) ! B*omega >>> call rone (h1,n) >>> call rzero(h2,n) >>> >>> ifield = 1 >>> tol = param(22) >>> imsh = 1 >>> call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh, >>> $ tol,200,1) >>> call copy (t,psi,n) ! Psi --> T (for output) >>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>> >>> nfldt = 1 + npscal >>> >>> if (istep.eq.0) call outpost2(vx,vy,vz,pr,t,nfldt,' ') >>> >>> do i=1,n >>> dum(i) = 1.-vx(i,1,1,1) >>> enddo >>> tot_deficit = glsc2(dum,bm1,n) >>> xmin = glmin(xm1,n) >>> xmax = glmax(xm1,n) >>> delta_star = tot_deficit/(xmax-xmin) >>> tmin = glmin(t,n) >>> tmax = glmax(t,n) >>> vortmin = glmin(vort,n) >>> vortmax = glmax(vort,n) >>> if (nid.eq.0) write(6,1) istep,time,delta_star,vortmin,vortmax >>> if (nid.eq.0) write(6,1) istep,tmin,tmax >>> 1 format(i8,1p4e13.5,' blasius: delta*') >>> >>> return >>> end >>> c----------------------------------------------------------------------- >>> >>> >>> ________________________________________ >>> From: Nek5000-users [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, June 26, 2018 1:22 PM >>> To: nek5000-users at lists.mcs.anl.gov >>> Subject: Re: [Nek5000-users] Stream function >>> >>> Hi, >>> To correctly compute the stream function, the rhs of the Poisson >>> equation needs to be the (negative) vorticity. Therefore, the line >>> >>> call col2(rhs,bm1,n) >>> >>> is wrong, and should be something like >>> >>> call col3(rhs, vorticity, bm1, n) >>> >>> where vorticity should be the computed vorticity using comp_vort. >>> >>> I guess your calculation of delta* only works for parallel boundary >>> layers. >>> >>> Philipp >>> >>> >>> >>> On 2018-06-26 18:35, nek5000-users at lists.mcs.anl.gov wrote: >>>> Hi Phillip, >>>> >>>> I am using the ?Blasius? example test outputting the streamfunction >>>> as a >>>> scalar. >>>> >>>> I included my code below. I am not sure what I am doing wrong. >>>> >>>> In userchk, I added ?compute streamfunction from vorticity? from the >>>> psi_omega example, but it does not compute the psi properly? (max_psi = >>>> min_psi = 0 in every step) >>>> >>>> c----------------------------------------------------------------------- >>>> >>>> >>>> subroutine userchk >>>> >>>> include 'SIZE' >>>> >>>> include 'TOTAL' >>>> >>>> common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >>>> >>>> common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >>>> >>>> common /blasiusg/ bin(lx1,ly1,lz1,lelv) >>>> >>>> common /scrns/ dum(lx1*ly1*lz1*lelv) >>>> >>>> common /xtream/ psi(lx1*ly1*lz1*lelt) >>>> >>>> $ , rhs(lx1*ly1*lz1*lelt) >>>> >>>> $ , h1 (lx1*ly1*lz1*lelt) >>>> >>>> $ , h2 (lx1*ly1*lz1*lelt) >>>> >>>> integer bin >>>> >>>> real normu(50),normv(50) >>>> >>>> real xmax,xmin,dx >>>> >>>> save xmax,xmin,dx >>>> >>>> n = nx1*ny1*nz1*nelv >>>> >>>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>>> >>>> c Compute streamfunction from vorticity >>>> >>>> call col2(rhs,bm1,n) >>>> >>>> call rone (h1 ,n) >>>> >>>> call rzero(h2 ,n) >>>> >>>> tol = param(22) >>>> >>>> imsh = 1 >>>> >>>> call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh,tol,200,1) >>>> >>>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>>> >>>> if (istep.eq.0) call outpost(vx,vy,vz,pr,psi,' ') >>>> >>>> c Compute delta* >>>> >>>> do i=1,n >>>> >>>> dum(i) = 1.-vx(i,1,1,1) >>>> >>>> enddo >>>> >>>> tot_deficit = glsc2(dum,bm1,n) >>>> >>>> xmin = glmin(xm1,n) >>>> >>>> xmax = glmax(xm1,n) >>>> >>>> delta_star = tot_deficit/(xmax-xmin) >>>> >>>> psimin = glmin(psi,n) >>>> >>>> psimax = glmax(psi,n) >>>> >>>> if (nid.eq.0) write(6,1) istep,time,delta_star,psimin,psimax >>>> >>>> 1 format(i8,1p4e13.5,' blasius: delta*') >>>> >>>> return >>>> >>>> end >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Fri Jul 13 05:00:28 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 15:30:28 +0530 Subject: [Nek5000-users] Problem in obtaining eigenvalues through Arnoldi (using NEK5000 with the ARPACK library) In-Reply-To: References: Message-ID: Hi Adam, Thanks for your reply. 0.100000E-09 p021 DIVERGENCE 0.100000E-09 p022 HELMHOLTZ 0.100000E-09 p024 TOLREL 0.100000E-04 p025 TOLABS 1.00000E-06 p113 : ARNOLDI: arpack tolerance Number of mesh element for entire domain is 1200. The resolution in cylinder vicinity On Thu, Jul 12, 2018 at 9:41 PM, wrote: > Hi; > What is your tolerance for eigenvalue convergence? I'm unable to answer > your question directly, as there can be number of problems. One of the > obvious ones could be mesh resolution. You have pretty big mesh. What is > the resolution in cylinder vicinity? What is the polynomial order? You have > number of eigenvalues converged to machine accuracy and a few of the order > 10**-4 in between. Those could be some spurious modes related to > insufficient resolution. What is your Reynolds number? > Regards > Adam > > > On 12/07/18 10:07, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Neks > > I am running a 3D simulation for a flow over a cylinder. My domain > size for simulation is 100Dx100D. where D is the diameter of a cylinder. We > have obtained the base flow through SFD. The base flow is used to calculate > the stability analysis through NEK5000 with the ARPACK library (Implemented > by A. Peplinski). > > we have used the following parameters..... > > 90.0000 p111 : ARNOLDI: size of Krylov space > 30.0000 p112 : ARNOLDI: number of eigenvectors > > We have run the Arnoldi with restart but we are not able to get the output > file (eigenvalues.txt and egvext_cyl0.f0..) even after almost 20 restarts. > Also, we tried to run with increasing the size of Krylov space but the > eigenvalues are not converging. > > The log file shows no changes in converged ritz values after around 20-22 > values. > > The part of the log file is shown below........... > > Kindly, help me out and let me know where I am going wrong..... > > Alok Mishra > > > > ------------------------------------------------------------ > --------------------------------------------------- > > ARNOLDI: after 520 stepper phase > > _naup2: Corresponding B-norm of the residual > -------------------------------------------- > 1 - 1: 6.623D-01 > > > _naup2: no. of "converged" Ritz values at this iter. > ---------------------------------------------------- > 1 - 1: 22 > > > _naup2: NEV and NP are > ---------------------- > 1 - 2: 52 128 > > > _naup2: "wanted" Ritz values -- real part > ----------------------------------------- > 1 - 5: 9.905D-01 9.905D-01 9.854D-01 9.854D-01 9.855D-01 > 6 - 10: 9.855D-01 9.897D-01 9.897D-01 9.924D-01 9.930D-01 > 11 - 15: 9.930D-01 9.905D-01 9.905D-01 9.943D-01 9.943D-01 > 16 - 20: 9.938D-01 9.938D-01 9.948D-01 9.948D-01 9.949D-01 > 21 - 25: 9.949D-01 9.951D-01 9.958D-01 9.960D-01 9.962D-01 > 26 - 30: 9.962D-01 9.966D-01 9.970D-01 9.970D-01 9.969D-01 > 31 - 35: 9.969D-01 9.973D-01 9.974D-01 9.975D-01 9.976D-01 > 36 - 40: 9.976D-01 9.971D-01 9.971D-01 9.978D-01 9.979D-01 > 41 - 45: 9.979D-01 9.982D-01 9.982D-01 1.000D+00 9.908D-01 > 46 - 50: 9.908D-01 1.004D+00 1.004D+00 1.005D+00 1.005D+00 > 51 - 52: 1.006D+00 1.006D+00 > > > _naup2: "wanted" Ritz values -- imag part > ----------------------------------------- > 1 - 5: 5.038D-02 -5.038D-02 -1.127D-01 1.127D-01 -1.119D-01 > 6 - 10: 1.119D-01 6.954D-02 -6.954D-02 0.000D+00 3.705D-03 > 11 - 15: -3.705D-03 -7.103D-02 7.103D-02 -9.233D-04 9.233D-04 > 16 - 20: 4.345D-02 -4.345D-02 6.799D-04 -6.799D-04 -1.821D-02 > 21 - 25: 1.821D-02 0.000D+00 0.000D+00 0.000D+00 -2.047D-03 > 26 - 30: 2.047D-03 0.000D+00 7.200D-05 -7.200D-05 2.386D-02 > 31 - 35: -2.386D-02 0.000D+00 0.000D+00 0.000D+00 -1.140D-04 > 36 - 40: 1.140D-04 3.125D-02 -3.125D-02 0.000D+00 -1.248D-04 > 41 - 45: 1.248D-04 -1.673D-03 1.673D-03 0.000D+00 -1.508D-01 > 46 - 50: 1.508D-01 -1.863D-02 1.863D-02 -2.109D-02 2.109D-02 > 51 - 52: -1.152D-02 1.152D-02 > > > _naup2: Ritz estimates of the "wanted" values > ---------------------------------------------- > 1 - 5: 3.315D-02 3.315D-02 3.244D-05 3.244D-05 7.035D-05 > 6 - 10: 7.035D-05 6.072D-11 6.072D-11 1.314D-02 2.772D-06 > 11 - 15: 2.772D-06 6.796D-15 6.796D-15 9.719D-04 9.719D-04 > 16 - 20: 7.467D-17 7.467D-17 5.506D-04 5.506D-04 2.437D-16 > 21 - 25: 2.437D-16 2.977D-03 7.238D-04 6.054D-04 3.914D-11 > 26 - 30: 3.914D-11 1.827D-04 1.138D-04 1.138D-04 1.048D-16 > 31 - 35: 1.048D-16 1.198D-04 6.358D-05 3.013D-05 3.490D-07 > 36 - 40: 3.490D-07 9.960D-18 9.960D-18 1.340D-07 2.518D-10 > 41 - 45: 2.518D-10 1.827D-16 1.827D-16 1.781D-16 7.278D-17 > 46 - 50: 7.278D-17 0.000D+00 0.000D+00 0.000D+00 0.000D+00 > 51 - 52: 0.000D+00 0.000D+00 > > Reached max iteration number; settingido=-2 for checkpointing. > ARNOLDI: > IDOARP = -2 > Writing checkpoint > 0 40 OPEN: ARPm11800.f00002 > 0 40 OPEN: ARVm11800.f00002 > > 40 2.0000E-01 done :: Write checkpoint > file size = 621.E+00MB > avg data-throughput = 624.1MB/s > io-nodes = 1 > > > ARNOLDI: finalize > Number of stepper cycles 520 > Time spent in ARNOLDI 60.3302609920502 > Average stepper phase time 10.9141681075096 > call outfld: ifpsco: F > > 40 2.0000E-01 Write checkpoint: > 0 40 OPEN: m11800.f00001 > > 40 2.0000E-01 done :: Write checkpoint > file size = 4.0 MB > avg data-throughput = 303.2MB/s > io-nodes = 1 > > > end of time-step loop > > > > > > > _______________________________________________ > Nek5000-users mailing listNek5000-users at lists.mcs.anl.govhttps://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 > > -- Alok Mishra Research Scholar Computational Propulsion Lab Aerospace Department IIT Kanpur +91-8795844555 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jul 13 05:09:40 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 15:39:40 +0530 Subject: [Nek5000-users] Problem in obtaining eigenvalues through Arnoldi (using NEK5000 with the ARPACK library) In-Reply-To: References: Message-ID: Hi Adam, Thanks for your reply. Tolerance for the different parameter taken for the case is shown below 0.100000E-09 p021 DIVERGENCE 0.100000E-09 p022 HELMHOLTZ 0.100000E-09 p024 TOLREL 0.100000E-04 p025 TOLABS 1.00000E-06 p113 : ARNOLDI: arpack tolerance Number of mesh element for entire domain is 1200. The resolution in cylinder vicinity is 32x10 (for the domain 2Dx2D over cylinder )and we have resolved the boundary with y+ =3 for Re=50. And the order of the polynomial is 5. Hope to get your reply soon.... Regards Alok On Thu, Jul 12, 2018 at 9:41 PM, wrote: > Hi; > What is your tolerance for eigenvalue convergence? I'm unable to answer > your question directly, as there can be number of problems. One of the > obvious ones could be mesh resolution. You have pretty big mesh. What is > the resolution in cylinder vicinity? What is the polynomial order? You have > number of eigenvalues converged to machine accuracy and a few of the order > 10**-4 in between. Those could be some spurious modes related to > insufficient resolution. What is your Reynolds number? > Regards > Adam > > > On 12/07/18 10:07, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Neks > > I am running a 3D simulation for a flow over a cylinder. My domain > size for simulation is 100Dx100D. where D is the diameter of a cylinder. We > have obtained the base flow through SFD. The base flow is used to calculate > the stability analysis through NEK5000 with the ARPACK library (Implemented > by A. Peplinski). > > we have used the following parameters..... > > 90.0000 p111 : ARNOLDI: size of Krylov space > 30.0000 p112 : ARNOLDI: number of eigenvectors > > We have run the Arnoldi with restart but we are not able to get the output > file (eigenvalues.txt and egvext_cyl0.f0..) even after almost 20 restarts. > Also, we tried to run with increasing the size of Krylov space but the > eigenvalues are not converging. > > The log file shows no changes in converged ritz values after around 20-22 > values. > > The part of the log file is shown below........... > > Kindly, help me out and let me know where I am going wrong..... > > Alok Mishra > > > > ------------------------------------------------------------ > --------------------------------------------------- > > ARNOLDI: after 520 stepper phase > > _naup2: Corresponding B-norm of the residual > -------------------------------------------- > 1 - 1: 6.623D-01 > > > _naup2: no. of "converged" Ritz values at this iter. > ---------------------------------------------------- > 1 - 1: 22 > > > _naup2: NEV and NP are > ---------------------- > 1 - 2: 52 128 > > > _naup2: "wanted" Ritz values -- real part > ----------------------------------------- > 1 - 5: 9.905D-01 9.905D-01 9.854D-01 9.854D-01 9.855D-01 > 6 - 10: 9.855D-01 9.897D-01 9.897D-01 9.924D-01 9.930D-01 > 11 - 15: 9.930D-01 9.905D-01 9.905D-01 9.943D-01 9.943D-01 > 16 - 20: 9.938D-01 9.938D-01 9.948D-01 9.948D-01 9.949D-01 > 21 - 25: 9.949D-01 9.951D-01 9.958D-01 9.960D-01 9.962D-01 > 26 - 30: 9.962D-01 9.966D-01 9.970D-01 9.970D-01 9.969D-01 > 31 - 35: 9.969D-01 9.973D-01 9.974D-01 9.975D-01 9.976D-01 > 36 - 40: 9.976D-01 9.971D-01 9.971D-01 9.978D-01 9.979D-01 > 41 - 45: 9.979D-01 9.982D-01 9.982D-01 1.000D+00 9.908D-01 > 46 - 50: 9.908D-01 1.004D+00 1.004D+00 1.005D+00 1.005D+00 > 51 - 52: 1.006D+00 1.006D+00 > > > _naup2: "wanted" Ritz values -- imag part > ----------------------------------------- > 1 - 5: 5.038D-02 -5.038D-02 -1.127D-01 1.127D-01 -1.119D-01 > 6 - 10: 1.119D-01 6.954D-02 -6.954D-02 0.000D+00 3.705D-03 > 11 - 15: -3.705D-03 -7.103D-02 7.103D-02 -9.233D-04 9.233D-04 > 16 - 20: 4.345D-02 -4.345D-02 6.799D-04 -6.799D-04 -1.821D-02 > 21 - 25: 1.821D-02 0.000D+00 0.000D+00 0.000D+00 -2.047D-03 > 26 - 30: 2.047D-03 0.000D+00 7.200D-05 -7.200D-05 2.386D-02 > 31 - 35: -2.386D-02 0.000D+00 0.000D+00 0.000D+00 -1.140D-04 > 36 - 40: 1.140D-04 3.125D-02 -3.125D-02 0.000D+00 -1.248D-04 > 41 - 45: 1.248D-04 -1.673D-03 1.673D-03 0.000D+00 -1.508D-01 > 46 - 50: 1.508D-01 -1.863D-02 1.863D-02 -2.109D-02 2.109D-02 > 51 - 52: -1.152D-02 1.152D-02 > > > _naup2: Ritz estimates of the "wanted" values > ---------------------------------------------- > 1 - 5: 3.315D-02 3.315D-02 3.244D-05 3.244D-05 7.035D-05 > 6 - 10: 7.035D-05 6.072D-11 6.072D-11 1.314D-02 2.772D-06 > 11 - 15: 2.772D-06 6.796D-15 6.796D-15 9.719D-04 9.719D-04 > 16 - 20: 7.467D-17 7.467D-17 5.506D-04 5.506D-04 2.437D-16 > 21 - 25: 2.437D-16 2.977D-03 7.238D-04 6.054D-04 3.914D-11 > 26 - 30: 3.914D-11 1.827D-04 1.138D-04 1.138D-04 1.048D-16 > 31 - 35: 1.048D-16 1.198D-04 6.358D-05 3.013D-05 3.490D-07 > 36 - 40: 3.490D-07 9.960D-18 9.960D-18 1.340D-07 2.518D-10 > 41 - 45: 2.518D-10 1.827D-16 1.827D-16 1.781D-16 7.278D-17 > 46 - 50: 7.278D-17 0.000D+00 0.000D+00 0.000D+00 0.000D+00 > 51 - 52: 0.000D+00 0.000D+00 > > Reached max iteration number; settingido=-2 for checkpointing. > ARNOLDI: > IDOARP = -2 > Writing checkpoint > 0 40 OPEN: ARPm11800.f00002 > 0 40 OPEN: ARVm11800.f00002 > > 40 2.0000E-01 done :: Write checkpoint > file size = 621.E+00MB > avg data-throughput = 624.1MB/s > io-nodes = 1 > > > ARNOLDI: finalize > Number of stepper cycles 520 > Time spent in ARNOLDI 60.3302609920502 > Average stepper phase time 10.9141681075096 > call outfld: ifpsco: F > > 40 2.0000E-01 Write checkpoint: > 0 40 OPEN: m11800.f00001 > > 40 2.0000E-01 done :: Write checkpoint > file size = 4.0 MB > avg data-throughput = 303.2MB/s > io-nodes = 1 > > > end of time-step loop > > > > > > > _______________________________________________ > Nek5000-users mailing listNek5000-users at lists.mcs.anl.govhttps://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 > > -- Alok Mishra Research Scholar Computational Propulsion Lab Aerospace Department IIT Kanpur +91-8795844555 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jul 13 06:57:35 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 11:57:35 +0000 Subject: [Nek5000-users] Pipe Roughness Message-ID: Yes, that is very useful and what I am looking for. Many thanks, Ali (Student) Embry-Riddle Aeronautical University -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jul 13 07:13:37 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 14:13:37 +0200 Subject: [Nek5000-users] Stream function In-Reply-To: References: <72604073-3f81-bd54-b576-b87613f0f133@mech.kth.se> Message-ID: Hi, I guess the errors under point 2 are related to the fact that you try to include the same common block multiple times, i.e. you probably have TOTAL and INPUT, SOLN and MASS. Just make sure that you have the relevant variables included via common blocks. Regarding point 1: In the end, you would need to decide what your boundary conditions for the Poisson/Helmholtz equation really are. For the example, we consider an all Dirichlet boundary, which can then be achieved with v2mask (or in fact v1mask as well i guess); this because all solid boundaries are connected and have thus the same value for the streamfunction. For your case, I guess you have periodicity in the streamwise direction, and solid wall at y=0. Not sure what one really needs to impose on the upper boundary... but in the end, this is why we use vmask2 in the example. Hope this helps, Philipp On 2018-07-12 20:47, nek5000-users at lists.mcs.anl.gov wrote: > Hi Philipp, > > Thanks very much for the userchk routine. > > I have been testing this with the Blasius example in Nek. I am hoping to implement this with my geometry (a 2-D backward facing step with the Blasius profile at the inlet upstream from the step). > > For the Blasius example in Nek, I used VisIt and checked rhs and psi from the stfc0.f* file, but psi does not look physical. > > 1. What is the purpose of using v2mask? I wonder whether I should specify a different mask... > > 2. Including declarations from 'INPUT', 'SOLN', and 'MASS' produced a long list of errors (please see below). To run the code, I commented three lines related to including 'INPUT', 'SOLN', and 'MASS'so that these are not included, but I wonder whether that would create problems? > > Any advice would be appreciated. > > Thanks very much. > > Hannah > > > INPUT:14:16: Error: Symbol ?param? at (1) already has basic type of REAL > INPUT:22:27: Error: Symbol ?param? at (1) is already in a COMMON block > INPUT:25:20: Error: Symbol ?matype? at (1) already has basic type of INTEGER > INPUT:30:28: Error: Symbol ?matype? at (1) is already in a COMMON block > INPUT:34:26: Error: Symbol ?if3d? at (1) already has basic type of LOGICAL > INPUT:50:26: Error: Symbol ?if3d? at (1) is already in a COMMON block > INPUT:66:27: Error: Symbol ?ifnav? at (1) already has basic type of LOGICAL > INPUT:69:27: Error: Symbol ?hcode? at (1) already has basic type of CHARACTER > INPUT:70:27: Error: Symbol ?ocode? at (1) already has basic type of CHARACTER > INPUT:71:27: Error: Symbol ?drivc? at (1) already has basic type of CHARACTER > INPUT:72:26: Error: Symbol ?rstv? at (1) already has basic type of CHARACTER > INPUT:73:28: Error: Symbol ?textsw? at (1) already has basic type of CHARACTER > INPUT:74:27: Error: Symbol ?initc? at (1) already has basic type of CHARACTER > INPUT:75:27: Error: Symbol ?hcode? at (1) is already in a COMMON block > INPUT:77:29: Error: Symbol ?turbmod? at (1) already has basic type of CHARACTER > INPUT:80:28: Error: Symbol ?reafle? at (1) already has basic type of CHARACTER > INPUT:81:28: Error: Symbol ?reafle? at (1) is already in a COMMON block > INPUT:83:29: Error: Symbol ?session? at (1) already has basic type of CHARACTER > INPUT:84:29: Error: Symbol ?session? at (1) is already in a COMMON block > INPUT:86:20: Error: Symbol ?cr_re2? at (1) already has basic type of INTEGER > INPUT:87:33: Error: Symbol ?cr_re2? at (1) is already in a COMMON block > INPUT:89:24: Error: Symbol ?re2off_b? at (1) already has basic type of INTEGER > INPUT:90:31: Error: Symbol ?re2off_b? at (1) is already in a COMMON block > INPUT:94:13: Error: Symbol ?xc? at (1) already has basic type of REAL > INPUT:98:24: Error: Symbol ?xc? at (1) is already in a COMMON block > INPUT:100:20: Error: Symbol ?igroup? at (1) already has basic type of INTEGER > INPUT:101:28: Error: Symbol ?igroup? at (1) is already in a COMMON block > INPUT:103:28: Error: Symbol ?ccurve? at (1) already has basic type of CHARACTER > INPUT:104:25: Error: Symbol ?cbc? at (1) already has basic type of CHARACTER > INPUT:105:25: Error: Symbol ?cbc? at (1) is already in a COMMON block > INPUT:107:19: Error: Symbol ?ieact? at (1) already has basic type of INTEGER > INPUT:108:27: Error: Symbol ?ieact? at (1) is already in a COMMON block > INPUT:112:20: Error: Symbol ?numsts? at (1) already has basic type of INTEGER > INPUT:113:26: Error: PARAMETER attribute of ?numsts? conflicts with PARAMETER attribute at (1) > INPUT:115:20: Error: Symbol ?numflu? at (1) already has basic type of INTEGER > INPUT:118:29: Error: Symbol ?numflu? at (1) is already in a COMMON block > INPUT:121:17: Error: Symbol ?bcf? at (1) already has basic type of INTEGER > INPUT:122:26: Error: Symbol ?bcf? at (1) is already in a COMMON block > INPUT:124:24: Error: Symbol ?bctyps? at (1) already has basic type of CHARACTER > INPUT:125:29: Error: Symbol ?bctyps? at (1) is already in a COMMON block > SOLN:4:18: Error: Symbol ?lvt1? at (1) already has basic type of INTEGER > SOLN:5:41: Error: PARAMETER attribute of ?lvt1? conflicts with PARAMETER attribute at (1) > SOLN:6:41: Error: PARAMETER attribute of ?lvt2? conflicts with PARAMETER attribute at (1) > SOLN:7:45: Error: PARAMETER attribute of ?lbt1? conflicts with PARAMETER attribute at (1) > SOLN:8:45: Error: PARAMETER attribute of ?lbt2? conflicts with PARAMETER attribute at (1) > SOLN:10:42: Error: PARAMETER attribute of ?lorder2? conflicts with PARAMETER attribute at (1) > SOLN:14:13: Error: Symbol ?bq? at (1) already has basic type of REAL > SOLN:15:22: Error: Symbol ?bq? at (1) is already in a COMMON block > SOLN:18:16: Error: Symbol ?vxlag? at (1) already has basic type of REAL > SOLN:33:13: Error: Symbol ?vx? at (1) already has basic type of REAL > SOLN:52:27: Error: Symbol ?vxlag? at (1) is already in a COMMON block > SOLN:59:13: Error: Symbol ?bx? at (1) already has basic type of REAL > SOLN:78:13: Error: Symbol ?bx? at (1) is already in a COMMON block > SOLN:82:18: Error: Symbol ?nu_star? at (1) already has basic type of REAL > SOLN:83:29: Error: Symbol ?nu_star? at (1) is already in a COMMON block > SOLN:85:13: Error: Symbol ?pr? at (1) already has basic type of REAL > SOLN:86:22: Error: Symbol ?pr? at (1) is already in a COMMON block > SOLN:88:14: Error: Symbol ?qtl? at (1) already has basic type of REAL > SOLN:89:25: Error: Symbol ?qtl? at (1) is already in a COMMON block > SOLN:91:15: Error: Symbol ?p0th? at (1) already has basic type of REAL > SOLN:92:27: Error: Symbol ?p0th? at (1) is already in a COMMON block > SOLN:94:18: Error: Symbol ?v1mask? at (1) already has basic type of REAL > SOLN:106:28: Error: Symbol ?v1mask? at (1) is already in a COMMON block > SOLN:111:15: Error: Symbol ?vxp? at (1) already has basic type of REAL > SOLN:133:25: Error: Symbol ?vxp? at (1) is already in a COMMON block > SOLN:138:16: Error: Symbol ?jp? at (1) already has basic type of INTEGER > SOLN:139:25: Error: Symbol ?jp? at (1) is already in a COMMON block > MASS:4:14: Error: Symbol ?bm1? at (1) already has basic type of REAL > MASS:11:23: Error: Symbol ?bm1? at (1) is already in a COMMON block > /home/Hannah/NekExamples/blasius/c3.f:360:25: > > call compute_f (f1,w ,t ) > 1 > Warning: Actual argument contains too few elements for dummy argument ?w? (1/4) at (1) > makefile:119: recipe for target 'nek5000' failed > make: *** [nek5000] Error 1 > ________________________________________ > From: Nek5000-users [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, July 12, 2018 3:37 AM > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Stream function > > Ok, so can you please just try the attached code in userchck? It should > work (at least does for us) in 2D. Essentially, the steps are: > 1. copmute z-vorticity in a new array vorticity > 2. construct the rhs by multiplying with -bm1 > 3. setup the Helmholtz problem and tolerances > 4. solve the Helmholtz problem and storing the results in a new array phi > 5. write out everything in two files. > > In this code you do not use the temperature at all, which I guess is > fine for a 2D case (which I guess is what you look at). > > best regards, > Philipp > > On 2018-07-10 22:33, Philipp Schlatter wrote: >> Dear Hannah, >> sorry that I only see the post now. Are you still having problems with >> the stream function, or does it work now? >> Best regards, >> Philipp >> >> On 2018-07-02 16:40, nek5000-users at lists.mcs.anl.gov wrote: >>> Hi JC, >>> >>> Yes, the mv_wall example computes the streamfunction, but it applies >>> tmask, tmult that I could not find where they are defined in the >>> file. I was experimenting with different masks. >>> >>> Do you know how postnek compute the streamfunction? >>> >>> I think it is computed in the subroutine strfct(psi) in postnek2.f, >>> but I am not sure what happens in the routine? >>> >>> Thanks, >>> >>> Hannah >>> ________________________________________ >>> From: Nek5000-users [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, June 29, 2018 3:47 AM >>> To: nek5000-users at lists.mcs.anl.gov >>> Subject: Re: [Nek5000-users] Stream function >>> >>> Hi Hannah, >>> >>> I tried to implement the streamfunction as well (for a 2D cylinder flow) >>> and it would appear that, doing na?vely, the tmask is set to zero >>> everywhere. Hence, when rhs * tmask is computed in the hmholtz >>> subroutine, rhs is set to zero everywhere and it then makes sense that >>> the returned streamfunction is zero everywhere as well. >>> >>> Not sure how to do fix this properly though. Any help would be >>> appreciated indeed :) >>> >>> >>> ++ >>> JC >>> >>> >>> On 06/28/2018 09:41 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> Hi Philipp, >>>> >>>> Thanks very much for your comments. Yes, the delta* works only for >>>> the parallel plate. >>>> >>>> The streamfunction computation with the Blasius example is still not >>>> working. I suspect I am not using the correct mask (vmult /tmult, >>>> imsh as well). >>>> >>>> Using the Blasius example, v1mask, vmult (imsh = 1), I dumped the >>>> streamfuntion to the temperature field. However, it only contains >>>> negative values and does not look physical (I pasted userchk below). >>>> >>>> Another Nek Example, ?mv_wall?, computes the streamfunction from the >>>> Possison equation using vorticity. It uses tmask, tmult, and imsh = 2. >>>> >>>> I tried implementing what was done in the ?mv_wall? example in the >>>> Blasius example, but the computed streamfunction is zero everywhere. >>>> >>>> Any ideas what I might be doing wrong? >>>> >>>> Any advice would be appreciated! >>>> >>>> Thanks again, >>>> >>>> Hannah >>>> >>>> c----------------------------------------------------------------------- >>>> subroutine userchk >>>> include 'SIZE' >>>> include 'TOTAL' >>>> >>>> common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >>>> >>>> common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >>>> common /blasiusg/ bin(lx1,ly1,lz1,lelv) >>>> common /scrns/ dum(lx1*ly1*lz1*lelv) >>>> >>>> common /xtream/ psi(lx1*ly1*lz1*lelt) >>>> $ , rhs(lx1*ly1*lz1*lelt) >>>> $ , h1 (lx1*ly1*lz1*lelt) >>>> $ , h2 (lx1*ly1*lz1*lelt) >>>> >>>> parameter (lt=lx1*ly1*lz1*lelt) >>>> common /scrns/ vort(lt,3),w1(lt),w2(lt) >>>> >>>> integer bin >>>> real normu(50),normv(50) >>>> >>>> real xmax,xmin,dx >>>> save xmax,xmin,dx >>>> >>>> n = nx1*ny1*nz1*nelv >>>> ifheat=.false. >>>> call comp_vort3(vort , w1, w2, vx, vy, vz) >>>> call copy (t,vort,n) ! Vorticity --> T >>>> ifto = .true. ! Dump vorticity as T >>>> c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>>> c Compute streamfunction from vorticity >>>> call col3 (rhs,t,bm1,n) ! B*omega >>>> call rone (h1,n) >>>> call rzero(h2,n) >>>> >>>> ifield = 1 >>>> tol = param(22) >>>> imsh = 1 >>>> call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh, >>>> $ tol,200,1) >>>> call copy (t,psi,n) ! Psi --> T (for output) >>>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>>> >>>> nfldt = 1 + npscal >>>> >>>> if (istep.eq.0) call outpost2(vx,vy,vz,pr,t,nfldt,' ') >>>> >>>> do i=1,n >>>> dum(i) = 1.-vx(i,1,1,1) >>>> enddo >>>> tot_deficit = glsc2(dum,bm1,n) >>>> xmin = glmin(xm1,n) >>>> xmax = glmax(xm1,n) >>>> delta_star = tot_deficit/(xmax-xmin) >>>> tmin = glmin(t,n) >>>> tmax = glmax(t,n) >>>> vortmin = glmin(vort,n) >>>> vortmax = glmax(vort,n) >>>> if (nid.eq.0) write(6,1) istep,time,delta_star,vortmin,vortmax >>>> if (nid.eq.0) write(6,1) istep,tmin,tmax >>>> 1 format(i8,1p4e13.5,' blasius: delta*') >>>> >>>> return >>>> end >>>> c----------------------------------------------------------------------- >>>> >>>> >>>> ________________________________________ >>>> From: Nek5000-users [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, June 26, 2018 1:22 PM >>>> To: nek5000-users at lists.mcs.anl.gov >>>> Subject: Re: [Nek5000-users] Stream function >>>> >>>> Hi, >>>> To correctly compute the stream function, the rhs of the Poisson >>>> equation needs to be the (negative) vorticity. Therefore, the line >>>> >>>> call col2(rhs,bm1,n) >>>> >>>> is wrong, and should be something like >>>> >>>> call col3(rhs, vorticity, bm1, n) >>>> >>>> where vorticity should be the computed vorticity using comp_vort. >>>> >>>> I guess your calculation of delta* only works for parallel boundary >>>> layers. >>>> >>>> Philipp >>>> >>>> >>>> >>>> On 2018-06-26 18:35, nek5000-users at lists.mcs.anl.gov wrote: >>>>> Hi Phillip, >>>>> >>>>> I am using the ?Blasius? example test outputting the streamfunction >>>>> as a >>>>> scalar. >>>>> >>>>> I included my code below. I am not sure what I am doing wrong. >>>>> >>>>> In userchk, I added ?compute streamfunction from vorticity? from the >>>>> psi_omega example, but it does not compute the psi properly? (max_psi = >>>>> min_psi = 0 in every step) >>>>> >>>>> c----------------------------------------------------------------------- >>>>> >>>>> >>>>> subroutine userchk >>>>> >>>>> include 'SIZE' >>>>> >>>>> include 'TOTAL' >>>>> >>>>> common /myblas/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) >>>>> >>>>> common /blasiusr/ u(lx1,ly1,lz1,lelv),v(lx1,ly1,lz1,lelv) >>>>> >>>>> common /blasiusg/ bin(lx1,ly1,lz1,lelv) >>>>> >>>>> common /scrns/ dum(lx1*ly1*lz1*lelv) >>>>> >>>>> common /xtream/ psi(lx1*ly1*lz1*lelt) >>>>> >>>>> $ , rhs(lx1*ly1*lz1*lelt) >>>>> >>>>> $ , h1 (lx1*ly1*lz1*lelt) >>>>> >>>>> $ , h2 (lx1*ly1*lz1*lelt) >>>>> >>>>> integer bin >>>>> >>>>> real normu(50),normv(50) >>>>> >>>>> real xmax,xmin,dx >>>>> >>>>> save xmax,xmin,dx >>>>> >>>>> n = nx1*ny1*nz1*nelv >>>>> >>>>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>>>> >>>>> c Compute streamfunction from vorticity >>>>> >>>>> call col2(rhs,bm1,n) >>>>> >>>>> call rone (h1 ,n) >>>>> >>>>> call rzero(h2 ,n) >>>>> >>>>> tol = param(22) >>>>> >>>>> imsh = 1 >>>>> >>>>> call hmholtz('psi ',psi,rhs,h1,h2,v1mask,vmult,imsh,tol,200,1) >>>>> >>>>> c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>>>> >>>>> if (istep.eq.0) call outpost(vx,vy,vz,pr,psi,' ') >>>>> >>>>> c Compute delta* >>>>> >>>>> do i=1,n >>>>> >>>>> dum(i) = 1.-vx(i,1,1,1) >>>>> >>>>> enddo >>>>> >>>>> tot_deficit = glsc2(dum,bm1,n) >>>>> >>>>> xmin = glmin(xm1,n) >>>>> >>>>> xmax = glmax(xm1,n) >>>>> >>>>> delta_star = tot_deficit/(xmax-xmin) >>>>> >>>>> psimin = glmin(psi,n) >>>>> >>>>> psimax = glmax(psi,n) >>>>> >>>>> if (nid.eq.0) write(6,1) istep,time,delta_star,psimin,psimax >>>>> >>>>> 1 format(i8,1p4e13.5,' blasius: delta*') >>>>> >>>>> return >>>>> >>>>> end >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Fri Jul 13 09:17:55 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 14:17:55 +0000 Subject: [Nek5000-users] Getting Error when compiling a large problem Message-ID: Dear Nek Users, I need to generate a rectangular grid with 17,310,888 elements. However, when I am changing MAXNEL in the maketools and recompiling, I am getting error. I am attaching the compilation output and my maketools file here. Could you please help me regarding that? Compilation works fine for MAXNEL=4,000,000. Thanks in advance for your help. With best regards, Ambrish ------------------------------------------------------ Ambrish Pandey Post Doctoral Researcher Institut f?r Thermo- und Fluiddynamik Technische Universit?t Ilmenau Ilmenau 98693 Germany Phone: +49 3677 69-2424 Emails: ambrish.pandey at tu-ilmenau.de ambrishiitk at gmail.com ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compile_output Type: application/octet-stream Size: 227640 bytes Desc: compile_output URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: maketools Type: application/octet-stream Size: 3627 bytes Desc: maketools URL: From nek5000-users at lists.mcs.anl.gov Fri Jul 13 10:04:25 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 15:04:25 +0000 Subject: [Nek5000-users] Getting an error when compiling makenek In-Reply-To: References: Message-ID: What version of gfortran is this? The problem seems to be solved when I am using intel compilers, i.e., setting icc and ifort in maketools. Thanks. With best regards, Ambrish ________________________________ From: Pandey Ambrish TU Ilmenau Sent: Wednesday, July 11, 2018 4:39:40 PM To: nek5000-users at lists.mcs.anl.gov Subject: Getting an error when compiling makenek Dear Nek Users, I am trying to compile new Nek5000 on SuperMUC but getting an error when compiling makenek. A few initial lines of the error are: gfortran: unrecognized option '-cpp' Warning: genmap.f:57: Illegal preprocessor directive Warning: genmap.f:190: Illegal preprocessor directive Warning: genmap.f:356: Illegal preprocessor directive Warning: genmap.f:1349: Illegal preprocessor directive Warning: genmap.f:1491: Illegal preprocessor directive Warning: genmap.f:1648: Illegal preprocessor directive Warning: genmap.f:1949: Illegal preprocessor directive Warning: genmap.f:3064: Illegal preprocessor directive Warning: genmap.f:3101: Illegal preprocessor directive Warning: genmap.f:3158: Illegal preprocessor directive Warning: genmap.f:3921: Illegal preprocessor directive I am attaching the detailed error output with this mail. Could you please suggest a solution to this problem? I want to use both the svn and new version of the code. Thanks. With best regards, Ambrish ------------------------------------------------------ Ambrish Pandey Post Doctoral Researcher Institut f?r Thermo- und Fluiddynamik Technische Universit?t Ilmenau Ilmenau 98693 Germany Phone: +49 3677 69-2424 Emails: ambrish.pandey at tu-ilmenau.de ambrishiitk at gmail.com ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jul 13 10:14:52 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 20:44:52 +0530 Subject: [Nek5000-users] Regarding generation of circular mesh using genbox Message-ID: Hello everyone, My aim is to obtain a circular mesh with radius equal to 50.0 and centered at (0,0). I used the following in my input.genbox file : input.rea 2 2 0.0 0.0 xctr yctr -100 -50 nel_r, nel_theta 0.0 50.0 1.0 r0 rn ratio 0.0 360.0 1.0 @0 @n ratio v ,O Velocity BC's (here, only at r0 and rn) By this specification, i think we need to provide BC's at the point (0,0) and at the circular ring of radius 50. I want to specify ux=uy=0 at origin and outflow bc at the periphery of the circle. I get the following in the box.tmp file : v ,O Velocity BC's (here, only at r0 and rn) My userbc subroutine is as follows : subroutine userbc (ix,iy,iz,iside,ieg) include 'SIZE' include 'TOTAL' include 'NEKUSE' ux=0.0 uy=0.0 uz=0.0 temp=0. return end My code runs into an error (screenshot is attachted). Can somebody point out where is the issue. Thanks. Rohan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2018-07-13 20-35-35.png Type: image/png Size: 247574 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Fri Jul 13 10:18:31 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 15:18:31 +0000 Subject: [Nek5000-users] Getting Error when compiling a large problem In-Reply-To: References: Message-ID: Dear Ambrish, What polynomial order are you using? How many processors? This seems like a very large number of elements (a record number). What resolution, in terms of grid points, are you targeting. Best, Paul ________________________________ From: Nek5000-users on behalf of nek5000-users at lists.mcs.anl.gov Sent: Friday, July 13, 2018 9:17:55 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Getting Error when compiling a large problem Dear Nek Users, I need to generate a rectangular grid with 17,310,888 elements. However, when I am changing MAXNEL in the maketools and recompiling, I am getting error. I am attaching the compilation output and my maketools file here. Could you please help me regarding that? Compilation works fine for MAXNEL=4,000,000. Thanks in advance for your help. With best regards, Ambrish ------------------------------------------------------ Ambrish Pandey Post Doctoral Researcher Institut f?r Thermo- und Fluiddynamik Technische Universit?t Ilmenau Ilmenau 98693 Germany Phone: +49 3677 69-2424 Emails: ambrish.pandey at tu-ilmenau.de ambrishiitk at gmail.com ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jul 13 10:54:27 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 17:54:27 +0200 Subject: [Nek5000-users] Getting Error when compiling a large problem In-Reply-To: References: Message-ID: What tools failed? I guess prenek and postnek?? On 13 Jul 2018, at 17:19, "nek5000-users at lists.mcs.anl.gov " > wrote: Dear Ambrish, What polynomial order are you using? How many processors? This seems like a very large number of elements (a record number). What resolution, in terms of grid points, are you targeting. Best, Paul -------------------------------- From: Nek5000-users > on behalf of nek5000-users at lists.mcs.anl.gov > Sent: Friday, July 13, 2018 9:17:55 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Getting Error when compiling a large problem ?Dear Nek Users, I need to generate a rectangular grid with 17,310,888 elements. However, when I am changing MAXNEL in the maketools and recompiling, I am getting error. I am attaching the compilation output and my maketools file here. Could you please help me regarding that? Compilation works fine for MAXNEL=4,000,000. Thanks in advance for your help. With best regards, Ambrish ------------------------------------------------------ Ambrish Pandey Post Doctoral Researcher Institut f?r Thermo- und Fluiddynamik Technische Universit?t Ilmenau Ilmenau 98693 Germany Phone: +49 3677 69-2424 Emails: ambrish.pandey at tu-ilmenau.de ambrishiitk at gmail.com ------------------------------------------------------ _______________________________________________ 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 Jul 13 10:55:56 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 17:55:56 +0200 Subject: [Nek5000-users] Getting an error when compiling makenek In-Reply-To: References: Message-ID: I think it also works with newer gcc (>4.x) versions. On 13 Jul 2018, at 17:10, "nek5000-users at lists.mcs.anl.gov " > wrote: What version of gfortran is this? The problem seems to be solved when I am using intel compilers, i.e., setting icc and ifort in maketools. Thanks. With best regards, Ambrish -------------------------------- From: Pandey Ambrish TU Ilmenau Sent: Wednesday, July 11, 2018 4:39:40 PM To: nek5000-users at lists.mcs.anl.gov Subject: Getting an error when compiling makenek ?Dear Nek Users, I am trying to compile new Nek5000 on SuperMUC but getting an error when compiling makenek. A few initial lines of the error are: gfortran: unrecognized option '-cpp' Warning: genmap.f:57: Illegal preprocessor directive Warning: genmap.f:190: Illegal preprocessor directive Warning: genmap.f:356: Illegal preprocessor directive Warning: genmap.f:1349: Illegal preprocessor directive Warning: genmap.f:1491: Illegal preprocessor directive Warning: genmap.f:1648: Illegal preprocessor directive Warning: genmap.f:1949: Illegal preprocessor directive Warning: genmap.f:3064: Illegal preprocessor directive Warning: genmap.f:3101: Illegal preprocessor directive Warning: genmap.f:3158: Illegal preprocessor directive Warning: genmap.f:3921: Illegal preprocessor directive I am attaching the detailed error output with this mail. Could you please suggest a solution to this problem? I want to use both the svn and new version of the code. Thanks. With best regards, Ambrish ------------------------------------------------------ Ambrish Pandey Post Doctoral Researcher Institut f?r Thermo- und Fluiddynamik Technische Universit?t Ilmenau Ilmenau 98693 Germany Phone: +49 3677 69-2424 Emails: ambrish.pandey at tu-ilmenau.de ambrishiitk at gmail.com ------------------------------------------------------ _______________________________________________ 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 Jul 13 12:15:38 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 17:15:38 +0000 Subject: [Nek5000-users] Getting Error when compiling a large problem In-Reply-To: References: Message-ID: Dear Paul, Thanks a lot for your prompt response. I am trying to generate the grid with 642*642*42 elements. And most probably I have to go to lx1 = 10 or 12. So the problem size will be something like 6400*6400*420. I will have to use 32768 or 65536 cores on SuperMUC. I generated this grid with earlier version of Nek (svn), and had to change MAXNEL in genbox and genmap directories. In the new version, it appears that changing MAXNEL in maketools enforces this value everywhere. I am getting error in the postnek. Prenek appears to have compiled. The error is as follows: /usr/app-soft/intel/v2017/bin/ifort -o /usr/wrk/people6/ampa9999/Nek_v17/Nek5000/bin/postx postnek.o postnek2.o postnek3.o postnek5.o postnek6.o tsort.o postnek8.o postnek9.o plot.o getfld.o legend.o userf.o revert.o trap.o animate.o genxyz.o screen.o g3d.o subs.o xinterface.o locglob.o postnek5a.o blas.o xdriver.o scrdmp.o coef.o postnek7.o speclib.o mxm.o byte.o ssyev.o iolib.o -L/usr/lib/X11 -lX11 -lm make[1]: Leaving directory `/usr/wrk/people6/ampa9999/Nek_v17/Nek5000/tools/postnek' ERROR: postnek failed to compile! Dear Ambrish, What polynomial order are you using? How many processors? This seems like a very large number of elements (a record number). What resolution, in terms of grid points, are you targeting. Best, Paul Dear Nek Users, I need to generate a rectangular grid with 17,310,888 elements. However, when I am changing MAXNEL in the maketools and recompiling, I am getting error. I am attaching the compilation output and my maketools file here. Could you please help me regarding that? Compilation works fine for MAXNEL=4,000,000. Thanks in advance for your help. With best regards, Ambrish What tools failed? I guess prenek and postnek?? On 13 Jul 2018, at 17:19, "nek5000-users at lists.mcs.anl.gov " > wrote: -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jul 13 17:29:00 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 13 Jul 2018 22:29:00 +0000 Subject: [Nek5000-users] Getting Error when compiling a large problem In-Reply-To: References: , Message-ID: Dear Ambrish, Postnek will certainly fail -- it is a serial code. You will need to use VisIt (or something comparable) for parallel post-processing. Also, as a matter of course, I strongly recommend starting out with 10^4--10^5 elements and running your simulation at lower Reynolds number to go through all steps of the workflow. Then step up to 10^6. Only after that would I consider > 10^7. As I say, you'll be in record territory at that point and thus completely on your own w.r.t. to support. Only a few of our most experienced users have pushed to that high of resolution. If I were tackling the problem you are attempting I would most definitely take these smaller steps first. They take no time and provide a chance to fully debug the whole process, including forcing conditions, boundary conditions, etc. Since they will run a 100 times faster, it make sense to gain insight in this way. hth, Paul ________________________________ From: Nek5000-users on behalf of nek5000-users at lists.mcs.anl.gov Sent: Friday, July 13, 2018 12:15:38 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Getting Error when compiling a large problem Dear Paul, Thanks a lot for your prompt response. I am trying to generate the grid with 642*642*42 elements. And most probably I have to go to lx1 = 10 or 12. So the problem size will be something like 6400*6400*420. I will have to use 32768 or 65536 cores on SuperMUC. I generated this grid with earlier version of Nek (svn), and had to change MAXNEL in genbox and genmap directories. In the new version, it appears that changing MAXNEL in maketools enforces this value everywhere. I am getting error in the postnek. Prenek appears to have compiled. The error is as follows: /usr/app-soft/intel/v2017/bin/ifort -o /usr/wrk/people6/ampa9999/Nek_v17/Nek5000/bin/postx postnek.o postnek2.o postnek3.o postnek5.o postnek6.o tsort.o postnek8.o postnek9.o plot.o getfld.o legend.o userf.o revert.o trap.o animate.o genxyz.o screen.o g3d.o subs.o xinterface.o locglob.o postnek5a.o blas.o xdriver.o scrdmp.o coef.o postnek7.o speclib.o mxm.o byte.o ssyev.o iolib.o -L/usr/lib/X11 -lX11 -lm make[1]: Leaving directory `/usr/wrk/people6/ampa9999/Nek_v17/Nek5000/tools/postnek' ERROR: postnek failed to compile! Dear Ambrish, What polynomial order are you using? How many processors? This seems like a very large number of elements (a record number). What resolution, in terms of grid points, are you targeting. Best, Paul Dear Nek Users, I need to generate a rectangular grid with 17,310,888 elements. However, when I am changing MAXNEL in the maketools and recompiling, I am getting error. I am attaching the compilation output and my maketools file here. Could you please help me regarding that? Compilation works fine for MAXNEL=4,000,000. Thanks in advance for your help. With best regards, Ambrish What tools failed? I guess prenek and postnek?? On 13 Jul 2018, at 17:19, "nek5000-users at lists.mcs.anl.gov " > wrote: -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jul 16 09:17:20 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 16 Jul 2018 10:17:20 -0400 Subject: [Nek5000-users] Using an external file for forcing in 'ffx' In-Reply-To: References: Message-ID: Hey everyone, Just following up on this question. Could really use some suggestion. Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. On Wed, Jul 11, 2018 at 11:34 AM, Saikat Mukherjee wrote: > Hey All, > > I have been stuck in this problem for a while now but I think it should be > simple and probably you can tell where I am going wrong. > > - So I have a forcing function on a finite difference X-Y grid, which I am > reading in as a text file in the 'userdat2' subroutine. > > - I am then parallelizing it using a previous suggestion by Paul, here is > a snippet of the routine. > > ------------------------------------------------------------ > -------------------------------------------- > > subroutine usrdat2 > > > include 'SIZE' > > include 'TOTAL' > > double precision :: my_array(651) > > integer m > > common /myarray/ my_array > > > parameter (my_array_size=651) > > > real work(my_array_size) > > > > n = my_array_size > > > call rzero(my_array,n) > > call rzero(work,n) > > > if (nid.eq.0) then > > open (unit=49,file='fint41.txt') > > do k = 1,n > > read(49,*) my_array(k) > > enddo > > close(49) > > endif > > > call gop(my_array,work,'+ ',n) ! Sum over all processors > > > return > > end > ------------------------------------------------------------ > --------------------------------------------- > > - Next I am interpolating this forcing function to the GLL grid points in > the userf routine, by a piecewise linear interpolant, here's how, > > ------------------------------------------------------------ > ---------------------------------------------- > > subroutine userf (ix,iy,iz,ieg) > > > include 'SIZE' > > include 'TOTAL' > > include 'NEKUSE' > > EQUIVALENCE (prandtl,param(2)) > > > double precision :: my_array(651) > > double precision :: shaped_array(31,21) > > real new_array(nx1,ny1,nz1,nelv) > > double precision :: xin(21),yin(31) > > double precision :: xn(nx1*ny1*nelv),yn(nx1*ny1*nelv) > > double precision :: fo(nx1*ny1*nelv) > > integer i,j,k,l,p,q > > integer e,eg > > common /myarray/ my_array > > > open(16,file='xin.txt') > > do p=1,21 > > read(16,*) xin(p) > > end do > > close(16) > > > open(12,file='yin.txt') > > do q=1,31 > > read(12,*) yin(q) > > end do > > close(12) > > > shaped_array = reshape(my_array,(/31,21/)) > > > do i=1,nx1*ny1*nelv > > xn(i) = xm1(i,1,1,1) > > yn(i) = ym1(i,1,1,1) > > end do > > call pwl_interp_2d(31,21,yin,xin,shaped_array,nx1*ny1*nelv,yn,xn, > fo) > > new_array=reshape(fo,(/nx1,ny1,nz1,nelv/)) > > > do e=1,nelv > > eg = lglel(e) > > ffx = new_array(ix,iy,iz,eg) > > end do > > > ffy = 0.0 > > ffz = 0.0 > > > return > > end > > > ------------------------------------------------------------ > ------------------------------------------------------------ > --------------- > > This is a test domain I made, with 6 elements. It seems to be working when > I am using only 1 core, i.e., in series. In parallel, it seems to be giving > me a different flowfield. My actual domain has 252 elements which I intend > to parallelize with 48 cores. So would like to ask you how to proceed. I > think I am close but I am slightly confused about part of the code that I > have made red. > > When I am trying this in my actual domain, I get an error, "Segmentation > fault occurred." I think the key here is parallelization and identifying > the elements correctly which I am not sure I am doing right. Thanks for > reading this lengthy email. Will be eager to hear from you. > > Thanks, > Saikat > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jul 16 17:49:52 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 16 Jul 2018 22:49:52 +0000 Subject: [Nek5000-users] LES Application to Natural Circulation Problem Message-ID: Good afternoon Nek5000, Where can I find more information or an example on Nek's LES model and how to properly make use of its capabilities. Am I correct in understanding the method used for solving the periodic hill example uses DNS? I have modified the periodic hill example to make my natural circulation problem and want to use of the LES dynamic Smagorinsky model to reduce the simulation's computational cost. Specifically my questions are, which parameters are needed and what guidelines are to be used when inputting these parameters? extrapolation = OIFS? filtering = none filterWeight = ? filterCutoffRatio = 0.9 vs 0.65 ? ? ? Thanks, Mario -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jul 16 20:12:04 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 16 Jul 2018 21:12:04 -0400 Subject: [Nek5000-users] Turbulent kinetic energy in TurbInflow example Message-ID: Dear Neks, In TurbInflow example there is a usr file for postprocessing where TKE is calculated. It says: ccc avg all the avgturbInflow0.f0* files call auto_averager(fname1) ccc copy uk=vx**2, vk=vy**2, wk=vz**2 call col3(uk,vx,vx,lt) call col3(vk,vy,vy,lt) call col3(wk,vz,vz,lt) ccc avg all the rmsturbInflow0.f0* files call auto_averager(fname2) ccc u'^2,v'^2,w'^2 = rms - avg**2 call sub2(vx,uk,lt) call sub2(vy,vk,lt) call sub2(vz,wk,lt) ccc Average in thex direction call my_x_avg(uk,vx,gs_avg_hndl,nelx,nely,nelz,ifld,rcmask) call my_x_avg(vk,vy,gs_avg_hndl,nelx,nely,nelz,ifld,rcmask) call my_x_avg(wk,vz,gs_avg_hndl,nelx,nely,nelz,ifld,rcmask) ccc TKE = 0.5*(u'^2+v'^2+w'^2) call add4(tk,uk,vk,wk,lt) call cmult(tk,0.5,lt) ccc sqrt uk,vk,wk to get urms, vrms and wrms call vsqrt(uk,lt) call vsqrt(vk,lt) call vsqrt(wk,lt) ccc output urms,vrms and wrms along with the TKE ccc TKE is in temperature field ifto = .true. call outpost(uk,vk,wk,pr,tk,'avx') As far as I know, the sub2 subroutine works like sub2(A,B,lt) A=A+B That means, it saves the sum in the first argument. The code says: call sub2(vx,uk,lt) call sub2(vy,vk,lt) call sub2(vz,wk,lt) Meaning that u'^2,v'^2,w'^2 is being stored in vx, vy, and vz. So should the code say:.. ? call add4(tk,vx,vy,vz,lt) instead of call add4(tk,uk,vk,wk,lt) Or there is something I'm missing? Thank you all. Juan Pablo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jul 17 08:07:16 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 17 Jul 2018 15:07:16 +0200 Subject: [Nek5000-users] LES Application to Natural Circulation Problem Message-ID: Nek5000 implements two regularization methods (filtering = explicit or hpfRT) which you can apply in a DNS _and_ LES context. In the LES context you can think of it like a SGS model stabilizing the under-resolved computation. There is a turbChannel example you can experiment with. Note, we found that classical Smagorinsky cannot challenge the simple use of regularization while filtered/VMS Smagorinsky versions (not avaiable yet) perform similiar. Cheers, Stefan -----Original message----- > From:nek5000-users at lists.mcs.anl.gov > Sent: Tuesday 17th July 2018 0:50 > To: nek5000-users at lists.mcs.anl.gov > Subject: [Nek5000-users] LES Application to Natural Circulation Problem > > Good afternoon Nek5000, > Where can I find more information or an example on Neks LES model and how to properly make use of its capabilities.? Am I correct in understanding the method used for solving the > periodic hill example uses DNS? > I have modified the periodic hill example to make my natural circulation problem and want to use of the LES dynamic Smagorinsky model to reduce the simulations computational cost.? > Specifically my questions are, which parameters are needed and what guidelines are to be used when inputting these parameters?? > extrapolation = OIFS? > filtering = none > filterWeight = ? > filterCutoffRatio = 0.9 vs 0.65 > ? > ? > ? > Thanks, > Mario > _______________________________________________ > 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 Jul 17 10:14:16 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 17 Jul 2018 17:14:16 +0200 (CEST) Subject: [Nek5000-users] Mesh Deformation in 3D Message-ID: Hi Neks, I have come up with a new problem regarding the mesh deformation. I was trying to make a rigid motion near the walls of a 3D cylinder . I took the advantage of ocyl2.usrfile to make that. But I am getting a jacobian error when I am runnning the simulation. I slightly changed the boundary condition part in the ocyl2.usr nface = 2*ndim do e=1,nelv do f=1,nface c Set Dirichlet for mesh velocity on all non-interior boundaries if ( (cbc(f,e,1).ne.'E ' . or. (cbc(f,e,1).ne.'P ' ) ) $ call facev(msk,e,f,z0,nx1,ny1,nz1) c Set inhomogeneous Dirichlet data on cylinder if (cbc(f,e,1).eq.'mv ') then call fcaver(xavg,xm1,e,f) if (xavg.gt.-1.2) call facev(tmp,e,f,m1,nx1,ny1,nz1) endif enddo enddo Since I use a 3D domain the right and left walls are Periodic bcs. So I also added one more condition (in bold letters above) to make the smoothing function. I feel it is correct but it throwing error once it starts running. I made the 3D geometry by using n2to3 on ocyl.rea file and gave PeriodicBoundary conditions. Could you please tell me how to solve this in 3D Thank you Sijo GEORGE -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jul 17 14:39:11 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 17 Jul 2018 21:39:11 +0200 (CEST) Subject: [Nek5000-users] Mesh deformation 3D mathematical doubt Message-ID: Hi Neks, I had made a question before regarding the mesh deformation using Laplace equation here I continue with the same question but in different way. Since I am using Laplace equation (Elliptic equation) to make the blending function, it is necessary to bound the equation with boundary conditions right? But in my case the right walls and left walls should also move according to the velocity of the object. So I think that, the Dirichlet BCs are applied only on the inlet, up, down and outlet. And in homogenous boundary condition should be applied on the right and left walls. It is just a thought from my mind. If I am right, can I apply a mixed boundary condition on this domain to the Laplace equation from the available source code ? Thanks in advance Sijo GEORGE -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jul 18 02:38:45 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 18 Jul 2018 09:38:45 +0200 Subject: [Nek5000-users] Dirichlet-Neumann BC Message-ID: Dear Neks, I have been looking into the different boundary conditions available by default in bdry.f. However, I haven't seen any mixed conditions. I would like to impose a no slip condition and specify the shear stress at the boundary. The boundary is flat and aligned with the mesh. Moreover it seems that shear stress boundary conditions are applicable only to the Pn-Pn-2 formulation. Is there a way I can specify the wall normal streamwise velocity gradient u_y as well ? Best regards, Armand. -- *Armand Shams* Master Thesis Intern D?partement a?rodynamique, a?ro?lasticit?, acoustique MSAT T?l: +33 6 99 51 15 84 ONERA - The French Aerospace Lab - Centre de Meudon 8, rue des Vertugadins - 92190 MEUDON Nous suivre sur : www.onera.fr | Twitter | LinkedIn | Facebook Avertissement/disclaimer https://www.onera.fr/en/emails-terms -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: eekkndejbleadiln.gif Type: image/gif Size: 1041 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Jul 18 04:07:38 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 18 Jul 2018 11:07:38 +0200 Subject: [Nek5000-users] Dirichlet-Neumann BC In-Reply-To: References: Message-ID: Hi, there are so-called traction boundary conditions (or mixed traction-velocity boundary conditions), see the documentation https://nek5000.github.io/NekDoc/theory.html (it is in the section about passive scalars, which is perhaps not ideal). The conditions should work for both PnPn and PnPn-2, but for some cases you need the stress formulation. I am not sure whether Nek is properly catching all impossible (or unimplemented) combinations. There are some Nek examples that use these conditions, so you can get some guidance from there. Hope this helps, Philipp On 2018-07-18 09:38, nek5000-users at lists.mcs.anl.gov wrote: > Dear Neks, > > > I have been looking into the different boundary conditions available by > default in bdry.f. However, I haven't seen any mixed conditions. I would > like to impose a no slip condition and specify the shear stress at the > boundary. The boundary is flat and aligned with the mesh. > > Moreover it seems that shear stress boundary conditions are applicable > only to the Pn-Pn-2 formulation. Is there a way I can specify the wall > normal streamwise velocity gradient u_y as well ? > > > Best regards, > > Armand. > > -- > *Armand Shams* > Master Thesis Intern > D?partement a?rodynamique, a?ro?lasticit?, acoustique > MSAT > T?l: +33 6 99 51 15 84 > > > ONERA?-?The French Aerospace Lab?-?Centre de Meudon > 8, rue des Vertugadins - 92190 MEUDON > > Nous suivre sur : www.onera.fr ?| Twitter > ?| LinkedIn > ?| Facebook > > > > Avertissement/disclaimer https://www.onera.fr/en/emails-terms > > > > > _______________________________________________ > 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 Jul 19 01:25:37 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 19 Jul 2018 11:55:37 +0530 Subject: [Nek5000-users] mesh converter ICEM CFD to NEK5000 Message-ID: Hi Neks, I am trying to convert 2D ICEM CFD mesh to NEK5000. Could you tell me, which is the best way to convert grid? My geometry is a 2D cylinder and 2D ellipse with a rectangular domain for the simulation. -- Alok Mishra Research Scholar Aerospace Department IIT Kanpur -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 19 03:15:49 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 19 Jul 2018 10:15:49 +0200 (CEST) Subject: [Nek5000-users] mesh converter ICEM CFD to NEK5000 In-Reply-To: References: Message-ID: You can use a python script called mshconvert.py which is available in internet. It convert .msh to .rea Remember Periodic bc won't work with it. Sijo De: "nek5000-users" ?: "nek5000-users" Envoy?: Jeudi 19 Juillet 2018 08:25:37 Objet: [Nek5000-users] mesh converter ICEM CFD to NEK5000 Hi Neks, I am trying to convert 2D ICEM CFD mesh to NEK5000. Could you tell me, which is the best way to convert grid? My geometry is a 2D cylinder and 2D ellipse with a rectangular domain for the simulation. -- Alok Mishra Research Scholar Aerospace Department IIT Kanpur _______________________________________________ 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 Jul 19 03:52:24 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 19 Jul 2018 10:52:24 +0200 Subject: [Nek5000-users] mesh converter ICEM CFD to NEK5000 In-Reply-To: References: Message-ID: Please use exo2nek which is distributed with the official release. On 19 Jul 2018, at 10:16, "nek5000-users at lists.mcs.anl.gov " > wrote: You can use a python script called mshconvert.py which is available in internet. It convert .msh to .rea Remember Periodic bc won't work with it. Sijo -------------------------------- De: "nek5000-users" > ?: "nek5000-users" > Envoy?: Jeudi 19 Juillet 2018 08:25:37 Objet: [Nek5000-users] mesh converter ICEM CFD to NEK5000 Hi Neks, I am trying to convert 2D ICEM CFD mesh to NEK5000. Could you tell me, which is the best way to convert grid? My geometry is a 2D cylinder and 2D ellipse with a rectangular domain for the simulation.? -- Alok Mishra Research Scholar? ?Aerospace Department IIT Kanpur _______________________________________________ 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 Jul 19 04:00:08 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 19 Jul 2018 11:00:08 +0200 (CEST) Subject: [Nek5000-users] mesh converter ICEM CFD to NEK5000 In-Reply-To: References: Message-ID: I was facing a boundary condition problem using exo2nek. Did you solve that? Sijo De: "nek5000-users" ?: "nek5000-users" Envoy?: Jeudi 19 Juillet 2018 10:52:24 Objet: Re: [Nek5000-users] mesh converter ICEM CFD to NEK5000 Please use exo2nek which is distributed with the official release. On 19 Jul 2018, at 10:16, " [ mailto:nek5000-users at lists.mcs.anl.gov | nek5000-users at lists.mcs.anl.gov ] " < [ mailto:nek5000-users at lists.mcs.anl.gov | nek5000-users at lists.mcs.anl.gov ] > wrote: You can use a python script called mshconvert.py which is available in internet. It convert .msh to .rea Remember Periodic bc won't work with it. Sijo De: "nek5000-users" < [ mailto:nek5000-users at lists.mcs.anl.gov | nek5000-users at lists.mcs.anl.gov ] > ?: "nek5000-users" < [ mailto:nek5000-users at lists.mcs.anl.gov | nek5000-users at lists.mcs.anl.gov ] > Envoy?: Jeudi 19 Juillet 2018 08:25:37 Objet: [Nek5000-users] mesh converter ICEM CFD to NEK5000 Hi Neks, I am trying to convert 2D ICEM CFD mesh to NEK5000. Could you tell me, which is the best way to convert grid? My geometry is a 2D cylinder and 2D ellipse with a rectangular domain for the simulation. -- Alok Mishra Research Scholar Aerospace Department IIT Kanpur _______________________________________________ Nek5000-users mailing list [ mailto:Nek5000-users at lists.mcs.anl.gov | Nek5000-users at lists.mcs.anl.gov ] [ https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users | https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users ] _______________________________________________ Nek5000-users mailing list [ mailto:Nek5000-users at lists.mcs.anl.gov | Nek5000-users at lists.mcs.anl.gov ] [ https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users | 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 Jul 19 06:51:59 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 19 Jul 2018 13:51:59 +0200 Subject: [Nek5000-users] mesh converter ICEM CFD to NEK5000 In-Reply-To: References: Message-ID: See workaround here: https://github.com/Nek5000/Nek5000/issues/502 -----Original message----- > From:nek5000-users at lists.mcs.anl.gov > Sent: Thursday 19th July 2018 11:01 > To: nek5000-users > Subject: Re: [Nek5000-users] mesh converter ICEM CFD to NEK5000 > > I was facing a boundary condition problem using exo2nek. > > Did you solve that? > > Sijo > > ----------- > De: "nek5000-users" > ?: "nek5000-users" > Envoy?: Jeudi 19 Juillet 2018 10:52:24 > Objet: Re: [Nek5000-users] mesh converter ICEM CFD to NEK5000 > > Please use exo2nek which is distributed with the official release. > > On 19 Jul 2018, at 10:16, "nek5000-users at lists.mcs.anl.gov " > wrote: > > You can use a python script called mshconvert.py which is available in internet. > > It convert .msh to .rea > > Remember Periodic bc won't work with it. > > Sijo > > ----------- > De: "nek5000-users" > > ?: "nek5000-users" > > Envoy?: Jeudi 19 Juillet 2018 08:25:37 > Objet: [Nek5000-users] mesh converter ICEM CFD to NEK5000 > > Hi Neks, > > > I am trying to convert 2D ICEM CFD mesh to NEK5000. Could you tell me, which is the best way to convert grid? My geometry is a 2D cylinder and 2D ellipse with a rectangular domain for the simulation.? > > > > -- > Alok Mishra > Research Scholar? > Aerospace Department IIT Kanpur > > > _______________________________________________ > 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 Sun Jul 22 03:41:22 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 22 Jul 2018 10:41:22 +0200 Subject: [Nek5000-users] mesh converter ICEM CFD to NEK5000 In-Reply-To: References: Message-ID: maybe only relevant to a few: The Python script mshconvert.py might still be interesting to groups that e.g. do not have access to the Exodus export filter in ICEM (like we...). In those cases, mshconvert.py does a good job to go from .msh to .rea (in 2D) and allows reasonably straightforward modification in case needed. 3D extrusion can then be done using n2to3. Philipp On 2018-07-19 13:51, nek5000-users at lists.mcs.anl.gov wrote: > See workaround here: https://github.com/Nek5000/Nek5000/issues/502 > > > -----Original message----- >> From:nek5000-users at lists.mcs.anl.gov >> Sent: Thursday 19th July 2018 11:01 >> To: nek5000-users >> Subject: Re: [Nek5000-users] mesh converter ICEM CFD to NEK5000 >> >> I was facing a boundary condition problem using exo2nek. >> >> Did you solve that? >> >> Sijo >> >> ----------- >> De: "nek5000-users" >> ?: "nek5000-users" >> Envoy?: Jeudi 19 Juillet 2018 10:52:24 >> Objet: Re: [Nek5000-users] mesh converter ICEM CFD to NEK5000 >> >> Please use exo2nek which is distributed with the official release. >> >> On 19 Jul 2018, at 10:16, "nek5000-users at lists.mcs.anl.gov " > wrote: >> >> You can use a python script called mshconvert.py which is available in internet. >> >> It convert .msh to .rea >> >> Remember Periodic bc won't work with it. >> >> Sijo >> >> ----------- >> De: "nek5000-users" > >> ?: "nek5000-users" > >> Envoy?: Jeudi 19 Juillet 2018 08:25:37 >> Objet: [Nek5000-users] mesh converter ICEM CFD to NEK5000 >> >> Hi Neks, >> >> >> I am trying to convert 2D ICEM CFD mesh to NEK5000. Could you tell me, which is the best way to convert grid? My geometry is a 2D cylinder and 2D ellipse with a rectangular domain for the simulation. >> >> >> >> -- >> Alok Mishra >> Research Scholar >> Aerospace Department IIT Kanpur >> >> >> _______________________________________________ >> 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 Jul 23 03:56:10 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 23 Jul 2018 10:56:10 +0200 (CEST) Subject: [Nek5000-users] Run time error Message-ID: Hi Neks, I am facing an error while running the simulation which I never had before. after 5001 time step the CFL number disappears and it gives an error stops running. (It is not CFL blowing. I mean if CFL blows it will show something like CFL : ******* right? In my case it is not like this. The CFL dis appears it is not even showing the CFL letters. ) Also it saves my output files unto there. Any one had the same problem before? Thank you Sijo -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jul 23 03:58:37 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 23 Jul 2018 10:58:37 +0200 Subject: [Nek5000-users] Run time error In-Reply-To: References: Message-ID: can you perhaps post the last 20 or so lines of your output? This appears more like a problem of your system. Did you check potential standard error output? On 2018-07-23 10:56, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > I am facing an error while running the simulation which I never had before. > > after 5001 time step the CFL number disappears and it gives an error > stops running. > > (It is not CFL blowing. I mean if CFL blows it will show something like > CFL : ******* right? In my case it is not like this. The CFL dis appears > it is not even showing the CFL letters. ) Also it saves my output files > unto there. > > > Any one had the same problem before? > > Thank you > > Sijo > > > _______________________________________________ > 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 Jul 23 04:16:18 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 23 Jul 2018 11:16:18 +0200 (CEST) Subject: [Nek5000-users] Run time error In-Reply-To: References: Message-ID: Here is the last 15 time steps, Step 5002, t= 2.5060730E-01, DT= 2.6334630E-05, C= .499 2.9631E+03 6.4746E-01 Solving for fluid 5002 Helmh3 fluid 4 3.2301E-09 2.8687E-03 1.0000E-07 5002 reorthogo: 0 5002 U-PRES gmres 1 9.7902E-07 1.0848E-06 1.0000E-06 1.0687E-02 2.0345E-02 5002 DNORM, DIVEX 0.979017414251552405E-06 0.979017414244615416E-06 5002 Fluid done 2.5061E-01 1.0325E-01 5002 2.50607295376E-01 6.91348098900E-01 2.43521097680E-01 4.47827001220E-01 1dragx 5002 2.50607295376E-01 7.39003317407E-07 9.98073784120E-07 -2.59070466713E-07 1dragy 5002 2.50607295376E-01 -2.89434103178E-07 -2.61006442373E-07 -2.84276608050E-08 1dragz 5002 2.50607295376E-01 1.26466785801E-07 1.23449081749E-07 3.01770405268E-09 1torqx 5002 2.50607295376E-01 4.66210074735E-09 -2.18142386531E-08 2.64763394004E-08 1torqy 5002 2.50607295376E-01 -1.39245119998E-06 -1.37178097352E-06 -2.06702264562E-08 1torqz Step 5003, t= 2.5063363E-01, DT= 2.6334630E-05, C= .499 2.9636E+03 5.0625E-01 Solving for fluid 5003 Helmh3 fluid 4 3.2284E-09 2.8685E-03 1.0000E-07 5003 reorthogo: 0 5003 U-PRES gmres 2 9.9844E-07 1.2476E-06 1.0000E-06 2.1245E-02 4.0459E-02 5003 DNORM, DIVEX 0.998438496961438229E-06 0.998438496995218115E-06 5003 Fluid done 2.5063E-01 1.2349E-01 5003 2.50633630006E-01 6.91343372331E-01 2.43530821430E-01 4.47812550901E-01 1dragx 5003 2.50633630006E-01 1.33883527191E-06 1.59788610149E-06 -2.59050829576E-07 1dragy 5003 2.50633630006E-01 -2.89455853305E-07 -2.61026965361E-07 -2.84288879440E-08 1dragz 5003 2.50633630006E-01 1.26408336357E-07 1.23391016237E-07 3.01732012020E-09 1torqx 5003 2.50633630006E-01 3.68027948823E-09 -2.27921145675E-08 2.64723940558E-08 1torqy 5003 2.50633630006E-01 -1.00290395946E-06 -9.82230311773E-07 -2.06736476910E-08 1torqz Step 5004, t= 2.5065996E-01, DT= 2.6334630E-05, C= .499 2.9641E+03 5.2639E-01 Solving for fluid 5004 Helmh3 fluid 4 3.2288E-09 2.8683E-03 1.0000E-07 5004 reorthogo: 0 5004 U-PRES gmres 6 9.6173E-07 1.2811E-06 1.0000E-06 6.3583E-02 1.2089E-01 5004 DNORM, DIVEX 0.961733547539616817E-06 0.961733547511125381E-06 5004 Fluid done 2.5066E-01 2.0408E-01 5004 2.50659964636E-01 6.91338822904E-01 2.43540719422E-01 4.47798103482E-01 1dragx 5004 2.50659964636E-01 1.24874530961E-06 1.50777140270E-06 -2.59026093090E-07 1dragy 5004 2.50659964636E-01 -2.89465334698E-07 -2.61035223976E-07 -2.84301107230E-08 1dragz 5004 2.50659964636E-01 1.26265232830E-07 1.23248343597E-07 3.01688923232E-09 1torqx 5004 2.50659964636E-01 3.78573331524E-09 -2.26826739824E-08 2.64684072976E-08 1torqy 5004 2.50659964636E-01 -1.06339152264E-06 -1.04271435718E-06 -2.06771654598E-08 1torqz Step 5005, time= 2.50686E-01, DT= 2.633E-05 Solving for fluid 5005 Helmh3 fluid 4 3.2297E-09 2.8681E-03 1.0000E-07 5005 reorthogo: 0 5005 U-PRES gmres 1 9.9687E-07 1.3440E-06 1.0000E-06 1.0692E-02 2.0364E-02 5005 DNORM, DIVEX 0.996871725480759347E-06 0.996871725467780684E-06 5005 Fluid done 2.5069E-01 1.0281E-01 5005 2.50686299266E-01 6.91334194687E-01 2.43550535727E-01 4.47783658960E-01 1dragx 5005 2.50686299266E-01 1.09616851227E-06 1.35517473326E-06 -2.59006220992E-07 1dragy 5005 2.50686299266E-01 -2.89485215237E-07 -2.61053885728E-07 -2.84313295093E-08 1dragz 5005 2.50686299266E-01 1.26237500989E-07 1.23221079188E-07 3.01642180084E-09 1torqx 5005 2.50686299266E-01 3.39617827483E-09 -2.30681746374E-08 2.64643529123E-08 1torqy 5005 2.50686299266E-01 -1.14135276097E-06 -1.12067128456E-06 -2.06814764025E-08 1torqz Step 5006, time= 2.50713E-01, DT= 2.633E-05 Solving for fluid 5006 Helmh3 fluid 4 3.2410E-09 2.8679E-03 1.0000E-07 5006 reorthogo: 0 5006 U-PRES gmres 5 8.8161E-07 2.1599E-06 1.0000E-06 5.2977E-02 1.0074E-01 5006 DNORM, DIVEX 0.881613814330421712E-06 0.881613814311075056E-06 5006 Fluid done 2.5071E-01 1.8287E-01 5006 2.50712633896E-01 6.91329604485E-01 2.43560387135E-01 4.47769217350E-01 1dragx 5006 2.50712633896E-01 1.43777322353E-06 1.69676731276E-06 -2.58994089237E-07 1dragy 5006 2.50712633896E-01 -2.89383022126E-07 -2.60950472113E-07 -2.84325500128E-08 1dragz 5006 2.50712633896E-01 1.27224824060E-07 1.24208987648E-07 3.01583641282E-09 1torqx 5006 2.50712633896E-01 4.44760336876E-09 -2.20126903424E-08 2.64602937112E-08 1torqy 5006 2.50712633896E-01 -9.84677597850E-07 -9.63990647078E-07 -2.06869507719E-08 1torqz Step 5007, time= 2.50739E-01, DT= 2.633E-05 Solving for fluid 5007 Helmh3 fluid 4 3.2591E-09 2.8677E-03 1.0000E-07 5007 reorthogo: 0 5007 U-PRES gmres 18 9.5587E-07 2.2352E-06 1.0000E-06 1.9039E-01 3.6388E-01 5007 DNORM, DIVEX 0.955873119537653350E-06 0.955873119540012972E-06 5007 Fluid done 2.5074E-01 4.4597E-01 5007 2.50738968526E-01 6.91324862597E-01 2.43570083958E-01 4.47754778640E-01 1dragx 5007 2.50738968526E-01 1.20307297002E-06 1.46204641771E-06 -2.58973447692E-07 1dragy 5007 2.50738968526E-01 -2.89417069365E-07 -2.60983294754E-07 -2.84337746105E-08 1dragz 5007 2.50738968526E-01 1.26831695982E-07 1.23816089695E-07 3.01560628701E-09 1torqx 5007 2.50738968526E-01 5.02139157632E-09 -2.14350565571E-08 2.64564481335E-08 1torqy 5007 2.50738968526E-01 -7.82904411358E-07 -7.62214464704E-07 -2.06899466533E-08 1torqz Step 5008, time= 2.50765E-01, DT= 2.633E-05 Solving for fluid 5008 Helmh3 fluid 4 3.2323E-09 2.8676E-03 1.0000E-07 5008 reorthogo: 0 5008 U-PRES gmres 20 9.0835E-07 2.3092E-06 1.0000E-06 2.1137E-01 4.0465E-01 5008 DNORM, DIVEX 0.908352025925184963E-06 0.908352025900079859E-06 5008 Fluid done 2.5077E-01 4.8687E-01 5008 2.50765303155E-01 6.91321406040E-01 2.43581063104E-01 4.47740342936E-01 1dragx 5008 2.50765303155E-01 2.74890528450E-06 3.00786518867E-06 -2.58959904170E-07 1dragy 5008 2.50765303155E-01 -2.89468785686E-07 -2.61033794512E-07 -2.84349911742E-08 1dragz 5008 2.50765303155E-01 1.26559461360E-07 1.23544367051E-07 3.01509430869E-09 1torqx 5008 2.50765303155E-01 3.49653887985E-09 -2.29559476187E-08 2.64524864985E-08 1torqy 5008 2.50765303155E-01 -7.50639979415E-07 -7.29944028055E-07 -2.06959513604E-08 1torqz Step 5009, time= 2.50792E-01, DT= 2.633E-05 Solving for fluid 5009 Helmh3 fluid 4 3.2421E-09 2.8674E-03 1.0000E-07 5009 reorthogo: 0 5009 U-PRES gmres 11 9.8214E-07 1.8725E-06 1.0000E-06 1.1646E-01 2.2180E-01 5009 DNORM, DIVEX 0.982139696736965556E-06 0.982139696702795612E-06 5009 Fluid done 2.5079E-01 3.0396E-01 5009 2.50791637785E-01 6.91315353362E-01 2.43589443294E-01 4.47725910069E-01 1dragx 5009 2.50791637785E-01 2.33682354097E-07 4.92616702902E-07 -2.58934348805E-07 1dragy 5009 2.50791637785E-01 -2.89487372587E-07 -2.61051167514E-07 -2.84362050730E-08 1dragz 5009 2.50791637785E-01 1.26715143423E-07 1.23700456898E-07 3.01468652550E-09 1torqx 5009 2.50791637785E-01 4.22547531068E-09 -2.22232504981E-08 2.64487258088E-08 1torqy 5009 2.50791637785E-01 -1.15647147333E-06 -1.13577307601E-06 -2.06983973201E-08 1torqz Step 5010, time= 2.50818E-01, DT= 2.633E-05 Solving for fluid 5010 Helmh3 fluid 4 3.2557E-09 2.8672E-03 1.0000E-07 5010 reorthogo: 0 5010 U-PRES gmres 11 9.7871E-07 1.4643E-06 1.0000E-06 1.1647E-01 2.2184E-01 5010 DNORM, DIVEX 0.978713374125623103E-06 0.978713374145168176E-06 5010 Fluid done 2.5082E-01 3.0435E-01 5010 2.50817972415E-01 6.91311580633E-01 2.43600100518E-01 4.47711480115E-01 1dragx 5010 2.50817972415E-01 1.59900014887E-07 4.18822790393E-07 -2.58922775507E-07 1dragy 5010 2.50817972415E-01 -2.89375448630E-07 -2.60938030333E-07 -2.84374182969E-08 1dragz 5010 2.50817972415E-01 1.27146994632E-07 1.24132866323E-07 3.01412830971E-09 1torqx 5010 2.50817972415E-01 3.86222016209E-09 -2.25823729936E-08 2.64445931557E-08 1torqy 5010 2.50817972415E-01 -1.75555627025E-06 -1.73485211374E-06 -2.07041565045E-08 1torqz Step 5011, time= 2.50844E-01, DT= 2.633E-05 Solving for fluid 5011 Helmh3 fluid 4 3.2445E-09 2.8670E-03 1.0000E-07 5011 reorthogo: 0 5011 U-PRES gmres 3 9.8584E-07 1.4800E-06 1.0000E-06 3.1853E-02 6.0543E-02 5011 DNORM, DIVEX 0.985840182003174908E-06 0.985840181989730166E-06 5011 Fluid done 2.5084E-01 1.4313E-01 5011 2.50844307045E-01 6.91307006675E-01 2.43609953588E-01 4.47697053087E-01 1dragx 5011 2.50844307045E-01 1.19376086041E-06 1.45267214241E-06 -2.58911282002E-07 1dragy 5011 2.50844307045E-01 -2.89518324212E-07 -2.61079698806E-07 -2.84386254057E-08 1dragz 5011 2.50844307045E-01 1.26538004874E-07 1.23524339762E-07 3.01366511130E-09 1torqx 5011 2.50844307045E-01 3.50102159475E-09 -2.29395957657E-08 2.64406173605E-08 1torqy 5011 2.50844307045E-01 -1.15532190933E-06 -1.13461210583E-06 -2.07098035033E-08 1torqz Step 5012, time= 2.50871E-01, DT= 2.633E-05 Solving for fluid 5012 Helmh3 fluid 4 3.2319E-09 2.8668E-03 1.0000E-07 5012 reorthogo: 0 5012 U-PRES gmres 5 9.5655E-07 1.5593E-06 1.0000E-06 5.3007E-02 1.0077E-01 5012 DNORM, DIVEX 0.956545576069178046E-06 0.956545576089094120E-06 5012 Fluid done 2.5087E-01 1.8317E-01 5012 2.50870641675E-01 6.91302353472E-01 2.43619724517E-01 4.47682628955E-01 1dragx 5012 2.50870641675E-01 9.11226385968E-07 1.17011932510E-06 -2.58892939132E-07 1dragy 5012 2.50870641675E-01 -2.89432479322E-07 -2.60992645110E-07 -2.84398342115E-08 1dragz 5012 2.50870641675E-01 1.27073588160E-07 1.24060305180E-07 3.01328297995E-09 1torqx 5012 2.50870641675E-01 4.82584823477E-09 -2.16110082294E-08 2.64368564641E-08 1torqy 5012 2.50870641675E-01 -1.17588004419E-06 -1.15516521543E-06 -2.07148287560E-08 1torqz Step 5013, time= 2.50897E-01, DT= 2.633E-05 Solving for fluid 5013 Helmh3 fluid 4 3.2287E-09 2.8666E-03 1.0000E-07 5013 reorthogo: 0 5013 U-PRES gmres 2 9.5713E-07 1.2499E-06 1.0000E-06 2.1281E-02 4.0455E-02 5013 DNORM, DIVEX 0.957134034958327482E-06 0.957134034942669443E-06 5013 Fluid done 2.5090E-01 1.2291E-01 5013 2.50896976305E-01 6.91297902394E-01 2.43629694642E-01 4.47668207752E-01 1dragx 5013 2.50896976305E-01 6.14485394545E-07 8.73364124021E-07 -2.58878729476E-07 1dragy 5013 2.50896976305E-01 -2.89427209756E-07 -2.60986168111E-07 -2.84410416450E-08 1dragz 5013 2.50896976305E-01 1.27234413257E-07 1.24221620967E-07 3.01279228989E-09 1torqx 5013 2.50896976305E-01 4.31696301276E-09 -2.21160739899E-08 2.64330370026E-08 1torqy 5013 2.50896976305E-01 -1.42260629409E-06 -1.40188632877E-06 -2.07199653204E-08 1torqz Step 5014, time= 2.50923E-01, DT= 2.633E-05 Solving for fluid 5014 Helmh3 fluid 4 3.2263E-09 2.8664E-03 1.0000E-07 5014 reorthogo: 0 5014 U-PRES gmres 8 9.8677E-07 1.7248E-06 1.0000E-06 8.4772E-02 1.6120E-01 5014 DNORM, DIVEX 0.986772488382639047E-06 0.986772488403645888E-06 5014 Fluid done 2.5092E-01 2.4381E-01 5014 2.50923310934E-01 6.91293384013E-01 2.43639594562E-01 4.47653789451E-01 1dragx 5014 2.50923310934E-01 1.72936300045E-06 1.98822152750E-06 -2.58858527045E-07 1dragy 5014 2.50923310934E-01 -2.89481745085E-07 -2.61039500236E-07 -2.84422448489E-08 1dragz 5014 2.50923310934E-01 1.27107116717E-07 1.24094741942E-07 3.01237477520E-09 1torqx 5014 2.50923310934E-01 3.69583275881E-09 -2.27333237863E-08 2.64291565451E-08 1torqy 5014 2.50923310934E-01 -8.03349762879E-07 -7.82624357654E-07 -2.07254052255E-08 1torqz Step 5015, time= 2.50950E-01, DT= 2.633E-05 Solving for fluid 5015 Helmh3 fluid 4 3.2296E-09 2.8662E-03 1.0000E-07 5015 reorthogo: 0 5015 U-PRES gmres 6 9.0937E-07 1.6936E-06 1.0000E-06 6.3624E-02 1.2093E-01 5015 DNORM, DIVEX 0.909368958162372379E-06 0.909368958244082366E-06 5015 Fluid done 2.5095E-01 2.0366E-01 5015 2.50949645564E-01 6.91288889659E-01 2.43649515583E-01 4.47639374076E-01 1dragx 5015 2.50949645564E-01 2.90375481535E-06 3.16258818400E-06 -2.58833368651E-07 1dragy 5015 2.50949645564E-01 -2.89416582294E-07 -2.60973134708E-07 -2.84434475857E-08 1dragz 5015 2.50949645564E-01 1.27171125092E-07 1.24159210559E-07 3.01191453351E-09 1torqx 5015 2.50949645564E-01 3.80951637878E-09 -2.26155828231E-08 2.64250992019E-08 1torqy 5015 2.50949645564E-01 -7.71080501129E-08 -5.63790769972E-08 -2.07289731157E-08 1torqz Step 5016, time= 2.50976E-01, DT= 2.633E-05 Solving for fluid 5016 Helmh3 fluid 4 3.2378E-09 2.8660E-03 1.0000E-07 5016 reorthogo: 0 5016 U-PRES gmres 2 8.5015E-07 1.3656E-06 1.0000E-06 2.1316E-02 4.0472E-02 5016 DNORM, DIVEX 0.850149772194823341E-06 0.850149772234970797E-06 5016 Fluid done 2.5098E-01 1.2322E-01 5016 2.50975980194E-01 6.91284214594E-01 2.43659253020E-01 4.47624961574E-01 1dragx 5016 2.50975980194E-01 1.87017133482E-06 2.12898116805E-06 -2.58809833233E-07 1dragy 5016 2.50975980194E-01 -2.89458661275E-07 -2.61014009813E-07 -2.84446514627E-08 1dragz 5016 2.50975980194E-01 1.27081549294E-07 1.24070042436E-07 3.01150685798E-09 1torqx 5016 2.50975980194E-01 2.90577561646E-09 -2.35150990040E-08 2.64208746205E-08 1torqy 5016 2.50975980194E-01 -7.33394593524E-07 -7.12661120859E-07 -2.07334726643E-08 1torqz 2018-07-22 09:30:52.570 (WARN ) [0xffef6aa91b0] :497945:ibm.runjob.client.Job: terminated by signal 11 2018-07-22 09:30:52.570 (WARN ) [0xffef6aa91b0] :497945:ibm.runjob.client.Job: abnormal termination by signal 11 from rank 1040 ----- Mail original ----- De: "nek5000-users" ?: "nek5000-users" Envoy?: Lundi 23 Juillet 2018 10:58:37 Objet: Re: [Nek5000-users] Run time error can you perhaps post the last 20 or so lines of your output? This appears more like a problem of your system. Did you check potential standard error output? On 2018-07-23 10:56, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > I am facing an error while running the simulation which I never had before. > > after 5001 time step the CFL number disappears and it gives an error > stops running. > > (It is not CFL blowing. I mean if CFL blows it will show something like > CFL : ******* right? In my case it is not like this. The CFL dis appears > it is not even showing the CFL letters. ) Also it saves my output files > unto there. > > > Any one had the same problem before? > > Thank you > > Sijo > > > _______________________________________________ > 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 Jul 23 04:19:00 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 23 Jul 2018 11:19:00 +0200 Subject: [Nek5000-users] Run time error In-Reply-To: References: Message-ID: well, you get a segfault somewhere at the end of step 5016 or beginning of 5017. I guess you need to debug your code, first identify where it happens and then find a solution. But this is not something that the mailing list can help. On 2018-07-23 11:16, nek5000-users at lists.mcs.anl.gov wrote: > > > Here is the last 15 time steps, > > > > Step 5002, t= 2.5060730E-01, DT= 2.6334630E-05, C= .499 2.9631E+03 6.4746E-01 > Solving for fluid > 5002 Helmh3 fluid 4 3.2301E-09 2.8687E-03 1.0000E-07 > 5002 reorthogo: 0 > 5002 U-PRES gmres 1 9.7902E-07 1.0848E-06 1.0000E-06 1.0687E-02 2.0345E-02 > 5002 DNORM, DIVEX 0.979017414251552405E-06 0.979017414244615416E-06 > 5002 Fluid done 2.5061E-01 1.0325E-01 > 5002 2.50607295376E-01 6.91348098900E-01 2.43521097680E-01 4.47827001220E-01 1dragx > 5002 2.50607295376E-01 7.39003317407E-07 9.98073784120E-07 -2.59070466713E-07 1dragy > 5002 2.50607295376E-01 -2.89434103178E-07 -2.61006442373E-07 -2.84276608050E-08 1dragz > 5002 2.50607295376E-01 1.26466785801E-07 1.23449081749E-07 3.01770405268E-09 1torqx > 5002 2.50607295376E-01 4.66210074735E-09 -2.18142386531E-08 2.64763394004E-08 1torqy > 5002 2.50607295376E-01 -1.39245119998E-06 -1.37178097352E-06 -2.06702264562E-08 1torqz > Step 5003, t= 2.5063363E-01, DT= 2.6334630E-05, C= .499 2.9636E+03 5.0625E-01 > Solving for fluid > 5003 Helmh3 fluid 4 3.2284E-09 2.8685E-03 1.0000E-07 > 5003 reorthogo: 0 > 5003 U-PRES gmres 2 9.9844E-07 1.2476E-06 1.0000E-06 2.1245E-02 4.0459E-02 > 5003 DNORM, DIVEX 0.998438496961438229E-06 0.998438496995218115E-06 > 5003 Fluid done 2.5063E-01 1.2349E-01 > 5003 2.50633630006E-01 6.91343372331E-01 2.43530821430E-01 4.47812550901E-01 1dragx > 5003 2.50633630006E-01 1.33883527191E-06 1.59788610149E-06 -2.59050829576E-07 1dragy > 5003 2.50633630006E-01 -2.89455853305E-07 -2.61026965361E-07 -2.84288879440E-08 1dragz > 5003 2.50633630006E-01 1.26408336357E-07 1.23391016237E-07 3.01732012020E-09 1torqx > 5003 2.50633630006E-01 3.68027948823E-09 -2.27921145675E-08 2.64723940558E-08 1torqy > 5003 2.50633630006E-01 -1.00290395946E-06 -9.82230311773E-07 -2.06736476910E-08 1torqz > Step 5004, t= 2.5065996E-01, DT= 2.6334630E-05, C= .499 2.9641E+03 5.2639E-01 > Solving for fluid > 5004 Helmh3 fluid 4 3.2288E-09 2.8683E-03 1.0000E-07 > 5004 reorthogo: 0 > 5004 U-PRES gmres 6 9.6173E-07 1.2811E-06 1.0000E-06 6.3583E-02 1.2089E-01 > 5004 DNORM, DIVEX 0.961733547539616817E-06 0.961733547511125381E-06 > 5004 Fluid done 2.5066E-01 2.0408E-01 > 5004 2.50659964636E-01 6.91338822904E-01 2.43540719422E-01 4.47798103482E-01 1dragx > 5004 2.50659964636E-01 1.24874530961E-06 1.50777140270E-06 -2.59026093090E-07 1dragy > 5004 2.50659964636E-01 -2.89465334698E-07 -2.61035223976E-07 -2.84301107230E-08 1dragz > 5004 2.50659964636E-01 1.26265232830E-07 1.23248343597E-07 3.01688923232E-09 1torqx > 5004 2.50659964636E-01 3.78573331524E-09 -2.26826739824E-08 2.64684072976E-08 1torqy > 5004 2.50659964636E-01 -1.06339152264E-06 -1.04271435718E-06 -2.06771654598E-08 1torqz > Step 5005, time= 2.50686E-01, DT= 2.633E-05 > Solving for fluid > 5005 Helmh3 fluid 4 3.2297E-09 2.8681E-03 1.0000E-07 > 5005 reorthogo: 0 > 5005 U-PRES gmres 1 9.9687E-07 1.3440E-06 1.0000E-06 1.0692E-02 2.0364E-02 > 5005 DNORM, DIVEX 0.996871725480759347E-06 0.996871725467780684E-06 > 5005 Fluid done 2.5069E-01 1.0281E-01 > 5005 2.50686299266E-01 6.91334194687E-01 2.43550535727E-01 4.47783658960E-01 1dragx > 5005 2.50686299266E-01 1.09616851227E-06 1.35517473326E-06 -2.59006220992E-07 1dragy > 5005 2.50686299266E-01 -2.89485215237E-07 -2.61053885728E-07 -2.84313295093E-08 1dragz > 5005 2.50686299266E-01 1.26237500989E-07 1.23221079188E-07 3.01642180084E-09 1torqx > 5005 2.50686299266E-01 3.39617827483E-09 -2.30681746374E-08 2.64643529123E-08 1torqy > 5005 2.50686299266E-01 -1.14135276097E-06 -1.12067128456E-06 -2.06814764025E-08 1torqz > Step 5006, time= 2.50713E-01, DT= 2.633E-05 > Solving for fluid > 5006 Helmh3 fluid 4 3.2410E-09 2.8679E-03 1.0000E-07 > 5006 reorthogo: 0 > 5006 U-PRES gmres 5 8.8161E-07 2.1599E-06 1.0000E-06 5.2977E-02 1.0074E-01 > 5006 DNORM, DIVEX 0.881613814330421712E-06 0.881613814311075056E-06 > 5006 Fluid done 2.5071E-01 1.8287E-01 > 5006 2.50712633896E-01 6.91329604485E-01 2.43560387135E-01 4.47769217350E-01 1dragx > 5006 2.50712633896E-01 1.43777322353E-06 1.69676731276E-06 -2.58994089237E-07 1dragy > 5006 2.50712633896E-01 -2.89383022126E-07 -2.60950472113E-07 -2.84325500128E-08 1dragz > 5006 2.50712633896E-01 1.27224824060E-07 1.24208987648E-07 3.01583641282E-09 1torqx > 5006 2.50712633896E-01 4.44760336876E-09 -2.20126903424E-08 2.64602937112E-08 1torqy > 5006 2.50712633896E-01 -9.84677597850E-07 -9.63990647078E-07 -2.06869507719E-08 1torqz > Step 5007, time= 2.50739E-01, DT= 2.633E-05 > Solving for fluid > 5007 Helmh3 fluid 4 3.2591E-09 2.8677E-03 1.0000E-07 > 5007 reorthogo: 0 > 5007 U-PRES gmres 18 9.5587E-07 2.2352E-06 1.0000E-06 1.9039E-01 3.6388E-01 > 5007 DNORM, DIVEX 0.955873119537653350E-06 0.955873119540012972E-06 > 5007 Fluid done 2.5074E-01 4.4597E-01 > 5007 2.50738968526E-01 6.91324862597E-01 2.43570083958E-01 4.47754778640E-01 1dragx > 5007 2.50738968526E-01 1.20307297002E-06 1.46204641771E-06 -2.58973447692E-07 1dragy > 5007 2.50738968526E-01 -2.89417069365E-07 -2.60983294754E-07 -2.84337746105E-08 1dragz > 5007 2.50738968526E-01 1.26831695982E-07 1.23816089695E-07 3.01560628701E-09 1torqx > 5007 2.50738968526E-01 5.02139157632E-09 -2.14350565571E-08 2.64564481335E-08 1torqy > 5007 2.50738968526E-01 -7.82904411358E-07 -7.62214464704E-07 -2.06899466533E-08 1torqz > Step 5008, time= 2.50765E-01, DT= 2.633E-05 > Solving for fluid > 5008 Helmh3 fluid 4 3.2323E-09 2.8676E-03 1.0000E-07 > 5008 reorthogo: 0 > 5008 U-PRES gmres 20 9.0835E-07 2.3092E-06 1.0000E-06 2.1137E-01 4.0465E-01 > 5008 DNORM, DIVEX 0.908352025925184963E-06 0.908352025900079859E-06 > 5008 Fluid done 2.5077E-01 4.8687E-01 > 5008 2.50765303155E-01 6.91321406040E-01 2.43581063104E-01 4.47740342936E-01 1dragx > 5008 2.50765303155E-01 2.74890528450E-06 3.00786518867E-06 -2.58959904170E-07 1dragy > 5008 2.50765303155E-01 -2.89468785686E-07 -2.61033794512E-07 -2.84349911742E-08 1dragz > 5008 2.50765303155E-01 1.26559461360E-07 1.23544367051E-07 3.01509430869E-09 1torqx > 5008 2.50765303155E-01 3.49653887985E-09 -2.29559476187E-08 2.64524864985E-08 1torqy > 5008 2.50765303155E-01 -7.50639979415E-07 -7.29944028055E-07 -2.06959513604E-08 1torqz > Step 5009, time= 2.50792E-01, DT= 2.633E-05 > Solving for fluid > 5009 Helmh3 fluid 4 3.2421E-09 2.8674E-03 1.0000E-07 > 5009 reorthogo: 0 > 5009 U-PRES gmres 11 9.8214E-07 1.8725E-06 1.0000E-06 1.1646E-01 2.2180E-01 > 5009 DNORM, DIVEX 0.982139696736965556E-06 0.982139696702795612E-06 > 5009 Fluid done 2.5079E-01 3.0396E-01 > 5009 2.50791637785E-01 6.91315353362E-01 2.43589443294E-01 4.47725910069E-01 1dragx > 5009 2.50791637785E-01 2.33682354097E-07 4.92616702902E-07 -2.58934348805E-07 1dragy > 5009 2.50791637785E-01 -2.89487372587E-07 -2.61051167514E-07 -2.84362050730E-08 1dragz > 5009 2.50791637785E-01 1.26715143423E-07 1.23700456898E-07 3.01468652550E-09 1torqx > 5009 2.50791637785E-01 4.22547531068E-09 -2.22232504981E-08 2.64487258088E-08 1torqy > 5009 2.50791637785E-01 -1.15647147333E-06 -1.13577307601E-06 -2.06983973201E-08 1torqz > Step 5010, time= 2.50818E-01, DT= 2.633E-05 > Solving for fluid > 5010 Helmh3 fluid 4 3.2557E-09 2.8672E-03 1.0000E-07 > 5010 reorthogo: 0 > 5010 U-PRES gmres 11 9.7871E-07 1.4643E-06 1.0000E-06 1.1647E-01 2.2184E-01 > 5010 DNORM, DIVEX 0.978713374125623103E-06 0.978713374145168176E-06 > 5010 Fluid done 2.5082E-01 3.0435E-01 > 5010 2.50817972415E-01 6.91311580633E-01 2.43600100518E-01 4.47711480115E-01 1dragx > 5010 2.50817972415E-01 1.59900014887E-07 4.18822790393E-07 -2.58922775507E-07 1dragy > 5010 2.50817972415E-01 -2.89375448630E-07 -2.60938030333E-07 -2.84374182969E-08 1dragz > 5010 2.50817972415E-01 1.27146994632E-07 1.24132866323E-07 3.01412830971E-09 1torqx > 5010 2.50817972415E-01 3.86222016209E-09 -2.25823729936E-08 2.64445931557E-08 1torqy > 5010 2.50817972415E-01 -1.75555627025E-06 -1.73485211374E-06 -2.07041565045E-08 1torqz > Step 5011, time= 2.50844E-01, DT= 2.633E-05 > Solving for fluid > 5011 Helmh3 fluid 4 3.2445E-09 2.8670E-03 1.0000E-07 > 5011 reorthogo: 0 > 5011 U-PRES gmres 3 9.8584E-07 1.4800E-06 1.0000E-06 3.1853E-02 6.0543E-02 > 5011 DNORM, DIVEX 0.985840182003174908E-06 0.985840181989730166E-06 > 5011 Fluid done 2.5084E-01 1.4313E-01 > 5011 2.50844307045E-01 6.91307006675E-01 2.43609953588E-01 4.47697053087E-01 1dragx > 5011 2.50844307045E-01 1.19376086041E-06 1.45267214241E-06 -2.58911282002E-07 1dragy > 5011 2.50844307045E-01 -2.89518324212E-07 -2.61079698806E-07 -2.84386254057E-08 1dragz > 5011 2.50844307045E-01 1.26538004874E-07 1.23524339762E-07 3.01366511130E-09 1torqx > 5011 2.50844307045E-01 3.50102159475E-09 -2.29395957657E-08 2.64406173605E-08 1torqy > 5011 2.50844307045E-01 -1.15532190933E-06 -1.13461210583E-06 -2.07098035033E-08 1torqz > Step 5012, time= 2.50871E-01, DT= 2.633E-05 > Solving for fluid > 5012 Helmh3 fluid 4 3.2319E-09 2.8668E-03 1.0000E-07 > 5012 reorthogo: 0 > 5012 U-PRES gmres 5 9.5655E-07 1.5593E-06 1.0000E-06 5.3007E-02 1.0077E-01 > 5012 DNORM, DIVEX 0.956545576069178046E-06 0.956545576089094120E-06 > 5012 Fluid done 2.5087E-01 1.8317E-01 > 5012 2.50870641675E-01 6.91302353472E-01 2.43619724517E-01 4.47682628955E-01 1dragx > 5012 2.50870641675E-01 9.11226385968E-07 1.17011932510E-06 -2.58892939132E-07 1dragy > 5012 2.50870641675E-01 -2.89432479322E-07 -2.60992645110E-07 -2.84398342115E-08 1dragz > 5012 2.50870641675E-01 1.27073588160E-07 1.24060305180E-07 3.01328297995E-09 1torqx > 5012 2.50870641675E-01 4.82584823477E-09 -2.16110082294E-08 2.64368564641E-08 1torqy > 5012 2.50870641675E-01 -1.17588004419E-06 -1.15516521543E-06 -2.07148287560E-08 1torqz > Step 5013, time= 2.50897E-01, DT= 2.633E-05 > Solving for fluid > 5013 Helmh3 fluid 4 3.2287E-09 2.8666E-03 1.0000E-07 > 5013 reorthogo: 0 > 5013 U-PRES gmres 2 9.5713E-07 1.2499E-06 1.0000E-06 2.1281E-02 4.0455E-02 > 5013 DNORM, DIVEX 0.957134034958327482E-06 0.957134034942669443E-06 > 5013 Fluid done 2.5090E-01 1.2291E-01 > 5013 2.50896976305E-01 6.91297902394E-01 2.43629694642E-01 4.47668207752E-01 1dragx > 5013 2.50896976305E-01 6.14485394545E-07 8.73364124021E-07 -2.58878729476E-07 1dragy > 5013 2.50896976305E-01 -2.89427209756E-07 -2.60986168111E-07 -2.84410416450E-08 1dragz > 5013 2.50896976305E-01 1.27234413257E-07 1.24221620967E-07 3.01279228989E-09 1torqx > 5013 2.50896976305E-01 4.31696301276E-09 -2.21160739899E-08 2.64330370026E-08 1torqy > 5013 2.50896976305E-01 -1.42260629409E-06 -1.40188632877E-06 -2.07199653204E-08 1torqz > Step 5014, time= 2.50923E-01, DT= 2.633E-05 > Solving for fluid > 5014 Helmh3 fluid 4 3.2263E-09 2.8664E-03 1.0000E-07 > 5014 reorthogo: 0 > 5014 U-PRES gmres 8 9.8677E-07 1.7248E-06 1.0000E-06 8.4772E-02 1.6120E-01 > 5014 DNORM, DIVEX 0.986772488382639047E-06 0.986772488403645888E-06 > 5014 Fluid done 2.5092E-01 2.4381E-01 > 5014 2.50923310934E-01 6.91293384013E-01 2.43639594562E-01 4.47653789451E-01 1dragx > 5014 2.50923310934E-01 1.72936300045E-06 1.98822152750E-06 -2.58858527045E-07 1dragy > 5014 2.50923310934E-01 -2.89481745085E-07 -2.61039500236E-07 -2.84422448489E-08 1dragz > 5014 2.50923310934E-01 1.27107116717E-07 1.24094741942E-07 3.01237477520E-09 1torqx > 5014 2.50923310934E-01 3.69583275881E-09 -2.27333237863E-08 2.64291565451E-08 1torqy > 5014 2.50923310934E-01 -8.03349762879E-07 -7.82624357654E-07 -2.07254052255E-08 1torqz > Step 5015, time= 2.50950E-01, DT= 2.633E-05 > Solving for fluid > 5015 Helmh3 fluid 4 3.2296E-09 2.8662E-03 1.0000E-07 > 5015 reorthogo: 0 > 5015 U-PRES gmres 6 9.0937E-07 1.6936E-06 1.0000E-06 6.3624E-02 1.2093E-01 > 5015 DNORM, DIVEX 0.909368958162372379E-06 0.909368958244082366E-06 > 5015 Fluid done 2.5095E-01 2.0366E-01 > 5015 2.50949645564E-01 6.91288889659E-01 2.43649515583E-01 4.47639374076E-01 1dragx > 5015 2.50949645564E-01 2.90375481535E-06 3.16258818400E-06 -2.58833368651E-07 1dragy > 5015 2.50949645564E-01 -2.89416582294E-07 -2.60973134708E-07 -2.84434475857E-08 1dragz > 5015 2.50949645564E-01 1.27171125092E-07 1.24159210559E-07 3.01191453351E-09 1torqx > 5015 2.50949645564E-01 3.80951637878E-09 -2.26155828231E-08 2.64250992019E-08 1torqy > 5015 2.50949645564E-01 -7.71080501129E-08 -5.63790769972E-08 -2.07289731157E-08 1torqz > Step 5016, time= 2.50976E-01, DT= 2.633E-05 > Solving for fluid > 5016 Helmh3 fluid 4 3.2378E-09 2.8660E-03 1.0000E-07 > 5016 reorthogo: 0 > 5016 U-PRES gmres 2 8.5015E-07 1.3656E-06 1.0000E-06 2.1316E-02 4.0472E-02 > 5016 DNORM, DIVEX 0.850149772194823341E-06 0.850149772234970797E-06 > 5016 Fluid done 2.5098E-01 1.2322E-01 > 5016 2.50975980194E-01 6.91284214594E-01 2.43659253020E-01 4.47624961574E-01 1dragx > 5016 2.50975980194E-01 1.87017133482E-06 2.12898116805E-06 -2.58809833233E-07 1dragy > 5016 2.50975980194E-01 -2.89458661275E-07 -2.61014009813E-07 -2.84446514627E-08 1dragz > 5016 2.50975980194E-01 1.27081549294E-07 1.24070042436E-07 3.01150685798E-09 1torqx > 5016 2.50975980194E-01 2.90577561646E-09 -2.35150990040E-08 2.64208746205E-08 1torqy > 5016 2.50975980194E-01 -7.33394593524E-07 -7.12661120859E-07 -2.07334726643E-08 1torqz > 2018-07-22 09:30:52.570 (WARN ) [0xffef6aa91b0] :497945:ibm.runjob.client.Job: terminated by signal 11 > 2018-07-22 09:30:52.570 (WARN ) [0xffef6aa91b0] :497945:ibm.runjob.client.Job: abnormal termination by signal 11 from rank 1040 > > ----- Mail original ----- > De: "nek5000-users" > ?: "nek5000-users" > Envoy?: Lundi 23 Juillet 2018 10:58:37 > Objet: Re: [Nek5000-users] Run time error > > can you perhaps post the last 20 or so lines of your output? > > This appears more like a problem of your system. Did you check potential > standard error output? > > On 2018-07-23 10:56, nek5000-users at lists.mcs.anl.gov wrote: >> Hi Neks, >> >> I am facing an error while running the simulation which I never had before. >> >> after 5001 time step the CFL number disappears and it gives an error >> stops running. >> >> (It is not CFL blowing. I mean if CFL blows it will show something like >> CFL : ******* right? In my case it is not like this. The CFL dis appears >> it is not even showing the CFL letters. ) Also it saves my output files >> unto there. >> >> >> Any one had the same problem before? >> >> Thank you >> >> Sijo >> >> >> _______________________________________________ >> 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 Jul 23 04:25:18 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 23 Jul 2018 11:25:18 +0200 (CEST) Subject: [Nek5000-users] Run time error In-Reply-To: References: Message-ID: Thank you very much. I found the problem and I hope it should work. Thanks for the help. ----- Mail original ----- De: "nek5000-users" ?: "nek5000-users" Envoy?: Lundi 23 Juillet 2018 11:19:00 Objet: Re: [Nek5000-users] Run time error well, you get a segfault somewhere at the end of step 5016 or beginning of 5017. I guess you need to debug your code, first identify where it happens and then find a solution. But this is not something that the mailing list can help. On 2018-07-23 11:16, nek5000-users at lists.mcs.anl.gov wrote: > > > Here is the last 15 time steps, > > > > Step 5002, t= 2.5060730E-01, DT= 2.6334630E-05, C= .499 2.9631E+03 6.4746E-01 > Solving for fluid > 5002 Helmh3 fluid 4 3.2301E-09 2.8687E-03 1.0000E-07 > 5002 reorthogo: 0 > 5002 U-PRES gmres 1 9.7902E-07 1.0848E-06 1.0000E-06 1.0687E-02 2.0345E-02 > 5002 DNORM, DIVEX 0.979017414251552405E-06 0.979017414244615416E-06 > 5002 Fluid done 2.5061E-01 1.0325E-01 > 5002 2.50607295376E-01 6.91348098900E-01 2.43521097680E-01 4.47827001220E-01 1dragx > 5002 2.50607295376E-01 7.39003317407E-07 9.98073784120E-07 -2.59070466713E-07 1dragy > 5002 2.50607295376E-01 -2.89434103178E-07 -2.61006442373E-07 -2.84276608050E-08 1dragz > 5002 2.50607295376E-01 1.26466785801E-07 1.23449081749E-07 3.01770405268E-09 1torqx > 5002 2.50607295376E-01 4.66210074735E-09 -2.18142386531E-08 2.64763394004E-08 1torqy > 5002 2.50607295376E-01 -1.39245119998E-06 -1.37178097352E-06 -2.06702264562E-08 1torqz > Step 5003, t= 2.5063363E-01, DT= 2.6334630E-05, C= .499 2.9636E+03 5.0625E-01 > Solving for fluid > 5003 Helmh3 fluid 4 3.2284E-09 2.8685E-03 1.0000E-07 > 5003 reorthogo: 0 > 5003 U-PRES gmres 2 9.9844E-07 1.2476E-06 1.0000E-06 2.1245E-02 4.0459E-02 > 5003 DNORM, DIVEX 0.998438496961438229E-06 0.998438496995218115E-06 > 5003 Fluid done 2.5063E-01 1.2349E-01 > 5003 2.50633630006E-01 6.91343372331E-01 2.43530821430E-01 4.47812550901E-01 1dragx > 5003 2.50633630006E-01 1.33883527191E-06 1.59788610149E-06 -2.59050829576E-07 1dragy > 5003 2.50633630006E-01 -2.89455853305E-07 -2.61026965361E-07 -2.84288879440E-08 1dragz > 5003 2.50633630006E-01 1.26408336357E-07 1.23391016237E-07 3.01732012020E-09 1torqx > 5003 2.50633630006E-01 3.68027948823E-09 -2.27921145675E-08 2.64723940558E-08 1torqy > 5003 2.50633630006E-01 -1.00290395946E-06 -9.82230311773E-07 -2.06736476910E-08 1torqz > Step 5004, t= 2.5065996E-01, DT= 2.6334630E-05, C= .499 2.9641E+03 5.2639E-01 > Solving for fluid > 5004 Helmh3 fluid 4 3.2288E-09 2.8683E-03 1.0000E-07 > 5004 reorthogo: 0 > 5004 U-PRES gmres 6 9.6173E-07 1.2811E-06 1.0000E-06 6.3583E-02 1.2089E-01 > 5004 DNORM, DIVEX 0.961733547539616817E-06 0.961733547511125381E-06 > 5004 Fluid done 2.5066E-01 2.0408E-01 > 5004 2.50659964636E-01 6.91338822904E-01 2.43540719422E-01 4.47798103482E-01 1dragx > 5004 2.50659964636E-01 1.24874530961E-06 1.50777140270E-06 -2.59026093090E-07 1dragy > 5004 2.50659964636E-01 -2.89465334698E-07 -2.61035223976E-07 -2.84301107230E-08 1dragz > 5004 2.50659964636E-01 1.26265232830E-07 1.23248343597E-07 3.01688923232E-09 1torqx > 5004 2.50659964636E-01 3.78573331524E-09 -2.26826739824E-08 2.64684072976E-08 1torqy > 5004 2.50659964636E-01 -1.06339152264E-06 -1.04271435718E-06 -2.06771654598E-08 1torqz > Step 5005, time= 2.50686E-01, DT= 2.633E-05 > Solving for fluid > 5005 Helmh3 fluid 4 3.2297E-09 2.8681E-03 1.0000E-07 > 5005 reorthogo: 0 > 5005 U-PRES gmres 1 9.9687E-07 1.3440E-06 1.0000E-06 1.0692E-02 2.0364E-02 > 5005 DNORM, DIVEX 0.996871725480759347E-06 0.996871725467780684E-06 > 5005 Fluid done 2.5069E-01 1.0281E-01 > 5005 2.50686299266E-01 6.91334194687E-01 2.43550535727E-01 4.47783658960E-01 1dragx > 5005 2.50686299266E-01 1.09616851227E-06 1.35517473326E-06 -2.59006220992E-07 1dragy > 5005 2.50686299266E-01 -2.89485215237E-07 -2.61053885728E-07 -2.84313295093E-08 1dragz > 5005 2.50686299266E-01 1.26237500989E-07 1.23221079188E-07 3.01642180084E-09 1torqx > 5005 2.50686299266E-01 3.39617827483E-09 -2.30681746374E-08 2.64643529123E-08 1torqy > 5005 2.50686299266E-01 -1.14135276097E-06 -1.12067128456E-06 -2.06814764025E-08 1torqz > Step 5006, time= 2.50713E-01, DT= 2.633E-05 > Solving for fluid > 5006 Helmh3 fluid 4 3.2410E-09 2.8679E-03 1.0000E-07 > 5006 reorthogo: 0 > 5006 U-PRES gmres 5 8.8161E-07 2.1599E-06 1.0000E-06 5.2977E-02 1.0074E-01 > 5006 DNORM, DIVEX 0.881613814330421712E-06 0.881613814311075056E-06 > 5006 Fluid done 2.5071E-01 1.8287E-01 > 5006 2.50712633896E-01 6.91329604485E-01 2.43560387135E-01 4.47769217350E-01 1dragx > 5006 2.50712633896E-01 1.43777322353E-06 1.69676731276E-06 -2.58994089237E-07 1dragy > 5006 2.50712633896E-01 -2.89383022126E-07 -2.60950472113E-07 -2.84325500128E-08 1dragz > 5006 2.50712633896E-01 1.27224824060E-07 1.24208987648E-07 3.01583641282E-09 1torqx > 5006 2.50712633896E-01 4.44760336876E-09 -2.20126903424E-08 2.64602937112E-08 1torqy > 5006 2.50712633896E-01 -9.84677597850E-07 -9.63990647078E-07 -2.06869507719E-08 1torqz > Step 5007, time= 2.50739E-01, DT= 2.633E-05 > Solving for fluid > 5007 Helmh3 fluid 4 3.2591E-09 2.8677E-03 1.0000E-07 > 5007 reorthogo: 0 > 5007 U-PRES gmres 18 9.5587E-07 2.2352E-06 1.0000E-06 1.9039E-01 3.6388E-01 > 5007 DNORM, DIVEX 0.955873119537653350E-06 0.955873119540012972E-06 > 5007 Fluid done 2.5074E-01 4.4597E-01 > 5007 2.50738968526E-01 6.91324862597E-01 2.43570083958E-01 4.47754778640E-01 1dragx > 5007 2.50738968526E-01 1.20307297002E-06 1.46204641771E-06 -2.58973447692E-07 1dragy > 5007 2.50738968526E-01 -2.89417069365E-07 -2.60983294754E-07 -2.84337746105E-08 1dragz > 5007 2.50738968526E-01 1.26831695982E-07 1.23816089695E-07 3.01560628701E-09 1torqx > 5007 2.50738968526E-01 5.02139157632E-09 -2.14350565571E-08 2.64564481335E-08 1torqy > 5007 2.50738968526E-01 -7.82904411358E-07 -7.62214464704E-07 -2.06899466533E-08 1torqz > Step 5008, time= 2.50765E-01, DT= 2.633E-05 > Solving for fluid > 5008 Helmh3 fluid 4 3.2323E-09 2.8676E-03 1.0000E-07 > 5008 reorthogo: 0 > 5008 U-PRES gmres 20 9.0835E-07 2.3092E-06 1.0000E-06 2.1137E-01 4.0465E-01 > 5008 DNORM, DIVEX 0.908352025925184963E-06 0.908352025900079859E-06 > 5008 Fluid done 2.5077E-01 4.8687E-01 > 5008 2.50765303155E-01 6.91321406040E-01 2.43581063104E-01 4.47740342936E-01 1dragx > 5008 2.50765303155E-01 2.74890528450E-06 3.00786518867E-06 -2.58959904170E-07 1dragy > 5008 2.50765303155E-01 -2.89468785686E-07 -2.61033794512E-07 -2.84349911742E-08 1dragz > 5008 2.50765303155E-01 1.26559461360E-07 1.23544367051E-07 3.01509430869E-09 1torqx > 5008 2.50765303155E-01 3.49653887985E-09 -2.29559476187E-08 2.64524864985E-08 1torqy > 5008 2.50765303155E-01 -7.50639979415E-07 -7.29944028055E-07 -2.06959513604E-08 1torqz > Step 5009, time= 2.50792E-01, DT= 2.633E-05 > Solving for fluid > 5009 Helmh3 fluid 4 3.2421E-09 2.8674E-03 1.0000E-07 > 5009 reorthogo: 0 > 5009 U-PRES gmres 11 9.8214E-07 1.8725E-06 1.0000E-06 1.1646E-01 2.2180E-01 > 5009 DNORM, DIVEX 0.982139696736965556E-06 0.982139696702795612E-06 > 5009 Fluid done 2.5079E-01 3.0396E-01 > 5009 2.50791637785E-01 6.91315353362E-01 2.43589443294E-01 4.47725910069E-01 1dragx > 5009 2.50791637785E-01 2.33682354097E-07 4.92616702902E-07 -2.58934348805E-07 1dragy > 5009 2.50791637785E-01 -2.89487372587E-07 -2.61051167514E-07 -2.84362050730E-08 1dragz > 5009 2.50791637785E-01 1.26715143423E-07 1.23700456898E-07 3.01468652550E-09 1torqx > 5009 2.50791637785E-01 4.22547531068E-09 -2.22232504981E-08 2.64487258088E-08 1torqy > 5009 2.50791637785E-01 -1.15647147333E-06 -1.13577307601E-06 -2.06983973201E-08 1torqz > Step 5010, time= 2.50818E-01, DT= 2.633E-05 > Solving for fluid > 5010 Helmh3 fluid 4 3.2557E-09 2.8672E-03 1.0000E-07 > 5010 reorthogo: 0 > 5010 U-PRES gmres 11 9.7871E-07 1.4643E-06 1.0000E-06 1.1647E-01 2.2184E-01 > 5010 DNORM, DIVEX 0.978713374125623103E-06 0.978713374145168176E-06 > 5010 Fluid done 2.5082E-01 3.0435E-01 > 5010 2.50817972415E-01 6.91311580633E-01 2.43600100518E-01 4.47711480115E-01 1dragx > 5010 2.50817972415E-01 1.59900014887E-07 4.18822790393E-07 -2.58922775507E-07 1dragy > 5010 2.50817972415E-01 -2.89375448630E-07 -2.60938030333E-07 -2.84374182969E-08 1dragz > 5010 2.50817972415E-01 1.27146994632E-07 1.24132866323E-07 3.01412830971E-09 1torqx > 5010 2.50817972415E-01 3.86222016209E-09 -2.25823729936E-08 2.64445931557E-08 1torqy > 5010 2.50817972415E-01 -1.75555627025E-06 -1.73485211374E-06 -2.07041565045E-08 1torqz > Step 5011, time= 2.50844E-01, DT= 2.633E-05 > Solving for fluid > 5011 Helmh3 fluid 4 3.2445E-09 2.8670E-03 1.0000E-07 > 5011 reorthogo: 0 > 5011 U-PRES gmres 3 9.8584E-07 1.4800E-06 1.0000E-06 3.1853E-02 6.0543E-02 > 5011 DNORM, DIVEX 0.985840182003174908E-06 0.985840181989730166E-06 > 5011 Fluid done 2.5084E-01 1.4313E-01 > 5011 2.50844307045E-01 6.91307006675E-01 2.43609953588E-01 4.47697053087E-01 1dragx > 5011 2.50844307045E-01 1.19376086041E-06 1.45267214241E-06 -2.58911282002E-07 1dragy > 5011 2.50844307045E-01 -2.89518324212E-07 -2.61079698806E-07 -2.84386254057E-08 1dragz > 5011 2.50844307045E-01 1.26538004874E-07 1.23524339762E-07 3.01366511130E-09 1torqx > 5011 2.50844307045E-01 3.50102159475E-09 -2.29395957657E-08 2.64406173605E-08 1torqy > 5011 2.50844307045E-01 -1.15532190933E-06 -1.13461210583E-06 -2.07098035033E-08 1torqz > Step 5012, time= 2.50871E-01, DT= 2.633E-05 > Solving for fluid > 5012 Helmh3 fluid 4 3.2319E-09 2.8668E-03 1.0000E-07 > 5012 reorthogo: 0 > 5012 U-PRES gmres 5 9.5655E-07 1.5593E-06 1.0000E-06 5.3007E-02 1.0077E-01 > 5012 DNORM, DIVEX 0.956545576069178046E-06 0.956545576089094120E-06 > 5012 Fluid done 2.5087E-01 1.8317E-01 > 5012 2.50870641675E-01 6.91302353472E-01 2.43619724517E-01 4.47682628955E-01 1dragx > 5012 2.50870641675E-01 9.11226385968E-07 1.17011932510E-06 -2.58892939132E-07 1dragy > 5012 2.50870641675E-01 -2.89432479322E-07 -2.60992645110E-07 -2.84398342115E-08 1dragz > 5012 2.50870641675E-01 1.27073588160E-07 1.24060305180E-07 3.01328297995E-09 1torqx > 5012 2.50870641675E-01 4.82584823477E-09 -2.16110082294E-08 2.64368564641E-08 1torqy > 5012 2.50870641675E-01 -1.17588004419E-06 -1.15516521543E-06 -2.07148287560E-08 1torqz > Step 5013, time= 2.50897E-01, DT= 2.633E-05 > Solving for fluid > 5013 Helmh3 fluid 4 3.2287E-09 2.8666E-03 1.0000E-07 > 5013 reorthogo: 0 > 5013 U-PRES gmres 2 9.5713E-07 1.2499E-06 1.0000E-06 2.1281E-02 4.0455E-02 > 5013 DNORM, DIVEX 0.957134034958327482E-06 0.957134034942669443E-06 > 5013 Fluid done 2.5090E-01 1.2291E-01 > 5013 2.50896976305E-01 6.91297902394E-01 2.43629694642E-01 4.47668207752E-01 1dragx > 5013 2.50896976305E-01 6.14485394545E-07 8.73364124021E-07 -2.58878729476E-07 1dragy > 5013 2.50896976305E-01 -2.89427209756E-07 -2.60986168111E-07 -2.84410416450E-08 1dragz > 5013 2.50896976305E-01 1.27234413257E-07 1.24221620967E-07 3.01279228989E-09 1torqx > 5013 2.50896976305E-01 4.31696301276E-09 -2.21160739899E-08 2.64330370026E-08 1torqy > 5013 2.50896976305E-01 -1.42260629409E-06 -1.40188632877E-06 -2.07199653204E-08 1torqz > Step 5014, time= 2.50923E-01, DT= 2.633E-05 > Solving for fluid > 5014 Helmh3 fluid 4 3.2263E-09 2.8664E-03 1.0000E-07 > 5014 reorthogo: 0 > 5014 U-PRES gmres 8 9.8677E-07 1.7248E-06 1.0000E-06 8.4772E-02 1.6120E-01 > 5014 DNORM, DIVEX 0.986772488382639047E-06 0.986772488403645888E-06 > 5014 Fluid done 2.5092E-01 2.4381E-01 > 5014 2.50923310934E-01 6.91293384013E-01 2.43639594562E-01 4.47653789451E-01 1dragx > 5014 2.50923310934E-01 1.72936300045E-06 1.98822152750E-06 -2.58858527045E-07 1dragy > 5014 2.50923310934E-01 -2.89481745085E-07 -2.61039500236E-07 -2.84422448489E-08 1dragz > 5014 2.50923310934E-01 1.27107116717E-07 1.24094741942E-07 3.01237477520E-09 1torqx > 5014 2.50923310934E-01 3.69583275881E-09 -2.27333237863E-08 2.64291565451E-08 1torqy > 5014 2.50923310934E-01 -8.03349762879E-07 -7.82624357654E-07 -2.07254052255E-08 1torqz > Step 5015, time= 2.50950E-01, DT= 2.633E-05 > Solving for fluid > 5015 Helmh3 fluid 4 3.2296E-09 2.8662E-03 1.0000E-07 > 5015 reorthogo: 0 > 5015 U-PRES gmres 6 9.0937E-07 1.6936E-06 1.0000E-06 6.3624E-02 1.2093E-01 > 5015 DNORM, DIVEX 0.909368958162372379E-06 0.909368958244082366E-06 > 5015 Fluid done 2.5095E-01 2.0366E-01 > 5015 2.50949645564E-01 6.91288889659E-01 2.43649515583E-01 4.47639374076E-01 1dragx > 5015 2.50949645564E-01 2.90375481535E-06 3.16258818400E-06 -2.58833368651E-07 1dragy > 5015 2.50949645564E-01 -2.89416582294E-07 -2.60973134708E-07 -2.84434475857E-08 1dragz > 5015 2.50949645564E-01 1.27171125092E-07 1.24159210559E-07 3.01191453351E-09 1torqx > 5015 2.50949645564E-01 3.80951637878E-09 -2.26155828231E-08 2.64250992019E-08 1torqy > 5015 2.50949645564E-01 -7.71080501129E-08 -5.63790769972E-08 -2.07289731157E-08 1torqz > Step 5016, time= 2.50976E-01, DT= 2.633E-05 > Solving for fluid > 5016 Helmh3 fluid 4 3.2378E-09 2.8660E-03 1.0000E-07 > 5016 reorthogo: 0 > 5016 U-PRES gmres 2 8.5015E-07 1.3656E-06 1.0000E-06 2.1316E-02 4.0472E-02 > 5016 DNORM, DIVEX 0.850149772194823341E-06 0.850149772234970797E-06 > 5016 Fluid done 2.5098E-01 1.2322E-01 > 5016 2.50975980194E-01 6.91284214594E-01 2.43659253020E-01 4.47624961574E-01 1dragx > 5016 2.50975980194E-01 1.87017133482E-06 2.12898116805E-06 -2.58809833233E-07 1dragy > 5016 2.50975980194E-01 -2.89458661275E-07 -2.61014009813E-07 -2.84446514627E-08 1dragz > 5016 2.50975980194E-01 1.27081549294E-07 1.24070042436E-07 3.01150685798E-09 1torqx > 5016 2.50975980194E-01 2.90577561646E-09 -2.35150990040E-08 2.64208746205E-08 1torqy > 5016 2.50975980194E-01 -7.33394593524E-07 -7.12661120859E-07 -2.07334726643E-08 1torqz > 2018-07-22 09:30:52.570 (WARN ) [0xffef6aa91b0] :497945:ibm.runjob.client.Job: terminated by signal 11 > 2018-07-22 09:30:52.570 (WARN ) [0xffef6aa91b0] :497945:ibm.runjob.client.Job: abnormal termination by signal 11 from rank 1040 > > ----- Mail original ----- > De: "nek5000-users" > ?: "nek5000-users" > Envoy?: Lundi 23 Juillet 2018 10:58:37 > Objet: Re: [Nek5000-users] Run time error > > can you perhaps post the last 20 or so lines of your output? > > This appears more like a problem of your system. Did you check potential > standard error output? > > On 2018-07-23 10:56, nek5000-users at lists.mcs.anl.gov wrote: >> Hi Neks, >> >> I am facing an error while running the simulation which I never had before. >> >> after 5001 time step the CFL number disappears and it gives an error >> stops running. >> >> (It is not CFL blowing. I mean if CFL blows it will show something like >> CFL : ******* right? In my case it is not like this. The CFL dis appears >> it is not even showing the CFL letters. ) Also it saves my output files >> unto there. >> >> >> Any one had the same problem before? >> >> Thank you >> >> Sijo >> >> >> _______________________________________________ >> 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 Jul 23 07:16:46 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 23 Jul 2018 14:16:46 +0200 Subject: [Nek5000-users] Dirichlet-Neumann BC In-Reply-To: References: Message-ID: Indeed traction boundary conditions are suitable. However it is unclear which NEKUSE variable I should set. From bdry.f lines 1101 to 1103 : ??????????? V1(IX,IY,IZ) = TRN ??????????? V2(IX,IY,IZ) = TR1 ??????????? V3(IX,IY,IZ) = TR2 it seems that I should set TRN, TR1 and TR2 for (shear horizontal local) 'shl' BC. The end goal here is to compute a friction velocity locally for which loglaw - velocity at the first grid cell is zero. For now whether I set 'shl' or 'SYM' I get the same results. Le 18/07/2018 ? 11:07, nek5000-users at lists.mcs.anl.gov a ?crit?: > Hi, > > there are so-called traction boundary conditions (or mixed > traction-velocity boundary conditions), see the documentation > https://nek5000.github.io/NekDoc/theory.html > (it is in the section about passive scalars, which is perhaps not > ideal). The conditions should work for both PnPn and PnPn-2, but for > some cases you need the stress formulation. I am not sure whether Nek > is properly catching all impossible (or unimplemented) combinations. > > There are some Nek examples that use these conditions, so you can get > some guidance from there. > > Hope this helps, > Philipp > > On 2018-07-18 09:38, nek5000-users at lists.mcs.anl.gov wrote: >> Dear Neks, >> >> >> I have been looking into the different boundary conditions available >> by default in bdry.f. However, I haven't seen any mixed conditions. I >> would like to impose a no slip condition and specify the shear stress >> at the boundary. The boundary is flat and aligned with the mesh. >> >> Moreover it seems that shear stress boundary conditions are >> applicable only to the Pn-Pn-2 formulation. Is there a way I can >> specify the wall normal streamwise velocity gradient u_y as well ? >> >> >> Best regards, >> >> Armand. >> >> -- >> *Armand Shams* >> Master Thesis Intern >> D?partement a?rodynamique, a?ro?lasticit?, acoustique >> MSAT >> T?l: +33 6 99 51 15 84 >> >> >> ONERA?-?The French Aerospace Lab?-?Centre de Meudon >> 8, rue des Vertugadins - 92190 MEUDON >> >> Nous suivre sur : www.onera.fr ?| Twitter >> ?| LinkedIn >> ?| Facebook >> >> >> >> Avertissement/disclaimer https://www.onera.fr/en/emails-terms >> >> >> >> >> _______________________________________________ >> 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 > -- *Armand Shams* Master Thesis Intern D?partement a?rodynamique, a?ro?lasticit?, acoustique MSAT T?l: +33 6 99 51 15 84 ONERA?-?The French Aerospace Lab?-?Centre de Meudon 8, rue des Vertugadins - 92190 MEUDON Nous suivre sur : www.onera.fr ?| Twitter ?| LinkedIn ?| Facebook Avertissement/disclaimer https://www.onera.fr/en/emails-terms -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iokboefaafamohnl.gif Type: image/gif Size: 1041 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon Jul 23 09:57:32 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 23 Jul 2018 10:57:32 -0400 Subject: [Nek5000-users] Using an external file for forcing in 'ffx' In-Reply-To: References: Message-ID: Hello, Following up on this question again. Would appreciate any input. Thanks, Saikat On Mon, Jul 16, 2018 at 10:17 AM, wrote: > Hey everyone, > > Just following up on this question. Could really use some suggestion. > > Thanks, > Saikat > > Saikat Mukherjee, > PhD Student, > Paul Research Group - http://www.me.vt.edu/mpaul/ > Engineering Science and Mechanics, > Virginia Tech. > > On Wed, Jul 11, 2018 at 11:34 AM, Saikat Mukherjee > wrote: > >> Hey All, >> >> I have been stuck in this problem for a while now but I think it should >> be simple and probably you can tell where I am going wrong. >> >> - So I have a forcing function on a finite difference X-Y grid, which I >> am reading in as a text file in the 'userdat2' subroutine. >> >> - I am then parallelizing it using a previous suggestion by Paul, here is >> a snippet of the routine. >> >> ------------------------------------------------------------ >> -------------------------------------------- >> >> subroutine usrdat2 >> >> >> include 'SIZE' >> >> include 'TOTAL' >> >> double precision :: my_array(651) >> >> integer m >> >> common /myarray/ my_array >> >> >> parameter (my_array_size=651) >> >> >> real work(my_array_size) >> >> >> >> n = my_array_size >> >> >> call rzero(my_array,n) >> >> call rzero(work,n) >> >> >> if (nid.eq.0) then >> >> open (unit=49,file='fint41.txt') >> >> do k = 1,n >> >> read(49,*) my_array(k) >> >> enddo >> >> close(49) >> >> endif >> >> >> call gop(my_array,work,'+ ',n) ! Sum over all processors >> >> >> return >> >> end >> ------------------------------------------------------------ >> --------------------------------------------- >> >> - Next I am interpolating this forcing function to the GLL grid points in >> the userf routine, by a piecewise linear interpolant, here's how, >> >> ------------------------------------------------------------ >> ---------------------------------------------- >> >> subroutine userf (ix,iy,iz,ieg) >> >> >> include 'SIZE' >> >> include 'TOTAL' >> >> include 'NEKUSE' >> >> EQUIVALENCE (prandtl,param(2)) >> >> >> double precision :: my_array(651) >> >> double precision :: shaped_array(31,21) >> >> real new_array(nx1,ny1,nz1,nelv) >> >> double precision :: xin(21),yin(31) >> >> double precision :: xn(nx1*ny1*nelv),yn(nx1*ny1*nelv) >> >> double precision :: fo(nx1*ny1*nelv) >> >> integer i,j,k,l,p,q >> >> integer e,eg >> >> common /myarray/ my_array >> >> >> open(16,file='xin.txt') >> >> do p=1,21 >> >> read(16,*) xin(p) >> >> end do >> >> close(16) >> >> >> open(12,file='yin.txt') >> >> do q=1,31 >> >> read(12,*) yin(q) >> >> end do >> >> close(12) >> >> >> shaped_array = reshape(my_array,(/31,21/)) >> >> >> do i=1,nx1*ny1*nelv >> >> xn(i) = xm1(i,1,1,1) >> >> yn(i) = ym1(i,1,1,1) >> >> end do >> >> call pwl_interp_2d(31,21,yin,xin,sh >> aped_array,nx1*ny1*nelv,yn,xn,fo) >> >> new_array=reshape(fo,(/nx1,ny1,nz1,nelv/)) >> >> >> do e=1,nelv >> >> eg = lglel(e) >> >> ffx = new_array(ix,iy,iz,eg) >> >> end do >> >> >> ffy = 0.0 >> >> ffz = 0.0 >> >> >> return >> >> end >> >> >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> --------------- >> >> This is a test domain I made, with 6 elements. It seems to be working >> when I am using only 1 core, i.e., in series. In parallel, it seems to be >> giving me a different flowfield. My actual domain has 252 elements which I >> intend to parallelize with 48 cores. So would like to ask you how to >> proceed. I think I am close but I am slightly confused about part of the >> code that I have made red. >> >> When I am trying this in my actual domain, I get an error, "Segmentation >> fault occurred." I think the key here is parallelization and identifying >> the elements correctly which I am not sure I am doing right. Thanks for >> reading this lengthy email. Will be eager to hear from you. >> >> Thanks, >> Saikat >> >> >> >> >> >> > > _______________________________________________ > 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 Jul 23 14:54:08 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 23 Jul 2018 21:54:08 +0200 Subject: [Nek5000-users] Using an external file for forcing in 'ffx' In-Reply-To: References: Message-ID: Hi, - userdat2 looks ok. Just some comments: use real instead of double precision as we compile with -r8. Then you could define your parameter right in the beginning and just use that one, instead of hardcoded 651. But these are details, it should work, and just read and broadcast your data to all processors. - in userf: again, use real instead. Also, you might read the FD coordinates in userdat2 as well. You can do as you do, but that is most inefficient (reading every time step from every processor). - you do not need to reshape the array, you can just define my_array with the proper size in userf. (my_array(31,21)). In fact, you do not even need that as you can simply pass my_array to pwl_intepr_2d. - the whole interpolation can be done once in the beginning anyway, or do you change the forcing field as a function of time? - you do not need separate fo and new_array (see above) - then the red bit: You have now interpolated your forcing on the gll points. So ffx simply needs to be the entry of this forcing field at the current ix,iy,iz,e. No need for a loop over the (local) elements, and no need for local-to-global mapping. just take the local index iel. Everything is local, as your interpolation was local as well (i.e. only interpolated to those elements that a specific processor had because you used xm1 and ym1. Sorry if I am misunderstanding. It is not easy to debug code without a running case. Hope this helps, philipp On 2018-07-23 16:57, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > Following up on this question again. Would appreciate any input. > > Thanks, > Saikat > > > > On Mon, Jul 16, 2018 at 10:17 AM, > wrote: > > Hey everyone, > > Just following up on this question. Could really use some suggestion. > > Thanks, > Saikat > > Saikat Mukherjee, > PhD Student, > Paul Research Group - http://www.me.vt.edu/mpaul/ > Engineering Science and Mechanics, > Virginia Tech. > > On Wed, Jul 11, 2018 at 11:34 AM, Saikat Mukherjee > wrote: > > Hey All, > > I have been stuck in this problem for a while now but I think it > should be simple and probably you can tell where I am going wrong. > > - So I have a forcing function on a finite difference X-Y grid, > which I am reading in as a text file in the 'userdat2' subroutine. > > - I am then parallelizing it using a previous suggestion by > Paul, here is a snippet of the routine. > > -------------------------------------------------------------------------------------------------------- > > ? ? ?subroutine usrdat2 > > > ? ? ? include 'SIZE' > > ? ? ? include 'TOTAL' > > ?? ? ? double precision :: my_array(651) > > ?? ? ? integer m > > ? ? ? ? common /myarray/ my_array > > > ? ? ? ? parameter (my_array_size=651) > > > ? ? ? ? real? work(my_array_size) > > > > ? ? ? ? n = my_array_size > > > ? ? ? ? call rzero(my_array,n) > > ? ? ? ? call rzero(work,n) > > > ? ? ? ? if (nid.eq.0) then > > ? ? ? ? ? open (unit=49,file='fint41.txt') > > ?? ? ? ? ? ? do k = 1,n > > ? ? ? ? ? ? ? ? read(49,*) my_array(k) > > ?? ? ? ? ? ? enddo > > ? ? ? ? ? close(49) > > ? ? ? ? endif > > > ?? ? ? ? call gop(my_array,work,'+? ',n) ? !? Sum over all > processors > > > ? ? ? return > > ? ? ? end > > --------------------------------------------------------------------------------------------------------- > > - Next I am interpolating this forcing function to the GLL grid > points in the userf routine, by a piecewise linear interpolant, > here's how, > > ---------------------------------------------------------------------------------------------------------- > > ? ? ?subroutine userf? (ix,iy,iz,ieg) > > > ? ? ? include 'SIZE' > > ? ? ? include 'TOTAL' > > ? ? ? include 'NEKUSE' > > ? ? ? EQUIVALENCE? ? (prandtl,param(2)) > > > ?? ? ? ? double precision :: my_array(651) > > ?? ? ? ? double precision :: shaped_array(31,21) > > ?? ? ? ? real new_array(nx1,ny1,nz1,nelv) > > ?? ? ? ? double precision :: xin(21),yin(31) > > ?? ? ? ? double precision :: xn(nx1*ny1*nelv),yn(nx1*ny1*nelv) > > ?? ? ? ? double precision :: fo(nx1*ny1*nelv) > > ?? ? ? ? integer i,j,k,l,p,q > > ?? ? ? ? integer e,eg > > ?? ? ? ? common /myarray/ my_array > > > ?? ? ? ? open(16,file='xin.txt') > > ?? ? ? ? do p=1,21 > > ?? ? ? ? read(16,*) xin(p) > > ?? ? ? ? end do > > ?? ? ? ? close(16) > > > ?? ? ? ? open(12,file='yin.txt') > > ?? ? ? ? do q=1,31 > > ?? ? ? ? read(12,*) yin(q) > > ?? ? ? ? end do > > ?? ? ? ? close(12) > > > ?? ? ? ? shaped_array = reshape(my_array,(/31,21/)) > > > ?? ? ? ? do i=1,nx1*ny1*nelv > > ?? ? ? ? xn(i) = xm1(i,1,1,1) > > ?? ? ? ? yn(i) = ym1(i,1,1,1) > > ?? ? ? ? end do > > ?? ? ? ? call > pwl_interp_2d(31,21,yin,xin,shaped_array,nx1*ny1*nelv,yn,xn,fo) > > > ? ? ? ??new_array=reshape(fo,(/nx1,ny1,nz1,nelv/)) > > > ?do e=1,nelv > > ? ? ? ? ? ? ? ? ? ? ? eg = lglel(e) > > ? ? ? ? ? ? ? ? ? ? ? ffx = new_array(ix,iy,iz,eg) > > ? ? ? ? ? ? ? ? ?end do > > > ? ? ? ? ?ffy = 0.0 > > ? ? ? ? ?ffz = 0.0 > > > ? ? ? return > > ? ? ? end > > > > --------------------------------------------------------------------------------------------------------------------------------------- > > This is a test domain I made, with 6 elements. It seems to be > working when I am using only 1 core, i.e., in series. In > parallel, it seems to be giving me a different flowfield. My > actual domain has 252 elements which I intend to parallelize > with 48 cores. So would like to ask you how to proceed. I think > I am close but I am slightly confused about part of the code > that I have made red. > > When I am trying this in my actual domain, I get an error, > "Segmentation fault occurred." I think the key here is > parallelization and identifying the elements correctly which I > am not sure I am doing right. Thanks for reading this lengthy > email. Will be eager to hear from you. > > Thanks, > Saikat > > > > > > > > _______________________________________________ > 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 Jul 23 18:46:08 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 23 Jul 2018 19:46:08 -0400 Subject: [Nek5000-users] Using an external file for forcing in 'ffx' In-Reply-To: References: Message-ID: Hey Philipp, Thanks this helps a lot! Couple of questions, 1) So you are saying the interpolation can be done in userdat2 at the start? My forcing field does not change with time. 2) So essentially you are saying the routine in red should be just, ffx = new_array(ix,iy,iz,iel) ? Does 'iel' by default designate the local index? Or do I have to declare 'iel' before? One of the problems I was having doing it this way is that I didn't get a flowfield when I tried to use more than one processor, that is, parallelizing it. However it returned me a flowfield when it was with just one processor. That is in series. I am uploading some files if you want to take a further look. https://drive.google.com/drive/folders/1i_TUfUePTHK2He9hGyRoFcC_1emeJhXU?usp=sharing Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. On Mon, Jul 23, 2018 at 5:56 PM, Saikat Mukherjee wrote: > Hey Philipp, > > Thanks this helps a lot! Couple of questions, > > 1) So you are saying the interpolation can be done in userdat2 at the > start? My forcing field does not change with time. > > 2) So essentially you are saying the routine in red should be just, ffx = > new_array(ix,iy,iz,iel) ? Does 'iel' by default designate the local index? > Or do I have to declare 'iel' before? > > One of the problems I was having doing it this way is that I didn't get a > flowfield when I tried to use more than one processor, that is, > parallelizing it. However it returned me a flowfield when it was with just > one processor. That is in series. > > I am uploading some files if you want to take a further look. > > > Thanks, > Saikat > > > > On Mon, Jul 23, 2018 at 3:54 PM, wrote: > >> Hi, >> - userdat2 looks ok. Just some comments: use real instead of double >> precision as we compile with -r8. Then you could define your parameter >> right in the beginning and just use that one, instead of hardcoded 651. But >> these are details, it should work, and just read and broadcast your data to >> all processors. >> >> - in userf: again, use real instead. Also, you might read the FD >> coordinates in userdat2 as well. You can do as you do, but that is most >> inefficient (reading every time step from every processor). >> >> - you do not need to reshape the array, you can just define my_array with >> the proper size in userf. (my_array(31,21)). In fact, you do not even need >> that as you can simply pass my_array to pwl_intepr_2d. >> >> - the whole interpolation can be done once in the beginning anyway, or do >> you change the forcing field as a function of time? >> >> - you do not need separate fo and new_array (see above) >> >> - then the red bit: You have now interpolated your forcing on the gll >> points. So ffx simply needs to be the entry of this forcing field at the >> current ix,iy,iz,e. No need for a loop over the (local) elements, and no >> need for local-to-global mapping. just take the local index iel. Everything >> is local, as your interpolation was local as well (i.e. only interpolated >> to those elements that a specific processor had because you used xm1 and >> ym1. >> >> Sorry if I am misunderstanding. It is not easy to debug code without a >> running case. >> >> Hope this helps, >> philipp >> >> On 2018-07-23 16:57, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello, >>> >>> Following up on this question again. Would appreciate any input. >>> >>> Thanks, >>> Saikat >>> >>> >>> >>> On Mon, Jul 16, 2018 at 10:17 AM, >> > wrote: >>> >>> Hey everyone, >>> >>> Just following up on this question. Could really use some suggestion. >>> >>> Thanks, >>> Saikat >>> >>> Saikat Mukherjee, >>> PhD Student, >>> Paul Research Group - http://www.me.vt.edu/mpaul/ >>> Engineering Science and Mechanics, >>> Virginia Tech. >>> >>> On Wed, Jul 11, 2018 at 11:34 AM, Saikat Mukherjee >> > wrote: >>> >>> Hey All, >>> >>> I have been stuck in this problem for a while now but I think it >>> should be simple and probably you can tell where I am going >>> wrong. >>> >>> - So I have a forcing function on a finite difference X-Y grid, >>> which I am reading in as a text file in the 'userdat2' >>> subroutine. >>> >>> - I am then parallelizing it using a previous suggestion by >>> Paul, here is a snippet of the routine. >>> >>> ------------------------------------------------------------ >>> -------------------------------------------- >>> >>> subroutine usrdat2 >>> >>> >>> include 'SIZE' >>> >>> include 'TOTAL' >>> >>> double precision :: my_array(651) >>> >>> integer m >>> >>> common /myarray/ my_array >>> >>> >>> parameter (my_array_size=651) >>> >>> >>> real work(my_array_size) >>> >>> >>> >>> n = my_array_size >>> >>> >>> call rzero(my_array,n) >>> >>> call rzero(work,n) >>> >>> >>> if (nid.eq.0) then >>> >>> open (unit=49,file='fint41.txt') >>> >>> do k = 1,n >>> >>> read(49,*) my_array(k) >>> >>> enddo >>> >>> close(49) >>> >>> endif >>> >>> >>> call gop(my_array,work,'+ ',n) ! Sum over all >>> processors >>> >>> >>> return >>> >>> end >>> >>> ------------------------------------------------------------ >>> --------------------------------------------- >>> >>> - Next I am interpolating this forcing function to the GLL grid >>> points in the userf routine, by a piecewise linear interpolant, >>> here's how, >>> >>> ------------------------------------------------------------ >>> ---------------------------------------------- >>> >>> subroutine userf (ix,iy,iz,ieg) >>> >>> >>> include 'SIZE' >>> >>> include 'TOTAL' >>> >>> include 'NEKUSE' >>> >>> EQUIVALENCE (prandtl,param(2)) >>> >>> >>> double precision :: my_array(651) >>> >>> double precision :: shaped_array(31,21) >>> >>> real new_array(nx1,ny1,nz1,nelv) >>> >>> double precision :: xin(21),yin(31) >>> >>> double precision :: xn(nx1*ny1*nelv),yn(nx1*ny1*nelv) >>> >>> double precision :: fo(nx1*ny1*nelv) >>> >>> integer i,j,k,l,p,q >>> >>> integer e,eg >>> >>> common /myarray/ my_array >>> >>> >>> open(16,file='xin.txt') >>> >>> do p=1,21 >>> >>> read(16,*) xin(p) >>> >>> end do >>> >>> close(16) >>> >>> >>> open(12,file='yin.txt') >>> >>> do q=1,31 >>> >>> read(12,*) yin(q) >>> >>> end do >>> >>> close(12) >>> >>> >>> shaped_array = reshape(my_array,(/31,21/)) >>> >>> >>> do i=1,nx1*ny1*nelv >>> >>> xn(i) = xm1(i,1,1,1) >>> >>> yn(i) = ym1(i,1,1,1) >>> >>> end do >>> >>> call >>> pwl_interp_2d(31,21,yin,xin,shaped_array,nx1*ny1*nelv,yn,xn,fo) >>> >>> >>> new_array=reshape(fo,(/nx1,ny1,nz1,nelv/)) >>> >>> >>> do e=1,nelv >>> >>> eg = lglel(e) >>> >>> ffx = new_array(ix,iy,iz,eg) >>> >>> end do >>> >>> >>> ffy = 0.0 >>> >>> ffz = 0.0 >>> >>> >>> return >>> >>> end >>> >>> >>> >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> --------------- >>> >>> This is a test domain I made, with 6 elements. It seems to be >>> working when I am using only 1 core, i.e., in series. In >>> parallel, it seems to be giving me a different flowfield. My >>> actual domain has 252 elements which I intend to parallelize >>> with 48 cores. So would like to ask you how to proceed. I think >>> I am close but I am slightly confused about part of the code >>> that I have made red. >>> >>> When I am trying this in my actual domain, I get an error, >>> "Segmentation fault occurred." I think the key here is >>> parallelization and identifying the elements correctly which I >>> am not sure I am doing right. Thanks for reading this lengthy >>> email. Will be eager to hear from you. >>> >>> Thanks, >>> Saikat >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >> s.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 Tue Jul 24 06:51:13 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 24 Jul 2018 12:51:13 +0100 Subject: [Nek5000-users] findpts Message-ID: Hi nek, I am doing the lagrangian particle tracking but got a problem in the findpts. It shows some points are not found after findpts. Can anyone give some suggestions? call intpts call findpts WARNING: point not within mesh xy[z]: ! NaN NaN NaN Kind regards, Jian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jul 24 07:01:31 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 24 Jul 2018 14:01:31 +0200 Subject: [Nek5000-users] findpts In-Reply-To: References: Message-ID: Hard to tell without any source code. -----Original message----- > From:nek5000-users at lists.mcs.anl.gov > Sent: Tuesday 24th July 2018 13:52 > To: nek5000-users at lists.mcs.anl.gov > Subject: [Nek5000-users] findpts > > Hi nek, > > I am doing the lagrangian particle tracking but got a problem in the findpts. It shows some points are not found after findpts. Can anyone give some suggestions? > > ?call intpts > ?call findpts > ?WARNING: point not within mesh xy[z]: !? ? ? ? ? ? NaN? ? ? ? ? ? NaN? ? ? ? ? ? NaN > > Kind regards, > > Jian? > _______________________________________________ > 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 Jul 24 01:29:01 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 24 Jul 2018 15:29:01 +0900 Subject: [Nek5000-users] Planar average in z-direction problem Message-ID: Hi, NeksI wonder why planar_average_z in navier5.f shows wrong result.here I attached 2 images.First image shows the z-directional grids points from zm1(I wrote a code to extract z coordinate at y = 0 as follows:======================================================insnum = nidinsuni = insnum + 1000WRITE(insnam,98) 'inst_field_', insnumOPEN(unit=insuni,file=insnam insnum = nid insuni = insnum + 1000 WRITE(insnam,98) 'inst_field_', insnum Open(unit=insuni,file=insnam) do i = 1,n if (ym1(i,1,1,1).eq.0.0)then WRITE(insuni,5) xm1(i,1,1,1) % , zm1(i,1,1,1) % , vx(i,1,1,1) % , vy(i,1,1,1) % , vz(i,1,1,1) % , phig(i,1,1,1) endif enddo CLOSE(insuni)======================================================?Then, I can collect lots of field data from each processor and sort data with ascending order using matlab.So, I got the result as 1st image.But when I use plannar_average_zI got the result as shown in 2nd image.1. I really want to modify the problems, so could you give me your idea on this problem?2. Additionally, could you explain 'zgm1' and 'area'?I noticed that, planar_average_r or s ... in turbChannel case has also 'area' but, those case are used to calculate ondifferent direction.But they used same input parameters.What I understand about area is, surface area of element.But I thought that different direction needs different indexing======================================================= subroutine planar_average_z(ua,u,w1,w2)cc Compute r-s planar average of quantity u()c include 'SIZE' include 'GEOM' include 'PARALLEL' include 'WZ' include 'ZPER'c real ua(lz1,nelz),u(lx1*ly1,lz1,nelv),w1(lz1,nelz),w2(lz1,nelz) integer e,eg,ezc melxy = nelx*nelyc nz = lz1*nelz call rzero(ua,nz) call rzero(w1,nz)c do e=1,neltc eg = lglel(e)c ez = 1 + (eg-1)/melxy call get_exyz(ex,ey,ez,eg,nelx,nely,nelz)c do k=1,lz1 do i=1,lx1*ly1 zz = (1.-zgm1(k,3))/2. ! = 1 for k=1, = 0 for k=lz1 aa = zz*area(i,1,5,e) + (1-zz)*area(i,1,6,e) ! wgtd jacobian w1(k,ez) = w1(k,ez) + aa ua(k,ez) = ua(k,ez) + aa*u(i,k,e) enddo enddo enddoc call gop(ua,w2,'+ ',nz) call gop(w1,w2,'+ ',nz)c do i=1,nz ua(i,1) = ua(i,1) / w1(i,1) ! Normalize enddoc return end======================================================Regards,Hyunduk.? ------------------------------------------------------------------------------------------------------------------ HyundukSeo(Mr.) IntegratedPh.D.course,SchooPusanNationalUniversity? ExperimentalThermo-FluidsMecENsys)Laboratory http://fluid.pusan.ac.kr T.:+82-51-510-1536M.:+82-10-2964-0994 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jul 24 01:34:14 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 24 Jul 2018 15:34:14 +0900 Subject: [Nek5000-users] Planar average in z-direction problem (image updated) Message-ID: Hi, NeksI wonder why planar_average_z in navier5.f shows wrong result.here I attached 2 images.1, https://drive.google.com/file/d/1Kng9HZfQW-TGTFwmFcXzbrcvhRYrQSdc/view?usp=sharing2.https://drive.google.com/file/d/1FN3i5mE6VSoPeehG5evjC33WrD3J4lB5/view?usp=sharingFirst image shows the z-directional grids points from zm1(I wrote a code to extract z coordinate at y = 0 as follows:======================================================insnum = nidinsuni = insnum + 1000WRITE(insnam,98) 'inst_field_', insnumOPEN(unit=insuni,file=insnam insnum = nid insuni = insnum + 1000 WRITE(insnam,98) 'inst_field_', insnum Open(unit=insuni,file=insnam) do i = 1,n if (ym1(i,1,1,1).eq.0.0)then WRITE(insuni,5) xm1(i,1,1,1) % , zm1(i,1,1,1) % , vx(i,1,1,1) % , vy(i,1,1,1) % , vz(i,1,1,1) % , phig(i,1,1,1) endif enddo CLOSE(insuni)======================================================?Then, I can collect lots of field data from each processor and sort data with ascending order using matlab.So, I got the result as 1st image.But when I use plannar_average_zI got the result as shown in 2nd image.1. I really want to modify the problems, so could you give me your idea on this problem?2. Additionally, could you explain 'zgm1' and 'area'?I noticed that, planar_average_r or s ... in turbChannel case has also 'area' but, those case are used to calculate ondifferent direction.But they used same input parameters.What I understand about area is, surface area of element.But I thought that different direction needs different indexing======================================================= subroutine planar_average_z(ua,u,w1,w2)cc Compute r-s planar average of quantity u()c include 'SIZE' include 'GEOM' include 'PARALLEL' include 'WZ' include 'ZPER'c real ua(lz1,nelz),u(lx1*ly1,lz1,nelv),w1(lz1,nelz),w2(lz1,nelz) integer e,eg,ezc melxy = nelx*nelyc nz = lz1*nelz call rzero(ua,nz) call rzero(w1,nz)c do e=1,neltc eg = lglel(e)c ez = 1 + (eg-1)/melxy call get_exyz(ex,ey,ez,eg,nelx,nely,nelz)c do k=1,lz1 do i=1,lx1*ly1 zz = (1.-zgm1(k,3))/2. ! = 1 for k=1, = 0 for k=lz1 aa = zz*area(i,1,5,e) + (1-zz)*area(i,1,6,e) ! wgtd jacobian w1(k,ez) = w1(k,ez) + aa ua(k,ez) = ua(k,ez) + aa*u(i,k,e) enddo enddo enddoc call gop(ua,w2,'+ ',nz) call gop(w1,w2,'+ ',nz)c do i=1,nz ua(i,1) = ua(i,1) / w1(i,1) ! Normalize enddoc return end======================================================Regards,Hyunduk.? ------------------------------------------------------------------------------------------------------------------ HyundukSeo(Mr.) IntegratedPh.D.course,SchooPusanNationalUniversity? ExperimentalThermo-FluidsMecENsys)Laboratory http://fluid.pusan.ac.kr T.:+82-51-510-1536M.:+82-10-2964-0994 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jul 24 09:28:16 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 24 Jul 2018 14:28:16 +0000 Subject: [Nek5000-users] Planar average in z-direction problem (image updated) In-Reply-To: References: Message-ID: Dear Hyunduk, I see several issues with the code you have. The first point is that your code will not work properly in parallel, so you need to be careful about parallel treatment of IO if you are running on more than one MPI rank. Secondly, it's generally not a good idea to test for equality with real numbers -- are you certain that the y values of interest are 0.0000000 ? or are they potentially 1.e-7 (say). Some of the mesh generation tools will have noise and your zero values might not be exactly zero. zgm1 is the position of the nodal points on the interval [-1,1] in the reference element area() is the surface area at the top and bottom of each element. (Here, we assume that "top" in z means also top in r-s-t space for the canonical Omega-hat := [-1,1]^3.) Thus, aa is a linear combination of the area at the top of the given element and bottom of the given element. This way the surface integral can handle tapered elements (but nothing more complex than that). hth, Paul ________________________________ From: Nek5000-users on behalf of nek5000-users at lists.mcs.anl.gov Sent: Tuesday, July 24, 2018 1:34 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Planar average in z-direction problem (image updated) Hi, Neks I wonder why planar_average_z in navier5.f shows wrong result. here I attached 2 images. 1, https://drive.google.com/file/d/1Kng9HZfQW-TGTFwmFcXzbrcvhRYrQSdc/view?usp=sharing 2. https://drive.google.com/file/d/1FN3i5mE6VSoPeehG5evjC33WrD3J4lB5/view?usp=sharing First image shows the z-directional grids points from zm1 (I wrote a code to extract z coordinate at y = 0 as follows: ====================================================== insnum = nid insuni = insnum + 1000 WRITE(insnam,98) 'inst_field_', insnum OPEN(unit=insuni,file=insnam insnum = nid insuni = insnum + 1000 WRITE(insnam,98) 'inst_field_', insnum Open(unit=insuni,file=insnam) do i = 1,n if (ym1(i,1,1,1).eq.0.0)then WRITE(insuni,5) xm1(i,1,1,1) % , zm1(i,1,1,1) % , vx(i,1,1,1) % , vy(i,1,1,1) % , vz(i,1,1,1) % , phig(i,1,1,1) endif enddo CLOSE(insuni) ====================================================== Then, I can collect lots of field data from each processor and sort data with ascending order using matlab. So, I got the result as 1st image. But when I use plannar_average_z I got the result as shown in 2nd image. 1. I really want to modify the problems, so could you give me your idea on this problem? 2. Additionally, could you explain 'zgm1' and 'area'? I noticed that, planar_average_r or s ... in turbChannel case has also 'area' but, those case are used to calculate on different direction. But they used same input parameters. What I understand about area is, surface area of element. But I thought that different direction needs different indexing ======================================================= subroutine planar_average_z(ua,u,w1,w2) c c Compute r-s planar average of quantity u() c include 'SIZE' include 'GEOM' include 'PARALLEL' include 'WZ' include 'ZPER' c real ua(lz1,nelz),u(lx1*ly1,lz1,nelv),w1(lz1,nelz),w2(lz1,nelz) integer e,eg,ez c melxy = nelx*nely c nz = lz1*nelz call rzero(ua,nz) call rzero(w1,nz) c do e=1,nelt c eg = lglel(e) c ez = 1 + (eg-1)/melxy call get_exyz(ex,ey,ez,eg,nelx,nely,nelz) c do k=1,lz1 do i=1,lx1*ly1 zz = (1.-zgm1(k,3))/2. ! = 1 for k=1, = 0 for k=lz1 aa = zz*area(i,1,5,e) + (1-zz)*area(i,1,6,e) ! wgtd jacobian w1(k,ez) = w1(k,ez) + aa ua(k,ez) = ua(k,ez) + aa*u(i,k,e) enddo enddo enddo c call gop(ua,w2,'+ ',nz) call gop(w1,w2,'+ ',nz) c do i=1,nz ua(i,1) = ua(i,1) / w1(i,1) ! Normalize enddo c return end ====================================================== Regards, Hyunduk. ------------------------------------------------------------------------------------------------------------------ Hyunduk Seo (Mr.) Integrated Ph.D. course, School of Mechanical Engineering, Pusan National University Experimental Thermo-Fluids Mechanics and Energy Systems (ExTENsys) Laboratory http://fluid.pusan.ac.kr T.: +82-51-510-1536 M.: +82-10-2964-0994 [http://webmail.pusan.ac.kr/api/notify.php?home=MjAxODA3MjQxNTM0MTR8bmVrNTAwMC11c2Vyc0BsaXN0cy5tY3MuYW5sLmdvdnxoZHNlbzAxMjNAcHVzYW4uYWMua3I=] -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jul 24 11:45:21 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 24 Jul 2018 16:45:21 +0000 Subject: [Nek5000-users] Pipe Roughness Message-ID: Dear Mr.Philipp, I think I need more help with the first way, changing the location of the mesh. I have used the NekNek script successfully, but I still do n't know how to trigger the main flow by these overlapped elements, near the wall. I.e. I still don't see any sign for a connection between these two meshes. Are there more details you can help me with besides the eddy_nekenk example? I would be very grateful. Thanks, Ali Embry-Riddle Aeronautical University -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jul 25 05:51:08 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 Jul 2018 12:51:08 +0200 Subject: [Nek5000-users] Pipe Roughness In-Reply-To: References: Message-ID: Hi, I guess I am not the best person to talk to when it comes to neknek. However, I guess that that approach might be the most accurate, but potentially also the most costly (in terms of human and computer time), I just wanted to make sure that this is indeed what you need, as opposed to e.g. simpler IBM? Philipp On 2018-07-24 18:45, nek5000-users at lists.mcs.anl.gov wrote: > > > Dear Mr.Philipp, > I think I need more help with the first way, changing the location of > the mesh. I have used the NekNek script successfully, but I still do n't > know how to trigger the main flow by these overlapped elements, near the > wall. I.e. I still don't see any sign for a connection between these two > meshes. Are there more details you can help me with besides the > eddy_nekenk example? I would be very grateful. > > > Thanks, > > Ali > > Embry-Riddle Aeronautical University > > > > > > > _______________________________________________ > 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 Jul 25 07:25:33 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 Jul 2018 12:25:33 +0000 Subject: [Nek5000-users] Pipe Roughness Message-ID: Thank you for your clarification, It seems my assessment was wrong. In my research, adding a roughness is not the main point, but it still should be considered. It doesn't matter which approach I go with as long as it is easy to implement by Nek5000. Anyway, I think I should do more research on these two approaches (NekNek and IBM) or I can build the mesh with a third-party program and convert it to Nek5000, right? Again, thank you for your assistance, Ali Embry-Riddle Aeronautical University -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jul 25 07:46:00 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 Jul 2018 14:46:00 +0200 Subject: [Nek5000-users] Pipe Roughness In-Reply-To: References: Message-ID: yes, there are a number of conversion tools from various mesh formats to nek5000. But one needs to keep in mind that the mesh quality is crucial if you want to exploit the benefits of a high order method. Philipp On 2018-07-25 14:25, nek5000-users at lists.mcs.anl.gov wrote: > > Thank you for your clarification, > > It seems my assessment was wrong. In my research, adding a roughness is > not the main point, but it still should be considered. It doesn't matter > which approach I go with as long as it is easy to implement by Nek5000. > Anyway, I think I should do more research on these two approaches > (NekNek and IBM) or I can build the mesh with a third-party program and > convert it to Nek5000, right? > > Again, thank you for your assistance, > > Ali > > /Embry-Riddle Aeronautical University/ > > > > > > _______________________________________________ > 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 Jul 25 10:35:24 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 Jul 2018 15:35:24 +0000 Subject: [Nek5000-users] Pipe Roughness Message-ID: Hi Ali, Regarding Nek-Nek, this might be helpful: http://nek5000.github.io/NekDoc/tutorials/neknek.html Regarding your question in one of your previous messages: the key aspect in coupling two meshes in a NekNek calculation is the boundary condition of the surfaces that overlap another domain... these surfaces must have ?int? boundary condition. At the beginning of the calculation, this serves as the flag for the solver to identify the surface GLL points that overlap with another domain. These surfaces become Dirichlet surfaces from there on, where Dirichlet velocity data is obtained by interpolating solution (velocity and passive scalars) between domains at the end of each time-step and during sub-iterations (number of sub-iterations at each time-step are controlled by the parameter ngeom specified in usrdat). Take a look at this tutorial, and see if it helps make things clear.. You can also look at the article ?A spectrally accurate method for overlapping grid solution of incompressible Navier?Stokes equations?. If you still have questions, please let me know. Should you choose to use NekNek for this calculation, I can help you setup the problem/mesh. Ketan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jul 25 14:42:10 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 Jul 2018 19:42:10 +0000 Subject: [Nek5000-users] Pipe Roughness Message-ID: Yes, that sounds awesome, and thank you for your generous offer. I'll see what is gonna happen and what I can do with NekNek approach. Ali Embry-Riddle Aeronautical University -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 26 08:07:39 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 26 Jul 2018 22:07:39 +0900 Subject: [Nek5000-users] Planar average in z-direction problem (image updated) Message-ID: DearPaul,Thankyouforyourecommendation.Asyousaid,IalsounderstandthatmycodeisnotMPIfriendly.But,mytopicwasmalfunctionoftheplanar_average_zinmycaseandIjustwantedtoknowwhetherthereareanyproblemsinmygridpoints.Infact,Inoticedthatmycomputationaldomainswith4boxesmadefrom.boxfilehavesomeproblems.(So,Iwroteacodetogeneratemeshgridfor1boxwithclustering.AndImanuallyassignedgridpointsthen,problemwassolved.)Ithinkconnectivitybetweeneachboxwasbadatthetime.Regards,Hyunduk.------------------------------------------------------------------------------------------------------------------------------------------------------Title:Re:Planaraverageinz-directionproblem(imageupdated)DearHyunduk,Iseeseveralissueswiththecodeyouhave.Thefirstpointisthatyourcodewillnotworkproperlyinparallel,soyouneedtobecarefulaboutparalleltreatmentofIOifyouarerunningonmorethanoneMPIrank.Secondly,it'sgenerallynotagoodideatotestforequalitywithrealnumbers--areyoucertainthattheyvaluesofinterestare0.0000000?oraretheypotentially1.e-7(say).Someofthemeshgenerationtoolswillhavenoiseandyourzerovaluesmightnotbeexactlyzero.zgm1isthepositionofthenodalpointsontheinterval[-1,1]inthereferenceelementarea()isthesurfaceareaatthetopandbottomofeachelement.(Here,weassumethat"top"inzmeansalsotopinr-s-tspaceforthecanonicalOmega-hat:=[-1,1]^3.)Thus,aaisalinearcombinationoftheareaatthetopofthegivenelementandbottomofthegivenelement.Thiswaythesurfaceintegralcanhandletaperedelements(butnothingmorecomplexthanthat).hth,Paul------------------------------------------------------------------------------------------------------------------------------------------------------Title:Planaraverageinz-directionproblem(imageupdated)Hi,NeksIwonderwhyplanar_average_zinnavier5.fshowswrongresult.hereIattached2images.1,https://drive.google.com/file/d/1Kng9HZfQW-TGTFwmFcXzbrcvhRYrQSdc/view?usp=sharing2.https://drive.google.com/file/d/1FN3i5mE6VSoPeehG5evjC33WrD3J4lB5/view?usp=sharingFirstimageshowsthez-directionalgridspointsfromzm1(Iwroteacodetoextractzcoordinateaty=0asfollows:======================================================insnum=nidinsuni=insnum+1000WRITE(insnam,98)'inst_field_',insnumOPEN(unit=insuni,file=insnaminsnum=nidinsuni=insnum+1000WRITE(insnam,98)'inst_field_',insnumOpen(unit=insuni,file=insnam)doi=1,nif(ym1(i,1,1,1).eq.0.0)thenWRITE(insuni,5)xm1(i,1,1,1)%,zm1(i,1,1,1)%,vx(i,1,1,1)%,vy(i,1,1,1)%,vz(i,1,1,1)%,phig(i,1,1,1)endifenddoCLOSE(insuni)======================================================Then,Icancollectlotsoffielddatafromeachprocessorandsortdatawithascendingorderusingmatlab.So,Igottheresultas1stimage.ButwhenIuseplannar_average_zIgottheresultasshownin2ndimage.1.Ireallywanttomodifytheproblems,socouldyougivemeyourideaonthisproblem?2.Additionally,couldyouexplain'zgm1'and'area'?Inoticedthat,planar_average_rors...inturbChannelcasehasalso'area'but,thosecaseareusedtocalculateondifferentdirection.Buttheyusedsameinputparameters.WhatIunderstandaboutareais,surfaceareaofelement.ButIthoughtthatdifferentdirectionneedsdifferentindexing=======================================================subroutineplanar_average_z(ua,u,w1,w2)ccComputer-splanaraverageofquantityu()cinclude'SIZE'include'GEOM'include'PARALLEL'include'WZ'include'ZPER'crealua(lz1,nelz),u(lx1*ly1,lz1,nelv),w1(lz1,nelz),w2(lz1,nelz)integere,eg,ezcmelxy=nelx*nelycnz=lz1*nelzcallrzero(ua,nz)callrzero(w1,nz)cdoe=1,neltceg=lglel(e)cez=1+(eg-1)/melxycallget_exyz(ex,ey,ez,eg,nelx,nely,nelz)cdok=1,lz1doi=1,lx1*ly1zz=(1.-zgm1(k,3))/2.!=1fork=1,=0fork=lz1aa=zz*area(i,1,5,e)+(1-zz)*area(i,1,6,e)!wgtdjacobianw1(k,ez)=w1(k,ez)+aaua(k,ez)=ua(k,ez)+aa*u(i,k,e)enddoenddoenddoccallgop(ua,w2,'+',nz)callgop(w1,w2,'+',nz)cdoi=1,nzua(i,1)=ua(i,1)/w1(i,1)!Normalizeenddocreturnend======================================================Regards,Hyunduk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 26 12:33:16 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 26 Jul 2018 18:33:16 +0100 Subject: [Nek5000-users] findpts returns ix iy iz iel Message-ID: Hi nek, I want to use findpts to return ix [1,nx1], iy [1,ny1], iz [1,nz1], and iel [1,nelv] for a set of points as follows, could anyone tell me how which are ix iy and iz? I think elid is the iel. call findpts(ih, rcode, 1, proc, 1, elid, 1, rst, ndim, dist, 1, pts(1), pts(n+1), pts(2*n+1), 1, n) Cheers, Jian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jul 26 12:40:25 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 26 Jul 2018 19:40:25 +0200 Subject: [Nek5000-users] findpts returns ix iy iz iel In-Reply-To: References: Message-ID: Before going into the details of findpts(). What are you trying to do? -----Original message----- > From:nek5000-users at lists.mcs.anl.gov > Sent: Thursday 26th July 2018 19:33 > To: nek5000-users at lists.mcs.anl.gov > Subject: [Nek5000-users] findpts returns ix iy iz iel > > Hi nek, > > I want to use findpts to return ix [1,nx1], iy [1,ny1], iz [1,nz1], and iel [1,nelv] for a set of points as follows, could anyone tell me how which are ix iy and iz? I think elid is the iel.? > > call findpts(ih, rcode, 1, proc, 1, elid, 1, rst, ndim, dist, 1, pts(1), pts(n+1), pts(2*n+1), 1, n) > > Cheers, > > Jian > _______________________________________________ > 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 Jul 28 06:02:39 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 28 Jul 2018 12:02:39 +0100 Subject: [Nek5000-users] findpts returns ix iy iz iel Message-ID: Hi Nek, What I want is the ix, iy, iz and iel at some points pts. So the findpts would be called with rst returned. But as far as I can see, rst are the coordinates of such element. May I has the grid point in that element, i.e. ix [1,nx1], iy [1,ny1], iz [1,nz1]? Kind regards, Jian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat Jul 28 10:33:08 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 28 Jul 2018 15:33:08 +0000 Subject: [Nek5000-users] findpts returns ix iy iz iel In-Reply-To: References: Message-ID: Dear Jian, rst will not generally map to the discrete point set (i,j,k) within an element. One strategy that would be reasonably fast would be to bin the intervals on either side of each Gauss Lobatto Legendre (GLL) point on the 1D interval [-1,1] and then to search for the GLL point that is closest to the r value returned from findpts. Then repeat for s and t. In fact, you could generate a mapping function u(r) that would map the GLL points to a uniform grid [1,lx1] then you could interrogate u(r) and and round the output via: i = u(r) + 0.5 Then repeat for s-->j, and t--> k. hth Paul ________________________________ From: Nek5000-users on behalf of nek5000-users at lists.mcs.anl.gov Sent: Saturday, July 28, 2018 6:02:39 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] findpts returns ix iy iz iel Hi Nek, What I want is the ix, iy, iz and iel at some points pts. So the findpts would be called with rst returned. But as far as I can see, rst are the coordinates of such element. May I has the grid point in that element, i.e. ix [1,nx1], iy [1,ny1], iz [1,nz1]? Kind regards, Jian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jul 31 14:48:50 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 31 Jul 2018 19:48:50 +0000 Subject: [Nek5000-users] Pipe Roughness Message-ID: Dear Ketan, Unfortunately, I couldn't modify the neknek script to be run on the Cray machine. Sometimes, it asks me about mpirun for MPMD, and other time the problem comes from the SESSION.NAME. I just got stuck at this point, so could you please help me with that? I.e.Is there something, like nekpbs, handles neknek? Thank you in advance, Ali Embry-Riddle Aeronautical University -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jul 31 14:57:00 2018 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 31 Jul 2018 21:57:00 +0200 Subject: [Nek5000-users] Pipe Roughness In-Reply-To: References: Message-ID: Dear Ali, Attached you can find a script that I have successfully used in the past to submit neknek MPMD jobs on Piz Daint (CSCS). Hope that helps, George > On 31 Jul 2018, at 21:48, nek5000-users at lists.mcs.anl.gov wrote: > > > Dear Ketan, > > Unfortunately, I couldn't modify the neknek script to be run on the Cray machine. Sometimes, it asks me about mpirun for MPMD, and other time the problem comes from the SESSION.NAME. I just got stuck at this point, so could you please help me with that? I.e.Is there something, like nekpbs, handles neknek? > > > Thank you in advance, > > Ali > Embry-Riddle Aeronautical University > > > > > _______________________________________________ > 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: submit.mpmd Type: application/octet-stream Size: 924 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: