From nek5000-users at lists.mcs.anl.gov Fri Nov 9 08:14:05 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Nov 2012 15:14:05 +0100 Subject: [Nek5000-users] Periodic B.C and Genmap Issue In-Reply-To: References: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF52B@EX7.d.ethz.ch> Message-ID: Hi Nek's, This question actually concerns the matlab code to transfer mesh from gambit to Nek. So far, I have used it to mesh pipe flow with a given inlet and oulet and it worked perfectly fine. I would like now to use periodic conditions between the inlet and oulet. As a matter of fact, I have remeshed my pipe with gambit and created 2 set of boundary conditions: 1. the pipe wall 2. a set called 'periodic' that contains all the faces from the inlet and outlet I then export the mesh under the .neu format. The thing is when I use the matlab code to produce my pipe.rea file, here is what I get for any faces subject to the periodic condition: P 1 5 0 0.00000 0.00000 0.00000 0.00000 The 5th face of element 1 should be connected to another element, but nothing comes out the matlab code. Have I missed something while meshing or is there any specific thing to do with the matlab code to be able to handle such periodic boundary conditions? Sincerely yours, JC On 24 June 2010 20:29, wrote: > > There should normally be two spaces after each bc in genbox. > > Regarding format in the .rea file, this is a problem with > mixed characters + numbers on the same input line, particularly > when the input character string supports blanks. > > I typically resolve the issue by looking at the source. > In this case, connect2.f in the nek/ repo indicates: > > > IF (NELGT.LT.1000) THEN > READ(9,50,ERR=500,END=500) > $ CHTEMP, > $ CBC(ISIDE,IEL,IFIELD),ID1,ID2, > $ (BC(II,ISIDE,IEL,IFIELD),II=1,**NBCREA) > 50 FORMAT(A1,A3,2I3,5G14.6) > ELSEIF (NELGT.LT.100000) THEN > READ(9,51,ERR=500,END=500) > $ CHTEMP, > $ CBC(ISIDE,IEL,IFIELD),ID1,ID2, > $ (BC(II,ISIDE,IEL,IFIELD),II=1,**NBCREA) > 51 FORMAT(A1,A3,I5,I1,5G14.6) > ELSEIF (NELGT.LT.1000000) THEN > READ(9,52,ERR=500,END=500) > $ CHTEMP, > $ CBC(ISIDE,IEL,IFIELD),ID1, > $ (BC(II,ISIDE,IEL,IFIELD),II=1,**NBCREA) > 52 FORMAT(A1,A3,I6,5G14.6) > ELSE > > > ... > > > Paul > > > > > On Thu, 24 Jun 2010, nek5000-users at lists.mcs.anl.**govwrote: > > Hi Paul, >> >> I am having a similar problem. >> I am trying to generate a mesh for a 3D periodic channel flow with >> periodic >> boundary conditions in x and z directions and walls on the y direction. >> I use genbox and then genmap. But i got the same error of Shriram. >> Note that i am having problems when i am using double periodic BCs : >> P ,P ,W ,W ,P ,P >> but single BCs works fine : >> P ,P ,W ,W ,W ,W >> W ,W ,W ,W ,P ,P >> W ,W ,P ,P ,W ,W >> >> Do you have a work around or a suggestion? >> >> Thank you >> francesco >> >> >> >> My error is >> >> >> reading .rea file data ... >> reading .re2 file data ... >> start locglob_lexico: 8 512 4096 >> 0.2000000000000000 >> locglob: 1 1 4096 >> locglob: 2 9 4096 >> locglob: 3 81 4096 >> locglob: 1 729 4096 >> locglob: 2 729 4096 >> locglob: 3 729 4096 >> locglob: 1 729 4096 >> locglob: 2 729 4096 >> locglob: 3 729 4096 >> done locglob_lexico: 729 729 4096 8 >> start periodic vtx: 512 729 >> 1 1 5 3 0.00000000E+00 1 shift >> >> abort: PERIODIC MISMATCH 2: >> 1 5 P ie >> 449 6 P je >> 449.0000000000000 0.0000000000000000E+000 bc >> >> >> My .box file is : >> >> >> turbChannel.rea >> 3 spatial dimension >> 1 number of fields >> # >> # comments: This is the box immediately behind the >> # refined cylinder in Ugo?s cyl+b.l. run. >> # >> # >> #=============================**=========================== >> # >> Box 1 Pipe >> -8 -8 -8 Nelx Nely Nelz >> 0.0 6.28 1.0 x0 x1 ratio >> -1.0 1.0 1.0 y0 y1 ratio >> 0.0 3.14 1.0 z0 z1 ratio >> P ,P ,W ,W ,P ,P BC?s: (cbx0, cbx1, cby0, cby1, cbz0, cbz1) >> >> >> >> >> >> >> >> -----Original Message----- >> From: nek5000-users-bounces at lists.**mcs.anl.govon behalf of >> nek5000-users at lists.mcs.anl.**gov >> Sent: Thu 6/24/2010 6:22 PM >> To: nek5000-users at lists.mcs.anl.**gov >> Subject: [Nek5000-users] Periodic B.C and Genmap Issue >> >> 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. >> >> >> 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 >> >> >> >> >> Regards >> Shriram >> >> ______________________________**_________________ >> 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 Fri Nov 9 08:15:29 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Nov 2012 15:15:29 +0100 Subject: [Nek5000-users] Periodic B.C and Genmap Issue In-Reply-To: References: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF52B@EX7.d.ethz.ch> Message-ID: PS: I have tried to send an email to cmeador at tamu.edu first, but I got a return to sender error. On 9 November 2012 15:14, wrote: > Hi Nek's, > > This question actually concerns the matlab code to transfer mesh from > gambit to Nek. So far, I have used it to mesh pipe flow with a given inlet > and oulet and it worked perfectly fine. I would like now to use periodic > conditions between the inlet and oulet. As a matter of fact, I have > remeshed my pipe with gambit and created 2 set of boundary conditions: > > 1. the pipe wall > 2. a set called 'periodic' that contains all the faces from the inlet > and outlet > > I then export the mesh under the .neu format. The thing is when I use the > matlab code to produce my pipe.rea file, here is what I get for any faces > subject to the periodic condition: > > P 1 5 0 0.00000 0.00000 0.00000 > 0.00000 > > The 5th face of element 1 should be connected to another element, but > nothing comes out the matlab code. Have I missed something while meshing or > is there any specific thing to do with the matlab code to be able to handle > such periodic boundary conditions? > > Sincerely yours, > > JC > On 24 June 2010 20:29, wrote: > >> >> There should normally be two spaces after each bc in genbox. >> >> Regarding format in the .rea file, this is a problem with >> mixed characters + numbers on the same input line, particularly >> when the input character string supports blanks. >> >> I typically resolve the issue by looking at the source. >> In this case, connect2.f in the nek/ repo indicates: >> >> >> IF (NELGT.LT.1000) THEN >> READ(9,50,ERR=500,END=500) >> $ CHTEMP, >> $ CBC(ISIDE,IEL,IFIELD),ID1,ID2, >> $ (BC(II,ISIDE,IEL,IFIELD),II=1,**NBCREA) >> 50 FORMAT(A1,A3,2I3,5G14.6) >> ELSEIF (NELGT.LT.100000) THEN >> READ(9,51,ERR=500,END=500) >> $ CHTEMP, >> $ CBC(ISIDE,IEL,IFIELD),ID1,ID2, >> $ (BC(II,ISIDE,IEL,IFIELD),II=1,**NBCREA) >> 51 FORMAT(A1,A3,I5,I1,5G14.6) >> ELSEIF (NELGT.LT.1000000) THEN >> READ(9,52,ERR=500,END=500) >> $ CHTEMP, >> $ CBC(ISIDE,IEL,IFIELD),ID1, >> $ (BC(II,ISIDE,IEL,IFIELD),II=1,**NBCREA) >> 52 FORMAT(A1,A3,I6,5G14.6) >> ELSE >> >> >> ... >> >> >> Paul >> >> >> >> >> On Thu, 24 Jun 2010, nek5000-users at lists.mcs.anl.**govwrote: >> >> Hi Paul, >>> >>> I am having a similar problem. >>> I am trying to generate a mesh for a 3D periodic channel flow with >>> periodic >>> boundary conditions in x and z directions and walls on the y direction. >>> I use genbox and then genmap. But i got the same error of Shriram. >>> Note that i am having problems when i am using double periodic BCs : >>> P ,P ,W ,W ,P ,P >>> but single BCs works fine : >>> P ,P ,W ,W ,W ,W >>> W ,W ,W ,W ,P ,P >>> W ,W ,P ,P ,W ,W >>> >>> Do you have a work around or a suggestion? >>> >>> Thank you >>> francesco >>> >>> >>> >>> My error is >>> >>> >>> reading .rea file data ... >>> reading .re2 file data ... >>> start locglob_lexico: 8 512 4096 >>> 0.2000000000000000 >>> locglob: 1 1 4096 >>> locglob: 2 9 4096 >>> locglob: 3 81 4096 >>> locglob: 1 729 4096 >>> locglob: 2 729 4096 >>> locglob: 3 729 4096 >>> locglob: 1 729 4096 >>> locglob: 2 729 4096 >>> locglob: 3 729 4096 >>> done locglob_lexico: 729 729 4096 8 >>> start periodic vtx: 512 729 >>> 1 1 5 3 0.00000000E+00 1 shift >>> >>> abort: PERIODIC MISMATCH 2: >>> 1 5 P ie >>> 449 6 P je >>> 449.0000000000000 0.0000000000000000E+000 bc >>> >>> >>> My .box file is : >>> >>> >>> turbChannel.rea >>> 3 spatial dimension >>> 1 number of fields >>> # >>> # comments: This is the box immediately behind the >>> # refined cylinder in Ugo?s cyl+b.l. run. >>> # >>> # >>> #=============================**=========================== >>> # >>> Box 1 Pipe >>> -8 -8 -8 Nelx Nely Nelz >>> 0.0 6.28 1.0 x0 x1 ratio >>> -1.0 1.0 1.0 y0 y1 ratio >>> 0.0 3.14 1.0 z0 z1 ratio >>> P ,P ,W ,W ,P ,P BC?s: (cbx0, cbx1, cby0, cby1, cbz0, >>> cbz1) >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: nek5000-users-bounces at lists.**mcs.anl.govon behalf of >>> nek5000-users at lists.mcs.anl.**gov >>> Sent: Thu 6/24/2010 6:22 PM >>> To: nek5000-users at lists.mcs.anl.**gov >>> Subject: [Nek5000-users] Periodic B.C and Genmap Issue >>> >>> 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. >>> >>> >>> 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 >>> >>> >>> >>> >>> Regards >>> Shriram >>> >>> ______________________________**_________________ >>> 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 > > _______________________________________________ > 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 Fri Nov 16 09:06:46 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 16 Nov 2012 15:06:46 +0000 Subject: [Nek5000-users] Visit reader for double precision f files Message-ID: Dear Neks, Reference to previous discussion (Sep.13th) about the support for the reading 64 bit files of nek5000 in VisIt, we have put up together a 3D cylinder as test case. For a double-precision format nek5000 dump file the 3D view and especially iso-contours are working fine whereas any 2D projection slice, or cut of the data is not working properly. In general operations considering the whole grid seem to work fine, but those related to a section of the grid such as box don't. This anomaly is happening regardless of choosing various pressure solver scheme (Pn_Pn/Pn_Pn-2) or including the grid data to be dumped in the file or not. I was wondering if you can help me with this issue. With many thanks Reza P.S. The 3D cylinder test-case located at the origin (0,0,0) of the coordinate system and extruded along the z-axis (perpendicular to the xy plane). The box extends from -15 to 25 in x direction, -9 to 9 in y direction and -2 to 2 in z directions. The mesh is constructed from the 2D cylinder in nek5000 repository. The number of elements is reduced, then extended in the z direction. An example of the dumped file can be found in the ftn: ftp://ftp.mech.kth.se/pub/pschlatt/nek5000 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Nov 16 09:10:01 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 16 Nov 2012 07:10:01 -0800 Subject: [Nek5000-users] Visit reader for double precision f files In-Reply-To: References: Message-ID: Hi Reza, Thank for you putting together this data set and your report. I will download the data set and begin study. Can you send me your personal email so I can ask clarifications without bugging the whole list? (My email is hchilds at lbl.gov) Thanks! -Hank On Fri, Nov 16, 2012 at 7:06 AM, wrote: > *Dear Neks, > * > Reference to previous discussion (Sep.13th) about the support for the reading 64 bit files of nek5000 in VisIt, we have put up together a 3D cylinder as test case. For a double-precision format nek5000 dump file the 3D view and especially iso-contours are working fine whereas any 2D projection slice, or cut of the data is not working properly. In general operations considering the whole grid seem to work fine, but those related to a section of the grid such as box don't. > This anomaly is happening regardless of choosing various pressure solver scheme (Pn_Pn/Pn_Pn-2) or including the grid data to be dumped in the file or not. I was wondering if you can help me with this issue. > > With many thanks > Reza > > P.S. The 3D cylinder test-case located at the origin (0,0,0) of the coordinate system and extruded along the z-axis (perpendicular to the xy plane). The box extends from -15 to 25 in x direction, -9 to 9 in y direction and -2 to 2 in z directions. The mesh is constructed from the 2D cylinder in nek5000 repository. The number of elements is reduced, then extended in the z direction. An example of the dumped file can be found in the ftn: > ftp://ftp.mech.kth.se/pub/pschlatt/nek5000 > > > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Nov 21 21:55:03 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Nov 2012 09:25:03 +0530 Subject: [Nek5000-users] Papers and textbooks Message-ID: Hello I have seen the list of slides and papers on the nek5000 website. Are there any other papers which will help to learn the methods used in nek5000. Also what would be good textbooks for the same ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Nov 22 01:38:04 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Nov 2012 01:38:04 -0600 (CST) Subject: [Nek5000-users] Papers and textbooks In-Reply-To: References: Message-ID: Hi Praveen, My 1997 JCP paper (on www.mcs.anl.gov/~fischer/pubhtml) lays out the basic algorithm for the Pn-Pn-2 method. There is a follow-up paper on Schwarz methods with Miller and Tufo, and then a pair of additional solver papers with Lottes. Another important (and short!) paper is the 2nd filter paper with Julie Mullen (2001 CRAS). Finally there is the book with Deville & Mund that is fairly comprehensive. The papers are all available at the above URL. Best regards, Paul On Thu, 22 Nov 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hello > I have seen the list of slides and papers on the nek5000 website. Are there > any other papers which will help to learn the methods used in nek5000. Also > what would be good textbooks for the same ? > Thanks > praveen > From nek5000-users at lists.mcs.anl.gov Sat Nov 24 11:27:25 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 24 Nov 2012 19:27:25 +0200 Subject: [Nek5000-users] Calculation of sectional forces Message-ID: Dears Neks I am using the solver to perform 3D simulations past an oscillating cylinder. Do you know if there is a subroutine to calculate the sectional lift and drag forces over the cross section of the cylinder in z-direction. Regards Sofia From nek5000-users at lists.mcs.anl.gov Sat Nov 24 17:36:39 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 24 Nov 2012 17:36:39 -0600 (CST) Subject: [Nek5000-users] Calculation of sectional forces In-Reply-To: References: Message-ID: Hi Sofia, There is a routine that computes torque as well as all three components of net force. A few of the examples call this routine --- you should be able to see this via: cd cd nek5_svn cd examples grep -i torq */*.usr The main idea is to identify the surfaces that constitute the object of interest, e.g., via the "set_obj" routine shown in some of these examples. Subsequent calls to the torque_calc routine will compute the net forces on these surfaces and sum them together. Please let us know if this answers your question. Best regards, Paul On Sat, 24 Nov 2012, nek5000-users at lists.mcs.anl.gov wrote: > Dears Neks > > I am using the solver to perform 3D simulations past an oscillating cylinder. > > Do you know if there is a subroutine to calculate the sectional lift and drag > forces over the cross section of the cylinder in z-direction. > > Regards > Sofia > > _______________________________________________ > 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 Nov 25 07:02:14 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 25 Nov 2012 18:32:14 +0530 Subject: [Nek5000-users] unable to visualize blasius results in visit Message-ID: Hello The blasius example saves files as blasius0.f* but the first file does not seem to contain the mesh. How can I visualize this in visit ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Nov 25 07:22:38 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 25 Nov 2012 07:22:38 -0600 (CST) Subject: [Nek5000-users] unable to visualize blasius results in visit In-Reply-To: References: Message-ID: Hi Praveen, Either set ifxyo = .true. in userchk in the .usr file or set the following flag T COORDINATES in the bottom of the .rea file. I'm not 100% certain why the default condition, which is to have the geometry written to the first file, is not working but we'll look into it. Thanks, Paul On Sun, 25 Nov 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hello > The blasius example saves files as blasius0.f* but the first file does not > seem to contain the mesh. How can I visualize this in visit ? > Thanks > praveen > From nek5000-users at lists.mcs.anl.gov Sun Nov 25 07:54:49 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 25 Nov 2012 19:24:49 +0530 Subject: [Nek5000-users] unable to visualize blasius results in visit In-Reply-To: References: Message-ID: Thanks. In the svn version of the code, userchk was saving initial field but not the coordinates. So I changed to ifxyo=.false. if (istep.eq.0)then ifxyo=.true. call outpost(vx,vy,vz,pr,t,' ') endif and then it seems to work fine. praveen On Sun, Nov 25, 2012 at 6:52 PM, wrote: > > Hi Praveen, > > Either set ifxyo = .true. in userchk in the .usr file or > set the following flag > > T COORDINATES > > in the bottom of the .rea file. > > I'm not 100% certain why the default condition, which is to > have the geometry written to the first file, is not working > but we'll look into it. > > Thanks, > > Paul > > > > On Sun, 25 Nov 2012, nek5000-users at lists.mcs.anl.**govwrote: > > Hello >> The blasius example saves files as blasius0.f* but the first file does not >> seem to contain the mesh. How can I visualize this in visit ? >> Thanks >> praveen >> >> ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Nov 25 10:22:51 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 25 Nov 2012 18:22:51 +0200 Subject: [Nek5000-users] Calculation of sectional forces In-Reply-To: References: Message-ID: Thank you Paul Regards Sofia On Sat, 24 Nov 2012 17:36:39 -0600 (CST), nek5000-users at lists.mcs.anl.gov wrote: > Hi Sofia, > > There is a routine that computes torque as well as all three > components of net force. > > A few of the examples call this routine --- you should be > able to see this via: > > cd > cd nek5_svn > cd examples > grep -i torq */*.usr > > The main idea is to identify the surfaces that constitute > the object of interest, e.g., via the "set_obj" routine > shown in some of these examples. Subsequent calls > to the torque_calc routine will compute the net forces > on these surfaces and sum them together. > > Please let us know if this answers your question. > > Best regards, > > Paul > > > On Sat, 24 Nov 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Dears Neks >> >> I am using the solver to perform 3D simulations past an oscillating >> cylinder. >> >> Do you know if there is a subroutine to calculate the sectional lift >> and drag forces over the cross section of the cylinder in z-direction. >> >> Regards >> Sofia >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Nov 27 03:04:26 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 Nov 2012 14:34:26 +0530 Subject: [Nek5000-users] Setting up a case from scratch Message-ID: Hello I want to setup a case of 2d cylinder in a channel. I plan to do this way 1. Make mesh in gmsh 2. Convert to vtx 3. Setup in prex and read vtx mesh. 3.1 make curved sides 3.2 set boundary conditions I have already tried all these steps partly. I want to know if there is any easier way to do it. Especially making curved sides and setting boundary conditions needs to be done per boundary edge. Is there a way to make it faster ? Thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Nov 27 06:40:08 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 Nov 2012 13:40:08 +0100 Subject: [Nek5000-users] ON for not axis aligned boundaries References: <5188A980-62EC-4C21-A58F-F9617C3464D9@mech.kth.se> Message-ID: Hej Neks we're trying to make the 'ON' boundary condition to work for not axis aligned boundaries, we took a look into the code, and if we're not mistaking, we should do a global rotation of "blocks" before setting the velocity masks for the necessary components? I was wondering if you could help us out with this? Cheers Armin > From nek5000-users at lists.mcs.anl.gov Wed Nov 28 06:58:33 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 06:58:33 -0600 (CST) Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: Message-ID: Hi Praveen, I would try building 2D mesh of the side wall of the channel with cylindrical 'hole' first in prex and then extrude this mesh in the spanwise direction with n2to3 tool. Best. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Tuesday, November 27, 2012 3:04:26 AM Subject: [Nek5000-users] Setting up a case from scratch Hello I want to setup a case of 2d cylinder in a channel. I plan to do this way 1. Make mesh in gmsh 2. Convert to vtx 3. Setup in prex and read vtx mesh. 3.1 make curved sides 3.2 set boundary conditions I have already tried all these steps partly. I want to know if there is any easier way to do it. Especially making curved sides and setting boundary conditions needs to be done per boundary edge. Is there a way to make it faster ? Thanks praveen _______________________________________________ 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 Nov 28 07:11:57 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 07:11:57 -0600 (CST) Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: Message-ID: Hi Praveen, I would recommend starting from the "ext_cyl" example. You should be able to make some progress with this and you could use prenek to modify the geometry if needed. Check out the README in that directory. Let me know if you have questions. Paul On Tue, 27 Nov 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hello > I want to setup a case of 2d cylinder in a channel. I plan to do this way > > 1. Make mesh in gmsh > 2. Convert to vtx > 3. Setup in prex and read vtx mesh. > 3.1 make curved sides > 3.2 set boundary conditions > > I have already tried all these steps partly. I want to know if there is any > easier way to do it. Especially making curved sides and setting boundary > conditions needs to be done per boundary edge. Is there a way to make it > faster ? > > Thanks > praveen > From nek5000-users at lists.mcs.anl.gov Wed Nov 28 07:56:01 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 19:26:01 +0530 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: Message-ID: Thanks to Aleks and Paul. I was able to setup the test case using the steps I wrote before (gmsh -> vtx -> prex -> rea). Now I am trying to use nek tools to do it. Starting from ext_cyl, I try to merge the two meshes to understand the process. fpcyl.box needs cc2.rea which I could not find. I changed cc2.rea in fpcyl.box to import.rea Then generate box.rea using genbox. Then I try nekmerge but I get following error. What am I doing wrong ? Thanks praveen $ nekmerge ascii or binary output ? (a/b): a Input new (output) file name: ooo Input source .rea file name or press enter to continue: box Input source .rea file name or press enter to continue: import Input source .rea file name or press enter to continue: locglob: 1 1 1 6144 locglob: 1 2 199 6144 locglob: 2 1 3158 6144 locglob: 2 2 3159 6144 done locglob_lexico: 3159 3159 6144 FACE ERROR: 458 4 520 3 On Wed, Nov 28, 2012 at 6:41 PM, wrote: > > Hi Praveen, > > I would recommend starting from the "ext_cyl" example. > > You should be able to make some progress with this and > you could use prenek to modify the geometry if needed. > Check out the README in that directory. > > Let me know if you have questions. > > Paul > > > On Tue, 27 Nov 2012, nek5000-users at lists.mcs.anl.**govwrote: > > Hello >> I want to setup a case of 2d cylinder in a channel. I plan to do this way >> >> 1. Make mesh in gmsh >> 2. Convert to vtx >> 3. Setup in prex and read vtx mesh. >> 3.1 make curved sides >> 3.2 set boundary conditions >> >> I have already tried all these steps partly. I want to know if there is >> any >> easier way to do it. Especially making curved sides and setting boundary >> conditions needs to be done per boundary edge. Is there a way to make it >> faster ? >> >> Thanks >> praveen >> >> ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Nov 28 08:00:12 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 19:30:12 +0530 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: Message-ID: If I specify import.rea file of ext_cyl as the first file during nekmerge I get this error $ nekmerge ascii or binary output ? (a/b): a Input new (output) file name: ooo Input source .rea file name or press enter to continue: import At line 19 of file reader.f Fortran runtime error: Bad integer for item 1 in list input praveen On Wed, Nov 28, 2012 at 7:26 PM, wrote: > Thanks to Aleks and Paul. I was able to setup the test case using the > steps I wrote before (gmsh -> vtx -> prex -> rea). > > Now I am trying to use nek tools to do it. > > Starting from ext_cyl, I try to merge the two meshes to understand the > process. > > fpcyl.box needs cc2.rea which I could not find. I changed cc2.rea in > fpcyl.box to import.rea > > Then generate box.rea using genbox. > > Then I try nekmerge but I get following error. What am I doing wrong ? > > Thanks > praveen > > $ nekmerge > ascii or binary output ? (a/b): > a > Input new (output) file name: > ooo > Input source .rea file name or press enter to continue: > box > Input source .rea file name or press enter to continue: > import > Input source .rea file name or press enter to continue: > > locglob: 1 1 1 6144 > locglob: 1 2 199 6144 > locglob: 2 1 3158 6144 > locglob: 2 2 3159 6144 > done locglob_lexico: 3159 3159 6144 > FACE ERROR: 458 4 520 3 > > > On Wed, Nov 28, 2012 at 6:41 PM, wrote: > >> >> Hi Praveen, >> >> I would recommend starting from the "ext_cyl" example. >> >> You should be able to make some progress with this and >> you could use prenek to modify the geometry if needed. >> Check out the README in that directory. >> >> Let me know if you have questions. >> >> Paul >> >> >> On Tue, 27 Nov 2012, nek5000-users at lists.mcs.anl.**govwrote: >> >> Hello >>> I want to setup a case of 2d cylinder in a channel. I plan to do this way >>> >>> 1. Make mesh in gmsh >>> 2. Convert to vtx >>> 3. Setup in prex and read vtx mesh. >>> 3.1 make curved sides >>> 3.2 set boundary conditions >>> >>> I have already tried all these steps partly. I want to know if there is >>> any >>> easier way to do it. Especially making curved sides and setting boundary >>> conditions needs to be done per boundary edge. Is there a way to make it >>> faster ? >>> >>> Thanks >>> praveen >>> >>> ______________________________**_________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.**gov >> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >> > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Nov 28 08:47:17 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 08:47:17 -0600 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: Message-ID: Note that this should be relatively trivial to do with the MOAB-based version of Nek (MOAB can read gmsh meshes already). I'm not sure whether you can specify higher-order hexes in gmsh, but if you can, start by generating those (27-node hex). Building and running Nek on MOAB is described in the Nek user's guide and on the nek wiki. The examples/moab problem is a MOAB-based one, showing how to do this for a fluid-only problem; moab_conjht demonstrates it for a fluid/solid problem. Note that the user documentation on text input is a bit out of date, so refer to the moab example rather than the user's guide for that (will take this as an indication I need to update the user's guide and wiki). As for boundary conditions, I'm not sure how this is represented in the gmsh files (whether groups of nodes/faces are indicated in the file, or whether a field on nodes/faces/sides is used to indicate this). If the former, these should read into MOAB sets marked with NEUMANN_SET or DIRICHLET_SET tags; if the latter, you'll have to interpret this data in the .usr file to set the boundary conditions. MOAB's gmsh reader is not parallelized, so if you want to run this problem in parallel, you'll need to translate into MOAB's .h5m file format, then partition, as described in the wiki instructions. Building MOAB builds also 'mbconvert', which converts between any file formats read/written by MOAB (for that matter, partitioning with MOAB's tool would allow you to read the gmsh file directly and output the partitioning info with the mesh to .h5m). - tim On 11/27/2012 03:04 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello > I want to setup a case of 2d cylinder in a channel. I plan to do this way > > 1. Make mesh in gmsh > 2. Convert to vtx > 3. Setup in prex and read vtx mesh. > 3.1 make curved sides > 3.2 set boundary conditions > > I have already tried all these steps partly. I want to know if there is any easier way to do it. Especially making > curved sides and setting boundary conditions needs to be done per boundary edge. Is there a way to make it faster ? > > Thanks > praveen > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (tautges at mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706 From nek5000-users at lists.mcs.anl.gov Wed Nov 28 09:12:28 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 20:42:28 +0530 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: Message-ID: Thanks Tim. Gmsh+moab was my next question and you answered it. I will try to see if it works. I made a mesh in gmsh with quadratic elements and mbconvert was able to convert it, atleast I get no error. Does this mean that nek will be able to use the curved element information contained in the mesh ? I see that gmsh can generate upto 5'th order elements (degree 5). In gmsh I can group boundary faces into sets which are identified by an integer tag, which should help in specifying boundary condition. praveen On Wed, Nov 28, 2012 at 8:17 PM, wrote: > Note that this should be relatively trivial to do with the MOAB-based > version of Nek (MOAB can read gmsh meshes already). I'm not sure whether > you can specify higher-order hexes in gmsh, but if you can, start by > generating those (27-node hex). Building and running Nek on MOAB is > described in the Nek user's guide and on the nek wiki. The examples/moab > problem is a MOAB-based one, showing how to do this for a fluid-only > problem; moab_conjht demonstrates it for a fluid/solid problem. Note that > the user documentation on text input is a bit out of date, so refer to the > moab example rather than the user's guide for that (will take this as an > indication I need to update the user's guide and wiki). > > As for boundary conditions, I'm not sure how this is represented in the > gmsh files (whether groups of nodes/faces are indicated in the file, or > whether a field on nodes/faces/sides is used to indicate this). If the > former, these should read into MOAB sets marked with NEUMANN_SET or > DIRICHLET_SET tags; if the latter, you'll have to interpret this data in > the .usr file to set the boundary conditions. > > MOAB's gmsh reader is not parallelized, so if you want to run this problem > in parallel, you'll need to translate into MOAB's .h5m file format, then > partition, as described in the wiki instructions. Building MOAB builds > also 'mbconvert', which converts between any file formats read/written by > MOAB (for that matter, partitioning with MOAB's tool would allow you to > read the gmsh file directly and output the partitioning info with the mesh > to .h5m). > > - tim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Nov 28 09:16:05 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 09:16:05 -0600 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: Message-ID: Try running 'mbsize' on the gmsh file, and check the number of vertices to make sure it's getting all of them. Or, run mbsize -ll, piping the output to a file, and check one of the hexes to make sure it's 27-noded. If that's the case, we're all set (modulo how to handle the BC's). - tim On 11/28/2012 09:12 AM, nek5000-users at lists.mcs.anl.gov wrote: > Thanks Tim. Gmsh+moab was my next question and you answered it. > > I will try to see if it works. I made a mesh in gmsh with quadratic elements and mbconvert was able to convert it, > atleast I get no error. Does this mean that nek will be able to use the curved element information contained in the mesh > ? I see that gmsh can generate upto 5'th order elements (degree 5). > > In gmsh I can group boundary faces into sets which are identified by an integer tag, which should help in specifying > boundary condition. > > praveen > > On Wed, Nov 28, 2012 at 8:17 PM, > wrote: > > Note that this should be relatively trivial to do with the MOAB-based version of Nek (MOAB can read gmsh meshes > already). I'm not sure whether you can specify higher-order hexes in gmsh, but if you can, start by generating > those (27-node hex). Building and running Nek on MOAB is described in the Nek user's guide and on the nek wiki. > The examples/moab problem is a MOAB-based one, showing how to do this for a fluid-only problem; moab_conjht > demonstrates it for a fluid/solid problem. Note that the user documentation on text input is a bit out of date, so > refer to the moab example rather than the user's guide for that (will take this as an indication I need to update > the user's guide and wiki). > > As for boundary conditions, I'm not sure how this is represented in the gmsh files (whether groups of nodes/faces > are indicated in the file, or whether a field on nodes/faces/sides is used to indicate this). If the former, these > should read into MOAB sets marked with NEUMANN_SET or DIRICHLET_SET tags; if the latter, you'll have to interpret > this data in the .usr file to set the boundary conditions. > > MOAB's gmsh reader is not parallelized, so if you want to run this problem in parallel, you'll need to translate > into MOAB's .h5m file format, then partition, as described in the wiki instructions. Building MOAB builds also > 'mbconvert', which converts between any file formats read/written by MOAB (for that matter, partitioning with MOAB's > tool would allow you to read the gmsh file directly and output the partitioning info with the mesh to .h5m). > > - tim > > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (tautges at mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706 From nek5000-users at lists.mcs.anl.gov Wed Nov 28 10:47:59 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 22:17:59 +0530 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: Message-ID: The gmsh file does have all vertices for the higher order elements. I am now trying to compile with moab. I am doing everything in serial for now. I compiled moab succesfully and can convert from gmsh to h5m. But when compiling nek with moab I get this type of errors. This is the first one. gcc -c -O2 -DMOAB -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG /Users/praveen/Applications/nek5_svn/trunk/nek/3rd_party/imeshcutil.c -o obj/imeshcutil.o SIZE:5.21: Included at /Users/praveen/Applications/nek5_svn/trunk/nek/3rd_party/MOABCORE:17: Included at /Users/praveen/Applications/nek5_svn/trunk/nek/3rd_party/NEKMOAB:51: Included at /Users/praveen/Applications/nek5_svn/trunk/nek/3rd_party/moab.f:79: parameter (ldim=2) 1 Error: Symbol 'ldim' at (1) has no IMPLICIT type My makenek looks like this # Fortran compiler F77="gfortran" # C compiler CC="gcc" # pre-processor symbol list # (set PPLIST=? to get a list of available symbols) PPLIST="MOAB" # plug-in list PLUGIN_LIST="" # OPTIONAL SETTINGS # ----------------- # enable MPI (default true) IFMPI="false" # auxilliary files to compile # NOTE: source files have to located in the same directory as makenek # a makefile_usr.inc has to be provided containing the build rules #USR="foo.o" # linking flags #USR_LFLAGS="-L/usr/lib -lfoo" # generic compiler flags #G="-g" # optimization flags #OPT_FLAGS_STD="" #OPT_FLAGS_MAG="" # enable AMG coarse grid solver (default XXT) #IFAMG="true" #IFAMG_DUMP="true" # CVODE path #CVODE_DIR=$HOME/cvode/lib # MOAB/iMESH path MOAB_DIR="/opt/moab" # For linking to MOAB, the following might be needed: # NOTE: compiler specific, use the appropriate one depending on your compiler # GNU: USR_LFLAGS="-lmpi_cxx -lstdc++" # Intel: # USR_LFLAGS="-cxxlib" # PGI: # USR_LFLAGS="-pgcpplibs" # USR_LFLAGS=" -lmpi_cxx -lstdc++" What am I doing wrong ? Thanks praveen On Wed, Nov 28, 2012 at 8:46 PM, wrote: > Try running 'mbsize' on the gmsh file, and check the number of vertices to > make sure it's getting all of them. Or, run mbsize -ll, piping the output > to a file, and check one of the hexes to make sure it's 27-noded. If > that's the case, we're all set (modulo how to handle the BC's). > > - tim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Nov 28 10:57:03 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 10:57:03 -0600 (CST) Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: Message-ID: Hi Praven, use examples/moab/SIZE Thanks. Aleks On Wed, 28 Nov 2012, nek5000-users at lists.mcs.anl.gov wrote: > The gmsh file does have all vertices for the higher order elements. > > I am now trying to compile with moab. I am doing everything in serial for > now. I compiled moab succesfully and can convert from gmsh to h5m. > > But when compiling nek with moab I get this type of errors. This is the > first one. > > gcc -c -O2 -DMOAB -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > /Users/praveen/Applications/nek5_svn/trunk/nek/3rd_party/imeshcutil.c -o > obj/imeshcutil.o > SIZE:5.21: > Included at > /Users/praveen/Applications/nek5_svn/trunk/nek/3rd_party/MOABCORE:17: > Included at > /Users/praveen/Applications/nek5_svn/trunk/nek/3rd_party/NEKMOAB:51: > Included at > /Users/praveen/Applications/nek5_svn/trunk/nek/3rd_party/moab.f:79: > > parameter (ldim=2) > 1 > Error: Symbol 'ldim' at (1) has no IMPLICIT type > > My makenek looks like this > > # Fortran compiler > F77="gfortran" > > # C compiler > CC="gcc" > > # pre-processor symbol list > # (set PPLIST=? to get a list of available symbols) > PPLIST="MOAB" > > # plug-in list > PLUGIN_LIST="" > > > # OPTIONAL SETTINGS > # ----------------- > > # enable MPI (default true) > IFMPI="false" > > # auxilliary files to compile > # NOTE: source files have to located in the same directory as makenek > # a makefile_usr.inc has to be provided containing the build rules > #USR="foo.o" > > # linking flags > #USR_LFLAGS="-L/usr/lib -lfoo" > > > # generic compiler flags > #G="-g" > > # optimization flags > #OPT_FLAGS_STD="" > #OPT_FLAGS_MAG="" > > # enable AMG coarse grid solver (default XXT) > #IFAMG="true" > #IFAMG_DUMP="true" > > # CVODE path > #CVODE_DIR=$HOME/cvode/lib > > # MOAB/iMESH path > MOAB_DIR="/opt/moab" > > # For linking to MOAB, the following might be needed: > # NOTE: compiler specific, use the appropriate one depending on your > compiler > # GNU: > USR_LFLAGS="-lmpi_cxx -lstdc++" > # Intel: > # USR_LFLAGS="-cxxlib" > # PGI: > # USR_LFLAGS="-pgcpplibs" > # USR_LFLAGS=" -lmpi_cxx -lstdc++" > > What am I doing wrong ? > > Thanks > praveen > > On Wed, Nov 28, 2012 at 8:46 PM, wrote: > >> Try running 'mbsize' on the gmsh file, and check the number of vertices to >> make sure it's getting all of them. Or, run mbsize -ll, piping the output >> to a file, and check one of the hexes to make sure it's 27-noded. If >> that's the case, we're all set (modulo how to handle the BC's). >> >> - tim >> > From nek5000-users at lists.mcs.anl.gov Wed Nov 28 11:23:04 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 22:53:04 +0530 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: Message-ID: Thanks. I am making little progress. Now I can compile. When running on h5m mesh I get read .rea file ABORT: nelv is invalid in nekmoab_proc_map nelv, lelv = 0 1850 But mbsize shows $ mbsize karman.h5m File karman.h5m: type count total minimum average rms maximum std.dev. ------- ----- ------- ----------- ----------- ----------- ----------- ----------- Edge 212 5.5 0.0063678 0.026102 0.029283 0.048844 0.013273 Quad 1832 0.89 3.8386e-05 0.0004881 0.00054375 0.0011788 0.00023963 1D Side 7328 1.8e+02 0.0037915 0.024086 0.027266 0.048844 0.012777 Vertex 7540 praveen On Wed, Nov 28, 2012 at 10:27 PM, wrote: > Hi Praven, > > use examples/moab/SIZE > > Thanks. > Aleks > > > > On Wed, 28 Nov 2012, nek5000-users at lists.mcs.anl.**govwrote: > > The gmsh file does have all vertices for the higher order elements. >> >> I am now trying to compile with moab. I am doing everything in serial for >> now. I compiled moab succesfully and can convert from gmsh to h5m. >> >> But when compiling nek with moab I get this type of errors. This is the >> first one. >> >> gcc -c -O2 -DMOAB -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**imeshcutil.c >> -o >> obj/imeshcutil.o >> SIZE:5.21: >> Included at >> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**MOABCORE:17: >> Included at >> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**NEKMOAB:51: >> Included at >> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**moab.f:79: >> >> parameter (ldim=2) >> 1 >> Error: Symbol 'ldim' at (1) has no IMPLICIT type >> >> My makenek looks like this >> >> # Fortran compiler >> F77="gfortran" >> >> # C compiler >> CC="gcc" >> >> # pre-processor symbol list >> # (set PPLIST=? to get a list of available symbols) >> PPLIST="MOAB" >> >> # plug-in list >> PLUGIN_LIST="" >> >> >> # OPTIONAL SETTINGS >> # ----------------- >> >> # enable MPI (default true) >> IFMPI="false" >> >> # auxilliary files to compile >> # NOTE: source files have to located in the same directory as makenek >> # a makefile_usr.inc has to be provided containing the build rules >> #USR="foo.o" >> >> # linking flags >> #USR_LFLAGS="-L/usr/lib -lfoo" >> >> >> # generic compiler flags >> #G="-g" >> >> # optimization flags >> #OPT_FLAGS_STD="" >> #OPT_FLAGS_MAG="" >> >> # enable AMG coarse grid solver (default XXT) >> #IFAMG="true" >> #IFAMG_DUMP="true" >> >> # CVODE path >> #CVODE_DIR=$HOME/cvode/lib >> >> # MOAB/iMESH path >> MOAB_DIR="/opt/moab" >> >> # For linking to MOAB, the following might be needed: >> # NOTE: compiler specific, use the appropriate one depending on your >> compiler >> # GNU: >> USR_LFLAGS="-lmpi_cxx -lstdc++" >> # Intel: >> # USR_LFLAGS="-cxxlib" >> # PGI: >> # USR_LFLAGS="-pgcpplibs" >> # USR_LFLAGS=" -lmpi_cxx -lstdc++" >> >> What am I doing wrong ? >> >> Thanks >> praveen >> >> On Wed, Nov 28, 2012 at 8:46 PM, > >> wrote: >> >> Try running 'mbsize' on the gmsh file, and check the number of vertices >>> to >>> make sure it's getting all of them. Or, run mbsize -ll, piping the >>> output >>> to a file, and check one of the hexes to make sure it's 27-noded. If >>> that's the case, we're all set (modulo how to handle the BC's). >>> >>> - tim >>> >>> >> ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Nov 28 11:28:58 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 11:28:58 -0600 (CST) Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: Message-ID: It looks like Nek does not get the mesh from MOAB... Also I doubt the currecnt version of Nek/MOAB supports 2D Quad meshes -- only 3D hexes, right, Tim? Thanks. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wed, 28 Nov 2012 11:23:04 -0600 (CST) Subject: Re: [Nek5000-users] Setting up a case from scratch Thanks. I am making little progress. Now I can compile. When running on h5m mesh I get read .rea file ABORT: nelv is invalid in nekmoab_proc_map nelv, lelv = 0 1850 But mbsize shows $ mbsize karman.h5m File karman.h5m: type count total minimum average rms maximum std.dev. ------- ----- ------- ----------- ----------- ----------- ----------- ----------- Edge 212 5.5 0.0063678 0.026102 0.029283 0.048844 0.013273 Quad 1832 0.89 3.8386e-05 0.0004881 0.00054375 0.0011788 0.00023963 1D Side 7328 1.8e+02 0.0037915 0.024086 0.027266 0.048844 0.012777 Vertex 7540 praveen On Wed, Nov 28, 2012 at 10:27 PM, wrote: > Hi Praven, > > use examples/moab/SIZE > > Thanks. > Aleks > > > > On Wed, 28 Nov 2012, nek5000-users at lists.mcs.anl.**govwrote: > > The gmsh file does have all vertices for the higher order elements. >> >> I am now trying to compile with moab. I am doing everything in serial for >> now. I compiled moab succesfully and can convert from gmsh to h5m. >> >> But when compiling nek with moab I get this type of errors. This is the >> first one. >> >> gcc -c -O2 -DMOAB -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**imeshcutil.c >> -o >> obj/imeshcutil.o >> SIZE:5.21: >> Included at >> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**MOABCORE:17: >> Included at >> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**NEKMOAB:51: >> Included at >> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**moab.f:79: >> >> parameter (ldim=2) >> 1 >> Error: Symbol 'ldim' at (1) has no IMPLICIT type >> >> My makenek looks like this >> >> # Fortran compiler >> F77="gfortran" >> >> # C compiler >> CC="gcc" >> >> # pre-processor symbol list >> # (set PPLIST=? to get a list of available symbols) >> PPLIST="MOAB" >> >> # plug-in list >> PLUGIN_LIST="" >> >> >> # OPTIONAL SETTINGS >> # ----------------- >> >> # enable MPI (default true) >> IFMPI="false" >> >> # auxilliary files to compile >> # NOTE: source files have to located in the same directory as makenek >> # a makefile_usr.inc has to be provided containing the build rules >> #USR="foo.o" >> >> # linking flags >> #USR_LFLAGS="-L/usr/lib -lfoo" >> >> >> # generic compiler flags >> #G="-g" >> >> # optimization flags >> #OPT_FLAGS_STD="" >> #OPT_FLAGS_MAG="" >> >> # enable AMG coarse grid solver (default XXT) >> #IFAMG="true" >> #IFAMG_DUMP="true" >> >> # CVODE path >> #CVODE_DIR=$HOME/cvode/lib >> >> # MOAB/iMESH path >> MOAB_DIR="/opt/moab" >> >> # For linking to MOAB, the following might be needed: >> # NOTE: compiler specific, use the appropriate one depending on your >> compiler >> # GNU: >> USR_LFLAGS="-lmpi_cxx -lstdc++" >> # Intel: >> # USR_LFLAGS="-cxxlib" >> # PGI: >> # USR_LFLAGS="-pgcpplibs" >> # USR_LFLAGS=" -lmpi_cxx -lstdc++" >> >> What am I doing wrong ? >> >> Thanks >> praveen >> >> On Wed, Nov 28, 2012 at 8:46 PM, > >> wrote: >> >> Try running 'mbsize' on the gmsh file, and check the number of vertices >>> to >>> make sure it's getting all of them. Or, run mbsize -ll, piping the >>> output >>> to a file, and check one of the hexes to make sure it's 27-noded. If >>> that's the case, we're all set (modulo how to handle the BC's). >>> >>> - tim >>> >>> >> ______________________________**_________________ > 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 Nov 28 13:23:02 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 13:23:02 -0600 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: Message-ID: Misun and one of her students had that working recently, but I'm not sure if all her updates have been committed to the code. Misun? - tim On 11/28/2012 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: > It looks like Nek does not get the mesh from MOAB... > > Also I doubt the currecnt version of Nek/MOAB supports 2D Quad meshes -- only 3D hexes, right, Tim? > > Thanks. > Aleks > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wed, 28 Nov 2012 11:23:04 -0600 (CST) > Subject: Re: [Nek5000-users] Setting up a case from scratch > > Thanks. I am making little progress. Now I can compile. When running on h5m > mesh I get > > read .rea file > ABORT: nelv is invalid in nekmoab_proc_map > nelv, lelv = 0 1850 > > But mbsize shows > > $ mbsize karman.h5m > File karman.h5m: > type count total minimum average rms maximum > std.dev. > ------- ----- ------- ----------- ----------- ----------- ----------- > ----------- > Edge 212 5.5 0.0063678 0.026102 0.029283 0.048844 > 0.013273 > Quad 1832 0.89 3.8386e-05 0.0004881 0.00054375 0.0011788 > 0.00023963 > 1D Side 7328 1.8e+02 0.0037915 0.024086 0.027266 0.048844 > 0.012777 > Vertex 7540 > > praveen > > On Wed, Nov 28, 2012 at 10:27 PM, wrote: > >> Hi Praven, >> >> use examples/moab/SIZE >> >> Thanks. >> Aleks >> >> >> >> On Wed, 28 Nov 2012, nek5000-users at lists.mcs.anl.**govwrote: >> >> The gmsh file does have all vertices for the higher order elements. >>> >>> I am now trying to compile with moab. I am doing everything in serial for >>> now. I compiled moab succesfully and can convert from gmsh to h5m. >>> >>> But when compiling nek with moab I get this type of errors. This is the >>> first one. >>> >>> gcc -c -O2 -DMOAB -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**imeshcutil.c >>> -o >>> obj/imeshcutil.o >>> SIZE:5.21: >>> Included at >>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**MOABCORE:17: >>> Included at >>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**NEKMOAB:51: >>> Included at >>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**moab.f:79: >>> >>> parameter (ldim=2) >>> 1 >>> Error: Symbol 'ldim' at (1) has no IMPLICIT type >>> >>> My makenek looks like this >>> >>> # Fortran compiler >>> F77="gfortran" >>> >>> # C compiler >>> CC="gcc" >>> >>> # pre-processor symbol list >>> # (set PPLIST=? to get a list of available symbols) >>> PPLIST="MOAB" >>> >>> # plug-in list >>> PLUGIN_LIST="" >>> >>> >>> # OPTIONAL SETTINGS >>> # ----------------- >>> >>> # enable MPI (default true) >>> IFMPI="false" >>> >>> # auxilliary files to compile >>> # NOTE: source files have to located in the same directory as makenek >>> # a makefile_usr.inc has to be provided containing the build rules >>> #USR="foo.o" >>> >>> # linking flags >>> #USR_LFLAGS="-L/usr/lib -lfoo" >>> >>> >>> # generic compiler flags >>> #G="-g" >>> >>> # optimization flags >>> #OPT_FLAGS_STD="" >>> #OPT_FLAGS_MAG="" >>> >>> # enable AMG coarse grid solver (default XXT) >>> #IFAMG="true" >>> #IFAMG_DUMP="true" >>> >>> # CVODE path >>> #CVODE_DIR=$HOME/cvode/lib >>> >>> # MOAB/iMESH path >>> MOAB_DIR="/opt/moab" >>> >>> # For linking to MOAB, the following might be needed: >>> # NOTE: compiler specific, use the appropriate one depending on your >>> compiler >>> # GNU: >>> USR_LFLAGS="-lmpi_cxx -lstdc++" >>> # Intel: >>> # USR_LFLAGS="-cxxlib" >>> # PGI: >>> # USR_LFLAGS="-pgcpplibs" >>> # USR_LFLAGS=" -lmpi_cxx -lstdc++" >>> >>> What am I doing wrong ? >>> >>> Thanks >>> praveen >>> >>> On Wed, Nov 28, 2012 at 8:46 PM, > >>> wrote: >>> >>> Try running 'mbsize' on the gmsh file, and check the number of vertices >>>> to >>>> make sure it's getting all of them. Or, run mbsize -ll, piping the >>>> output >>>> to a file, and check one of the hexes to make sure it's 27-noded. If >>>> that's the case, we're all set (modulo how to handle the BC's). >>>> >>>> - tim >>>> >>>> >>> ______________________________**_________________ >> 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 > -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (tautges at mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706 From nek5000-users at lists.mcs.anl.gov Wed Nov 28 16:45:00 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 16:45:00 -0600 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: <1571030809.59392.1354131353537.JavaMail.root@zimbra.anl.gov> References: <1571030809.59392.1354131353537.JavaMail.root@zimbra.anl.gov> Message-ID: Oh, right, ok. I'd forgotten that those parts of NekCEM and Nek5000 are different. - tim On 11/28/2012 01:35 PM, Misun Min wrote: > > Hi Tim > > MOAB supporting 2D quad meshes have been tested for NekCEM/LBM > codes but not tested with nek5000. I'll check with Aleks to make > sure the updated moab routines not to conflict with nek5000 and > commit soon. > > Thanks > Misun > > ----- Original Message ----- > From: "Tim Tautges" > To: nek5000-users at lists.mcs.anl.gov, "Misun Min" > Sent: Wednesday, November 28, 2012 1:23:02 PM > Subject: Re: [Nek5000-users] Setting up a case from scratch > > Misun and one of her students had that working recently, but I'm not sure if all her updates have been committed to the > code. Misun? > > - tim > > On 11/28/2012 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: >> It looks like Nek does not get the mesh from MOAB... >> >> Also I doubt the currecnt version of Nek/MOAB supports 2D Quad meshes -- only 3D hexes, right, Tim? >> >> Thanks. >> Aleks >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Wed, 28 Nov 2012 11:23:04 -0600 (CST) >> Subject: Re: [Nek5000-users] Setting up a case from scratch >> >> Thanks. I am making little progress. Now I can compile. When running on h5m >> mesh I get >> >> read .rea file >> ABORT: nelv is invalid in nekmoab_proc_map >> nelv, lelv = 0 1850 >> >> But mbsize shows >> >> $ mbsize karman.h5m >> File karman.h5m: >> type count total minimum average rms maximum >> std.dev. >> ------- ----- ------- ----------- ----------- ----------- ----------- >> ----------- >> Edge 212 5.5 0.0063678 0.026102 0.029283 0.048844 >> 0.013273 >> Quad 1832 0.89 3.8386e-05 0.0004881 0.00054375 0.0011788 >> 0.00023963 >> 1D Side 7328 1.8e+02 0.0037915 0.024086 0.027266 0.048844 >> 0.012777 >> Vertex 7540 >> >> praveen >> >> On Wed, Nov 28, 2012 at 10:27 PM, wrote: >> >>> Hi Praven, >>> >>> use examples/moab/SIZE >>> >>> Thanks. >>> Aleks >>> >>> >>> >>> On Wed, 28 Nov 2012, nek5000-users at lists.mcs.anl.**govwrote: >>> >>> The gmsh file does have all vertices for the higher order elements. >>>> >>>> I am now trying to compile with moab. I am doing everything in serial for >>>> now. I compiled moab succesfully and can convert from gmsh to h5m. >>>> >>>> But when compiling nek with moab I get this type of errors. This is the >>>> first one. >>>> >>>> gcc -c -O2 -DMOAB -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**imeshcutil.c >>>> -o >>>> obj/imeshcutil.o >>>> SIZE:5.21: >>>> Included at >>>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**MOABCORE:17: >>>> Included at >>>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**NEKMOAB:51: >>>> Included at >>>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**moab.f:79: >>>> >>>> parameter (ldim=2) >>>> 1 >>>> Error: Symbol 'ldim' at (1) has no IMPLICIT type >>>> >>>> My makenek looks like this >>>> >>>> # Fortran compiler >>>> F77="gfortran" >>>> >>>> # C compiler >>>> CC="gcc" >>>> >>>> # pre-processor symbol list >>>> # (set PPLIST=? to get a list of available symbols) >>>> PPLIST="MOAB" >>>> >>>> # plug-in list >>>> PLUGIN_LIST="" >>>> >>>> >>>> # OPTIONAL SETTINGS >>>> # ----------------- >>>> >>>> # enable MPI (default true) >>>> IFMPI="false" >>>> >>>> # auxilliary files to compile >>>> # NOTE: source files have to located in the same directory as makenek >>>> # a makefile_usr.inc has to be provided containing the build rules >>>> #USR="foo.o" >>>> >>>> # linking flags >>>> #USR_LFLAGS="-L/usr/lib -lfoo" >>>> >>>> >>>> # generic compiler flags >>>> #G="-g" >>>> >>>> # optimization flags >>>> #OPT_FLAGS_STD="" >>>> #OPT_FLAGS_MAG="" >>>> >>>> # enable AMG coarse grid solver (default XXT) >>>> #IFAMG="true" >>>> #IFAMG_DUMP="true" >>>> >>>> # CVODE path >>>> #CVODE_DIR=$HOME/cvode/lib >>>> >>>> # MOAB/iMESH path >>>> MOAB_DIR="/opt/moab" >>>> >>>> # For linking to MOAB, the following might be needed: >>>> # NOTE: compiler specific, use the appropriate one depending on your >>>> compiler >>>> # GNU: >>>> USR_LFLAGS="-lmpi_cxx -lstdc++" >>>> # Intel: >>>> # USR_LFLAGS="-cxxlib" >>>> # PGI: >>>> # USR_LFLAGS="-pgcpplibs" >>>> # USR_LFLAGS=" -lmpi_cxx -lstdc++" >>>> >>>> What am I doing wrong ? >>>> >>>> Thanks >>>> praveen >>>> >>>> On Wed, Nov 28, 2012 at 8:46 PM, > >>>> wrote: >>>> >>>> Try running 'mbsize' on the gmsh file, and check the number of vertices >>>>> to >>>>> make sure it's getting all of them. Or, run mbsize -ll, piping the >>>>> output >>>>> to a file, and check one of the hexes to make sure it's 27-noded. If >>>>> that's the case, we're all set (modulo how to handle the BC's). >>>>> >>>>> - tim >>>>> >>>>> >>>> ______________________________**_________________ >>> 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 >> > -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (tautges at mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706 From nek5000-users at lists.mcs.anl.gov Wed Nov 28 21:40:01 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Nov 2012 09:10:01 +0530 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: <1571030809.59392.1354131353537.JavaMail.root@zimbra.anl.gov> Message-ID: Thanks. I will be eagerly waiting for this. praveen On Thu, Nov 29, 2012 at 4:15 AM, wrote: > Oh, right, ok. I'd forgotten that those parts of NekCEM and Nek5000 are > different. > > - tim > > On 11/28/2012 01:35 PM, Misun Min wrote: > >> >> Hi Tim >> >> MOAB supporting 2D quad meshes have been tested for NekCEM/LBM >> codes but not tested with nek5000. I'll check with Aleks to make >> sure the updated moab routines not to conflict with nek5000 and >> commit soon. >> >> Thanks >> Misun >> >> >> ----- Original Message ----- >> From: "Tim Tautges" >> To: nek5000-users at lists.mcs.anl.**gov , >> "Misun Min" >> Sent: Wednesday, November 28, 2012 1:23:02 PM >> Subject: Re: [Nek5000-users] Setting up a case from scratch >> >> Misun and one of her students had that working recently, but I'm not sure >> if all her updates have been committed to the >> code. Misun? >> >> - tim >> >> On 11/28/2012 11:28 AM, nek5000-users at lists.mcs.anl.**govwrote: >> >>> It looks like Nek does not get the mesh from MOAB... >>> >>> Also I doubt the currecnt version of Nek/MOAB supports 2D Quad meshes -- >>> only 3D hexes, right, Tim? >>> >>> Thanks. >>> Aleks >>> >>> >>> ----- Original Message ----- >>> From: nek5000-users at lists.mcs.anl.**gov >>> To: nek5000-users at lists.mcs.anl.**gov >>> Sent: Wed, 28 Nov 2012 11:23:04 -0600 (CST) >>> Subject: Re: [Nek5000-users] Setting up a case from scratch >>> >>> Thanks. I am making little progress. Now I can compile. When running on >>> h5m >>> mesh I get >>> >>> read .rea file >>> ABORT: nelv is invalid in nekmoab_proc_map >>> nelv, lelv = 0 1850 >>> >>> But mbsize shows >>> >>> $ mbsize karman.h5m >>> File karman.h5m: >>> type count total minimum average rms maximum >>> std.dev. >>> ------- ----- ------- ----------- ----------- ----------- ----------- >>> ----------- >>> Edge 212 5.5 0.0063678 0.026102 0.029283 0.048844 >>> 0.013273 >>> Quad 1832 0.89 3.8386e-05 0.0004881 0.00054375 0.0011788 >>> 0.00023963 >>> 1D Side 7328 1.8e+02 0.0037915 0.024086 0.027266 0.048844 >>> 0.012777 >>> Vertex 7540 >>> >>> praveen >>> >>> On Wed, Nov 28, 2012 at 10:27 PM, > >>> wrote: >>> >>> Hi Praven, >>>> >>>> use examples/moab/SIZE >>>> >>>> Thanks. >>>> Aleks >>>> >>>> >>>> >>>> On Wed, 28 Nov 2012, nek5000-users at lists.mcs.anl.****gov< >>>> nek5000-users at lists.mcs.**anl.gov >>>> >wrote: >>>> >>>> The gmsh file does have all vertices for the higher order elements. >>>> >>>>> >>>>> I am now trying to compile with moab. I am doing everything in serial >>>>> for >>>>> now. I compiled moab succesfully and can convert from gmsh to h5m. >>>>> >>>>> But when compiling nek with moab I get this type of errors. This is the >>>>> first one. >>>>> >>>>> gcc -c -O2 -DMOAB -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE >>>>> -DGLOBAL_LONG_LONG >>>>> /Users/praveen/Applications/****nek5_svn/trunk/nek/3rd_party/*** >>>>> *imeshcutil.c >>>>> -o >>>>> obj/imeshcutil.o >>>>> SIZE:5.21: >>>>> Included at >>>>> /Users/praveen/Applications/****nek5_svn/trunk/nek/3rd_party/*** >>>>> *MOABCORE:17: >>>>> Included at >>>>> /Users/praveen/Applications/****nek5_svn/trunk/nek/3rd_party/*** >>>>> *NEKMOAB:51: >>>>> Included at >>>>> /Users/praveen/Applications/****nek5_svn/trunk/nek/3rd_party/*** >>>>> *moab.f:79: >>>>> >>>>> parameter (ldim=2) >>>>> 1 >>>>> Error: Symbol 'ldim' at (1) has no IMPLICIT type >>>>> >>>>> My makenek looks like this >>>>> >>>>> # Fortran compiler >>>>> F77="gfortran" >>>>> >>>>> # C compiler >>>>> CC="gcc" >>>>> >>>>> # pre-processor symbol list >>>>> # (set PPLIST=? to get a list of available symbols) >>>>> PPLIST="MOAB" >>>>> >>>>> # plug-in list >>>>> PLUGIN_LIST="" >>>>> >>>>> >>>>> # OPTIONAL SETTINGS >>>>> # ----------------- >>>>> >>>>> # enable MPI (default true) >>>>> IFMPI="false" >>>>> >>>>> # auxilliary files to compile >>>>> # NOTE: source files have to located in the same directory as makenek >>>>> # a makefile_usr.inc has to be provided containing the build >>>>> rules >>>>> #USR="foo.o" >>>>> >>>>> # linking flags >>>>> #USR_LFLAGS="-L/usr/lib -lfoo" >>>>> >>>>> >>>>> # generic compiler flags >>>>> #G="-g" >>>>> >>>>> # optimization flags >>>>> #OPT_FLAGS_STD="" >>>>> #OPT_FLAGS_MAG="" >>>>> >>>>> # enable AMG coarse grid solver (default XXT) >>>>> #IFAMG="true" >>>>> #IFAMG_DUMP="true" >>>>> >>>>> # CVODE path >>>>> #CVODE_DIR=$HOME/cvode/lib >>>>> >>>>> # MOAB/iMESH path >>>>> MOAB_DIR="/opt/moab" >>>>> >>>>> # For linking to MOAB, the following might be needed: >>>>> # NOTE: compiler specific, use the appropriate one depending on your >>>>> compiler >>>>> # GNU: >>>>> USR_LFLAGS="-lmpi_cxx -lstdc++" >>>>> # Intel: >>>>> # USR_LFLAGS="-cxxlib" >>>>> # PGI: >>>>> # USR_LFLAGS="-pgcpplibs" >>>>> # USR_LFLAGS=" -lmpi_cxx -lstdc++" >>>>> >>>>> What am I doing wrong ? >>>>> >>>>> Thanks >>>>> praveen >>>>> >>>>> On Wed, Nov 28, 2012 at 8:46 PM, >>>> nek5000-users at lists.mcs.**anl.gov >> >>>>> wrote: >>>>> >>>>> Try running 'mbsize' on the gmsh file, and check the number of >>>>> vertices >>>>> >>>>>> to >>>>>> make sure it's getting all of them. Or, run mbsize -ll, piping the >>>>>> output >>>>>> to a file, and check one of the hexes to make sure it's 27-noded. If >>>>>> that's the case, we're all set (modulo how to handle the BC's). >>>>>> >>>>>> - tim >>>>>> >>>>>> >>>>>> ______________________________****_________________ >>>>> >>>> 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 >>> >>> >> > -- > ==============================**==============================**==== > "You will keep in perfect peace him whose mind is > steadfast, because he trusts in you." Isaiah 26:3 > > Tim Tautges Argonne National Laboratory > (tautges at mcs.anl.gov) (telecommuting from UW-Madison) > phone (gvoice): (608) 354-1459 1500 Engineering Dr. > fax: (608) 263-4499 Madison, WI 53706 > > ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Nov 29 03:24:57 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Nov 2012 03:24:57 -0600 (CST) Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: <1571030809.59392.1354131353537.JavaMail.root@zimbra.anl.gov> Message-ID: Praveen, You can also merge your rea files using either prex or, if your boundary conditions are set already, pretex. Simply read in mesh 1, then IMPORT MESH and read in mesh 2. Paul On Thu, 29 Nov 2012, nek5000-users at lists.mcs.anl.gov wrote: > Thanks. I will be eagerly waiting for this. > > praveen > > On Thu, Nov 29, 2012 at 4:15 AM, wrote: > >> Oh, right, ok. I'd forgotten that those parts of NekCEM and Nek5000 are >> different. >> >> - tim >> >> On 11/28/2012 01:35 PM, Misun Min wrote: >> >>> >>> Hi Tim >>> >>> MOAB supporting 2D quad meshes have been tested for NekCEM/LBM >>> codes but not tested with nek5000. I'll check with Aleks to make >>> sure the updated moab routines not to conflict with nek5000 and >>> commit soon. >>> >>> Thanks >>> Misun >>> >>> >>> ----- Original Message ----- >>> From: "Tim Tautges" >>> To: nek5000-users at lists.mcs.anl.**gov , >>> "Misun Min" >>> Sent: Wednesday, November 28, 2012 1:23:02 PM >>> Subject: Re: [Nek5000-users] Setting up a case from scratch >>> >>> Misun and one of her students had that working recently, but I'm not sure >>> if all her updates have been committed to the >>> code. Misun? >>> >>> - tim >>> >>> On 11/28/2012 11:28 AM, nek5000-users at lists.mcs.anl.**govwrote: >>> >>>> It looks like Nek does not get the mesh from MOAB... >>>> >>>> Also I doubt the currecnt version of Nek/MOAB supports 2D Quad meshes -- >>>> only 3D hexes, right, Tim? >>>> >>>> Thanks. >>>> Aleks >>>> >>>> >>>> ----- Original Message ----- >>>> From: nek5000-users at lists.mcs.anl.**gov >>>> To: nek5000-users at lists.mcs.anl.**gov >>>> Sent: Wed, 28 Nov 2012 11:23:04 -0600 (CST) >>>> Subject: Re: [Nek5000-users] Setting up a case from scratch >>>> >>>> Thanks. I am making little progress. Now I can compile. When running on >>>> h5m >>>> mesh I get >>>> >>>> read .rea file >>>> ABORT: nelv is invalid in nekmoab_proc_map >>>> nelv, lelv = 0 1850 >>>> >>>> But mbsize shows >>>> >>>> $ mbsize karman.h5m >>>> File karman.h5m: >>>> type count total minimum average rms maximum >>>> std.dev. >>>> ------- ----- ------- ----------- ----------- ----------- ----------- >>>> ----------- >>>> Edge 212 5.5 0.0063678 0.026102 0.029283 0.048844 >>>> 0.013273 >>>> Quad 1832 0.89 3.8386e-05 0.0004881 0.00054375 0.0011788 >>>> 0.00023963 >>>> 1D Side 7328 1.8e+02 0.0037915 0.024086 0.027266 0.048844 >>>> 0.012777 >>>> Vertex 7540 >>>> >>>> praveen >>>> >>>> On Wed, Nov 28, 2012 at 10:27 PM, > >>>> wrote: >>>> >>>> Hi Praven, >>>>> >>>>> use examples/moab/SIZE >>>>> >>>>> Thanks. >>>>> Aleks >>>>> >>>>> >>>>> >>>>> On Wed, 28 Nov 2012, nek5000-users at lists.mcs.anl.****gov< >>>>> nek5000-users at lists.mcs.**anl.gov >>>>>> wrote: >>>>> >>>>> The gmsh file does have all vertices for the higher order elements. >>>>> >>>>>> >>>>>> I am now trying to compile with moab. I am doing everything in serial >>>>>> for >>>>>> now. I compiled moab succesfully and can convert from gmsh to h5m. >>>>>> >>>>>> But when compiling nek with moab I get this type of errors. This is the >>>>>> first one. >>>>>> >>>>>> gcc -c -O2 -DMOAB -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE >>>>>> -DGLOBAL_LONG_LONG >>>>>> /Users/praveen/Applications/****nek5_svn/trunk/nek/3rd_party/*** >>>>>> *imeshcutil.c >>>>>> -o >>>>>> obj/imeshcutil.o >>>>>> SIZE:5.21: >>>>>> Included at >>>>>> /Users/praveen/Applications/****nek5_svn/trunk/nek/3rd_party/*** >>>>>> *MOABCORE:17: >>>>>> Included at >>>>>> /Users/praveen/Applications/****nek5_svn/trunk/nek/3rd_party/*** >>>>>> *NEKMOAB:51: >>>>>> Included at >>>>>> /Users/praveen/Applications/****nek5_svn/trunk/nek/3rd_party/*** >>>>>> *moab.f:79: >>>>>> >>>>>> parameter (ldim=2) >>>>>> 1 >>>>>> Error: Symbol 'ldim' at (1) has no IMPLICIT type >>>>>> >>>>>> My makenek looks like this >>>>>> >>>>>> # Fortran compiler >>>>>> F77="gfortran" >>>>>> >>>>>> # C compiler >>>>>> CC="gcc" >>>>>> >>>>>> # pre-processor symbol list >>>>>> # (set PPLIST=? to get a list of available symbols) >>>>>> PPLIST="MOAB" >>>>>> >>>>>> # plug-in list >>>>>> PLUGIN_LIST="" >>>>>> >>>>>> >>>>>> # OPTIONAL SETTINGS >>>>>> # ----------------- >>>>>> >>>>>> # enable MPI (default true) >>>>>> IFMPI="false" >>>>>> >>>>>> # auxilliary files to compile >>>>>> # NOTE: source files have to located in the same directory as makenek >>>>>> # a makefile_usr.inc has to be provided containing the build >>>>>> rules >>>>>> #USR="foo.o" >>>>>> >>>>>> # linking flags >>>>>> #USR_LFLAGS="-L/usr/lib -lfoo" >>>>>> >>>>>> >>>>>> # generic compiler flags >>>>>> #G="-g" >>>>>> >>>>>> # optimization flags >>>>>> #OPT_FLAGS_STD="" >>>>>> #OPT_FLAGS_MAG="" >>>>>> >>>>>> # enable AMG coarse grid solver (default XXT) >>>>>> #IFAMG="true" >>>>>> #IFAMG_DUMP="true" >>>>>> >>>>>> # CVODE path >>>>>> #CVODE_DIR=$HOME/cvode/lib >>>>>> >>>>>> # MOAB/iMESH path >>>>>> MOAB_DIR="/opt/moab" >>>>>> >>>>>> # For linking to MOAB, the following might be needed: >>>>>> # NOTE: compiler specific, use the appropriate one depending on your >>>>>> compiler >>>>>> # GNU: >>>>>> USR_LFLAGS="-lmpi_cxx -lstdc++" >>>>>> # Intel: >>>>>> # USR_LFLAGS="-cxxlib" >>>>>> # PGI: >>>>>> # USR_LFLAGS="-pgcpplibs" >>>>>> # USR_LFLAGS=" -lmpi_cxx -lstdc++" >>>>>> >>>>>> What am I doing wrong ? >>>>>> >>>>>> Thanks >>>>>> praveen >>>>>> >>>>>> On Wed, Nov 28, 2012 at 8:46 PM, >>>>> nek5000-users at lists.mcs.**anl.gov >> >>>>>> wrote: >>>>>> >>>>>> Try running 'mbsize' on the gmsh file, and check the number of >>>>>> vertices >>>>>> >>>>>>> to >>>>>>> make sure it's getting all of them. Or, run mbsize -ll, piping the >>>>>>> output >>>>>>> to a file, and check one of the hexes to make sure it's 27-noded. If >>>>>>> that's the case, we're all set (modulo how to handle the BC's). >>>>>>> >>>>>>> - tim >>>>>>> >>>>>>> >>>>>>> ______________________________****_________________ >>>>>> >>>>> 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 >>>> >>>> >>> >> -- >> ==============================**==============================**==== >> "You will keep in perfect peace him whose mind is >> steadfast, because he trusts in you." Isaiah 26:3 >> >> Tim Tautges Argonne National Laboratory >> (tautges at mcs.anl.gov) (telecommuting from UW-Madison) >> phone (gvoice): (608) 354-1459 1500 Engineering Dr. >> fax: (608) 263-4499 Madison, WI 53706 >> >> ______________________________**_________________ >> 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 Nov 29 07:45:46 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Nov 2012 19:15:46 +0530 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: <1571030809.59392.1354131353537.JavaMail.root@zimbra.anl.gov> Message-ID: Hi Paul Your suggestion works for me. I am asked a question Would you like to displace existing elements in box? What does that mean ? Thanks praveen On Thu, Nov 29, 2012 at 2:54 PM, wrote: > Praveen, > > You can also merge your rea files using either prex or, if your > boundary conditions are set already, pretex. > > Simply read in mesh 1, then IMPORT MESH and read in mesh 2. > > Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Nov 29 07:53:41 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Nov 2012 19:23:41 +0530 Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: <1571030809.59392.1354131353537.JavaMail.root@zimbra.anl.gov> Message-ID: This is explained in the primer. Does it mean that the two meshes I want to merge need not be conforming, i.e., they can have overlapping parts and prenek will fix that. Thanks praveen On Thu, Nov 29, 2012 at 7:15 PM, wrote: > Hi Paul > Your suggestion works for me. I am asked a question > > Would you like to displace existing elements in box? > > What does that mean ? > > Thanks > praveen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Nov 29 08:00:04 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Nov 2012 08:00:04 -0600 (CST) Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: References: <1571030809.59392.1354131353537.JavaMail.root@zimbra.anl.gov> Message-ID: Hi Praveen, No - they still must be conforming. If you answer Yes, it will eliminate all elements that have centers interior to the bounding box of the imported mesh. The idea of this was that you could build a simple box with genbox, then have a complex insert that would match 2*d interior faces within the original box (of dimension d) and have the insert replace the orginal elements in the interior. Paul On Thu, 29 Nov 2012, nek5000-users at lists.mcs.anl.gov wrote: > This is explained in the primer. Does it mean that the two meshes I want to > merge need not be conforming, i.e., they can have overlapping parts and > prenek will fix that. > > Thanks > praveen > > On Thu, Nov 29, 2012 at 7:15 PM, wrote: > >> Hi Paul >> Your suggestion works for me. I am asked a question >> >> Would you like to displace existing elements in box? >> >> What does that mean ? >> >> Thanks >> praveen >> > From nek5000-users at lists.mcs.anl.gov Thu Nov 29 10:01:59 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Nov 2012 17:01:59 +0100 Subject: [Nek5000-users] go.m in amg_matlab toolbox Message-ID: Dear Neks, is it algorithmically possible to split the program go.m such that the files amg_Aff.dat amg_AfP.dat amg_W.dat amg.dat are generated in parallel, perhaps in four separate programs? The reason why I am asking is that for a larger element number the serial generation of the files takes very long. Thanks a lot, Joerg. From nek5000-users at lists.mcs.anl.gov Wed Nov 28 13:35:53 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Nov 2012 13:35:53 -0600 (CST) Subject: [Nek5000-users] Setting up a case from scratch In-Reply-To: <50B66496.7080201@mcs.anl.gov> Message-ID: Hi Tim MOAB supporting 2D quad meshes have been tested for NekCEM/LBM codes but not tested with nek5000. I'll check with Aleks to make sure the updated moab routines not to conflict with nek5000 and commit soon. Thanks Misun ----- Original Message ----- From: "Tim Tautges" To: nek5000-users at lists.mcs.anl.gov, "Misun Min" Sent: Wednesday, November 28, 2012 1:23:02 PM Subject: Re: [Nek5000-users] Setting up a case from scratch Misun and one of her students had that working recently, but I'm not sure if all her updates have been committed to the code. Misun? - tim On 11/28/2012 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: > It looks like Nek does not get the mesh from MOAB... > > Also I doubt the currecnt version of Nek/MOAB supports 2D Quad meshes -- only 3D hexes, right, Tim? > > Thanks. > Aleks > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wed, 28 Nov 2012 11:23:04 -0600 (CST) > Subject: Re: [Nek5000-users] Setting up a case from scratch > > Thanks. I am making little progress. Now I can compile. When running on h5m > mesh I get > > read .rea file > ABORT: nelv is invalid in nekmoab_proc_map > nelv, lelv = 0 1850 > > But mbsize shows > > $ mbsize karman.h5m > File karman.h5m: > type count total minimum average rms maximum > std.dev. > ------- ----- ------- ----------- ----------- ----------- ----------- > ----------- > Edge 212 5.5 0.0063678 0.026102 0.029283 0.048844 > 0.013273 > Quad 1832 0.89 3.8386e-05 0.0004881 0.00054375 0.0011788 > 0.00023963 > 1D Side 7328 1.8e+02 0.0037915 0.024086 0.027266 0.048844 > 0.012777 > Vertex 7540 > > praveen > > On Wed, Nov 28, 2012 at 10:27 PM, wrote: > >> Hi Praven, >> >> use examples/moab/SIZE >> >> Thanks. >> Aleks >> >> >> >> On Wed, 28 Nov 2012, nek5000-users at lists.mcs.anl.**govwrote: >> >> The gmsh file does have all vertices for the higher order elements. >>> >>> I am now trying to compile with moab. I am doing everything in serial for >>> now. I compiled moab succesfully and can convert from gmsh to h5m. >>> >>> But when compiling nek with moab I get this type of errors. This is the >>> first one. >>> >>> gcc -c -O2 -DMOAB -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**imeshcutil.c >>> -o >>> obj/imeshcutil.o >>> SIZE:5.21: >>> Included at >>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**MOABCORE:17: >>> Included at >>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**NEKMOAB:51: >>> Included at >>> /Users/praveen/Applications/**nek5_svn/trunk/nek/3rd_party/**moab.f:79: >>> >>> parameter (ldim=2) >>> 1 >>> Error: Symbol 'ldim' at (1) has no IMPLICIT type >>> >>> My makenek looks like this >>> >>> # Fortran compiler >>> F77="gfortran" >>> >>> # C compiler >>> CC="gcc" >>> >>> # pre-processor symbol list >>> # (set PPLIST=? to get a list of available symbols) >>> PPLIST="MOAB" >>> >>> # plug-in list >>> PLUGIN_LIST="" >>> >>> >>> # OPTIONAL SETTINGS >>> # ----------------- >>> >>> # enable MPI (default true) >>> IFMPI="false" >>> >>> # auxilliary files to compile >>> # NOTE: source files have to located in the same directory as makenek >>> # a makefile_usr.inc has to be provided containing the build rules >>> #USR="foo.o" >>> >>> # linking flags >>> #USR_LFLAGS="-L/usr/lib -lfoo" >>> >>> >>> # generic compiler flags >>> #G="-g" >>> >>> # optimization flags >>> #OPT_FLAGS_STD="" >>> #OPT_FLAGS_MAG="" >>> >>> # enable AMG coarse grid solver (default XXT) >>> #IFAMG="true" >>> #IFAMG_DUMP="true" >>> >>> # CVODE path >>> #CVODE_DIR=$HOME/cvode/lib >>> >>> # MOAB/iMESH path >>> MOAB_DIR="/opt/moab" >>> >>> # For linking to MOAB, the following might be needed: >>> # NOTE: compiler specific, use the appropriate one depending on your >>> compiler >>> # GNU: >>> USR_LFLAGS="-lmpi_cxx -lstdc++" >>> # Intel: >>> # USR_LFLAGS="-cxxlib" >>> # PGI: >>> # USR_LFLAGS="-pgcpplibs" >>> # USR_LFLAGS=" -lmpi_cxx -lstdc++" >>> >>> What am I doing wrong ? >>> >>> Thanks >>> praveen >>> >>> On Wed, Nov 28, 2012 at 8:46 PM, > >>> wrote: >>> >>> Try running 'mbsize' on the gmsh file, and check the number of vertices >>>> to >>>> make sure it's getting all of them. Or, run mbsize -ll, piping the >>>> output >>>> to a file, and check one of the hexes to make sure it's 27-noded. If >>>> that's the case, we're all set (modulo how to handle the BC's). >>>> >>>> - tim >>>> >>>> >>> ______________________________**_________________ >> 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 > -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (tautges at mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706 From nek5000-users at lists.mcs.anl.gov Fri Nov 16 09:04:17 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 16 Nov 2012 15:04:17 -0000 Subject: [Nek5000-users] Visit reader for double precision f files Message-ID: //Dear Neks, // Reference to previous discussion (Sep.13th) about the support for the reading 64 bit files of nek5000 in VisIt, we have put up together a 3D cylinder as test case. For a double-precision format nek5000 dump file the 3D view and especially iso-contours are working fine whereas any 2D projection slice, or cut of the data is not working properly. In general operations considering the whole grid seem to work fine, but those related to a section of the grid such as box don't. This anomaly is happening regardless of choosing various pressure solver scheme (Pn_Pn/Pn_Pn-2) or including the grid data to be dumped in the file or not. I was wondering if you can help me with this issue. With many thanks Reza P.S. The 3D cylinder test-case located at the origin (0,0,0) of the coordinate system and extruded along the z-axis (perpendicular to the xy plane). The box extends from -15 to 25 in x direction, -9 to 9 in y direction and -2 to 2 in z directions. The mesh is constructed from the 2D cylinder in nek5000 repository. The number of elements is reduced, then extended in the z direction. An example of the dumped file can be found in the ftn: ftp://ftp.mech.kth.se/pub/pschlatt/nek5000 -------------- next part -------------- An HTML attachment was scrubbed... URL: