November 2010 - Nek5000-users - mailman3.cels.anl.gov

problem with closed internal boundaries
by nek5000-users＠lists.mcs.anl.gov 23 Jul '13

23 Jul '13

Hello Neks, I'm trying to model a flow past an obstacle in a channel. As a first step I would like to do a 2D simulation. I'm encountering some problems during the geometry data generation in the nek5000 execution : it looks like the program can only generate NaN values although genmap seems to work well on the .rea file. I can also reopen the rea file with prenek without any problems. Do you have any idea what is going wrong here? Is it problematic to have a closed internal boundary condition? Thanks in advance for any help. Best, Michael B

1 9

Periodic B.C and Genmap Issue
by nek5000-users＠lists.mcs.anl.gov 09 Nov '12

09 Nov '12

Hi Paul, This post is in reference to the previous post by Michael (dated Jun 22). When I try to get a map file for a rea file that has periodic vertices, I get the following error. The rea file was generated the same way as before (Gambit -> Nek through Matlab). I checked on Matlab by plotting the periodic vertices and confirmed for a few faces that they are indeed periodic. Also, as you had earlier suggested (with the new genmap), I tried changing the tolerances fro 0.09 to 0.2 and I get the same periodic mismatch error. Could you provide any leads on where things are going wrong ? Please find below the error message. Thanks. <error> Input (.rea) file name: domain Input mesh tolerance (default 0.2): NOTE: smaller is better, but generous is more forgiving for bad meshes. 0.09 reading .rea file data ... start locglob_lexico: 8 3912 31296 8.99999999999999967E-002 locglob: 1 1 31296 locglob: 2 36 31296 locglob: 3 1224 31296 locglob: 1 4851 31296 locglob: 2 4851 31296 locglob: 3 4851 31296 locglob: 1 4851 31296 locglob: 2 4851 31296 locglob: 3 4851 31296 done locglob_lexico: 4851 4851 31296 10 start periodic vtx: 3912 4851 abort: PERIODIC MISMATCH 2: 1093 1 P ie 0 1 je 4.14470000000000029E-003 0.0000000000000000 bc 8 quit </error> Regards Shriram

1 10

Re: [Nek5000-users] Vanishing Jacobian error description
by nek5000-users＠lists.mcs.anl.gov 10 Mar '11

10 Mar '11

Hi Paul, Here is the rea, usr, & SIZE file I am using. I ran it again without the curved side information and it worked, so I think the problem is somewhere in the curved side section of the rea. The geometry is a square base lofted into a circle in the +z direction. The mesh was generated in gambit. I've developed a matlab code that will take a mesh created in gambit and generate the required REA formatting. I have created some basic shapes to test the matlab portion and the curved side portion, and it worked in most cases (not this one yet). I'm not sure what is going on with the curved side data in this case however. Thanks for looking at this, Michael ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: "Nekton User List" <nek5000-users(a)lists.mcs.anl.gov> Sent: Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Vanishing Jacobian error description Michael, The code is trying to check to ensure that the mesh is valid. Sometimes, however, there are other causes for the problem. Can you send a gzip'd rea/usr file, and I can take a look later tonight. Paul On Tue, 20 Apr 2010, nek5000-users(a)lists.mcs.anl.gov wrote: > Hi, > > I am running into an issue with 'Vanishing Jacobian'. To help understand what the problem > is, could someone explain what is meant in the error? Specifically, what it means by "Xth node" of the element. > Also, I ran into this issue when I was deforming geometries in the usr file, where one of the elements > would overlap another by mistake. However in this case I know there are no overlaps. > > Here is a portion: > > 0 ERROR: Vanishing Jacobian near 91th node of element 69. > 1.40692804605498586E-002 -7.79619559165757245E-003 > 0 xyz: 2.65874E-01 3.54498E-01 2.87050E+00 > 0 xyz: 2.07855E-01 1.77249E-01 2.87050E+00 > > > 0 ERROR: Vanishing Jacobian near 76th node of element 70. > 2.59472856644434001E-002 -2.12442422718029170E-002 > 0 xyz: 2.11655E-01 4.23310E-01 2.62500E+00 > 0 xyz: 3.54498E-01 1.77249E-01 2.87050E+00 > > Thanks for any help deciphering this error! > > - Michael > > > > > > _______________________________________________ Nek5000-users mailing list Nek5000-users(a)lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users

1 4

lambda2
by nek5000-users＠lists.mcs.anl.gov 28 Jan '11

28 Jan '11

dear neks, in the source file postpro.f i found the following subroutine: subroutine lambda2(l2) c c Generate Lambda-2 vortex of Jeong & Hussein, JFM '95 c ... but it is not used in the code and i wanted calculate it for some visualizations. may you can explain me how i can use it. because i tried just to call it in the usrchk subroutine but then i get an error message (segmentation fault...). best, fred

1 4

Visit and NEK 3D data
by nek5000-users＠lists.mcs.anl.gov 06 Jan '11

06 Jan '11

Hello all, I am running into a problem with Visit and NEK 3D data files. Visit (version 1.12.2) reads them in, but the mesh is all jumbled up. If anyone could try Visit on this file, I'd be grateful, perhaps there is some setting in Visit that I overlooked. The data file (4MB) is: http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/si… I use the following meta data file: NEK5000 version: 1.0 filetemplate: c203d.fld%02d firsttimestep: 2 numtimesteps: 1 Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universität Wien (Technical University of Vienna) Inst. f. Strömungsmechanik und Wärmeübertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.h…

1 29

Re: [Nek5000-users] Compute the derivatives
by nek5000-users＠lists.mcs.anl.gov 26 Nov '10

26 Nov '10

Hi Michael, iostep dump works only for the dump of quantities specified as T in your .rea like ***** OUTPUT FIELD SPECIFICATION ***** 8 SPECIFICATIONS FOLLOW T COORDINATES T VELOCITY T PRESSURE T TEMPERATURE F TEMPERATURE GRADIENT 2 PASSIVE SCALARS F F Since userchk is called every timestep so you'll need something like if (mod(istep,iostep).eq.0) then ... Best, Aleks ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: nek5000-users(a)lists.mcs.anl.gov Sent: Thursday, July 1, 2010 7:57:07 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Compute the derivatives Hi Paul and Aleks, I have a question regarding this. I have implemented this and it is working nicely, however it is dumping out a .f file every step, rather than every iotime step I have specified in the rea. Do you know how to fix this? - Michael ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: nek5000-users(a)lists.mcs.anl.gov Sent: Wednesday, June 2, 2010 10:57:41 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Compute the derivatives Hi JC, To dump the computed derivatives into separate field files you can use in userchk ifxyo = .true. ! for cooordinates ifpo = .false. ! turn off pressure output ifto = .false. ! turn off pressure output call outpost(vxx,vxy,vxz,pr,t,'dvx') call outpost(vyx,vyy,vyz,pr,t,'dvy') ... Best, Aleks On Wed, 2 Jun 2010, nek5000-users(a)lists.mcs.anl.gov wrote: > > dudxyz is somewhat dated and slow... > > I recommend somthing like: > > parameter (lt=lx1*ly1*lz1*lelv) > common /mygrad/ vxx(lt),vxy(lt),vxz(lt) > $ , vyx(lt),vyy(lt),vyz(lt) > $ , vzx(lt),vzy(lt),vzz(lt) > > call gradm1(vxx,vxy,vxz,vx) > call gradm1(vyx,vyy,vyz,vy) > call gradm1(vzx,vzy,vzz,vz) > > Note that putting these arrays into a common block, as > shown, is a good idea for several reasons, one of which > is that it guarantees that the data will be byte-aligned with the cache line. > On some machines (e.g., BG/P) this > is crucial for proper functionality - for this reason we > don't mix variable types in a given common block. > > If you subsequently wish to access elements of vxx etc. > on an element-by-element basis you can of course do something > like > > parameter (lt=lx1*ly1*lz1) > common /mygrad/ vxx(lt,lelt),vxy(lt,lelt),vxz(lt,lelt) > : > : > > Paul > > On Wed, 2 Jun 2010, nek5000-users(a)lists.mcs.anl.gov wrote: > >> Hi Nek's, >> >> I have a home-made global stability code, but in order to use it I first >> need to compute the derivatives of my base flow: dUdX, dUdY, dVdX, dVdY. >> How could one compute these derivatives using Nek 5k and drop them along >> with X Y U V in the blah.f**** file (or perhaps another .f**** file) ? I >> assume I have to make use of the subroutine *dudxyz >> (du,u,rm1,sm1,tm1,jm1,imsh,isd)*, but I'm not sure what to put as inputs. >> >> Regards, >> JC >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users(a)lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users(a)lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users(a)lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users

1 9

solver tolerances and norm of residual
by nek5000-users＠lists.mcs.anl.gov 24 Nov '10

24 Nov '10

Hello Neks. I'm wondering about some details regarding the solvers, namely in regard to the following two tolerances: P021 DIVERGENCE tolerance for the pressure solver P022 HELMHOLTZ tolerance for the velocity solver I assume these tolerances are for some norm on the residual of pressure/velocity. If so, what is the specific norm? Thanks. --Mike

1 23

nelt>lelt
by nek5000-users＠lists.mcs.anl.gov 22 Nov '10

22 Nov '10

Hello all, Anyone have any idea what could be causing the following error (I am running 64 processes using 18432 elements)? 18422 18423 18424 18425 18426 18427 18428 18429 18430 18431 18432 done :: mapping elements to processors ABORT: nelt>lelt! 0 14179 288 My SIZE file follows. C Dimension file to be included C C HCUBE array dimensions C parameter (ldim=3) parameter (lx1=6,ly1=lx1,lz1=lx1,lelt=288,lelv=lelt) parameter (lxd=9,lyd=lxd,lzd=lxd) parameter (lelx=1,lely=1,lelz=1) c parameter (lzl=3 + 2*(ldim-3)) c parameter (lx2=lx1-2) parameter (ly2=ly1-2) parameter (lz2=lz1-2) parameter (lx3=lx1) parameter (ly3=ly1) parameter (lz3=lz1) c c parameter (lpelv=lelv,lpelt=lelt,lpert=3) ! perturbation c parameter (lpx1=lx1,lpy1=ly1,lpz1=lz1) ! array sizes c parameter (lpx2=lx2,lpy2=ly2,lpz2=lz2) c parameter (lpelv=1,lpelt=1,lpert=1) ! perturbation parameter (lpx1=1,lpy1=1,lpz1=1) ! array sizes parameter (lpx2=1,lpy2=1,lpz2=1) c c c parameter (lbelv=lelv,lbelt=lelt) ! MHD c parameter (lbx1=lx1,lby1=ly1,lbz1=lz1) ! array sizes c parameter (lbx2=lx2,lby2=ly2,lbz2=lz2) c parameter (lbelv=1,lbelt=1) ! MHD parameter (lbx1=1,lby1=1,lbz1=1) ! array sizes parameter (lbx2=1,lby2=1,lbz2=1) c C LX1M=LX1 when there are moving meshes; =1 otherwise parameter (lx1m=lx1,ly1m=ly1,lz1m=lz1) parameter (ldimt= 11) ! 3 passive scalars + T parameter (ldimt1=ldimt+1) parameter (ldimt3=ldimt+3) parameter (lp = 64) parameter (lelg = 18432) c c Note: In the new code, LELGEC should be about sqrt(LELG) c PARAMETER (LELGEC = 1) PARAMETER (LXYZ2 = 1) PARAMETER (LXZ21 = 1) c PARAMETER (LMAXV=LX1*LY1*LZ1*LELV) PARAMETER (LMAXT=LX1*LY1*LZ1*LELT) PARAMETER (LMAXP=LX2*LY2*LZ2*LELV) PARAMETER (LXZ=LX1*LZ1) PARAMETER (LORDER=3) PARAMETER (MAXOBJ=4,MAXMBR=LELT*6,lhis=1) C C Common Block Dimensions C PARAMETER (LCTMP0 =2*LX1*LY1*LZ1*LELT) PARAMETER (LCTMP1 =4*LX1*LY1*LZ1*LELT) C C The parameter LVEC controls whether an additional 42 field arrays C are required for Steady State Solutions. If you are not using C Steady State, it is recommended that LVEC=1. C PARAMETER (LVEC=1) C C Uzawa projection array dimensions C parameter (mxprev = 20) parameter (lgmres = 30) C C Split projection array dimensions C parameter(lmvec = 1) parameter(lsvec = 1) parameter(lstore=lmvec*lsvec) c c NONCONFORMING STUFF c parameter (maxmor = lelt) C C Array dimensions C COMMON/DIMN/NELV,NELT,NX1,NY1,NZ1,NX2,NY2,NZ2 $,NX3,NY3,NZ3,NDIM,NFIELD,NPERT,NID $,NXD,NYD,NZD c automatically added by makenek parameter(lxo = lx1) ! max output grid size (lxo>=lx1) c automatically added by makenek parameter(lpart = 10 ) ! max number of particles c automatically added by makenek integer ax1,ay1,az1,ax2,ay2,az2 parameter (ax1=lx1,ay1=ly1,az1=lz1,ax2=lx2,ay2=ly2,az2=lz2) ! running averages -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universität Wien (Vienna University of Technology) Inst. f. Strömungsmechanik und Wärmeübertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.h…

1 2

Temperature Issue, non physical values for certain Pr num.
by nek5000-users＠lists.mcs.anl.gov 18 Nov '10

18 Nov '10

Hi, I am having an issue with temperature values in my domain. The domain consists of two inlets, one at a temperature of 300 and the other 100. It appears that the interface between the two is giving non-physical temperatures, but what is interesting is the magnitude of these over/under shoots is dependent on the Prandtl number. To see the extend of this I saved the max/min temperature in the domain for several time steps. See the attached image. The low Pr case had Pr = 0.005, where as the other case had Pr = 0.71. Both cases show non - physical results, but the low Pr case seems to recover and approach the limits for the domain given by the boundary conditions. In the other Pr = 0.71 case, the fluctuations and magnitudes are much larger and don't appear to stabilize and recover. Again, I have looked at fld files to confirm that these large differences occur at the interface between the hot/cold fluid. Is there a solution to this problem? Thanks, Michael

1 3

Users Meeting, Dec. 9 & 10
by nek5000-users＠lists.mcs.anl.gov 16 Nov '10

16 Nov '10

Dear Nek Users, We're happy to confirm that Uesrmeeting2010 is on for Dec. 9 and 10. It appears that we will have ~20 participants. More detail concerning the schedule will be forthcoming in an email to registered participants in the next few days. We look forward to meeting you at Argonne next month! -- The Nek5k development group

1 0