From nek5000-users at lists.mcs.anl.gov Tue Dec 4 02:08:49 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 Dec 2012 13:38:49 +0530 Subject: [Nek5000-users] Computing total kinetic energy Message-ID: Hello I use following code to compute total kinetic energy in the domain inside userchk c Compute total kinetic energy if(mod(istep,10).eq.0)then n = nx1*ny1*nz1*nelv xke = glsc3(vx, vx, bm1, n) yke = glsc3(vy, vy, bm1, n) zke = glsc3(vz, vz, bm1, n) total_ke = 0.5*(xke + yke + zke) if(nid.eq.0) write(6,1) istep, time, total_ke 1 format(i6,1p2e14.6,' Totalke') endif Is this correct ? Does this account for the parallel computation or do I need to do something extra to gather from other processes ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Dec 4 02:33:10 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 Dec 2012 02:33:10 -0600 (CST) Subject: [Nek5000-users] Computing total kinetic energy In-Reply-To: References: Message-ID: Hi Praveen, Yes - this is correct. The "glsc3" stands for global scalar product, 3 arguments and thus is fully parallel. If you wanted (for some reason) a result local to each processor, you would use vlsc3, which stands for vector local scalar product, 3 arguments. An example would be: integer e real ek(lelt) nxyz = nx1*ny1*nz1 do e=1,nelv ek(e) = (vlsc3(vx(1,1,1,e),vx(1,1,1,e),bm1(1,1,1,e),nxyz) $ + vlsc3(vy(1,1,1,e),vy(1,1,1,e),bm1(1,1,1,e),nxyz) $ + vlsc3(vz(1,1,1,e),vz(1,1,1,e),bm1(1,1,1,e),nxyz)) /2. enddo Paul On Tue, 4 Dec 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hello > > I use following code to compute total kinetic energy in the domain inside > userchk > > c Compute total kinetic energy > if(mod(istep,10).eq.0)then > n = nx1*ny1*nz1*nelv > xke = glsc3(vx, vx, bm1, n) > yke = glsc3(vy, vy, bm1, n) > zke = glsc3(vz, vz, bm1, n) > total_ke = 0.5*(xke + yke + zke) > if(nid.eq.0) write(6,1) istep, time, total_ke > 1 format(i6,1p2e14.6,' Totalke') > endif > > Is this correct ? Does this account for the parallel computation or do I > need to do something extra to gather from other processes ? > > Thanks > praveen > From nek5000-users at lists.mcs.anl.gov Wed Dec 5 07:08:46 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 5 Dec 2012 13:08:46 +0000 Subject: [Nek5000-users] How to use the linearised solver with a base flow Message-ID: Dear All How to use the linearised NS solver with a base flow? Could someone can give me an example? Thanks very much. Hui -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Dec 6 06:38:42 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 06 Dec 2012 13:38:42 +0100 Subject: [Nek5000-users] Traveling gravity waves Message-ID: Hi Neks, I am trying to set up a traveling gravity wave and started from the std.wv example. - In the useric I prescribed the the Initial velocity by using linear wave theory (Airy) http://en.wikipedia.org/wiki/Airy_wave_theory#Solution_for_a_progressive_monochromatic_wave wave amplitude - the initial mesh was generate with genbox with periodic sides, bottom wall and a free surface - the surface tension was excluded by setting sigma & We = 0 - reverted density & viscosity to dimensional variables (SI Units) in the .rea to get correct velocities - set the gravitational force in userf ffy = -9.81*param(1) But instead of a traveling wave the system reverts to a sort of standing wave immediately Do I have set the initial velocity of the moving mesh as well? And if so are wx,wy the correct variables to do so? Did I apply the dimensions correctly? I attached the .rea & .usr, any help with my Problem would be greatly appreciated. Thanks Arne -------------- next part -------------- ****** PARAMETERS ***** 2.610000 NEKTON VERSION 2 DIMENSIONAL RUN --- Based on "leeho1a.rea" 120 PARAMETERS FOLLOW--- See Lee W. Ho 1989 MIT Ph.D. Thesis 998.0 p1 DENSITY 1 p2 VISCOS -3.e4 0 0.01 0. 0. 0. 0. 1.00000 p7 RHOCP 0.10000E-01 p8 CONDUCT 0. 0. p10 FINTIME 1000 p11 NSTEPS 0.000250 p12 DT 0. p13 IOCOMM 0. p14 IOTIME 5. p15 IOSTEP 0. p16 PSSOLVER 0. 0.50000E-01 p18 GRID -1.00000 p19 INTYPE 5.0000 p20 NORDER 1.000000E-10 p21 DIVERGENCE 1.000000E-12 p22 HELMHOLTZ 0 p23 NPSCAL 0.100000E-01 p24 TOLREL 0.100000E-01 p25 TOLABS 0.40000 p26 COURANT/NTAU 3.00000 p27 TORDER 0. p28 TORDER: mesh velocity (0: p28=p27) 0. p29 magnetic visc if > 0, = -1/Rm if < 0 0. p30 > 0 ==> properties set in uservp() 0. p31 NPERT: #perturbation modes 0. p32 #BCs in re2 file, if > 0 0. 0. 0. 0. 0. 0. 0. 0. 0. p41 1-->multiplicative SEMG 0. p42 0=gmres/1=pcg 0. p43 0=semg/1=schwarz 0. p44 0=E-based/1=A-based prec. 0. p45 Relaxation factor for DTFS 0. p46 reserved 0.0950000E+00 p47 vnu: mesh matieral prop 0. 0. 0. 0. 0. p52 IOHIS 0. 0. p54 1,2,3-->fixed flow rate dir=x,y,z 0. p55 vol.flow rate (p54>0) or Ubar (p54<0) 0. 0. 0. 1.00000 p59 !=0 --> full Jac. eval. for each el. 0. p60 !=0 --> init. velocity to small nonzero 0. 0. p62 >0 --> force byte_swap for output 0. p63 =8 --> force 8-byte output 0. p64 =1 --> perturbation restart 1.00000 p65 #iofiles (eg, 0 or 64); <0 --> sep. dirs 4.00000 p66 output : <0=ascii, else binary 4.00000 p67 restart: <0=ascii, else binary 0. p68 iastep: freq for avg_all 0. 0. 0. 0. 0. 0. p74 verbose Helmholtz 0.01 p75 perturbation amplitude (in .usr) 0. 0. 0. 0. 0. 0. 0. 0. 0. p84 !=0 --> sets initial timestep if p12>0 0. p85 dt ratio if p84 !=0, for timesteps>0 0. p86 reserved 0. 0. 0. 0. 0. 0. 0. p93 Number of previous pressure solns saved 0. p94 start projecting velocity after p94 step 0. p95 start projecting pressure after p95 step 0. 0. 0. 3.00000 p99 dealiasing: <0--> off/3--> old/4--> new 0. 1.00000 p101 No. of additional filter modes 1.00000 p102 Dump out divergence at each time step -0.01 p103 weight of stabilizing filter (.01) 0. 0. 0. 0. p107 !=0--> add to h2 array in hlmhotz eqn 0. 0. 0. 0. 0. 0. 0. 0. 0 6. p116 !=0: x elements for fast tensor product 0 10. p117 !=0: y elements for fast tensor product 0 1. p118 !=0: z elements for fast tensor product 0. 0. 4 Lines of passive scalar data follows2 CONDUCT; 2RHOCP -10.0000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 13 LOGICAL SWITCHES FOLLOW T IFFLOW F IFHEAT T IFTRAN T T F F F F F F F F F IFNAV & IFADVC (convection in P.S. fields) F F T T T T T T T T T T IFTMSH (IF mesh for this field is T mesh) F IFAXIS T IFSTRS F IFSPLIT F IFMGRID F IFMODEL F IFKEPS T IFMVBD F IFCHAR 8.00000 8.00000 -0.500000 -4.00000 XFAC,YFAC,XZERO,YZERO **MESH DATA** 1st line is X of corner 1,2,3,4. 2nd line is Y. -120 2 120 NEL,NDIM,NELV 0 PRESOLVE/RESTART OPTIONS ***** 7 INITIAL CONDITIONS ***** C Default C Default C Default C Default C Default C Default C Default ***** DRIVE FORCE DATA ***** BODY FORCE, FLOW, Q 4 Lines of Drive force data follow C C C C ***** Variable Property Data ***** Overrrides Parameter data. 1 Lines follow. 0 PACKETS OF DATA FOLLOW ***** HISTORY AND INTEGRAL DATA ***** 0 POINTS. Hcode, I,J,H,IEL ***** OUTPUT FIELD SPECIFICATION ***** 6 SPECIFICATIONS FOLLOW T COORDINATES T VELOCITY T PRESSURE F TEMPERATURE F TEMPERATURE GRADIENT 0 PASSIVE SCALARS ***** OBJECT SPECIFICATION ***** 0 Surface Objects 0 Volume Objects 0 Edge Objects 0 Point Objects -------------- next part -------------- c----------------------------------------------------------------------- c c Setup for 2D free-surface standing wave problem c c Re = 998.0/1 c c We = 0 c c Fr = 1/9.81 c c c----------------------------------------------------------------------- subroutine uservp (ix,iy,iz,ieg) include 'SIZE' include 'TOTAL' include 'NEKUSE' ! udiff =0. ! utrans=0. return end c----------------------------------------------------------------------- subroutine userf (ix,iy,iz,ieg) include 'SIZE' include 'TOTAL' include 'NEKUSE' common /fsparam/ amp,alpha,Re,Pg,We,gamma_r,gamma_i,w_k ffx = 0.0 c ffy = -(Re*Pg)**(-2) c ffy = -1 ! ffy = -9.81 ffy = -9.81*param(1) ffz = 0.0 return end c----------------------------------------------------------------------- subroutine userq (ix,iy,iz,ieg) include 'SIZE' include 'TOTAL' include 'NEKUSE' C qvol = 0.0 source = 0.0 return end c----------------------------------------------------------------------- subroutine userchk include 'SIZE' include 'TOTAL' common /outputs/ vol0,ymx0,vy20,vy2l,total_ke0 common /fsarray/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) common /fsparam/ amp,alpha,Re,Pg,We,gamma_r,gamma_i,w_k real dtmax save dtmax integer xxx n = nx1*ny1*nz1*nelv vol = glsum(bm1,n) vy2 = glsc3(vy,bm1,vy,n)/vol if (vy2.gt.0) vy2 = sqrt(vy2) !Compute maximal surface elevation ymx = glmax(ym1,n) c !Compute total kinetic energy xke = glsc3(vx, vx, bm1, n) yke = glsc3(vy, vy, bm1, n) total_ke = 0.5*(xke + yke) !compute maximal mesh velocity w_wx = glmax(wx,n) !compute maximal velocity w_vx = glmax(vx,n) c c Target error values for ge are asympotically ~ 1.e-4 c c !Only first step if (istep.eq.0) then vol0 = vol ymx0 = ymx vy20 = vy2 c !Initial kinetic energy total_ke0 = total_ke c !Output Initial Condition call outpost(vx,vy,vz,pr,t,'IC_') !Only on Node 0 if (nid.eq.0) then c Create Output file for Volume OPEN (22,FILE='volume.txt',STATUS='REPLACE', & ACCESS='sequential',position='append') WRITE(22,*) 'Conservation of Volume' CLOSE(20) endif else c !Volume volr = vol/vol0 ymxr = ymx/ymx0 vy2l = vy2/vy2l !Only on Node 0 if (nid.eq.0) then write(6,1) istep,time,ymx,vy2,ymxr 1 format(i5,1p4e14.6,' amp') c Open Output file for Volume OPEN (22,FILE='volume.txt',STATUS='OLD',ACCESS='sequential', & position='append') WRITE(22,*) time,'step', istep, 'delta Volume',(vol-vol0)/vol0 WRITE(22,*) 'kinetic energy' , total_ke, & 'delta', (total_ke0-total_ke) WRITE(22,*) 'maximal surface elevation' ,ymx,'delta',ymx-ymx0 WRITE(22,*) 'maximal x-mesh velocity' ,w_wx , & 'maximal x-velocity' ,w_vx CLOSE(22) endif endif vy2l = vy2 c if (istep.eq.0) dtmax = abs(param(12)) ! small steps at start c if (istep.eq.0) dt = dtmax/100. c dt = dt*1.01 c dt = min(dtmax,dt) c param(12) = -dt param(93) = 0 ! no projection for free-surface param(94) = 0 ! no velocity projection for free-surface param(95) = 0 ! no pressure projection for free-surface return end c----------------------------------------------------------------------- subroutine userbc (ix,iy,iz,iside,ieg) include 'SIZE' include 'TOTAL' include 'NEKUSE' common /fsparam/ amp,alpha,Re,Pg,We,gamma_r,gamma_i,w_k ! ux=0.0 ! uy=0.0 ! uz=0.0 ! temp=0.0 c sigma = We ! surface tension = Weber number c sigma = 1.e-8 sigma = 0 return end c----------------------------------------------------------------------- subroutine useric (ix,iy,iz,eg) include 'SIZE' include 'TOTAL' include 'NEKUSE' common /fsarray/ ub(lx1,ly1,lz1,lelt),vb(lx1,ly1,lz1,lelt) common /fsparam/ amp,alpha,Re,Pg,We,gamma_r,gamma_i,w_k integer e,eg c Prescribe Velocity c ux=0.0 c uy=0.0 c 2D Simualation z = 0 c uz=0.0 ! temp=0 c amp = 0.05 ! Perturbation amplitude c amp = param(75) c Wave_k ... etc c w_k = 2.0 w_g = 9.81 c w_g = 1 !skalierte Gravitation w_w = sqrt(w_g * w_k) one = 1. pi = 4.*atan(one) x0 = 0. x1 = 2. n = nx1*ny1*nz1*nelv xmin = x0 xmax = x1 do i=1,n ! perurbation displacement x = xm1(i,1,1,1) y = ym1(i,1,1,1) ! ax = w_k * 2.0 *pi*(x-xmin)/(xmax-xmin) ax = w_k * x disp1 = sin(ax) disp2 = cos(ax) ! w_koeff = w_g * amp * w_k / w_w w_koeff = amp * w_w c yscl = 1+y ! zero when y=-1, 1 when y = 0 c vx(i,1,1,1) = amp * w_w * exp(w_k*y)*disp1 c vy(i,1,1,1) = -amp * w_w * exp(w_k*y)*disp2 c !set velocity vx(i,1,1,1) = w_koeff * exp(w_k*y)*disp1 vy(i,1,1,1) = w_koeff * exp(w_k*y)*disp2 c !set mesh velocity ! wx(i,1,1,1) = w_koeff * exp(w_k*y)*disp1 ! wy(i,1,1,1) = w_koeff * exp(w_k*y)*disp2 enddo return end c----------------------------------------------------------------------- subroutine usrdat c Verbose timing ! iverbose = 1 ! fully verbose ! call platform_timer(iverbose) ! call exitti('timer done$',iverbose) return end c----------------------------------------------------------------------- subroutine usrdat3 return end c----------------------------------------------------------------------- subroutine usrdat2 include 'SIZE' include 'TOTAL' include 'ZPER' ! nelx,nely for quickmv include 'CTIMER' ! icalld common /fsparam/ amp,alpha,Re,Pg,We,gamma_r,gamma_i,w_k common /xyorig/ xo(lx1*ly1*lz1*lelt),yo(lx1*ly1*lz1*lelt) character*3 cb integer e,eg,ex,ey,ez nelx = 6 nely = 6 param(66) = 4 ! std nek5000 output param(67) = 4 c Re = 3.e4 ! hard-code Reynolds number c visc = 1/Re c param(2) = visc c cpfld(1,1) = visc c cpfld(1,2) = 1.0 ! density ! ! Pg = 1.1e-4 ! Gravitational Peclet number We = 0.0 amp = param(75) ! Perturbation amplitude c amp = 0.05 ! Perturbation amplitude one = 1. pi = 4.*atan(one) x0 = 0. x1 = 2.0 * pi call rescale_x (xm1,x0,x1) ! x on [0,1] later *2*pi y0 = -3.5 y1 = 0. call rescale_x (ym1,y0,y1) ! y on [-1,0] w_k = 1.0 n = nx1*ny1*nz1*nelv xmin = glmin(xm1,n) xmax = glmax(xm1,n) icalld = icalld+1 do i=1,n ! perurbation displacement x = xm1(i,1,1,1) y = ym1(i,1,1,1) ! ax = w_k * 2*pi*(x-xmin)/(xmax-xmin) ax = w_k * x disp = sin(ax) c yscl = 1+y ! zero when y=-1, 1 when y = 0 c ym1(i,1,1,1) = y + amp*yscl*disp c ym1(i,1,1,1) = y + (y - y0) * amp * disp !same function ym1(i,1,1,1) = y + (y - y0)/(-y0) * amp * disp !same function enddo param(59) = 1 ! force std operator evaluation for deformed geometry c Set surface tension on free surface ! sigma = We ! must be set in userbc for cb = 'ms ' sigma = 0.0 itop = 3 if (if3d) itop = 5 do e=1,nelv cb = cbc(itop,e,1) ! bc on top surface if (cb.eq.'MS ') bc(4,itop,e,1) = sigma enddo return end c----------------------------------------------------------------------- From nek5000-users at lists.mcs.anl.gov Thu Dec 6 06:45:30 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 Dec 2012 06:45:30 -0600 (CST) Subject: [Nek5000-users] Traveling gravity waves In-Reply-To: Message-ID: Hi Arne, Just one comment that ffx is a force per unit volume so you do not need to multiple it by density, i.e. param(1) Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Thursday, December 6, 2012 6:38:42 AM Subject: [Nek5000-users] Traveling gravity waves Hi Neks, I am trying to set up a traveling gravity wave and started from the std.wv example. - In the useric I prescribed the the Initial velocity by using linear wave theory (Airy) http://en.wikipedia.org/wiki/Airy_wave_theory#Solution_for_a_progressive_monochromatic_wave wave amplitude - the initial mesh was generate with genbox with periodic sides, bottom wall and a free surface - the surface tension was excluded by setting sigma & We = 0 - reverted density & viscosity to dimensional variables (SI Units) in the .rea to get correct velocities - set the gravitational force in userf ffy = -9.81*param(1) But instead of a traveling wave the system reverts to a sort of standing wave immediately Do I have set the initial velocity of the moving mesh as well? And if so are wx,wy the correct variables to do so? Did I apply the dimensions correctly? I attached the .rea & .usr, any help with my Problem would be greatly appreciated. Thanks Arne _______________________________________________ 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 Dec 6 06:54:10 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 06 Dec 2012 13:54:10 +0100 Subject: [Nek5000-users] Traveling gravity waves In-Reply-To: References: Message-ID: thanks Aleks. I tried that as well, but the velocity field still is completely different to the initial Condition after one step (dt = 0.00025). Arne On 06.12.2012 13:45, nek5000-users at lists.mcs.anl.gov wrote: > Hi Arne, > > Just one comment that ffx is a force per unit volume so you do not need to multiple it by density, i.e. param(1) > > Aleks > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Thursday, December 6, 2012 6:38:42 AM > Subject: [Nek5000-users] Traveling gravity waves > > Hi Neks, > > I am trying to set up a traveling gravity wave and started from the > std.wv example. > > - In the useric I prescribed the the Initial velocity by using linear > wave theory (Airy) > > http://en.wikipedia.org/wiki/Airy_wave_theory#Solution_for_a_progressive_monochromatic_wave > wave amplitude > - the initial mesh was generate with genbox with periodic sides, bottom > wall and a free surface > - the surface tension was excluded by setting sigma & We = 0 > - reverted density & viscosity to dimensional variables (SI Units) in > the .rea to get correct velocities > - set the gravitational force in userf ffy = -9.81*param(1) > > But instead of a traveling wave the system reverts to a sort of standing > wave immediately > > Do I have set the initial velocity of the moving mesh as well? And if so > are wx,wy the correct variables to do so? > Did I apply the dimensions correctly? > > I attached the .rea & .usr, any help with my Problem would be greatly > appreciated. > > Thanks > Arne > > _______________________________________________ > 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 Dec 6 10:05:54 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 Dec 2012 10:05:54 -0600 Subject: [Nek5000-users] Traveling gravity waves In-Reply-To: <6924_1354797533_qB6CcrG0007846_mailman.5627.1354797531.3251.nek5000-users@lists.mcs.anl.gov> References: <6924_1354797533_qB6CcrG0007846_mailman.5627.1354797531.3251.nek5000-users@lists.mcs.anl.gov> Message-ID: I am not an expert on surface waves but just wondering if you are initializing with one wave component such as this? [image: \eta\, =\, a\, \cos\, ( k x\, -\, \omega t ).]My understanding is you should have multiple components to see something interesting. This can be simply achieved by modulating the above form by a spatial localization function such as exp(-(x-x0)2) or add other components such as a1 cos(kx...)+ a2 cos(2kx...)+...etc Ammar On Thu, Dec 6, 2012 at 6:38 AM, wrote: > Hi Neks, > > I am trying to set up a traveling gravity wave and started from the > std.wv example. > > - In the useric I prescribed the the Initial velocity by using linear > wave theory (Airy) > > > http://en.wikipedia.org/wiki/Airy_wave_theory#Solution_for_a_progressive_monochromatic_wave > wave amplitude > - the initial mesh was generate with genbox with periodic sides, bottom > wall and a free surface > - the surface tension was excluded by setting sigma & We = 0 > - reverted density & viscosity to dimensional variables (SI Units) in > the .rea to get correct velocities > - set the gravitational force in userf ffy = -9.81*param(1) > > But instead of a traveling wave the system reverts to a sort of standing > wave immediately > > Do I have set the initial velocity of the moving mesh as well? And if so > are wx,wy the correct variables to do so? > Did I apply the dimensions correctly? > > I attached the .rea & .usr, any help with my Problem would be greatly > appreciated. > > Thanks > Arne > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- http://aelghany.googlepages.com/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Dec 6 16:05:00 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 06 Dec 2012 23:05:00 +0100 Subject: [Nek5000-users] Traveling gravity waves In-Reply-To: References: <6924_1354797533_qB6CcrG0007846_mailman.5627.1354797531.3251.nek5000-users@lists.mcs.anl.gov> Message-ID: Hi Ammar, as I am using a single deepwater wave with amplitude a = 0.01 and wavenumber k = 1 the steepness := k*a = 0.01 is quite low. Higher Order terms from Stokes Theory?http://en.wikipedia.org/wiki/Stokes_wave can be neglected as they are small For example the third order solution for deep water?http://en.wikipedia.org/wiki/Stokes_wave#Third-order_Stokes_wave_on_deep_water doesn't differ from the Airy Theory so the velocities are correct to order 3 in the pertubation series with respect to the steepness k*a Only the surface elevation differs in the order O( a?k +a?k) which should be neglectable as well. I want to simulate a simple wave and than goto steeper waves with higher nonlinearities (Stokes) in order to create a test case to see what resolution and parameters are needed in NEK5000 and then step up to more complex sea states. I already simulated this wave with a pseudo-spectral method which stability strongly depends on accurate initial Conditions and could simulate many periods without problems. All the best, Arne PS: I'll let you know if 3rd Stokes made a difference Zitat von nek5000-users at lists.mcs.anl.gov: > > > > * I am not an expert on surface waves but just wondering if > * you are initializing with one wave component such as this? > * > > > My understanding is you should have multiple components to see > something interesting. This can be simply achieved by modulating the > above > form by a spatial localization function such as exp(-(x-x0)2) or > add other components such as a1 cos(kx...)+ a2 cos(2kx...)+...etc > > Ammar > > > > > ? > On Thu, Dec 6, 2012 at 6:38 AM, wrote: >> >> Hi Neks, >> >> I am trying to set up a traveling gravity wave and started from the >> std.wv example. >> >> - In the useric I prescribed the the Initial velocity by using linear >> wave theory (Airy) >> >> http://en.wikipedia.org/wiki/Airy_wave_theory#Solution_for_a_progressive_monochromatic_wave >> ? wave amplitude >> - the initial mesh was generate with genbox with periodic sides, bottom >> wall and a free surface >> - the surface tension was excluded by setting sigma & We = 0 >> - reverted density & viscosity to dimensional ?variables (SI Units) in >> the .rea to get correct velocities >> - set the gravitational force in userf ffy = -9.81*param(1) >> >> But instead of a traveling wave the system reverts to a sort >> of standing >> wave immediately >> >> Do I have set the initial velocity of the moving mesh as well? >> And if so >> are wx,wy the correct variables to do so? >> Did I apply the dimensions correctly? >> >> I attached the .rea & .usr, any help with my Problem would be greatly >> appreciated. >> >> Thanks >> Arne >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> ? >> > > > > > > -- > http://aelghany.googlepages.com/home > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Dec 7 10:29:49 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 7 Dec 2012 10:29:49 -0600 Subject: [Nek5000-users] Traveling gravity waves In-Reply-To: References: <6924_1354797533_qB6CcrG0007846_mailman.5627.1354797531.3251.nek5000-users@lists.mcs.anl.gov> Message-ID: I understand H.O.T. do not make big difference in the displacement amplitude, but how can you have dispersion without having at least two components such as cos(theta) and cos(2*theta) you can estimate how much run time you need to see significant dispersion based on the phase speed of each component. I also had a lot of problems in the past with pseudospectral codes where there are small inconsistencies/errors in the initial conditions. Ammar On Dec 6, 2012, at 4:05 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Ammar, > > as I am using a single deepwater wave with amplitude a = 0.01 and wavenumber k = 1 the steepness := k*a = 0.01 is quite low. > Higher Order terms from Stokes Theory http://en.wikipedia.org/wiki/Stokes_wave can be neglected as they are small > For example the third order solution for deep water http://en.wikipedia.org/wiki/Stokes_wave#Third-order_Stokes_wave_on_deep_water doesn't differ from the Airy Theory so the velocities are correct to order 3 in the pertubation series with respect to the steepness k*a > Only the surface elevation differs in the order O( a?k +a?k) which should be neglectable as well. > > I want to simulate a simple wave and than goto steeper waves with higher nonlinearities (Stokes) in order to create a test case to see what resolution and parameters are needed in NEK5000 > and then step up to more complex sea states. I already simulated this wave with a pseudo-spectral method which stability strongly depends on accurate initial Conditions and could simulate many periods without problems. > > All the best, Arne > > PS: I'll let you know if 3rd Stokes made a difference > > Zitat von nek5000-users at lists.mcs.anl.gov: > >> I am not an expert on surface waves but just wondering if >> you are initializing with one wave component such as this? >> >> My understanding is you should have multiple components to see something interesting. This can be simply achieved by modulating the above >> form by a spatial localization function such as exp(-(x-x0)2) or add other components such as a1 cos(kx...)+ a2 cos(2kx...)+...etc >> >> Ammar >> >> >> >> >> >> >> On Thu, Dec 6, 2012 at 6:38 AM, wrote: >> Hi Neks, >> >> I am trying to set up a traveling gravity wave and started from the >> std.wv example. >> >> - In the useric I prescribed the the Initial velocity by using linear >> wave theory (Airy) >> >> http://en.wikipedia.org/wiki/Airy_wave_theory#Solution_for_a_progressive_monochromatic_wave >> wave amplitude >> - the initial mesh was generate with genbox with periodic sides, bottom >> wall and a free surface >> - the surface tension was excluded by setting sigma & We = 0 >> - reverted density & viscosity to dimensional variables (SI Units) in >> the .rea to get correct velocities >> - set the gravitational force in userf ffy = -9.81*param(1) >> >> But instead of a traveling wave the system reverts to a sort of standing >> wave immediately >> >> Do I have set the initial velocity of the moving mesh as well? And if so >> are wx,wy the correct variables to do so? >> Did I apply the dimensions correctly? >> >> I attached the .rea & .usr, any help with my Problem would be greatly >> appreciated. >> >> Thanks >> Arne >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> >> >> >> >> -- >> http://aelghany.googlepages.com/home >> > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat Dec 8 02:36:33 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 8 Dec 2012 14:06:33 +0530 Subject: [Nek5000-users] 3-D Taylor-Green problem Message-ID: Hello I am solving the 3-D Taylor-Green problem as described here http://www.dlr.de/as/desktopdefault.aspx/tabid-8170/13999_read-35550/ C3.5 Direct Numerical Simulation of the Taylor-Green Vortex at Re = 1600 using NEK. I use lx1 = 10 lx2 = lx1-2 ldx = 15 No of elements = 14^3 or 28^3 The evolution of dissipation rate with time is shown in attached pdf. f=0.0 indicates no filtering and f=0.05 means filter parameter P103. Use of filter seems to capture peak dissipation rate better but still some difference is seen. The DG results with similar number of dofs in the problem description give good estimate of peak rate. So I expect NEK results to improve further and would like to ask for any advice. Should I try with larger amount of filtering ? I have attached my SIZE and rea files. Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: box.rea Type: application/octet-stream Size: 5594 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: diss.pdf Type: application/pdf Size: 32937 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SIZE Type: application/octet-stream Size: 3353 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Sat Dec 8 15:01:35 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 8 Dec 2012 15:01:35 -0600 Subject: [Nek5000-users] 3-D Taylor-Green problem In-Reply-To: References: Message-ID: Your results make sense to me. Note that you are not really "capturing" peak dissipation rate with filtering. you are only supplementing the resolved dissipation on a given grid by artificially damping energy. that's why you get higher peak with f=0.05 and N=14^3 relative to f=0 and N=14^3 I wonder how much resolution N^3 you need (with f=0) to truly capture the peak dissipation rate? In order to better judge your simulations you should compare DNS (f=0) and LES f=nonzero for gradually increased resolution N^3 if DNS is expensive , good news DNS is already been done , Check Brachet et al JFM article Journal of Fluid Mechanics / Volume 130 / May 1983, pp 411-452 ( Small-scale structure of the Taylor?Green vortex Marc E. Brachet a1p1, Daniel I. Meiron a1, Steven A. Orszag a1, B. G. Nickel a2 ) and compare the time history of the dissipation rate to what you get at the same Reynolds number. Ammar On Dec 8, 2012, at 2:36 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello > I am solving the 3-D Taylor-Green problem as described here > > http://www.dlr.de/as/desktopdefault.aspx/tabid-8170/13999_read-35550/ > C3.5 Direct Numerical Simulation of the Taylor-Green Vortex at Re = 1600 > > using NEK. > > I use > > lx1 = 10 > lx2 = lx1-2 > ldx = 15 > > No of elements = 14^3 or 28^3 > > The evolution of dissipation rate with time is shown in attached pdf. > > f=0.0 indicates no filtering and f=0.05 means filter parameter P103. > > Use of filter seems to capture peak dissipation rate better but still some difference is seen. The DG results with similar number of dofs in the problem description give good estimate of peak rate. So I expect NEK results to improve further and would like to ask for any advice. Should I try with larger amount of filtering ? > > I have attached my SIZE and rea files. > > Thanks > praveen > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat Dec 8 15:12:50 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 8 Dec 2012 15:12:50 -0600 Subject: [Nek5000-users] 3-D Taylor-Green problem In-Reply-To: References: Message-ID: Can you elaborate on the 512^3 case? it is impressive you are getting close with 32^3 and some filtering I was wondering : (1) what if you turn off filtering with 32^3 (i.e. set f=0), the question here if filtering is significantly contributing to the dissipation rate. if it does not make a big difference then I would say your LES with 32^3 and f=0.05 is pretty good. (2) how does the time history in all cases compare to Brachet et al. (see my previous note) at the same Re. Ammar On Dec 8, 2012, at 3:01 PM, nek5000-users at lists.mcs.anl.gov wrote: > Your results make sense to me. Note that you are not really "capturing" peak dissipation rate with filtering. > you are only supplementing the resolved dissipation on a given grid by artificially damping energy. that's why you get higher peak with f=0.05 and N=14^3 relative to f=0 and N=14^3 > I wonder how much resolution N^3 you need (with f=0) to truly capture the peak dissipation rate? > > In order to better judge your simulations you should compare DNS (f=0) and LES f=nonzero for gradually increased resolution N^3 > > if DNS is expensive , good news DNS is already been done , Check Brachet et al JFM article Journal of Fluid Mechanics / Volume 130 / May 1983, pp 411-452 > ( > Small-scale structure of the Taylor?Green vortex > Marc E. Brachet a1p1, Daniel I. Meiron a1, Steven A. Orszag a1, B. G. Nickel a2 > ) > > > and compare the time history of the dissipation rate > to what you get at the same Reynolds number. > > > > Ammar > > > > > > > On Dec 8, 2012, at 2:36 AM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello >> I am solving the 3-D Taylor-Green problem as described here >> >> http://www.dlr.de/as/desktopdefault.aspx/tabid-8170/13999_read-35550/ >> C3.5 Direct Numerical Simulation of the Taylor-Green Vortex at Re = 1600 >> >> using NEK. >> >> I use >> >> lx1 = 10 >> lx2 = lx1-2 >> ldx = 15 >> >> No of elements = 14^3 or 28^3 >> >> The evolution of dissipation rate with time is shown in attached pdf. >> >> f=0.0 indicates no filtering and f=0.05 means filter parameter P103. >> >> Use of filter seems to capture peak dissipation rate better but still some difference is seen. The DG results with similar number of dofs in the problem description give good estimate of peak rate. So I expect NEK results to improve further and would like to ask for any advice. Should I try with larger amount of filtering ? >> >> I have attached my SIZE and rea files. >> >> Thanks >> praveen >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat Dec 8 22:31:27 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 9 Dec 2012 10:01:27 +0530 Subject: [Nek5000-users] 3-D Taylor-Green problem In-Reply-To: References: Message-ID: Hello Ammar The filter refers to a stabilization technique and is not related to LES. It is explained here "Filter-Based Stabilization of Spectral Element Methods" I do not know the details of the spectral simulation. I took the data from the website I mentioned in my post and some explanation is given in the case description I linked to before. I used 14^3 and 28^3 elements but within each element the velocity is a Q_9 function and pressure is Q_7 function. Thanks for the reference. I have not seen it before and will check it out. Thanks praveen On Sun, Dec 9, 2012 at 2:42 AM, wrote: > Can you elaborate on the 512^3 case? it is impressive you are getting > close with 32^3 and some filtering > I was wondering : > (1) what if you turn off filtering with 32^3 (i.e. set f=0), the question > here if filtering is significantly contributing to the dissipation rate. if > it does not make a big difference then I would say your LES with 32^3 and > f=0.05 is pretty good. > (2) how does the time history in all cases compare to Brachet et al. (see > my previous note) at the same Re. > > Ammar > > On Dec 8, 2012, at 3:01 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Your results make sense to me. Note that you are not really "capturing" > peak dissipation rate with filtering. > you are only supplementing the resolved dissipation on a given grid by > artificially damping energy. that's why you get higher peak with f=0.05 > and N=14^3 relative to f=0 and N=14^3 > I wonder how much resolution N^3 you need (with f=0) to truly capture the > peak dissipation rate? > > In order to better judge your simulations you should compare DNS (f=0) and > LES f=nonzero for gradually increased resolution N^3 > > if DNS is expensive , good news DNS is already been done , Check Brachet > et al JFM article Journal of Fluid Mechanics / > Volume 130 / May 1983, pp 411-452 > ( > Small-scale structure of the Taylor?Green vortex*Marc E. Brachet a1p1 > *, *Daniel I. Meiron a1*, *Steven A. Orszag a1*, *B. G. Nickel a2* > ) > > > and compare the time history of the dissipation rate > to what you get at the same Reynolds number. > > > > Ammar > > > > > > > On Dec 8, 2012, at 2:36 AM, nek5000-users at lists.mcs.anl.gov wrote: > > Hello > I am solving the 3-D Taylor-Green problem as described here > > http://www.dlr.de/as/desktopdefault.aspx/tabid-8170/13999_read-35550/ > C3.5 Direct Numerical Simulation of the Taylor-Green Vortex at Re = 1600 > > using NEK. > > I use > > lx1 = 10 > lx2 = lx1-2 > ldx = 15 > > No of elements = 14^3 or 28^3 > > The evolution of dissipation rate with time is shown in attached pdf. > > f=0.0 indicates no filtering and f=0.05 means filter parameter P103. > > Use of filter seems to capture peak dissipation rate better but still some > difference is seen. The DG results with similar number of dofs in the > problem description give good estimate of peak rate. So I expect NEK > results to improve further and would like to ask for any advice. Should I > try with larger amount of filtering ? > > I have attached my SIZE and rea files. > > Thanks > praveen > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Dec 9 10:15:33 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 9 Dec 2012 10:15:33 -0600 Subject: [Nek5000-users] 3-D Taylor-Green problem In-Reply-To: References: Message-ID: Hi Praveen Filtering removes energy at the small scales (small length scales/high frequency components) If you estimate the turbulent kinetic energy removed by the filtering and compare it to the resolved kinetic energy or the total (resolved+subgrid scale) then your simulation : (1) May be considered DNS ; if the above ratio is small (2) LES if it is relatively big in (2) the hope is that subgrid scale motion does not affect the scales of interest in a given problem. Filtering stabilizes simulations since it provides a way for removing energy at the small unresolved scales. I ran turbulent wake simulations in the past where filtering was absolutely necessary and the argument was that it did not affect the scales of interest. So the bottomline is you need to at least be aware of what scales are impacted by filtering and if indeed you are interested in such scales. That is why you see some comparisons in the paper for a given case with different values of the filtering parameter. so let me know what happens when 32^3 is run with f=0 and also the comparison to Brachet et al. Ammar On Dec 8, 2012, at 10:31 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Ammar > > The filter refers to a stabilization technique and is not related to LES. It is explained here > > "Filter-Based Stabilization of Spectral Element Methods" > > I do not know the details of the spectral simulation. I took the data from the website I mentioned in my post and some explanation is given in the case description I linked to before. > > I used 14^3 and 28^3 elements but within each element the velocity is a Q_9 function and pressure is Q_7 function. > > Thanks for the reference. I have not seen it before and will check it out. > > Thanks > praveen > > On Sun, Dec 9, 2012 at 2:42 AM, wrote: > Can you elaborate on the 512^3 case? it is impressive you are getting close with 32^3 and some filtering > I was wondering : > (1) what if you turn off filtering with 32^3 (i.e. set f=0), the question here if filtering is significantly contributing to the dissipation rate. if it does not make a big difference then I would say your LES with 32^3 and f=0.05 is pretty good. > (2) how does the time history in all cases compare to Brachet et al. (see my previous note) at the same Re. > > Ammar > > On Dec 8, 2012, at 3:01 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Your results make sense to me. Note that you are not really "capturing" peak dissipation rate with filtering. >> you are only supplementing the resolved dissipation on a given grid by artificially damping energy. that's why you get higher peak with f=0.05 and N=14^3 relative to f=0 and N=14^3 >> I wonder how much resolution N^3 you need (with f=0) to truly capture the peak dissipation rate? >> >> In order to better judge your simulations you should compare DNS (f=0) and LES f=nonzero for gradually increased resolution N^3 >> >> if DNS is expensive , good news DNS is already been done , Check Brachet et al JFM article Journal of Fluid Mechanics / Volume 130 / May 1983, pp 411-452 >> ( >> Small-scale structure of the Taylor?Green vortex >> Marc E. Brachet a1p1, Daniel I. Meiron a1, Steven A. Orszag a1, B. G. Nickel a2 >> ) >> >> >> and compare the time history of the dissipation rate >> to what you get at the same Reynolds number. >> >> >> >> Ammar >> >> >> >> >> >> >> On Dec 8, 2012, at 2:36 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello >>> I am solving the 3-D Taylor-Green problem as described here >>> >>> http://www.dlr.de/as/desktopdefault.aspx/tabid-8170/13999_read-35550/ >>> C3.5 Direct Numerical Simulation of the Taylor-Green Vortex at Re = 1600 >>> >>> using NEK. >>> >>> I use >>> >>> lx1 = 10 >>> lx2 = lx1-2 >>> ldx = 15 >>> >>> No of elements = 14^3 or 28^3 >>> >>> The evolution of dissipation rate with time is shown in attached pdf. >>> >>> f=0.0 indicates no filtering and f=0.05 means filter parameter P103. >>> >>> Use of filter seems to capture peak dissipation rate better but still some difference is seen. The DG results with similar number of dofs in the problem description give good estimate of peak rate. So I expect NEK results to improve further and would like to ask for any advice. Should I try with larger amount of filtering ? >>> >>> I have attached my SIZE and rea files. >>> >>> Thanks >>> praveen >>> _______________________________________________ >>> 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 -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Dec 12 05:02:08 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 12 Dec 2012 16:32:08 +0530 Subject: [Nek5000-users] 3-D Taylor-Green problem In-Reply-To: References: Message-ID: Hi I made the 28^3 computation without filter and all results are plotted together. The KE is well predicted even on the coarse mesh. The dissipation rate did not seem to change much with/without filtering on 28^3 mesh. I will try with more elements to see if the results improve and compare with Brachet et al. Thanks praveen On Sun, Dec 9, 2012 at 9:45 PM, wrote: > Hi Praveen > > Filtering removes energy at the small scales (small length scales/high > frequency components) > If you estimate the turbulent kinetic energy removed by the filtering and > compare it to the resolved kinetic energy or the total (resolved+subgrid > scale) > then your simulation : > > (1) May be considered DNS ; if the above ratio is small > (2) LES if it is relatively big > > in (2) the hope is that subgrid scale motion does not affect the scales of > interest in a given problem. > > Filtering stabilizes simulations since it provides a way for removing > energy at the small unresolved scales. I ran turbulent wake simulations in > the past > where filtering was absolutely necessary and the argument was that it did > not affect the scales of interest. > > So the bottomline is you need to at least be aware of what scales are > impacted by filtering and if indeed you are interested in such scales. That > is why > you see some comparisons in the paper for a given case with different > values of the filtering parameter. > > so let me know what happens when 32^3 is run with f=0 and also the > comparison to Brachet et al. > > Ammar > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: diss.pdf Type: application/pdf Size: 38247 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Dec 12 11:32:20 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 12 Dec 2012 11:32:20 -0600 Subject: [Nek5000-users] 3-D Taylor-Green problem In-Reply-To: References: Message-ID: This is impressive to me! the fact that filtering is not contributing too much to the dissipation rate and that both the trend/time evolution and numerical magnitude of the dissipation rate are accurately predicted throughout the simulation. Ammar On Dec 12, 2012, at 5:02 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi > I made the 28^3 computation without filter and all results are plotted together. The KE is well predicted even on the coarse mesh. The dissipation rate did not seem to change much with/without filtering on 28^3 mesh. I will try with more elements to see if the results improve and compare with Brachet et al. > Thanks > praveen > > > On Sun, Dec 9, 2012 at 9:45 PM, wrote: > Hi Praveen > > Filtering removes energy at the small scales (small length scales/high frequency components) > If you estimate the turbulent kinetic energy removed by the filtering and compare it to the resolved kinetic energy or the total (resolved+subgrid scale) > then your simulation : > > (1) May be considered DNS ; if the above ratio is small > (2) LES if it is relatively big > > in (2) the hope is that subgrid scale motion does not affect the scales of interest in a given problem. > > Filtering stabilizes simulations since it provides a way for removing energy at the small unresolved scales. I ran turbulent wake simulations in the past > where filtering was absolutely necessary and the argument was that it did not affect the scales of interest. > > So the bottomline is you need to at least be aware of what scales are impacted by filtering and if indeed you are interested in such scales. That is why > you see some comparisons in the paper for a given case with different values of the filtering parameter. > > so let me know what happens when 32^3 is run with f=0 and also the comparison to Brachet et al. > > Ammar > > > _______________________________________________ > 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 Dec 17 10:08:37 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 17 Dec 2012 17:08:37 +0100 Subject: [Nek5000-users] Probability Density Function Message-ID: Dear Neks, I want to calculate the probability density function of a scalar field ff in the attached subroutine. Since the element mesh is nonuniform I have to assign a weight "wght" with each grid point of ff. The weight is given by the volume of the associated grid cell. Coordinates of x,y,z of all vertices (primary and secondary nodes) are stored in xm1,ym1,zm1 as far as I know. This weight turns out to have in parts negative values which is unphysical. What went wrong? subroutine pdf_calc(ff,step,i_offset,i_name) include 'SIZE' include 'TOTAL' parameter(npdf=501) real ff(lx1,ly1,lz1,lelt) real pdf(npdf) real work(npdf) real val, vol, offset, wght integer e,eg,ex,ey,ez,f !-----Set arrays to zero call rzero(pdf,npdf) call rzero(work,npdf) !-----Offset if(i_offset==0) offset=0.0 if(i_offset==1) offset=int(npdf/2)*step !-----Pick face 5 f = 5 vol=atan(1.0) do e=1,nelv do k=1,nz1 do j=1,ny1 do i=1,nx1 wght= (zm1(i,j,k+1,e)-zm1(i,j,k,e)) * area(i,j,f,e) mpi_allreduce) call gop(pdf,work,'+ ',npdf) !------------------------------------------------------------ if(nid.eq.0)then if(i_name.eq.1)OPEN(10,file="pdf_uzte.dat",position="append") if(i_name.eq.2)OPEN(10,file="pdf_epst.dat",position="append") if(i_name.eq.3)OPEN(10,file="pdf_epsv.dat",position="append") if(i_name.eq.4)OPEN(10,file="pdf_temp.dat",position="append") if(i_name.eq.5)OPEN(10,file="pdf_dtdz.dat",position="append") do ipdf=1,npdf write(10,*) (ipdf-1)*step-offset, pdf(ipdf) enddo CLOSE(10) endif return end Thanks in advance and best wishes, Joerg. ---------------------------------------------------- Joerg Schumacher Heisenberg Professor for Theoretical Fluid Mechanics Institute of Thermodynamics and Fluid Mechanics Department of Mechanical Engineering Ilmenau University of Technology P.O. Box 100565 D-98684 Ilmenau Germany E-mail: joerg.schumacher at tu-ilmenau.de http://www.tu-ilmenau.de/tsm Phone: +49-3677-69-2428 Fax: +49-3677-69-2411 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Dec 17 10:33:17 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 17 Dec 2012 10:33:17 -0600 (CST) Subject: [Nek5000-users] Probability Density Function In-Reply-To: References: Message-ID: Hi Joerg, For a weight, I would just use the diagonal mass matrix, bm1(i,j,k,e) , which corresponds precisely to the volume associated with a gridpoint. I don't know why your weights went negative --- assuming that your mesh was generated with n2to3, it would seem that they should indeed be positive. Paul On Mon, 17 Dec 2012, nek5000-users at lists.mcs.anl.gov wrote: > > > Dear Neks, > > I want to calculate the probability density function of > a scalar field ff in the attached subroutine. > Since the element mesh is > nonuniform I have to assign a weight "wght" with each grid point of > ff. > The weight is given by the volume of the associated grid cell. > Coordinates of x,y,z of all vertices > (primary and secondary nodes) are > stored in xm1,ym1,zm1 as far as I know. > This weight turns out to have > in parts negative values which is unphysical. What went wrong? > > > subroutine pdf_calc(ff,step,i_offset,i_name) > include 'SIZE' > include > 'TOTAL' > > parameter(npdf=501) > > real ff(lx1,ly1,lz1,lelt) > real > pdf(npdf) > real work(npdf) > real val, vol, offset, wght > > integer > e,eg,ex,ey,ez,f > > !-----Set arrays to zero > call rzero(pdf,npdf) > call > rzero(work,npdf) > > !-----Offset > if(i_offset==0) offset=0.0 > > if(i_offset==1) offset=int(npdf/2)*step > > !-----Pick face 5 > f = 5 > > > vol=atan(1.0) > > do e=1,nelv > do k=1,nz1 > do j=1,ny1 > do i=1,nx1 > wght= > (zm1(i,j,k+1,e)-zm1(i,j,k,e)) * area(i,j,f,e) mpi_allreduce) > call > gop(pdf,work,'+ > ',npdf) > > !------------------------------------------------------------ > > if(nid.eq.0)then > > > if(i_name.eq.1)OPEN(10,file="pdf_uzte.dat",position="append") > > if(i_name.eq.2)OPEN(10,file="pdf_epst.dat",position="append") > > if(i_name.eq.3)OPEN(10,file="pdf_epsv.dat",position="append") > > if(i_name.eq.4)OPEN(10,file="pdf_temp.dat",position="append") > > if(i_name.eq.5)OPEN(10,file="pdf_dtdz.dat",position="append") > > do > ipdf=1,npdf > write(10,*) (ipdf-1)*step-offset, pdf(ipdf) > enddo > > CLOSE(10) > > endif > > return > end > > Thanks in advance and best wishes, > Joerg. > > ---------------------------------------------------- > Joerg > Schumacher > > Heisenberg Professor for Theoretical Fluid > Mechanics > Institute of Thermodynamics and Fluid Mechanics > Department of > Mechanical Engineering > Ilmenau University of Technology > P.O. Box 100565 > > D-98684 Ilmenau > Germany > > E-mail: > joerg.schumacher at tu-ilmenau.de > http://www.tu-ilmenau.de/tsm > Phone: > +49-3677-69-2428 > Fax: +49-3677-69-2411 > From nek5000-users at lists.mcs.anl.gov Mon Dec 17 13:08:00 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 17 Dec 2012 20:08:00 +0100 Subject: [Nek5000-users] Probability Density Function In-Reply-To: References: Message-ID: Hi Paul, thanks. It might be that the reason for the negative weights is that zm1(i,j,k+1,e) exceeds the bounds >> do e=1,nelv >> do k=1,nz1 >> do j=1,ny1 >> do i=1,nx1 >> wght=(zm1(i,j,k+1,e)-zm1(i,j,k,e)) * area(i,j,f,e) With a loop k=1,nz1-1 things seem to work fine. I will compare this with bm1(i,j,k,e). Joerg From nek5000-users at lists.mcs.anl.gov Thu Dec 27 05:13:33 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 27 Dec 2012 12:13:33 +0100 Subject: [Nek5000-users] mesh problems Message-ID: Dear Neks, I generated a big mesh with 7948800 elements for a cylindrical cell of aspect ratio 3, i.e. x between -1.5 and 1.5 y between -1.5 and 1.5 z between 0 and 1 prex, n2to3, reatore2, amgdump and genmap worked. The AMG preconditioning with go.m worked as well (runtime 3.5 weeks). prex started out of 3 basic elements which were refined with multi split into Element1: 90, 90 subelements Element2: 70, 90 Element3: 70, 90 stretch, r, factor 3 I started the job on BG/Q and get the following error messages in the output file: bash-4.1$ m G3_96.out.0 /----------------------------------------------------------\ | _ __ ______ __ __ ______ ____ ____ ____ | | / | / // ____// //_/ / ____/ / __ \ / __ \ / __ \ | | / |/ // __/ / ,< /___ \ / / / // / / // / / / | | / /| // /___ / /| | ____/ / / /_/ // /_/ // /_/ / | | /_/ |_//_____//_/ |_|/_____/ \____/ \____/ \____/ | | | |----------------------------------------------------------| | | | NEK5000: Open Source Spectral Element Solver | | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC | | Version: 1.0rc1 / SVN r838 | | Web: http://nek5000.mcs.anl.gov | | | \----------------------------------------------------------/ Number of processors: 65536 REAL wdsize : 8 INTEGER wdsize : 4 Beginning session: /homec/hil02/hil020/nek5_svn/g396_r097_Lx1_08_Ra1e9/G3_96.rea timer accuracy: 1.4962500E-07 sec read .rea file read .re2 file byte swap: T -0.2931277218E+36 6.543210030 nelgt/nelgv/lelt: 7948800 7948800 150 lx1 /lx2 /lx3 : 4 2 4 mapping elements to processors element load imbalance: 1 121 122 done :: mapping elements to processors reading mesh reading curved sides reading bc for ifld 1 reading bc for ifld 2 done :: read .re2 file 0 objects found done :: read .rea file 496.34 sec Reset the target Courant number to .5 setup mesh topology Right-handed check complete for 7948800 elements. OK. setvert3d: 4 152084809 215675209 152084809 152084809 call usrsetvert done :: usrsetvert gs_setup: 50336837 unique labels shared pairwise times (avg, min, max): 0.00330717 0.000218656 0.00853093 crystal router : 0.0077495 0.00761262 0.00818637 used all_to_all method: crystal router setupds time 6.1645E-01 seconds 0 4 152084809 7948800 8 max multiplicity done :: setup mesh topology call usrdat done :: usrdat generate geomerty data vol_t,vol_v: 7.06857958483581861 7.06857958483581861 done :: generate geomerty data call usrdat2 done :: usrdat2 regenerate geomerty data 1 vol_t,vol_v: 7.06857958483581861 7.06857958483581861 done :: regenerate geomerty data 1 verify mesh topology -1.50001142304138035 1.50001142290878886 Xrange -1.50001142298026835 1.50001142292693612 Yrange 0.000000000000000000E+00 1.00000000000000000 Zrange WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: i,j,k,ie: 4 2 1 954634 i,j,k,ie: 1 2 1 916744 i,j,k,ie: 2 4 2 972970 i,j,k,ie: 2 1 1 931570 WARNING1 Element mesh mismatch at: i,j,k,ie: 4 2 1 957874 WARNING1 Element mesh mismatch at: i,j,k,ie: 4 2 1 996664 Near X = -.12308168E-01 -.34092836 .60036000E-01, d: .12947845E-04 .00000000E+00 81.225474 WARNING1 Element mesh mismatch at: Near X = .11336871E-01 -.82826699 .61838637E-01, d: .00000000E+00 -.11766071E-04 88.069931 Near X = .97128875E-05 .82845591 .60036000E-01, d: .00000000E+00 -.20015559E-04 88.069931 i,j,k,ie: 2 1 1 981007 WARNING1 Element mesh mismatch at: i,j,k,ie: 2 1 1 939607 i,j,k,ie: 4 2 4 995854 WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: i,j,k,ie: 2 4 3 972989 WARNING1 Element mesh mismatch at: i,j,k,ie: 2 4 4 931590 Near X = .12193251E-01 .42841310 .66558003E-01, d: .00000000E+00 -.12947474E-04 81.991313 WARNING1 Element mesh mismatch at: i,j,k,ie: 4 2 4 916204 WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: i,j,k,ie: 1 2 4 958144 WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: Near X = .12320624E-01 .31593135 .73282003E-01, d: .12573222E-04 .00000000E+00 81.079569 i,j,k,ie: 3 2 4 541894 WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: i,j,k,ie: 2 1 1 981003 WARNING1 Element mesh mismatch at: i,j,k,ie: 2 4 1 939603 WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: i,j,k,ie: 2 4 4 890151 WARNING1 Element mesh mismatch at: Near X = -.62894639E-05 -1.1769232 .60036000E-01, d: .15284684E-04 .00000000E+00 92.459135 WARNING1 Element mesh mismatch at: Near X = .63923475E-05 1.1769232 .60036000E-01, d: .00000000E+00 -.15284684E-04 92.458255 i,j,k,ie: 3 2 4 2524 i,j,k,ie: 3 2 4 624964 Near X = -.10302672E-04 .82845591 .60036000E-01, d: .20015559E-04 .00000000E+00 88.062609 i,j,k,ie: 2 4 4 62171 i,j,k,ie: 2 4 4 600363 WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: WARNING1 Element mesh mismatch at: --------------------------------------------------------- and so on??. The job hangs at this position and does not continue. Can it be that the precision of the coordinate ranges is not sufficient? For a job that runs well (here an aspect ratio one cell as an example) I got in the output file the following coordinates. ?? verify mesh topology -0.500000000000000000 0.500000000000000000 Xrange -0.500000000000000000 0.500000000000000000 Yrange 0.000000000000000000E+00 1.00000000000000000 Zrange done :: verify mesh topology ?? i.e. precise bounds down to the last digit. Note also that I had to adapt the programs n2to3 and reatore2, e.g.: [josc1234 at reynolds n2to3]$ diff n2to3.f n2to3.f_orig 31c31 < parameter(nelm=99999) --- > parameter(nelm=9999) [josc1234 at reynolds reatore2]$ diff reatore2.f reatore2.f_orig 19c19 < parameter(lelt=10000000) --- > parameter(lelt=1000000) 118c118 I wonder if you have an idea where things went wrong? Is it already the prex? Thanks for your help in advance. Best regards, Joerg. From nek5000-users at lists.mcs.anl.gov Thu Dec 27 05:57:06 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 27 Dec 2012 05:57:06 -0600 (CST) Subject: [Nek5000-users] mesh problems In-Reply-To: References: Message-ID: Hi Joerg, We are presently working on all aspects of the workflow for large element counts. (Yours is > 2.5x larger than any previous ones that I'm aware of.) You can test your prex theory by running a case with just a few slabs in z. Typically I would have n2to3 build the mesh with fairly large spacing in z and then use usrdat2() to recompress to the desired z range --- the reason for this is that genmap needs to identify the mesh topology based on the mesh geometry (i.e., the vertex locations), which requires distinguishing "coincident" vertices by the Euclidean distance separating them. There are tolerances (as prompted in genmap) that give some control in making the proper distinction and the tolerance are relative, based on local edge length of the given elements. In any case, this is a possible source of the error you're encountering. Increasing the z spacing reduces the dimensionality of the difficulty so that z-separation is obvious. Regarding the long runtime for matlab - yes, this is possible. (Obviously, extending this phase to parallel execution is a high priority for us.) It's also possible that if the graph of the mesh were messed up (e.g., from genmap) then the matlab phase might take longer to find optimal coarsening/interpolation for amg. A reasonable stategy at this point might be to increase the polynomial order, which would allow, say, a factor (10/8)^3 or (12/10)^3 reduction in the number of elements you need and thus significantly cut down on some of the difficulties you're encountering. hth, Paul On Thu, 27 Dec 2012, nek5000-users at lists.mcs.anl.gov wrote: > Dear Neks, > > I generated a big mesh with 7948800 elements for a cylindrical cell of aspect ratio 3, i.e. > > x between -1.5 and 1.5 > y between -1.5 and 1.5 > z between 0 and 1 > > prex, n2to3, reatore2, amgdump and genmap worked. The AMG preconditioning with go.m worked as well (runtime 3.5 weeks). > > prex started out of 3 basic elements which were refined with multi split into > > Element1: 90, 90 subelements > Element2: 70, 90 > Element3: 70, 90 > stretch, r, factor 3 > > I started the job on BG/Q and get the following error messages in the output file: > > bash-4.1$ m G3_96.out.0 > /----------------------------------------------------------\ > | _ __ ______ __ __ ______ ____ ____ ____ | > | / | / // ____// //_/ / ____/ / __ \ / __ \ / __ \ | > | / |/ // __/ / ,< /___ \ / / / // / / // / / / | > | / /| // /___ / /| | ____/ / / /_/ // /_/ // /_/ / | > | /_/ |_//_____//_/ |_|/_____/ \____/ \____/ \____/ | > | | > |----------------------------------------------------------| > | | > | NEK5000: Open Source Spectral Element Solver | > | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC | > | Version: 1.0rc1 / SVN r838 | > | Web: http://nek5000.mcs.anl.gov | > | | > \----------------------------------------------------------/ > > > Number of processors: 65536 > REAL wdsize : 8 > INTEGER wdsize : 4 > > > Beginning session: > /homec/hil02/hil020/nek5_svn/g396_r097_Lx1_08_Ra1e9/G3_96.rea > > > timer accuracy: 1.4962500E-07 sec > > read .rea file > read .re2 file > byte swap: T -0.2931277218E+36 6.543210030 > nelgt/nelgv/lelt: 7948800 7948800 150 > lx1 /lx2 /lx3 : 4 2 4 > > mapping elements to processors > element load imbalance: 1 121 122 > done :: mapping elements to processors > > reading mesh > reading curved sides > reading bc for ifld 1 > reading bc for ifld 2 > done :: read .re2 file > > 0 objects found > done :: read .rea file 496.34 sec > > Reset the target Courant number to .5 > setup mesh topology > Right-handed check complete for 7948800 elements. OK. > setvert3d: 4 152084809 215675209 152084809 152084809 > call usrsetvert > done :: usrsetvert > > gs_setup: 50336837 unique labels shared > pairwise times (avg, min, max): 0.00330717 0.000218656 0.00853093 > crystal router : 0.0077495 0.00761262 0.00818637 > used all_to_all method: crystal router > setupds time 6.1645E-01 seconds 0 4 152084809 7948800 > 8 max multiplicity > done :: setup mesh topology > > call usrdat > done :: usrdat > > generate geomerty data > vol_t,vol_v: 7.06857958483581861 7.06857958483581861 > done :: generate geomerty data > > call usrdat2 > done :: usrdat2 > > regenerate geomerty data 1 > vol_t,vol_v: 7.06857958483581861 7.06857958483581861 > done :: regenerate geomerty data 1 > > verify mesh topology > -1.50001142304138035 1.50001142290878886 Xrange > -1.50001142298026835 1.50001142292693612 Yrange > 0.000000000000000000E+00 1.00000000000000000 Zrange > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > i,j,k,ie: 4 2 1 954634 > i,j,k,ie: 1 2 1 916744 > i,j,k,ie: 2 4 2 972970 > i,j,k,ie: 2 1 1 931570 > WARNING1 Element mesh mismatch at: > i,j,k,ie: 4 2 1 957874 > WARNING1 Element mesh mismatch at: > i,j,k,ie: 4 2 1 996664 > Near X = -.12308168E-01 -.34092836 .60036000E-01, d: .12947845E-04 .00000000E+00 81.225474 > WARNING1 Element mesh mismatch at: > Near X = .11336871E-01 -.82826699 .61838637E-01, d: .00000000E+00 -.11766071E-04 88.069931 > Near X = .97128875E-05 .82845591 .60036000E-01, d: .00000000E+00 -.20015559E-04 88.069931 > i,j,k,ie: 2 1 1 981007 > WARNING1 Element mesh mismatch at: > i,j,k,ie: 2 1 1 939607 > i,j,k,ie: 4 2 4 995854 > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > i,j,k,ie: 2 4 3 972989 > WARNING1 Element mesh mismatch at: > i,j,k,ie: 2 4 4 931590 > Near X = .12193251E-01 .42841310 .66558003E-01, d: .00000000E+00 -.12947474E-04 81.991313 > WARNING1 Element mesh mismatch at: > i,j,k,ie: 4 2 4 916204 > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > i,j,k,ie: 1 2 4 958144 > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > Near X = .12320624E-01 .31593135 .73282003E-01, d: .12573222E-04 .00000000E+00 81.079569 > i,j,k,ie: 3 2 4 541894 > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > i,j,k,ie: 2 1 1 981003 > WARNING1 Element mesh mismatch at: > i,j,k,ie: 2 4 1 939603 > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > i,j,k,ie: 2 4 4 890151 > WARNING1 Element mesh mismatch at: > Near X = -.62894639E-05 -1.1769232 .60036000E-01, d: .15284684E-04 .00000000E+00 92.459135 > WARNING1 Element mesh mismatch at: > Near X = .63923475E-05 1.1769232 .60036000E-01, d: .00000000E+00 -.15284684E-04 92.458255 > i,j,k,ie: 3 2 4 2524 > i,j,k,ie: 3 2 4 624964 > Near X = -.10302672E-04 .82845591 .60036000E-01, d: .20015559E-04 .00000000E+00 88.062609 > i,j,k,ie: 2 4 4 62171 > i,j,k,ie: 2 4 4 600363 > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > WARNING1 Element mesh mismatch at: > --------------------------------------------------------- > and so on??. > > > The job hangs at this position and does not continue. Can it be that the precision of the coordinate ranges is not sufficient? > For a job that runs well (here an aspect ratio one cell as an example) I got in the output file the following coordinates. > > ?? > > verify mesh topology > -0.500000000000000000 0.500000000000000000 Xrange > -0.500000000000000000 0.500000000000000000 Yrange > 0.000000000000000000E+00 1.00000000000000000 Zrange > done :: verify mesh topology > > ?? > > i.e. precise bounds down to the last digit. > Note also that I had to adapt the programs n2to3 and reatore2, e.g.: > > [josc1234 at reynolds n2to3]$ diff n2to3.f n2to3.f_orig > 31c31 > < parameter(nelm=99999) > --- >> parameter(nelm=9999) > > [josc1234 at reynolds reatore2]$ diff reatore2.f reatore2.f_orig > 19c19 > < parameter(lelt=10000000) > --- >> parameter(lelt=1000000) > 118c118 > > > I wonder if you have an idea where things went wrong? Is it already the prex? > Thanks for your help in advance. > > Best regards, Joerg. > > > _______________________________________________ > 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 Dec 27 06:43:26 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 27 Dec 2012 13:43:26 +0100 Subject: [Nek5000-users] mesh problems In-Reply-To: References: Message-ID: Hi Paul, > We are presently working on all aspects of the workflow for large > element counts. (Yours is > 2.5x larger than any previous ones that I'm aware of.) > > You can test your prex theory by running a case with just > a few slabs in z. > > Typically I would have n2to3 build the mesh with fairly > large spacing in z and then use usrdat2() to recompress > to the desired z range --- the reason for this is that > genmap needs to identify the mesh topology based on the > mesh geometry (i.e., the vertex locations), which requires > distinguishing "coincident" vertices by the Euclidean > distance separating them. There are tolerances (as prompted > in genmap) that give some control in making the proper > distinction and the tolerance are relative, based on local > edge length of the given elements. In any case, this is a > possible source of the error you're encountering. Increasing > the z spacing reduces the dimensionality of the difficulty > so that z-separation is obvious. > I faced the same trouble with 2.17 million elements. Let me follow your suggestion and set up a mesh in cell with z between 0 and 3 while keeping the x-y mesh exactly the same, just to check if the same errors occur. > Regarding the long runtime for matlab - yes, this is possible. > (Obviously, extending this phase to parallel execution is a > high priority for us.) It's also possible that if the graph > of the mesh were messed up (e.g., from genmap) then the matlab > phase might take longer to find optimal coarsening/interpolation > for amg. > Yes, the one might be correlated with the other. For 2.17 million elements it took 4 hours instead of nearly four weeks. > A reasonable stategy at this point might be to increase the polynomial order, which would allow, say, a factor (10/8)^3 or (12/10)^3 reduction in the number of elements you need and thus significantly cut down on some of the difficulties you're encountering. > This will help a bit, I agree. Thanks, Joerg.