From nek5000-users at lists.mcs.anl.gov Tue May 3 05:08:58 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 03 May 2011 12:08:58 +0200 Subject: [Nek5000-users] Turbulent shear layer Message-ID: Hi, I'm trying to set up a turbulent shear layer similiar to the test cases used in http://www.springerlink.com/content/h7263g6268875412/fulltext.pdf (DNS of Compressible Inert and Infinitely Fast Reacting Mixing Layers, Mahle, Sesterhenn, Friedrich; New Res. in Num. and Exp. Fluid Mech. VI, NNFM 96, pp. 372-380, 2007) and http://maeresearch.ucsd.edu/SARKAR/PantanoSW_jfm_03.pdf (Mixing of a conserved scalar in a turbulent reacting shear layer, Pantano, Sarkar, Williams; J. Fluid Mech. (2003), vol. 481, pp. 291-328). However, my simulations converge to the laminar flow and/or explode. I know that the papers used compressible flows, but I hoped that it may work for incompressible flows as well. I'm not interested chemical reactions since I just want to observe the mixing of passive scalars in a turbulent flow using DNS. It is a 2D test case at the moment so it can be run on my small workstation (only 4 Cores). It is a channel ([0,2]x[0,1]) with periodic boundary conditions in x-direction and moving walls with velocity u=1 on the bottom side of the mesh and u=-1 on the upper side. The flow is initialized with a hyperbolic tangent profile with random perturbations added. The mesh has 64x32 elements with p=9. I made some runs with to different settings. One case is only the unsteady NS equation and in the second case the temperature and one passive scalar are added. In the first case, the flow gets laminar and after approx. 269000 iterations the solution explodes. In the second case, the solver has trouble with the flow although I use the same initial and boundary conditions for the velocity field. It takes 384 time steps until the divergence of the velocity field is smaller than 1e-1 while in the first case it only takes six time steps. Furthermore, the Helmholtz solver for the passive scalar fails right from the beginning. It does not matter if I initialize the scalar with zeros or something else. The temperature field doesn't make problems like this. The velocity field also looks a bit strange. You can identify the edges of the elements and the solution begins to blow up pretty soon (approx. 20000 time steps). The meshes was generated using genbox and prenek/prex. All files are attached to the mail. Has anyone experienced a similar problem or can give me a hint what I'm doing wrong? I also tried other cases, but the flows always gets laminar or explodes so it is seems to be my fault. If anyone has an idea for a better/easier test case I would appreciate any suggestions. I just want a DNS of a turbulent flow in an easy geometry that can be handled with about 32 CPUs when running as 3D case. Just two more things: 1. Why can't I join the mailing list? I think I subscribed 2-3 times, but I don't get any mails. 2. Where can I report (probably) useful information or small bugs that are not directly related to the solver? Thanks! Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 64x32_withscalar.tar.gz Type: application/x-gzip Size: 135477 bytes Desc: 64x32_withscalar.tar.gz URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 64x32_noscalar.tar.gz Type: application/x-gzip Size: 61783 bytes Desc: 64x32_noscalar.tar.gz URL: From nek5000-users at lists.mcs.anl.gov Wed May 4 08:43:53 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 4 May 2011 08:43:53 -0500 (CDT) Subject: [Nek5000-users] Turbulent shear layer In-Reply-To: References: Message-ID: Alex, It seems that the reason you're unable to subscribe is that email to your return address is rejected? Can you try from a different email address? >From your description below - my initial guess about what is happening is that the 2D case probably should relaminarize, whereas 3D would not. In the case where it does relaminarize, if it also ultimately reaches a steady state, then a flaw in my implementation of the projection scheme (Fischer CMAME '98) will result in linearly-dependent vectors and blow-up. I expect that this is the issue you encounter at large step counts. It's something that is on our to-be-fixed list, but it's not encountered in unsteady cases that constitute the bulk of the code usage. Hope this helps. Paul On Tue, 3 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I'm trying to set up a turbulent shear layer similiar to the test cases used > in http://www.springerlink.com/content/h7263g6268875412/fulltext.pdf (DNS of > Compressible Inert and Infinitely Fast Reacting Mixing Layers, Mahle, > Sesterhenn, Friedrich; New Res. in Num. and Exp. Fluid Mech. VI, NNFM 96, pp. > 372-380, 2007) and http://maeresearch.ucsd.edu/SARKAR/PantanoSW_jfm_03.pdf > (Mixing of a conserved scalar in a turbulent reacting shear layer, Pantano, > Sarkar, Williams; J. Fluid Mech. (2003), vol. 481, pp. 291-328). However, my > simulations converge to the laminar flow and/or explode. I know that the > papers used compressible flows, but I hoped that it may work for > incompressible flows as well. I'm not interested chemical reactions since I > just want to observe the mixing of passive scalars in a turbulent flow using > DNS. > > It is a 2D test case at the moment so it can be run on my small workstation > (only 4 Cores). It is a channel ([0,2]x[0,1]) with periodic boundary > conditions in x-direction and moving walls with velocity u=1 on the bottom > side of the mesh and u=-1 on the upper side. The flow is initialized with a > hyperbolic tangent profile with random perturbations added. The mesh has > 64x32 elements with p=9. I made some runs with to different settings. One > case is only the unsteady NS equation and in the second case the temperature > and one passive scalar are added. > > In the first case, the flow gets laminar and after approx. 269000 iterations > the solution explodes. In the second case, the solver has trouble with the > flow although I use the same initial and boundary conditions for the velocity > field. It takes 384 time steps until the divergence of the velocity field is > smaller than 1e-1 while in the first case it only takes six time steps. > Furthermore, the Helmholtz solver for the passive scalar fails right from the > beginning. It does not matter if I initialize the scalar with zeros or > something else. The temperature field doesn't make problems like this. The > velocity field also looks a bit strange. You can identify the edges of the > elements and the solution begins to blow up pretty soon (approx. 20000 time > steps). > > The meshes was generated using genbox and prenek/prex. All files are > attached to the mail. > > Has anyone experienced a similar problem or can give me a hint what I'm doing > wrong? I also tried other cases, but the flows always gets laminar or > explodes so it is seems to be my fault. If anyone has an idea for a > better/easier test case I would appreciate any suggestions. I just want a DNS > of a turbulent flow in an easy geometry that can be handled with about 32 > CPUs when running as 3D case. > > Just two more things: > 1. Why can't I join the mailing list? I think I subscribed 2-3 times, but I > don't get any mails. 2. Where can I report (probably) useful information or > small bugs that are not directly related to the solver? > > Thanks! > Alex > > > From nek5000-users at lists.mcs.anl.gov Thu May 5 06:11:41 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 5 May 2011 13:11:41 +0200 Subject: [Nek5000-users] Adjoint perturbation Message-ID: Hi Nek's, I am interested into the linear adjoint perturbation. The equations read: -du/dt = (U.Grad) u - transpose(Grad(U)) u + 1/Re Laplacian(u) - grad(p) div(u) = 0 Assuming t' = T-t, one can rewrite: du/dt' = (U.Grad) u - transpose(Grad(U)) u + 1/Re Laplacian(u) - grad(p) Only small modifications to the perturbation mode are necessary, mainly to evaluate the tranpose gradient terms. Here is what I've done to evaluate these: subroutine conv_adj(conv_x,conv_y,conv_z,u_x,u_y,u_z) ! used to be conv1n include 'SIZE' include 'DXYZ' include 'INPUT' include 'GEOM' include 'SOLN' include 'TSTEP' parameter (lt=lx1*ly1*lz1*lelt) real u_x (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) real u_y (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) real u_z (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) real u_xx (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) real u_xy (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) real u_xz (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) real u_yx (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) real u_yy (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) real u_yz (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) real u_zx (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) real u_zy (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) real u_zz (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) real conv_x (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) real conv_y (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) real conv_z (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) *call gradm1(u_xx,u_xy,u_xz,u_x)* * call gradm1(u_yx,u_yy,u_yz,u_y)* * call gradm1(u_zx,u_zy,u_zz,u_z)* * * * conv_x = vx*u_xx + vy*u_yx + vz*u_zx* * conv_y = vx*u_xy + vy*u_yy + vz*u_zy* * conv_z = vx*u_xz + vy*u_yz + vz*u_zz* return end However, I'm not sure I've done it properly or not (arrays declaration for instance). Especially, I had no idea wheter I have to use the gradm1 subroutine or its weak counterpart wgradm1. Finally in perturb.f, I've slightly change the advap subroutine the following way: subroutine advabp C C Eulerian scheme, add convection term to forcing function C at current time step. C include 'SIZE' include 'INPUT' include 'SOLN' include 'MASS' include 'TSTEP' C COMMON /SCRNS/ TA1 (LX1*LY1*LZ1*LELV) $ , TA2 (LX1*LY1*LZ1*LELV) $ , TA3 (LX1*LY1*LZ1*LELV) $ , TB1 (LX1*LY1*LZ1*LELV) $ , TB2 (LX1*LY1*LZ1*LELV) $ , TB3 (LX1*LY1*LZ1*LELV) C ntot1 = nx1*ny1*nz1*nelv ntot2 = nx2*ny2*nz2*nelv c if (if3d) then call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save velocity call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),vzp(1,jp)) ! U <-- du * call conv_adj(ta1,ta2,ta3,tb1,tb2,tb3)* * call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity* *c* * do i=1,ntot1* * tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield)* * bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i)* * bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i)* * bfzp(i,jp) = bfzp(i,jp)-tmp*ta3(i)* * enddo* c call convop (ta1,vxp(1,jp)) ! U.grad dU call convop (ta2,vyp(1,jp)) call convop (ta3,vzp(1,jp)) c do i=1,ntot1 tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) *bfxp(i,jp) = bfxp(i,jp) + tmp*ta1(i)* * bfyp(i,jp) = bfyp(i,jp) + tmp*ta2(i)* * bfzp(i,jp) = bfzp(i,jp) + tmp*ta3(i)* enddo c else ! 2D c call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save velocity call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),vzp(1,jp)) ! U <-- dU call convop (ta1,tb1) ! du.grad U call convop (ta2,tb2) call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity c do i=1,ntot1 tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) enddo c call convop (ta1,vxp(1,jp)) ! U.grad dU call convop (ta2,vyp(1,jp)) c do i=1,ntot1 tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) enddo c endif c return end Any help to spot potential erros or to speed up these operation would be highly appreciated. Best regards, -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri May 6 08:49:14 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 6 May 2011 08:49:14 -0500 (CDT) Subject: [Nek5000-users] Adjoint perturbation In-Reply-To: References: Message-ID: Dear Jean-Christophe, My apologies for the delay in getting back to you - we've been saturated with proposal writing on our end. Your approach looks reasonable -- though I would avoid at all costs the f90 type declarations and stick with the std f77-based approach to be consistent with the code. I'll look into your proposed approach. I should point out also that we've recently had an adjoint solver developed by some colleagues that is ready to go into the svn repo. I've just been delayed in getting it in because of travel and proposals. My hope is that this will be in the repo in about 10-15 days. Regarding the proper choice of gradm1 vs wgradm1, the question ultimately comes down to the degree of differentiability of the input --- functions in nek are only C0 and hence one-time differentiable. This applies also to the test functions. Thus, the std. practice is to move a derivative from the solution to the test functions (i.e., to use the weak derivative) whenever the solution is to be differentiated twice. Regards, Paul On Thu, 5 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > > I am interested into the linear adjoint perturbation. The equations read: > > -du/dt = (U.Grad) u - transpose(Grad(U)) u + 1/Re Laplacian(u) - grad(p) > > div(u) = 0 > > Assuming t' = T-t, one can rewrite: du/dt' = (U.Grad) u - transpose(Grad(U)) > u + 1/Re Laplacian(u) - grad(p) > Only small modifications to the perturbation mode are necessary, mainly to > evaluate the tranpose gradient terms. Here is what I've done to evaluate > these: > > subroutine conv_adj(conv_x,conv_y,conv_z,u_x,u_y,u_z) ! used to be > conv1n > > > include 'SIZE' > > include 'DXYZ' > > include 'INPUT' > > include 'GEOM' > > include 'SOLN' > > include 'TSTEP' > > > parameter (lt=lx1*ly1*lz1*lelt) > > real u_x (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > > real u_y (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > > real u_z (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > > > real u_xx (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > > real u_xy (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > > real u_xz (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > > > real u_yx (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) > > real u_yy (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) > > real u_yz (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) > > > real u_zx (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) > > real u_zy (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) > > real u_zz (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) > > > real conv_x (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) > > real conv_y (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) > > real conv_z (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) > > > *call gradm1(u_xx,u_xy,u_xz,u_x)* > > * call gradm1(u_yx,u_yy,u_yz,u_y)* > > * call gradm1(u_zx,u_zy,u_zz,u_z)* > > * > * > > * conv_x = vx*u_xx + vy*u_yx + vz*u_zx* > > * conv_y = vx*u_xy + vy*u_yy + vz*u_zy* > > * conv_z = vx*u_xz + vy*u_yz + vz*u_zz* > > > return > > end > > However, I'm not sure I've done it properly or not (arrays declaration for > instance). Especially, I had no idea wheter I have to use the gradm1 > subroutine or its weak counterpart wgradm1. Finally in perturb.f, I've > slightly change the advap subroutine the following way: > > subroutine advabp > > C > > C Eulerian scheme, add convection term to forcing function > > C at current time step. > > C > > include 'SIZE' > > include 'INPUT' > > include 'SOLN' > > include 'MASS' > > include 'TSTEP' > > C > > COMMON /SCRNS/ TA1 (LX1*LY1*LZ1*LELV) > > $ , TA2 (LX1*LY1*LZ1*LELV) > > $ , TA3 (LX1*LY1*LZ1*LELV) > > $ , TB1 (LX1*LY1*LZ1*LELV) > > $ , TB2 (LX1*LY1*LZ1*LELV) > > $ , TB3 (LX1*LY1*LZ1*LELV) > > C > > ntot1 = nx1*ny1*nz1*nelv > > ntot2 = nx2*ny2*nz2*nelv > > c > > if (if3d) then > > call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save > velocity > > call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),vzp(1,jp)) ! U <-- du > > * call conv_adj(ta1,ta2,ta3,tb1,tb2,tb3)* > > * call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity* > > *c* > > * do i=1,ntot1* > > * tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield)* > > * bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i)* > > * bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i)* > > * bfzp(i,jp) = bfzp(i,jp)-tmp*ta3(i)* > > * enddo* > > c > > call convop (ta1,vxp(1,jp)) ! U.grad dU > > call convop (ta2,vyp(1,jp)) > > call convop (ta3,vzp(1,jp)) > > c > > do i=1,ntot1 > > tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) > > *bfxp(i,jp) = bfxp(i,jp) + tmp*ta1(i)* > > * bfyp(i,jp) = bfyp(i,jp) + tmp*ta2(i)* > > * bfzp(i,jp) = bfzp(i,jp) + tmp*ta3(i)* > > enddo > > c > > else ! 2D > > c > > call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save > velocity > > call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),vzp(1,jp)) ! U <-- dU > > call convop (ta1,tb1) ! du.grad U > > call convop (ta2,tb2) > > call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity > > c > > do i=1,ntot1 > > tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) > > bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) > > bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) > > enddo > > c > > call convop (ta1,vxp(1,jp)) ! U.grad dU > > call convop (ta2,vyp(1,jp)) > > c > > do i=1,ntot1 > > tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) > > bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) > > bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) > > enddo > > c > > endif > > c > > return > > end > > > Any help to spot potential erros or to speed up these operation would be > highly appreciated. > > Best regards, > -- > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Mon May 9 05:27:06 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 9 May 2011 05:27:06 -0500 (CDT) Subject: [Nek5000-users] Mesh-Generation - Poisson solver In-Reply-To: <4DC7B5A7.4070103@mech.kth.se> References: <4DC7B5A7.4070103@mech.kth.se> Message-ID: Hi David, The solver computes the displacement for the entire mesh --- That was the goal of using the PDE-based approach and is important if you have very thin meshes near the displaced boundary. To blend to the interior, I use the Gordon Hall scheme (also known as trans-finite interpolation) on each element. This can usually be invoked with the simple call: call fix_geom I confess I've not tried fix_geom for 2D but I think it should work. It is not a bad idea to call fix_geom after calling the Poisson clean up that you have below --- the advantage of fix_geom is that it generally will get points back onto a proper GLL displacement. (This is by no means rigorous... it's been developed more or less on a case-by-case basis.) Paul On Mon, 9 May 2011, David Tempelmann wrote: > Hi Paul, > > I've been using the "blending"-feature for the wing mesh that I got from > you quite a bit now and it works nicely. However, I thought I had > understood what it does but now I realized that I do not. > > The following part of the code that I got from you does the blending by > solving a Poisson equation if I understand it right. In the beginning I > thought that it solves a Poisson equation for each element where the > coordinates of the GLL points along the edges are given as boundary > conditions. But now I realized that also points at the upper edge (edge > 3) of some elements (mostly the first 2-3 above the wall) are displaced. > That means that those points can not be prescribed as boundary conditions. > > Could you explain what kind of equation you solve and what it does to > the coordinates? > > Thanks a lot! > > David > > subroutine move_sides(xmn,ymn,zmn) ! Blend xmn --> xm1 > include 'SIZE' > include 'TOTAL' > > parameter (ltt=lx1*ly1*lz1*lelt) > common /scrns/ h1(ltt),h2(ltt),ta(ltt),tb(ltt) > > character*4 name > > call set_tmsk(tmask) > > > do ipass=1,ndim ! x- and y-component of displacement > > write(name,4) ipass > 4 format('mov',i1) > > n = nx1*ny1*nz1*nelv > imesh = 1 > ifield = 1 > isd = 1 > call rzero(t ,n) > call rzero(bq,n) > call rone (h1,n) > call rzero(h2,n) > > if (ipass.eq.1) call sub3(tb,xmn,xm1,n) ! Boundary displacement > if (ipass.eq.2) call sub3(tb,ymn,ym1,n) > if (ipass.eq.3) call sub3(tb,zmn,zm1,n) > > call axhelm (ta,tb,h1,h2,imesh,isd) > call chsign (ta,n) > > tolmv = 1.e-5 > nmxh = 100 > > c Blend displacement into interior > call hmholtz(name,t,ta,h1,h2,tmask,vmult,imesh,tolmv,nmxh,isd) > > if (ipass.eq.1) call add3(vx,t,tb,n) ! vx = t+t_bdry = total > displacement > if (ipass.eq.2) call add3(vy,t,tb,n) ! vy = t+t_bdry > if (ipass.eq.3) call add3(vz,t,tb,n) ! vz = t+t_bdry > > enddo > > call add2(xm1,vx,n) ! New mesh > call add2(ym1,vy,n) > call add2(zm1,vz,n) > > call outpost(vx,vy,vz,pr,t,' ') > > return > end > From nek5000-users at lists.mcs.anl.gov Wed May 11 13:44:10 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 11 May 2011 11:44:10 -0700 Subject: [Nek5000-users] Running Simulations in Parallel with nekbmpi Message-ID: Hello, I recently built nek on a new machine with an Intel i7. I think I have all the necessary libraries and packages installed but it looks like nek is trying to run 4 processors in series when I use nekbmpi. Has anyone experienced a similar problem? Below is the header of my logfile for a case where I tried running with two processors. Thanks, John /----------------------------------------------------------\\ | _ __ ______ __ __ ______ ____ ____ ____ | | / | / // ____// //_/ / ____/ / __ \\ / __ \\ / __ \\ | | / |/ // __/ / ,< /___ \\ / / / // / / // / / / | | / /| // /___ / /| | ____/ / / /_/ // /_/ // /_/ / | | /_/ |_//_____//_/ |_|/_____/ \\____/ \\____/ \\____/ | | | |----------------------------------------------------------| | | | NEK5000: Open Source Spectral Element Solver | | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC | | Version: 1.0rc1 / SVN r684 | | Web: http://nek5000.mcs.anl.gov | | | \\----------------------------------------------------------/ Number of processors: 1 REAL wdsize : 8 INTEGER wdsize : 4 /----------------------------------------------------------\\ | _ __ ______ __ __ ______ ____ ____ ____ | | / | / // ____// //_/ / ____/ / __ \\ / __ \\ / __ \\ | | / |/ // __/ / ,< /___ \\ / / / // / / // / / / | | / /| // /___ / /| | ____/ / / /_/ // /_/ // /_/ / | | /_/ |_//_____//_/ |_|/_____/ \\____/ \\____/ \\____/ | | | |----------------------------------------------------------| | | | NEK5000: Open Source Spectral Element Solver | | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC | | Version: 1.0rc1 / SVN r684 | | Web: http://nek5000.mcs.anl.gov | | | \\----------------------------------------------------------/ Number of processors: 1 REAL wdsize : 8 INTEGER wdsize : 4 Beginning session: /home/akerleyj/repos/nek5_svn/research/flatchan_Re1600/fc1d.rea timer accuracy: 0.0000000E+00 sec read .rea file nelgt/nelgv/lelt: 1510 1510 1600 lx1 /lx2 /lx3 : 8 8 8 mapping elements to processors -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 11 13:47:06 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 11 May 2011 13:47:06 -0500 Subject: [Nek5000-users] Running Simulations in Parallel with nekbmpi In-Reply-To: References: Message-ID: Hey John, Just a initial thought, but have you set "lp" in the SIZE file to 2? Josh On Wed, May 11, 2011 at 1:44 PM, wrote: > Hello, > > I recently built nek on a new machine with an Intel i7.? I think I have all > the necessary libraries and packages installed but it looks like nek is > trying to run 4 processors in series when I use nekbmpi.?? Has anyone > experienced a similar problem?? Below is the header of my logfile for a case > where I tried running with two processors. > > > Thanks, > > John > > /----------------------------------------------------------\\ > |????? _?? __ ______ __ __? ______? ____?? ____?? ____???? | > |???? / | / // ____// //_/ / ____/ / __ \\ / __ \\ / __ \\??? | > |??? /? |/ // __/? / , |?? / /|? // /___ / /| | ____/ / / /_/ // /_/ // /_/ /???? | > |? /_/ |_//_____//_/ |_|/_____/? \\____/ \\____/ \\____/????? | > |????????????????????????????????????????????????????????? | > |----------------------------------------------------------| > |????????????????????????????????????????????????????????? | > | NEK5000:? Open Source Spectral Element Solver??????????? | > | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC??????????? | > | Version:? 1.0rc1 / SVN r684????????????????????????????? | > | Web:????? http://nek5000.mcs.anl.gov???????????????????? | > |????????????????????????????????????????????????????????? | > \\----------------------------------------------------------/ > > > ?Number of processors:?????????? 1 > ?REAL??? wdsize????? :?????????? 8 > ?INTEGER wdsize????? :?????????? 4 > /----------------------------------------------------------\\ > |????? _?? __ ______ __ __? ______? ____?? ____?? ____???? | > |???? / | / // ____// //_/ / ____/ / __ \\ / __ \\ / __ \\??? | > |??? /? |/ // __/? / , |?? / /|? // /___ / /| | ____/ / / /_/ // /_/ // /_/ /???? | > |? /_/ |_//_____//_/ |_|/_____/? \\____/ \\____/ \\____/????? | > |????????????????????????????????????????????????????????? | > |----------------------------------------------------------| > |????????????????????????????????????????????????????????? | > | NEK5000:? Open Source Spectral Element Solver??????????? | > | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC??????????? | > | Version:? 1.0rc1 / SVN r684????????????????????????????? | > | Web:????? http://nek5000.mcs.anl.gov???????????????????? | > |????????????????????????????????????????????????????????? | > \\----------------------------------------------------------/ > > > ?Number of processors:?????????? 1 > ?REAL??? wdsize????? :?????????? 8 > ?INTEGER wdsize????? :?????????? 4 > > > ? Beginning session: > > /home/akerleyj/repos/nek5_svn/research/flatchan_Re1600/fc1d.rea > > > ?timer accuracy:?? 0.0000000E+00 sec > > ?read .rea file > ?nelgt/nelgv/lelt:???? 1510???? 1510???? 1600 > ?lx1? /lx2? /lx3 :??????? 8??????? 8??????? 8 > > ?mapping elements to processors > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Wed May 11 13:55:03 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 11 May 2011 20:55:03 +0200 Subject: [Nek5000-users] Running Simulations in Parallel with nekbmpi In-Reply-To: References: Message-ID: John, Did you compile Nek5000 with MPI support (IFMPI=true in makenek)? -Stefan On 5/11/11, nek5000-users at lists.mcs.anl.gov wrote: > Hey John, > > Just a initial thought, but have you set "lp" in the SIZE file to 2? > > Josh > > On Wed, May 11, 2011 at 1:44 PM, wrote: >> Hello, >> >> I recently built nek on a new machine with an Intel i7.? I think I have >> all >> the necessary libraries and packages installed but it looks like nek is >> trying to run 4 processors in series when I use nekbmpi.?? Has anyone >> experienced a similar problem?? Below is the header of my logfile for a >> case >> where I tried running with two processors. >> >> >> Thanks, >> >> John >> >> /----------------------------------------------------------\\ >> |????? _?? __ ______ __ __? ______? ____?? ____?? ____???? | >> |???? / | / // ____// //_/ / ____/ / __ \\ / __ \\ / __ \\??? | >> |??? /? |/ // __/? / ,> |?? / /|? // /___ / /| | ____/ / / /_/ // /_/ // /_/ /???? | >> |? /_/ |_//_____//_/ |_|/_____/? \\____/ \\____/ \\____/????? | >> |????????????????????????????????????????????????????????? | >> |----------------------------------------------------------| >> |????????????????????????????????????????????????????????? | >> | NEK5000:? Open Source Spectral Element Solver??????????? | >> | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC??????????? | >> | Version:? 1.0rc1 / SVN r684????????????????????????????? | >> | Web:????? http://nek5000.mcs.anl.gov???????????????????? | >> |????????????????????????????????????????????????????????? | >> \\----------------------------------------------------------/ >> >> >> ?Number of processors:?????????? 1 >> ?REAL??? wdsize????? :?????????? 8 >> ?INTEGER wdsize????? :?????????? 4 >> /----------------------------------------------------------\\ >> |????? _?? __ ______ __ __? ______? ____?? ____?? ____???? | >> |???? / | / // ____// //_/ / ____/ / __ \\ / __ \\ / __ \\??? | >> |??? /? |/ // __/? / ,> |?? / /|? // /___ / /| | ____/ / / /_/ // /_/ // /_/ /???? | >> |? /_/ |_//_____//_/ |_|/_____/? \\____/ \\____/ \\____/????? | >> |????????????????????????????????????????????????????????? | >> |----------------------------------------------------------| >> |????????????????????????????????????????????????????????? | >> | NEK5000:? Open Source Spectral Element Solver??????????? | >> | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC??????????? | >> | Version:? 1.0rc1 / SVN r684????????????????????????????? | >> | Web:????? http://nek5000.mcs.anl.gov???????????????????? | >> |????????????????????????????????????????????????????????? | >> \\----------------------------------------------------------/ >> >> >> ?Number of processors:?????????? 1 >> ?REAL??? wdsize????? :?????????? 8 >> ?INTEGER wdsize????? :?????????? 4 >> >> >> ? Beginning session: >> >> /home/akerleyj/repos/nek5_svn/research/flatchan_Re1600/fc1d.rea >> >> >> ?timer accuracy:?? 0.0000000E+00 sec >> >> ?read .rea file >> ?nelgt/nelgv/lelt:???? 1510???? 1510???? 1600 >> ?lx1? /lx2? /lx3 :??????? 8??????? 8??????? 8 >> >> ?mapping elements to processors >> >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> > > > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed May 11 14:25:47 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 11 May 2011 12:25:47 -0700 Subject: [Nek5000-users] Running Simulations in Parallel with nekbmpi Message-ID: Hi, I have lp=512 in SIZE, and I did compile with IFMPI=true. I recompiled yesterday because I thought this may be the case, but I was still getting the same error. When I first start a simulation and run top, it shows four processors running nek5000, but this changes to one processor after a few seconds. Thanks, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 16 07:16:20 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 16 May 2011 07:16:20 -0500 (CDT) Subject: [Nek5000-users] Neek5000 variable viscosity case In-Reply-To: <4DD0F4B0.9010204@lav.mavt.ethz.ch> References: <4DD0F4B0.9010204@lav.mavt.ethz.ch> Message-ID: Dear Francesco, For low Mach, if you want var. viscosity you must also set ifexplvis to be true. This will treat the remaining part of the stress tensor explicitly, so that you do capture the physics of the full stress tensor. Now, a couple of comments --- The original explicit formulation, based on strong form developed by Stefan, worked well with our dyn. smag. model, but was not in exact agreement the PnPn-2 stress formulation until refined to convergence. I modified this to a weak form in January and it does now agree w/ PnPn-2, but the dyn. smag. tests that I've done do not work. I've been so busy for the past months with travel and proposal writing that I've not had a chance to understand why dyn. smag. appears to be broken. I'm hoping to resolve this shortly. Cheers, Paul On Mon, 16 May 2011, Francesco Lucci wrote: > Dear Paul, > > sorry to bother you but we need a clarification about the variable viscosity > simulations. > > We run a LowMach number case of an heated channel and we see a strong > variation > changing the viscosity temperature dependence. > (in pic we plot the square of the streamwise velocity fluctuation) > This is not surprising but we would like to have more insight on how the code > treats > the variable viscosity in order to valuate the possible assumptions or errors > we made. > > We assume that the code, instead of solving for div( mu S), solves mu div(S) > with mu that varies in space. > Thus the term (grad muj) S is neglected. > > Is that correct? Is there anything else we have to know?Have anybody > evaluated the effect of this approximation? > > Thank you a lot for you help. > francesco > > From nek5000-users at lists.mcs.anl.gov Mon May 16 07:45:01 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 16 May 2011 14:45:01 +0200 Subject: [Nek5000-users] Neek5000 variable viscosity case In-Reply-To: References: <4DD0F4B0.9010204@lav.mavt.ethz.ch> Message-ID: Hi Francesco, I coded up the variable viscosity support for the PN-PN formulation but the low Mach number support is still missing. For low Mach number flows we do something inconsistent: We assume that nu is identical to nu_ref (constant in space). Obviously this is not true! This is a serious kludge rather than an approximation altough the effect is not known a-priori (and is case dependent)! Cheers Stefan On 5/16/11, nek5000-users at lists.mcs.anl.gov wrote: > > > Dear Francesco, > > For low Mach, if you want var. viscosity you must also set ifexplvis > to be true. This will treat the remaining part of the stress tensor > explicitly, so that you do capture the physics of the full stress tensor. > > Now, a couple of comments --- > > The original explicit formulation, based on strong form developed by > Stefan, > worked well with our dyn. smag. model, but was not in exact agreement > the PnPn-2 stress formulation until refined to convergence. > > I modified this to a weak form in January and it does now agree w/ PnPn-2, > but the dyn. smag. tests that I've done do not work. > > I've been so busy for the past months with travel and proposal writing > that I've not had a chance to understand why dyn. smag. appears to be > broken. I'm hoping to resolve this shortly. > > Cheers, > > Paul > > > On Mon, 16 May 2011, Francesco Lucci wrote: > >> Dear Paul, >> >> sorry to bother you but we need a clarification about the variable >> viscosity >> simulations. >> >> We run a LowMach number case of an heated channel and we see a strong >> variation >> changing the viscosity temperature dependence. >> (in pic we plot the square of the streamwise velocity fluctuation) >> This is not surprising but we would like to have more insight on how the >> code >> treats >> the variable viscosity in order to valuate the possible assumptions or >> errors >> we made. >> >> We assume that the code, instead of solving for div( mu S), solves mu >> div(S) >> with mu that varies in space. >> Thus the term (grad muj) S is neglected. >> >> Is that correct? Is there anything else we have to know?Have anybody >> evaluated the effect of this approximation? >> >> Thank you a lot for you help. >> francesco >> >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon May 16 09:52:32 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 16 May 2011 16:52:32 +0200 Subject: [Nek5000-users] Neek5000 variable viscosity case In-Reply-To: References: <4DD0F4B0.9010204@lav.mavt.ethz.ch> Message-ID: <4DD13A30.2040007@lav.mavt.ethz.ch> Dear Paul and Stefan, thank you for the reply. I am not sure if i have understood the situation. We use the LowMach formulation but we did not set ifexplvis to be true. we varied the viscosity in uservp by adding : ... if (IFLOMACH) visc= param(2)*TEMP**0.67 ... Different cases were run with different exponent for the temperature and we see a clear difference between these cases. Thus somehow we have a case of variable viscosity With 'we assume that nu is identical to nu_ref (constant in space)' do you mean that the equations were derived assuming constant nu ( or mu?), but the code implementation allows a space variation? Or that you fix somewhere nu to be constant in the code? In conclusion, given that i need a variable viscosity, a)In your opinion, which is the best that we can currently do ? set ifexplvis to be true, and add visc= param(2)*TEMP**0.67 ? . b) to set ifexplvis to be true, do i have to change it manually in connect2 and drive2? in only one of the two files? or is there a better way? thank you a lot francesco On 05/16/2011 02:45 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Francesco, > > I coded up the variable viscosity support for the PN-PN formulation > but the low Mach number support is still missing. For low Mach number > flows we do something inconsistent: We assume that nu is identical to > nu_ref (constant in space). Obviously this is not true! This is a > serious kludge rather than an approximation altough the effect is not > known a-priori (and is case dependent)! > > Cheers > Stefan > > On 5/16/11, nek5000-users at lists.mcs.anl.gov > wrote: >> >> Dear Francesco, >> >> For low Mach, if you want var. viscosity you must also set ifexplvis >> to be true. This will treat the remaining part of the stress tensor >> explicitly, so that you do capture the physics of the full stress tensor. >> >> Now, a couple of comments --- >> >> The original explicit formulation, based on strong form developed by >> Stefan, >> worked well with our dyn. smag. model, but was not in exact agreement >> the PnPn-2 stress formulation until refined to convergence. >> >> I modified this to a weak form in January and it does now agree w/ PnPn-2, >> but the dyn. smag. tests that I've done do not work. >> >> I've been so busy for the past months with travel and proposal writing >> that I've not had a chance to understand why dyn. smag. appears to be >> broken. I'm hoping to resolve this shortly. >> >> Cheers, >> >> Paul >> >> >> On Mon, 16 May 2011, Francesco Lucci wrote: >> >>> Dear Paul, >>> >>> sorry to bother you but we need a clarification about the variable >>> viscosity >>> simulations. >>> >>> We run a LowMach number case of an heated channel and we see a strong >>> variation >>> changing the viscosity temperature dependence. >>> (in pic we plot the square of the streamwise velocity fluctuation) >>> This is not surprising but we would like to have more insight on how the >>> code >>> treats >>> the variable viscosity in order to valuate the possible assumptions or >>> errors >>> we made. >>> >>> We assume that the code, instead of solving for div( mu S), solves mu >>> div(S) >>> with mu that varies in space. >>> Thus the term (grad muj) S is neglected. >>> >>> Is that correct? Is there anything else we have to know?Have anybody >>> evaluated the effect of this approximation? >>> >>> Thank you a lot for you help. >>> francesco >>> >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon May 16 10:06:50 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 16 May 2011 10:06:50 -0500 (CDT) Subject: [Nek5000-users] Nek5000 variable viscosity case In-Reply-To: <4DD13A30.2040007@lav.mavt.ethz.ch> References: <4DD0F4B0.9010204@lav.mavt.ethz.ch> <4DD13A30.2040007@lav.mavt.ethz.ch> Message-ID: Dear Francesco, As Stefan indicated, the current explicit treatment of viscosity pertains only to the incompressible formulation for PnPn. (My mistake in thinking it would work for low Mach.) I think the way to proceed is to write down the original PDE, then set mu = mu_ref + mu'(X,t), and treat the varying portion explicitly in time. The rest of the formulation should go through OK, save that you will have a new forcing term that involves mu'. If you can come up with the PDE-based form then we should be able to develop the correct forcing term inside Nek. Of course, I realize this isn't easy in the full low-Mach formulation, but by working together we can crack this. Cheers, Paul On Mon, 16 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul and Stefan, > > thank you for the reply. > I am not sure if i have understood the situation. > > We use the LowMach formulation but we did not set ifexplvis to be true. > we varied the viscosity in uservp by adding : > ... > if (IFLOMACH) visc= param(2)*TEMP**0.67 > ... > > Different cases were run with different exponent for the temperature and we > see > a clear difference between these cases. Thus somehow we have a case of > variable viscosity > > With 'we assume that nu is identical to nu_ref (constant in space)' > do you mean that the equations were derived assuming constant nu ( or mu?), > but the > code implementation allows a space variation? Or that you fix somewhere nu > to be constant in the code? > > In conclusion, given that i need a variable viscosity, > > a)In your opinion, which is the best that we can currently do ? > set ifexplvis to be true, and add visc= param(2)*TEMP**0.67 ? . > > b) to set ifexplvis to be true, do i have to change it manually in connect2 > and drive2? > in only one of the two files? or is there a better way? > > thank you a lot > francesco > > > > On 05/16/2011 02:45 PM, nek5000-users at lists.mcs.anl.gov wrote: >> Hi Francesco, >> >> I coded up the variable viscosity support for the PN-PN formulation >> but the low Mach number support is still missing. For low Mach number >> flows we do something inconsistent: We assume that nu is identical to >> nu_ref (constant in space). Obviously this is not true! This is a >> serious kludge rather than an approximation altough the effect is not >> known a-priori (and is case dependent)! >> >> Cheers >> Stefan >> >> On 5/16/11, nek5000-users at lists.mcs.anl.gov >> wrote: >>> >>> Dear Francesco, >>> >>> For low Mach, if you want var. viscosity you must also set ifexplvis >>> to be true. This will treat the remaining part of the stress tensor >>> explicitly, so that you do capture the physics of the full stress tensor. >>> >>> Now, a couple of comments --- >>> >>> The original explicit formulation, based on strong form developed by >>> Stefan, >>> worked well with our dyn. smag. model, but was not in exact agreement >>> the PnPn-2 stress formulation until refined to convergence. >>> >>> I modified this to a weak form in January and it does now agree w/ PnPn-2, >>> but the dyn. smag. tests that I've done do not work. >>> >>> I've been so busy for the past months with travel and proposal writing >>> that I've not had a chance to understand why dyn. smag. appears to be >>> broken. I'm hoping to resolve this shortly. >>> >>> Cheers, >>> >>> Paul >>> >>> >>> On Mon, 16 May 2011, Francesco Lucci wrote: >>> >>>> Dear Paul, >>>> >>>> sorry to bother you but we need a clarification about the variable >>>> viscosity >>>> simulations. >>>> >>>> We run a LowMach number case of an heated channel and we see a strong >>>> variation >>>> changing the viscosity temperature dependence. >>>> (in pic we plot the square of the streamwise velocity fluctuation) >>>> This is not surprising but we would like to have more insight on how the >>>> code >>>> treats >>>> the variable viscosity in order to valuate the possible assumptions or >>>> errors >>>> we made. >>>> >>>> We assume that the code, instead of solving for div( mu S), solves mu >>>> div(S) >>>> with mu that varies in space. >>>> Thus the term (grad muj) S is neglected. >>>> >>>> Is that correct? Is there anything else we have to know?Have anybody >>>> evaluated the effect of this approximation? >>>> >>>> Thank you a lot for you help. >>>> francesco >>>> >>>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon May 16 11:18:41 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 16 May 2011 18:18:41 +0200 Subject: [Nek5000-users] Nek5000 variable viscosity case In-Reply-To: References: <4DD0F4B0.9010204@lav.mavt.ethz.ch> <4DD13A30.2040007@lav.mavt.ethz.ch> Message-ID: Francesco, you can set vdiff to whatever you like. The implemented formulation was derived based on the assumption that mue is constant in space. So no matter what you, (a) or (b) will be wrong! I don't remember the details but the tricky thing was QTL or the pressure boundary condition which has change accordingly. Start from the low Mach number equations and split mue into a constant and varying part. Then, discretize the eqns using the BDF/EXT scheme and treat the varying part explicit. Finally you have to derive the pressure equation and a boundary condition. From this it should be obvious what needs to be modified. How this could be implemented is another story. -Stefan On 5/16/11, nek5000-users at lists.mcs.anl.gov wrote: > > Dear Francesco, > > As Stefan indicated, the current explicit treatment of > viscosity pertains only to the incompressible formulation > for PnPn. (My mistake in thinking it would work for low Mach.) > > I think the way to proceed is to write down the original > PDE, then set mu = mu_ref + mu'(X,t), and treat the varying > portion explicitly in time. > > The rest of the formulation should go through OK, save that > you will have a new forcing term that involves mu'. > > If you can come up with the PDE-based form then we should > be able to develop the correct forcing term inside Nek. > Of course, I realize this isn't easy in the full low-Mach > formulation, but by working together we can crack this. > > Cheers, > > Paul > > > > On Mon, 16 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Paul and Stefan, >> >> thank you for the reply. >> I am not sure if i have understood the situation. >> >> We use the LowMach formulation but we did not set ifexplvis to be true. >> we varied the viscosity in uservp by adding : >> ... >> if (IFLOMACH) visc= param(2)*TEMP**0.67 >> ... >> >> Different cases were run with different exponent for the temperature and >> we >> see >> a clear difference between these cases. Thus somehow we have a case of >> variable viscosity >> >> With 'we assume that nu is identical to nu_ref (constant in space)' >> do you mean that the equations were derived assuming constant nu ( or >> mu?), >> but the >> code implementation allows a space variation? Or that you fix somewhere >> nu >> to be constant in the code? >> >> In conclusion, given that i need a variable viscosity, >> >> a)In your opinion, which is the best that we can currently do ? >> set ifexplvis to be true, and add visc= param(2)*TEMP**0.67 ? . >> >> b) to set ifexplvis to be true, do i have to change it manually in >> connect2 >> and drive2? >> in only one of the two files? or is there a better way? >> >> thank you a lot >> francesco >> >> >> >> On 05/16/2011 02:45 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> Hi Francesco, >>> >>> I coded up the variable viscosity support for the PN-PN formulation >>> but the low Mach number support is still missing. For low Mach number >>> flows we do something inconsistent: We assume that nu is identical to >>> nu_ref (constant in space). Obviously this is not true! This is a >>> serious kludge rather than an approximation altough the effect is not >>> known a-priori (and is case dependent)! >>> >>> Cheers >>> Stefan >>> >>> On 5/16/11, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> >>>> Dear Francesco, >>>> >>>> For low Mach, if you want var. viscosity you must also set ifexplvis >>>> to be true. This will treat the remaining part of the stress tensor >>>> explicitly, so that you do capture the physics of the full stress >>>> tensor. >>>> >>>> Now, a couple of comments --- >>>> >>>> The original explicit formulation, based on strong form developed by >>>> Stefan, >>>> worked well with our dyn. smag. model, but was not in exact agreement >>>> the PnPn-2 stress formulation until refined to convergence. >>>> >>>> I modified this to a weak form in January and it does now agree w/ >>>> PnPn-2, >>>> but the dyn. smag. tests that I've done do not work. >>>> >>>> I've been so busy for the past months with travel and proposal writing >>>> that I've not had a chance to understand why dyn. smag. appears to be >>>> broken. I'm hoping to resolve this shortly. >>>> >>>> Cheers, >>>> >>>> Paul >>>> >>>> >>>> On Mon, 16 May 2011, Francesco Lucci wrote: >>>> >>>>> Dear Paul, >>>>> >>>>> sorry to bother you but we need a clarification about the variable >>>>> viscosity >>>>> simulations. >>>>> >>>>> We run a LowMach number case of an heated channel and we see a strong >>>>> variation >>>>> changing the viscosity temperature dependence. >>>>> (in pic we plot the square of the streamwise velocity fluctuation) >>>>> This is not surprising but we would like to have more insight on how >>>>> the >>>>> code >>>>> treats >>>>> the variable viscosity in order to valuate the possible assumptions or >>>>> errors >>>>> we made. >>>>> >>>>> We assume that the code, instead of solving for div( mu S), solves mu >>>>> div(S) >>>>> with mu that varies in space. >>>>> Thus the term (grad muj) S is neglected. >>>>> >>>>> Is that correct? Is there anything else we have to know?Have anybody >>>>> evaluated the effect of this approximation? >>>>> >>>>> Thank you a lot for you help. >>>>> francesco >>>>> >>>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon May 16 12:21:51 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 16 May 2011 19:21:51 +0200 Subject: [Nek5000-users] Problem with conjugate heat transfer + Low Mach number formulation Message-ID: Dear all, I am running a case with conjugate heat transfer + Low Mach number formulation, the domain is a 2D channel. The boundary conditions for the temperature are: - fluid: constant inlet temperature equal to 1; - solid: constant temperature equal to 2 at the outer side, at the inner side there is no boundary condition because the energy equation has to be solved, the other sides are insulated. What I see is that the flow starts to accelerate almost immediately even though at the beginning the temperature of the fluid domain is almost 1. The outlet velocity becomes more than two times the inlet velocity. The reason is that at the wall (and especially at the inlet corner) the thermal divergence is quite large, while it is almost zero in the rest of the fluid domain. In a conjugate heat transfer problem the derivative of the temperature is discontinuos across the wall because of the different thermal conductivities. Could there be a problem when "opgrad" and "opdssum" are evaluated in "subroutine qthermal"? I know that they are evaluated only on the fluid domain but maybe the discontinuity in the derivative of the temperature could give some problems. Thanks a lot in advance for your help. Regards, Andrea From nek5000-users at lists.mcs.anl.gov Wed May 18 15:46:14 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 18 May 2011 15:46:14 -0500 Subject: [Nek5000-users] Average in arbitrary direction Message-ID: Hello Neks, I have looked at the turbChannel example for an example on planar averaging. However, I was wondering if there was any advice on how to do this if the elements aren't exactly "nice"... (i.e., the elements may have arbitrary rotations) Specifically, I have a pipe flow, and I am wanting to do an average in the z (axial) direction. My initial thoughts were to interpolate my values to set R, theta components, and then average this along z. I'm stuck on the best way to do either one of these operations, however (especially because I would like to use an integration rule to compute the average in the z direction). If anyone could point me in the right direction, that would be a big help. Thanks! -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Wed May 18 15:59:18 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 18 May 2011 15:59:18 -0500 (CDT) Subject: [Nek5000-users] Average in arbitrary direction In-Reply-To: References: Message-ID: Hi Josh, You can use the interp() routines --- let me check if we have examples in the repo. These are somewhat expensive, so if you're also integrating in time (even over just 10 steps), it would pay to only interpolate the time-averaged data, rather than interpolating every timestep and then averaging the profiles. However, I can understand that there are times you'd want the full time signal. The best integration formulae for periodic signals (e.g., in your theta direction and perhaps in z, if you have periodicity) is to simply sum the values, sampled uniformly in space (z or theta), and dived by n, the number of samples. You do need to sample with sufficient density to capture all the wiggles --- another reason that time averaging has value. Paul On Wed, 18 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello Neks, > > I have looked at the turbChannel example for an example on planar averaging. > > However, I was wondering if there was any advice on how to do this if > the elements aren't exactly "nice"... (i.e., the elements may have > arbitrary rotations) > > Specifically, I have a pipe flow, and I am wanting to do an average in > the z (axial) direction. My initial thoughts were to interpolate my > values to set R, theta components, and then average this along z. I'm > stuck on the best way to do either one of these operations, however > (especially because I would like to use an integration rule to compute > the average in the z direction). > > If anyone could point me in the right direction, that would be a big > help. Thanks! > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu May 19 09:21:03 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 19 May 2011 09:21:03 -0500 Subject: [Nek5000-users] Average in arbitrary direction In-Reply-To: References: Message-ID: Hello Paul, This sound like exactly what I need. I didn't find anything like interp() while using grep in the repo--are you referring to the routines found in postpro.f ?? Thanks, Josh On Wed, May 18, 2011 at 3:59 PM, wrote: > > Hi Josh, > > You can use the interp() routines --- let me check if we have > examples in the repo. > > These are somewhat expensive, so if you're also integrating in > time (even over just 10 steps), it would pay to only interpolate > the time-averaged data, rather than interpolating every timestep > and then averaging the profiles. ? However, I can understand that > there are times you'd want the full time signal. > > The best integration formulae for periodic signals (e.g., in your theta > direction and perhaps in z, if you have periodicity) > is to simply sum the values, sampled uniformly in space (z or > theta), and dived by n, the number of samples. ? You do need > to sample with sufficient density to capture all the wiggles --- > another reason that time averaging has value. > > Paul > > > > On Wed, 18 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello Neks, >> >> I have looked at the turbChannel example for an example on planar >> averaging. >> >> However, I was wondering if there was any advice ?on how to do this if >> the elements aren't exactly "nice"... (i.e., the elements may have >> arbitrary rotations) >> >> Specifically, I have a pipe flow, and I am wanting to do an average in >> the z (axial) direction. ?My initial thoughts were to interpolate my >> values to set R, theta components, and then average this along z. ?I'm >> stuck on the best way to do either one of these operations, however >> (especially because I would like to use an integration rule to compute >> the average in the z direction). >> >> If anyone could point me in the right direction, that would be a big >> help. ?Thanks! >> >> -- >> Josh Camp >> >> "All that is necessary for the triumph of evil is that good men do >> nothing" -- Edmund Burke >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Thu May 19 15:06:05 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 19 May 2011 15:06:05 -0500 (CDT) Subject: [Nek5000-users] Average in arbitrary direction In-Reply-To: Message-ID: <552121414.86615.1305835565006.JavaMail.root@zimbra.anl.gov> Hi Josh, yes, there are 3 intpts* routines from postpro.f that you can use. I have an example but I need to update it for the current repo version of this routines -- I'll send it to you once I modify and test it. Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Thursday, May 19, 2011 9:21:03 AM Subject: Re: [Nek5000-users] Average in arbitrary direction Hello Paul, This sound like exactly what I need. I didn't find anything like interp() while using grep in the repo--are you referring to the routines found in postpro.f ?? Thanks, Josh On Wed, May 18, 2011 at 3:59 PM, wrote: > > Hi Josh, > > You can use the interp() routines --- let me check if we have > examples in the repo. > > These are somewhat expensive, so if you're also integrating in > time (even over just 10 steps), it would pay to only interpolate > the time-averaged data, rather than interpolating every timestep > and then averaging the profiles. ? However, I can understand that > there are times you'd want the full time signal. > > The best integration formulae for periodic signals (e.g., in your theta > direction and perhaps in z, if you have periodicity) > is to simply sum the values, sampled uniformly in space (z or > theta), and dived by n, the number of samples. ? You do need > to sample with sufficient density to capture all the wiggles --- > another reason that time averaging has value. > > Paul > > > > On Wed, 18 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello Neks, >> >> I have looked at the turbChannel example for an example on planar >> averaging. >> >> However, I was wondering if there was any advice ?on how to do this if >> the elements aren't exactly "nice"... (i.e., the elements may have >> arbitrary rotations) >> >> Specifically, I have a pipe flow, and I am wanting to do an average in >> the z (axial) direction. ?My initial thoughts were to interpolate my >> values to set R, theta components, and then average this along z. ?I'm >> stuck on the best way to do either one of these operations, however >> (especially because I would like to use an integration rule to compute >> the average in the z direction). >> >> If anyone could point me in the right direction, that would be a big >> help. ?Thanks! >> >> -- >> Josh Camp >> >> "All that is necessary for the triumph of evil is that good men do >> nothing" -- Edmund Burke >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri May 20 08:02:33 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 20 May 2011 08:02:33 -0500 Subject: [Nek5000-users] Average in arbitrary direction In-Reply-To: <552121414.86615.1305835565006.JavaMail.root@zimbra.anl.gov> References: <552121414.86615.1305835565006.JavaMail.root@zimbra.anl.gov> Message-ID: Hello Aleks, I see the three routines I need, and I think I understand the basics of the functions (although I think it would still be nice to see an example if you are still working on updating it). I had some quick questions about the routine intpts_setup...it defines some variables npt_max, nxf, nyf, nzf. Could you give a quick definition of the meaning of these 4 variables to the findpts_setup routine? Particularly, at least in the repo I have, npt_max is set to 256. Do I need to change this if I'll be needing to interpolate onto more than 256 points (or does this mean something else)? Thanks, Josh On Thu, May 19, 2011 at 3:06 PM, wrote: > Hi Josh, > > yes, there are 3 intpts* routines from postpro.f that you can use. I have an example but I need to update it for the current repo version of this routines -- I'll send it to you once I modify and test it. > > Best, > Aleks > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Thursday, May 19, 2011 9:21:03 AM > Subject: Re: [Nek5000-users] Average in arbitrary direction > > Hello Paul, > > This sound like exactly what I need. ?I didn't find anything like > interp() while using grep in the repo--are you referring to the > routines found in postpro.f ?? > > Thanks, > > Josh > > On Wed, May 18, 2011 at 3:59 PM, ? wrote: >> >> Hi Josh, >> >> You can use the interp() routines --- let me check if we have >> examples in the repo. >> >> These are somewhat expensive, so if you're also integrating in >> time (even over just 10 steps), it would pay to only interpolate >> the time-averaged data, rather than interpolating every timestep >> and then averaging the profiles. ? However, I can understand that >> there are times you'd want the full time signal. >> >> The best integration formulae for periodic signals (e.g., in your theta >> direction and perhaps in z, if you have periodicity) >> is to simply sum the values, sampled uniformly in space (z or >> theta), and dived by n, the number of samples. ? You do need >> to sample with sufficient density to capture all the wiggles --- >> another reason that time averaging has value. >> >> Paul >> >> >> >> On Wed, 18 May 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello Neks, >>> >>> I have looked at the turbChannel example for an example on planar >>> averaging. >>> >>> However, I was wondering if there was any advice ?on how to do this if >>> the elements aren't exactly "nice"... (i.e., the elements may have >>> arbitrary rotations) >>> >>> Specifically, I have a pipe flow, and I am wanting to do an average in >>> the z (axial) direction. ?My initial thoughts were to interpolate my >>> values to set R, theta components, and then average this along z. ?I'm >>> stuck on the best way to do either one of these operations, however >>> (especially because I would like to use an integration rule to compute >>> the average in the z direction). >>> >>> If anyone could point me in the right direction, that would be a big >>> help. ?Thanks! >>> >>> -- >>> Josh Camp >>> >>> "All that is necessary for the triumph of evil is that good men do >>> nothing" -- Edmund Burke >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > > > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > 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 > -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Thu May 19 16:15:14 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 19 May 2011 16:15:14 -0500 Subject: [Nek5000-users] Average in arbitrary direction (fwd) In-Reply-To: References: Message-ID: Hi Josh, The routine that you want is attached to this email or you can find it here: http://www.mcs.anl.gov/~jwalker/interp_v.f You give it a packed list of the points that you want to interpolate x(1),y(1),z(1),....,x(n),y(n),z(n) along with the number of points, n, and it gives you back the velocities at each point u(1),v(1),w(1),...,u(n),v(n),w(n). Make sure to change lpart in SIZE to the number of points you want. Best, Justin On Thu, May 19, 2011 at 3:09 PM, Paul Fischer wrote: > > Justin, > > Can you post or send the latest interp_uvw() routine that > you used in your hemi case? > > I guess we need to get the hemi example into the repo. > > Thanks, > > Paul > > > ---------- Forwarded message ---------- > Date: Thu, 19 May 2011 15:06:05 -0500 (CDT) > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Average in arbitrary direction > > Hi Josh, > > yes, there are 3 intpts* routines from postpro.f that you can use. I have > an example but I need to update it for the current repo version of this > routines -- I'll send it to you once I modify and test it. > > Best, > Aleks > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Thursday, May 19, 2011 9:21:03 AM > Subject: Re: [Nek5000-users] Average in arbitrary direction > > Hello Paul, > > This sound like exactly what I need. I didn't find anything like > interp() while using grep in the repo--are you referring to the > routines found in postpro.f ?? > > Thanks, > > Josh > > On Wed, May 18, 2011 at 3:59 PM, wrote: > >> >> Hi Josh, >> >> You can use the interp() routines --- let me check if we have >> examples in the repo. >> >> These are somewhat expensive, so if you're also integrating in >> time (even over just 10 steps), it would pay to only interpolate >> the time-averaged data, rather than interpolating every timestep >> and then averaging the profiles. However, I can understand that >> there are times you'd want the full time signal. >> >> The best integration formulae for periodic signals (e.g., in your theta >> direction and perhaps in z, if you have periodicity) >> is to simply sum the values, sampled uniformly in space (z or >> theta), and dived by n, the number of samples. You do need >> to sample with sufficient density to capture all the wiggles --- >> another reason that time averaging has value. >> >> Paul >> >> >> >> On Wed, 18 May 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >> Hello Neks, >>> >>> I have looked at the turbChannel example for an example on planar >>> averaging. >>> >>> However, I was wondering if there was any advice on how to do this if >>> the elements aren't exactly "nice"... (i.e., the elements may have >>> arbitrary rotations) >>> >>> Specifically, I have a pipe flow, and I am wanting to do an average in >>> the z (axial) direction. My initial thoughts were to interpolate my >>> values to set R, theta components, and then average this along z. I'm >>> stuck on the best way to do either one of these operations, however >>> (especially because I would like to use an integration rule to compute >>> the average in the z direction). >>> >>> If anyone could point me in the right direction, that would be a big >>> help. Thanks! >>> >>> -- >>> Josh Camp >>> >>> "All that is necessary for the triumph of evil is that good men do >>> nothing" -- Edmund Burke >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> > > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: interp_v.f Type: text/x-fortran Size: 1446 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Fri May 20 10:22:57 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 20 May 2011 10:22:57 -0500 (CDT) Subject: [Nek5000-users] Average in arbitrary direction In-Reply-To: References: <552121414.86615.1305835565006.JavaMail.root@zimbra.anl.gov> Message-ID: Hi Josh, I would just use Justin's interp_v routine which calls intpts* so you do not have to -- at least for the first time. The description of the parameters nxf,...,npt_max yo can find at nek5_svn/trunk/nek/jl2/findpts.c:89 Let me know if you have other questions. Aleks On Fri, 20 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello Aleks, > > I see the three routines I need, and I think I understand the basics > of the functions (although I think it would still be nice to see an > example if you are still working on updating it). > > I had some quick questions about the routine intpts_setup...it defines > some variables npt_max, nxf, nyf, nzf. Could you give a quick > definition of the meaning of these 4 variables to the findpts_setup > routine? > > Particularly, at least in the repo I have, npt_max is set to 256. Do > I need to change this if I'll be needing to interpolate onto more than > 256 points (or does this mean something else)? > > Thanks, > > Josh > > On Thu, May 19, 2011 at 3:06 PM, wrote: >> Hi Josh, >> >> yes, there are 3 intpts* routines from postpro.f that you can use. I have an example but I need to update it for the current repo version of this routines -- I'll send it to you once I modify and test it. >> >> Best, >> Aleks >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Thursday, May 19, 2011 9:21:03 AM >> Subject: Re: [Nek5000-users] Average in arbitrary direction >> >> Hello Paul, >> >> This sound like exactly what I need. ?I didn't find anything like >> interp() while using grep in the repo--are you referring to the >> routines found in postpro.f ?? >> >> Thanks, >> >> Josh >> >> On Wed, May 18, 2011 at 3:59 PM, ? wrote: >>> >>> Hi Josh, >>> >>> You can use the interp() routines --- let me check if we have >>> examples in the repo. >>> >>> These are somewhat expensive, so if you're also integrating in >>> time (even over just 10 steps), it would pay to only interpolate >>> the time-averaged data, rather than interpolating every timestep >>> and then averaging the profiles. ? However, I can understand that >>> there are times you'd want the full time signal. >>> >>> The best integration formulae for periodic signals (e.g., in your theta >>> direction and perhaps in z, if you have periodicity) >>> is to simply sum the values, sampled uniformly in space (z or >>> theta), and dived by n, the number of samples. ? You do need >>> to sample with sufficient density to capture all the wiggles --- >>> another reason that time averaging has value. >>> >>> Paul >>> >>> >>> >>> On Wed, 18 May 2011, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hello Neks, >>>> >>>> I have looked at the turbChannel example for an example on planar >>>> averaging. >>>> >>>> However, I was wondering if there was any advice ?on how to do this if >>>> the elements aren't exactly "nice"... (i.e., the elements may have >>>> arbitrary rotations) >>>> >>>> Specifically, I have a pipe flow, and I am wanting to do an average in >>>> the z (axial) direction. ?My initial thoughts were to interpolate my >>>> values to set R, theta components, and then average this along z. ?I'm >>>> stuck on the best way to do either one of these operations, however >>>> (especially because I would like to use an integration rule to compute >>>> the average in the z direction). >>>> >>>> If anyone could point me in the right direction, that would be a big >>>> help. ?Thanks! >>>> >>>> -- >>>> Josh Camp >>>> >>>> "All that is necessary for the triumph of evil is that good men do >>>> nothing" -- Edmund Burke >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> >> >> >> -- >> Josh Camp >> >> "All that is necessary for the triumph of evil is that good men do >> nothing" -- Edmund Burke >> _______________________________________________ >> 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 >> > > > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sun May 22 11:31:25 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 22 May 2011 18:31:25 +0200 Subject: [Nek5000-users] Average in arbitrary direction In-Reply-To: References: <552121414.86615.1305835565006.JavaMail.root@zimbra.anl.gov> Message-ID: Hi Josh Currently we use the interpolation stuff in g2gi() and hpts(). Just have a look into these subroutines. The interpolation wrappers intpts_setup() and intpts() are designed to provide a simple interface making it easy to use. The parameters in intpts_setup have another meaning (see in findpts.c) and you don't need to modify them unless there is a good reason. -Stefan On 5/20/11, nek5000-users at lists.mcs.anl.gov wrote: > Hello Aleks, > > I see the three routines I need, and I think I understand the basics > of the functions (although I think it would still be nice to see an > example if you are still working on updating it). > > I had some quick questions about the routine intpts_setup...it defines > some variables npt_max, nxf, nyf, nzf. Could you give a quick > definition of the meaning of these 4 variables to the findpts_setup > routine? > > Particularly, at least in the repo I have, npt_max is set to 256. Do > I need to change this if I'll be needing to interpolate onto more than > 256 points (or does this mean something else)? > > Thanks, > > Josh > > On Thu, May 19, 2011 at 3:06 PM, wrote: >> Hi Josh, >> >> yes, there are 3 intpts* routines from postpro.f that you can use. I have >> an example but I need to update it for the current repo version of this >> routines -- I'll send it to you once I modify and test it. >> >> Best, >> Aleks >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Thursday, May 19, 2011 9:21:03 AM >> Subject: Re: [Nek5000-users] Average in arbitrary direction >> >> Hello Paul, >> >> This sound like exactly what I need. I didn't find anything like >> interp() while using grep in the repo--are you referring to the >> routines found in postpro.f ?? >> >> Thanks, >> >> Josh >> >> On Wed, May 18, 2011 at 3:59 PM, wrote: >>> >>> Hi Josh, >>> >>> You can use the interp() routines --- let me check if we have >>> examples in the repo. >>> >>> These are somewhat expensive, so if you're also integrating in >>> time (even over just 10 steps), it would pay to only interpolate >>> the time-averaged data, rather than interpolating every timestep >>> and then averaging the profiles. However, I can understand that >>> there are times you'd want the full time signal. >>> >>> The best integration formulae for periodic signals (e.g., in your theta >>> direction and perhaps in z, if you have periodicity) >>> is to simply sum the values, sampled uniformly in space (z or >>> theta), and dived by n, the number of samples. You do need >>> to sample with sufficient density to capture all the wiggles --- >>> another reason that time averaging has value. >>> >>> Paul >>> >>> >>> >>> On Wed, 18 May 2011, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hello Neks, >>>> >>>> I have looked at the turbChannel example for an example on planar >>>> averaging. >>>> >>>> However, I was wondering if there was any advice on how to do this if >>>> the elements aren't exactly "nice"... (i.e., the elements may have >>>> arbitrary rotations) >>>> >>>> Specifically, I have a pipe flow, and I am wanting to do an average in >>>> the z (axial) direction. My initial thoughts were to interpolate my >>>> values to set R, theta components, and then average this along z. I'm >>>> stuck on the best way to do either one of these operations, however >>>> (especially because I would like to use an integration rule to compute >>>> the average in the z direction). >>>> >>>> If anyone could point me in the right direction, that would be a big >>>> help. Thanks! >>>> >>>> -- >>>> Josh Camp >>>> >>>> "All that is necessary for the triumph of evil is that good men do >>>> nothing" -- Edmund Burke >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> >> >> >> -- >> Josh Camp >> >> "All that is necessary for the triumph of evil is that good men do >> nothing" -- Edmund Burke >> _______________________________________________ >> 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 >> > > > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue May 24 09:13:40 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 24 May 2011 16:13:40 +0200 Subject: [Nek5000-users] Compilation error Message-ID: Hi Nek's, Up to now I have compiled and run the code on the various workstations available in my lab. I am now trying to compile it (only in serial for the moment) on an IBM Power 6 ( http://www.idris.fr/su/Scalaire/vargas/hw-vargas.html) but I encounter an error (which is the reason why I do not compile it using mpi support yet). Following is the outpost from the compilation: xlf_r -qsuppress=cmpmsg -o nek5000 obj/stenosis.o obj/drive.o obj/drive1.o obj/drive2.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o obj/hsmg.o obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o obj/byte.o obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/cvode_driver.o obj/nek_comm.o obj/init_plugin.o obj/setprop.o obj/qthermal.o obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o obj/dsygv.o obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o obj/singlmesh.o obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o obj/jl2_sarray_sort.o obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o ld: 0711-317 ERROR: Undefined symbol: .etime ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. gmake: *** [nek5000] Error 8 Attached is the whole compiler.out file also. Does anyone have an idea? Regards, -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compiler.out Type: application/octet-stream Size: 36597 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Tue May 24 09:20:19 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 24 May 2011 09:20:19 -0500 (CDT) Subject: [Nek5000-users] Compilation error In-Reply-To: References: Message-ID: Dear Jean-Christophe, etime is a fairly std. timer function, but obviously not supported with your compiler. When using mpi, it uses instead the mpi timer, so there is no issue. The quick fix here would be to edit mpi_dummy.f and change the etime() reference therein to the ibm timer function. You might also try setting it zero - but I'm not 100% certain that there are no divisions involving time in the denominator... It's worth a try, however. Paul On Tue, 24 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > Up to now I have compiled and run the code on the various workstations > available in my lab. I am now trying to compile it (only in serial for the > moment) on an IBM Power 6 ( > http://www.idris.fr/su/Scalaire/vargas/hw-vargas.html) but I encounter an > error (which is the reason why I do not compile it using mpi support > yet). Following is the outpost from the compilation: > > xlf_r -qsuppress=cmpmsg -o nek5000 obj/stenosis.o obj/drive.o obj/drive1.o > obj/drive2.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o > obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o > obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o > obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o > obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o > obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o > obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o obj/hsmg.o > obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o > obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o obj/byte.o > obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/cvode_driver.o > obj/nek_comm.o obj/init_plugin.o obj/setprop.o obj/qthermal.o > obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o obj/dsygv.o > obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o obj/singlmesh.o > obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o obj/jl2_sarray_sort.o > obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o > obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o > obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o > obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o > obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o > obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o > ld: 0711-317 ERROR: Undefined symbol: .etime > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more > information. > gmake: *** [nek5000] Error 8 > > Attached is the whole compiler.out file also. Does anyone have an idea? > > Regards, > > -- > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Wed May 25 07:21:58 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 May 2011 14:21:58 +0200 Subject: [Nek5000-users] Compilation error In-Reply-To: References: Message-ID: Thanks for the tip, it now works at least for serial calculation. Note furthermore that, using the xlf compiler from ibm, I also had to change -qrealsize=8 into -qautodbl=dbl4 in order to avoid a segmentation fault. I am now trying to compile to it for parallel calculation, thus I specified mpxlf_r and mpcc_r in F77 and C fields in makenek. However I get the following message as soon as I start the compilation: ./makenek stenosis makenek - automatic build tool for Nek5000 ** test === End of Compilation 1 === 1501-510 Compilation successful for file test_f77.f. llsubmit: Processed command file through Submit Filter: "/usr/local/loadl/Fidris/llsubmit_exit". ** underscore_test === End of Compilation 1 === 1501-510 Compilation successful for file test_underscore.f. ERROR: Unable to detect compiler! - don't know how to promote datatype REAL to 8 bytes - don't know how to invoke the C pre-processor (CPP) before compilation Please edit the makefile and specify the requested compiler flags using the P variable. I presume it is a fairly simple error to solve, but I am not familiar at all with such massively parallel calculators yet [?] Best regards, JC On 24 May 2011 16:20, wrote: > > Dear Jean-Christophe, > > etime is a fairly std. timer function, but obviously not > supported with your compiler. > > When using mpi, it uses instead the mpi timer, so there is no > issue. > > The quick fix here would be to edit mpi_dummy.f and change > the etime() reference therein to the ibm timer function. > > You might also try setting it zero - but I'm not 100% certain > that there are no divisions involving time in the denominator... > It's worth a try, however. > > Paul > > > > > On Tue, 24 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Nek's, >> >> Up to now I have compiled and run the code on the various workstations >> available in my lab. I am now trying to compile it (only in serial for the >> moment) on an IBM Power 6 ( >> http://www.idris.fr/su/Scalaire/vargas/hw-vargas.html) but I encounter an >> error (which is the reason why I do not compile it using mpi support >> yet). Following is the outpost from the compilation: >> >> xlf_r -qsuppress=cmpmsg -o nek5000 obj/stenosis.o obj/drive.o >> obj/drive1.o >> obj/drive2.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o >> obj/connect1.o >> obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o >> obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o >> obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o >> obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o >> obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o >> obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o >> obj/hsmg.o >> obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o >> obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o >> obj/byte.o >> obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/cvode_driver.o >> obj/nek_comm.o obj/init_plugin.o obj/setprop.o obj/qthermal.o >> obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o obj/dsygv.o >> obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o obj/singlmesh.o >> obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o >> obj/jl2_sarray_sort.o >> obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o >> obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o >> obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o >> obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o >> obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o >> obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o >> ld: 0711-317 ERROR: Undefined symbol: .etime >> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more >> information. >> gmake: *** [nek5000] Error 8 >> >> Attached is the whole compiler.out file also. Does anyone have an idea? >> >> Regards, >> >> -- >> Jean-Christophe >> >> _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 33D.gif Type: image/gif Size: 104 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed May 25 07:41:04 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 May 2011 07:41:04 -0500 (CDT) Subject: [Nek5000-users] Compilation error In-Reply-To: Message-ID: <1809040197.104781.1306327264626.JavaMail.root@zimbra.anl.gov> Hi Jean-Christophe, Could you try to modify makefile after makenek has generated it? That is what I do for g95 compiler on my Mac. The downside is that .f file should be a copy of .usr file every time you modify it. Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, May 25, 2011 7:21:58 AM Subject: Re: [Nek5000-users] Compilation error Thanks for the tip, it now works at least for serial calculation. Note furthermore that, using the xlf compiler from ibm, I also had to change -qrealsize=8 into -qautodbl=dbl4 in order to avoid a segmentation fault. I am now trying to compile to it for parallel calculation, thus I specified mpxlf_r and mpcc_r in F77 and C fields in makenek. However I get the following message as soon as I start the compilation: ./makenek stenosis makenek - automatic build tool for Nek5000 ** test === End of Compilation 1 === 1501-510 Compilation successful for file test_f77.f. llsubmit: Processed command file through Submit Filter: "/usr/local/loadl/Fidris/llsubmit_exit". ** underscore_test === End of Compilation 1 === 1501-510 Compilation successful for file test_underscore.f. ERROR: Unable to detect compiler! - don't know how to promote datatype REAL to 8 bytes - don't know how to invoke the C pre-processor (CPP) before compilation Please edit the makefile and specify the requested compiler flags using the P variable. I presume it is a fairly simple error to solve, but I am not familiar at all with such massively parallel calculators yet Best regards, JC On 24 May 2011 16:20, < nek5000-users at lists.mcs.anl.gov > wrote: Dear Jean-Christophe, etime is a fairly std. timer function, but obviously not supported with your compiler. When using mpi, it uses instead the mpi timer, so there is no issue. The quick fix here would be to edit mpi_dummy.f and change the etime() reference therein to the ibm timer function. You might also try setting it zero - but I'm not 100% certain that there are no divisions involving time in the denominator... It's worth a try, however. Paul On Tue, 24 May 2011, nek5000-users at lists.mcs.anl.gov wrote: Hi Nek's, Up to now I have compiled and run the code on the various workstations available in my lab. I am now trying to compile it (only in serial for the moment) on an IBM Power 6 ( http://www.idris.fr/su/Scalaire/vargas/hw-vargas.html ) but I encounter an error (which is the reason why I do not compile it using mpi support yet). Following is the outpost from the compilation: xlf_r -qsuppress=cmpmsg -o nek5000 obj/stenosis.o obj/drive.o obj/drive1.o obj/drive2.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o obj/hsmg.o obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o obj/byte.o obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/cvode_driver.o obj/nek_comm.o obj/init_plugin.o obj/setprop.o obj/qthermal.o obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o obj/dsygv.o obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o obj/singlmesh.o obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o obj/jl2_sarray_sort.o obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o ld: 0711-317 ERROR: Undefined symbol: .etime ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. gmake: *** [nek5000] Error 8 Attached is the whole compiler.out file also. Does anyone have an idea? Regards, -- Jean-Christophe _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Jean-Christophe _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed May 25 07:44:31 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 May 2011 14:44:31 +0200 Subject: [Nek5000-users] Compilation error In-Reply-To: <1809040197.104781.1306327264626.JavaMail.root@zimbra.anl.gov> References: <1809040197.104781.1306327264626.JavaMail.root@zimbra.anl.gov> Message-ID: That's what I did indeed, and it works. On 25 May 2011 14:41, wrote: > Hi Jean-Christophe, > > Could you try to modify makefile after makenek has generated it? That is > what I do for g95 compiler on my Mac. > > The downside is that .f file should be a copy of .usr file every time you > modify it. > > Best, > Aleks > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, May 25, 2011 7:21:58 AM > Subject: Re: [Nek5000-users] Compilation error > > > Thanks for the tip, it now works at least for serial calculation. Note > furthermore that, using the xlf compiler from ibm, I also had to change > -qrealsize=8 into -qautodbl=dbl4 in order to avoid a segmentation fault. > > > I am now trying to compile to it for parallel calculation, thus I specified > mpxlf_r and mpcc_r in F77 and C fields in makenek. However I get the > following message as soon as I start the compilation: > > > > > > > > > ./makenek stenosis > makenek - automatic build tool for Nek5000 > ** test === End of Compilation 1 === > 1501-510 Compilation successful for file test_f77.f. > llsubmit: Processed command file through Submit Filter: > "/usr/local/loadl/Fidris/llsubmit_exit". > ** underscore_test === End of Compilation 1 === > 1501-510 Compilation successful for file test_underscore.f. > ERROR: Unable to detect compiler! > - don't know how to promote datatype REAL to 8 bytes > - don't know how to invoke the C pre-processor (CPP) before compilation > Please edit the makefile and specify the requested compiler flags using the > P variable. > > > I presume it is a fairly simple error to solve, but I am not familiar at > all with such massively parallel calculators yet > > > Best regards, > JC > > On 24 May 2011 16:20, < nek5000-users at lists.mcs.anl.gov > wrote: > > > > Dear Jean-Christophe, > > etime is a fairly std. timer function, but obviously not > supported with your compiler. > > When using mpi, it uses instead the mpi timer, so there is no > issue. > > The quick fix here would be to edit mpi_dummy.f and change > the etime() reference therein to the ibm timer function. > > You might also try setting it zero - but I'm not 100% certain > that there are no divisions involving time in the denominator... > It's worth a try, however. > > Paul > > > > > > > On Tue, 24 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > > Hi Nek's, > > Up to now I have compiled and run the code on the various workstations > available in my lab. I am now trying to compile it (only in serial for the > moment) on an IBM Power 6 ( > http://www.idris.fr/su/Scalaire/vargas/hw-vargas.html ) but I encounter an > error (which is the reason why I do not compile it using mpi support > yet). Following is the outpost from the compilation: > > xlf_r -qsuppress=cmpmsg -o nek5000 obj/stenosis.o obj/drive.o obj/drive1.o > obj/drive2.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o > obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o > obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o > obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o > obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o > obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o > obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o > obj/hsmg.o > obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o > obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o obj/byte.o > obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/cvode_driver.o > obj/nek_comm.o obj/init_plugin.o obj/setprop.o obj/qthermal.o > obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o obj/dsygv.o > obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o obj/singlmesh.o > obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o obj/jl2_sarray_sort.o > obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o > obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o > obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o > obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o > obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o > obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o > ld: 0711-317 ERROR: Undefined symbol: .etime > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more > information. > gmake: *** [nek5000] Error 8 > > Attached is the whole compiler.out file also. Does anyone have an idea? > > Regards, > > -- > Jean-Christophe > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > -- > Jean-Christophe > > _______________________________________________ > 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 > > -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 25 12:21:35 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 May 2011 19:21:35 +0200 Subject: [Nek5000-users] Compilation error In-Reply-To: <1809040197.104781.1306327264626.JavaMail.root@zimbra.anl.gov> References: <1809040197.104781.1306327264626.JavaMail.root@zimbra.anl.gov> Message-ID: Makenek does currently not support g95 but the GNU Fortran compiler gfortran which is also available on Mac. -Stefan On 5/25/11, nek5000-users at lists.mcs.anl.gov wrote: > Hi Jean-Christophe, > > Could you try to modify makefile after makenek has generated it? That is > what I do for g95 compiler on my Mac. > > The downside is that .f file should be a copy of .usr file every time you > modify it. > > Best, > Aleks > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, May 25, 2011 7:21:58 AM > Subject: Re: [Nek5000-users] Compilation error > > > Thanks for the tip, it now works at least for serial calculation. Note > furthermore that, using the xlf compiler from ibm, I also had to change > -qrealsize=8 into -qautodbl=dbl4 in order to avoid a segmentation fault. > > > I am now trying to compile to it for parallel calculation, thus I specified > mpxlf_r and mpcc_r in F77 and C fields in makenek. However I get the > following message as soon as I start the compilation: > > > > > > > > > ./makenek stenosis > makenek - automatic build tool for Nek5000 > ** test === End of Compilation 1 === > 1501-510 Compilation successful for file test_f77.f. > llsubmit: Processed command file through Submit Filter: > "/usr/local/loadl/Fidris/llsubmit_exit". > ** underscore_test === End of Compilation 1 === > 1501-510 Compilation successful for file test_underscore.f. > ERROR: Unable to detect compiler! > - don't know how to promote datatype REAL to 8 bytes > - don't know how to invoke the C pre-processor (CPP) before compilation > Please edit the makefile and specify the requested compiler flags using the > P variable. > > > I presume it is a fairly simple error to solve, but I am not familiar at all > with such massively parallel calculators yet > > > Best regards, > JC > > On 24 May 2011 16:20, < nek5000-users at lists.mcs.anl.gov > wrote: > > > > Dear Jean-Christophe, > > etime is a fairly std. timer function, but obviously not > supported with your compiler. > > When using mpi, it uses instead the mpi timer, so there is no > issue. > > The quick fix here would be to edit mpi_dummy.f and change > the etime() reference therein to the ibm timer function. > > You might also try setting it zero - but I'm not 100% certain > that there are no divisions involving time in the denominator... > It's worth a try, however. > > Paul > > > > > > > On Tue, 24 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > > Hi Nek's, > > Up to now I have compiled and run the code on the various workstations > available in my lab. I am now trying to compile it (only in serial for the > moment) on an IBM Power 6 ( > http://www.idris.fr/su/Scalaire/vargas/hw-vargas.html ) but I encounter an > error (which is the reason why I do not compile it using mpi support > yet). Following is the outpost from the compilation: > > xlf_r -qsuppress=cmpmsg -o nek5000 obj/stenosis.o obj/drive.o obj/drive1.o > obj/drive2.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o > obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o > obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o > obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o > obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o > obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o > obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o obj/hsmg.o > obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o > obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o obj/byte.o > obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/cvode_driver.o > obj/nek_comm.o obj/init_plugin.o obj/setprop.o obj/qthermal.o > obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o obj/dsygv.o > obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o obj/singlmesh.o > obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o obj/jl2_sarray_sort.o > obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o > obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o > obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o > obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o > obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o > obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o > ld: 0711-317 ERROR: Undefined symbol: .etime > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more > information. > gmake: *** [nek5000] Error 8 > > Attached is the whole compiler.out file also. Does anyone have an idea? > > Regards, > > -- > Jean-Christophe > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > -- > Jean-Christophe > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed May 25 12:36:32 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 May 2011 19:36:32 +0200 Subject: [Nek5000-users] Compilation error In-Reply-To: References: Message-ID: It's not a good idea to use -qautodbl=dbl4 instead of qrealsize=8. This option makes both default REAL and DOUBLE PRECISION be 8 byte quantities. Beware, however, that this option also makes anything declared REAL*4 be 8bytes. This is an issue because some MPI messages will be truncated as the message size is computed based on the assumption that a REAL*4 variable is 4bytes Can you try to run nek with the debugger to see why you run into a SEGFAULT? -Stefan On 5/25/11, nek5000-users at lists.mcs.anl.gov wrote: > Thanks for the tip, it now works at least for serial calculation. Note > furthermore that, using the xlf compiler from ibm, I also had to change > -qrealsize=8 into -qautodbl=dbl4 in order to avoid a segmentation fault. > > I am now trying to compile to it for parallel calculation, thus I specified > mpxlf_r and mpcc_r in F77 and C fields in makenek. However I get the > following message as soon as I start the compilation: > >>>> ./makenek stenosis >>>> makenek - automatic build tool for Nek5000 >>>> ** test === End of Compilation 1 === >>>> 1501-510 Compilation successful for file test_f77.f. >>>> llsubmit: Processed command file through Submit Filter: >>>> "/usr/local/loadl/Fidris/llsubmit_exit". >>>> ** underscore_test === End of Compilation 1 === >>>> 1501-510 Compilation successful for file test_underscore.f. >>>> ERROR: Unable to detect compiler! >>>> - don't know how to promote datatype REAL to 8 bytes >>>> - don't know how to invoke the C pre-processor (CPP) before >>>> compilation >>>> Please edit the makefile and specify the requested compiler flags >>>> using the P variable. > > > I presume it is a fairly simple error to solve, but I am not familiar at all > with such massively parallel calculators yet [?] > > Best regards, > JC > On 24 May 2011 16:20, wrote: >> >> >> Dear Jean-Christophe, >> >> etime is a fairly std. timer function, but obviously not >> supported with your compiler. >> >> When using mpi, it uses instead the mpi timer, so there is no >> issue. >> >> The quick fix here would be to edit mpi_dummy.f and change >> the etime() reference therein to the ibm timer function. >> >> You might also try setting it zero - but I'm not 100% certain >> that there are no divisions involving time in the denominator... >> It's worth a try, however. >> >> Paul >> >> >> >> >> On Tue, 24 May 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Nek's, >>> >>> Up to now I have compiled and run the code on the various workstations >>> available in my lab. I am now trying to compile it (only in serial for >>> the >>> moment) on an IBM Power 6 ( >>> http://www.idris.fr/su/Scalaire/vargas/hw-vargas.html) but I encounter an >>> error (which is the reason why I do not compile it using mpi support >>> yet). Following is the outpost from the compilation: >>> >>> xlf_r -qsuppress=cmpmsg -o nek5000 obj/stenosis.o obj/drive.o >>> obj/drive1.o >>> obj/drive2.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o >>> obj/connect1.o >>> obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o >>> obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o >>> obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o >>> obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o >>> obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o >>> obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o >>> obj/hsmg.o >>> obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o >>> obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o >>> obj/byte.o >>> obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/cvode_driver.o >>> obj/nek_comm.o obj/init_plugin.o obj/setprop.o obj/qthermal.o >>> obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o obj/dsygv.o >>> obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o obj/singlmesh.o >>> obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o >>> obj/jl2_sarray_sort.o >>> obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o >>> obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o >>> obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o >>> obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o >>> obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o >>> obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o >>> ld: 0711-317 ERROR: Undefined symbol: .etime >>> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more >>> information. >>> gmake: *** [nek5000] Error 8 >>> >>> Attached is the whole compiler.out file also. Does anyone have an idea? >>> >>> Regards, >>> >>> -- >>> Jean-Christophe >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > > -- > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Wed May 25 12:40:11 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 25 May 2011 19:40:11 +0200 Subject: [Nek5000-users] Compilation error In-Reply-To: References: Message-ID: Somehow makenek does not recognize your compiler. That's strange as we do not run into these issues on BGL and BGP using the IBM XL Fortran/C compilers. Can you post: - makenek - output of: "mpixlf_r -show" -Stefan On 5/25/11, nek5000-users at lists.mcs.anl.gov wrote: > Thanks for the tip, it now works at least for serial calculation. Note > furthermore that, using the xlf compiler from ibm, I also had to change > -qrealsize=8 into -qautodbl=dbl4 in order to avoid a segmentation fault. > > I am now trying to compile to it for parallel calculation, thus I specified > mpxlf_r and mpcc_r in F77 and C fields in makenek. However I get the > following message as soon as I start the compilation: > >>>> ./makenek stenosis >>>> makenek - automatic build tool for Nek5000 >>>> ** test === End of Compilation 1 === >>>> 1501-510 Compilation successful for file test_f77.f. >>>> llsubmit: Processed command file through Submit Filter: >>>> "/usr/local/loadl/Fidris/llsubmit_exit". >>>> ** underscore_test === End of Compilation 1 === >>>> 1501-510 Compilation successful for file test_underscore.f. >>>> ERROR: Unable to detect compiler! >>>> - don't know how to promote datatype REAL to 8 bytes >>>> - don't know how to invoke the C pre-processor (CPP) before >>>> compilation >>>> Please edit the makefile and specify the requested compiler flags >>>> using the P variable. > > > I presume it is a fairly simple error to solve, but I am not familiar at all > with such massively parallel calculators yet [?] > > Best regards, > JC > On 24 May 2011 16:20, wrote: >> >> >> Dear Jean-Christophe, >> >> etime is a fairly std. timer function, but obviously not >> supported with your compiler. >> >> When using mpi, it uses instead the mpi timer, so there is no >> issue. >> >> The quick fix here would be to edit mpi_dummy.f and change >> the etime() reference therein to the ibm timer function. >> >> You might also try setting it zero - but I'm not 100% certain >> that there are no divisions involving time in the denominator... >> It's worth a try, however. >> >> Paul >> >> >> >> >> On Tue, 24 May 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Nek's, >>> >>> Up to now I have compiled and run the code on the various workstations >>> available in my lab. I am now trying to compile it (only in serial for >>> the >>> moment) on an IBM Power 6 ( >>> http://www.idris.fr/su/Scalaire/vargas/hw-vargas.html) but I encounter an >>> error (which is the reason why I do not compile it using mpi support >>> yet). Following is the outpost from the compilation: >>> >>> xlf_r -qsuppress=cmpmsg -o nek5000 obj/stenosis.o obj/drive.o >>> obj/drive1.o >>> obj/drive2.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o >>> obj/connect1.o >>> obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o >>> obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o >>> obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o >>> obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o >>> obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o >>> obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o >>> obj/hsmg.o >>> obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o >>> obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o >>> obj/byte.o >>> obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/cvode_driver.o >>> obj/nek_comm.o obj/init_plugin.o obj/setprop.o obj/qthermal.o >>> obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o obj/dsygv.o >>> obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o obj/singlmesh.o >>> obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o >>> obj/jl2_sarray_sort.o >>> obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o >>> obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o >>> obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o >>> obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o >>> obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o >>> obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o >>> ld: 0711-317 ERROR: Undefined symbol: .etime >>> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more >>> information. >>> gmake: *** [nek5000] Error 8 >>> >>> Attached is the whole compiler.out file also. Does anyone have an idea? >>> >>> Regards, >>> >>> -- >>> Jean-Christophe >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > > -- > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Sat May 28 11:25:58 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 28 May 2011 18:25:58 +0200 Subject: [Nek5000-users] Subroutine opdssum Message-ID: Dear all, I was looking into the subroutine "vec_dssum", which is called in "opdssum". At a certain point there is a call to "gs_op_many" (a gather scatter operation I guess, isn't it?) and one of the arguments which is passed to this subroutine is "gsh_fld(ifldt)". I printed to screen the content of "gsh_fld" but I don't understand what is the meaning of it. Thanks in advance for your help. Regards, Andreas. From nek5000-users at lists.mcs.anl.gov Mon May 30 12:03:19 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 30 May 2011 19:03:19 +0200 Subject: [Nek5000-users] Problem with conjugate heat transfer + Low Machnumber formulation References: Message-ID: Dear all, I still have the same problem running the case, no way to solve it. The mass flow rate at the outlet is almost 50% bigger than the mass flow rate at the inlet. I obtain the same results both running it serially and in parallel, therefore I don't think that the problem is in the stiffness summation executed in qthermal (the stiffness summation does nothing when you run the code serially, isn't it?), but maybe in opgrad or opdiv. I tried to run a similar case, but I put Dirichlet boundary conditions for the temperature at the interface between solid and fluid, which of course does not make sense for a conjugate heat transfer problem. The strange thing is that this case works fine and the mass flow rate at the inlet is the same as at the outlet. Do you have any suggestion? Regards, Andrea. -----Original Message----- From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of nek5000-users at lists.mcs.anl.gov Sent: Mon 5/16/2011 7:21 PM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Problem with conjugate heat transfer + Low Machnumber formulation Dear all, I am running a case with conjugate heat transfer + Low Mach number formulation, the domain is a 2D channel. The boundary conditions for the temperature are: - fluid: constant inlet temperature equal to 1; - solid: constant temperature equal to 2 at the outer side, at the inner side there is no boundary condition because the energy equation has to be solved, the other sides are insulated. What I see is that the flow starts to accelerate almost immediately even though at the beginning the temperature of the fluid domain is almost 1. The outlet velocity becomes more than two times the inlet velocity. The reason is that at the wall (and especially at the inlet corner) the thermal divergence is quite large, while it is almost zero in the rest of the fluid domain. In a conjugate heat transfer problem the derivative of the temperature is discontinuos across the wall because of the different thermal conductivities. Could there be a problem when "opgrad" and "opdssum" are evaluated in "subroutine qthermal"? I know that they are evaluated only on the fluid domain but maybe the discontinuity in the derivative of the temperature could give some problems. Thanks a lot in advance for your help. Regards, Andrea _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4058 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon May 30 18:10:21 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 30 May 2011 18:10:21 -0500 (CDT) Subject: [Nek5000-users] Subroutine opdssum In-Reply-To: References: Message-ID: Dear Andreas, gsh_fld(ifldt) refers to the gather-scatter handle for field "ifldt" ifldt would be a flag refering to the field (1=velocity, 2=temperature, etc.) for which the gather-scatter (gs) operation is being performed. At present, the situation is not entirely satisfactory because ifield is a global variable that can be in an ambiguous state. In the past, opdssum (like all other "op" commands) would be applied only on a vector field - for which there is only one mesh (or topology), namely, velocity. In MHD, one also has the B-field but this field generally matches the topology of the velocity. This state of affairs will change in the near future when we support a B-field external to the velocity field. I hope this clarifies a bit... Paul On Sat, 28 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > Dear all, > > I was looking into the subroutine "vec_dssum", which is called in "opdssum". > At a certain point there is a call to "gs_op_many" (a gather scatter operation I guess, isn't it?) and one of the arguments which is passed to this subroutine is "gsh_fld(ifldt)". I printed to screen the content of "gsh_fld" but I don't understand what is the meaning of it. > > Thanks in advance for your help. > > Regards, > Andreas. > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sat May 28 11:16:28 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 28 May 2011 16:16:28 +0000 Subject: [Nek5000-users] Subroutine opdssum Message-ID: Dear all, I was looking into the subroutine "vec_dssum", which is called in "opdssum". At a certain point there is a call to "gs_op_many" (a gather scatter operation I guess, isn't it?) and one of the arguments which is passed to this subroutine is "gsh_fld(ifldt)". I printed to screen the content of "gsh_fld" but I don't understand what is the meaning of it. Thanks in advance for your help. Regards, Andreas. From nek5000-users at lists.mcs.anl.gov Tue May 31 10:26:41 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 31 May 2011 17:26:41 +0200 Subject: [Nek5000-users] Subroutine opdssum References: Message-ID: Dear Paul, thank you very much for your help: the answer is very clear. I was asking that question because I have a problem with conjugate heat transfer and Low Mach number formulation (I already posted a question about that) and I was trying to understand what is going on in qthermal.f . When at line 41 of qthermal.f the subroutine opdssum is called, ifield= 2 (temperature field), and when vec_dssum is called, gs_op_many is executed with gsh_fld(ifldt)=1 (where ifldt=ifield). Then at line 50, ifield is changed to 1 (velocity field). After that dssum is called and gs_op is executed with gsh_fld(ifldt)= 0. I don't understand why gsh_fld(2) is equal to 1 while gsh_fld(1) is equal to 0. What is the difference in the two operations? Thanks in advance for your help. With best regards, Andrea. -----Original Message----- From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of nek5000-users at lists.mcs.anl.gov Sent: Tue 5/31/2011 1:10 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Subroutine opdssum Dear Andreas, gsh_fld(ifldt) refers to the gather-scatter handle for field "ifldt" ifldt would be a flag refering to the field (1=velocity, 2=temperature, etc.) for which the gather-scatter (gs) operation is being performed. At present, the situation is not entirely satisfactory because ifield is a global variable that can be in an ambiguous state. In the past, opdssum (like all other "op" commands) would be applied only on a vector field - for which there is only one mesh (or topology), namely, velocity. In MHD, one also has the B-field but this field generally matches the topology of the velocity. This state of affairs will change in the near future when we support a B-field external to the velocity field. I hope this clarifies a bit... Paul On Sat, 28 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > Dear all, > > I was looking into the subroutine "vec_dssum", which is called in "opdssum". > At a certain point there is a call to "gs_op_many" (a gather scatter operation I guess, isn't it?) and one of the arguments which is passed to this subroutine is "gsh_fld(ifldt)". I printed to screen the content of "gsh_fld" but I don't understand what is the meaning of it. > > Thanks in advance for your help. > > Regards, > Andreas. > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3967 bytes Desc: not available URL: