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

Re: [Nek5000-users] Setting up a case from scratch
by nek5000-users＠lists.mcs.anl.gov 29 Nov '12

29 Nov '12

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" <tautges(a)mcs.anl.gov> > To: nek5000-users(a)lists.mcs.anl.gov, "Misun Min" <mmin(a)mcs.anl.gov> > 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(a)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(a)lists.mcs.anl.gov >> To: nek5000-users(a)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, <nek5000-users(a)lists.mcs.anl.gov> wrote: >> >>> Hi Praven, >>> >>> use examples/moab/SIZE >>> >>> Thanks. >>> Aleks >>> >>> >>> >>> On Wed, 28 Nov 2012, nek5000-users(a)lists.mcs.anl.**gov<nek5000-users(a)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(a)lists.mcs.anl.**gov<nek5000-users(a)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(a)lists.mcs.anl.**gov <Nek5000-users(a)lists.mcs.anl.gov> >>> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users<https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users> >>> >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users(a)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(a)mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706

1 5

Re: [Nek5000-users] Setting up a case from scratch
by nek5000-users＠lists.mcs.anl.gov 28 Nov '12

28 Nov '12

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" <tautges(a)mcs.anl.gov> To: nek5000-users(a)lists.mcs.anl.gov, "Misun Min" <mmin(a)mcs.anl.gov> 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(a)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(a)lists.mcs.anl.gov > To: nek5000-users(a)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, <nek5000-users(a)lists.mcs.anl.gov> wrote: > >> Hi Praven, >> >> use examples/moab/SIZE >> >> Thanks. >> Aleks >> >> >> >> On Wed, 28 Nov 2012, nek5000-users(a)lists.mcs.anl.**gov<nek5000-users(a)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(a)lists.mcs.anl.**gov<nek5000-users(a)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(a)lists.mcs.anl.**gov <Nek5000-users(a)lists.mcs.anl.gov> >> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users<https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users> >> > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users(a)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(a)mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706

1 0

Setting up a case from scratch
by nek5000-users＠lists.mcs.anl.gov 28 Nov '12

28 Nov '12

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

1 12

ON for not axis aligned boundaries
by nek5000-users＠lists.mcs.anl.gov 27 Nov '12

27 Nov '12

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 >

1 0

Calculation of sectional forces
by nek5000-users＠lists.mcs.anl.gov 25 Nov '12

25 Nov '12

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

1 2

unable to visualize blasius results in visit
by nek5000-users＠lists.mcs.anl.gov 25 Nov '12

25 Nov '12

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

1 2

Papers and textbooks
by nek5000-users＠lists.mcs.anl.gov 22 Nov '12

22 Nov '12

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

1 1

Visit reader for double precision f files
by nek5000-users＠lists.mcs.anl.gov 16 Nov '12

16 Nov '12

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

1 1

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