From nek5000-users at lists.mcs.anl.gov Tue Mar 2 10:38:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 2 Mar 2010 10:38:49 -0600 Subject: [Nek5000-users] Model a Power Law Fluid? Message-ID: <803a52461003020838p5dbf4611kb5c9ddd38f7cce21@mail.gmail.com> I am interested in modeling a power law fluid. My particular case will be shear thinning. Nek5000 has been recommended to me as a package that could most likely handle this. Has anyone done this before? If not, would it be a fairly straightforward adjustment to the code? Thanks, LaCroix -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Mar 3 05:46:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 03 Mar 2010 17:16:03 +0530 Subject: [Nek5000-users] Code output Message-ID: <4B8E4BFB.5060200@iitk.ac.in> Hi, I'm trying to solve for a lid driven cavity flow (in 2D for now) using NEK5000. The viscosity has been set to one and the lid is moving with a velocity of 10000. I don't understand the meaning of the numbers given in the code output. For ex: Step 499268, t= 6.8040858E-02, DT= 1.2825985E-07, C= 0.409 5.9000E+04 9.7954E-02 Solving for fluid 499268 Hmholtz VELX: 9 2.9714E-11 1.3717E+07 3.0000E-10 499268 Hmholtz VELY: 9 1.3165E-11 1.1815E+07 3.0000E-10 499268 U-Press std. : 91 2.9185E-08 3.0000E-08 2.6864E-03 8.4799E-02 499268 DNORM, DIVEX 2.918545176353094E-008 2.918487500510926E-008 499268 6.8041E-02 9.2034E-02 Fluid done Step 499269, t= 6.8040986E-02, DT= 1.2825985E-07, C= 0.409 5.9000E+04 9.9300E-02 Solving for fluid 499269 Hmholtz VELX: 9 2.9708E-11 1.3713E+07 3.0000E-10 499269 Hmholtz VELY: 9 1.3158E-11 1.1809E+07 3.0000E-10 499269 U-Press std. : 91 2.9192E-08 3.0000E-08 2.6781E-03 8.6898E-02 499269 DNORM, DIVEX 2.919249585636570E-008 2.919235717748844E-008 499269 6.8041E-02 9.4083E-02 Fluid done Step 499270, t= 6.8041114E-02, DT= 1.2825985E-07, C= 0.409 5.9000E+04 1.0086E-01 Solving for fluid 499270 Hmholtz VELX: 9 2.9703E-11 1.3708E+07 3.0000E-10 499270 Hmholtz VELY: 9 1.3151E-11 1.1802E+07 3.0000E-10 499270 U-Press std. : 91 2.9200E-08 3.0000E-08 2.6698E-03 8.3875E-02 499270 DNORM, DIVEX 2.919940124964188E-008 2.920027044061877E-008 499270 6.8041E-02 9.1076E-02 Fluid done It would be great if someone could explain what the numbers mean. I'm worried about the numbers in the second column being of the order of 1E+07. Is that a problem? Also while specifying the boundary conditions, how can one specify user set boundary conditions for more than one boundary using userbc? Is there a parameter which one could check to see if the grid resolution if enough for the case there is being run or should we resort to checking for grid independence? The rea, map and usr files are attached. Thanking you, Mani chandra P.S I'd really like to thank the developers for releasing this software for free and for documenting it so as to spread it's usage. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lid.map URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lid.rea URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lid.usr URL: From nek5000-users at lists.mcs.anl.gov Wed Mar 3 06:02:20 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 3 Mar 2010 13:02:20 +0100 Subject: [Nek5000-users] Code output In-Reply-To: <4B8E4BFB.5060200@iitk.ac.in> References: <4B8E4BFB.5060200@iitk.ac.in> Message-ID: Helmholtz solver output (velocity solve): > 499268 Hmholtz VELX: 9 2.9714E-11 1.3717E+07 3.0000E-10 col3: number of iterations (9) col4: final residual (2.9714E-11) col5: initial residual (1.3717E+07) col6: solver tolerance (3.0000E-10) Pressure solver output: > 499268 U-Press std. : 91 2.9185E-08 3.0000E-08 2.6864E-03 8.4799E-02 col3: number of iterations (91) col4: final residual (2.9185E-08) col5: solver tolerance (3.0000E-08) col6: initial residual (2.6864E-03 ) col6: elapsed solver time hth, Stefan On Mar 3, 2010, at 12:46 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I'm trying to solve for a lid driven cavity flow (in 2D for now) using NEK5000. The viscosity has been set to one and the lid is moving with a velocity of 10000. I don't understand the meaning of the numbers given in the code output. For ex: > > Step 499268, t= 6.8040858E-02, DT= 1.2825985E-07, C= 0.409 5.9000E+04 9.7954E-02 > Solving for fluid > 499268 Hmholtz VELX: 9 2.9714E-11 1.3717E+07 3.0000E-10 > 499268 Hmholtz VELY: 9 1.3165E-11 1.1815E+07 3.0000E-10 > 499268 U-Press std. : 91 2.9185E-08 3.0000E-08 2.6864E-03 8.4799E-02 > 499268 DNORM, DIVEX 2.918545176353094E-008 2.918487500510926E-008 > 499268 6.8041E-02 9.2034E-02 Fluid done > Step 499269, t= 6.8040986E-02, DT= 1.2825985E-07, C= 0.409 5.9000E+04 9.9300E-02 > Solving for fluid > 499269 Hmholtz VELX: 9 2.9708E-11 1.3713E+07 3.0000E-10 > 499269 Hmholtz VELY: 9 1.3158E-11 1.1809E+07 3.0000E-10 > 499269 U-Press std. : 91 2.9192E-08 3.0000E-08 2.6781E-03 8.6898E-02 > 499269 DNORM, DIVEX 2.919249585636570E-008 2.919235717748844E-008 > 499269 6.8041E-02 9.4083E-02 Fluid done > Step 499270, t= 6.8041114E-02, DT= 1.2825985E-07, C= 0.409 5.9000E+04 1.0086E-01 > Solving for fluid > 499270 Hmholtz VELX: 9 2.9703E-11 1.3708E+07 3.0000E-10 > 499270 Hmholtz VELY: 9 1.3151E-11 1.1802E+07 3.0000E-10 > 499270 U-Press std. : 91 2.9200E-08 3.0000E-08 2.6698E-03 8.3875E-02 > 499270 DNORM, DIVEX 2.919940124964188E-008 2.920027044061877E-008 > 499270 6.8041E-02 9.1076E-02 Fluid done > > It would be great if someone could explain what the numbers mean. I'm worried about the numbers in the second column being of the order of 1E+07. Is that a problem? Also while specifying the boundary conditions, how can one specify user set boundary conditions for more than one boundary using userbc? Is there a parameter which one could check to see if the grid resolution if enough for the case there is being run or should we resort to checking for grid independence? > > The rea, map and usr files are attached. > > Thanking you, > Mani chandra > > P.S I'd really like to thank the developers for releasing this software for free and for documenting it so as to spread it's usage. > _______________________________________________ > 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 Mar 3 07:03:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 3 Mar 2010 07:03:34 -0600 (CST) Subject: [Nek5000-users] Code output In-Reply-To: <4B8E4BFB.5060200@iitk.ac.in> References: <4B8E4BFB.5060200@iitk.ac.in> Message-ID: Mani, final inital target residual residual residual > 499270 Hmholtz VELX: 9 2.9703E-11 1.3708E+07 3.0000E-10 which implies that you are driving the residual in the viscous substep down by 1.e18 in the iterative solver. Normally, I would control Reynolds number by reducing viscosity and keeping the velocity to be 1.0 --- In that way, your time scale is ~1.0 (assuming the domain size to also be roughly unit size). In Nek5k, we support this by allowing the use to specify Reynolds number directly by setting param2 in the .rea file to be a negative number. For example, assume your box size is one and your lid speed is one and you would like Re=60,000. You would set param 2 to be -60000. The result is that nek5000 immediately sets param 2 to 1./60000 when it reads the value. Same goes for conductivity (param 8). However, if you prefer to work in other unit systems (e.g., by changing the velocity), that is also fine. You might in that case find it useful to set params 21 (DIVERGENCE) and 22 (HELMHOLTZ) to 0. Then set TOLREL (param 24) to, say, .01 or .001. Zeroing p21 and p21 turns off the absolute tolerances, and lets Nek5000 compute the proper tolerances through tolrel (p24). In principle, the values of tolrel I specify above shoud be plenty adequate -- nek5000 generates its own tolerances inside for each solver according to problem specifications and eigenvalue estimates. I find it tends to be a bit too convservative, resulting in tighter tolerances than necessary (but not 1.e-18), so generally favor the approach above based on convective time scales. Hope this helps. Paul On Wed, 3 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I'm trying to solve for a lid driven cavity flow (in 2D for now) using > NEK5000. The viscosity has been set to one and the lid is moving with a > velocity of 10000. I don't understand the meaning of the numbers given in the > code output. For ex: > > Step 499268, t= 6.8040858E-02, DT= 1.2825985E-07, C= 0.409 5.9000E+04 > 9.7954E-02 > Solving for fluid > 499268 Hmholtz VELX: 9 2.9714E-11 1.3717E+07 3.0000E-10 > 499268 Hmholtz VELY: 9 1.3165E-11 1.1815E+07 3.0000E-10 > 499268 U-Press std. : 91 2.9185E-08 3.0000E-08 2.6864E-03 > 8.4799E-02 > 499268 DNORM, DIVEX 2.918545176353094E-008 2.918487500510926E-008 > 499268 6.8041E-02 9.2034E-02 Fluid done > Step 499269, t= 6.8040986E-02, DT= 1.2825985E-07, C= 0.409 5.9000E+04 > 9.9300E-02 > Solving for fluid > 499269 Hmholtz VELX: 9 2.9708E-11 1.3713E+07 3.0000E-10 > 499269 Hmholtz VELY: 9 1.3158E-11 1.1809E+07 3.0000E-10 > 499269 U-Press std. : 91 2.9192E-08 3.0000E-08 2.6781E-03 > 8.6898E-02 > 499269 DNORM, DIVEX 2.919249585636570E-008 2.919235717748844E-008 > 499269 6.8041E-02 9.4083E-02 Fluid done > Step 499270, t= 6.8041114E-02, DT= 1.2825985E-07, C= 0.409 5.9000E+04 > 1.0086E-01 > Solving for fluid > 499270 Hmholtz VELX: 9 2.9703E-11 1.3708E+07 3.0000E-10 > 499270 Hmholtz VELY: 9 1.3151E-11 1.1802E+07 3.0000E-10 > 499270 U-Press std. : 91 2.9200E-08 3.0000E-08 2.6698E-03 > 8.3875E-02 > 499270 DNORM, DIVEX 2.919940124964188E-008 2.920027044061877E-008 > 499270 6.8041E-02 9.1076E-02 Fluid done > > It would be great if someone could explain what the numbers mean. I'm worried > about the numbers in the second column being of the order of 1E+07. Is that a > problem? Also while specifying the boundary conditions, how can one specify > user set boundary conditions for more than one boundary using userbc? Is > there a parameter which one could check to see if the grid resolution if > enough for the case there is being run or should we resort to checking for > grid independence? > > The rea, map and usr files are attached. > > Thanking you, > Mani chandra > > P.S I'd really like to thank the developers for releasing this software for > free and for documenting it so as to spread it's usage. > From nek5000-users at lists.mcs.anl.gov Thu Mar 4 10:26:18 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 04 Mar 2010 21:56:18 +0530 Subject: [Nek5000-users] [*] Re: Code output In-Reply-To: References: <4B8E4BFB.5060200@iitk.ac.in> Message-ID: <4B8FDF2A.1090206@iitk.ac.in> Thanks for that info! --Mani chandra From nek5000-users at lists.mcs.anl.gov Thu Mar 4 11:28:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 04 Mar 2010 22:58:11 +0530 Subject: [Nek5000-users] Something wrong when visualizing fld files with Visit... Message-ID: <4B8FEDAB.2040905@iitk.ac.in> Hi, When I try to visualize the fld files using Visit, it runs fine for some time and then suddenly the subsequent images become all gibberish. When I modify the metadata file to start with the fld file which looks corrupted, it's image looks fine in Visit (although the time data is missing..) and all the following images look corrupted. What could be the problem? I'm attaching a few fld files and their images along with the metadata file. Thanking you, Mani chandra -------------- next part -------------- A non-text attachment was scrubbed... Name: lid.fld99 Type: application/octet-stream Size: 512084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lid.fld100 Type: application/octet-stream Size: 512084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lid.fld101 Type: application/octet-stream Size: 512084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fld99.tif Type: image/tiff Size: 1845100 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fld100.tif Type: image/tiff Size: 1844998 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vis.nek2d URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SIZEu URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lid.map URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lid.rea URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lid.usr URL: From nek5000-users at lists.mcs.anl.gov Thu Mar 4 12:07:02 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 4 Mar 2010 12:07:02 -0600 (CST) Subject: [Nek5000-users] Something wrong when visualizing fld files with Visit... In-Reply-To: <4B8FEDAB.2040905@iitk.ac.in> References: <4B8FEDAB.2040905@iitk.ac.in> Message-ID: Mani, I've seen this behavior in the past as well --- it is a VisIt issue but I don't know the full story. I'll try to check into it. Paul On Thu, 4 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > When I try to visualize the fld files using Visit, it runs fine for some > time and then suddenly the subsequent images become all gibberish. When I > modify the metadata file to start with the fld file which looks corrupted, > it's image looks fine in Visit (although the time data is missing..) and all > the following images look corrupted. What could be the problem? > > I'm attaching a few fld files and their images along with the metadata > file. > > Thanking you, > Mani chandra > From nek5000-users at lists.mcs.anl.gov Thu Mar 4 12:20:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 4 Mar 2010 19:20:49 +0100 Subject: [Nek5000-users] Something wrong when visualizing fld files with Visit... In-Reply-To: <4B8FEDAB.2040905@iitk.ac.in> References: <4B8FEDAB.2040905@iitk.ac.in> Message-ID: <3FCFCD52-5549-4BBB-BD99-52BACC5D1F53@lav.mavt.ethz.ch> Is there a specific reason to dump your data in ASCII? It is highly recommend to use the BINARY format! Check param(66) and param(67) in your .rea file. ASCII: values < 0 e.g param(66) = -1 BINARY: values >0 e.g. param(66) = 1 Also make sure the your .usr does not overwrite this setting. Hth, Stefan On Mar 4, 2010, at 6:28 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > When I try to visualize the fld files using Visit, it runs fine for some time and then suddenly the subsequent images become all gibberish. When I modify the metadata file to start with the fld file which looks corrupted, it's image looks fine in Visit (although the time data is missing..) and all the following images look corrupted. What could be the problem? > > I'm attaching a few fld files and their images along with the metadata file. > > Thanking you, > Mani chandra > From nek5000-users at lists.mcs.anl.gov Thu Mar 4 12:25:56 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 4 Mar 2010 19:25:56 +0100 Subject: [Nek5000-users] Something wrong when visualizing fld files with Visit... In-Reply-To: References: <4B8FEDAB.2040905@iitk.ac.in> Message-ID: Yes, there are several unresolved issues with the ASCII format in our VisIt reader. One of the headers cannot be parsed correctly because of a missing whitespace. The BINARY format (.f???? files) should work well. Stefan On Mar 4, 2010, at 7:07 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Mani, > > I've seen this behavior in the past as well --- it is a VisIt > issue but I don't know the full story. I'll try to check into > it. > > Paul > > > On Thu, 4 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> When I try to visualize the fld files using Visit, it runs fine for some time and then suddenly the subsequent images become all gibberish. When I modify the metadata file to start with the fld file which looks corrupted, it's image looks fine in Visit (although the time data is missing..) and all the following images look corrupted. What could be the problem? >> >> I'm attaching a few fld files and their images along with the metadata file. >> >> Thanking you, >> Mani chandra >> > _______________________________________________ > 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 Mar 4 21:52:05 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 04 Mar 2010 22:52:05 -0500 Subject: [Nek5000-users] map file for conjugate heat In-Reply-To: References: <4B8E4BFB.5060200@iitk.ac.in> Message-ID: <4B907FE5.9010501@vt.edu> Dear Developers, with the conjugate heat transfer cases, I am running into issues which seem unresolvable. I would thus appreciate your help. Attached is a case with conjugate heat transfer around a circle in 2D (conj.rea). After the map has been generated with genmap (conj.map), running the case results in the messages posted in output. The mesh runs just fine when all elements are defined as fluids (nel=nelv and adding the right boundary conditions in the fluids section), so I don't think it has to do with poor mesh quality. It would be great if you could look into this and see what is wrong and how to fix it. Thanks, Markus -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: conj.map URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: conj.rea URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: conj.usr URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: output URL: From nek5000-users at lists.mcs.anl.gov Fri Mar 5 03:06:56 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 5 Mar 2010 03:06:56 -0600 (CST) Subject: [Nek5000-users] map file for conjugate heat In-Reply-To: <4B907FE5.9010501@vt.edu> References: <4B8E4BFB.5060200@iitk.ac.in> <4B907FE5.9010501@vt.edu> Message-ID: Hi Markus, there clearly seems to be a problem with genmap... I'm looking into it. Paul On Thu, 4 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear Developers, > > with the conjugate heat transfer cases, I am running into issues which seem > unresolvable. I would thus appreciate your help. > > Attached is a case with conjugate heat transfer around a circle in 2D > (conj.rea). After the map has been generated with genmap (conj.map), running > the case results in the messages posted in output. The mesh runs just fine > when all elements are defined as fluids (nel=nelv and adding the right > boundary conditions in the fluids section), so I don't think it has to do > with poor mesh quality. > > It would be great if you could look into this and see what is wrong and how > to fix it. > > Thanks, > Markus > From nek5000-users at lists.mcs.anl.gov Fri Mar 5 03:39:46 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 5 Mar 2010 03:39:46 -0600 (CST) Subject: [Nek5000-users] map file for conjugate heat In-Reply-To: <4B907FE5.9010501@vt.edu> References: <4B8E4BFB.5060200@iitk.ac.in> <4B907FE5.9010501@vt.edu> Message-ID: Dear Markus, I think if you check out the new version of genmap.f and rebuild it that it will give a workable .map file for your conjugate heat transfer problem. Paul On Thu, 4 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear Developers, > > with the conjugate heat transfer cases, I am running into issues which seem > unresolvable. I would thus appreciate your help. > > Attached is a case with conjugate heat transfer around a circle in 2D > (conj.rea). After the map has been generated with genmap (conj.map), running > the case results in the messages posted in output. The mesh runs just fine > when all elements are defined as fluids (nel=nelv and adding the right > boundary conditions in the fluids section), so I don't think it has to do > with poor mesh quality. > > It would be great if you could look into this and see what is wrong and how > to fix it. > > Thanks, > Markus > From nek5000-users at lists.mcs.anl.gov Fri Mar 5 09:29:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 5 Mar 2010 09:29:06 -0600 (CST) Subject: [Nek5000-users] map file for conjugate heat In-Reply-To: References: <4B8E4BFB.5060200@iitk.ac.in> <4B907FE5.9010501@vt.edu> Message-ID: Hi Markus, I'm still checking into your case --- it doesn't appear to be working for me (yet)... any luck on your end? Paul On Fri, 5 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > > Dear Markus, > > I think if you check out the new version of genmap.f and rebuild > it that it will give a workable .map file for your conjugate heat > transfer problem. > > Paul > > > On Thu, 4 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Developers, >> >> with the conjugate heat transfer cases, I am running into issues which seem >> unresolvable. I would thus appreciate your help. >> >> Attached is a case with conjugate heat transfer around a circle in 2D >> (conj.rea). After the map has been generated with genmap (conj.map), >> running the case results in the messages posted in output. The mesh runs >> just fine when all elements are defined as fluids (nel=nelv and adding the >> right boundary conditions in the fluids section), so I don't think it has >> to do with poor mesh quality. >> >> It would be great if you could look into this and see what is wrong and how >> to fix it. >> >> Thanks, >> Markus >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Mar 5 12:57:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 5 Mar 2010 13:57:12 -0500 Subject: [Nek5000-users] map file for conjugate heat In-Reply-To: References: <4B8E4BFB.5060200@iitk.ac.in> <4B907FE5.9010501@vt.edu> Message-ID: <1267815432.4b91540850e5e@webmail.vt.edu> Hi, I tried it on 1 and 2, 8 processors, using the newest genmap, and it works! We'll test a 3D case next and post results. Thank you very much, Markus Quoting nek5000-users at lists.mcs.anl.gov: > > Hi Markus, > > I'm still checking into your case --- it doesn't appear to be working > for me (yet)... any luck on your end? > > Paul > > > On Fri, 5 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Dear Markus, > > > > I think if you check out the new version of genmap.f and rebuild > > it that it will give a workable .map file for your conjugate heat > > transfer problem. > > > > Paul > > > > > > On Thu, 4 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Dear Developers, > >> > >> with the conjugate heat transfer cases, I am running into issues which > seem > >> unresolvable. I would thus appreciate your help. > >> > >> Attached is a case with conjugate heat transfer around a circle in 2D > >> (conj.rea). After the map has been generated with genmap (conj.map), > >> running the case results in the messages posted in output. The mesh runs > >> just fine when all elements are defined as fluids (nel=nelv and adding the > >> right boundary conditions in the fluids section), so I don't think it has > >> to do with poor mesh quality. > >> > >> It would be great if you could look into this and see what is wrong and > how > >> to fix it. > >> > >> Thanks, > >> Markus > >> > > _______________________________________________ > > 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 Thu Mar 11 03:44:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 11 Mar 2010 10:44:27 +0100 Subject: [Nek5000-users] Define objects in prenek Message-ID: <4B98BB7B.6080305@kit.edu> Hello, I have a question to "prenek". I'm trying to define a grid of a rigid sphere in a channel (similar to the configuration in the paper of Zeng, Balachandar, Fischer (2005) "Wall-induced forces on a rigid sphere at finite Reynoldsnumber"). To my knowledge I have to generate the sphere grid with CURVE SIDES > SPHERICAL MESH ("sphere.rea") and then the channel grid ("channel.rea"). Finally I have to insert the sphere grid as an object into the channel grid. But I don't know how to do this. Hope you can help me. Thanks a lot. Best regards, Fred From nek5000-users at lists.mcs.anl.gov Thu Mar 11 03:54:31 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 11 Mar 2010 03:54:31 -0600 (CST) Subject: [Nek5000-users] Define objects in prenek In-Reply-To: <4B98BB7B.6080305@kit.edu> References: <4B98BB7B.6080305@kit.edu> Message-ID: Fred, If your tensor-product-based channel mesh has grid lines that coincide with the outer layer of your spherical mesh, then it is very easy. Start prenek with a mesh called channel (say), then, IMPORT MESH import your sphere mesh and answer "y" (yes) to the question about whether you wish to displace elements in the existing mesh. What this does is to delete any element that is inside the bounding box that contains all elements from the imported spherical mesh. Note that this assumes that at least the last layer of your spherical mesh is a cartesian face. Have you ever used the text-based version of prenek? (I think it gets compiled automatically when prex is compiled, and is called pretex.) I can set up a couple of scripts as examples and will do so in a few hours --- Paul On Thu, 11 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I have a question to "prenek". I'm trying to define a grid of a rigid sphere > in a channel (similar to the configuration in the paper of Zeng, Balachandar, > Fischer (2005) "Wall-induced forces on a rigid sphere at finite > Reynoldsnumber"). To my knowledge I have to generate the sphere grid with > CURVE SIDES > SPHERICAL MESH ("sphere.rea") and then the channel grid > ("channel.rea"). Finally I have to insert the sphere grid as an object into > the channel grid. But I don't know how to do this. > > Hope you can help me. Thanks a lot. > > Best regards, > Fred > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Mar 12 02:11:02 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 12 Mar 2010 09:11:02 +0100 Subject: [Nek5000-users] Define objects in prenek Message-ID: <4B99F716.10404@kit.edu> Hi Paul, that's what I'm doing, at least I'm thinking to do this. But when I generate the grid of the sphere, I don't know which b.c. I should define on the grid boundaries. And when I import this mesh into the channel-file the information of the surface objects (which I defined in the sphere-file) are lost and prenek is again asking me for the b.c. of the imported mesh, even the cartesian box of the sphere is matching exactly into the channel-mesh (and I type "y" for displacing the existing elements). So I don't know exactly where my failure is... Best, Fred From nek5000-users at lists.mcs.anl.gov Fri Mar 12 04:24:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 12 Mar 2010 04:24:12 -0600 (CST) Subject: [Nek5000-users] Define objects in prenek In-Reply-To: <4B99F716.10404@kit.edu> References: <4B99F716.10404@kit.edu> Message-ID: Hi Fred, If the files are not too large, is it possible to send me a gzippd tarfile ? Paul On Fri, 12 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > that's what I'm doing, at least I'm thinking to do this. But when I generate > the grid of the sphere, I don't know which b.c. I should define on the grid > boundaries. And when I import this mesh into the channel-file the information > of the surface objects (which I defined in the sphere-file) are lost and > prenek is again asking me for the b.c. of the imported mesh, even the > cartesian box of the sphere is matching exactly into the channel-mesh (and I > type "y" for displacing the existing elements). So I don't know exactly where > my failure is... > > Best, Fred > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Mar 12 12:41:14 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 12 Mar 2010 12:41:14 -0600 Subject: [Nek5000-users] "genmap" trouble with periodic boundary conditions Message-ID: <4b299bf14607c99d6ff83d83396c52c3.squirrel@webmail.uic.edu> Hello, I am trying to run a backward facing step geometry simulation. Making the mesh with "genbox" works fine but "genmap" gives the following error. It seems there is some problem with the periodic boundary conditions. ------------------------------------------------------------------------- Input (.rea) file name: Input mesh tolerance (default 0.2): NOTE: smaller is better, but generous is more forgiving for bad meshes. reading .rea file data ... start locglob_lexico: 8 5184 41472 0.1000000 locglob: 1 1 41472 locglob: 2 41 41472 locglob: 3 485 41472 locglob: 1 6305 41472 locglob: 2 6305 41472 locglob: 3 6305 41472 locglob: 1 6305 41472 locglob: 2 6305 41472 locglob: 3 6305 41472 done locglob_lexico: 6305 6305 41472 8 start periodic vtx: 5184 6305 abort: PERIODIC MISMATCH 2: 1 5 P ie 0 4 je 0.000000 0.000000 bc 8 quit --------------------------------------------------------------------------- Here is my bfs.box file. --------------------------------------------------------------------------- bfs1.rea -3 spatial dimension (if negative dump .re2 file) 1 number of fields # #======================================================================= # box_1 -32 -3 -12 nelx,nely,nelz (negative --> auto spacing) 0.0 17.92 1.03 x_0 x_1 ratio -1.0 -0.5 1.25 0.0 6.0 1 W ,O ,W , ,P ,P bc's ! west,east,south,north,bottom,top box_2 -32 -3 -12 nelx,nely,nelz (negative --> auto spacing) 0.0 17.92 1.03 x_0 x_1 ratio -0.5 0.0 0.8 0.0 6.0 1 W ,O , , ,P ,P bc's ! west,east,south,north,bottom,top box_3 -32 -6 -12 nelx,nely,nelz (negative --> auto spacing) 0.0 17.92 1.03 x_0 x_1 ratio 0.0 10.76 2.25 0.0 6.0 1 ,O , , ,P ,P bc's ! west,east,south,north,bottom,top box_4 -8 -6 -12 nelx,nely,nelz (negative --> auto spacing) -5.0 0.0 0.85 x_0 x_1 ratio 0.0 10.76 2.25 0.0 6.0 1 v , ,W , ,P ,P bc's ! west,east,south,north,bottom,top --------------------------------------------------------------------------- I cannot figure out what this error means. If I change the periodic boundary condition to any other b.c., it works. This error started occurring after I did a "svn update tools" this morning. Now "genmap" does not even run on an old .rea file. Can anybody suggest me solutions for this. Thanks a lot, Harish Kanchi. From nek5000-users at lists.mcs.anl.gov Mon Mar 15 12:36:39 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 15 Mar 2010 18:36:39 +0100 Subject: [Nek5000-users] what parameters for a moving wall induced velocity problem? Message-ID: <5313C3E0D03CB044A289CAC54D804C12015167276967@BVMBX1.univ-lyon1.fr> Dear Nek5000 users, I'm looking forward to enforce a moving wall boundary condition. My question is mainly focused on the logical switches I should turn on and off. Until now, I managed to get the mesh moving by enforcing xm1 and ym1 in a function that is called by nekadvance() before the fluid solver. Since I know my time dependant mesh moving function, I also compute wx and wy. A recomputation of all Jacobians,etc... is then done and is followed by a topology test. All the following logical flags (IFMVBD, IFMGRID, IFUSRMV) are turned off and switching them on doesn't seem to change anything in the further described problem. This method seems to work as long as I specify an initial velocity but it fails when I want to simulate the fluid flow induced by the wall movement itself ( therefore when I don't specify the initial velocity). I only get some random velocities values around 1e-20 despite the outer walls are moving significantly, and this regardless to the viscosity, density, or wall movement velocity. Is this phenomenon intrinsic to the code formulation and do I need to specify an initial value different from zero? What appropriate configuration of the .rea file would you recommend to get a wall-induced fluid motion? Has anybody already succeded in doing such a thing ? Thank you in advance for any help you could provide Best regards, Michael Bruckner From nek5000-users at lists.mcs.anl.gov Mon Mar 22 07:53:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 22 Mar 2010 07:53:25 -0500 (CDT) Subject: [Nek5000-users] makenek problem (fwd) Message-ID: David, We've been having some makenek issues of late. I'm forwarding to the users list so that it comes to the attention of all the developers. Hopefully we'll get it straightened out for you in the next 48 hours, though Stefan and I are both on travel. Best regards, Paul ---------- Forwarded message ---------- Date: Mon, 22 Mar 2010 02:15:50 -0400 From: David Goluskin To: Aleksandr Obabko , Paul Fischer Subject: makenek problem Hi Aleks, I'm suddenly having problems running makenek to compile nek5000. I have checked out the latest version, 444. I'm trying to run the (unmodified) makenek script on the ray0.usr file, and I get some errors. The same thing happens when I try the usr file from a different example. I'm not sure if I had to customize makenek previously, but I don't remember doing so. A lot of makenek runs with no problems, but 6 errors come up at one point. The errors are: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ mpif77 -c -O2 -r8 -cpp -fno-second-underscore -DMPI -DLONGINT8 -I/home/goluskin/nek5_svn/trunk/nek /home/goluskin/nek5_svn/trunk/nek/comm_mpi.f <<<<<<< .mine ^ pathf95-400 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 13, Column = 1 The characters found in the label field are not valid. ^ pathf95-95 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 13, Column = 9 The real constant must contain digits in the whole and/or the fractional part of the constant. &,'| Version: 1.0rc1 / SVN r444M |' ^ pathf95-66 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 14, Column = 7 A defined operator is missing the "." delimiter. ======= ^ pathf95-400 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 15, Column = 1 The characters found in the label field are not valid. ^ pathf95-197 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 15, Column = 7 Unexpected syntax: "EOS" was expected but found "=". >>>>>>> .r428 ^ pathf95-400 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 17, Column = 1 The characters found in the label field are not valid. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Do you have any idea what's wrong here? If it's easier for you to address this issue by phone, I am free 4-5 PM EST tomorrow, and I can call you then. Thanks very much, David From nek5000-users at lists.mcs.anl.gov Mon Mar 22 08:01:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 22 Mar 2010 14:01:55 +0100 Subject: [Nek5000-users] makenek problem (fwd) In-Reply-To: References: Message-ID: <471AFD05-1C78-4800-AEE7-2D75C205ACC0@lav.mavt.ethz.ch> David, it seems like you did an 'svn update' and you ended up with unresolved conflicts. Just delete the nek directory in the trunk and run svn update nek Also, please make sure to use an up-to-date makenek which we provide together with the source. #Stefan On Mar 22, 2010, at 1:53 PM, nek5000-users at lists.mcs.anl.gov wrote: > > David, > > We've been having some makenek issues of late. > I'm forwarding to the users list so that it comes > to the attention of all the developers. > > Hopefully we'll get it straightened out for you in the > next 48 hours, though Stefan and I are both on travel. > > Best regards, > > Paul > > > ---------- Forwarded message ---------- > Date: Mon, 22 Mar 2010 02:15:50 -0400 > From: David Goluskin > To: Aleksandr Obabko , Paul Fischer > Subject: makenek problem > > Hi Aleks, > > I'm suddenly having problems running makenek to compile nek5000. I have > checked out the latest version, 444. I'm trying to run the (unmodified) > makenek script on the ray0.usr file, and I get some errors. The same thing > happens when I try the usr file from a different example. I'm not sure if I > had to customize makenek previously, but I don't remember doing so. A lot > of makenek runs with no problems, but 6 errors come up at one point. The > errors are: > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > mpif77 -c -O2 -r8 -cpp -fno-second-underscore -DMPI -DLONGINT8 > -I/home/goluskin/nek5_svn/trunk/nek > /home/goluskin/nek5_svn/trunk/nek/comm_mpi.f > > <<<<<<< .mine > ^ > pathf95-400 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 13, Column = 1 > > The characters found in the label field are not valid. > ^ > pathf95-95 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 13, Column = 9 > The real constant must contain digits in the whole and/or the fractional > part of the constant. > > &,'| Version: 1.0rc1 / SVN r444M |' > ^ > pathf95-66 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 14, Column = 7 > A defined operator is missing the "." delimiter. > > ======= > ^ > pathf95-400 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 15, Column = 1 > > The characters found in the label field are not valid. > ^ > pathf95-197 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 15, Column = 7 > > Unexpected syntax: "EOS" was expected but found "=". > >>>>>>>> .r428 > ^ > pathf95-400 pathf95: ERROR PRINTHEADER, File = HEADER, Line = 17, Column = 1 > > The characters found in the label field are not valid. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Do you have any idea what's wrong here? If it's easier for you to address > this issue by phone, I am free 4-5 PM EST tomorrow, and I can call you then. > > Thanks very much, > > David > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Mar 22 11:34:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 22 Mar 2010 12:34:04 -0400 Subject: [Nek5000-users] makenek problem (fwd) In-Reply-To: <471AFD05-1C78-4800-AEE7-2D75C205ACC0@lav.mavt.ethz.ch> References: <471AFD05-1C78-4800-AEE7-2D75C205ACC0@lav.mavt.ethz.ch> Message-ID: <4de801df1003220934h49f24cc8h19915f4f10df4dc7@mail.gmail.com> Stefan, Thank you, it appears that was indeed the problem. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Mar 23 22:12:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 23 Mar 2010 22:12:29 -0500 (CDT) Subject: [Nek5000-users] seg fault In-Reply-To: <4de801df1003231255y489d9956r1d394028422d1f37@mail.gmail.com> References: <4de801df1003221440l5dc5a92arad13d4a32a42d385@mail.gmail.com> <4de801df1003221720sa00d354j8c20640d19701a09@mail.gmail.com> <4de801df1003231255y489d9956r1d394028422d1f37@mail.gmail.com> Message-ID: Hi David, Can you send me the full logfile for the single processor case? If you're getting to the point where a field file is being generated then the issue is not where I suspected it was. Of course, if the logfile is buffered we're likely stuck unless you can run it interactively ? Thanks, Paul On Tue, 23 Mar 2010, David Goluskin wrote: > Hey Aleks > > I don't know how to see what timestep I failed on, but one fld file is > output successfully (the initial condition, I guess). Do you have any idea > what the newest version of nek is that might work? If not, I can figure > that out. Perhaps it would be helpful to you if I figured that out? > > Best, > > David > > On Tue, Mar 23, 2010 at 1:30 PM, Aleksandr Obabko wrote: > >> Hi David, >> >> Does you case crashes on the second timestep? Mine does on our local >> sicortex with new version of the code. Could you run with old version of >> the code for now? >> >> Thanks, >> Aleks >> >> >> > From nek5000-users at lists.mcs.anl.gov Wed Mar 24 11:00:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 24 Mar 2010 21:30:16 +0530 Subject: [Nek5000-users] Postprocessing Message-ID: <4BAA3710.1050803@iitk.ac.in> Dear Nek devs, I'm a bit confused regarding postprocessing. Is one supposed to run a simulation and then run nek5k again to load the fld files using load_fld() for postprocessing? Or can one compute the desired quantities after every time step using userchk() and then output them in a file? For example, how can I compute the vorticity using the differential operators defined in the code? After computing the vorticity, can it be outputted using the same fld files? Regards, Mani chandra From nek5000-users at lists.mcs.anl.gov Wed Mar 24 11:28:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 24 Mar 2010 11:28:41 -0500 (CDT) Subject: [Nek5000-users] Postprocessing In-Reply-To: <4BAA3710.1050803@iitk.ac.in> References: <4BAA3710.1050803@iitk.ac.in> Message-ID: Mani, It somewhat depends on what you're after. You can use postx and compute the vorticity there --- it is only 32 bit but it does allow you to compute the vorticity for any existing velocity data in the (older) .fld file output format. Alternatively, if you're using VisIt or some other analysis tool, or doing run-time analysis, you can compute the vorticity at runtime. If you wish to output the vorticity field, you can do so, e.g., as follows: c----------------------------------------------------------------------- subroutine userchk include 'SIZE' include 'TOTAL' parameter(lt=lx1*ly1*lz1*lelv) common /scrns/ vort(lt,3),w1(lt),w2(lt) if (mod(istep,iostep).eq.0) then call comp_vort3(vort,w1,w2,vx,vy,vz) call outpost(vort(1,1),vort(1,2),vort(1,3),pr,t,'vrt') endif return end c----------------------------------------------------------------------- This would generate an output "vrtmy_case..." if your .rea file is my_case.rea Any of the post-processing tools could then read the vrt.... files and treat the vorticity as the velocity vector field. As I say, not exactly sure what you have in mind, but this is one possible approach. Paul On Wed, 24 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nek devs, > > I'm a bit confused regarding postprocessing. Is one supposed to run a > simulation and then run nek5k again to load the fld files using load_fld() > for postprocessing? Or can one compute the desired quantities after every > time step using userchk() and then output them in a file? For example, how > can I compute the vorticity using the differential operators defined in the > code? After computing the vorticity, can it be outputted using the same fld > files? > > Regards, > Mani chandra > _______________________________________________ > 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 Mar 25 07:07:13 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 25 Mar 2010 13:07:13 +0100 Subject: [Nek5000-users] GNU compiler problems Message-ID: <43DE7BB6-024B-40D1-849F-D9BA5C9EEEDC@lav.mavt.ethz.ch> Dear NEK Users, unfortunately a change introduced in r429 is causing some weird problems if you compile NEK with gfortran/gcc. We're currently working on a fix. Sorry for the inconvenience -Stefan From nek5000-users at lists.mcs.anl.gov Thu Mar 25 12:03:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 25 Mar 2010 12:03:11 -0500 Subject: [Nek5000-users] GNU compiler problems Message-ID: <899deb480d6feaf310f93f9ccc03efcc.squirrel@webmail.uic.edu> Hi Stefan, Thanks for letting us know about the problem. I have been facing some compiling errors for the past 10 days. Is this the problem that you are also noticing. ==================== /home/harish/nek5_svn/trunk/nek/navier8.f: In function ???setvert3d???: /home/harish/nek5_svn/trunk/nek/navier8.f:2369: internal compiler error: in expand_expr_real_1, at expr.c:6839 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [navier8.o] Error 1 make: *** Waiting for unfinished jobs.... ==================== I still think its a problem with my cluster that is giving this error. I am in touch with system support on this error. But they also have not been able to figure out what is wrong. I have tried compiling with MPICH1 compiler and OpenMPI compiler, both giving the same compiling error. Attached is my compiler.out for you reference. I am compiling the example case "fs_2" using OpenMPI compiler. Thanks, Harish Kanchi -------------- next part -------------- A non-text attachment was scrubbed... Name: compiler.out Type: application/octet-stream Size: 26990 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Thu Mar 25 12:38:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 25 Mar 2010 18:38:50 +0100 Subject: [Nek5000-users] GNU compiler problems Message-ID: <015c01cacc42$0dd8ef9b$0d24a8c0@d.ethz.ch> There is a bug in the gfortran compiler. Please update your gfortran compiler. This will fix your compilation problems but not the weird behavior I was talking about. Stefan --- original message --- From: "nek5000-users at lists.mcs.anl.gov" Subject: Re: [Nek5000-users] GNU compiler problems Date: 25th March 2010 Time: 6:03:18 pm Hi Stefan, Thanks for letting us know about the problem. I have been facing some compiling errors for the past 10 days. Is this the problem that you are also noticing. ==================== /home/harish/nek5_svn/trunk/nek/navier8.f: In function ???setvert3d???: /home/harish/nek5_svn/trunk/nek/navier8.f:2369: internal compiler error: in expand_expr_real_1, at expr.c:6839 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [navier8.o] Error 1 make: *** Waiting for unfinished jobs.... ==================== I still think its a problem with my cluster that is giving this error. I am in touch with system support on this error. But they also have not been able to figure out what is wrong. I have tried compiling with MPICH1 compiler and OpenMPI compiler, both giving the same compiling error. Attached is my compiler.out for you reference. I am compiling the example case "fs_2" using OpenMPI compiler. Thanks, Harish Kanchi From nek5000-users at lists.mcs.anl.gov Thu Mar 25 17:29:35 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 25 Mar 2010 17:29:35 -0500 (CDT) Subject: [Nek5000-users] seg fault In-Reply-To: <4de801df1003241407sc8f2ad7t1683e4ad85ad1654@mail.gmail.com> References: <4de801df1003221440l5dc5a92arad13d4a32a42d385@mail.gmail.com> <4de801df1003221720sa00d354j8c20640d19701a09@mail.gmail.com> <4de801df1003231255y489d9956r1d394028422d1f37@mail.gmail.com> <4de801df1003232154g1c24df3aj298292f99689128f@mail.gmail.com> <4de801df1003240544u6f840054x818220a1f4460d02@mail.gmail.com> <4de801df1003241407sc8f2ad7t1683e4ad85ad1654@mail.gmail.com> Message-ID: Hi David, We're looking into this... Paul On Wed, 24 Mar 2010, David Goluskin wrote: > Hi Paul and Aleks, > > After running "makenek clean" before building, the new version of nek still > seg fault. I'll use version 417 of nek for now. > > David > > On Wed, Mar 24, 2010 at 9:31 AM, Paul Fischer wrote: > >> >> >> Thanks David -- sorry to run you through the debug process remotely, >> but just trying to isolate the variables and don't have access at the >> moment to a similar platform (Aleks does and he's also on top of this). >> >> The nice thing is is that we having a rapidly growing user group ( > 60 >> at the moment) so that bug identification happens rapidly. >> >> It's important to rebuild with the current makenek after each svn >> update, e.g., makenek clean; makenek my_case >> >> The reason is that the .o files may have different memory layouts from >> one version to the next and there are then memory issues when the >> different versions get linked together. Not certain that's the case >> here, but a seg-fault is often indicative of such. >> >> Hope this fixes it! >> >> >> Paul >> >> > From nek5000-users at lists.mcs.anl.gov Sat Mar 27 06:06:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 27 Mar 2010 16:36:00 +0530 Subject: [Nek5000-users] [*] Re: Postprocessing In-Reply-To: References: <4BAA3710.1050803@iitk.ac.in> Message-ID: <4BADE698.8070504@iitk.ac.in> On 03/24/2010 09:58 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Mani, > > It somewhat depends on what you're after. > > You can use postx and compute the vorticity there --- it is > only 32 bit but it does allow you to compute the vorticity > for any existing velocity data in the (older) .fld file > output format. > > Alternatively, if you're using VisIt or some other analysis > tool, or doing run-time analysis, you can compute the vorticity > at runtime. If you wish to output the vorticity field, you can > do so, e.g., as follows: > > c----------------------------------------------------------------------- > subroutine userchk > include 'SIZE' > include 'TOTAL' > > parameter(lt=lx1*ly1*lz1*lelv) > common /scrns/ vort(lt,3),w1(lt),w2(lt) > > if (mod(istep,iostep).eq.0) then > call comp_vort3(vort,w1,w2,vx,vy,vz) > call outpost(vort(1,1),vort(1,2),vort(1,3),pr,t,'vrt') > endif > > return > end > c----------------------------------------------------------------------- > > > This would generate an output "vrtmy_case..." if your .rea file is > my_case.rea > > Any of the post-processing tools could then read the vrt.... files > and treat the vorticity as the velocity vector field. > > As I say, not exactly sure what you have in mind, but this is one > possible approach. > > Paul > > > > > > On Wed, 24 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Nek devs, >> >> I'm a bit confused regarding postprocessing. Is one supposed to >> run a simulation and then run nek5k again to load the fld files using >> load_fld() for postprocessing? Or can one compute the desired >> quantities after every time step using userchk() and then output them >> in a file? For example, how can I compute the vorticity using the >> differential operators defined in the code? After computing the >> vorticity, can it be outputted using the same fld files? >> >> Regards, >> Mani chandra >> _______________________________________________ >> 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 > Dear Paul, The files generated by the code in usr_chk(), vrtmy_case0.f* do not seem to have vorticity in them when I view them in Visit through the database file. They only seem to have pressure, x, y, z components of velocity and the velocity magnitude. Could something be wrong? Mani chandra From nek5000-users at lists.mcs.anl.gov Sat Mar 27 07:43:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 27 Mar 2010 07:43:50 -0500 (CDT) Subject: [Nek5000-users] [*] Re: Postprocessing In-Reply-To: <4BADE698.8070504@iitk.ac.in> References: <4BAA3710.1050803@iitk.ac.in> <4BADE698.8070504@iitk.ac.in> Message-ID: Hi Mani, Nek currently supports only a few output fields: X, V, p, T, ps1, ... ,psn X = coords V = velocity p = pressure T = temperature psj = jth passive scalar The call call outpost(vort(1,1),vort(1,2),vort(1,3),pr,t,'vrt') would generate a file "vrtmycase0.f..." with vorticity components in place of V=(vx,vy,vz). To view these with visit, load the vrt... file and request to look at "velocity" (VisIt thinks the field is a velocity field). Paul On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > On 03/24/2010 09:58 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> Mani, >> >> It somewhat depends on what you're after. >> >> You can use postx and compute the vorticity there --- it is >> only 32 bit but it does allow you to compute the vorticity >> for any existing velocity data in the (older) .fld file >> output format. >> >> Alternatively, if you're using VisIt or some other analysis >> tool, or doing run-time analysis, you can compute the vorticity >> at runtime. If you wish to output the vorticity field, you can >> do so, e.g., as follows: >> >> c----------------------------------------------------------------------- >> subroutine userchk >> include 'SIZE' >> include 'TOTAL' >> >> parameter(lt=lx1*ly1*lz1*lelv) >> common /scrns/ vort(lt,3),w1(lt),w2(lt) >> >> if (mod(istep,iostep).eq.0) then >> call comp_vort3(vort,w1,w2,vx,vy,vz) >> call outpost(vort(1,1),vort(1,2),vort(1,3),pr,t,'vrt') >> endif >> >> return >> end >> c----------------------------------------------------------------------- >> >> >> This would generate an output "vrtmy_case..." if your .rea file is >> my_case.rea >> >> Any of the post-processing tools could then read the vrt.... files >> and treat the vorticity as the velocity vector field. >> >> As I say, not exactly sure what you have in mind, but this is one >> possible approach. >> >> Paul >> >> >> >> >> >> On Wed, 24 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear Nek devs, >>> >>> I'm a bit confused regarding postprocessing. Is one supposed to run a >>> simulation and then run nek5k again to load the fld files using load_fld() >>> for postprocessing? Or can one compute the desired quantities after every >>> time step using userchk() and then output them in a file? For example, how >>> can I compute the vorticity using the differential operators defined in >>> the code? After computing the vorticity, can it be outputted using the >>> same fld files? >>> >>> Regards, >>> Mani chandra >>> _______________________________________________ >>> 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 >> > Dear Paul, > > The files generated by the code in usr_chk(), vrtmy_case0.f* do not seem > to have vorticity in them when I view them in Visit through the database > file. They only seem to have pressure, x, y, z components of velocity and the > velocity magnitude. Could something be wrong? > > Mani chandra > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sat Mar 27 09:05:32 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 27 Mar 2010 19:35:32 +0530 Subject: [Nek5000-users] Compilation errors when points in an element become large Message-ID: <4BAE10AC.3020903@iitk.ac.in> Dear Nek devs, In the example case "pipe", when I put in lx1=16 and lxd=24 with everything else being the same, the following compilation error occurs: mpif77 -o nek5000 drive.o drive1.o drive2.o plan4.o bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o subuser.o isosurf.o byte.o chelpers.o byte_mpi.o postpro.o cvode_driver.o setprop.o qthermal.o makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o jl2_gs.o jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o comm_mpi.o drive2.o: In function `a_dmp_': drive2.f:(.text+0x61f): relocation truncated to fit: R_X86_64_32S against symbol `scruz_' defined in COMMON section in plan4.o drive2.f:(.text+0x631): relocation truncated to fit: R_X86_64_32 against symbol `scrns_' defined in COMMON section in convect.o drive2.f:(.text+0x647): relocation truncated to fit: R_X86_64_32 against symbol `scrns_' defined in COMMON section in convect.o drive2.o: In function `plan3_vol_': drive2.f:(.text+0x6b0): relocation truncated to fit: R_X86_64_PC32 against symbol `cvflow_i_' defined in COMMON section in drive2.o drive2.f:(.text+0x6de): relocation truncated to fit: R_X86_64_32 against symbol `scrns_' defined in COMMON section in convect.o drive2.f:(.text+0x6ee): relocation truncated to fit: R_X86_64_32 against symbol `scrns_' defined in COMMON section in convect.o drive2.f:(.text+0x700): relocation truncated to fit: R_X86_64_32 against symbol `scrns_' defined in COMMON section in convect.o drive2.f:(.text+0x72f): relocation truncated to fit: R_X86_64_32 against symbol `scrns_' defined in COMMON section in convect.o drive2.f:(.text+0x735): relocation truncated to fit: R_X86_64_32 against symbol `scrns_' defined in COMMON section in convect.o drive2.f:(.text+0x73a): relocation truncated to fit: R_X86_64_32 against symbol `scrns_' defined in COMMON section in convect.o drive2.f:(.text+0x75e): additional relocation overflows omitted from the output collect2: ld returned 1 exit status make: *** [nek5000] Error 1 These kind of errors seem to come up whenever I increase lx1, lxd or sometimes even lelt and lelg to a large number in other examples too. How do i rectify this? Also what are the functions of lelx, lely and lelz? These parameters are not documented on the Nek5000 website. Regards, Mani chandra From nek5000-users at lists.mcs.anl.gov Sat Mar 27 09:28:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 27 Mar 2010 09:28:59 -0500 (CDT) Subject: [Nek5000-users] Compilation errors when points in an element become large In-Reply-To: <4BAE10AC.3020903@iitk.ac.in> References: <4BAE10AC.3020903@iitk.ac.in> Message-ID: Mani, You are exceeding local (per processor memory limits). Are you running this in parallel? One cure (for some compilers, and assuming you have enough memory on your machine) is to add to the makenek script: G = "-mcmodel=medium" which allows one to address the large memory limit. Another simple thing to do (particularly if running in serial) is to make certain that lelt and lelv do not exceed the number of elements in your simulation (determined by "grep NEL pipe.rea"). Lelt and lelv are the upper bounds on number of elements PER PROCESSOR. If you are using 8 processors, then you could have lelt = lelv >= NEL/8 where lelt and lelv are set in SIZEu (soon to be "SIZE" with the latest release) and NEL is the value in your .rea file. Does this make sense? Paul On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nek devs, > > In the example case "pipe", when I put in lx1=16 and lxd=24 with > everything else being the same, the following compilation error occurs: > > mpif77 -o nek5000 drive.o drive1.o drive2.o plan4.o bdry.o coef.o conduct.o > connect1.o connect2.o dssum.o edgec.o eigsolv.o gauss.o genxyz.o navier1.o > navier0.o navier2.o navier3.o navier4.o prepost.o speclib.o map2.o turb.o > mvmesh.o ic.o ssolv.o planx.o math.o mxm_wrapper.o hmholtz.o gfdm_par.o > gfdm_op.o gfdm_solve.o subs1.o subs2.o genbox.o gmres.o hsmg.o convect.o > induct.o perturb.o navier5.o navier6.o navier7.o navier8.o fast3d.o fasts.o > calcz.o subuser.o isosurf.o byte.o chelpers.o byte_mpi.o postpro.o > cvode_driver.o setprop.o qthermal.o makeq.o papi.o ssygv.o dsygv.o mxm_std.o > blas.o jl2_gs.o jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o > jl2_gs_local.o jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o > jl2_fcrystal.o jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o > jl_errmem.o jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o > jl_poly.o jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o comm_mpi.o > drive2.o: In function `a_dmp_': > drive2.f:(.text+0x61f): relocation truncated to fit: R_X86_64_32S against > symbol `scruz_' defined in COMMON section in plan4.o > drive2.f:(.text+0x631): relocation truncated to fit: R_X86_64_32 against > symbol `scrns_' defined in COMMON section in convect.o > drive2.f:(.text+0x647): relocation truncated to fit: R_X86_64_32 against > symbol `scrns_' defined in COMMON section in convect.o > drive2.o: In function `plan3_vol_': > drive2.f:(.text+0x6b0): relocation truncated to fit: R_X86_64_PC32 against > symbol `cvflow_i_' defined in COMMON section in drive2.o > drive2.f:(.text+0x6de): relocation truncated to fit: R_X86_64_32 against > symbol `scrns_' defined in COMMON section in convect.o > drive2.f:(.text+0x6ee): relocation truncated to fit: R_X86_64_32 against > symbol `scrns_' defined in COMMON section in convect.o > drive2.f:(.text+0x700): relocation truncated to fit: R_X86_64_32 against > symbol `scrns_' defined in COMMON section in convect.o > drive2.f:(.text+0x72f): relocation truncated to fit: R_X86_64_32 against > symbol `scrns_' defined in COMMON section in convect.o > drive2.f:(.text+0x735): relocation truncated to fit: R_X86_64_32 against > symbol `scrns_' defined in COMMON section in convect.o > drive2.f:(.text+0x73a): relocation truncated to fit: R_X86_64_32 against > symbol `scrns_' defined in COMMON section in convect.o > drive2.f:(.text+0x75e): additional relocation overflows omitted from the > output > collect2: ld returned 1 exit status > make: *** [nek5000] Error 1 > > These kind of errors seem to come up whenever I increase lx1, lxd or > sometimes even lelt and lelg to a large number in other examples too. How do > i rectify this? > Also what are the functions of lelx, lely and lelz? These parameters are not > documented on the Nek5000 website. > > Regards, > Mani chandra > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sat Mar 27 17:34:51 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 27 Mar 2010 17:34:51 -0500 (CDT) Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: <2063501867.99301269729106230.JavaMail.root@neo-mail-3> Message-ID: <134916948.99691269729291839.JavaMail.root@neo-mail-3> Hello Users, My question is in regard to the curved side data section in the REA file.? I know that the first 3 terms?describe the side, element, and radius, but there are several other numbers that are currently zero, and then the letter C. Background for the question: I have a situation where I would like to curve an element edge in any plane. I know this is possible from previous posts regarding a sphere.rea. I know that with two points and a radius, that is enough to describe a circle in a plane.? But lets say I have a side where 2 pts lie on the XY plane, but the center of the circle is located on the YZ plane for example... the question is how to represent this in the REA. In the REA you just give the element side ( 2 pts ) and the radius, which does fix the circle center but the plane that contains the center is not fixed.? So what I am wondering is what the other numbers in this section do...if you could say, give the center instead of the radius, or give a third point with the other 2 pts in the element side to fully define the circle and plane. Also, Is it possible to curve the remaining 4 sides of the element (edges 9, 10, 11, 12 that would be in the "z" direction) in the same manner as edges 1-8? Thanks for any input on this matter! Regards, Michael Meador -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat Mar 27 22:34:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 27 Mar 2010 22:34:12 -0500 (CDT) Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: <134916948.99691269729291839.JavaMail.root@neo-mail-3> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> Message-ID: Michael, I've only recently added general purpose midside-node support, which puts a point in 3-space for any one of the 12 edges and nek then fits a parabola to this. I'll set up an example that demos this. The feature has limited support at the moment -- but does work in nek5000 and generates correct geometry. Depending on what you are after, there may be other ways to generate the geometry. One of my favorite techniques is to project a given input geometry onto the desired surface. Paul On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: Hello Users, My question is in regard to the curved side data section in the REA file.?? I know that the first 3 terms??describe the side, element, and radius, but there are several other numbers that are currently zero, and then the letter C. Background for the question: I have a situation where I would like to curve an element edge in any plane. I know this is possible from previous posts regarding a sphere.rea. I know that with two points and a radius, that is enough to describe a circle in a plane.?? But lets say I have a side where 2 pts lie on the XY plane, but the center of the circle is located on the YZ plane for example... the question is how to represent this in the REA. In the REA you just give the element side ( 2 pts ) and the radius, which does fix the circle center but the plane that contains the center is not fixed.?? So what I am wondering is what the other numbers in this section do...if you could say, give the center instead of the radius, or give a third point with the other 2 pts in the element side to fully define the circle and plane. Also, Is it possible to curve the remaining 4 sides of the element (edges 9, 10, 11, 12 that would be in the "z" direction) in the same manner as edges 1-8? Thanks for any input on this matter! Regards, Michael Meador From nek5000-users at lists.mcs.anl.gov Mon Mar 29 08:59:08 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 29 Mar 2010 09:59:08 -0400 Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> Message-ID: <4BB0B22C.9030903@vt.edu> Hi, I was looking into the midpoint feature and generated a cube (1 element, x, y, z from 0 to 1) in prenek, then converted all edges to the midpoint notation with prenek, and then manipulated one edge in the rea file. This is the resulting curved side section: ***** CURVED SIDE DATA ***** 12 Curved sides follow IEDGE,IEL,CURVE(I),I=1,5, CCURVE 1 1 0.500000 0.00000 0.00000 0.00000 0.00000 m 2 1 1.10000 0.500000 0.00000 0.00000 0.00000 m . . . 10 1 1.00000 -0.500000 0.500000 0.00000 0.00000 m 11 1 1.00000 1.00000 0.500000 0.00000 0.00000 m 12 1 0.00000 1.00000 0.500000 0.00000 0.00000 m where edge 10 is supposedly not a straight line any more. When I run this in nek, however, the cube still comes out with straight edges. Are there any other parameters I need to set? I checked out the most recent nek version and overcame compilation issues with gcc-gfortran 4.4.3-4.fc12 from the fedora 12 repository. Thanks, Markus nek5000-users at lists.mcs.anl.gov wrote: > > > Michael, > > I've only recently added general purpose midside-node support, > which puts a point in 3-space for any one of the 12 edges and > nek then fits a parabola to this. > > I'll set up an example that demos this. The feature has limited > support at the moment -- but does work in nek5000 and generates > correct geometry. > > Depending on what you are after, there may be other ways to > generate the geometry. One of my favorite techniques is to > project a given input geometry onto the desired surface. > > > Paul > > > > On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > Hello Users, > > > > > My question is in regard to the curved side data section in the REA > file. I know that the first 3 terms describe the side, element, and > radius, but there are several other numbers that are currently zero, and > then the letter C. > > > > Background for the question: I have a situation where I would like to > curve an element edge in any plane. I know this is possible from > previous posts regarding a sphere.rea. > > > > I know that with two points and a radius, that is enough to describe a > circle in a plane. But lets say I have a side where 2 pts lie on the > XY plane, but the center of the circle is located on the YZ plane for > example... the question is how to represent this in the REA. In the REA > you just give the element side ( 2 pts ) and the radius, which does fix > the circle center but the plane that contains the center is not > fixed. So what I am wondering is what the other numbers in this > section do...if you could say, give the center instead of the radius, or > give a third point with the other 2 pts in the element side to fully > define the circle and plane. > > > > Also, Is it possible to curve the remaining 4 sides of the element > (edges 9, 10, 11, 12 that would be in the "z" direction) in the same > manner as edges 1-8? Thanks for any input on this matter! > > > > Regards, > > Michael Meador > > > ------------------------------------------------------------------------ > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Mar 29 10:04:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 29 Mar 2010 10:04:29 -0500 (CDT) Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: <4BB0B22C.9030903@vt.edu> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> Message-ID: Hi Markus, Did you visualize this with VisIt and with the geometry put out into (at least) the first .fld or .f file ? Paul On Mon, 29 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I was looking into the midpoint feature and generated a cube (1 element, x, > y, z from 0 to 1) in prenek, then converted all edges to the midpoint > notation with prenek, and then manipulated one edge in the rea file. This is > the resulting curved side section: > ***** CURVED SIDE DATA ***** > 12 Curved sides follow IEDGE,IEL,CURVE(I),I=1,5, CCURVE > 1 1 0.500000 0.00000 0.00000 0.00000 0.00000 m > 2 1 1.10000 0.500000 0.00000 0.00000 0.00000 m > . > . > . > 10 1 1.00000 -0.500000 0.500000 0.00000 0.00000 m > 11 1 1.00000 1.00000 0.500000 0.00000 0.00000 m > 12 1 0.00000 1.00000 0.500000 0.00000 0.00000 m > > where edge 10 is supposedly not a straight line any more. > > When I run this in nek, however, the cube still comes out with straight > edges. > > Are there any other parameters I need to set? > > I checked out the most recent nek version and overcame compilation issues > with gcc-gfortran 4.4.3-4.fc12 from the fedora 12 repository. > > Thanks, > Markus > > > nek5000-users at lists.mcs.anl.gov wrote: >> >> >> Michael, >> >> I've only recently added general purpose midside-node support, >> which puts a point in 3-space for any one of the 12 edges and >> nek then fits a parabola to this. >> >> I'll set up an example that demos this. The feature has limited >> support at the moment -- but does work in nek5000 and generates >> correct geometry. >> >> Depending on what you are after, there may be other ways to >> generate the geometry. One of my favorite techniques is to >> project a given input geometry onto the desired surface. >> >> >> Paul >> >> >> >> On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >> >> >> Hello Users, >> >> >> >> >> My question is in regard to the curved side data section in the REA >> file. I know that the first 3 terms describe the side, element, and >> radius, but there are several other numbers that are currently zero, and >> then the letter C. >> >> >> >> Background for the question: I have a situation where I would like to >> curve an element edge in any plane. I know this is possible from >> previous posts regarding a sphere.rea. >> >> >> >> I know that with two points and a radius, that is enough to describe a >> circle in a plane. But lets say I have a side where 2 pts lie on the >> XY plane, but the center of the circle is located on the YZ plane for >> example... the question is how to represent this in the REA. In the REA >> you just give the element side ( 2 pts ) and the radius, which does fix >> the circle center but the plane that contains the center is not >> fixed. So what I am wondering is what the other numbers in this >> section do...if you could say, give the center instead of the radius, or >> give a third point with the other 2 pts in the element side to fully >> define the circle and plane. >> >> >> >> Also, Is it possible to curve the remaining 4 sides of the element >> (edges 9, 10, 11, 12 that would be in the "z" direction) in the same >> manner as edges 1-8? Thanks for any input on this matter! >> >> >> >> Regards, >> >> Michael Meador >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Mar 29 11:21:51 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 29 Mar 2010 12:21:51 -0400 Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> Message-ID: <1269879711.4bb0d39f7044c@webmail.vt.edu> Hi, just double-checked, that's what I did. I only ran it for one time step without any meaningful physics, though. Attached are all case files. The nek version I am using is revision 456. Markus Quoting nek5000-users at lists.mcs.anl.gov: > > Hi Markus, > > Did you visualize this with VisIt and with the geometry > put out into (at least) the first .fld or .f file ? > > Paul > > > On Mon, 29 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi, > > > > I was looking into the midpoint feature and generated a cube (1 element, x, > > y, z from 0 to 1) in prenek, then converted all edges to the midpoint > > notation with prenek, and then manipulated one edge in the rea file. This > is > > the resulting curved side section: > > ***** CURVED SIDE DATA ***** > > 12 Curved sides follow IEDGE,IEL,CURVE(I),I=1,5, CCURVE > > 1 1 0.500000 0.00000 0.00000 0.00000 0.00000 m > > 2 1 1.10000 0.500000 0.00000 0.00000 0.00000 m > > . > > . > > . > > 10 1 1.00000 -0.500000 0.500000 0.00000 0.00000 m > > 11 1 1.00000 1.00000 0.500000 0.00000 0.00000 m > > 12 1 0.00000 1.00000 0.500000 0.00000 0.00000 m > > > > where edge 10 is supposedly not a straight line any more. > > > > When I run this in nek, however, the cube still comes out with straight > > edges. > > > > Are there any other parameters I need to set? > > > > I checked out the most recent nek version and overcame compilation issues > > with gcc-gfortran 4.4.3-4.fc12 from the fedora 12 repository. > > > > Thanks, > > Markus > > > > > > nek5000-users at lists.mcs.anl.gov wrote: > >> > >> > >> Michael, > >> > >> I've only recently added general purpose midside-node support, > >> which puts a point in 3-space for any one of the 12 edges and > >> nek then fits a parabola to this. > >> > >> I'll set up an example that demos this. The feature has limited > >> support at the moment -- but does work in nek5000 and generates > >> correct geometry. > >> > >> Depending on what you are after, there may be other ways to > >> generate the geometry. One of my favorite techniques is to > >> project a given input geometry onto the desired surface. > >> > >> > >> Paul > >> > >> > >> > >> On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> > >> > >> > >> Hello Users, > >> > >> > >> > >> > >> My question is in regard to the curved side data section in the REA > >> file. I know that the first 3 terms describe the side, element, and > >> radius, but there are several other numbers that are currently zero, and > >> then the letter C. > >> > >> > >> > >> Background for the question: I have a situation where I would like to > >> curve an element edge in any plane. I know this is possible from > >> previous posts regarding a sphere.rea. > >> > >> > >> > >> I know that with two points and a radius, that is enough to describe a > >> circle in a plane. But lets say I have a side where 2 pts lie on the > >> XY plane, but the center of the circle is located on the YZ plane for > >> example... the question is how to represent this in the REA. In the REA > >> you just give the element side ( 2 pts ) and the radius, which does fix > >> the circle center but the plane that contains the center is not > >> fixed. So what I am wondering is what the other numbers in this > >> section do...if you could say, give the center instead of the radius, or > >> give a third point with the other 2 pts in the element side to fully > >> define the circle and plane. > >> > >> > >> > >> Also, Is it possible to curve the remaining 4 sides of the element > >> (edges 9, 10, 11, 12 that would be in the "z" direction) in the same > >> manner as edges 1-8? Thanks for any input on this matter! > >> > >> > >> > >> Regards, > >> > >> Michael Meador > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: test.tar.bz2 Type: application/x-bzip Size: 6000 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon Mar 29 11:37:43 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 29 Mar 2010 11:37:43 -0500 (CDT) Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: <1269879711.4bb0d39f7044c@webmail.vt.edu> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <1269879711.4bb0d39f7044c@webmail.vt.edu> Message-ID: Hi Markus, Thanks -- I'll check into it. Paul On Mon, 29 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > just double-checked, that's what I did. I only ran it for one time step without > any meaningful physics, though. > Attached are all case files. The nek version I am using is revision 456. > > Markus > > > > Quoting nek5000-users at lists.mcs.anl.gov: > >> >> Hi Markus, >> >> Did you visualize this with VisIt and with the geometry >> put out into (at least) the first .fld or .f file ? >> >> Paul >> >> >> On Mon, 29 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> I was looking into the midpoint feature and generated a cube (1 element, x, >>> y, z from 0 to 1) in prenek, then converted all edges to the midpoint >>> notation with prenek, and then manipulated one edge in the rea file. This >> is >>> the resulting curved side section: >>> ***** CURVED SIDE DATA ***** >>> 12 Curved sides follow IEDGE,IEL,CURVE(I),I=1,5, CCURVE >>> 1 1 0.500000 0.00000 0.00000 0.00000 0.00000 m >>> 2 1 1.10000 0.500000 0.00000 0.00000 0.00000 m >>> . >>> . >>> . >>> 10 1 1.00000 -0.500000 0.500000 0.00000 0.00000 m >>> 11 1 1.00000 1.00000 0.500000 0.00000 0.00000 m >>> 12 1 0.00000 1.00000 0.500000 0.00000 0.00000 m >>> >>> where edge 10 is supposedly not a straight line any more. >>> >>> When I run this in nek, however, the cube still comes out with straight >>> edges. >>> >>> Are there any other parameters I need to set? >>> >>> I checked out the most recent nek version and overcame compilation issues >>> with gcc-gfortran 4.4.3-4.fc12 from the fedora 12 repository. >>> >>> Thanks, >>> Markus >>> >>> >>> nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>> >>>> Michael, >>>> >>>> I've only recently added general purpose midside-node support, >>>> which puts a point in 3-space for any one of the 12 edges and >>>> nek then fits a parabola to this. >>>> >>>> I'll set up an example that demos this. The feature has limited >>>> support at the moment -- but does work in nek5000 and generates >>>> correct geometry. >>>> >>>> Depending on what you are after, there may be other ways to >>>> generate the geometry. One of my favorite techniques is to >>>> project a given input geometry onto the desired surface. >>>> >>>> >>>> Paul >>>> >>>> >>>> >>>> On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>> >>>> >>>> Hello Users, >>>> >>>> >>>> >>>> >>>> My question is in regard to the curved side data section in the REA >>>> file. I know that the first 3 terms describe the side, element, and >>>> radius, but there are several other numbers that are currently zero, and >>>> then the letter C. >>>> >>>> >>>> >>>> Background for the question: I have a situation where I would like to >>>> curve an element edge in any plane. I know this is possible from >>>> previous posts regarding a sphere.rea. >>>> >>>> >>>> >>>> I know that with two points and a radius, that is enough to describe a >>>> circle in a plane. But lets say I have a side where 2 pts lie on the >>>> XY plane, but the center of the circle is located on the YZ plane for >>>> example... the question is how to represent this in the REA. In the REA >>>> you just give the element side ( 2 pts ) and the radius, which does fix >>>> the circle center but the plane that contains the center is not >>>> fixed. So what I am wondering is what the other numbers in this >>>> section do...if you could say, give the center instead of the radius, or >>>> give a third point with the other 2 pts in the element side to fully >>>> define the circle and plane. >>>> >>>> >>>> >>>> Also, Is it possible to curve the remaining 4 sides of the element >>>> (edges 9, 10, 11, 12 that would be in the "z" direction) in the same >>>> manner as edges 1-8? Thanks for any input on this matter! >>>> >>>> >>>> >>>> Regards, >>>> >>>> Michael Meador >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > > > From nek5000-users at lists.mcs.anl.gov Wed Mar 31 09:14:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 31 Mar 2010 19:44:25 +0530 Subject: [Nek5000-users] [*] Re: [*] Re: Postprocessing In-Reply-To: References: <4BAA3710.1050803@iitk.ac.in> <4BADE698.8070504@iitk.ac.in> Message-ID: <4BB358C1.3070903@iitk.ac.in> Dear Paul, Does the code that you gave to output vorticity work for 2D too? I'm trying to simulate a lid driven cavity at Re=10000 and the velocity seems fine but nothing shows up on the vorticity plot (I've attached both of them). Mani chandra On 03/27/2010 06:13 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Mani, > > Nek currently supports only a few output fields: > > X, V, p, T, ps1, ... ,psn > > X = coords > V = velocity > p = pressure > T = temperature > psj = jth passive scalar > > The call > > call outpost(vort(1,1),vort(1,2),vort(1,3),pr,t,'vrt') > > would generate a file "vrtmycase0.f..." with vorticity > components in place of V=(vx,vy,vz). > > To view these with visit, load the vrt... file and request > to look at "velocity" (VisIt thinks the field is a velocity > field). > > Paul > > > On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> On 03/24/2010 09:58 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>> Mani, >>> >>> It somewhat depends on what you're after. >>> >>> You can use postx and compute the vorticity there --- it is >>> only 32 bit but it does allow you to compute the vorticity >>> for any existing velocity data in the (older) .fld file >>> output format. >>> >>> Alternatively, if you're using VisIt or some other analysis >>> tool, or doing run-time analysis, you can compute the vorticity >>> at runtime. If you wish to output the vorticity field, you can >>> do so, e.g., as follows: >>> >>> c----------------------------------------------------------------------- >>> >>> subroutine userchk >>> include 'SIZE' >>> include 'TOTAL' >>> >>> parameter(lt=lx1*ly1*lz1*lelv) >>> common /scrns/ vort(lt,3),w1(lt),w2(lt) >>> >>> if (mod(istep,iostep).eq.0) then >>> call comp_vort3(vort,w1,w2,vx,vy,vz) >>> call outpost(vort(1,1),vort(1,2),vort(1,3),pr,t,'vrt') >>> endif >>> >>> return >>> end >>> c----------------------------------------------------------------------- >>> >>> >>> >>> This would generate an output "vrtmy_case..." if your .rea file is >>> my_case.rea >>> >>> Any of the post-processing tools could then read the vrt.... files >>> and treat the vorticity as the velocity vector field. >>> >>> As I say, not exactly sure what you have in mind, but this is one >>> possible approach. >>> >>> Paul >>> >>> >>> >>> >>> >>> On Wed, 24 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Dear Nek devs, >>>> >>>> I'm a bit confused regarding postprocessing. Is one supposed to >>>> run a simulation and then run nek5k again to load the fld files >>>> using load_fld() for postprocessing? Or can one compute the desired >>>> quantities after every time step using userchk() and then output >>>> them in a file? For example, how can I compute the vorticity using >>>> the differential operators defined in the code? After computing the >>>> vorticity, can it be outputted using the same fld files? >>>> >>>> Regards, >>>> Mani chandra >>>> _______________________________________________ >>>> 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 >>> >> Dear Paul, >> >> The files generated by the code in usr_chk(), vrtmy_case0.f* do >> not seem to have vorticity in them when I view them in Visit through >> the database file. They only seem to have pressure, x, y, z >> components of velocity and the velocity magnitude. Could something be >> wrong? >> >> Mani chandra >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: velocity.png Type: image/png Size: 178269 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vorticity.png Type: image/png Size: 62975 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Mar 31 09:32:51 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 31 Mar 2010 16:32:51 +0200 Subject: [Nek5000-users] [*] Re: [*] Re: Postprocessing In-Reply-To: <4BB358C1.3070903@iitk.ac.in> References: <4BAA3710.1050803@iitk.ac.in> <4BADE698.8070504@iitk.ac.in> <4BB358C1.3070903@iitk.ac.in> Message-ID: <97199DFD-372A-4E4F-811A-2EBDB75659D0@lav.mavt.ethz.ch> Mani, yes comp_vort3() works for 2D and 3D. The reason why your vorticity seems to be ZERO is simple.: If you call outpost(fld1,fld2,fld3,fld4,fld5,'foo') in 2D you'll dump effectively {fld1,fld2,fld4,fld5}. The 'z-velocity' (here fld3) is missing in 2D. However vort(1,3) is the only non-trivial component in 2D! There is an easy fix: Put vort(1,3) first in the argument list of outpost() and then visualize the vorticity using the x-velocity variable in VisIt. hth, Stefan On Mar 31, 2010, at 4:14 PM, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul, > > Does the code that you gave to output vorticity work for 2D too? I'm trying to simulate a lid driven cavity at Re=10000 and the velocity seems fine but nothing shows up on the vorticity plot (I've attached both of them). > > Mani chandra > > On 03/27/2010 06:13 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> Hi Mani, >> >> Nek currently supports only a few output fields: >> >> X, V, p, T, ps1, ... ,psn >> >> X = coords >> V = velocity >> p = pressure >> T = temperature >> psj = jth passive scalar >> >> The call >> >> call outpost(vort(1,1),vort(1,2),vort(1,3),pr,t,'vrt') >> >> would generate a file "vrtmycase0.f..." with vorticity >> components in place of V=(vx,vy,vz). >> >> To view these with visit, load the vrt... file and request >> to look at "velocity" (VisIt thinks the field is a velocity >> field). >> >> Paul >> >> >> On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> On 03/24/2010 09:58 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>> Mani, >>>> >>>> It somewhat depends on what you're after. >>>> >>>> You can use postx and compute the vorticity there --- it is >>>> only 32 bit but it does allow you to compute the vorticity >>>> for any existing velocity data in the (older) .fld file >>>> output format. >>>> >>>> Alternatively, if you're using VisIt or some other analysis >>>> tool, or doing run-time analysis, you can compute the vorticity >>>> at runtime. If you wish to output the vorticity field, you can >>>> do so, e.g., as follows: >>>> >>>> c----------------------------------------------------------------------- >>>> subroutine userchk >>>> include 'SIZE' >>>> include 'TOTAL' >>>> >>>> parameter(lt=lx1*ly1*lz1*lelv) >>>> common /scrns/ vort(lt,3),w1(lt),w2(lt) >>>> >>>> if (mod(istep,iostep).eq.0) then >>>> call comp_vort3(vort,w1,w2,vx,vy,vz) >>>> call outpost(vort(1,1),vort(1,2),vort(1,3),pr,t,'vrt') >>>> endif >>>> >>>> return >>>> end >>>> c----------------------------------------------------------------------- >>>> >>>> >>>> This would generate an output "vrtmy_case..." if your .rea file is >>>> my_case.rea >>>> >>>> Any of the post-processing tools could then read the vrt.... files >>>> and treat the vorticity as the velocity vector field. >>>> >>>> As I say, not exactly sure what you have in mind, but this is one >>>> possible approach. >>>> >>>> Paul >>>> >>>> >>>> >>>> >>>> >>>> On Wed, 24 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Dear Nek devs, >>>>> >>>>> I'm a bit confused regarding postprocessing. Is one supposed to run a simulation and then run nek5k again to load the fld files using load_fld() for postprocessing? Or can one compute the desired quantities after every time step using userchk() and then output them in a file? For example, how can I compute the vorticity using the differential operators defined in the code? After computing the vorticity, can it be outputted using the same fld files? >>>>> >>>>> Regards, >>>>> Mani chandra >>>>> _______________________________________________ >>>>> 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 >>>> >>> Dear Paul, >>> >>> The files generated by the code in usr_chk(), vrtmy_case0.f* do not seem to have vorticity in them when I view them in Visit through the database file. They only seem to have pressure, x, y, z components of velocity and the velocity magnitude. Could something be wrong? >>> >>> Mani chandra >>> _______________________________________________ >>> 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 >> > >