From nek5000-users at lists.mcs.anl.gov Mon Aug 5 16:19:37 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 5 Aug 2013 16:19:37 -0500 Subject: [Nek5000-users] Pulsatile Flow in NEK5000 Message-ID: Hi There NEKs, I am currently trying to run a case with pulsatile inlet condition. The context is pulsatile stenotic flows. I have two Question regrading the set up: 1st Question) How do I access the "Time" variable in NEK5000? I need to define a time dependent inlet velocity condition in the user file. V as a function of Y and T. I already have the function which is a patient specific velocity inlet profile. Please note that this should be a pulsatile flow. This, I assume, is different than a periodic flow. I'll be investigation the effect of pulsatility on some 2D geometries. It would be wonderful to know how to implement time dependent inlet velocity condition in user file. Previously I have only used steady and parabolic inlet velocity. 2nd Question) I will be using a simple Dirichlet BC on pressure for the outlet. I have also used the Nozzle outlet condition but, as it turns out, I cannot use the Nozzle condition with stress formulation. I wanted to know if the Sponge condition for outlet is proper and if it can be coupled with stress formulation? I am considering a non-Newtonian fluid with variable viscosity for my simulation. Any assistance is greatly appreciated. Best of luck to everyone, Javid -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Aug 5 17:24:32 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 5 Aug 2013 17:24:32 -0500 (CDT) Subject: [Nek5000-users] Pulsatile Flow in NEK5000 In-Reply-To: Message-ID: Hi Javid, You simply need to use the "time" variable, e.g., ux=1-y*y gives the steady state solution, whereas eps = 0.1 period = 5.0 arg = 2*pi*time/period ux = (1-y*y)*(1+eps*sin(arg)) would give a sinusoidal fluctuation. (Note that this is _not_ the Womersely solution that is the exact inlet condition for fully developed pulsatile flow...) Regarding outflow, I don't know why the standard nozzle approach would not work with the stress formulation. Am on travel at the moment and don't have time to dig into this, but perhaps someone else can assist. Best, Paul ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov, "Cassel Kevin" Sent: Monday, August 5, 2013 4:19:37 PM Subject: [Nek5000-users] Pulsatile Flow in NEK5000 Hi There NEKs, I am currently trying to run a case with pulsatile inlet condition. The context is pulsatile stenotic flows. I have two Question regrading the set up: 1st Question) How do I access the "Time" variable in NEK5000? I need to define a time dependent inlet velocity condition in the user file. V as a function of Y and T. I already have the function which is a patient specific velocity inlet profile. Please note that this should be a pulsatile flow. This, I assume, is different than a periodic flow. I'll be investigation the effect of pulsatility on some 2D geometries. It would be wonderful to know how to implement time dependent inlet velocity condition in user file. Previously I have only used steady and parabolic inlet velocity. 2nd Question) I will be using a simple Dirichlet BC on pressure for the outlet. I have also used the Nozzle outlet condition but, as it turns out, I cannot use the Nozzle condition with stress formulation. I wanted to know if the Sponge condition for outlet is proper and if it can be coupled with stress formulation? I am considering a non-Newtonian fluid with variable viscosity for my simulation. Any assistance is greatly appreciated. Best of luck to everyone, Javid _______________________________________________ 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 Aug 6 17:34:44 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 6 Aug 2013 17:34:44 -0500 Subject: [Nek5000-users] Nek5000-users Digest, Vol 54, Issue 1 In-Reply-To: References: Message-ID: Hi Paul, Thanks so much for the help and quick response. The code is running fine. I do realize that this is not a Womersley inlet. In fact I have access to patient specific Doppler measured velocity profiles (V of T in this case) that I am implementing with the assumption of a fully developed flow. This is justified to some extent since the vein in reality, before the spot that we consider the inlet for our study, is long enough to develop a parabolic profile in the tube. Am still waiting for any ideas if the Sponge outlet condition can be used with stress formulation for non-Newtonian flows. Cheers, Javid On Tue, Aug 6, 2013 at 12:00 PM, wrote: > Send Nek5000-users mailing list submissions to > nek5000-users at lists.mcs.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > or, via email, send a message with subject or body 'help' to > nek5000-users-request at lists.mcs.anl.gov > > You can reach the person managing the list at > nek5000-users-owner at lists.mcs.anl.gov > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nek5000-users digest..." > > > Today's Topics: > > 1. Pulsatile Flow in NEK5000 (nek5000-users at lists.mcs.anl.gov) > 2. Re: Pulsatile Flow in NEK5000 (nek5000-users at lists.mcs.anl.gov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 5 Aug 2013 16:19:37 -0500 > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov, Cassel Kevin > Subject: [Nek5000-users] Pulsatile Flow in NEK5000 > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi There NEKs, > > I am currently trying to run a case with pulsatile inlet condition. The > context is pulsatile stenotic flows. I have two Question regrading the set > up: > > 1st Question) How do I access the "Time" variable in NEK5000? I need to > define a time dependent inlet velocity condition in the user file. V as a > function of Y and T. I already have the function which is a patient > specific velocity inlet profile. Please note that this should be a > pulsatile flow. This, I assume, is different than a periodic flow. I'll be > investigation the effect of pulsatility on some 2D geometries. > It would be wonderful to know how to implement time dependent inlet > velocity condition in user file. Previously I have only used steady > and parabolic inlet velocity. > > 2nd Question) I will be using a simple Dirichlet BC on pressure for the > outlet. I have also used the Nozzle outlet condition but, as it turns out, > I cannot use the Nozzle condition with stress formulation. I wanted to know > if the Sponge condition for outlet is proper and if it can be coupled with > stress formulation? I am considering a non-Newtonian fluid with variable > viscosity for my simulation. > > Any assistance is greatly appreciated. > > Best of luck to everyone, > Javid > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.mcs.anl.gov/pipermail/nek5000-users/attachments/20130805/8178cef4/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 5 Aug 2013 17:24:32 -0500 (CDT) > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Pulsatile Flow in NEK5000 > Message-ID: > > Content-Type: text/plain; charset=utf-8 > > > Hi Javid, > > You simply need to use the "time" variable, e.g., > > > ux=1-y*y > > gives the steady state solution, whereas > > eps = 0.1 > period = 5.0 > arg = 2*pi*time/period > ux = (1-y*y)*(1+eps*sin(arg)) > > would give a sinusoidal fluctuation. (Note that this is > _not_ the Womersely solution that is the exact inlet > condition for fully developed pulsatile flow...) > > Regarding outflow, I don't know why the standard nozzle > approach would not work with the stress formulation. > Am on travel at the moment and don't have time to dig > into this, but perhaps someone else can assist. > > Best, Paul > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov, "Cassel Kevin" > Sent: Monday, August 5, 2013 4:19:37 PM > Subject: [Nek5000-users] Pulsatile Flow in NEK5000 > > > > Hi There NEKs, > > > I am currently trying to run a case with pulsatile inlet condition. The > context is pulsatile stenotic flows. I have two Question regrading the set > up: > > > 1st Question) How do I access the "Time" variable in NEK5000? I need to > define a time dependent inlet velocity condition in the user file. V as a > function of Y and T. I already have the function which is a patient > specific velocity inlet profile. Please note that this should be a > pulsatile flow. This, I assume, is different than a periodic flow. I'll be > investigation the effect of pulsatility on some 2D geometries. > It would be wonderful to know how to implement time dependent inlet > velocity condition in user file. Previously I have only used steady and > parabolic inlet velocity. > > > 2nd Question) I will be using a simple Dirichlet BC on pressure for the > outlet. I have also used the Nozzle outlet condition but, as it turns out, > I cannot use the Nozzle condition with stress formulation. I wanted to know > if the Sponge condition for outlet is proper and if it can be coupled with > stress formulation? I am considering a non-Newtonian fluid with variable > viscosity for my simulation. > > > Any assistance is greatly appreciated. > > > Best of luck to everyone, > Javid > _______________________________________________ > 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 > > > End of Nek5000-users Digest, Vol 54, Issue 1 > ******************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Aug 14 13:25:18 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Aug 2013 14:25:18 -0400 Subject: [Nek5000-users] Maketools compile issue of prenek Message-ID: Dear Neks I updated my tools today to the latest version and then after "./maketools clean" and "./maketools all" I encountered a problem in compiling prenek. Even after "rm -rf tools" and "svn update tools", I still see the same problem regardless. Also note that I have set BIGMEM="true" in my maketools. Since I did not have this problem the first time I built the tools, I am not sure how this could be related to my compiler or machine memory (which are all the same). So I would appreciate it if anyone can help me figure this out. Regards, Hesam ---------------------- Make prenek... ---------------------- make[1]: Entering directory `/home/p/peltier/hsalehip/src/nek5_svn/trunk/tools/prenek' gfortran -o /home/p/peltier/hsalehip/bin/prex prenek.o curve.o edit.o build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o xdriver.o -L/usr/lib/X11 -lX11 -lm curve.o: In function `hex_transition_3d_e_': curve.f:(.text+0x6309): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp2_' defined in COMMON section in zipper2.o curve.f:(.text+0x637e): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp2_' defined in COMMON section in zipper2.o curve.f:(.text+0x63ab): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp2_' defined in COMMON section in zipper2.o curve.f:(.text+0x63d8): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp2_' defined in COMMON section in zipper2.o curve.o: In function `hexagon_refine_e_': curve.f:(.text+0x75a5): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp2_' defined in COMMON section in zipper2.o curve.f:(.text+0x763d): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp2_' defined in COMMON section in zipper2.o curve.f:(.text+0x768d): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp2_' defined in COMMON section in zipper2.o build.o: In function `list_delete_': build.f:(.text+0x2d37): relocation truncated to fit: R_X86_64_32S against symbol `idelt_' defined in COMMON section in build.o build.f:(.text+0x2dd1): relocation truncated to fit: R_X86_64_32S against symbol `idelt_' defined in COMMON section in build.o build.o: In function `imp_mesh_vtx_': build.f:(.text+0x30f3): relocation truncated to fit: R_X86_64_32S against symbol `c_xyz_' defined in COMMON section in build.o build.f:(.text+0x3124): additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status make[1]: *** [prex] Error 1 make[1]: Leaving directory `/home/p/peltier/hsalehip/src/nek5_svn/trunk/tools/prenek' make: *** [all] Error 1 From nek5000-users at lists.mcs.anl.gov Wed Aug 14 16:54:36 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Aug 2013 16:54:36 -0500 Subject: [Nek5000-users] Maketools compile issue of prenek In-Reply-To: References: Message-ID: Hi, Have you tried changing BIBMEM= false? Otherwise, if you change your parameter limits (of nelm) in tools/prenek/basics.inc, you should be able to compile. I would suggest trying 100,000 to start. Best, Katie On Wed, Aug 14, 2013 at 1:25 PM, wrote: > Dear Neks > > I updated my tools today to the latest version and then after "./maketools > clean" and "./maketools all" I encountered a problem in compiling prenek. > Even after "rm -rf tools" and "svn update tools", I still see the same > problem regardless. Also note that I have set BIGMEM="true" in my maketools. > > Since I did not have this problem the first time I built the tools, I am > not sure how this could be related to my compiler or machine memory (which > are all the same). So I would appreciate it if anyone can help me figure > this out. > > Regards, > Hesam > > > ---------------------- > Make prenek... > ---------------------- > make[1]: Entering directory `/home/p/peltier/hsalehip/src/** > nek5_svn/trunk/tools/prenek' > gfortran -o /home/p/peltier/hsalehip/bin/**prex prenek.o curve.o edit.o > build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o > vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o > xdriver.o -L/usr/lib/X11 -lX11 -lm > curve.o: In function `hex_transition_3d_e_': > curve.f:(.text+0x6309): relocation truncated to fit: R_X86_64_PC32 against > symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.f:(.text+0x637e): relocation truncated to fit: R_X86_64_PC32 against > symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.f:(.text+0x63ab): relocation truncated to fit: R_X86_64_PC32 against > symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.f:(.text+0x63d8): relocation truncated to fit: R_X86_64_PC32 against > symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.o: In function `hexagon_refine_e_': > curve.f:(.text+0x75a5): relocation truncated to fit: R_X86_64_PC32 against > symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.f:(.text+0x763d): relocation truncated to fit: R_X86_64_PC32 against > symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.f:(.text+0x768d): relocation truncated to fit: R_X86_64_PC32 against > symbol `ctmp2_' defined in COMMON section in zipper2.o > build.o: In function `list_delete_': > build.f:(.text+0x2d37): relocation truncated to fit: R_X86_64_32S against > symbol `idelt_' defined in COMMON section in build.o > build.f:(.text+0x2dd1): relocation truncated to fit: R_X86_64_32S against > symbol `idelt_' defined in COMMON section in build.o > build.o: In function `imp_mesh_vtx_': > build.f:(.text+0x30f3): relocation truncated to fit: R_X86_64_32S against > symbol `c_xyz_' defined in COMMON section in build.o > build.f:(.text+0x3124): additional relocation overflows omitted from the > output > collect2: error: ld returned 1 exit status > make[1]: *** [prex] Error 1 > make[1]: Leaving directory `/home/p/peltier/hsalehip/src/** > nek5_svn/trunk/tools/prenek' > make: *** [all] Error 1 > > > ______________________________**_________________ > 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 Fri Aug 16 10:10:47 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 16 Aug 2013 11:10:47 -0400 Subject: [Nek5000-users] Maketools compile issue of prenek In-Reply-To: References: Message-ID: Hi Katie Thanks for your reply. I did manage to compile prenek with 100,000 nelm. Making BIGMEM = false did not change it though. Regards, Hesam On 13-08-14 05:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > Have you tried changing BIBMEM= false? > > Otherwise, if you change your parameter limits (of nelm) in > tools/prenek/basics.inc, you should be able to compile. I would > suggest trying 100,000 to start. > > Best, > Katie > > > On Wed, Aug 14, 2013 at 1:25 PM, > wrote: > > Dear Neks > > I updated my tools today to the latest version and then after > "./maketools clean" and "./maketools all" I encountered a problem > in compiling prenek. Even after "rm -rf tools" and "svn update > tools", I still see the same problem regardless. Also note that I > have set BIGMEM="true" in my maketools. > > Since I did not have this problem the first time I built the > tools, I am not sure how this could be related to my compiler or > machine memory (which are all the same). So I would appreciate it > if anyone can help me figure this out. > > Regards, > Hesam > > > ---------------------- > Make prenek... > ---------------------- > make[1]: Entering directory > `/home/p/peltier/hsalehip/src/nek5_svn/trunk/tools/prenek' > gfortran -o /home/p/peltier/hsalehip/bin/prex prenek.o curve.o > edit.o build.o build1.o build2.o bound.o plot.o xinterface.o > glomod.o legend.o vprops.o iolib.o subs.o zipper2.o postnek6.o > screen.o revert.o crs.o mxm.o xdriver.o -L/usr/lib/X11 -lX11 -lm > curve.o: In function `hex_transition_3d_e_': > curve.f:(.text+0x6309): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.f:(.text+0x637e): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.f:(.text+0x63ab): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.f:(.text+0x63d8): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.o: In function `hexagon_refine_e_': > curve.f:(.text+0x75a5): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.f:(.text+0x763d): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp2_' defined in COMMON section in zipper2.o > curve.f:(.text+0x768d): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp2_' defined in COMMON section in zipper2.o > build.o: In function `list_delete_': > build.f:(.text+0x2d37): relocation truncated to fit: R_X86_64_32S > against symbol `idelt_' defined in COMMON section in build.o > build.f:(.text+0x2dd1): relocation truncated to fit: R_X86_64_32S > against symbol `idelt_' defined in COMMON section in build.o > build.o: In function `imp_mesh_vtx_': > build.f:(.text+0x30f3): relocation truncated to fit: R_X86_64_32S > against symbol `c_xyz_' defined in COMMON section in build.o > build.f:(.text+0x3124): additional relocation overflows omitted > from the output > collect2: error: ld returned 1 exit status > make[1]: *** [prex] Error 1 > make[1]: Leaving directory > `/home/p/peltier/hsalehip/src/nek5_svn/trunk/tools/prenek' > make: *** [all] Error 1 > > > _______________________________________________ > 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 Fri Aug 16 23:37:51 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 17 Aug 2013 00:37:51 -0400 Subject: [Nek5000-users] compiler optimizations Message-ID: Hello, I have been playing with compiler flags and directives to see if I can improve the time-to-solution of the turbChannel example. I have had some success and would like to give back to the community. What is the best procedure for doing this? I'm using the Intel-13.1.3.192 compiler on a Sandybridge Xeon. baseline timing for 1000 iterations on 8 cpu is total time 443.08s With a few compiler directives and optimization flags I got it down to total time 304.52s Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat Aug 17 09:16:28 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 17 Aug 2013 09:16:28 -0500 (CDT) Subject: [Nek5000-users] compiler optimizations In-Reply-To: References: Message-ID: Hi Dan, Great to hear! If you want to send the flags we could incorporate them into makenek. Thanks! Paul On Sat, 17 Aug 2013, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I have been playing with compiler flags and directives to see if I can > improve the time-to-solution of the turbChannel example. I have had some > success and would like to give back to the community. What is the best > procedure for doing this? > > I'm using the Intel-13.1.3.192 compiler on a Sandybridge Xeon. > > baseline timing for 1000 iterations on 8 cpu is > total time 443.08s > > With a few compiler directives and optimization flags I got it down to > total time 304.52s > > Dan > From nek5000-users at lists.mcs.anl.gov Sat Aug 17 20:07:26 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 17 Aug 2013 21:07:26 -0400 Subject: [Nek5000-users] compiler optimizations In-Reply-To: References: Message-ID: see attached patch files. The Intel C compiler does not recognize "-align array32byte -align zcommons", so you will have to deal with that in makenek.inc and makefile.template. Also see comments prefixed with DSK in mxm_std.patch Hope this helps. Dan On Sat, Aug 17, 2013 at 10:16 AM, wrote: > > Hi Dan, > > Great to hear! > > If you want to send the flags we could incorporate them > into makenek. > > Thanks! > > Paul > > > On Sat, 17 Aug 2013, nek5000-users at lists.mcs.anl.**govwrote: > > Hello, >> >> I have been playing with compiler flags and directives to see if I can >> improve the time-to-solution of the turbChannel example. I have had some >> success and would like to give back to the community. What is the best >> procedure for doing this? >> >> I'm using the Intel-13.1.3.192 compiler on a Sandybridge Xeon. >> >> baseline timing for 1000 iterations on 8 cpu is >> total time 443.08s >> >> With a few compiler directives and optimization flags I got it down to >> total time 304.52s >> >> Dan >> >> ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: convect.patch Type: application/octet-stream Size: 1033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: makenek.inc.patch Type: application/octet-stream Size: 459 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mxm_std.patch Type: application/octet-stream Size: 3386 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon Aug 19 02:45:14 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Aug 2013 09:45:14 +0200 Subject: [Nek5000-users] Solving linearized NS equations in 3D Message-ID: Hi Neks' ! I'm trying to visualize the Crow instability using the linearized equation solver in 3D. However, the resulting vorticity of the perturbation is the same for the calculation in 2D (ie. not the Crow instability). Are there any other parameters to change in the .rea or SIZE files to go from 2D to 3D when using the linearized NS? Any help would be greatly appreciated. Thanks, Holly From nek5000-users at lists.mcs.anl.gov Mon Aug 26 14:15:35 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 Aug 2013 13:15:35 -0600 Subject: [Nek5000-users] Div(flux) in weak form Message-ID: Hello Neks, I'm looking for some guidance, or, better, a code snippet. Within userchk, I have calculated a flux vector: flux = (flux_x, flux_y, flux_z). I need to include the divergence of this vector as a forcing term via qvol. I want to incorporate divergence(flux) in weak form (i.e., apply integration by parts). I believe that I need to use wgradm1 to do this, but the exact syntax in not clear. Would one of you kindly point me in the write direction, or give me the code to do that? I understand the term then needs to be multiplied by the inverse mass matrix. Thanks much! Mike From nek5000-users at lists.mcs.anl.gov Mon Aug 26 14:40:22 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 Aug 2013 12:40:22 -0700 Subject: [Nek5000-users] error in compilation due to high tensor product grid Message-ID: Hi nek users, When ever I try to compile a case of TurbChannel using very high resolution in x,y,z it would give me error as follows. turbChannel.f:(.text+0x24): relocation truncated to fit: R_X86_64_PC32 against symbol `dimn_' defined in COMMON section in obj/turbChannel.o turbChannel.f:(.text+0x4a): relocation truncated to fit: R_X86_64_PC32 against symbol `dimn_' defined in COMMON section in obj/turbChannel.o turbChannel.f:(.text+0x7c): relocation truncated to fit: R_X86_64_PC32 against symbol `gfdmic_' defined in COMMON section in obj/turbChannel.o turbChannel.f:(.text+0xb0): relocation truncated to fit: R_X86_64_PC32 against symbol `dimn_' defined in COMMON section in obj/turbChannel.o turbChannel.f:(.text+0xdf): relocation truncated to fit: R_X86_64_32S against symbol `hcglb_' defined in COMMON section in obj/turbChannel.o turbChannel.f:(.text+0x163): relocation truncated to fit: R_X86_64_32S against symbol `gfdmic_' defined in COMMON section in obj/turbChannel.o turbChannel.f:(.text+0x177): relocation truncated to fit: R_X86_64_PC32 against symbol `dimn_' defined in COMMON section in obj/turbChannel.o turbChannel.f:(.text+0x18b): relocation truncated to fit: R_X86_64_PC32 against symbol `dimn_' defined in COMMON section in obj/turbChannel.o turbChannel.f:(.text+0x19a): relocation truncated to fit: R_X86_64_PC32 against symbol `dimn_' defined in COMMON section in obj/turbChannel.o turbChannel.f:(.text+0x233): relocation truncated to fit: R_X86_64_32S against symbol `gauss_' defined in COMMON section in obj/turbChannel.o obj/turbChannel.o: In function `set_obj_': turbChannel.f:(.text+0x390): additional relocation overflows omitted from the output collect2: ld returned 1 exit status make: *** [nek5000] Error Can anybody please help me on that. Thanks, Tanmoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Aug 26 14:55:06 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 Aug 2013 15:55:06 -0400 Subject: [Nek5000-users] error in compilation due to high tensor product grid In-Reply-To: References: Message-ID: Hi Tanmoy, I believe you should reduce "lelt" is SIZE (implying that you will use more number of processors for your case) and recompile it. Hesam On 13-08-26 03:40 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi nek users, > > When ever I try to compile a case of TurbChannel using very high > resolution in x,y,z it would give me error as follows. > turbChannel.f:(.text+0x24): relocation truncated to fit: R_X86_64_PC32 > against symbol `dimn_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x4a): relocation truncated to fit: R_X86_64_PC32 > against symbol `dimn_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x7c): relocation truncated to fit: R_X86_64_PC32 > against symbol `gfdmic_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0xb0): relocation truncated to fit: R_X86_64_PC32 > against symbol `dimn_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0xdf): relocation truncated to fit: R_X86_64_32S > against symbol `hcglb_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x163): relocation truncated to fit: R_X86_64_32S > against symbol `gfdmic_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x177): relocation truncated to fit: > R_X86_64_PC32 against symbol `dimn_' defined in COMMON section in > obj/turbChannel.o > turbChannel.f:(.text+0x18b): relocation truncated to fit: > R_X86_64_PC32 against symbol `dimn_' defined in COMMON section in > obj/turbChannel.o > turbChannel.f:(.text+0x19a): relocation truncated to fit: > R_X86_64_PC32 against symbol `dimn_' defined in COMMON section in > obj/turbChannel.o > turbChannel.f:(.text+0x233): relocation truncated to fit: R_X86_64_32S > against symbol `gauss_' defined in COMMON section in obj/turbChannel.o > obj/turbChannel.o: In function `set_obj_': > turbChannel.f:(.text+0x390): additional relocation overflows omitted > from the output > collect2: ld returned 1 exit status > make: *** [nek5000] Error > > Can anybody please help me on that. > > Thanks, > > Tanmoy > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Aug 26 14:58:11 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 Aug 2013 12:58:11 -0700 Subject: [Nek5000-users] error in compilation due to high tensor product grid In-Reply-To: References: Message-ID: Hi Hesam, Thank you very much for your advice... Tanmoy On Mon, Aug 26, 2013 at 12:55 PM, wrote: > Hi Tanmoy, > > I believe you should reduce "lelt" is SIZE (implying that you will use > more number of processors for your case) and recompile it. > > Hesam > > > On 13-08-26 03:40 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi nek users, > > When ever I try to compile a case of TurbChannel using very high > resolution in x,y,z it would give me error as follows. > turbChannel.f:(.text+0x24): relocation truncated to fit: R_X86_64_PC32 > against symbol `dimn_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x4a): relocation truncated to fit: R_X86_64_PC32 > against symbol `dimn_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x7c): relocation truncated to fit: R_X86_64_PC32 > against symbol `gfdmic_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0xb0): relocation truncated to fit: R_X86_64_PC32 > against symbol `dimn_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0xdf): relocation truncated to fit: R_X86_64_32S > against symbol `hcglb_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x163): relocation truncated to fit: R_X86_64_32S > against symbol `gfdmic_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x177): relocation truncated to fit: R_X86_64_PC32 > against symbol `dimn_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x18b): relocation truncated to fit: R_X86_64_PC32 > against symbol `dimn_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x19a): relocation truncated to fit: R_X86_64_PC32 > against symbol `dimn_' defined in COMMON section in obj/turbChannel.o > turbChannel.f:(.text+0x233): relocation truncated to fit: R_X86_64_32S > against symbol `gauss_' defined in COMMON section in obj/turbChannel.o > obj/turbChannel.o: In function `set_obj_': > turbChannel.f:(.text+0x390): additional relocation overflows omitted from > the output > collect2: ld returned 1 exit status > make: *** [nek5000] Error > > Can anybody please help me on that. > > Thanks, > > Tanmoy > > > > _______________________________________________ > Nek5000-users mailing listNek5000-users at lists.mcs.anl.govhttps://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 Tue Aug 27 20:11:58 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 Aug 2013 21:11:58 -0400 Subject: [Nek5000-users] Body Force And USR Questions Message-ID: Hi All, I hate to ask such lengthy and simple questions, but I'm getting stuck and could use a sharp kick... I read through source code, examples, and the docs, but could still use some help... I have some background with SEM study and my own trivial code, so I have some understanding of the spatial discretization part of it. I have a trivial "template" problem setup and running. My problem is understanding what some of the variables are (in context of their use in the code), and how to use them in the .usr file to do what I want. I'm trying to simulate a horizontal wind turbine wake flow, using the actuator disc method and then the actuator line method. I can get some flow results by specifying constant body forces in .usr. I have also tried a simple use of what I think is the z-velocity in an equation to calculate a body force, and this seems to work also... I'd like to move on to more complex body force calculations, but need to know more about what some of the variables are; how they're calculated, and how they are used/called in .usr. The following is my first pass at a list of questions: 1) Spatially, which variables specify the actual GLL point numbers (not physical coordinates, but point count in each coordinate direction)? Are these ix,iy,iz? I assume they are numbered per element? 2) Are x,y,z the real physical coordinates in space? Are they the actual domain size? Are there non-dimensional coordinates also? What are the xc,yc,zc variables? 3) Are ux, uy, uz the fluid velocities in the coordinate directions? 4) Can the velocities and forces be specified or referred to at any physical location, or only at the GLL points? In other words, is there internal extrapolation going on, or do I need to specify and read my forces at GLL points only? All the subroutines seem to call based on ix,iy,iz; when I run the following, it does calculate some forces: subroutine userf (ix,iy,iz,ieg) include 'SIZE' include 'TOTAL' include 'NEKUSE' c ffx = 0. ffy = 0. ffz = 0. if ((z>70).AND.(z<71.).AND.(x>60.).AND.(x<90.) +.AND.(y>60.).AND.(y<90.)) then ffz = -(.5*1.2*(uz**2.)*(4.*.9*(1.-.9))) c ffz = (-1000.) endif c write (6,*) ffz,ieg return end However, if I change my spatial selection to: if ((z==71.).AND.(x>60.).AND.(x<90.) +.AND.(y>60.).AND.(y<90.)) then I get no force output. If everything is at the GLL locations, are there available subroutines to extrapolate to/from physical locations? 5) I assume that the subroutines in .usr are called at each time step? Is "istep" the number of the time step? Is "time" the actual time integration time, or the wall clock? What is "itime"? Just want to be able to calculate physical location of a line moving on the grid based on time step... Thanks, Murph -- *Murphy Leo O'Dea, PE"Murph"* PhD Student, Mechanical Engineering /School Of Engineering And Computer Science/ /Oakland University/ mlodea at oakland.edu http://www.secs.oakland.edu/~mlodea/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Aug 28 20:43:54 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Aug 2013 20:43:54 -0500 Subject: [Nek5000-users] Body Force And USR Questions In-Reply-To: References: Message-ID: Murph, 1) Elemental arrays (such as velocity, spatial coordinates, etc) are indeed numbered by elements. These arrays have the form (using the x velocity, for example) vx( lx1, ly1, lz1, lelv), where lx1, ly1, and lz1 are the number of GLL points in each master coordinate direction (r, s, and t, respectively), and lelv is the *allocated* number of local elements on each processor (nelv is the actual number of local elements). For example, if you wanted the x velocity at the (5,4,6) nodal point for local element 10, you would access it as vx(5,4,6,10). 2) The physical coordinates on mesh 1 (velocity grid) are stored globally in the arrays xm1, ym1 and zm1, with the same structure as "vx" above. The x, y, and z variables you might see in .usr file examples are temporary variables that are given to the user for convenience. For example, the subroutine userf has the form subroutine userf(ix,iy,iz,ieg) where ix, iy, iz are the r,s,t indices and ieg is the global element number. The call to userf would appear in a loop as something like do iel=1,nelv ieg = lglel(iel) do iz=1,nz1 do iy=1,ny1 do ix=1,nx1 x = xm1(ix,iy,iz,iel) ?. call userf(ix,iy,iz,ieg) ? (use the user-supplied values for ffx, ffy, and ffz) enddo enddo enddo enddo Note that ieg is the "global" element number (out of the total number of elements in your problem), while iel is the "local" element number (out of the number of elements on a given processor). The process is similar for userbc and useric. There are only physical coordinates in Nek. The arrays xc, yc and zc store the element corner coordinates (4 points in 2D, 8 points in 3D, for each element); basically, these arrays store what you would see in the .rea file. 3) ux, uy, and uz are temporary variables in the same vein as x, y, and z, as listed above. The velocity arrays are vx, vy, and vz for the x, y, and z velocities, and they have the array structure as the spatial coordinates. 4) The subroutines in the .usr file are indeed only at the GLL points. If you wanted to apply a forcing function at a specific point/line (as I'm assuming you want to do when you specify z == 71), you would need to project that to the GLL points. Unfortunately, a projection such as this is not trivial, and I'm not aware of any routines that are already built to do something like that. My suggestion would be to avoid something like z==71, and instead do something like if ( z.gt.(71. - eps).and.z.lt.(71. + eps)) ? where "eps" is chosen larger enough so that you know at least *some* GLL points are encapsulated in this range (so, you might need to play with this number a bit). Also, you may want to avoid using logical symbols such as >= and == and instead use the Fortran 77 equivalents, such as ".ge." and ".eq." . Since the base NEK code is written in F77, using F90-type relation operators *potentially* could cause some problems. 5) userbc and userf are indeed called every time step. "istep" is the time step, and "time" is the simulation time, not wall-clock time. I'm not sure what itime represents. I hope this helps get you started! Josh Ph.D., Texas A&M University '13 On Aug 27, 2013, at 8:11 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi All, > > I hate to ask such lengthy and simple questions, but I'm getting stuck and could use a sharp kick... I read through source code, examples, and the docs, but could still use some help... I have some background with SEM study and my own trivial code, so I have some understanding of the spatial discretization part of it. I have a trivial "template" problem setup and running. > > My problem is understanding what some of the variables are (in context of their use in the code), and how to use them in the .usr file to do what I want. I'm trying to simulate a horizontal wind turbine wake flow, using the actuator disc method and then the actuator line method. I can get some flow results by specifying constant body forces in .usr. I have also tried a simple use of what I think is the z-velocity in an equation to calculate a body force, and this seems to work also... > > I'd like to move on to more complex body force calculations, but need to know more about what some of the variables are; how they're calculated, and how they are used/called in .usr. The following is my first pass at a list of questions: > > 1) Spatially, which variables specify the actual GLL point numbers (not physical coordinates, but point count in each coordinate direction)? Are these ix,iy,iz? I assume they are numbered per element? > > 2) Are x,y,z the real physical coordinates in space? Are they the actual domain size? Are there non-dimensional coordinates also? What are the xc,yc,zc variables? > > 3) Are ux, uy, uz the fluid velocities in the coordinate directions? > > 4) Can the velocities and forces be specified or referred to at any physical location, or only at the GLL points? In other words, is there internal extrapolation going on, or do I need to specify and read my forces at GLL points only? All the subroutines seem to call based on ix,iy,iz; when I run the following, it does calculate some forces: > > subroutine userf (ix,iy,iz,ieg) > include 'SIZE' > include 'TOTAL' > include 'NEKUSE' > c > ffx = 0. > ffy = 0. > ffz = 0. > > if ((z>70).AND.(z<71.).AND.(x>60.).AND.(x<90.) > +.AND.(y>60.).AND.(y<90.)) then > > ffz = -(.5*1.2*(uz**2.)*(4.*.9*(1.-.9))) > c ffz = (-1000.) > endif > > c write (6,*) ffz,ieg > > return > end > > However, if I change my spatial selection to: > > if ((z==71.).AND.(x>60.).AND.(x<90.) > +.AND.(y>60.).AND.(y<90.)) then > > I get no force output. If everything is at the GLL locations, are there available subroutines to extrapolate to/from physical locations? > > 5) I assume that the subroutines in .usr are called at each time step? Is "istep" the number of the time step? Is "time" the actual time integration time, or the wall clock? What is "itime"? Just want to be able to calculate physical location of a line moving on the grid based on time step... > > Thanks, > Murph > > > -- > Murphy Leo O?Dea, PE ?Murph? > PhD Student, Mechanical Engineering > > School Of Engineering And Computer Science > Oakland University > > mlodea at oakland.edu > > http://www.secs.oakland.edu/~mlodea/ > > _______________________________________________ > 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 Aug 29 13:21:51 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Aug 2013 14:21:51 -0400 Subject: [Nek5000-users] convert mesh by MOAB Message-ID: Hi All, I am trying to convert cubit mesh to .h5m using MOAB (mbconvert blah.cub blah.h5m), but I get this error Element ids are not contiguous! Failed to load "pipe.cub". Error code: MB_INDEX_OUT_OF_RANGE (1) Error message: No sparse tag CATEGORY value for Vertex 1 I don't know what is the problem, does anybody can help in this problem. FYI, I used Trelis to make a mesh, is there anything wrong with my geometry or mesh? Thanks, Ami -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Aug 29 13:34:06 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Aug 2013 13:34:06 -0500 Subject: [Nek5000-users] convert mesh by MOAB In-Reply-To: References: Message-ID: Before saving to the .cub file, use the Trelis (Cubit) command "compress ids all". - tim On 08/29/2013 01:21 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi All, > > I am trying to convert cubit mesh to .h5m using MOAB (mbconvert blah.cub blah.h5m), but I get this error > > Element ids are not contiguous! > Failed to load "pipe.cub". > Error code: MB_INDEX_OUT_OF_RANGE (1) > Error message: No sparse tag CATEGORY value for Vertex 1 > > I don't know what is the problem, does anybody can help in this problem. FYI, I used Trelis to make a mesh, is there > anything wrong with my geometry or mesh? > > Thanks, > Ami > > > _______________________________________________ > 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 Thu Aug 29 14:38:31 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Aug 2013 15:38:31 -0400 Subject: [Nek5000-users] convert mesh by MOAB In-Reply-To: References: Message-ID: Thanks tim for your answer, I used that command and now I get this error. Segmentation fault (core dumped) I don't know whatis the problem with my meshing because I can convert from gmsh files (.msh) to .h5m but for cubit it gets stocked!! Do you have any idea what is the problem wiht my meshing stuff with cubit? Thanks, Amirreza On Thu, Aug 29, 2013 at 2:34 PM, wrote: > Before saving to the .cub file, use the Trelis (Cubit) command "compress > ids all". > > - tim > > > On 08/29/2013 01:21 PM, nek5000-users at lists.mcs.anl.**govwrote: > >> Hi All, >> >> I am trying to convert cubit mesh to .h5m using MOAB (mbconvert blah.cub >> blah.h5m), but I get this error >> >> Element ids are not contiguous! >> Failed to load "pipe.cub". >> Error code: MB_INDEX_OUT_OF_RANGE (1) >> Error message: No sparse tag CATEGORY value for Vertex 1 >> >> I don't know what is the problem, does anybody can help in this problem. >> FYI, I used Trelis to make a mesh, is there >> anything wrong with my geometry or mesh? >> >> Thanks, >> Ami >> >> >> ______________________________**_________________ >> 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 Aug 29 14:49:44 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Aug 2013 14:49:44 -0500 Subject: [Nek5000-users] convert mesh by MOAB In-Reply-To: References: Message-ID: Try going through ExodusII (.exo or .g), that might work. Also, which version of cubit are you using? - tim On 08/29/2013 02:38 PM, nek5000-users at lists.mcs.anl.gov wrote: > Thanks tim for your answer, > I used that command and now I get this error. > > Segmentation fault (core dumped) > > I don't know whatis the problem with my meshing because I can convert from gmsh files (.msh) to .h5m but for cubit it > gets stocked!! Do you have any idea what is the problem wiht my meshing stuff with cubit? > > Thanks, > Amirreza > > > On Thu, Aug 29, 2013 at 2:34 PM, > wrote: > > Before saving to the .cub file, use the Trelis (Cubit) command "compress ids all". > > - tim > > > On 08/29/2013 01:21 PM, nek5000-users at lists.mcs.anl.__gov wrote: > > Hi All, > > I am trying to convert cubit mesh to .h5m using MOAB (mbconvert blah.cub blah.h5m), but I get this error > > Element ids are not contiguous! > Failed to load "pipe.cub". > Error code: MB_INDEX_OUT_OF_RANGE (1) > Error message: No sparse tag CATEGORY value for Vertex 1 > > I don't know what is the problem, does anybody can help in this problem. FYI, I used Trelis to make a mesh, is there > anything wrong with my geometry or mesh? > > Thanks, > Ami > > > _________________________________________________ > 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 > > > > > _______________________________________________ > 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 Thu Aug 29 15:07:49 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Aug 2013 16:07:49 -0400 Subject: [Nek5000-users] convert mesh by MOAB In-Reply-To: References: Message-ID: Sorry, but that doesn't work too, it gives me Failed to load "pipe.e". Error code: MB_INDEX_OUT_OF_RANGE (1) Error message: pipe.e: Trouble reading vertices I tried every exporting format but none of them wasn't work, I just made a pipe with map type meshing and then I used ''compress ids all" then I exported it as output. everything before that seems good but MOAB gives me different errors!! Thanks, Ami On Thu, Aug 29, 2013 at 3:49 PM, wrote: > Try going through ExodusII (.exo or .g), that might work. Also, which > version of cubit are you using? > > - tim > > > On 08/29/2013 02:38 PM, nek5000-users at lists.mcs.anl.**govwrote: > >> Thanks tim for your answer, >> I used that command and now I get this error. >> >> Segmentation fault (core dumped) >> >> I don't know whatis the problem with my meshing because I can convert >> from gmsh files (.msh) to .h5m but for cubit it >> gets stocked!! Do you have any idea what is the problem wiht my meshing >> stuff with cubit? >> >> Thanks, >> Amirreza >> >> >> On Thu, Aug 29, 2013 at 2:34 PM, > nek5000-users at lists.**mcs.anl.gov >> >> wrote: >> >> Before saving to the .cub file, use the Trelis (Cubit) command >> "compress ids all". >> >> - tim >> >> >> On 08/29/2013 01:21 PM, nek5000-users at lists.mcs.anl.__**gov > nek5000-users at lists.**mcs.anl.gov > >> wrote: >> >> Hi All, >> >> I am trying to convert cubit mesh to .h5m using MOAB (mbconvert >> blah.cub blah.h5m), but I get this error >> >> Element ids are not contiguous! >> Failed to load "pipe.cub". >> Error code: MB_INDEX_OUT_OF_RANGE (1) >> Error message: No sparse tag CATEGORY value for Vertex 1 >> >> I don't know what is the problem, does anybody can help in this >> problem. FYI, I used Trelis to make a mesh, is there >> anything wrong with my geometry or mesh? >> >> Thanks, >> Ami >> >> >> ______________________________**___________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.__**gov > *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 > 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 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 Aug 29 15:41:32 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Aug 2013 15:41:32 -0500 Subject: [Nek5000-users] convert mesh by MOAB In-Reply-To: References: Message-ID: Are you working in serial or parallel? If the latter you'll have to partition the mesh, using moab's mbpart tool... - tim On 08/29/2013 03:07 PM, nek5000-users at lists.mcs.anl.gov wrote: > Sorry, but that doesn't work too, it gives me > Failed to load "pipe.e". > Error code: MB_INDEX_OUT_OF_RANGE (1) > Error message: pipe.e: Trouble reading vertices > > I tried every exporting format but none of them wasn't work, I just made a pipe with map type meshing and then I used > ''compress ids all" then I exported it as output. everything before that seems good but MOAB gives me different errors!! > > Thanks, > Ami > > > On Thu, Aug 29, 2013 at 3:49 PM, > wrote: > > Try going through ExodusII (.exo or .g), that might work. Also, which version of cubit are you using? > > - tim > > > On 08/29/2013 02:38 PM, nek5000-users at lists.mcs.anl.__gov wrote: > > Thanks tim for your answer, > I used that command and now I get this error. > > Segmentation fault (core dumped) > > I don't know whatis the problem with my meshing because I can convert from gmsh files (.msh) to .h5m but for > cubit it > gets stocked!! Do you have any idea what is the problem wiht my meshing stuff with cubit? > > Thanks, > Amirreza > > > On Thu, Aug 29, 2013 at 2:34 PM, > >> wrote: > > Before saving to the .cub file, use the Trelis (Cubit) command "compress ids all". > > - tim > > > On 08/29/2013 01:21 PM, nek5000-users at lists.mcs.anl.____gov > wrote: > > Hi All, > > I am trying to convert cubit mesh to .h5m using MOAB (mbconvert blah.cub blah.h5m), but I get this error > > Element ids are not contiguous! > Failed to load "pipe.cub". > Error code: MB_INDEX_OUT_OF_RANGE (1) > Error message: No sparse tag CATEGORY value for Vertex 1 > > I don't know what is the problem, does anybody can help in this problem. FYI, I used Trelis to make a > mesh, is there > anything wrong with my geometry or mesh? > > Thanks, > Ami > > > ___________________________________________________ > 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 > > __> > > > > > > _________________________________________________ > 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 > > > > > _______________________________________________ > 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 Thu Aug 29 16:31:24 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Aug 2013 17:31:24 -0400 Subject: [Nek5000-users] convert mesh by MOAB In-Reply-To: References: Message-ID: mbpart also is not working!! On Thu, Aug 29, 2013 at 4:41 PM, wrote: > Are you working in serial or parallel? If the latter you'll have to > partition the mesh, using moab's mbpart tool... > > - tim > > > On 08/29/2013 03:07 PM, nek5000-users at lists.mcs.anl.**govwrote: > >> Sorry, but that doesn't work too, it gives me >> Failed to load "pipe.e". >> Error code: MB_INDEX_OUT_OF_RANGE (1) >> Error message: pipe.e: Trouble reading vertices >> >> I tried every exporting format but none of them wasn't work, I just made >> a pipe with map type meshing and then I used >> ''compress ids all" then I exported it as output. everything before that >> seems good but MOAB gives me different errors!! >> >> Thanks, >> Ami >> >> >> On Thu, Aug 29, 2013 at 3:49 PM, > nek5000-users at lists.**mcs.anl.gov >> >> wrote: >> >> Try going through ExodusII (.exo or .g), that might work. Also, >> which version of cubit are you using? >> >> - tim >> >> >> On 08/29/2013 02:38 PM, nek5000-users at lists.mcs.anl.__**gov > nek5000-users at lists.**mcs.anl.gov > >> wrote: >> >> Thanks tim for your answer, >> I used that command and now I get this error. >> >> Segmentation fault (core dumped) >> >> I don't know whatis the problem with my meshing because I can >> convert from gmsh files (.msh) to .h5m but for >> cubit it >> gets stocked!! Do you have any idea what is the problem wiht my >> meshing stuff with cubit? >> >> Thanks, >> Amirreza >> >> >> On Thu, Aug 29, 2013 at 2:34 PM, > >> > >> >> > nek5000-users at lists.**mcs.anl.gov >>> >> wrote: >> >> Before saving to the .cub file, use the Trelis (Cubit) >> command "compress ids all". >> >> - tim >> >> >> On 08/29/2013 01:21 PM, nek5000-users at lists.mcs.anl.__**__gov >> >> >> >> >> wrote: >> >> Hi All, >> >> I am trying to convert cubit mesh to .h5m using MOAB >> (mbconvert blah.cub blah.h5m), but I get this error >> >> Element ids are not contiguous! >> Failed to load "pipe.cub". >> Error code: MB_INDEX_OUT_OF_RANGE (1) >> Error message: No sparse tag CATEGORY value for Vertex 1 >> >> I don't know what is the problem, does anybody can help >> in this problem. FYI, I used Trelis to make a >> mesh, is there >> anything wrong with my geometry or mesh? >> >> Thanks, >> Ami >> >> >> ______________________________**_____________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.__**__gov > Nek5000-users at lists.__**mcs.anl.gov >> >> >> >> https://lists.mcs.anl.gov/____**mailman/listinfo/nek5000-users >> >> **> >> > 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 > 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 > *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 > 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 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 Aug 29 16:57:46 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Aug 2013 16:57:46 -0500 Subject: [Nek5000-users] convert mesh by MOAB In-Reply-To: References: Message-ID: [Taking the conversation offline now, I'm guessing it's inability to read latest .cub file format.] - tim On 08/29/2013 04:31 PM, nek5000-users at lists.mcs.anl.gov wrote: > mbpart also is not working!! > > > On Thu, Aug 29, 2013 at 4:41 PM, > wrote: > > Are you working in serial or parallel? If the latter you'll have to partition the mesh, using moab's mbpart tool... > > - tim > > > On 08/29/2013 03:07 PM, nek5000-users at lists.mcs.anl.__gov wrote: > > Sorry, but that doesn't work too, it gives me > Failed to load "pipe.e". > Error code: MB_INDEX_OUT_OF_RANGE (1) > Error message: pipe.e: Trouble reading vertices > > I tried every exporting format but none of them wasn't work, I just made a pipe with map type meshing and then I > used > ''compress ids all" then I exported it as output. everything before that seems good but MOAB gives me different > errors!! > > Thanks, > Ami > > > On Thu, Aug 29, 2013 at 3:49 PM, > >> wrote: > > Try going through ExodusII (.exo or .g), that might work. Also, which version of cubit are you using? > > - tim > > > On 08/29/2013 02:38 PM, nek5000-users at lists.mcs.anl.____gov > wrote: > > Thanks tim for your answer, > I used that command and now I get this error. > > Segmentation fault (core dumped) > > I don't know whatis the problem with my meshing because I can convert from gmsh files (.msh) to .h5m > but for > cubit it > gets stocked!! Do you have any idea what is the problem wiht my meshing stuff with cubit? > > Thanks, > Amirreza > > > On Thu, Aug 29, 2013 at 2:34 PM, > > > ____mcs.anl.gov > >>> wrote: > > Before saving to the .cub file, use the Trelis (Cubit) command "compress ids all". > > - tim > > > On 08/29/2013 01:21 PM, nek5000-users at lists.mcs.anl.______gov ____mcs.anl.gov > > >> wrote: > > Hi All, > > I am trying to convert cubit mesh to .h5m using MOAB (mbconvert blah.cub blah.h5m), but I get > this error > > Element ids are not contiguous! > Failed to load "pipe.cub". > Error code: MB_INDEX_OUT_OF_RANGE (1) > Error message: No sparse tag CATEGORY value for Vertex 1 > > I don't know what is the problem, does anybody can help in this problem. FYI, I used Trelis to > make a > mesh, is there > anything wrong with my geometry or mesh? > > Thanks, > Ami > > > _____________________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.______gov ____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 ____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 > > __> > > > > > _________________________________________________ > 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 > > > > > _______________________________________________ > 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