From nek5000-users at lists.mcs.anl.gov Wed Jun 2 08:15:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 02 Jun 2010 15:15:53 +0200 Subject: [Nek5000-users] Compute the derivatives Message-ID: <4C065989.7050602@gmail.com> Hi Nek's, I have a home-made global stability code, but in order to use it I first need to compute the derivatives of my base flow: dUdX, dUdY, dVdX, dVdY. How could one compute these derivatives using Nek 5k and drop them along with X Y U V in the blah.f**** file (or perhaps another .f**** file) ? I assume I have to make use of the subroutine *dudxyz (du,u,rm1,sm1,tm1,jm1,imsh,isd)*, but I'm not sure what to put as inputs. Regards, JC -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 2 08:58:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 2 Jun 2010 08:58:23 -0500 (CDT) Subject: [Nek5000-users] Compute the derivatives In-Reply-To: <4C065989.7050602@gmail.com> References: <4C065989.7050602@gmail.com> Message-ID: dudxyz is somewhat dated and slow... I recommend somthing like: parameter (lt=lx1*ly1*lz1*lelv) common /mygrad/ vxx(lt),vxy(lt),vxz(lt) $ , vyx(lt),vyy(lt),vyz(lt) $ , vzx(lt),vzy(lt),vzz(lt) call gradm1(vxx,vxy,vxz,vx) call gradm1(vyx,vyy,vyz,vy) call gradm1(vzx,vzy,vzz,vz) Note that putting these arrays into a common block, as shown, is a good idea for several reasons, one of which is that it guarantees that the data will be byte-aligned with the cache line. On some machines (e.g., BG/P) this is crucial for proper functionality - for this reason we don't mix variable types in a given common block. If you subsequently wish to access elements of vxx etc. on an element-by-element basis you can of course do something like parameter (lt=lx1*ly1*lz1) common /mygrad/ vxx(lt,lelt),vxy(lt,lelt),vxz(lt,lelt) : : Paul On Wed, 2 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > I have a home-made global stability code, but in order to use it I first need > to compute the derivatives of my base flow: dUdX, dUdY, dVdX, dVdY. > How could one compute these derivatives using Nek 5k and drop them along with > X Y U V in the blah.f**** file (or perhaps another .f**** file) ? I assume I > have to make use of the subroutine *dudxyz (du,u,rm1,sm1,tm1,jm1,imsh,isd)*, > but I'm not sure what to put as inputs. > > Regards, > JC > From nek5000-users at lists.mcs.anl.gov Wed Jun 2 10:57:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 2 Jun 2010 10:57:41 -0500 (CDT) Subject: [Nek5000-users] Compute the derivatives In-Reply-To: References: <4C065989.7050602@gmail.com> Message-ID: Hi JC, To dump the computed derivatives into separate field files you can use in userchk ifxyo = .true. ! for cooordinates ifpo = .false. ! turn off pressure output ifto = .false. ! turn off pressure output call outpost(vxx,vxy,vxz,pr,t,'dvx') call outpost(vyx,vyy,vyz,pr,t,'dvy') ... Best, Aleks On Wed, 2 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > dudxyz is somewhat dated and slow... > > I recommend somthing like: > > parameter (lt=lx1*ly1*lz1*lelv) > common /mygrad/ vxx(lt),vxy(lt),vxz(lt) > $ , vyx(lt),vyy(lt),vyz(lt) > $ , vzx(lt),vzy(lt),vzz(lt) > > call gradm1(vxx,vxy,vxz,vx) > call gradm1(vyx,vyy,vyz,vy) > call gradm1(vzx,vzy,vzz,vz) > > Note that putting these arrays into a common block, as > shown, is a good idea for several reasons, one of which > is that it guarantees that the data will be byte-aligned with the cache line. > On some machines (e.g., BG/P) this > is crucial for proper functionality - for this reason we > don't mix variable types in a given common block. > > If you subsequently wish to access elements of vxx etc. > on an element-by-element basis you can of course do something > like > > parameter (lt=lx1*ly1*lz1) > common /mygrad/ vxx(lt,lelt),vxy(lt,lelt),vxz(lt,lelt) > : > : > > Paul > > On Wed, 2 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Nek's, >> >> I have a home-made global stability code, but in order to use it I first >> need to compute the derivatives of my base flow: dUdX, dUdY, dVdX, dVdY. >> How could one compute these derivatives using Nek 5k and drop them along >> with X Y U V in the blah.f**** file (or perhaps another .f**** file) ? I >> assume I have to make use of the subroutine *dudxyz >> (du,u,rm1,sm1,tm1,jm1,imsh,isd)*, but I'm not sure what to put as inputs. >> >> Regards, >> JC >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Jun 3 14:42:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 03 Jun 2010 21:42:44 +0200 Subject: [Nek5000-users] NEKTON and Gambit In-Reply-To: <594293907.283401274553467407.JavaMail.root@neo-mail-3> References: <594293907.283401274553467407.JavaMail.root@neo-mail-3> Message-ID: <1275594164.3189.10.camel@localhost.localdomain> Hello Michael, If you get a chance to look at this, it would be greatly appreciated here. Cheers, Frank On Sat, 2010-05-22 at 13:37 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > Yes I am out of the country at the moment but can pass along the code > when I get back (in a week). > > And yes Gambit has an export format for Nekton but I couldn?t make > sense of it. I used a portion of matlab code Paul had written awhile > back that writes the REA format, the rest of the code simply extracts > information from the Generic Mesh file (Neutral file .neu) exported > from Gambit and prepares it to write the REA. > > I?ll post the code when I return and try to include some explanation > of how to get started with it. I included lots of comments so it > should be straight forward. > > Until then, > Michael M > > ----- Mensaje original ----- > De: nek5000-users at lists.mcs.anl.gov > Para: nek5000-users at lists.mcs.anl.gov > Enviados: Viernes, 21 de Mayo 2010 14:21:20 GMT -05:00 Colombia > Asunto: Re: [Nek5000-users] NEKTON and Gambit > > Hi Josh, > > Yes, I recall that. For sure, I'd be grateful if you could let him > know > that he has an eager customer for his program. > > Cheers, > Frank > > On Fri, 2010-05-21 at 19:09 +0000, nek5000-users at lists.mcs.anl.gov > wrote: > > Hey Frank, > > One of my colleagues, Michael, posted a method a while back that > lists the steps to do something like this. It involves exporting the > mesh from Gambit to the neutral file format (NEU) and then using a > matlab program to convert the mesh to a usable REA file. > > I can't go into more detail than that as I wasn't the one to write > the Matlab program, but I'm sure he wouldn't mind passing the Matlab > file along again when he gets back to campus. Hope this helps, > > > > - Josh > > -----Original Message----- > > From: nek5000-users at lists.mcs.anl.gov > > Date: Fri, 21 May 2010 18:39:51 > > To: > > Subject: [Nek5000-users] NEKTON and Gambit > > > > Hello all, > > > > I notice that Fluent's grid generator Gambit writes out meshes in > NEKTON > > format. However, from looking at the (ASCI) file it write out, it > > doesn't seem to be related to the structure the NEK5000 is > expecting. > > Does anyone know if it is at all possible to get a mesh from Gambit > into > > a format that NEK5000 can use? > > > > Cheers, > > Frank > > > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 > -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Jun 3 20:43:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 3 Jun 2010 20:43:23 -0500 (CDT) Subject: [Nek5000-users] GAMBIT to NEKTON matlab code In-Reply-To: <1438352388.2354651275615779538.JavaMail.root@neo-mail-3> Message-ID: <433051239.2354711275615803947.JavaMail.root@neo-mail-3> All, First, since this is not a question to the developers but rather a supplementary topic/useful tool for importing complex geometries, please reply to my personal email rather than clogging up the user list with questions. If a developer replies that it is not?a problem to respond directly then go ahead, but I feel it may be intrusive to some users searching for real questions.???? email:?? cmeador at tamu.edu ( for questions , I will try to get to them when I can) Attached is the matlab m-files necessary to convert a neutral file to a Nekton REA file. Note that it only creates the heart of the REA and you must paste it into a template REA of your choice. The main file to use is called " rea_write.m ". Here you specify the inputs at the top. You can read through the comments and get an idea of what functions do what.? I am sure that much of the program can be improved to run faster, but at the moment I don't have time for that and it is working for what I needed it to. To get started with Gambit, assuming you imported/created your geometry in gambit, follow these 3 basic steps: 1.??? Set Solver type to GENERIC 2.?? When Meshing, make sure the edge node count is 3 (for midpoints).? This should make the face count 8 and the volume count 20 nodes. ????? This setting is necessary to take advantage of Nektons mid side node support. 3.?? Use the zones to label faces as Boundary conditions. Select multiple faces if you like. Since the solver is set to generic, just call the BC anything you like, "Inlet" for example.? The Matlab code will ask you "What did you mean by Inlet", where you would input 'v' for a fortran velocity input.? If it is a thermal problem (TBC = 1 in the inputs in rea_write), it will ask for the momentum and thermal BC.? In gambit, any face that is not labeled with a BC type is assumed to be a Wall. NOTE:?? The Mesh must be HEX & Edge node count 3!...? ONLY works for 3D cases! I also included a few sample NEU files that you can try as examples, and to help check if your gambit mesh is set up correctly. Also, the code is written assuming Gambit calls the z-axis "y" and the y-axis "z". I found this was the case with the Gambit we were using, so the code will switch the coordinates. When we imported from Solidworks we noticed that it was doing this.? Hope this is enough to get started and good luck with it!! - Michael M. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GAMBIT TO NEK.zip Type: application/zip Size: 126725 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Thu Jun 3 21:01:14 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 04 Jun 2010 04:01:14 +0200 Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file Message-ID: <1275616874.3189.21.camel@localhost.localdomain> Hello Michael, It seems that you sent an email with a *.zip attachment, which due to a spam filter, got blocked. If it is renamed to say *.zipp, then it should get through. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Jun 3 21:13:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 3 Jun 2010 21:13:25 -0500 (CDT) Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <1596829159.2358011275617601163.JavaMail.root@neo-mail-3> Message-ID: <1504059398.2358031275617605483.JavaMail.root@neo-mail-3> Hi Frank, Try the attached. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada Central Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file Hello Michael, It seems that you sent an email with a *.zip attachment, which due to a spam filter, got blocked. ?If it is renamed to say *.zipp, then it should get through. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GambitToNek.tar Type: application/x-tar Size: 90836 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 4 09:15:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 Jun 2010 09:15:29 -0500 Subject: [Nek5000-users] "vnormal_desired = ?" for turbulent outflow boundary condition Message-ID: Hello, I am running a LES case for backward facing step with Re=28000. The incoming mean velocity is 1.0. I am having trouble with setting the turbulent outflow boundary condition. I am using the fill_div(usrdiv) subroutine. The "vnmo_desired = 0.05" for this case and for this value the simulation does not look right. As seen in the two figures for instantaneous and average x-velocity countour pictures. Instantaneous x-vel: http://www2.uic.edu/~hkanch1/x-vel-instantaneous.jpeg Average x-vel: http://www2.uic.edu/~hkanch1/x-vel-avg0000.jpeg For a value of "vnmo_desired" less than 0.02, the simulation blows up. Is there a way I can estimate the value of "vel_normal desired". The incoming channel height is 4.0 and mean velocity is 1.0. The outflow channel height is 5.0. The value of "dmax = 1.488", this is used in calculation "cdiv". Attached is the *.usr file for this case. Any help will be appreciated. Thanks, Harish. -------------- next part -------------- A non-text attachment was scrubbed... Name: bfs3d.usr Type: application/octet-stream Size: 8406 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 4 08:24:42 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 04 Jun 2010 09:24:42 -0400 Subject: [Nek5000-users] Visualizing moving meshes in VisIT Message-ID: <4C08FE9A.4020209@vt.edu> Frank, Hank, I am interested in visualizing moving meshes in VisIT. From previous posts, I read that you are working on that. Is it usable yet and how do I go about it? Thanks, Markus From nek5000-users at lists.mcs.anl.gov Fri Jun 4 10:40:22 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 Jun 2010 17:40:22 +0200 Subject: [Nek5000-users] RE : Visualizing moving meshes in VisIT In-Reply-To: <4C08FE9A.4020209@vt.edu> References: <4C08FE9A.4020209@vt.edu> Message-ID: <5313C3E0D03CB044A289CAC54D804C120157D55BF795@BVMBX1.univ-lyon1.fr> Hi Markus, I managed to get the moving mesh in VisIt by changing a line in the input plugin source code. You can easily download the source on VisIt website (you can also find some plugin compilation documentation there) and then recompile the plugin after having done the following : in function GetMesh() change the last line from : timestepToUseForMesh = 0; to : timestepToUseForMesh = ts; That works for me with VisIt 1.12.1 hth, Michael B ________________________________________ De : nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] de la part de nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Date d'envoi : vendredi 4 juin 2010 15:24 ? : nek5000-users at lists.mcs.anl.gov Objet : [Nek5000-users] Visualizing moving meshes in VisIT Frank, Hank, I am interested in visualizing moving meshes in VisIT. From previous posts, I read that you are working on that. Is it usable yet and how do I go about 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 Jun 4 15:17:33 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 04 Jun 2010 22:17:33 +0200 Subject: [Nek5000-users] Visualizing moving meshes in VisIT In-Reply-To: <4C08FE9A.4020209@vt.edu> References: <4C08FE9A.4020209@vt.edu> Message-ID: <1275682653.3131.10.camel@localhost.localdomain> Hi Markus, No, in my understanding that is not possible, since Visit only uses the grid in the *.f0001 file that Nek5000 writes out. If you just want a rough idea of how the mesh is changing, a really poor workaround is to change the name of later files to *.f0001. Cheers, Frank On Fri, 2010-06-04 at 09:24 -0400, nek5000-users at lists.mcs.anl.gov wrote: > Frank, Hank, > > I am interested in visualizing moving meshes in VisIT. From previous > posts, I read that you are working on that. Is it usable yet and how do > I go about it? > > Thanks, > Markus > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Jun 4 15:20:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 Jun 2010 13:20:00 -0700 Subject: [Nek5000-users] Visualizing moving meshes in VisIT In-Reply-To: <1275682653.3131.10.camel@localhost.localdomain> References: <4C08FE9A.4020209@vt.edu> <1275682653.3131.10.camel@localhost.localdomain> Message-ID: Frank- What about Michael's suggestion for when the mesh moves every time slice? (recompiling the plugin) -h On Fri, Jun 4, 2010 at 1:17 PM, wrote: > Hi Markus, > > No, in my understanding that is not possible, since Visit only uses the > grid in the *.f0001 file that Nek5000 writes out. > > If you just want a rough idea of how the mesh is changing, a really poor > workaround is to change the name of later files to *.f0001. > > Cheers, > Frank > > > On Fri, 2010-06-04 at 09:24 -0400, nek5000-users at lists.mcs.anl.gov > wrote: >> Frank, Hank, >> >> I am interested in visualizing moving meshes in VisIT. From previous >> posts, I read that you are working on that. Is it usable yet and how do >> I go about it? >> >> Thanks, >> Markus >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 Jun 4 15:20:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 Jun 2010 15:20:27 -0500 (CDT) Subject: [Nek5000-users] Visualizing moving meshes in VisIT In-Reply-To: <1275682653.3131.10.camel@localhost.localdomain> References: <4C08FE9A.4020209@vt.edu> <1275682653.3131.10.camel@localhost.localdomain> Message-ID: I believe that there is some work being done on this... I can talk with the visit developers next week. Paul On Fri, 4 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Markus, No, in my understanding that is not possible, since Visit only uses the grid in the *.f0001 file that Nek5000 writes out. If you just want a rough idea of how the mesh is changing, a really poor workaround is to change the name of later files to *.f0001. Cheers, Frank On Fri, 2010-06-04 at 09:24 -0400, nek5000-users at lists.mcs.anl.gov wrote: > Frank, Hank, > > I am interested in visualizing moving meshes in VisIT. From previous > posts, I read that you are working on that. Is it usable yet and how do > I go about it? > > Thanks, > Markus > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ 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 Jun 4 15:29:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 Jun 2010 16:29:58 -0400 Subject: [Nek5000-users] RE : Visualizing moving meshes in VisIT In-Reply-To: <5313C3E0D03CB044A289CAC54D804C120157D55BF795@BVMBX1.univ-lyon1.fr> References: <4C08FE9A.4020209@vt.edu> <5313C3E0D03CB044A289CAC54D804C120157D55BF795@BVMBX1.univ-lyon1.fr> Message-ID: <1275683398.4c096246af5a1@webmail.vt.edu> Hi Michael, thanks a lot, that worked well - and just recompiling the plugin (no need to redo the whole program) is pretty fast too. On the long run, it would be nice to have a switch somewhere in the GUI since this Visit installation is also used for bigger, time-varying data, where I guess rereading a non-changing mesh every time step will, as Hank pointed out earlier, slow things down. Thanks again, Markus Quoting nek5000-users at lists.mcs.anl.gov: > Hi Markus, > > I managed to get the moving mesh in VisIt by changing a line in the input > plugin source code. > > You can easily download the source on VisIt website (you can also find some > plugin compilation documentation there) and then recompile the plugin after > having done the following : > > in function GetMesh() change the last line from : > timestepToUseForMesh = 0; > to : > timestepToUseForMesh = ts; > > That works for me with VisIt 1.12.1 > > hth, > > > Michael B > ________________________________________ > De : nek5000-users-bounces at lists.mcs.anl.gov > [nek5000-users-bounces at lists.mcs.anl.gov] de la part de > nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] > Date d'envoi : vendredi 4 juin 2010 15:24 > ? : nek5000-users at lists.mcs.anl.gov > Objet : [Nek5000-users] Visualizing moving meshes in VisIT > > Frank, Hank, > > I am interested in visualizing moving meshes in VisIT. From previous > posts, I read that you are working on that. Is it usable yet and how do > I go about 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 Fri Jun 4 16:04:47 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 Jun 2010 23:04:47 +0200 Subject: [Nek5000-users] Visualizing moving meshes in VisIT In-Reply-To: References: <4C08FE9A.4020209@vt.edu> <1275682653.3131.10.camel@localhost.localdomain> Message-ID: We talked about the moving mesh support some time ago. There are some issues we need to resolve first. I think the changes will make it into the next release of VisIt. Stefan On Jun 4, 2010, at 10:20 PM, nek5000-users at lists.mcs.anl.gov wrote: > > I believe that there is some work being done on this... > I can talk with the visit developers next week. > > Paul > > > On Fri, 4 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Markus, > > No, in my understanding that is not possible, since Visit only uses the > grid in the *.f0001 file that Nek5000 writes out. > > If you just want a rough idea of how the mesh is changing, a really poor > workaround is to change the name of later files to *.f0001. > > Cheers, > Frank > > > On Fri, 2010-06-04 at 09:24 -0400, nek5000-users at lists.mcs.anl.gov > wrote: >> Frank, Hank, >> I am interested in visualizing moving meshes in VisIT. From previous posts, I read that you are working on that. Is it usable yet and how do I go about it? >> Thanks, >> Markus >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 Fri Jun 4 18:24:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 05 Jun 2010 01:24:06 +0200 Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <1504059398.2358031275617605483.JavaMail.root@neo-mail-3> References: <1504059398.2358031275617605483.JavaMail.root@neo-mail-3> Message-ID: <1275693846.3131.34.camel@localhost.localdomain> Hi Michael, Thanks very much for the code. One question concerning the curved sides: if one had a 3D cylindrical pipe grid from Gambit, how would the curvature of the outside (boundary) faces of the grid be set in your code? Cheers, Frank On Thu, 2010-06-03 at 21:13 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > > > Try the attached. > > > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file > > Hello Michael, > > It seems that you sent an email with a *.zip attachment, which due to > a > spam filter, got blocked. If it is renamed to say *.zipp, then it > should get through. > > Cheers, > Frank > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Jun 4 18:42:17 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 Jun 2010 18:42:17 -0500 (CDT) Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <1275693846.3131.34.camel@localhost.localdomain> Message-ID: <637244841.2535851275694937374.JavaMail.root@neo-mail-3> Hi Frank, This is achieved by the step 2 in the list I gave:? You must set the edge nodes from 2 to 3. Alternatively you could set the face from 4 to 8 or the volume from 8 to 20 nodes. The extra nodes that gambit throws because of this are the midpoints.? For Nekton , the recent midside node support feature which fits a parabola through the two corner points and midpoint of the element side is where this comes into play.? So all you need to do is make sure you have set the mesh nodes as above, and the matlab code does the rest. It separates the element's corner nodes from the midpoint nodes. The midpoint nodes are written into the curved side section of the the REA, whereas the corner points are written into the Mesh data section.?So...The matlab code only uses the flag 'm' for curved side data. Also, in the inputs section you can specify a maximum radius for consideration. The code will check each edge's corner and midpoints and determine the radius curvature. If it is too large it considers it a straight edge and moves on. Hope this helps, Michael ----- Original Message ----- From: nek5000-users at lists. mcs . anl .gov To: nek5000-users at lists. mcs . anl .gov Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file Hi Michael, Thanks very much for the code. ?One question concerning the curved sides: if one had a 3D cylindrical pipe grid from Gambit, how would the curvature of the outside (boundary) faces of the grid be set in your code? Cheers, Frank On Thu, 2010-06-03 at 21:13 -0500, nek5000-users at lists. mcs . anl .gov wrote: > Hi Frank, > > ? > > Try the attached. > > ? > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: nek5000-users at lists. mcs . anl .gov > Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file > > Hello Michael, > > It seems that you sent an email with a *.zip attachment, which due to > a > spam filter, got blocked. ?If it is renamed to say *. zipp , then it > should get through. > > Cheers, > Frank > > > -- > Frank Herbert Muldoon , Ph .D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo ( skype ) > http ://tetra.fluid. tuwien .ac.at/ fmuldoo / public_html / webpage /frank-muldoon. html > > _______________________________________________ > 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 -- Frank Herbert Muldoon , Ph .D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo ( skype ) http ://tetra.fluid. tuwien .ac.at/ fmuldoo / public_html / webpage /frank-muldoon. html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists. mcs . anl .gov https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 4 18:51:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 05 Jun 2010 01:51:34 +0200 Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <637244841.2535851275694937374.JavaMail.root@neo-mail-3> References: <637244841.2535851275694937374.JavaMail.root@neo-mail-3> Message-ID: <1275695494.3131.39.camel@localhost.localdomain> Hi Michael, What is the "list" you are referring to? Cheers, Frank On Fri, 2010-06-04 at 18:42 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > > > This is achieved by the step 2 in the list I gave: You must set the > edge nodes from 2 to 3. Alternatively you could set the face from 4 to > 8 or the volume from 8 to 20 nodes. The extra nodes that gambit throws > because of this are the midpoints. For Nekton, the recent midside > node support feature which fits a parabola through the two corner > points and midpoint of the element side is where this comes into > play. > > > > So all you need to do is make sure you have set the mesh nodes as > above, and the matlab code does the rest. It separates the element's > corner nodes from the midpoint nodes. The midpoint nodes are written > into the curved side section of the the REA, whereas the corner points > are written into the Mesh data section. So...The matlab code only uses > the flag 'm' for curved side data. > > > > Also, in the inputs section you can specify a maximum radius for > consideration. The code will check each edge's corner and midpoints > and determine the radius curvature. If it is too large it considers it > a straight edge and moves on. > > > > Hope this helps, > > > > Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > file > > Hi Michael, > > Thanks very much for the code. One question concerning the curved > sides: if one had a 3D cylindrical pipe grid from Gambit, how would > the > curvature of the outside (boundary) faces of the grid be set in your > code? > > Cheers, > Frank > > > On Thu, 2010-06-03 at 21:13 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Hi Frank, > > > > > > > > Try the attached. > > > > > > > > - Michael > > > > > > ----- Original Message ----- > > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > > Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada Central > > Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > file > > > > Hello Michael, > > > > It seems that you sent an email with a *.zip attachment, which due > to > > a > > spam filter, got blocked. If it is renamed to say *.zipp, then it > > should get through. > > > > Cheers, > > Frank > > > > > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > 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 > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Jun 4 18:55:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 Jun 2010 18:55:03 -0500 (CDT) Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <1275695494.3131.39.camel@localhost.localdomain> Message-ID: <197995640.2537201275695703735.JavaMail.root@neo-mail-3> >From the previous email: 1.??? Set Solver type to GENERIC 2.?? When Meshing, make sure the edge node count is 3 (for midpoints).? This should make the face count 8 and the volume count 20 nodes. ????? This setting is necessary to take advantage of Nektons mid side node support. 3.?? Use the zones to label faces as Boundary conditions. Select multiple faces if you like. Since the solver is set to generic, just call the BC anything you like, "Inlet" for example.? The Matlab code will ask you "What did you mean by Inlet", where you would input 'v' for a fortran velocity input.? If it is a thermal problem (TBC = 1 in the inputs in rea_write), it will ask for the momentum and thermal BC.? In gambit, any face that is not labeled with a BC type is assumed to be a Wall. NOTE:?? The Mesh must be HEX & Edge node count 3!...? ONLY works for 3D cases! ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Friday, June 4, 2010 6:51:34 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file Hi Michael, What is the "list" you are referring to? ? Cheers, Frank On Fri, 2010-06-04 at 18:42 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > ? > > This is achieved by the step 2 in the list I gave: ?You must set the > edge nodes from 2 to 3. Alternatively you could set the face from 4 to > 8 or the volume from 8 to 20 nodes. The extra nodes that gambit throws > because of this are the midpoints. ?For Nekton, the recent midside > node support feature which fits a parabola through the two corner > points and midpoint of the element side is where this comes into > play. ? > > ? > > So all you need to do is make sure you have set the mesh nodes as > above, and the matlab code does the rest. It separates the element's > corner nodes from the midpoint nodes. The midpoint nodes are written > into the curved side section of the the REA, whereas the corner points > are written into the Mesh data section. So...The matlab code only uses > the flag 'm' for curved side data. > > ? > > Also, in the inputs section you can specify a maximum radius for > consideration. The code will check each edge's corner and midpoints > and determine the radius curvature. If it is too large it considers it > a straight edge and moves on. > > ? > > Hope this helps, > > ? > > Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > file > > Hi Michael, > > Thanks very much for the code. ?One question concerning the curved > sides: if one had a 3D cylindrical pipe grid from Gambit, how would > the > curvature of the outside (boundary) faces of the grid be set in your > code? > > Cheers, > Frank > > > On Thu, 2010-06-03 at 21:13 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Hi Frank, > > > > ? > > > > Try the attached. > > > > ? > > > > - Michael > > > > > > ----- Original Message ----- > > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > > Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada Central > > Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > file > > > > Hello Michael, > > > > It seems that you sent an email with a *.zip attachment, which due > to > > a > > spam filter, got blocked. ?If it is renamed to say *.zipp, then it > > should get through. > > > > Cheers, > > Frank > > > > > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > 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 > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat Jun 5 11:28:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 05 Jun 2010 18:28:38 +0200 Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <637244841.2535851275694937374.JavaMail.root@neo-mail-3> References: <637244841.2535851275694937374.JavaMail.root@neo-mail-3> Message-ID: <1275755318.3131.47.camel@localhost.localdomain> Hi Michael, I have been running your code and have hit the error below. Unfortunately, I don't ever use Matlab. Cheers, Frank ELEM & PTS MATRIX RESTURCTURE: STARTED **** ??? Index exceeds matrix dimensions. Error in ==> readingNEU2 at 99 ElmF(f+1:f+n1(i),1)=BC1m(f+1:f+n1(i),1); Error in ==> rea_write at 17 [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... >> On Fri, 2010-06-04 at 18:42 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > > > This is achieved by the step 2 in the list I gave: You must set the > edge nodes from 2 to 3. Alternatively you could set the face from 4 to > 8 or the volume from 8 to 20 nodes. The extra nodes that gambit throws > because of this are the midpoints. For Nekton, the recent midside > node support feature which fits a parabola through the two corner > points and midpoint of the element side is where this comes into > play. > > > > So all you need to do is make sure you have set the mesh nodes as > above, and the matlab code does the rest. It separates the element's > corner nodes from the midpoint nodes. The midpoint nodes are written > into the curved side section of the the REA, whereas the corner points > are written into the Mesh data section. So...The matlab code only uses > the flag 'm' for curved side data. > > > > Also, in the inputs section you can specify a maximum radius for > consideration. The code will check each edge's corner and midpoints > and determine the radius curvature. If it is too large it considers it > a straight edge and moves on. > > > > Hope this helps, > > > > Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > file > > Hi Michael, > > Thanks very much for the code. One question concerning the curved > sides: if one had a 3D cylindrical pipe grid from Gambit, how would > the > curvature of the outside (boundary) faces of the grid be set in your > code? > > Cheers, > Frank > > > On Thu, 2010-06-03 at 21:13 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Hi Frank, > > > > > > > > Try the attached. > > > > > > > > - Michael > > > > > > ----- Original Message ----- > > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > > Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada Central > > Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > file > > > > Hello Michael, > > > > It seems that you sent an email with a *.zip attachment, which due > to > > a > > spam filter, got blocked. If it is renamed to say *.zipp, then it > > should get through. > > > > Cheers, > > Frank > > > > > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > 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 > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Sun Jun 6 08:58:01 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 6 Jun 2010 08:58:01 -0500 Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <1275755318.3131.47.camel@localhost.localdomain> References: <637244841.2535851275694937374.JavaMail.root@neo-mail-3> <1275755318.3131.47.camel@localhost.localdomain> Message-ID: <252522FF-EBEA-435A-AE99-A96DAA5F8F8E@neo.tamu.edu> Frank, It is trying to extract information about the boundary conditions from the neu file, there is most likely an error here. Attach the Neu file and I'll have a look - Michael On Jun 5, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Michael, > > I have been running your code and have hit the error below. > Unfortunately, I don't ever use Matlab. > > Cheers, > Frank > > > ELEM & PTS MATRIX RESTURCTURE: STARTED **** > ??? Index exceeds matrix dimensions. > > Error in ==> readingNEU2 at 99 > ElmF(f+1:f+n1(i),1)=BC1m(f+1:f+n1(i),1); > > Error in ==> rea_write at 17 > [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... > >>> > > > > On Fri, 2010-06-04 at 18:42 -0500, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Frank, >> >> >> >> This is achieved by the step 2 in the list I gave: You must set the >> edge nodes from 2 to 3. Alternatively you could set the face from 4 >> to >> 8 or the volume from 8 to 20 nodes. The extra nodes that gambit >> throws >> because of this are the midpoints. For Nekton, the recent midside >> node support feature which fits a parabola through the two corner >> points and midpoint of the element side is where this comes into >> play. >> >> >> >> So all you need to do is make sure you have set the mesh nodes as >> above, and the matlab code does the rest. It separates the element's >> corner nodes from the midpoint nodes. The midpoint nodes are written >> into the curved side section of the the REA, whereas the corner >> points >> are written into the Mesh data section. So...The matlab code only >> uses >> the flag 'm' for curved side data. >> >> >> >> Also, in the inputs section you can specify a maximum radius for >> consideration. The code will check each edge's corner and midpoints >> and determine the radius curvature. If it is too large it considers >> it >> a straight edge and moves on. >> >> >> >> Hope this helps, >> >> >> >> Michael >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada Central >> Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked >> file >> >> Hi Michael, >> >> Thanks very much for the code. One question concerning the curved >> sides: if one had a 3D cylindrical pipe grid from Gambit, how would >> the >> curvature of the outside (boundary) faces of the grid be set in your >> code? >> >> Cheers, >> Frank >> >> >> On Thu, 2010-06-03 at 21:13 -0500, nek5000-users at lists.mcs.anl.gov >> wrote: >>> Hi Frank, >>> >>> >>> >>> Try the attached. >>> >>> >>> >>> - Michael >>> >>> >>> ----- Original Message ----- >>> From: nek5000-users at lists.mcs.anl.gov >>> To: nek5000-users at lists.mcs.anl.gov >>> Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada Central >>> Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked >> file >>> >>> Hello Michael, >>> >>> It seems that you sent an email with a *.zip attachment, which due >> to >>> a >>> spam filter, got blocked. If it is renamed to say *.zipp, then it >>> should get through. >>> >>> Cheers, >>> Frank >>> >>> >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of F >>> luid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> 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 >> -- >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> Technische Universit?t Wien (Technical University of Vienna) >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fl >> uid >> Mechanics and Heat Transfer) >> Resselgasse 3 >> 1040 Wien >> Tel: +4315880132232 >> Fax: +4315880132299 >> Cell:+436765203470 >> fmuldoo (skype) >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >> _______________________________________________ >> 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 > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 Jun 7 00:30:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 07 Jun 2010 07:30:48 +0200 Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <252522FF-EBEA-435A-AE99-A96DAA5F8F8E@neo.tamu.edu> References: <637244841.2535851275694937374.JavaMail.root@neo-mail-3> <1275755318.3131.47.camel@localhost.localdomain> <252522FF-EBEA-435A-AE99-A96DAA5F8F8E@neo.tamu.edu> Message-ID: <1275888648.3131.70.camel@localhost.localdomain> Hi Michael, The mesh is at: http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/GambitToNek/simple.neu Cheers, Frank On Sun, 2010-06-06 at 08:58 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > It is trying to extract information about the boundary conditions from > the neu file, there is most likely an error here. > > Attach the Neu file and I'll have a look > > > - Michael > > On Jun 5, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Michael, > > > > I have been running your code and have hit the error below. > > Unfortunately, I don't ever use Matlab. > > > > Cheers, > > Frank > > > > > > ELEM & PTS MATRIX RESTURCTURE: STARTED **** > > ??? Index exceeds matrix dimensions. > > > > Error in ==> readingNEU2 at 99 > > ElmF(f+1:f+n1(i),1)=BC1m(f+1:f+n1(i),1); > > > > Error in ==> rea_write at 17 > > [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... > > > >>> > > > > > > > > On Fri, 2010-06-04 at 18:42 -0500, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Frank, > >> > >> > >> > >> This is achieved by the step 2 in the list I gave: You must set the > >> edge nodes from 2 to 3. Alternatively you could set the face from 4 > >> to > >> 8 or the volume from 8 to 20 nodes. The extra nodes that gambit > >> throws > >> because of this are the midpoints. For Nekton, the recent midside > >> node support feature which fits a parabola through the two corner > >> points and midpoint of the element side is where this comes into > >> play. > >> > >> > >> > >> So all you need to do is make sure you have set the mesh nodes as > >> above, and the matlab code does the rest. It separates the element's > >> corner nodes from the midpoint nodes. The midpoint nodes are written > >> into the curved side section of the the REA, whereas the corner > >> points > >> are written into the Mesh data section. So...The matlab code only > >> uses > >> the flag 'm' for curved side data. > >> > >> > >> > >> Also, in the inputs section you can specify a maximum radius for > >> consideration. The code will check each edge's corner and midpoints > >> and determine the radius curvature. If it is too large it considers > >> it > >> a straight edge and moves on. > >> > >> > >> > >> Hope this helps, > >> > >> > >> > >> Michael > >> > >> > >> ----- Original Message ----- > >> From: nek5000-users at lists.mcs.anl.gov > >> To: nek5000-users at lists.mcs.anl.gov > >> Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada Central > >> Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > >> file > >> > >> Hi Michael, > >> > >> Thanks very much for the code. One question concerning the curved > >> sides: if one had a 3D cylindrical pipe grid from Gambit, how would > >> the > >> curvature of the outside (boundary) faces of the grid be set in your > >> code? > >> > >> Cheers, > >> Frank > >> > >> > >> On Thu, 2010-06-03 at 21:13 -0500, nek5000-users at lists.mcs.anl.gov > >> wrote: > >>> Hi Frank, > >>> > >>> > >>> > >>> Try the attached. > >>> > >>> > >>> > >>> - Michael > >>> > >>> > >>> ----- Original Message ----- > >>> From: nek5000-users at lists.mcs.anl.gov > >>> To: nek5000-users at lists.mcs.anl.gov > >>> Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada Central > >>> Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > >> file > >>> > >>> Hello Michael, > >>> > >>> It seems that you sent an email with a *.zip attachment, which due > >> to > >>> a > >>> spam filter, got blocked. If it is renamed to say *.zipp, then it > >>> should get through. > >>> > >>> Cheers, > >>> Frank > >>> > >>> > >>> -- > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>> Technische Universit?t Wien (Technical University of Vienna) > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of F > >>> luid > >>> Mechanics and Heat Transfer) > >>> Resselgasse 3 > >>> 1040 Wien > >>> Tel: +4315880132232 > >>> Fax: +4315880132299 > >>> Cell:+436765203470 > >>> fmuldoo (skype) > >>> > >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>> > >>> _______________________________________________ > >>> 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 > >> -- > >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >> Technische Universit?t Wien (Technical University of Vienna) > >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fl > >> uid > >> Mechanics and Heat Transfer) > >> Resselgasse 3 > >> 1040 Wien > >> Tel: +4315880132232 > >> Fax: +4315880132299 > >> Cell:+436765203470 > >> fmuldoo (skype) > >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >> > >> _______________________________________________ > >> 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 > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > 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 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Jun 7 10:39:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 7 Jun 2010 10:39:58 -0500 (CDT) Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <1275888648.3131.70.camel@localhost.localdomain> Message-ID: <277329961.2848671275925198672.JavaMail.root@neo-mail-3> Hi Frank, I think the problem is that you specified two different groups (maybe for a fluid & solid problem?)...at the moment, the matlab program only recognizes 1 fluid group from Gambit. The idea at the moment is to merge a fluid and solid REA using Prex. I don't know if you were trying to do this, but this is the first issue I see: The Number of groups should be 1. Also, For your Boundary Conditions, I see that you have marked an inlet and outlet, but the rest I'm not sure what they are. If they are simply Walls then you don't need to mark them and Gambit will label them as Walls by default. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, June 7, 2010 12:30:48 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file Hi Michael, The mesh is at: http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/GambitToNek/simple.neu Cheers, Frank On Sun, 2010-06-06 at 08:58 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > It is trying to extract information about the boundary conditions from > the neu file, there is most likely an error here. > > Attach the Neu file and I'll have a look > > > - Michael > > On Jun 5, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Michael, > > > > I have been running your code and have hit the error below. > > Unfortunately, I don't ever use Matlab. > > > > Cheers, > > Frank > > > > > > ELEM & PTS MATRIX RESTURCTURE: STARTED **** > > ??? Index exceeds matrix dimensions. > > > > Error in ==> readingNEU2 at 99 > > ElmF(f+1:f+n1(i),1)=BC1m(f+1:f+n1(i),1); > > > > Error in ==> rea_write at 17 > > [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... > > > >>> > > > > > > > > On Fri, 2010-06-04 at 18:42 -0500, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Frank, > >> > >> > >> > >> This is achieved by the step 2 in the list I gave: You must set the > >> edge nodes from 2 to 3. Alternatively you could set the face from 4 > >> to > >> 8 or the volume from 8 to 20 nodes. The extra nodes that gambit > >> throws > >> because of this are the midpoints. For Nekton, the recent midside > >> node support feature which fits a parabola through the two corner > >> points and midpoint of the element side is where this comes into > >> play. > >> > >> > >> > >> So all you need to do is make sure you have set the mesh nodes as > >> above, and the matlab code does the rest. It separates the element's > >> corner nodes from the midpoint nodes. The midpoint nodes are written > >> into the curved side section of the the REA, whereas the corner > >> points > >> are written into the Mesh data section. So...The matlab code only > >> uses > >> the flag 'm' for curved side data. > >> > >> > >> > >> Also, in the inputs section you can specify a maximum radius for > >> consideration. The code will check each edge's corner and midpoints > >> and determine the radius curvature. If it is too large it considers > >> it > >> a straight edge and moves on. > >> > >> > >> > >> Hope this helps, > >> > >> > >> > >> Michael > >> > >> > >> ----- Original Message ----- > >> From: nek5000-users at lists.mcs.anl.gov > >> To: nek5000-users at lists.mcs.anl.gov > >> Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada Central > >> Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > >> file > >> > >> Hi Michael, > >> > >> Thanks very much for the code. One question concerning the curved > >> sides: if one had a 3D cylindrical pipe grid from Gambit, how would > >> the > >> curvature of the outside (boundary) faces of the grid be set in your > >> code? > >> > >> Cheers, > >> Frank > >> > >> > >> On Thu, 2010-06-03 at 21:13 -0500, nek5000-users at lists.mcs.anl.gov > >> wrote: > >>> Hi Frank, > >>> > >>> > >>> > >>> Try the attached. > >>> > >>> > >>> > >>> - Michael > >>> > >>> > >>> ----- Original Message ----- > >>> From: nek5000-users at lists.mcs.anl.gov > >>> To: nek5000-users at lists.mcs.anl.gov > >>> Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada Central > >>> Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > >> file > >>> > >>> Hello Michael, > >>> > >>> It seems that you sent an email with a *.zip attachment, which due > >> to > >>> a > >>> spam filter, got blocked. If it is renamed to say *.zipp, then it > >>> should get through. > >>> > >>> Cheers, > >>> Frank > >>> > >>> > >>> -- > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>> Technische Universit?t Wien (Technical University of Vienna) > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of F > >>> luid > >>> Mechanics and Heat Transfer) > >>> Resselgasse 3 > >>> 1040 Wien > >>> Tel: +4315880132232 > >>> Fax: +4315880132299 > >>> Cell:+436765203470 > >>> fmuldoo (skype) > >>> > >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>> > >>> _______________________________________________ > >>> 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 > >> -- > >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >> Technische Universit?t Wien (Technical University of Vienna) > >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fl > >> uid > >> Mechanics and Heat Transfer) > >> Resselgasse 3 > >> 1040 Wien > >> Tel: +4315880132232 > >> Fax: +4315880132299 > >> Cell:+436765203470 > >> fmuldoo (skype) > >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >> > >> _______________________________________________ > >> 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 > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > 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 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 7 11:51:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 07 Jun 2010 18:51:34 +0200 Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <277329961.2848671275925198672.JavaMail.root@neo-mail-3> References: <277329961.2848671275925198672.JavaMail.root@neo-mail-3> Message-ID: <1275929494.22017.11.camel@localhost.localdomain> Hi Michael, Thanks for looking at it. After removing all boundary conditions except the inlet and outlet and letting Gambit default everything else to walls it runs OK. The original flow problem is two phase with the two phases seperated by a BC named "marangoni_interface". If that is left out, then I assume the boundary is set to "E", i.e., element connectivity. If that is left in, then "Gambit2Nek" gives: ??? Attempted to access FluidBC(0,1); index must be a positive integer or logical. Error in ==> getBC2 at 23 FluidBC(b,1) = Type(i); Error in ==> rea_write at 78 FluidBC = getBC2(ElemConn,ElmF,FaceF,TypeF,Elem1,ElemInfo); Perhaps this is because "Gambit2Nek" cannot deal with an internal BC, i.e., one between what were two phases? Also, it seems that it is not possible to give NEK bc names that have more than 1 character? For example; "ms" and "shl". MOMENTUM NEK BC = ms ??? Subscripted assignment dimension mismatch. Error in ==> readingNEU2 at 85 type1(i) = input('MOMENTUM NEK BC = ','s'); Error in ==> rea_write at 17 [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... Cheers, Frank On Mon, 2010-06-07 at 10:39 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > I think the problem is that you specified two different groups (maybe > for a fluid & solid problem?)...at the moment, the matlab program only > recognizes 1 fluid group from Gambit. The idea at the moment is to > merge a fluid and solid REA using Prex. I don't know if you were > trying to do this, but this is the first issue I see: The Number of > groups should be 1. > > Also, For your Boundary Conditions, I see that you have marked an > inlet and outlet, but the rest I'm not sure what they are. If they are > simply Walls then you don't need to mark them and Gambit will label > them as Walls by default. > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 7, 2010 12:30:48 AM GMT -06:00 Guadalajara / Mexico > City / Monterrey > Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > file > > Hi Michael, > > The mesh is at: > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/GambitToNek/simple.neu > > Cheers, > Frank > > On Sun, 2010-06-06 at 08:58 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Frank, > > > > It is trying to extract information about the boundary conditions > from > > the neu file, there is most likely an error here. > > > > Attach the Neu file and I'll have a look > > > > > > - Michael > > > > On Jun 5, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Hi Michael, > > > > > > I have been running your code and have hit the error below. > > > Unfortunately, I don't ever use Matlab. > > > > > > Cheers, > > > Frank > > > > > > > > > ELEM & PTS MATRIX RESTURCTURE: STARTED **** > > > ??? Index exceeds matrix dimensions. > > > > > > Error in ==> readingNEU2 at 99 > > > ElmF(f+1:f+n1(i),1)=BC1m(f+1:f+n1(i),1); > > > > > > Error in ==> rea_write at 17 > > > [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... > > > > > >>> > > > > > > > > > > > > On Fri, 2010-06-04 at 18:42 -0500, nek5000-users at lists.mcs.anl.gov > > > wrote: > > >> Hi Frank, > > >> > > >> > > >> > > >> This is achieved by the step 2 in the list I gave: You must set > the > > >> edge nodes from 2 to 3. Alternatively you could set the face from > 4 > > >> to > > >> 8 or the volume from 8 to 20 nodes. The extra nodes that gambit > > >> throws > > >> because of this are the midpoints. For Nekton, the recent > midside > > >> node support feature which fits a parabola through the two corner > > >> points and midpoint of the element side is where this comes into > > >> play. > > >> > > >> > > >> > > >> So all you need to do is make sure you have set the mesh nodes as > > >> above, and the matlab code does the rest. It separates the > element's > > >> corner nodes from the midpoint nodes. The midpoint nodes are > written > > >> into the curved side section of the the REA, whereas the corner > > >> points > > >> are written into the Mesh data section. So...The matlab code > only > > >> uses > > >> the flag 'm' for curved side data. > > >> > > >> > > >> > > >> Also, in the inputs section you can specify a maximum radius for > > >> consideration. The code will check each edge's corner and > midpoints > > >> and determine the radius curvature. If it is too large it > considers > > >> it > > >> a straight edge and moves on. > > >> > > >> > > >> > > >> Hope this helps, > > >> > > >> > > >> > > >> Michael > > >> > > >> > > >> ----- Original Message ----- > > >> From: nek5000-users at lists.mcs.anl.gov > > >> To: nek5000-users at lists.mcs.anl.gov > > >> Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada > Central > > >> Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, > blocked > > >> file > > >> > > >> Hi Michael, > > >> > > >> Thanks very much for the code. One question concerning the > curved > > >> sides: if one had a 3D cylindrical pipe grid from Gambit, how > would > > >> the > > >> curvature of the outside (boundary) faces of the grid be set in > your > > >> code? > > >> > > >> Cheers, > > >> Frank > > >> > > >> > > >> On Thu, 2010-06-03 at 21:13 -0500, > nek5000-users at lists.mcs.anl.gov > > >> wrote: > > >>> Hi Frank, > > >>> > > >>> > > >>> > > >>> Try the attached. > > >>> > > >>> > > >>> > > >>> - Michael > > >>> > > >>> > > >>> ----- Original Message ----- > > >>> From: nek5000-users at lists.mcs.anl.gov > > >>> To: nek5000-users at lists.mcs.anl.gov > > >>> Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada > Central > > >>> Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > > >> file > > >>> > > >>> Hello Michael, > > >>> > > >>> It seems that you sent an email with a *.zip attachment, which > due > > >> to > > >>> a > > >>> spam filter, got blocked. If it is renamed to say *.zipp, then > it > > >>> should get through. > > >>> > > >>> Cheers, > > >>> Frank > > >>> > > >>> > > >>> -- > > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > >>> Technische Universit?t Wien (Technical University of Vienna) > > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of F > > >>> luid > > >>> Mechanics and Heat Transfer) > > >>> Resselgasse 3 > > >>> 1040 Wien > > >>> Tel: +4315880132232 > > >>> Fax: +4315880132299 > > >>> Cell:+436765203470 > > >>> fmuldoo (skype) > > >>> > > >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > >>> > > >>> _______________________________________________ > > >>> 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 > > >> -- > > >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > >> Technische Universit?t Wien (Technical University of Vienna) > > >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fl > > >> uid > > >> Mechanics and Heat Transfer) > > >> Resselgasse 3 > > >> 1040 Wien > > >> Tel: +4315880132232 > > >> Fax: +4315880132299 > > >> Cell:+436765203470 > > >> fmuldoo (skype) > > >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > >> > > >> _______________________________________________ > > >> 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 > > > -- > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > Technische Universit?t Wien (Technical University of Vienna) > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of > Fluid > > > Mechanics and Heat Transfer) > > > Resselgasse 3 > > > 1040 Wien > > > Tel: +4315880132232 > > > Fax: +4315880132299 > > > Cell:+436765203470 > > > fmuldoo (skype) > > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > _______________________________________________ > > > 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 > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Jun 7 12:01:20 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 7 Jun 2010 12:01:20 -0500 (CDT) Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <1275929494.22017.11.camel@localhost.localdomain> Message-ID: <1710751754.2870001275930080263.JavaMail.root@neo-mail-3> Hi Frank, Yes at the moment, the 'Gambit2Nek' will not handle an internal BC. And yes, the boundary condition inputs must be a single character. To get around this, you can call it a dummy character and then go back later and change it in the REA file. Markus is doing this for a symmetry boundary condition by calling it 's' and then going back and changing it to sym. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, June 7, 2010 11:51:34 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file Hi Michael, Thanks for looking at it. After removing all boundary conditions except the inlet and outlet and letting Gambit default everything else to walls it runs OK. The original flow problem is two phase with the two phases seperated by a BC named "marangoni_interface". If that is left out, then I assume the boundary is set to "E", i.e., element connectivity. If that is left in, then "Gambit2Nek" gives: ??? Attempted to access FluidBC(0,1); index must be a positive integer or logical. Error in ==> getBC2 at 23 FluidBC(b,1) = Type(i); Error in ==> rea_write at 78 FluidBC = getBC2(ElemConn,ElmF,FaceF,TypeF,Elem1,ElemInfo); Perhaps this is because "Gambit2Nek" cannot deal with an internal BC, i.e., one between what were two phases? Also, it seems that it is not possible to give NEK bc names that have more than 1 character? For example; "ms" and "shl". MOMENTUM NEK BC = ms ??? Subscripted assignment dimension mismatch. Error in ==> readingNEU2 at 85 type1(i) = input('MOMENTUM NEK BC = ','s'); Error in ==> rea_write at 17 [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... Cheers, Frank On Mon, 2010-06-07 at 10:39 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > I think the problem is that you specified two different groups (maybe > for a fluid & solid problem?)...at the moment, the matlab program only > recognizes 1 fluid group from Gambit. The idea at the moment is to > merge a fluid and solid REA using Prex. I don't know if you were > trying to do this, but this is the first issue I see: The Number of > groups should be 1. > > Also, For your Boundary Conditions, I see that you have marked an > inlet and outlet, but the rest I'm not sure what they are. If they are > simply Walls then you don't need to mark them and Gambit will label > them as Walls by default. > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 7, 2010 12:30:48 AM GMT -06:00 Guadalajara / Mexico > City / Monterrey > Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > file > > Hi Michael, > > The mesh is at: > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/GambitToNek/simple.neu > > Cheers, > Frank > > On Sun, 2010-06-06 at 08:58 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Frank, > > > > It is trying to extract information about the boundary conditions > from > > the neu file, there is most likely an error here. > > > > Attach the Neu file and I'll have a look > > > > > > - Michael > > > > On Jun 5, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Hi Michael, > > > > > > I have been running your code and have hit the error below. > > > Unfortunately, I don't ever use Matlab. > > > > > > Cheers, > > > Frank > > > > > > > > > ELEM & PTS MATRIX RESTURCTURE: STARTED **** > > > ??? Index exceeds matrix dimensions. > > > > > > Error in ==> readingNEU2 at 99 > > > ElmF(f+1:f+n1(i),1)=BC1m(f+1:f+n1(i),1); > > > > > > Error in ==> rea_write at 17 > > > [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... > > > > > >>> > > > > > > > > > > > > On Fri, 2010-06-04 at 18:42 -0500, nek5000-users at lists.mcs.anl.gov > > > wrote: > > >> Hi Frank, > > >> > > >> > > >> > > >> This is achieved by the step 2 in the list I gave: You must set > the > > >> edge nodes from 2 to 3. Alternatively you could set the face from > 4 > > >> to > > >> 8 or the volume from 8 to 20 nodes. The extra nodes that gambit > > >> throws > > >> because of this are the midpoints. For Nekton, the recent > midside > > >> node support feature which fits a parabola through the two corner > > >> points and midpoint of the element side is where this comes into > > >> play. > > >> > > >> > > >> > > >> So all you need to do is make sure you have set the mesh nodes as > > >> above, and the matlab code does the rest. It separates the > element's > > >> corner nodes from the midpoint nodes. The midpoint nodes are > written > > >> into the curved side section of the the REA, whereas the corner > > >> points > > >> are written into the Mesh data section. So...The matlab code > only > > >> uses > > >> the flag 'm' for curved side data. > > >> > > >> > > >> > > >> Also, in the inputs section you can specify a maximum radius for > > >> consideration. The code will check each edge's corner and > midpoints > > >> and determine the radius curvature. If it is too large it > considers > > >> it > > >> a straight edge and moves on. > > >> > > >> > > >> > > >> Hope this helps, > > >> > > >> > > >> > > >> Michael > > >> > > >> > > >> ----- Original Message ----- > > >> From: nek5000-users at lists.mcs.anl.gov > > >> To: nek5000-users at lists.mcs.anl.gov > > >> Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada > Central > > >> Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, > blocked > > >> file > > >> > > >> Hi Michael, > > >> > > >> Thanks very much for the code. One question concerning the > curved > > >> sides: if one had a 3D cylindrical pipe grid from Gambit, how > would > > >> the > > >> curvature of the outside (boundary) faces of the grid be set in > your > > >> code? > > >> > > >> Cheers, > > >> Frank > > >> > > >> > > >> On Thu, 2010-06-03 at 21:13 -0500, > nek5000-users at lists.mcs.anl.gov > > >> wrote: > > >>> Hi Frank, > > >>> > > >>> > > >>> > > >>> Try the attached. > > >>> > > >>> > > >>> > > >>> - Michael > > >>> > > >>> > > >>> ----- Original Message ----- > > >>> From: nek5000-users at lists.mcs.anl.gov > > >>> To: nek5000-users at lists.mcs.anl.gov > > >>> Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada > Central > > >>> Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > > >> file > > >>> > > >>> Hello Michael, > > >>> > > >>> It seems that you sent an email with a *.zip attachment, which > due > > >> to > > >>> a > > >>> spam filter, got blocked. If it is renamed to say *.zipp, then > it > > >>> should get through. > > >>> > > >>> Cheers, > > >>> Frank > > >>> > > >>> > > >>> -- > > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > >>> Technische Universit?t Wien (Technical University of Vienna) > > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of F > > >>> luid > > >>> Mechanics and Heat Transfer) > > >>> Resselgasse 3 > > >>> 1040 Wien > > >>> Tel: +4315880132232 > > >>> Fax: +4315880132299 > > >>> Cell:+436765203470 > > >>> fmuldoo (skype) > > >>> > > >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > >>> > > >>> _______________________________________________ > > >>> 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 > > >> -- > > >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > >> Technische Universit?t Wien (Technical University of Vienna) > > >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fl > > >> uid > > >> Mechanics and Heat Transfer) > > >> Resselgasse 3 > > >> 1040 Wien > > >> Tel: +4315880132232 > > >> Fax: +4315880132299 > > >> Cell:+436765203470 > > >> fmuldoo (skype) > > >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > >> > > >> _______________________________________________ > > >> 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 > > > -- > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > Technische Universit?t Wien (Technical University of Vienna) > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of > Fluid > > > Mechanics and Heat Transfer) > > > Resselgasse 3 > > > 1040 Wien > > > Tel: +4315880132232 > > > Fax: +4315880132299 > > > Cell:+436765203470 > > > fmuldoo (skype) > > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > _______________________________________________ > > > 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 > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 7 12:16:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 07 Jun 2010 19:16:58 +0200 Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <1710751754.2870001275930080263.JavaMail.root@neo-mail-3> References: <1710751754.2870001275930080263.JavaMail.root@neo-mail-3> Message-ID: <1275931018.22017.21.camel@localhost.localdomain> Hi Michael, Any chance of Gambit2Nek being able to handle internal boundaries? They arise when using the "msi" boundary which addresses moving boundaries between two fluids. Or perhaps there is a way to change them by hand in the output from Gambit2Nek? Cheers, Frank On Mon, 2010-06-07 at 12:01 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Yes at the moment, the 'Gambit2Nek' will not handle an internal BC. > And yes, the boundary condition inputs must be a single character. To > get around this, you can call it a dummy character and then go back > later and change it in the REA file. Markus is doing this for a > symmetry boundary condition by calling it 's' and then going back and > changing it to sym. > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 7, 2010 11:51:34 AM GMT -06:00 Guadalajara / Mexico > City / Monterrey > Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > file > > Hi Michael, > > Thanks for looking at it. After removing all boundary conditions > except > the inlet and outlet and letting Gambit default everything else to > walls > it runs OK. The original flow problem is two phase with the two > phases > seperated by a BC named "marangoni_interface". If that is left out, > then I assume the boundary is set to "E", i.e., element connectivity. > If that is left in, then "Gambit2Nek" gives: > > ??? Attempted to access FluidBC(0,1); index must be a positive integer > or logical. > > Error in ==> getBC2 at 23 > FluidBC(b,1) = Type(i); > > Error in ==> rea_write at 78 > FluidBC = getBC2(ElemConn,ElmF,FaceF,TypeF,Elem1,ElemInfo); > > > Perhaps this is because "Gambit2Nek" cannot deal with an internal BC, > i.e., one between what were two phases? > > > Also, it seems that it is not possible to give NEK bc names that have > more than 1 character? For example; "ms" and "shl". > > MOMENTUM NEK BC = ms > ??? Subscripted assignment dimension mismatch. > > Error in ==> readingNEU2 at 85 > type1(i) = input('MOMENTUM NEK BC = ','s'); > > Error in ==> rea_write at 17 > [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... > > > Cheers, > Frank > > > > On Mon, 2010-06-07 at 10:39 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Hi Frank, > > > > I think the problem is that you specified two different groups > (maybe > > for a fluid & solid problem?)...at the moment, the matlab program > only > > recognizes 1 fluid group from Gambit. The idea at the moment is to > > merge a fluid and solid REA using Prex. I don't know if you were > > trying to do this, but this is the first issue I see: The Number of > > groups should be 1. > > > > Also, For your Boundary Conditions, I see that you have marked an > > inlet and outlet, but the rest I'm not sure what they are. If they > are > > simply Walls then you don't need to mark them and Gambit will label > > them as Walls by default. > > > > - Michael > > > > ----- Original Message ----- > > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > > Sent: Monday, June 7, 2010 12:30:48 AM GMT -06:00 Guadalajara / > Mexico > > City / Monterrey > > Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > > file > > > > Hi Michael, > > > > The mesh is at: > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/GambitToNek/simple.neu > > > > Cheers, > > Frank > > > > On Sun, 2010-06-06 at 08:58 -0500, nek5000-users at lists.mcs.anl.gov > > wrote: > > > Frank, > > > > > > It is trying to extract information about the boundary conditions > > from > > > the neu file, there is most likely an error here. > > > > > > Attach the Neu file and I'll have a look > > > > > > > > > - Michael > > > > > > On Jun 5, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov > wrote: > > > > > > > Hi Michael, > > > > > > > > I have been running your code and have hit the error below. > > > > Unfortunately, I don't ever use Matlab. > > > > > > > > Cheers, > > > > Frank > > > > > > > > > > > > ELEM & PTS MATRIX RESTURCTURE: STARTED **** > > > > ??? Index exceeds matrix dimensions. > > > > > > > > Error in ==> readingNEU2 at 99 > > > > ElmF(f+1:f+n1(i),1)=BC1m(f+1:f+n1(i),1); > > > > > > > > Error in ==> rea_write at 17 > > > > [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... > > > > > > > >>> > > > > > > > > > > > > > > > > On Fri, 2010-06-04 at 18:42 -0500, > nek5000-users at lists.mcs.anl.gov > > > > wrote: > > > >> Hi Frank, > > > >> > > > >> > > > >> > > > >> This is achieved by the step 2 in the list I gave: You must > set > > the > > > >> edge nodes from 2 to 3. Alternatively you could set the face > from > > 4 > > > >> to > > > >> 8 or the volume from 8 to 20 nodes. The extra nodes that > gambit > > > >> throws > > > >> because of this are the midpoints. For Nekton, the recent > > midside > > > >> node support feature which fits a parabola through the two > corner > > > >> points and midpoint of the element side is where this comes > into > > > >> play. > > > >> > > > >> > > > >> > > > >> So all you need to do is make sure you have set the mesh nodes > as > > > >> above, and the matlab code does the rest. It separates the > > element's > > > >> corner nodes from the midpoint nodes. The midpoint nodes are > > written > > > >> into the curved side section of the the REA, whereas the > corner > > > >> points > > > >> are written into the Mesh data section. So...The matlab code > > only > > > >> uses > > > >> the flag 'm' for curved side data. > > > >> > > > >> > > > >> > > > >> Also, in the inputs section you can specify a maximum radius > for > > > >> consideration. The code will check each edge's corner and > > midpoints > > > >> and determine the radius curvature. If it is too large it > > considers > > > >> it > > > >> a straight edge and moves on. > > > >> > > > >> > > > >> > > > >> Hope this helps, > > > >> > > > >> > > > >> > > > >> Michael > > > >> > > > >> > > > >> ----- Original Message ----- > > > >> From: nek5000-users at lists.mcs.anl.gov > > > >> To: nek5000-users at lists.mcs.anl.gov > > > >> Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada > > Central > > > >> Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, > > blocked > > > >> file > > > >> > > > >> Hi Michael, > > > >> > > > >> Thanks very much for the code. One question concerning the > > curved > > > >> sides: if one had a 3D cylindrical pipe grid from Gambit, how > > would > > > >> the > > > >> curvature of the outside (boundary) faces of the grid be set in > > your > > > >> code? > > > >> > > > >> Cheers, > > > >> Frank > > > >> > > > >> > > > >> On Thu, 2010-06-03 at 21:13 -0500, > > nek5000-users at lists.mcs.anl.gov > > > >> wrote: > > > >>> Hi Frank, > > > >>> > > > >>> > > > >>> > > > >>> Try the attached. > > > >>> > > > >>> > > > >>> > > > >>> - Michael > > > >>> > > > >>> > > > >>> ----- Original Message ----- > > > >>> From: nek5000-users at lists.mcs.anl.gov > > > >>> To: nek5000-users at lists.mcs.anl.gov > > > >>> Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada > > Central > > > >>> Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, > blocked > > > >> file > > > >>> > > > >>> Hello Michael, > > > >>> > > > >>> It seems that you sent an email with a *.zip attachment, which > > due > > > >> to > > > >>> a > > > >>> spam filter, got blocked. If it is renamed to say *.zipp, > then > > it > > > >>> should get through. > > > >>> > > > >>> Cheers, > > > >>> Frank > > > >>> > > > >>> > > > >>> -- > > > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > >>> Technische Universit?t Wien (Technical University of Vienna) > > > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of > F > > > >>> luid > > > >>> Mechanics and Heat Transfer) > > > >>> Resselgasse 3 > > > >>> 1040 Wien > > > >>> Tel: +4315880132232 > > > >>> Fax: +4315880132299 > > > >>> Cell:+436765203470 > > > >>> fmuldoo (skype) > > > >>> > > > >> > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > >>> > > > >>> _______________________________________________ > > > >>> 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 > > > >> -- > > > >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > >> Technische Universit?t Wien (Technical University of Vienna) > > > >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of > Fl > > > >> uid > > > >> Mechanics and Heat Transfer) > > > >> Resselgasse 3 > > > >> 1040 Wien > > > >> Tel: +4315880132232 > > > >> Fax: +4315880132299 > > > >> Cell:+436765203470 > > > >> fmuldoo (skype) > > > >> > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > -- > > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > > Technische Universit?t Wien (Technical University of Vienna) > > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of > > Fluid > > > > Mechanics and Heat Transfer) > > > > Resselgasse 3 > > > > 1040 Wien > > > > Tel: +4315880132232 > > > > Fax: +4315880132299 > > > > Cell:+436765203470 > > > > fmuldoo (skype) > > > > > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > > > _______________________________________________ > > > > 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 > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > 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 > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Jun 7 13:09:31 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 7 Jun 2010 13:09:31 -0500 (CDT) Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file In-Reply-To: <1275931018.22017.21.camel@localhost.localdomain> Message-ID: <345354162.2885291275934171295.JavaMail.root@neo-mail-3> At the moment, I don't have the time to add that ability, so the best bet would be to do it by hand using the output. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, June 7, 2010 12:16:58 PM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked file Hi Michael, Any chance of Gambit2Nek being able to handle internal boundaries? They arise when using the "msi" boundary which addresses moving boundaries between two fluids. Or perhaps there is a way to change them by hand in the output from Gambit2Nek? Cheers, Frank On Mon, 2010-06-07 at 12:01 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Yes at the moment, the 'Gambit2Nek' will not handle an internal BC. > And yes, the boundary condition inputs must be a single character. To > get around this, you can call it a dummy character and then go back > later and change it in the REA file. Markus is doing this for a > symmetry boundary condition by calling it 's' and then going back and > changing it to sym. > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 7, 2010 11:51:34 AM GMT -06:00 Guadalajara / Mexico > City / Monterrey > Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > file > > Hi Michael, > > Thanks for looking at it. After removing all boundary conditions > except > the inlet and outlet and letting Gambit default everything else to > walls > it runs OK. The original flow problem is two phase with the two > phases > seperated by a BC named "marangoni_interface". If that is left out, > then I assume the boundary is set to "E", i.e., element connectivity. > If that is left in, then "Gambit2Nek" gives: > > ??? Attempted to access FluidBC(0,1); index must be a positive integer > or logical. > > Error in ==> getBC2 at 23 > FluidBC(b,1) = Type(i); > > Error in ==> rea_write at 78 > FluidBC = getBC2(ElemConn,ElmF,FaceF,TypeF,Elem1,ElemInfo); > > > Perhaps this is because "Gambit2Nek" cannot deal with an internal BC, > i.e., one between what were two phases? > > > Also, it seems that it is not possible to give NEK bc names that have > more than 1 character? For example; "ms" and "shl". > > MOMENTUM NEK BC = ms > ??? Subscripted assignment dimension mismatch. > > Error in ==> readingNEU2 at 85 > type1(i) = input('MOMENTUM NEK BC = ','s'); > > Error in ==> rea_write at 17 > [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... > > > Cheers, > Frank > > > > On Mon, 2010-06-07 at 10:39 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Hi Frank, > > > > I think the problem is that you specified two different groups > (maybe > > for a fluid & solid problem?)...at the moment, the matlab program > only > > recognizes 1 fluid group from Gambit. The idea at the moment is to > > merge a fluid and solid REA using Prex. I don't know if you were > > trying to do this, but this is the first issue I see: The Number of > > groups should be 1. > > > > Also, For your Boundary Conditions, I see that you have marked an > > inlet and outlet, but the rest I'm not sure what they are. If they > are > > simply Walls then you don't need to mark them and Gambit will label > > them as Walls by default. > > > > - Michael > > > > ----- Original Message ----- > > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > > Sent: Monday, June 7, 2010 12:30:48 AM GMT -06:00 Guadalajara / > Mexico > > City / Monterrey > > Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, blocked > > file > > > > Hi Michael, > > > > The mesh is at: > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/GambitToNek/simple.neu > > > > Cheers, > > Frank > > > > On Sun, 2010-06-06 at 08:58 -0500, nek5000-users at lists.mcs.anl.gov > > wrote: > > > Frank, > > > > > > It is trying to extract information about the boundary conditions > > from > > > the neu file, there is most likely an error here. > > > > > > Attach the Neu file and I'll have a look > > > > > > > > > - Michael > > > > > > On Jun 5, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov > wrote: > > > > > > > Hi Michael, > > > > > > > > I have been running your code and have hit the error below. > > > > Unfortunately, I don't ever use Matlab. > > > > > > > > Cheers, > > > > Frank > > > > > > > > > > > > ELEM & PTS MATRIX RESTURCTURE: STARTED **** > > > > ??? Index exceeds matrix dimensions. > > > > > > > > Error in ==> readingNEU2 at 99 > > > > ElmF(f+1:f+n1(i),1)=BC1m(f+1:f+n1(i),1); > > > > > > > > Error in ==> rea_write at 17 > > > > [Npts,Nelm,Elem,ElemMidPts1,Pts,Elem1,ElmF,... > > > > > > > >>> > > > > > > > > > > > > > > > > On Fri, 2010-06-04 at 18:42 -0500, > nek5000-users at lists.mcs.anl.gov > > > > wrote: > > > >> Hi Frank, > > > >> > > > >> > > > >> > > > >> This is achieved by the step 2 in the list I gave: You must > set > > the > > > >> edge nodes from 2 to 3. Alternatively you could set the face > from > > 4 > > > >> to > > > >> 8 or the volume from 8 to 20 nodes. The extra nodes that > gambit > > > >> throws > > > >> because of this are the midpoints. For Nekton, the recent > > midside > > > >> node support feature which fits a parabola through the two > corner > > > >> points and midpoint of the element side is where this comes > into > > > >> play. > > > >> > > > >> > > > >> > > > >> So all you need to do is make sure you have set the mesh nodes > as > > > >> above, and the matlab code does the rest. It separates the > > element's > > > >> corner nodes from the midpoint nodes. The midpoint nodes are > > written > > > >> into the curved side section of the the REA, whereas the > corner > > > >> points > > > >> are written into the Mesh data section. So...The matlab code > > only > > > >> uses > > > >> the flag 'm' for curved side data. > > > >> > > > >> > > > >> > > > >> Also, in the inputs section you can specify a maximum radius > for > > > >> consideration. The code will check each edge's corner and > > midpoints > > > >> and determine the radius curvature. If it is too large it > > considers > > > >> it > > > >> a straight edge and moves on. > > > >> > > > >> > > > >> > > > >> Hope this helps, > > > >> > > > >> > > > >> > > > >> Michael > > > >> > > > >> > > > >> ----- Original Message ----- > > > >> From: nek5000-users at lists.mcs.anl.gov > > > >> To: nek5000-users at lists.mcs.anl.gov > > > >> Sent: Friday, June 4, 2010 6:24:06 PM GMT -06:00 US/Canada > > Central > > > >> Subject: Re: [Nek5000-users] to Michael--> Nek5000 & Gambit, > > blocked > > > >> file > > > >> > > > >> Hi Michael, > > > >> > > > >> Thanks very much for the code. One question concerning the > > curved > > > >> sides: if one had a 3D cylindrical pipe grid from Gambit, how > > would > > > >> the > > > >> curvature of the outside (boundary) faces of the grid be set in > > your > > > >> code? > > > >> > > > >> Cheers, > > > >> Frank > > > >> > > > >> > > > >> On Thu, 2010-06-03 at 21:13 -0500, > > nek5000-users at lists.mcs.anl.gov > > > >> wrote: > > > >>> Hi Frank, > > > >>> > > > >>> > > > >>> > > > >>> Try the attached. > > > >>> > > > >>> > > > >>> > > > >>> - Michael > > > >>> > > > >>> > > > >>> ----- Original Message ----- > > > >>> From: nek5000-users at lists.mcs.anl.gov > > > >>> To: nek5000-users at lists.mcs.anl.gov > > > >>> Sent: Thursday, June 3, 2010 9:01:14 PM GMT -06:00 US/Canada > > Central > > > >>> Subject: [Nek5000-users] to Michael--> Nek5000 & Gambit, > blocked > > > >> file > > > >>> > > > >>> Hello Michael, > > > >>> > > > >>> It seems that you sent an email with a *.zip attachment, which > > due > > > >> to > > > >>> a > > > >>> spam filter, got blocked. If it is renamed to say *.zipp, > then > > it > > > >>> should get through. > > > >>> > > > >>> Cheers, > > > >>> Frank > > > >>> > > > >>> > > > >>> -- > > > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > >>> Technische Universit?t Wien (Technical University of Vienna) > > > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of > F > > > >>> luid > > > >>> Mechanics and Heat Transfer) > > > >>> Resselgasse 3 > > > >>> 1040 Wien > > > >>> Tel: +4315880132232 > > > >>> Fax: +4315880132299 > > > >>> Cell:+436765203470 > > > >>> fmuldoo (skype) > > > >>> > > > >> > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > >>> > > > >>> _______________________________________________ > > > >>> 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 > > > >> -- > > > >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > >> Technische Universit?t Wien (Technical University of Vienna) > > > >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of > Fl > > > >> uid > > > >> Mechanics and Heat Transfer) > > > >> Resselgasse 3 > > > >> 1040 Wien > > > >> Tel: +4315880132232 > > > >> Fax: +4315880132299 > > > >> Cell:+436765203470 > > > >> fmuldoo (skype) > > > >> > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > -- > > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > > Technische Universit?t Wien (Technical University of Vienna) > > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of > > Fluid > > > > Mechanics and Heat Transfer) > > > > Resselgasse 3 > > > > 1040 Wien > > > > Tel: +4315880132232 > > > > Fax: +4315880132299 > > > > Cell:+436765203470 > > > > fmuldoo (skype) > > > > > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > > > _______________________________________________ > > > > 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 > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > 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 > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > 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 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 8 07:30:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 08 Jun 2010 14:30:04 +0200 Subject: [Nek5000-users] Compute the derivatives In-Reply-To: References: <4C065989.7050602@gmail.com> Message-ID: <4C0E37CC.3060806@gmail.com> Hi all, Thanks for the tip Aleks. Anyway, I have another question. When I visualize the computed derivatives using VisIt or Tecplot, it appears that discontinuities exist at the interfaces between elements. Is that normal or did I screw up something when setting up the calculation ? Thanks, JC PS: Attached is a small portion of my computational domain on which one can clearly see the discontinuities. From nek5000-users at lists.mcs.anl.gov Tue Jun 8 07:43:14 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 8 Jun 2010 14:43:14 +0200 Subject: [Nek5000-users] Compute the derivatives In-Reply-To: <4C0E37CC.3060806@gmail.com> References: <4C065989.7050602@gmail.com> <4C0E37CC.3060806@gmail.com> Message-ID: That's ok! The SEM solution is by construction in C0 but not in C1. Note: The jump in the derivative vanishes if N -> infty. If you want to force the derivative to be in C0 just use dssum(). Hth, Stefan On Jun 8, 2010, at 2:30 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi all, > > Thanks for the tip Aleks. > Anyway, I have another question. When I visualize the computed derivatives using VisIt or Tecplot, it appears that discontinuities exist at the interfaces between elements. > Is that normal or did I screw up something when setting up the calculation ? > > Thanks, > > JC > > PS: Attached is a small portion of my computational domain on which one can clearly see the discontinuities. > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Jun 8 07:43:37 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 8 Jun 2010 07:43:37 -0500 (CDT) Subject: [Nek5000-users] Compute the derivatives In-Reply-To: <4C0E37CC.3060806@gmail.com> References: <4C065989.7050602@gmail.com> <4C0E37CC.3060806@gmail.com> Message-ID: Are you viewing derivatives computed w/ nek, and then dumped and visualized by VisIt? Or are these derivatives computed inside one of the vis packages? (don't know if that's even possible...) If you are well-resolved, derivatives will appear continuous. If you are marginally resolved, they may or may not appear continuous, since the underlying basis is only C0. One option is, say, call gradm1(tx,ty,tz,t) call dsavg(tx) call dsavg(ty) call dsavg(tz) which would project appropriately declared arrays tx,ty,tz into C0 --- it does not always make things look better, but often does. Also, it will make visit happy since Visit expects to visualize C0 fields. hth Paul On Tue, 8 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi all, > > Thanks for the tip Aleks. > Anyway, I have another question. When I visualize the computed derivatives > using VisIt or Tecplot, it appears that discontinuities exist at the > interfaces between elements. > Is that normal or did I screw up something when setting up the calculation ? > > Thanks, > > JC > > PS: Attached is a small portion of my computational domain on which one can > clearly see the discontinuities. > _______________________________________________ > 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 Jun 9 03:06:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 09 Jun 2010 10:06:11 +0200 Subject: [Nek5000-users] Compilation problems Message-ID: <4C0F4B73.7000705@gmail.com> Hi Nek's, First of all, thanks for the tips concerning the computation of derivatives. I have dowloaded the latest repo on my own laptop, and I get some troubles once I computed the code and want to execute it. I compile the code using gcc and gfortran (I do not have any other compilers on my laptop at the moment). Compilation seems to be successful, but as soon as I wanna execute ./nek5000 I get the following message: Number of processors: 1 REAL wdsize : 8 INTEGER wdsize : 4 At line 512 of file /home/jean-christophe/ENSAM/nek5_svn/trunk/nek/drive2.f (unit = 8, file = 'SESSION.NAME') Fortran runtime error: End of file It used to work with the previous version I had, which dated back to early April. Regards, JC PS:Attached is the compiler.out -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: compiler.out URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 9 07:11:10 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 9 Jun 2010 07:11:10 -0500 (CDT) Subject: [Nek5000-users] Compilation problems In-Reply-To: <1130460.536401276085345176.JavaMail.root@zimbra> Message-ID: <21318597.536421276085470749.JavaMail.root@zimbra> Hi JC, use nek* scripts in nek5_svn/trunk/tools/scripts Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, June 9, 2010 3:06:11 AM GMT -06:00 US/Canada Central Subject: [Nek5000-users] Compilation problems Hi Nek's, First of all, thanks for the tips concerning the computation of derivatives. I have dowloaded the latest repo on my own laptop, and I get some troubles once I computed the code and want to execute it. I compile the code using gcc and gfortran (I do not have any other compilers on my laptop at the moment). Compilation seems to be successful, but as soon as I wanna execute ./nek5000 I get the following message: Number of processors: 1 REAL wdsize : 8 INTEGER wdsize : 4 At line 512 of file /home/jean-christophe/ENSAM/nek5_svn/trunk/nek/drive2.f (unit = 8, file = 'SESSION.NAME') Fortran runtime error: End of file It used to work with the previous version I had, which dated back to early April. Regards, JC PS:Attached is the compiler.out _______________________________________________ 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 Jun 10 10:58:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 10 Jun 2010 10:58:03 -0500 Subject: [Nek5000-users] Gradients in an object : Few queries for parallel setting. Message-ID: Hello, I am trying to find gradients and the coordinates of an object in nek. I used set_obj routine to fix my walls as object and also wrote a routine that is similar to the drag_calc routine to dump out the co-ordinates and the gradients on the object. This code works fine for a serial setting while for parallel setting, only a part of the object coordinates are dumped out. I suspect that I have not included a few routines that would gather information from all the processors. It would be great if you could throw in some suggestions that would set it to work in parallel setting. I have pasted a part of the usrchk routine herewith : DIMENSION TEMP1(lz1**2) ! Stores the du/dy of all the GLL points in one face (in the object) parameter(lt=lx1*ly1*lz1) common /scrns/ pm1(lx1,ly1,lz1,lelv) $,vxx(lx1,ly1,lz1,lelv),vxy(lx1,ly1,lz1,lelv),vxz(lx1,ly1,lz1,lelv) $,vyx(lx1,ly1,lz1,lelv),vyy(lx1,ly1,lz1,lelv),vyz(lx1,ly1,lz1,lelv) common /scruz/ $ vzx(lx1,ly1,lz1,lelv),vzy(lx1,ly1,lz1,lelv),vzz(lx1,ly1,lz1,lelv) $,one(lx1,ly1,lz1,lelv) if (istep.eq.0) then call set_obj ! objects for surface integrals endif call izero(TEMP1,lz1**2) ! Initializing to zeros. open(unit=103,file='coord.txt') ! few files for post-processing open(unit=104,file='elenos.txt') CALL DUDXYZ (vxx,vx,RXM1,SXM1,TXM1,JACM1,1,1) CALL DUDXYZ (vxy,vx,RYM1,SYM1,TYM1,JACM1,1,1) CALL DUDXYZ (vxz,vx,RZM1,SZM1,TZM1,JACM1,1,1) ntot1 = nx1*ny1*nz1*nelv call rone (one,ntot1) c------------------------------------------------------------------ DO 100 II=1,NHIS IF (HCODE(10,II).NE.'I') GOTO 100 IOBJ = LOCHIS(1,II) MEMTOT = NMEMBER(IOBJ) IF (HCODE(1,II).NE.' ' .OR. HCODE(2,II).NE.' ' .OR. $ HCODE(3,II).NE.' ' ) THEN IFIELD = 1 DO 50 MEM=1,MEMTOT ISK = 0 IEG = OBJECT(IOBJ,MEM,1) IFC = OBJECT(IOBJ,MEM,2) c IF (GLLNID(IEG).EQ.NID) THEN C This processor has a contribution IE = GLLEL(IEG) write(104,*)ieg,ie,gllnid(ieg),nid call rone (one,ntot1) call dotabf(TEMP1,vxy,one,ifc,ie) ! subroutine that multiplies vxy by one and stores in temp for that element CALL DSSET(NX1,NY1,NZ1) IFACE = EFACE1(IFC) JS1 = SKPDAT(1,IFACE) JF1 = SKPDAT(2,IFACE) JSKIP1 = SKPDAT(3,IFACE) JS2 = SKPDAT(4,IFACE) JF2 = SKPDAT(5,IFACE) JSKIP2 = SKPDAT(6,IFACE) I = 0 DO 110 J2=JS2,JF2,JSKIP2 DO 110 J1=JS1,JF1,JSKIP1 I = I+1 if(istep.eq.2) then write(103,18)xm1(J1,J2,1,ie),ym1(J1,J2,1,ie),zm1(J1,J2,1,ie) $ ,TEMP1(I) 18 format(1x,4(E14.7,1X)) endif 110 CONTINUE c ENDIF 50 CONTINUE If the rea/usr file is needed, please let me know. Thanks. Thanks Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 11 04:00:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 11 Jun 2010 04:00:23 -0500 (CDT) Subject: [Nek5000-users] Gradients in an object : Few queries for parallel setting. In-Reply-To: References: Message-ID: Shriram, I think the following code should work in parallel, though I've not tested it. Note that I was unsure of your desired logic wrt how often you wanted to write the data etc, so you'll need to modify accordingly. Paul common /scrns/ pm1(lx1,ly1,lz1,lelv) $,vxx(lx1,ly1,lz1,lelv),vxy(lx1,ly1,lz1,lelv),vxz(lx1,ly1,lz1,lelv) $,vyx(lx1,ly1,lz1,lelv),vyy(lx1,ly1,lz1,lelv),vyz(lx1,ly1,lz1,lelv) common /scruz/ $ vzx(lx1,ly1,lz1,lelv),vzy(lx1,ly1,lz1,lelv),vzz(lx1,ly1,lz1,lelv) $,temp(4,ly1**2),work(4,ly1**2) if (istep.eq.0) call set_obj ! objects for surface integrals if (nid.eq.0.and.istep.eq.0) then ! ONLY NODE 0 opens file open(unit=103,file='coord.txt') ! few files for post-processing open(unit=104,file='elenos.txt') endif call gradm1 (vxx,vxy,vxz,vx) ! MORE EFFICIENT than dudxyz DO 100 II=1,NHIS IF (HCODE(10,II).NE.'I') GOTO 100 IOBJ = LOCHIS(1,II) MEMTOT = NMEMBER(IOBJ) IF (HCODE(1,II).NE.' ' .OR. HCODE(2,II).NE.' ' .OR. $ HCODE(3,II).NE.' ' ) THEN IFIELD = 1 DO 50 MEM=1,MEMTOT ISK = 0 IEG = OBJECT(IOBJ,MEM,1) IFC = OBJECT(IOBJ,MEM,2) if (nid.eq.0) write(104,*) ieg,gllel(ieg),gllnid(ieg) call rzero(temp,4*ly1*ly1) if (gllnid(ieg).eq.nid) then ! this processor has a contribution ie = gllel(ieg) CALL DSSET(NX1,NY1,NZ1) IFACE = EFACE1(IFC) JS1 = SKPDAT(1,IFACE) JF1 = SKPDAT(2,IFACE) JSKIP1 = SKPDAT(3,IFACE) JS2 = SKPDAT(4,IFACE) JF2 = SKPDAT(5,IFACE) JSKIP2 = SKPDAT(6,IFACE) I = 0 DO 110 J2=JS2,JF2,JSKIP2 DO 110 J1=JS1,JF1,JSKIP1 I = I+1 temp(1,i) = xm1(j1,j2,1,ie) temp(2,i) = xm1(j1,j2,1,ie) temp(3,i) = xm1(j1,j2,1,ie) temp(4,i) = vxy(j1,j2,1,ie) 110 CONTINUE endif call gop(temp,work,'+ ',4*ly1*ly1) ! gather results onto rank 0 if (nid.eq.0) write(103,18) ((temp(k,i),k=1,4),i=1,ly1*ly1) 18 format(1p4e15.7) 50 CONTINUE ENDIF ENDDO On Thu, 10 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I am trying to find gradients and the coordinates of an object in nek. I > used set_obj routine to fix my walls as object and also wrote a routine that > is > similar to the drag_calc routine to dump out the co-ordinates and the > gradients on the object. This code works fine for a serial setting while for > parallel setting, > only a part of the object coordinates are dumped out. I suspect that I have > not included a few routines that would gather information from all the > processors. > It would be great if you could throw in some suggestions that would set it > to work in parallel setting. I have pasted a part of the usrchk routine > herewith : > > > > DIMENSION TEMP1(lz1**2) ! Stores the du/dy of all the GLL points in > one face (in the object) > > parameter(lt=lx1*ly1*lz1) > common /scrns/ pm1(lx1,ly1,lz1,lelv) > $,vxx(lx1,ly1,lz1,lelv),vxy(lx1,ly1,lz1,lelv),vxz(lx1,ly1,lz1,lelv) > $,vyx(lx1,ly1,lz1,lelv),vyy(lx1,ly1,lz1,lelv),vyz(lx1,ly1,lz1,lelv) > common /scruz/ > $ vzx(lx1,ly1,lz1,lelv),vzy(lx1,ly1,lz1,lelv),vzz(lx1,ly1,lz1,lelv) > $,one(lx1,ly1,lz1,lelv) > > if (istep.eq.0) then > call set_obj ! objects for surface integrals > endif > > call izero(TEMP1,lz1**2) ! Initializing to zeros. > > open(unit=103,file='coord.txt') ! few files for post-processing > open(unit=104,file='elenos.txt') > > CALL DUDXYZ (vxx,vx,RXM1,SXM1,TXM1,JACM1,1,1) > CALL DUDXYZ (vxy,vx,RYM1,SYM1,TYM1,JACM1,1,1) > CALL DUDXYZ (vxz,vx,RZM1,SZM1,TZM1,JACM1,1,1) > > ntot1 = nx1*ny1*nz1*nelv > > call rone (one,ntot1) > c------------------------------------------------------------------ > > DO 100 II=1,NHIS > > IF (HCODE(10,II).NE.'I') GOTO 100 > IOBJ = LOCHIS(1,II) > MEMTOT = NMEMBER(IOBJ) > > IF (HCODE(1,II).NE.' ' .OR. HCODE(2,II).NE.' ' .OR. > $ HCODE(3,II).NE.' ' ) THEN > IFIELD = 1 > > DO 50 MEM=1,MEMTOT > ISK = 0 > IEG = OBJECT(IOBJ,MEM,1) > IFC = OBJECT(IOBJ,MEM,2) > c IF (GLLNID(IEG).EQ.NID) THEN > C This processor has a contribution > IE = GLLEL(IEG) > write(104,*)ieg,ie,gllnid(ieg),nid > > call rone (one,ntot1) > call dotabf(TEMP1,vxy,one,ifc,ie) ! subroutine that multiplies vxy by > one and stores in temp for that element > > CALL DSSET(NX1,NY1,NZ1) > IFACE = EFACE1(IFC) > JS1 = SKPDAT(1,IFACE) > JF1 = SKPDAT(2,IFACE) > JSKIP1 = SKPDAT(3,IFACE) > JS2 = SKPDAT(4,IFACE) > JF2 = SKPDAT(5,IFACE) > JSKIP2 = SKPDAT(6,IFACE) > > I = 0 > DO 110 J2=JS2,JF2,JSKIP2 > DO 110 J1=JS1,JF1,JSKIP1 > I = I+1 > if(istep.eq.2) then > write(103,18)xm1(J1,J2,1,ie),ym1(J1,J2,1,ie),zm1(J1,J2,1,ie) > $ ,TEMP1(I) > 18 format(1x,4(E14.7,1X)) > endif > 110 CONTINUE > > c ENDIF > 50 CONTINUE > > > > > If the rea/usr file is needed, please let me know. Thanks. > > Thanks > Shriram > From nek5000-users at lists.mcs.anl.gov Fri Jun 11 11:55:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 11 Jun 2010 11:55:50 -0500 Subject: [Nek5000-users] Gradients in an object : Few queries for parallel setting. In-Reply-To: References: Message-ID: Paul, Thanks for the suggestions. Just a brief description of what I am doing : I am running LES in a turbine passage and this subroutine is to see if the resolution close to the blade is ok. I would be modifying it during production runs. I implemented the changes you mentioned, but I get the following error from usrchk routine : done :: set initial conditions call userchk Signal 15 received. Signal 15 received. . . When I comment the call gop( ) routine the program runs but I have the same problem that only a part of the object is written out. The modified code is pasted below. Thanks for any suggestions. common /scrns/ pm1(lx1,ly1,lz1,lelv) $,vxx(lx1,ly1,lz1,lelv),vxy(lx1,ly1,lz1,lelv),vxz(lx1,ly1,lz1,lelv) $,vyx(lx1,ly1,lz1,lelv),vyy(lx1,ly1,lz1,lelv),vyz(lx1,ly1,lz1,lelv) common /scruz/ $ vzx(lx1,ly1,lz1,lelv),vzy(lx1,ly1,lz1,lelv),vzz(lx1,ly1,lz1,lelv) $,temp(4,ly1**2),work(4,ly1**2) if (istep.eq.0) call set_obj ! obj for surface integrals. if (nid.eq.0.and. istep.eq.0) then ! ONLY NODE 0 opens file open(unit=103,file='coord.txt') open(unit=104,file='elenos.txt') endif call gradm1(vxx,vxy,vxz,vx) DO 100 II=1,NHIS IF (HCODE(10,II).NE.'I') GOTO 100 IOBJ = LOCHIS(1,II) MEMTOT = NMEMBER(IOBJ) IF (HCODE(1,II).NE.' ' .OR. HCODE(2,II).NE.' ' .OR. $ HCODE(3,II).NE.' ' ) THEN IFIELD = 1 DO 50 MEM=1,MEMTOT ISK = 0 IEG = OBJECT(IOBJ,MEM,1) IFC = OBJECT(IOBJ,MEM,2) if (nid.eq.0) write(104,*) ieg,gllel(ieg),gllnid(ieg) call rzero(temp,4*ly1*ly1) IF (gllnid(ieg).eq.nid) then ! this processor has a contribution ie = gllel(ieg) CALL DSSET(NX1,NY1,NZ1) IFACE = EFACE1(IFC) JS1 = SKPDAT(1,IFACE) JF1 = SKPDAT(2,IFACE) JSKIP1 = SKPDAT(3,IFACE) JS2 = SKPDAT(4,IFACE) JF2 = SKPDAT(5,IFACE) JSKIP2 = SKPDAT(6,IFACE) I = 0 DO 110 J2=JS2,JF2,JSKIP2 DO 110 J1=JS1,JF1,JSKIP1 I = I+1 temp(1,i) = xm1(j1,j2,1,ie) temp(2,i) = ym1(j1,j2,1,ie) temp(3,i) = zm1(j1,j2,1,ie) temp(4,i) = vxy(j1,j2,1,ie) 110 CONTINUE ENDIF call gop(temp,work,'+ ',4*ly1*ly1) ! gather results onto rank 0 IF (nid.eq.0) write(103,18) ((temp(k,i),k=1,4),i=1,ly1*ly1) 18 format(1p4e15.7) 50 CONTINUE ENDIF 100 CONTINUE Regards Shriram Jagannathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 11 14:16:07 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 11 Jun 2010 15:16:07 -0400 Subject: [Nek5000-users] genmap In-Reply-To: References: Message-ID: Hi Stephan, I just noticed that this thread is still open. Does the output of my 'ulimit -a' make it clear to you why increasing lelm from 500,000 to 3,000,000 caused genmap to stop working for me? If so, is it clear a priori what the maximum lelm on my system could be? Thanks a lot, David On Wed, May 26, 2010 at 1:17 PM, David Goluskin wrote: > Hi Stephan, > > Here is the output of 'ulimit -a'. Do you need any other info? I'm on a > SiCortex 1458. > > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 4089 > max locked memory (kbytes, -l) 64000 > max memory size (kbytes, -m) unlimited > open files (-n) 8192 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 4089 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > > Thanks, > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 11 15:32:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 11 Jun 2010 15:32:25 -0500 (CDT) Subject: [Nek5000-users] nek on new setup (fwd) Message-ID: Hi Mike, I'm fwd'g to the nek5000 users list (are you on this?). I think Aleks can answer the question about axisymmetry + meridional velocity. Paul ---------- Forwarded message ---------- Date: Fri, 11 Jun 2010 09:02:02 -0700 From: Michael Sprague To: Paul Fischer Subject: Re: nek on new setup Paul, Those are both helpful comments regarding makenek.inc. Both are due to early misconfigured mpicc/mpif77. I'm now using the distributed makenek.inc and have changed lelt. Compilation seems to go fine. Unfortunately, I'm still seeing the same problem. I'm confident the problem is in our system. I'll keep working with our cluster-guy to try and figure out the problem. On an unrelated note, is there anything special that needs to be done for a 2D axisymmetric problem where temperature is used to represent the meridional velocity? In the old version, I made a manual change to one of the .f routines. I'm guess that is all "automated" in the present version, but I wanted to make sure. Thanks. --Mike On Jun 11, 2010, at 1:03 AM, Paul Fischer wrote: > > Hi Mike, > > One think I noticed is that you had lelt=1000 in your SIZE > file, which is rather large for 3D. > > I would guess that the executable was then looking for about > 2GB memory/core -- do you have that much memory per core? > > In my case I reduced it to 130, implying minimum number > of processors = 8. > > Paul > > > > On Thu, 10 Jun 2010, Michael Sprague wrote: > >> Paul, >> >> Great! I appreciate it! The files are in the attached zip file; I also >> included the file 901.out, which is the output from my last run which >> choked. >> >> I'm using mpif77/mpicc built from pgf77/pgcc; the makenek.inc gave me a >> little guff in that it said it couldn't detecet a compiler, so I specified >> the flags in P and switched NOCOMPILE as shown below: >> >> *) echo "ERROR: Unable to detect compiler!" >> echo " - don't know how to promote datatype REAL to 8 bytes" >> echo " - don't know how to invoke the C pre-processor (CPP) before >> compilation" >> echo " Please edit the makefile and specify the requested compiler >> flags using the P variable." >> echo "" >> P="-r8 -Mpreprocess" >> NOCOMPILE=0 >> read;; >> >> After that compilation seemed to go fine. I've attached makenek.inc as >> well. >> >> --Mike From nek5000-users at lists.mcs.anl.gov Fri Jun 11 17:21:35 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 11 Jun 2010 17:21:35 -0500 (CDT) Subject: [Nek5000-users] nek on new setup (fwd) In-Reply-To: Message-ID: <1372595.645351276294895239.JavaMail.root@zimbra> Hi Mike, In the current repo version of conduct.f, the default for the array t(1,1,1,1,1) in axisymmetric case (ifaxis=.true.) is a scalar (isd=1). Only in MHD axisymmetric cases it is treated as a vector component -- meridional velocity in axisymmetric flow w/ a swirl : conduct.f:55 isd = 1 if (ifaxis.and.ifmhd) isd = 2 !This is a problem if T is to be T! So for your problem, you still need to modify this file and set isd=2 if ifaxis=.true. irrespective of ifmhd but watch out if you decide to add a real temperature/passive scalar later :) We hope we will have a better solution for it it some point. Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: users at nek5000.mcs.anl.gov Sent: Friday, June 11, 2010 3:32:25 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] nek on new setup (fwd) Hi Mike, I'm fwd'g to the nek5000 users list (are you on this?). I think Aleks can answer the question about axisymmetry + meridional velocity. Paul ---------- Forwarded message ---------- On an unrelated note, is there anything special that needs to be done for a 2D axisymmetric problem where temperature is used to represent the meridional velocity? In the old version, I made a manual change to one of the .f routines. I'm guess that is all "automated" in the present version, but I wanted to make sure. Thanks. --Mike From nek5000-users at lists.mcs.anl.gov Sun Jun 13 06:19:28 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 13 Jun 2010 13:19:28 +0200 Subject: [Nek5000-users] genmap In-Reply-To: References: Message-ID: <5530432C-E00D-421F-A413-C367DAA44F6C@lav.mavt.ethz.ch> Hi David, I guess you need to lower the memory footprint of GENMAP because you don't have enough memory available. Try to change the parameter 'lelm' in tools/genmap/SIZE and recompile GENMAP. Stefan On May 26, 2010, at 7:17 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stephan, > > Here is the output of 'ulimit -a'. Do you need any other info? I'm on a SiCortex 1458. > > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 4089 > max locked memory (kbytes, -l) 64000 > max memory size (kbytes, -m) unlimited > open files (-n) 8192 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 4089 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > > Thanks, > > 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 Tue Jun 15 08:47:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 15 Jun 2010 15:47:58 +0200 Subject: [Nek5000-users] Residuals Message-ID: <4C17848E.9020703@gmail.com> Hi Nek's, I have a question concerning residuals. I wanna run a calculation that yields to a stationnary flow. In order to be sure that my calculation has converged, I'd like to see the residuals. How/where could I output them ? Regards, JC From nek5000-users at lists.mcs.anl.gov Tue Jun 15 09:41:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 15 Jun 2010 09:41:48 -0500 (CDT) Subject: [Nek5000-users] Residuals In-Reply-To: <4C17848E.9020703@gmail.com> References: <4C17848E.9020703@gmail.com> Message-ID: JC, Given that (v,u_t) = (v,r), where r is the residual, I would assume that you can get the desired residual estimate by looking at u_t := du/dt ~= || u^n - u^n-1 || / dt ? Typically, I would do this in userchk, creating a set of variables in a common block, e.g. parameter (lt=lx1*ly1*lz1*lelt) common /vold/ uo(lt),vo(lt),wo(lt) real linf,l2,h1,semi n = nx1*ny1*nz1*nz1*nelv if (istep.gt.0) then call opsub2 (uo,vo,wo,vx,vy,vz) call normvc (h1,semi,l2,linf,uo,vo,wo) if (nid.eq.0) write(6,1) istep,time,h1,semi,l2,linf 1 format(i8,1p5e13.6,' resnorm') endif call opcopy (uo,vo,wo,vx,vy,vz) ! Save current velocity Then "grep resnorm logfile > t.t" would put the time history of this quantity into the file t.t, assuming your stdout is directed to logfile. Paul On Tue, 15 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > I have a question concerning residuals. > I wanna run a calculation that yields to a stationnary flow. In order to be > sure that my calculation has converged, I'd like to see the residuals. > How/where could I output them ? > > Regards, > JC > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > uuuu bdry.f: SUBROUTINE SETLOG bdry.f:C Subroutine to initialize logical flags bdry.f: SUBROUTINE SETRZER bdry.f: SUBROUTINE CHKNORD (IFALGN,IFNORX,IFNORY,IFNORZ,IFC,IEL) bdry.f: SUBROUTINE CHKAXCB bdry.f: SUBROUTINE CHKCBC (CB,IEL,IFC,IFALGN) bdry.f: SUBROUTINE BCMASK bdry.f: SUBROUTINE BCDIRVC(V1,V2,V3,mask1,mask2,mask3) bdry.f: SUBROUTINE BCDIRSC(S) bdry.f: SUBROUTINE BCNEUSC(S,ITYPE) bdry.f: SUBROUTINE FACEIS (CB,S,IEL,IFACE,NX,NY,NZ) bdry.f: SUBROUTINE FACEIV (CB,V1,V2,V3,IEL,IFACE,NX,NY,NZ) bdry.f: SUBROUTINE NEKASGN (IX,IY,IZ,IEL) bdry.f: SUBROUTINE BCNEUTR bdry.f: SUBROUTINE TRCON (TRX,TRY,TRZ,TR1,TR2,TR3,IEL,IFC) bdry.f: SUBROUTINE TRST2D (TRX,TRY,SIGST,IEL,IFC) bdry.f: SUBROUTINE TRSTAX (TRX,TRY,SIGST,IEL,IFC) bdry.f: SUBROUTINE CTANG2D (CANG,SANG,IXN,IYN,IAN,IFC,IEL) bdry.f: SUBROUTINE TRST3D (TRX,TRY,TRZ,SIGST,IEL,IFC) bdry.f: SUBROUTINE SETDRS (DRM1,DRTM1,DSM1,DSTM1,IFC) bdry.f: SUBROUTINE GLOBROT (R1,R2,R3,IEL,IFC) bdry.f: SUBROUTINE FACEC2 (A1,A2,B1,B2,IFC) bdry.f: SUBROUTINE LFALSE (IFA,N) bdry.f: SUBROUTINE RZERO3 (A,B,C,N) bdry.f: SUBROUTINE UNITVEC (X,Y,Z,N) bdry.f: SUBROUTINE SETSHL bdry.f: SUBROUTINE CHKZVN (VMAX,IEL,IFC,IVNORL) bdry.f: SUBROUTINE BCTWALL (TMP1,TMP2,TMP3) bdry.f: SUBROUTINE ANTIMSK1(X,XMASK,N) bdry.f: subroutine check_cyclic ! check for cyclic bcs byte_mpi.f: subroutine byte_open_mpi(fname) byte_mpi.f: subroutine byte_read_mpi(buf,icount,iorank) byte_mpi.f: subroutine byte_write_mpi(buf,icount,iorank) byte_mpi.f: subroutine byte_close_mpi byte_mpi.f: subroutine byte_set_view(ioff_in) byte_mpi.f: subroutine nek_comm_io(nn) calcz.f: subroutine calcz(d,e,n,dmax,dmin,z,ierr) calcz.f: subroutine ident(a,n) coef.f: subroutine genwz coef.f: subroutine geom1 (xm3,ym3,zm3) coef.f: subroutine glmapm3 (xm3,ym3,zm3) coef.f: subroutine glmapm1 coef.f:C Note: Subroutines GLMAPM1, GEODAT1, AREA2, SETWGTR and AREA3 coef.f: subroutine geodat1 coef.f:C Note: Subroutines GLMAPM1, GEODAT1, AREA2, SETWGTR and AREA3 coef.f: subroutine geom2 coef.f: subroutine xyzrst (xrm1,yrm1,zrm1,xsm1,ysm1,zsm1, coef.f: subroutine chkjac(jac,n,iel,X,Y,Z,ND,IERR) coef.f: subroutine volume coef.f: subroutine setarea coef.f: subroutine area2 coef.f:C Note: Subroutines GLMAPM1, GEODAT1, AREA2, SETWGTR and AREA3 coef.f: subroutine setwgtr (wgtr1,wgtr2,wgtr3,wgtr4) coef.f:C Note: Subroutines GLMAPM1, GEODAT1, AREA2, SETWGTR and AREA3 coef.f: subroutine area3 coef.f:C Note: Subroutines GLMAPM1, GEODAT1, AREA2, SETWGTR and AREA3 coef.f: subroutine lagmass coef.f: subroutine setinvm coef.f: subroutine maprs(y,x,xa,nrest,iel) coef.f: subroutine map31 (y,x,iel) coef.f: subroutine map13 (y,x,iel) coef.f: subroutine map12 (y,x,iel) coef.f: subroutine map21t (y,x,iel) coef.f: subroutine map21e (y,x,iel) coef.f: subroutine out_xyz_el(x,y,z,e) coef.f: subroutine out_fld_el(x,e,c2) coef.f: subroutine outxm3j(xm3,ym3,jm3) coef.f: SUBROUTINE INVMT(A,B,AA,N) coef.f: SUBROUTINE LUBKSB(A,N,NP,INDX,B) coef.f: SUBROUTINE LUDCMP(A,N,NP,INDX,D) comm_mpi.f: subroutine iniproc comm_mpi.f: subroutine init_nek_comm comm_mpi.f: subroutine gop( x, w, op, n) comm_mpi.f: subroutine igop( x, w, op, n) comm_mpi.f: subroutine i8gop( x, w, op, n) comm_mpi.f: subroutine csend(mtype,buf,len,jnid,jpid) comm_mpi.f: subroutine crecv(mtype,buf,lenm) comm_mpi.f: subroutine crecv3(mtype,buf,len,lenm) comm_mpi.f: subroutine lbcast(ifif) comm_mpi.f: subroutine bcast(buf,len) comm_mpi.f: subroutine create_comm(icomm) comm_mpi.f: subroutine msgwait(imsg) comm_mpi.f: subroutine gsync() comm_mpi.f: subroutine exitti(stringi,idata) comm_mpi.f: subroutine err_chk(ierr,string) comm_mpi.f: subroutine exitt comm_mpi.f: subroutine printHeader conduct.f: subroutine cdscal (igeom) conduct.f: subroutine makeuq conduct.f: subroutine setqvol(bql) conduct.f: subroutine nekuq (bql,iel) conduct.f: subroutine convab conduct.f: subroutine makeabq conduct.f: subroutine makebdq conduct.f: subroutine convch_old conduct.f: subroutine thyprk (tch,ilag) conduct.f: subroutine thypab (tch,ilag) conduct.f: subroutine hypmsk1 (htmask) conduct.f: subroutine tchinit (tch,ilag) conduct.f: subroutine lagscal conduct.f: subroutine outfldrq (x,txt10,ichk) conduct.f: subroutine cdscal_expl (igeom) conduct.f: subroutine diffab ! explicit treatment of diffusion operator connect1.f: subroutine setup_topo connect1.f: subroutine initds connect1.f: subroutine setedge connect1.f: subroutine dsset(nx,ny,nz) connect1.f: subroutine genxyzl connect1.f: subroutine verify connect1.f: subroutine setside connect1.f: subroutine verrhe connect1.f: subroutine facind (kx1,kx2,ky1,ky2,kz1,kz2,nx,ny,nz,iface) connect1.f: subroutine facindr (kx1,kx2,ky1,ky2,kz1,kz2,nx,ny,nz,iface) connect1.f: subroutine facev(a,ie,iface,val,nx,ny,nz) connect1.f: subroutine ifacev(a,ie,iface,val,nx,ny,nz) connect1.f: subroutine facec(a,b,ie,iface,nx,ny,nz,nel) connect1.f: subroutine combin2(glnm1,glnm2,nglob) connect1.f: subroutine outfldio (x,txt10) connect1.f: subroutine outfldi (x,txt10) connect1.f: subroutine outfldr (x,txt10) connect1.f: subroutine checkit(idum) connect1.f: subroutine outfldro (x,txt10,ichk) connect1.f: subroutine outfldrp (x,txt10,ichk) connect1.f: subroutine outmatp(a,m,n,name6,ie) connect1.f: subroutine gs_chkr(glo_num) connect1.f: subroutine gs_counter(glo_num,gsh_std) connect1.f: subroutine gs_new_tstr(glo_num,x,c,gsh_std) connect1.f: subroutine xfill(x,c,n) connect1.f: subroutine setup_mesh_dssum ! Set up dssum for mesh connect2.f: subroutine readat connect2.f: subroutine rdparam connect2.f: subroutine rdmesh connect2.f: subroutine rdcurve connect2.f: subroutine rdbdry connect2.f: subroutine rdicdf connect2.f: subroutine rdmatp connect2.f: subroutine rdhist connect2.f: subroutine rdout connect2.f: subroutine rdobj connect2.f: subroutine vrdsmsh connect2.f: subroutine vrdsmshx ! verify mesh topology connect2.f: subroutine rotat2(xyz,angle,npts) connect2.f: subroutine scale(xyzl,nl) connect2.f: subroutine inrtia(xyzi,cg,xyzl,n,itype) connect2.f: subroutine volume2(vol,xyz,n) connect2.f: subroutine findcg(cg,xyz,n) connect2.f: subroutine divide(list1,list2,nl1,nl2,ifok,list,nl,xyzi,cg,WGT) connect2.f: subroutine bin_rd1(ifbswap) ! read mesh, curve, and bc info connect2.f: subroutine buf_to_xyz(buf,e,ifbswap) ! version 1 of binary reader connect2.f: subroutine buf_to_curve(buf) ! version 1 of binary reader connect2.f: subroutine buf_to_bc(cbl,bl,buf) ! version 1 of binary reader connect2.f: subroutine bin_rd1_mesh(ifbswap) ! version 1 of binary reader connect2.f: subroutine bin_rd1_curve (ifbswap) ! v. 1 of curve side reader connect2.f: subroutine bin_rd1_bc (cbl,bl,ifbswap) ! v. 1 of bc reader connect2.f: subroutine buf_close_outv ! this is the stupid O(P) formulation connect2.f: subroutine buf_close_out ! this is the stupid O(P) formulation connect2.f: subroutine open_bin_file(ifbswap) ! open file & chk for byteswap connect2.f: subroutine chk_xyz connect2.f: subroutine chk_nel connect2.f: subroutine cscan(sout,key,nk) convect.f: subroutine setup_convect(igeom) convect.f: subroutine char_conv(p0,u,ulag,msk,c,cs,gsl) convect.f: subroutine char_conv1 convect.f: subroutine int_vel(c_t,t0,c,n,nc,ct,nid) convect.f: subroutine conv_rhs (du,u,c,bmsk,gsl) convect.f: subroutine convop_fst_3d(du,u,c,mx,md,nel) convect.f: subroutine convop_fst_2d(du,u,c,mx,md,nel) convect.f: subroutine grad_rstd(ur,us,ut,u,mx,md,if3d,ju) convect.f: subroutine intp_rstd(ju,u,mx,md,if3d,idir) convect.f: subroutine gen_int(jgl,jgt,mp,np,w) convect.f: subroutine gen_dgl(dgl,dgt,mp,np,w) convect.f: subroutine lim_chk(n,m,avar5,lvar5,sub_name10) convect.f: subroutine get_int_ptr (ip,mx,md) convect.f: subroutine get_dgl_ptr (ip,mx,md) convect.f: subroutine set_conv_char(ct,c,ux,uy,uz,nelc,tau,ifnew) convect.f: subroutine set_ct_cvx(ct,c,m,u,v,w,tau,nc,mc,nelc,ifnew) convect.f: subroutine grad_rst(ur,us,ut,u,md,if3d) convect.f: subroutine convect_new(bdu,u,ifuf,cx,cy,cz,ifcf) convect.f: subroutine convect_cons(bdu,u,ifuf,cx,cy,cz,ifcf) convect.f: subroutine set_convect_cons(cx,cy,cz,ux,uy,uz) convect.f: subroutine set_convect_new(cr,cs,ct,ux,uy,uz) convect.f: subroutine set_char_mask(mask,u,v,w) ! mask for hyperbolic system convect.f: subroutine advchar convect.f: subroutine convch convect.f: subroutine convop_cons_3d(du,u,c,mx,md,nel) ! Conservation form convect.f: subroutine convop_cons_2d(du,u,c,mx,md,nel) ! Conservation form cvode_aux.f: subroutine add_fcvfun_usr(ydot) cvode_aux.f: subroutine cv_unpack_sol(y) cvode_aux.f: subroutine cv_pack_sol(y) cvode_driver.f: subroutine cv_setsize(n_in,nfld_last) cvode_driver.f: subroutine cv_init cvode_driver.f: subroutine cdscal_cvode(igeom) cvode_driver.f: subroutine cv_setsize(n_in,nfld_last) cvode_driver.f: subroutine cv_init cvode_driver.f: subroutine cdscal_cvode(igeom) cvode_driver.f: SUBROUTINE FCVJTIMES (V,FJV,TT,Y,FY,H,IPAR,RPAR,WORK,IER) cvode_driver.f: subroutine store_vel(vx_,vy_,vz_) cvode_driver.f: subroutine set_vel(vx_,vy_,vz_) cvode_driver.f: subroutine update_vel(time_) cvode_driver.f: subroutine fcvfun (cv_time, y, ydot, ipar, rpar, ier) drive1.f: subroutine nek_init drive1.f: subroutine nek_solve drive1.f: subroutine nek_advance drive1.f: subroutine nek_end drive2.f: subroutine initdim drive2.f: subroutine initdat drive2.f: subroutine comment drive2.f: subroutine setvar drive2.f: subroutine echopar drive2.f: subroutine gengeom (igeom) drive2.f: subroutine files drive2.f: subroutine settime drive2.f: subroutine geneig (igeom) drive2.f: subroutine fluid (igeom) drive2.f: subroutine heat (igeom) drive2.f: subroutine meshv (igeom) drive2.f: subroutine rescont (ind) drive2.f: subroutine rstartc (ind) drive2.f: subroutine time00 drive2.f: subroutine runstat drive2.f: subroutine pprint_all(s,n_in,io) drive2.f: subroutine opcount(ICALL) drive2.f: subroutine dofcnt drive2.f: subroutine vol_flow drive2.f: subroutine compute_vol_soln(vxc,vyc,vzc,prc) drive2.f: subroutine plan2_vol(vxc,vyc,vzc,prc) drive2.f: subroutine plan3_vol(vxc,vyc,vzc,prc) drive2.f: subroutine a_dmp drive2.f: subroutine outrio (v,n,io) drive2.f: subroutine reset_prop dssum.f: subroutine setupds(gs_handle,nx,ny,nz,nel,melg,vertex,glo_num) dssum.f: subroutine dssum(u,nx,ny,nz) dssum.f: subroutine dsop(u,op,nx,ny,nz) dssum.f: subroutine vec_dssum(u,v,w,nx,ny,nz) dssum.f: subroutine vec_dsop(u,v,w,nx,ny,nz,op) dssum.f: subroutine nvec_dssum(u,stride,n,gs_handle) dssum.f: subroutine matvec3(uout,Jmat,uin,iftrsp,n1,n2) dssum.f: subroutine matvec3t(uout,Jmat,uin,iftrsp,n1,n2) dssum.f: subroutine matvect (out,d,vec,n1,n2) dssum.f:c subroutine opq_in_place(a,b,c) dssum.f: subroutine vectof_add(b,a,ie,iface,nx,ny,nz) dssum.f: subroutine zero_f(b,ie,iface,nx,ny,nz) dssum.f: subroutine ftovec_0(a,b,ie,iface,nx,ny,nz) dssum.f: subroutine ftovec(a,b,ie,iface,nx,ny,nz) dssum.f: subroutine vectof(b,a,ie,iface,nx,ny,nz) dssum.f: subroutine ftoveci(a,b,ie,iface,nx,ny,nz) dssum.f: subroutine vectofi(b,a,ie,iface,nx,ny,nz) dssum.f: subroutine apply_Jt(u,nx,ny,nz,nel) dssum.f: subroutine apply_J(u,nx,ny,nz,nel) dssum.f: subroutine h1_proj(u,nx,ny,nz) dssum.f: subroutine dssum_msk(u,mask,nx,ny,nz) dssum.f: subroutine dssum_msk2(u,mask,binv,nx,ny,nz) eigsolv.f: SUBROUTINE ESTEIG eigsolv.f: SUBROUTINE EIGENV eigsolv.f: SUBROUTINE ALPHAM1 (ALPHA,MASK,MULT,H1,H2,ISD) eigsolv.f: SUBROUTINE GAMMAM1 (GAMMA,MASK,MULT,H1,H2,ISD) eigsolv.f: SUBROUTINE ALPHAM2 (ALPHA,H1,H2,H2INV,INLOC) eigsolv.f: SUBROUTINE GAMMAM2 (GAMMA,H1,H2,H2INV,INLOC) eigsolv.f: SUBROUTINE STARTX1 (X1,Y1,MASK,MULT,NEL) eigsolv.f: SUBROUTINE STARTX2 (X2,Y2) fast3d.f: subroutine gen_fast(x,y,z) fast3d.f: subroutine plane_space_std(lr,ls,lt,i1,i2,w,x,y,z,nx,nxn,nz0,nzn) fast3d.f: subroutine plane_space(lr,ls,lt,i1,i2,w,x,y,z,nx,nxn,nz0,nzn) fast3d.f: subroutine plane_space2(lr,ls,lt,i1,w,x,y,z,nx,nxn,nz0,nzn) fast3d.f: subroutine set_up_fast_1D_fem(s,lam,n,lbc,rbc,ll,lm,lr,z,nz,ie) fast3d.f: subroutine set_up_1D_geom(dx,lbc,rbc,ll,lm,lr,z,nz) fast3d.f: subroutine gen_eigs_A_fem(sf,sft,atd,n,l,lbc,rbc) fast3d.f: subroutine get_fast_bc(lbr,rbr,lbs,rbs,lbt,rbt,ie,ierr) fast3d.f: subroutine get_fast_bc2(lbr,rbr,lbs,rbs,lbt,rbt,ie,ierr) fast3d.f: subroutine outv(x,n,name3) fast3d.f: subroutine outmat(a,m,n,name6,ie) fast3d.f: subroutine set_up_fast_1D_fem_ax fast3d.f: subroutine set_up_1D_geom_ax(dx,lbc,rbc,ll,lm,lr,z,y,nz) fast3d.f: subroutine gen_eigs_A_fem_ax(sf,sft,atd,n,l,y,lbc,rbc) fast3d.f: subroutine load_semhat_weighted ! Fills the SEMHAT arrays fast3d.f: subroutine do_semhat_weight(jgl,dgl,bgl,n) fast3d.f: subroutine semhat(a,b,c,d,z,dgll,jgll,bgl,zgl,dgl,jgl,n,w) fast3d.f: subroutine fd_weights_full(xx,x,n,m,c) fast3d.f: subroutine set_up_fast_1D_sem(s,lam,n,lbc,rbc,ll,lm,lr,ie) fast3d.f: subroutine set_up_fast_1D_sem_op(g,b0,b1,l,r,ll,lm,lr,bh,jgl,jscl) fast3d.f: subroutine swap_lengths fast3d.f: subroutine row_zero(a,m,n,i) fasts.f: subroutine local_solves_fdm(u,v) fasts.f: subroutine fastdm1(R,ie,w1,w2) fasts.f: subroutine tensr3(v,nv,u,nu,A,Bt,Ct,w) fasts.f: subroutine s_face_to_int(x,c) fasts.f: subroutine dface_ext(x) fasts.f: subroutine dface_add1si(x,c) fasts.f: subroutine init_weight_op fasts.f: subroutine do_weight_op(x) gauss.f: SUBROUTINE LU(A,N,NDIM,IR,IC) gauss.f:C IT IS THE FIRST SUBROUTINE TO COMPUTE THE MX. INV. gauss.f: SUBROUTINE SOLVE(F,A,K,N,NDIM,IR,IC) genbox.f: subroutine genbox genbox.f: subroutine gen_gtp_vertex (vertex,ncrnr) genbox.f: subroutine getbox(x,y,z,nfld) genbox.f: subroutine mapbox(melx,mely,melz) genbox.f: subroutine makebox(x,y,z,nfld) genbox.f: subroutine geti1(i,iend,io) genbox.f: subroutine geti2(i1,i2,iend,io) genbox.f: subroutine geti3(i1,i2,i3,iend,io) genbox.f: subroutine getr2(r1,r2,iend,io) genbox.f: subroutine getr3(r1,r2,r3,iend,io) genbox.f: subroutine getrv(r,n,iend,io) genbox.f: subroutine getiv(r,n,iend,io) genbox.f: subroutine getcv0(c,m,n,iend,io) genbox.f: subroutine getcv(c,m,n,iend,io) genbox.f: subroutine gets(c,n,iend,io) genbox.f: subroutine get_multi_seg(nelxyz,x,y,z,m,if3d) genbox.f: subroutine geometric_x(x,n,x0,x1,gain) genbox.f: subroutine get_xyz_distribution (x,nelx) genbox.f: subroutine scannocom(iend,infile) genbox.f: subroutine jjnt(x,n) genbox.f: subroutine bcpbox(nfld) genbox.f: subroutine outbox_mesh genxyz.f: subroutine arcsrf(xml,yml,zml,nxl,nyl,nzl,ie,isid) genxyz.f: subroutine defsrf(xml,yml,zml,nxl,nyl,nzl,ie,iface1,ccv) genxyz.f: subroutine intrsc(x3,x2,x1,delt,ie,iface) genxyz.f: subroutine zbrac(x1,x2,succes) genxyz.f: subroutine setdef genxyz.f: subroutine gencoor (xm3,ym3,zm3) genxyz.f: subroutine genxyz (xml,yml,zml,nxl,nyl,nzl) genxyz.f: subroutine setzgml (zgml,iel,nxl,nyl,nzl,ifaxis) genxyz.f: subroutine sphsrf(xml,yml,zml,ifce,ie,nx,ny,nz,xysrf) genxyz.f: subroutine edg3d(xysrf,x1,x2,i1,i2,j1,j2,nx,ny) genxyz.f: subroutine cross(v1,v2,v3) genxyz.f: subroutine norm3d(v1) genxyz.f: subroutine crn3d(xcv,xc,yc,zc,curve,iface) genxyz.f: subroutine rotxyz genxyz.f: subroutine gensrf(XML,YML,ZML,IFCE,IE,MX,MY,MZ,zgml) genxyz.f: subroutine prjects(x0,dxc,c,cc) genxyz.f: subroutine srfind(x1,x0,c,cc) genxyz.f: subroutine linquad(xl,yl,zl,nxl,nyl,nzl) genxyz.f: subroutine xyzlin(xl,yl,zl,nxl,nyl,nzl,e) genxyz.f: subroutine xyzquad(xl,yl,zl,nxl,nyl,nzl,e) gfdm_op.f: subroutine gfdm_ops gfdm_op.f: subroutine gfdm_set_prs_op(mfld) gfdm_op.f: subroutine set_1d_e_mat(eigv,eigs,n,length,nel,nxv,nxp gfdm_op.f: subroutine build_D1d_d(DI,II,dgg1,igg1,wm1,b1d,length,nel,nxv,nxp gfdm_op.f: subroutine gfdm_set_diagp(eigi,tpn,nn,eigx,l,eigy,m,eigz,n) gfdm_op.f: subroutine gfdm_set_geom(work,melx,mely,melz) gfdm_op.f: subroutine gfdm_set_genwz(nx,nxp) gfdm_op.f: subroutine gfdm_set_bc(cb0,cbn,mfld) gfdm_op.f: subroutine add2s2mat2p(a,ma,na,i1,j1,b,ldb,s,m,n) gfdm_op.f: subroutine overflow_chk(n_req,n_avail,var,sub) gfdm_op.f: subroutine solveMp(z,r,n,w,nza) gfdm_op.f: subroutine map12q(r2,r1,rt) gfdm_op.f: subroutine cgpa(x,b,r,p,z,w,niter,tolin) gfdm_op.f: subroutine row_mult (A,B,n1,n2) gfdm_op.f: subroutine a1d (A1,A1t,d2,b2,d1,d1t,wgl,nx) gfdm_op.f: subroutine set_diagA (da,dat,b,d,w,nx) gfdm_op.f: subroutine gfdm_chk_size gfdm_par.f: subroutine g25d_init gfdm_par.f: subroutine gfdm_init gfdm_par.f: subroutine gfdm_check_array_sizes gfdm_par.f: subroutine gfdm_mappings gfdm_par.f: subroutine assign_tp_numbering_pres(tpn,nex,ney,nez,nx,ny,nz gfdm_par.f: subroutine reassign_tp_numbering gfdm_par.f: subroutine cex_setup(part_in,nr,part_out,m,n,nid,np) gfdm_par.f: subroutine cexr(w,u,m,n,part_out,part_in,msg_id,wdsize,nid,np) gfdm_par.f: subroutine cextr(u,m,n,w,part_out,part_in,msg_id,wdsize,nid,np) gfdm_par.f: subroutine cexi(w,u,m,n,part_out,part_in,msg_id,wdsize,nid,np) gfdm_par.f: subroutine cexti(u,m,n,w,part_out,part_in,msg_id,wdsize,nid,np) gfdm_solve.f: subroutine gfdm_pres_solv(z,r,ug,wg) gmres.f: subroutine uzawa_gmres(res,h1,h2,h2inv,intype,iter) gmres.f: subroutine uzawa_gmres_split0(l,u,b,binv,n) gmres.f: subroutine uzawa_gmres_split(l,u,b,binv,n) gmres.f: subroutine uzawa_gmres_temp(a,b,n) gmres.f: subroutine ax(w,x,h1,h2,n) gmres.f: subroutine hmh_gmres(res,h1,h2,wt,iter) gmres.f: subroutine project(x,b,w,r,n,xx,bb,k0,km0,kc,km,nitr,tr,ta,r0,rk) hmholtz.f: subroutine hmholtz(name,u,rhs,h1,h2,mask,mult,imsh,tli,maxit,isd) hmholtz.f: subroutine axhelm (au,u,helm1,helm2,imesh,isd) hmholtz.f: subroutine setfast (helm1,helm2,imesh) hmholtz.f: subroutine sfastax hmholtz.f: subroutine setprec (dpcm1,helm1,helm2,imesh,isd) hmholtz.f: subroutine chktcg1 (tol,res,h1,h2,mask,mult,imesh,isd) hmholtz.f: subroutine cggo(x,f,h1,h2,mask,mult,imsh,tin,maxit,isd,binv,name) hmholtz.f: subroutine calc (diag,upper,d,e,n,dmax,dmin) hmholtz.f: subroutine fdm_h1(z,r,d,mask,mult,nel,kt,rr) hmholtz.f: subroutine set_fdm_prec_h1A_gen hmholtz.f: subroutine set_fdm_prec_h1A_els hmholtz.f: subroutine set_fdm_prec_h1b(d,h1,h2,nel) hmholtz.f: subroutine set_fdm_prec_h1A hmholtz.f: subroutine generalev(a,b,lam,n,w) hmholtz.f: subroutine outmat2(a,m,n,k,name) hmholtz.f: subroutine rescale_abhalf (a,b,w,n) hsmg.f: subroutine hsmg_setup() hsmg.f: subroutine hsmg_setup_semhat hsmg.f: subroutine hsmg_setup_intp hsmg.f: subroutine hsmg_setup_intpm(jh,zf,zc,nf,nc) hsmg.f: subroutine hsmg_setup_dssum hsmg.f: subroutine hsmg_setup_wtmask hsmg.f: subroutine hsmg_intp(uf,uc,l) ! l is coarse level hsmg.f: subroutine hsmg_rstr(uc,uf,l) ! l is coarse level hsmg.f: subroutine hsmg_rstr_no_dssum(uc,uf,l) ! l is coarse level hsmg.f: subroutine hsmg_tnsr(v,nv,u,nu,A,At) hsmg.f: subroutine hsmg_tnsr2d(v,nv,u,nu,A,Bt) hsmg.f: subroutine hsmg_tnsr3d(v,nv,u,nu,A,Bt,Ct) hsmg.f: subroutine hsmg_tnsr2d_el(v,nv,u,nu,A,Bt) hsmg.f: subroutine hsmg_tnsr3d_el(v,nv,u,nu,A,Bt,Ct) hsmg.f: subroutine hsmg_dssum(u,l) hsmg.f: subroutine hsmg_dsprod(u,l) hsmg.f: subroutine hsmg_schwarz_dssum(u,l) hsmg.f: subroutine hsmg_extrude(arr1,l1,f1,arr2,l2,f2,nx,ny,nz) hsmg.f: subroutine hsmg_schwarz(e,r,l) hsmg.f: subroutine hsmg_schwarz_toext2d(a,b,n) hsmg.f: subroutine hsmg_schwarz_toext3d(a,b,n) hsmg.f: subroutine hsmg_schwarz_toreg2d(b,a,n) hsmg.f: subroutine hsmg_schwarz_toreg3d(b,a,n) hsmg.f: subroutine hsmg_setup_fdm() hsmg.f: subroutine hsmg_setup_fast(s,d,nl,ah,bh,n) hsmg.f: subroutine hsmg_setup_fast1d(s,lam,nl,lbc,rbc,ll,lm,lr,ah,bh,n,ie) hsmg.f: subroutine hsmg_setup_fast1d_a(a,lbc,rbc,ll,lm,lr,ah,n) hsmg.f: subroutine hsmg_setup_fast1d_b(b,lbc,rbc,ll,lm,lr,bh,n) hsmg.f: subroutine hsmg_fdm(e,r,l) hsmg.f: subroutine hsmg_do_fast(e,r,s,d,nl) hsmg.f: subroutine hsmg_do_wt(u,wt,nx,ny,nz) hsmg.f: subroutine hsmg_setup_rstr_wt(wt,nx,ny,nz,l,w) hsmg.f: subroutine hsmg_setup_mask(wt,nx,ny,nz,l,w) hsmg.f: subroutine hsmg_setup_schwarz_wt(ifsqrt) hsmg.f: subroutine hsmg_setup_schwarz_wt2d(wt,n,work,ifsqrt) hsmg.f: subroutine hsmg_setup_schwarz_wt3d(wt,n,work,ifsqrt) hsmg.f: subroutine hsmg_schwarz_wt(e,l) hsmg.f: subroutine hsmg_schwarz_wt2d(e,wt,n) hsmg.f: subroutine hsmg_schwarz_wt3d(e,wt,n) hsmg.f: subroutine hsmg_coarse_solve(e,r) hsmg.f: subroutine hsmg_setup_solve hsmg.f: subroutine hsmg_solve(e,r) hsmg.f: subroutine hsmg_setup_mg_nx() ic.f: subroutine setics ic.f:c mesh coordinates (see Subroutine INIGEOM) ic.f: subroutine slogic (iffort,ifrest,ifprsl,nfiles) ic.f: subroutine restart(nfiles) ic.f: subroutine sioflag(ndumps,fname,rsopts) ic.f: subroutine mapdmp(sdump,tdump,ieg,nxr,nyr,nzr,if_byte_sw) ic.f: subroutine mapab(x,y,nxr,nel) ic.f: subroutine mapab4R(x,y,nxr,nel) ic.f: subroutine csplit(s0,s1,s2,l0) ic.f: subroutine lshft(string,ipt) ic.f: subroutine ljust(string) ic.f: subroutine chknorm (ifzero) ic.f: subroutine prsolvt ic.f: subroutine prsolvv ic.f: subroutine nekuic ic.f: subroutine capit(lettrs,n) ic.f: subroutine perturb(tt,ifld,eps) ic.f: subroutine vcospf(x,y,n) ic.f: subroutine vbyte_swap(x,n) ic.f: subroutine geom_reset(icall) ic.f: subroutine dsavg(u) ic.f: subroutine map13_all(x3,x1) ic.f: subroutine mfi_gets(u,wk,lwk,iskip) ic.f: subroutine mfi_getv(u,v,w,wk,lwk,iskip) ic.f: subroutine mfi_parse_hdr(hdr) ic.f: subroutine parse_std_hdr(hdr) ic.f: subroutine parse_std_hdr_2006(hdr,rlcode) ic.f: subroutine mfi(fname) ic.f: subroutine mbyte_open(hname,fid) ! open blah000.fldnn ic.f: subroutine mfi_prepare(hname) ! determine which nodes are readers induct.f: subroutine induct (igeom) induct.f: subroutine lagbfield induct.f: subroutine makebsource_mhd induct.f: subroutine makeufb induct.f: subroutine makextb induct.f: subroutine makebdfb induct.f: subroutine cresvib(resv1,resv2,resv3,h1,h2) induct.f: subroutine cresvibp(resv1,resv2,resv3,h1,h2) induct.f: subroutine incomprn (ux,uy,uz,up) induct.f: subroutine opzero(ux,uy,uz) induct.f: subroutine opnorm(unorm,ux,uy,uz,type3) induct.f: subroutine lorentz_force (lf,b1,b2,b3,w1,w2) induct.f: subroutine curl(vort,u,v,w,ifavg,work1,work2) induct.f: subroutine lorentz_force2(lf,b1,b2,b3) induct.f: subroutine lorentz_force_e(lf,b1,b2,b3,e) induct.f: subroutine spec_curl_e (cb,b1,b2,b3,rx,ry,rz,sx,sy,sz,tx,ty,tz) induct.f: subroutine specx(b,nb,a,na,ba,ab,w) induct.f: subroutine phys_to_elsasser(u1,u2,u3,b1,b2,b3,n) induct.f: subroutine elsasser_to_phys(u1,u2,u3,b1,b2,b3,n) induct.f: subroutine phys_to_elsasser2(u1,b1,n) induct.f: subroutine elsasser_to_phys2(u1,b1,n) induct.f: subroutine elsasserh(igeom) induct.f: subroutine compute_cfl(cfl,u,v,w,dt) induct.f: subroutine getdr(dri,zgm1,nx1) induct.f: subroutine ophinv_pr(o1,o2,o3,i1,i2,i3,h1,h2,tolh,nmxhi) induct.f: subroutine ophinvm(o1,o2,o3,i1,i2,i3,m1,m2,m3,h1,h2,tolh,nmxhi) induct.f: subroutine set_ifbcor(ifbcor) induct.f: subroutine setrhsp(p,h1,h2,h2inv,pset,nprev) induct.f: subroutine gensolnp(p,h1,h2,h2inv,pset,nprev) induct.f: subroutine econjp(pset,nprev,h1,h2,h2inv,ierr) induct.f: subroutine advab_elsasser_fast induct.f: subroutine set_dealias_rx induct.f: subroutine cfl_check init_plugin.f: subroutine init_plugin makeq.f: subroutine makeq makeq_aux.f: subroutine makeq_aux map2.f: subroutine mapelpr() map2.f: subroutine set_proc_map() map2.f: subroutine gfdm_elm_to_proc(gllnid,np) map2.f: subroutine gfdm_map_2d(map_st,nes,net,num_el,np) map2.f: subroutine gfdm_set_pst(ip,is,it,nelbox,nstride_box,nxp,nyp,nzp) map2.f: subroutine gfdm_build_global_el_map (gllnid,map_st,nes,net map2.f: subroutine outmati(u,m,n,name6) map2.f: subroutine get_map math.f: SUBROUTINE BLANK(A,N) math.f: SUBROUTINE VSQ (A,N) math.f: SUBROUTINE VSQRT(A,N) math.f: subroutine invers2(a,b,n) math.f: subroutine invcol1(a,n) math.f: subroutine invcol2(a,b,n) math.f: subroutine invcol3(a,b,c,n) math.f: subroutine col4(a,b,c,d,n) math.f: subroutine Xaddcol3(a,b,c,n) math.f: subroutine addcol4(a,b,c,d,n) math.f: subroutine ascol5 (a,b,c,d,e,n) math.f: subroutine sub2(a,b,n) math.f: subroutine sub3(a,b,c,n) math.f: subroutine subcol3(a,b,c,n) math.f: subroutine subcol4(a,b,c,d,n) math.f: subroutine rzero(a,n) math.f: subroutine izero(a,n) math.f: subroutine ione(a,n) math.f: subroutine rone(a,n) math.f: subroutine cfill(a,b,n) math.f: subroutine ifill(ia,ib,n) math.f: subroutine copy(a,b,n) math.f: subroutine chcopy(a,b,n) math.f: subroutine icopy(a,b,n) math.f: subroutine i8copy(a,b,n) math.f: subroutine chsign(a,n) math.f: subroutine cmult(a,const,n) math.f: subroutine cadd(a,const,n) math.f: subroutine iadd(i1,iscal,n) math.f: subroutine cadd2(a,b,const,n) math.f: subroutine vcross (u1,u2,u3,v1,v2,v3,w1,w2,w3,n) math.f: subroutine vdot2 (dot,u1,u2,v1,v2,n) math.f: subroutine vdot3 (dot,u1,u2,u3,v1,v2,v3,n) math.f: subroutine addtnsr(s,h1,h2,h3,nx,ny,nz) math.f: subroutine iflip(i1,n) math.f: subroutine iswap(b,ind,n,temp) math.f: subroutine col2(a,b,n) math.f: subroutine col2c(a,b,c,n) math.f: subroutine col3(a,b,c,n) math.f: subroutine add2(a,b,n) math.f: subroutine add3(a,b,c,n) math.f: subroutine addcol3(a,b,c,n) math.f: subroutine add2s1(a,b,c1,n) math.f: subroutine add2s2(a,b,c1,n) math.f: subroutine add3s2(a,b,c,c1,c2,n) math.f: subroutine add4(a,b,c,d,n) math.f: subroutine gllog(la,lb) math.f: subroutine dcadd(a,const,n) math.f: subroutine dsub2(a,b,n) math.f: subroutine dadd2(a,b,n) math.f: subroutine chswapr(b,L,ind,n,temp) math.f: subroutine drcopy(r,d,N) math.f: subroutine sorts(xout,xin,work,n) math.f: subroutine icadd(a,c,n) math.f: subroutine isort(a,ind,n) math.f: subroutine sort(a,ind,n) math.f: subroutine iswap_ip(x,p,n) math.f: subroutine iswapt_ip(x,p,n) math.f: subroutine swap_ip(x,p,n) math.f: subroutine swapt_ip(x,p,n) math.f: subroutine glvadd(x,w,n) math.f: subroutine add3s12(x,y,z,c1,c2,n) math.f: subroutine admcol3(a,b,c,d,n) math.f: subroutine add2col2(a,b,c,n) math.f: subroutine add2sxy(x,a,y,b,n) math.f: subroutine col2s2(x,y,s,n) mpi_dummy.f: subroutine mpi_scan(data1, data2, n, datatype, mpi_dummy.f: subroutine mpi_abort ( comm, errorcode, ierror ) mpi_dummy.f: subroutine mpi_allgather ( data1, nsend, sendtype, data2, mpi_dummy.f: subroutine mpi_allgatherv ( data1, nsend, sendtype, mpi_dummy.f: subroutine mpi_allreduce ( data1, data2, n, datatype, mpi_dummy.f: subroutine mpi_barrier ( comm, ierror ) mpi_dummy.f: subroutine mpi_bcast ( data, n, datatype, node, comm, ierror ) mpi_dummy.f: subroutine mpi_bsend ( data, n, datatype, iproc, itag, mpi_dummy.f: subroutine mpi_cart_create ( comm, ndims, dims, periods, mpi_dummy.f: subroutine mpi_cart_get ( comm, ndims, dims, periods, mpi_dummy.f: subroutine mpi_cart_shift ( comm, idir, idisp, isource, mpi_dummy.f: subroutine mpi_comm_dup ( comm, comm_out, ierror ) mpi_dummy.f: subroutine mpi_comm_free ( comm, ierror ) mpi_dummy.f: subroutine mpi_comm_rank ( comm, me, ierror ) mpi_dummy.f: subroutine mpi_comm_size ( comm, nprocs, ierror ) mpi_dummy.f: subroutine mpi_comm_split ( comm, icolor, ikey, comm_new, mpi_dummy.f: subroutine mpi_copy_double_precision ( data1, data2, n, ierror ) mpi_dummy.f: subroutine mpi_copy_integer ( data1, data2, n, ierror ) mpi_dummy.f: subroutine mpi_copy_real ( data1, data2, n, ierror ) mpi_dummy.f: subroutine mpi_finalize ( ierror ) mpi_dummy.f: subroutine mpi_get_count ( istatus, datatype, icount, ierror ) mpi_dummy.f: subroutine mpi_init ( ierror ) mpi_dummy.f: subroutine mpi_irecv ( data, n, datatype, iproc, itag, mpi_dummy.f: subroutine mpi_isend ( data, n, datatype, iproc, itag, mpi_dummy.f: subroutine mpi_recv ( data, n, datatype, iproc, itag, mpi_dummy.f: subroutine mpi_reduce ( data1, data2, n, datatype, operation, mpi_dummy.f: subroutine mpi_reduce_double_precision ( mpi_dummy.f: subroutine mpi_reduce_integer8 ( mpi_dummy.f: subroutine mpi_reduce_integer ( mpi_dummy.f: subroutine mpi_reduce_real ( mpi_dummy.f: subroutine mpi_reduce_scatter ( data1, data2, n, datatype, mpi_dummy.f: subroutine mpi_rsend ( data, n, datatype, iproc, itag, mpi_dummy.f: subroutine mpi_send ( data, n, datatype, iproc, itag, mpi_dummy.f: subroutine mpi_wait ( irequest, istatus, ierror ) mpi_dummy.f: subroutine mpi_waitall ( icount, irequest, istatus, ierror ) mpi_dummy.f: subroutine mpi_waitany ( icount, array_of_requests, index, mpi_dummy.f: subroutine mpi_initialized(mpi_is_initialized, ierr) mpi_dummy.f: subroutine mpi_comm_create(icomm,igroup,icommd,ierr) mpi_dummy.f: subroutine mpi_comm_group(icomm,igroup,ierr) mpi_dummy.f: subroutine mpi_group_free mpi_dummy.f: subroutine mpi_attr_get(icomm,ikey,ival,iflag,ierr) mvmesh.f: subroutine cbcmesh mvmesh.f: subroutine admeshv mvmesh.f: subroutine admesht mvmesh.f: subroutine divws (fms,sfv,phi,nel,idir) mvmesh.f: subroutine axifms (fms,sfv,phi,nel,idir) mvmesh.f: subroutine updcoor mvmesh.f:C Subroutine to update geometry for moving boundary problems mvmesh.f: subroutine mvbdry (nel) mvmesh.f: subroutine norcmp (wt1,wt2,wt3,rnx,rny,rnz,ifc) mvmesh.f: subroutine facemv (wt1,wt2,wt3,rnx,rny,rnz,smt,ifc) mvmesh.f: subroutine faczqn (wt1,wt2,wt3,ifc,iel) mvmesh.f: subroutine facsmt (smt,ifc) mvmesh.f: subroutine cqnet (qni,ta,nel) mvmesh.f: subroutine facemt (w1,w2,w3,rnx,rny,rnz,qni,dsa,smt,rhola,ifc) mvmesh.f: subroutine elasolv (nel) mvmesh.f: subroutine meshtol (ta,tolmsh,nel,imsolv) mvmesh.f: subroutine updxyz (nel) mvmesh.f: subroutine lagmshv (nel) mvmesh.f: subroutine facec3 (a1,a2,a3,b1,b2,b3,ifc) mvmesh.f: subroutine ptbgeom mvmesh.f:C Subroutine to impose perturbation to geometry before solution mvmesh.f: subroutine ibdgeom (nel) mvmesh.f: subroutine inigeom (ux,uy,uz,x,y,z,iside,iel) mvmesh.f: subroutine quickmv mvmesh.f: subroutine quickmv2d mvmesh.f: subroutine quickmv3d mxm_std.f: subroutine mxmf2(A,N1,B,N2,C,N3) mxm_std.f: subroutine mxf1(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf2(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf3(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf4(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf5(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf6(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf7(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf8(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf9(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf10(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf11(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf12(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf13(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf14(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf15(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf16(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf17(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf18(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf19(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf20(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf21(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf22(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf23(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxf24(a,n1,b,n2,c,n3) mxm_std.f: subroutine mxm44_0(a, m, b, k, c, n) mxm_std.f: subroutine mxm44_2(a, m, b, k, c, n) mxm_wrapper.f: subroutine mxm(a,n1,b,n2,c,n3) navier0.f: SUBROUTINE ESOLVER (RES,H1,H2,H2INV,INTYPE) navier0.f: SUBROUTINE ESTRAT navier0.f: SUBROUTINE EINIT navier0.f: subroutine dmp_map(imap) navier0.f: subroutine p_outvec_ir(ia,a,lda,name9) navier1.f: subroutine plan1 (igeom) navier1.f: subroutine crespuz (respr,g1,g2,g3,h1,h2,h2inv,intype) navier1.f: subroutine cresvuz (resv1,resv2,resv3) navier1.f: subroutine makeg (out1,out2,out3,h1,h2,intype) navier1.f: subroutine ctolspl (tolspl,respr) navier1.f: subroutine ortho (respr) navier1.f: subroutine zaver1 (pm1) navier1.f: subroutine cdabdtp (ap,wp,h1,h2,h2inv,intype) navier1.f: subroutine opgrad (out1,out2,out3,inp) navier1.f: subroutine cdtp (dtx,x,rm2,sm2,tm2,isd) navier1.f: subroutine multd (dx,x,rm2,sm2,tm2,isd,iflg) navier1.f: subroutine ophinv (out1,out2,out3,inp1,inp2,inp3,h1,h2,tolh,nmxi) navier1.f: subroutine ophx (out1,out2,out3,inp1,inp2,inp3,h1,h2) navier1.f: subroutine opbinv (out1,out2,out3,inp1,inp2,inp3,h2inv) navier1.f: subroutine opbinv1(out1,out2,out3,inp1,inp2,inp3,SCALE) navier1.f: subroutine uzprec (rpcg,rcg,h1m1,h2m1,intype,wp) navier1.f: subroutine eprec (z2,r2) navier1.f: subroutine convprn (iconv,rbnorm,rrpt,res,z,tol) navier1.f: subroutine convpr (res,tol,iconv,rbnorm) navier1.f: subroutine chktcg2 (tol,res,iconv) navier1.f: subroutine dudxyz (du,u,rm1,sm1,tm1,jm1,imsh,isd) navier1.f: subroutine convopo (conv,fi) navier1.f: subroutine conv2 (dtfi,fi) navier1.f: subroutine cmask (cmask1,cmask2) navier1.f: subroutine makef navier1.f: subroutine makeuf navier1.f: subroutine nekuf (f1,f2,f3) navier1.f: subroutine natconv navier1.f: subroutine settbar (tbar) navier1.f: subroutine advab navier1.f: subroutine makebdf navier1.f: subroutine makeabf navier1.f: subroutine setab3 (ab0,ab1,ab2) navier1.f: subroutine setabbd (ab,dtlag,nab,nbd) navier1.f: subroutine setbd (bd,dtbd,nbd) navier1.f: subroutine bdsys (a,b,dt,nbd,ndim) navier1.f: subroutine advchar_old navier1.f: subroutine ophyprkn(vel1,vel2,vel3,ilag) navier1.f: subroutine ophypab (vel1,vel2,vel3,ilag) navier1.f: subroutine tauinit (tau,ilag) navier1.f: subroutine velinit (vel1,vel2,vel3,ilag) navier1.f: subroutine velconv (vxn,vyn,vzn,tau) navier1.f: subroutine frkconv (y,x,mask) navier1.f: subroutine velchar (vel,vn,vlag,nbd,tau,dtbd) navier1.f: subroutine lagvel navier1.f: subroutine hypmsk3 (hv1msk,hv2msk,hv3msk) navier1.f: subroutine setordbd navier1.f: subroutine testmom (rmom,resv1,resv2,resv3,w1,w2,w3) navier1.f: subroutine testdtp navier1.f: subroutine tmultd navier1.f: subroutine normsc (h1,semi,l2,linf,x,imesh) navier1.f: subroutine normvc (h1,semi,l2,linf,x1,x2,x3) navier1.f: subroutine genwp (wp,wm2,p) navier1.f: subroutine convuz (ifstuz) navier1.f: subroutine convsp (ifstsp) navier1.f: subroutine antimsk (y,x,xmask,n) navier1.f: subroutine opamask (vbdry1,vbdry2,vbdry3) navier1.f: subroutine opmask (res1,res2,res3) navier1.f: subroutine opadd2 (a1,a2,a3,b1,b2,b3) navier1.f: subroutine opsub2 (a1,a2,a3,b1,b2,b3) navier1.f: subroutine opsub3 (a1,a2,a3,b1,b2,b3,c1,c2,c3) navier1.f: subroutine opcolv3(a1,a2,a3,b1,b2,b3,c) navier1.f: subroutine opcolv (a1,a2,a3,c) navier1.f: subroutine opcol2 (a1,a2,a3,b1,b2,b3) navier1.f: subroutine opchsgn (a,b,c) navier1.f: subroutine opcopy (a1,a2,a3,b1,b2,b3) navier1.f: subroutine rotate_cyc(r1,r2,r3,idir) navier1.f: subroutine opdssum (a,b,c)! NOTE: opdssum works on FLUID/MHD arrays only! navier1.f: subroutine opdsop (a,b,c,op)! opdsop works on FLUID/MHD arrays only! navier1.f: subroutine opicol2 (a1,a2,a3,b1,b2,b3) navier1.f: subroutine oprzero (a,b,c) navier1.f: subroutine oprone (a,b,c) navier1.f: subroutine opcmult (a,b,c,const) navier1.f: subroutine opcolv2c(a1,a2,a3,b1,b2,c) navier1.f: subroutine opcolv2(a1,a2,a3,b1,b2) navier1.f: subroutine opadd2col(a1,a2,a3,b1,b2,b3,c) navier1.f: subroutine opcolv3c(a1,a2,a3,b1,b2,b3,c,d) navier1.f: subroutine uzawa (rcg,h1,h2,h2inv,intype,iter) navier1.f: subroutine spbslpf(abd,lda,n,m,b) navier1.f: subroutine spbfapf(abd,lda,n,m,info) navier1.f: subroutine mapw(md,nd,m1,n1,mflg) navier1.f: subroutine mapwp(md,nd,m1,n1,mflg) navier1.f: subroutine specmp(b,nb,a,na,ba,ab,w) navier1.f: subroutine setmap(n1,nd) navier1.f: subroutine set_PND(P,LkD,LkNt,N,D) navier1.f: subroutine transpose(a,lda,b,ldb) navier1.f: subroutine convop(conv,fi) navier1.f: subroutine conv1d (dfi,fi) navier1.f: subroutine conv1n(du,u) navier1.f: subroutine conv1o(dfi,fi) navier1.f: subroutine conv1 (dfi,fi) navier1.f: subroutine conv1no(du,u) navier1.f: subroutine conv1rk(du,dv,dw,u,v,w) navier1.f: subroutine velconvv(vxn,vyn,vzn,tau) navier1.f: subroutine frkconvv (du,dv,dw,u,v,w,mu) navier1.f: subroutine conv1rk2(du,dv,dw,u,v,w,cu,cv,cw,beta,wk) navier1.f: subroutine frkconvv2(du,dv,dw,u,v,w,cu,cv,cw,beta,mu,wk) navier1.f: subroutine hypmsk3v(msk,mask) navier1.f: subroutine ophyprk (vel1,vel2,vel3,ilag) navier1.f: subroutine opdiv(outfld,inpx,inpy,inpz) navier1.f: subroutine opgradt(outx,outy,outz,inpfld) navier1.f: subroutine setproj(n1,nd) navier1.f: subroutine set_PNDoi(Pt,P,LkNt,N,D) navier1.f: subroutine wgradm1(ux,uy,uz,u,nel) ! weak form of grad navier1.f: SUBROUTINE MAKEVIS navier1.f: SUBROUTINE COMP_SIEJ (U1,U2,U3) navier1.f: subroutine wlaplacian(out,a,diff,ifld) navier2.f: subroutine aspect_ratios(ar) navier2.f: subroutine eig2(AA,eign,eig1) navier2.f: subroutine quadratic_h(x1,x2,a,b,c) navier2.f: subroutine out_sem(iel) navier2.f: subroutine gradm11(ux,uy,uz,u,e) navier2.f: subroutine gradm11ts(u,ux,uy,uz,e) navier2.f: subroutine makemsf(afx,afy,afz) navier3.f: SUBROUTINE EPREC2(Z2,R2) navier3.f: subroutine dd_solver(u,v) navier3.f: subroutine rar2_out(x,name13) navier3.f: subroutine rarr_out2(x,name13) navier4.f: subroutine incompr navier4.f: subroutine setrhs(p,h1,h2,h2inv) navier4.f: subroutine gensoln(p,h1,h2,h2inv) navier4.f: subroutine updtset(p,h1,h2,h2inv,IERR) navier4.f: subroutine econj(kprev,h1,h2,h2inv,ierr) navier4.f: subroutine chkptol navier4.f: subroutine updrhse(p,h1,h2,h2inv,ierr) navier4.f: subroutine echeck(kprev,h1,h2,h2inv,intetype) navier4.f: subroutine savep(P,H1,H2,H2INV) navier4.f: subroutine projh(r,h1,h2,bi,vml,vmk,approx,napprox,wl,ws,name4) navier4.f: subroutine gensh(v1,h1,h2,vml,vmk,approx,napprox,wl,ws,name4) navier4.f: subroutine hconj(approx,k,h1,h2,vml,vmk,ws,name4,ierr) navier4.f: subroutine updrhsh(approx,napprox,h1,h2,vml,vmk,ws,name4) navier4.f: subroutine hmhzpf(name,u,r,h1,h2,mask,mult,imesh,tli,maxit,isd,bi) navier4.f: subroutine hsolve(name,u,r,h1,h2,vmk,vml,imsh,tol,maxit,isd navier5.f: subroutine q_filter(wght) navier5.f: subroutine filterq(v,f,nx,nz,w1,w2,ft,if3d,dmax) navier5.f: subroutine outmatx(a,m,n,io,name) navier5.f: subroutine drag_calc(scale) navier5.f: subroutine mappr(pm1,pm2,pa,pb) navier5.f: subroutine out_csrmats(acsr,ia,ja,n,name9) navier5.f: subroutine local_grad3(ur,us,ut,u,N,e,D,Dt) navier5.f: subroutine local_grad2(ur,us,u,N,e,D,Dt) navier5.f: subroutine gradm1(ux,uy,uz,u) navier5.f: subroutine outpost(v1,v2,v3,vp,vt,name3) navier5.f: subroutine outpost2(v1,v2,v3,vp,vt,nfldt,name3) navier5.f: subroutine comp_vort3(vort,work1,work2,u,v,w) navier5.f: subroutine surface_int(sint,sarea,a,ie,iface1) navier5.f: subroutine surface_flux(dq,qx,qy,qz,ie,iface,w) navier5.f: subroutine gaujordf(a,m,n,indr,indc,ipiv,ierr,rmult) navier5.f: subroutine legendre_poly(L,x,N) navier5.f: subroutine build_new_filter(intv,zpts,nx,kut,wght,nid) navier5.f: subroutine avg_all navier5.f: subroutine avg1(avg,f,alpha,beta,n,name,ifverbose) navier5.f: subroutine avg2(avg,f,alpha,beta,n,name,ifverbose) navier5.f: subroutine avg3(avg,f,g,alpha,beta,n,name,ifverbose) navier5.f: subroutine build_legend_transform(Lj,Ljt,zpts,nx) navier5.f: subroutine local_err_est(err,u,nx,Lj,Ljt,uh,w,if3d) navier5.f: subroutine transpose1(a,n) navier5.f: subroutine get_exyz(ex,ey,ez,eg,nelx,nely,nelz) navier5.f: subroutine dump_header2d(excode,nx,ny,nlx,nly) navier5.f: subroutine outfld2d_p(u,v,w,nx,ny,nlx,nly,name,ifld,jid,npido) navier5.f: subroutine outfld2d(u,v,w,nx,ny,nlx,nly,name,ifld) navier5.f: subroutine planar_average_z(ua,u,w1,w2) navier5.f: subroutine drgtrq(dgtq,xm0,ym0,zm0,sij,pm1,visc,f,e) navier5.f: subroutine torque_calc(scale,x0,ifdout,iftout) navier5.f: subroutine comp_sij(sij,nij,u,v,w,ur,us,ut,vr,vs,vt,wr,ws,wt) navier5.f: subroutine y_slice (ua,u,w1,w2) navier5.f: subroutine z_slice (ua,u,w1,w2) navier5.f: subroutine y_average(ua,u,w1,w2) navier5.f: subroutine z_average(ua,u,w1,w2) navier5.f: subroutine y_avg_buff(ux,uy,uz,c2,name,icount) navier5.f: subroutine z_avg_buff(ux,uy,uz,c2,name,icount) navier5.f: subroutine y_ins_buff(ux,uy,uz,c2,name,icount) navier5.f: subroutine z_ins_buff(ux,uy,uz,c2,name,icount) navier5.f: subroutine buff_2d_out(u,v,w,nx,ny,nex,ney,c2,name,ifld) navier5.f: subroutine y2d(u,v,w,p,c1,icount) navier5.f: subroutine z2d(u,v,w,p,c1,icount) navier5.f: subroutine anal_2d navier5.f: subroutine chkit(u,name4,n) navier5.f: subroutine outmesh navier5.f: subroutine out_el(xt,e) navier5.f: subroutine get_el(xt,x,y,z) navier5.f: subroutine shear_calc_max(strsmx,scale,x0,ifdout,iftout) navier5.f: subroutine get_strsmax(strsmax,xm0,ym0,zm0,sij,pm1,visc,f,e) navier5.f: subroutine fix_geom ! fix up geometry irregularities navier5.f: subroutine gh_face_extend(x,zg,n,gh_type,e,v) navier5.f: subroutine gh_face_extend_2d(x,zg,n,gh_type,e,v) navier5.f: subroutine gh_face_extend_3d(x,zg,n,gh_type,e,v) navier5.f: subroutine rand_fld_h1(x) navier5.f: subroutine rescale_x (x,x0,x1) navier6.f: subroutine set_overlap navier6.f: subroutine overflow_ck(n_req,n_avail,signal) navier6.f: subroutine iunswap(b,ind,n,temp) navier6.f: subroutine set_fem_data_l2(nep,nd,no,x,y,z,p) navier6.f: subroutine map_face12(x2,x1,w1,w2) navier6.f: subroutine map_one_face12(x2,x1,iface,i12,i12t,w1,w2) navier6.f: subroutine dface_add1sa(x) navier6.f: subroutine faces(a,s,ie,iface,nx,ny,nz) navier7.f: subroutine out_acsr(acsr,ia,ja,n) navier7.f: subroutine compress_acsr(acsr,ia,ja,n) navier7.f: subroutine outbox(xmax,xmin,ymax,ymin,io) navier7.f: subroutine imout(x,m,n,name) navier7.f: subroutine out_abd(abd,lda,n,m) navier7.f: subroutine rarr_out(x,name13) navier7.f: subroutine iarr_out(x,name) navier7.f: subroutine iar2_out(x,name) navier7.f: subroutine scsr_permute(bcsr,ib,jb,acsr,ia,ja,n navier7.f: write(6,*) 'HMT HACK in subroutine scsr_permute() ... pls fix!' navier7.f: subroutine scsr_to_spb(abd,lda,acsr,ia,ja,n) navier7.f: subroutine scsr_to_spbm(abd,lda,acsr,ia,ja,n) navier7.f: subroutine out_spbmat(abd,n,lda,name) navier7.f: subroutine swap(b,ind,n,temp) navier7.f: subroutine ipermute(a,icperm,n,b) navier7.f: subroutine out_csrmat(acsr,ia,ja,n,name9) navier8.f: subroutine set_vert(glo_num,ngv,nx,nel,vertex,ifcenter) navier8.f: subroutine crs_solve_l2(uf,vf) navier8.f:c subroutine test_h1_crs navier8.f: subroutine set_up_h1_crs navier8.f: subroutine set_jl_crs_mask(n, mask, se_to_gcrs) navier8.f: subroutine set_mat_ij(ia,ja,n,ne) navier8.f: subroutine irank_vec(ind,nn,a,m,n,key,nkey,aa) navier8.f: subroutine ituple_sort(a,lda,n,key,nkey,ind,aa) navier8.f: subroutine tuple_sort(a,lda,n,key,nkey,ind,aa) navier8.f: subroutine get_local_crs(a,lda,nxc,h1,h2,w,ldw) navier8.f: subroutine a_crs_enriched(a,h1,h2,x1,y1,z1,nxc,if3d,ie) navier8.f: subroutine a_crs_3d(a,h1,h2,xc,yc,zc,ie) navier8.f: subroutine bindec(bin_in) navier8.f: subroutine get_local_A_tet(a,x,y,z,kt,ie) navier8.f: subroutine a_crs_2d(a,h1,h2,x,y,ie) navier8.f: subroutine map_m_to_n(a,na,b,nb,if3d,w,ldw) navier8.f: subroutine specmpn(b,nb,a,na,ba,ab,if3d,w,ldw) navier8.f: subroutine irank(A,IND,N) navier8.f: subroutine iranku(r,input,n,w,ind) navier8.f: subroutine ifacev_redef(a,ie,iface,val,nx,ny,nz) navier8.f: subroutine map_c_to_f_l2_bilin(uf,uc,w) navier8.f: subroutine map_f_to_c_l2_bilin(uc,uf,w) navier8.f: subroutine maph1_to_l2(a,na,b,nb,if3d,w,ldw) navier8.f: subroutine maph1_to_l2t(b,nb,a,na,if3d,w,ldw) navier8.f: subroutine irank_vec_tally(ind,nn,a,m,n,key,nkey,key2,aa) navier8.f: subroutine out_se1(se2crs,nx,name) navier8.f: subroutine out_se0(se2crs,nx,nel,name) navier8.f: subroutine crs_solve_h1(uf,vf) navier8.f: subroutine set_h1_basis_bilin navier8.f: subroutine map_c_to_f_h1_bilin(uf,uc) navier8.f: subroutine map_f_to_c_h1_bilin(uc,uf) navier8.f: subroutine get_local_crs_galerkin(a,ncl,nxc,h1,h2,w1,w2) navier8.f: subroutine gen_crs_basis(b,j) ! bi- tri-linear navier8.f: subroutine gen_crs_basis2(b,j) ! bi- tri-quadratic navier8.f: subroutine get_vertex navier8.f: subroutine assign_gllnid(gllnid,iunsort,nelgt,nelgv,np) navier8.f: subroutine get_vert navier8.f: subroutine get_vert_map(vertex, nlv, nel, suffix) navier8.f: subroutine irank_vecn(ind,nn,a,m,n,key,nkey,aa) navier8.f: subroutine gbtuple_rank(tuple,m,n,nmax,cr_h,nid,np,ind) navier8.f: subroutine setvert3d(glo_num,ngv,nx,nel,vertex,ifcenter) navier8.f: subroutine setvert2d(glo_num,ngv,nx,nel,vertex,ifcenter) papi.f: subroutine nek_flops(flops,mflops) papi.f: subroutine getflops_papi(flops,mflops) pertsupport.f: subroutine flushBuffer(k) pertsupport.f: subroutine opscale(v1,v2,v3,temp,alpha) pertsupport.f: subroutine opscaleV(v1,v2,v3,alpha) pertsupport.f: subroutine computelyap pertsupport.f: subroutine computelyap1(vxq,vyq,vzq,tq,jpp) pertsupport.f: subroutine rescalepert(pertnorm,pertinvnorm,jpp) pertsupport.f: subroutine writehist(v1,v2,v3,temp,jpp) pertsupport.f: subroutine initialize pertsupport.f: subroutine initialize1(jpp) pertsupport.f: subroutine get_useric pertsupport.f: subroutine out_pert ! dump perturbation .fld files pertsupport.f: subroutine pert_add2s2(i,j,scale) ! xi = xi + scale * xj pertsupport.f: subroutine pert_ortho_norm ! orthogonalize and rescale pert. arrays pertsupport.f: subroutine pert_ortho_norm1 (k) ! orthogonalize k against 1...k-1 perturb.f: subroutine fluidp (igeom) perturb.f: subroutine perturbv (igeom) perturb.f: subroutine lagfieldp perturb.f: subroutine makefp perturb.f: subroutine makeufp perturb.f: subroutine advabp perturb.f: subroutine makextp perturb.f: subroutine makebdfp perturb.f: subroutine cresvipp(resv1,resv2,resv3,h1,h2) perturb.f: subroutine heatp (igeom) perturb.f: subroutine cdscalp (igeom) perturb.f: subroutine makeqp perturb.f: subroutine makeuqp perturb.f: subroutine convabp perturb.f: subroutine makeabqp perturb.f: subroutine makebdqp perturb.f: subroutine lagscalp perturb.f: subroutine incomprp (ux,uy,uz,up) perturb.f: subroutine extrapprp (prextr) perturb.f: subroutine lagpresp perturb.f: subroutine lyap_scale ! Rescale / orthogonalize perturbation fields perturb.f: subroutine out_pert ! dump perturbation .fld files perturb.f: subroutine pert_add2s2(i,j,scale) ! xi = xi + scale * xj perturb.f: subroutine pert_ortho_norm ! orthogonalize and rescale pert. arrays perturb.f: subroutine pert_ortho_norm1 (k) ! orthogonalize k against 1...k-1 perturb.f: subroutine opscale(v1,v2,v3,temp,alpha) perturb.f: subroutine opscaleV(v1,v2,v3,alpha) perturb.f: subroutine computelyap perturb.f: subroutine computelyap1(vxq,vyq,vzq,tq,jpp) perturb.f: subroutine rescalepert(pertnorm,pertinvnorm,jpp) plan4.f: subroutine plan4 plan4.f:c by an external subroutine e.g qthermal plan4.f: subroutine crespsp (respr) plan4.f: subroutine cresvsp (resv1,resv2,resv3,h1,h2) plan4.f: subroutine op_curl(w1,w2,w3,u1,u2,u3,ifavg,work1,work2) plan4.f: subroutine opadd2cm (a1,a2,a3,b1,b2,b3,c) plan4.f: subroutine split_vis plan4.f: subroutine redo_split_vis plan4.f: subroutine v_extrap(vext) planx.f: SUBROUTINE PLAN3 (IGEOM) planx.f: SUBROUTINE LAGPRES planx.f: SUBROUTINE CRESVIF (RESV1,RESV2,RESV3,H1,H2) planx.f: SUBROUTINE EXTRAPP (PREXTR) planx.f: subroutine ophinvpr(ot1,ot2,ot3,in1,in2,in3,h1,h2,tolh,nmxi) planx.f: subroutine hmzpf2(nm,u,rhs,h1,h2,mask,mult,imsh,tol,mxit,isd) planx.f: subroutine projh2(v1,h1,h2,vml,vmask,isd) planx.f: subroutine gensh2(v1,h1,h2,vml,vmask,isd) planx.f: subroutine updtseth2(v1,h1,h2,vml,vmask,isd) planx.f: subroutine hconj2(kprev,h1,h2,vml,vmask,isd) planx.f: subroutine updrhsh2(h1,h2,vml,vmask,isd) postpro.f: subroutine load_fld(string) postpro.f: subroutine lambda2(l2) postpro.f: subroutine find_lam3(lam,aa,w,ndim,ierr) postpro.f: subroutine quadratic(x1,x2,a,b,c,ierr) postpro.f: subroutine cubic(xo,ai1,ai2,ai3,ierr) postpro.f: subroutine comp_gije(gije,u,v,w,e) postpro.f: subroutine filter_s1(scalar,tf,nx,nel) ! filter scalar field postpro.f: subroutine filter_s0(scalar,wght,ncut,name5) ! filter scalar field postpro.f: subroutine intpts_setup(tolin) postpro.f: subroutine intpts(fieldin,nfld,iTl,mi,rTl,mr,n,iffindin,ih) postpro.f: subroutine intpts_done() postpro.f: subroutine tens3d1(v,u,f,ft,nv,nu) ! v = F x F x F x u postpro.f: subroutine build_1d_filt(fh,fht,trnsfr,nx,nid) postpro.f: subroutine mag_tensor_e(mag,aije) postpro.f: subroutine comp_sije(gije) postpro.f: subroutine map2reg(ur,n,u,nel) postpro.f: subroutine map2reg_2di_e(uf,n,uc,m) ! Fine, uniform pt postpro.f: subroutine map2reg_3di_e(uf,n,uc,m) ! Fine, uniform pt postpro.f: subroutine gen_int_gz(j,jt,g,n,z,m) postpro.f: subroutine zuni(z,np) postpro.f: subroutine gen_rea(imid) ! Generate and output essential parts of .rea postpro.f: subroutine gen_rea_xyz postpro.f: subroutine gen_rea_curve(imid) postpro.f: subroutine gen_rea_bc (ifld) postpro.f: subroutine gen_rea_midside_e(e) postpro.f: subroutine hpts prepost.f: subroutine prepost(ifdoin,prefin) prepost.f: subroutine prepost_map(isave) ! isave=0-->fwd, isave=1-->bkwd prepost.f: subroutine outfld(prefix) prepost.f: subroutine outhis(ifhis) ! output time history info prepost.f: subroutine intglq prepost.f: subroutine bdforce prepost.f: subroutine bdheat prepost.f: subroutine setsmu (smult) prepost.f: subroutine file2(nopen,PREFIX) prepost.f: subroutine rzero4(a,n) prepost.f: subroutine copyX4(a,b,n) prepost.f: subroutine copy4r(a,b,n) prepost.f: subroutine dump_header(excodein,p66) prepost.f: subroutine fill_tmp(tdump,id,ie) prepost.f: subroutine get_id(id) prepost.f: subroutine close_fld(p66) prepost.f: subroutine out_tmp(id,p66) prepost.f: subroutine mfo_outfld(prefix) ! muti-file output prepost.f: subroutine io_init ! determine which nodes will output prepost.f: subroutine mfo_open_files(prefix) ! open files prepost.f: subroutine restart_nfld( nfld, prefix ) prepost.f: subroutine restart_save(iosave,save_size,nfldi) prepost.f: subroutine mfo_mdatav(u,v,w,nel) prepost.f: subroutine mfo_mdatas(u,nel) prepost.f: subroutine mfo_outs(u,nel,mx,my,mz) ! output a scalar field prepost.f: subroutine mfo_outv(u,v,w,nel,mx,my,mz) ! output a vector field prepost.f: subroutine mfo_write_hdr ! write hdr, byte key, els. qthermal.f: subroutine qthermal setprop.f: subroutine setprop speclib.f: SUBROUTINE ZWGL (Z,W,NP) speclib.f: SUBROUTINE ZWGLL (Z,W,NP) speclib.f: SUBROUTINE ZWGJ (Z,W,NP,ALPHA,BETA) speclib.f: SUBROUTINE ZWGJD (Z,W,NP,ALPHA,BETA) speclib.f: SUBROUTINE ZWGLJ (Z,W,NP,ALPHA,BETA) speclib.f: SUBROUTINE ZWGLJD (Z,W,NP,ALPHA,BETA) speclib.f: SUBROUTINE JACG (XJAC,NP,ALPHA,BETA) speclib.f: SUBROUTINE JACOBF (POLY,PDER,POLYM1,PDERM1,POLYM2,PDERM2, speclib.f: SUBROUTINE DGJ (D,DT,Z,NZ,NZD,ALPHA,BETA) speclib.f: SUBROUTINE DGJD (D,DT,Z,NZ,NZD,ALPHA,BETA) speclib.f: SUBROUTINE DGLJ (D,DT,Z,NZ,NZD,ALPHA,BETA) speclib.f: SUBROUTINE DGLJD (D,DT,Z,NZ,NZD,ALPHA,BETA) speclib.f: SUBROUTINE DGLL (D,DT,Z,NZ,NZD) speclib.f: WRITE (6,*) 'Subroutine DGLL' speclib.f: SUBROUTINE DGLLGL (D,DT,ZM1,ZM2,IM12,NZM1,NZM2,ND1,ND2) speclib.f:C (see subroutine IGLLGL). speclib.f: SUBROUTINE DGLJGJ (D,DT,ZGL,ZG,IGLG,NPGL,NPG,ND1,ND2,ALPHA,BETA) speclib.f:C (see subroutine IGLJGJ). speclib.f: SUBROUTINE DGLJGJD (D,DT,ZGL,ZG,IGLG,NPGL,NPG,ND1,ND2,ALPHA,BETA) speclib.f:C (see subroutine IGLJGJ). speclib.f: SUBROUTINE IGLM (I12,IT12,Z1,Z2,NZ1,NZ2,ND1,ND2) speclib.f: SUBROUTINE IGLLM (I12,IT12,Z1,Z2,NZ1,NZ2,ND1,ND2) speclib.f: SUBROUTINE IGJM (I12,IT12,Z1,Z2,NZ1,NZ2,ND1,ND2,ALPHA,BETA) speclib.f: SUBROUTINE IGLJM (I12,IT12,Z1,Z2,NZ1,NZ2,ND1,ND2,ALPHA,BETA) ssolv.f: SUBROUTINE SSTEST (ISSS) ssolv.f: SUBROUTINE SSINIT (KMAX) ssolv.f: SUBROUTINE CHKEXT (IFACCX,Z,S) ssolv.f: SUBROUTINE FILLLAG ssolv.f: SUBROUTINE GONSTEP (N,ITEST) ssolv.f: SUBROUTINE GO1STEP (X,Y,NVEC) ssolv.f: SUBROUTINE GOSTEP ssolv.f: SUBROUTINE MODPROP ssolv.f: SUBROUTINE MKVEC (X) ssolv.f: SUBROUTINE MKARR (X) ssolv.f: SUBROUTINE SSPARAM (KMAX,L) ssolv.f: SUBROUTINE CHKSSVT ssolv.f: SUBROUTINE CHKSSV ssolv.f: SUBROUTINE CHKSST ssolv.f: SUBROUTINE SSNORMD (DV1,DV2,DV3) ssolv.f: SUBROUTINE SSNORMP (DV1,DV2,DV3) ssolv.f: SUBROUTINE SETTOLV ssolv.f:C See subroutine CHKSSV ssolv.f: SUBROUTINE SETTOLT ssolv.f: SUBROUTINE CHKTOLP (TOLMIN) ssolv.f: SUBROUTINE SETCHAR ssolv.f: SUBROUTINE PROJECT subs1.f: SUBROUTINE SETDT subs1.f: SUBROUTINE CVGNLPS (IFCONV) subs1.f: SUBROUTINE UNORM subs1.f: SUBROUTINE CHKTMG (TOL,RES,W1,W2,MULT,MASK,IMESH) subs1.f: SUBROUTINE SETDTC subs1.f: SUBROUTINE CUMAX (V1,V2,V3,UMAX) subs1.f: SUBROUTINE SETDTFS (DTFS) subs1.f: SUBROUTINE CDXMIN2 (DTST,RHOSIG,IEL,IFC,IFAXIS) subs1.f: SUBROUTINE CDXMIN3 (DTST,RHOSIG,IEL,IFC) subs1.f: SUBROUTINE FCAVER(XAVER,A,IEL,IFACE1) subs1.f: SUBROUTINE FACCL2(A,B,IFACE1) subs1.f: SUBROUTINE FACCL3(A,B,C,IFACE1) subs1.f: SUBROUTINE FADDCL3(A,B,C,IFACE1) subs1.f: subroutine sethlm (h1,h2,intloc) subs1.f: SUBROUTINE VPROPS subs1.f: SUBROUTINE NEKUVP (IEL) subs1.f: SUBROUTINE DIAGNOS subs1.f: SUBROUTINE SETSOLV subs1.f: SUBROUTINE MGGO subs1.f: SUBROUTINE MGINIT subs1.f: SUBROUTINE HMHZSF (NAME,U1,U2,U3,R1,R2,R3,H1,H2, subs1.f: SUBROUTINE CHKTCGS (R1,R2,R3,RMASK1,RMASK2,RMASK3,RMULT,BINV, subs1.f: SUBROUTINE CGGOSF (U1,U2,U3,R1,R2,R3,H1,H2,RMULT,BINV, subs1.f: SUBROUTINE AXHMSF (AU1,AU2,AU3,U1,U2,U3,H1,H2,MATMOD) subs1.f: SUBROUTINE STNRATE (U1,U2,U3,NEL,MATMOD) subs1.f: SUBROUTINE UXYZ (U,EX,EY,EZ,NEL) subs1.f: SUBROUTINE URST (U,UR,US,UT,NEL) subs1.f: SUBROUTINE DDRST (U,UR,US,UT) subs1.f: SUBROUTINE AXIEZZ (U2,EYY,EZZ,NEL) subs1.f: subroutine flush_io subs1.f: subroutine fcsum2(xsum,asum,x,e,f) subs2.f: SUBROUTINE STRESS (H1,H2,NEL,MATMOD,IFAXIS) subs2.f: SUBROUTINE AIJUJ (AU1,AU2,AU3,NEL,IFAXIS) subs2.f: SUBROUTINE TTXYZ (FF,TX,TY,TZ,NEL) subs2.f: SUBROUTINE TTRST (FF,FR,FS,FT,TA) subs2.f: SUBROUTINE AXITZZ (VFY,TZZ,NEL) subs2.f: SUBROUTINE SETAXDY (IFAXDY) subs2.f: SUBROUTINE SETAXW1 (IFAXWG) subs2.f: SUBROUTINE SETAXW2 (IFAXWG) subs2.f: SUBROUTINE STNRINV subs2.f: SUBROUTINE OPDOT (DP,A1,A2,A3,B1,B2,B3,N) subs2.f: SUBROUTINE OPADDS (A1,A2,A3,B1,B2,B3,CONST,N,ISC) subs2.f: SUBROUTINE FACEXS (A,B,IFACE1,IOP) subs2.f: SUBROUTINE FACEXV (A1,A2,A3,B1,B2,B3,IFACE1,IOP) subs2.f: SUBROUTINE FACSUB2 (A1,A2,A3,B1,B2,B3,IFACE1) subs2.f: SUBROUTINE GAMMASF (H1,H2) subs2.f: SUBROUTINE CMULT2 (A,B,CONST,N) subs2.f: SUBROUTINE ADD3S (A,B,C,CONST,N) subs2.f: SUBROUTINE EMERXIT subs2.f: SUBROUTINE FACCVS (A1,A2,A3,B,IFACE1) subs2.f: SUBROUTINE STX1SF subs2.f: SUBROUTINE SOLVEL subs2.f: SUBROUTINE VSOLN (UX,UY,UZ,X,Y,Z,PI) subs2.f: SUBROUTINE SOLPRES subs2.f: SUBROUTINE PRSOLN (P,X,Y,Z,PI) subs2.f: SUBROUTINE STORE subs2.f: SUBROUTINE PRINTEL (TA,A,IEL) subs2.f: SUBROUTINE PRINTV (TA,A,NEL) subs2.f: SUBROUTINE OUTF1 (X,TXT,IEL,IFC) subs2.f: SUBROUTINE OUTM1 (X,TXT,NP,IEL,IP) subs2.f: SUBROUTINE OUTM2 (X,TXT,NP,IEL,IP) subs2.f: SUBROUTINE STSMASK (C1MASK,C2MASK,C3MASK) subs2.f: SUBROUTINE UPDMSYS (IFLD) subs2.f: SUBROUTINE SETHMSK (HVMASK,HFMASK,IFLD,NEL) subs2.f: SUBROUTINE SKIPCNR (NEL) subs2.f: SUBROUTINE SETMASK (C1MASK,C2MASK,C3MASK,HVMASK,NEL) subs2.f: SUBROUTINE SETMLOG (HVMASK,HFMASK,IFLD,NEL) subs2.f: SUBROUTINE SETCSYS (HVMASK,HFMASK,NEL) subs2.f: SUBROUTINE COMAVN2 (HVMASK,HFMASK,NEL) subs2.f: SUBROUTINE COMAVN3 (HVMASK,HFMASK,NEL) subs2.f: SUBROUTINE FIXWMSK (W2MASK,W3MASK,HVMASK,HFMASK,NEL) subs2.f: SUBROUTINE FXWMS2 (W2MASK,HVMASK,HFMASK,NEL) subs2.f: SUBROUTINE FXWMS3 (W2MASK,W3MASK,HVMASK,HFMASK,NEL) subs2.f: SUBROUTINE SETCDAT subs2.f: SUBROUTINE EDGINDF (LF1,LF2,LFSKIP,ISD,IFCN) subs2.f: SUBROUTINE EDGINDV (LV1,LV2,LVSKIP,ISD) subs2.f: SUBROUTINE SETCDOF subs2.f: SUBROUTINE AMASK (VB1,VB2,VB3,V1,V2,V3,NEL) subs2.f: SUBROUTINE RMASK (R1,R2,R3,NEL) subs2.f: SUBROUTINE QMASK (R1,R2,R3,R1MASK,R2MASK,R3MASK,NEL) subs2.f: SUBROUTINE FCMSK2 (R1,R2,S1,S2,R1MASK,R2MASK,NEL) subs2.f: SUBROUTINE FCMSK3 (R1,R2,R3,S1,S2,S3,R1MASK,R2MASK,R3MASK,NEL) subs2.f: SUBROUTINE EGMASK (R1,R2,R3,S1,S2,S3,R1MASK,R2MASK,R3MASK,NEL) subs2.f: SUBROUTINE CRMSK2 (R1,R2,S1,S2,R1MASK,R2MASK,NEL) subs2.f: SUBROUTINE CRMSK3 (R1,R2,R3,S1,S2,S3,R1MASK,R2MASK,R3MASK,NEL) subs2.f: subroutine getSnormal(sn,ix,iy,iz,iside,e) turb.f: SUBROUTINE SETTURB turb.f: SUBROUTINE PRETMIC turb.f: SUBROUTINE POSTMIC turb.f: SUBROUTINE CBCTURB turb.f: SUBROUTINE WHATFLD (IFTURB) turb.f: SUBROUTINE TURBFLD (IFKFLD,IFEFLD) turb.f: SUBROUTINE TVISCOS turb.f: SUBROUTINE TVISCKE turb.f: SUBROUTINE TVISCA turb.f: SUBROUTINE TPROPK turb.f: SUBROUTINE TPROPE turb.f: SUBROUTINE MAKETQ turb.f: SUBROUTINE SETQK turb.f: SUBROUTINE SETQE turb.f: SUBROUTINE TURBQK turb.f: SUBROUTINE TURBQE turb.f: SUBROUTINE TURBWBC (TMP,TMA,SMU) turb.f: SUBROUTINE FACEWSK (S,IEL,IFC) turb.f: SUBROUTINE FACEWSE (S,IEL,IFC) turb.f: SUBROUTINE SETTMC turb.f: SUBROUTINE COMPHI (PHI) turb.f: SUBROUTINE INIPHI (PHI) turb.f: SUBROUTINE TWALLUZ (IGEOM) turb.f: SUBROUTINE TWALLSH turb.f: SUBROUTINE FACEWS (TRX,TRY,TRZ,IEL,IFC) turb.f: SUBROUTINE COMWUZ (XWLL,YWLL,ZWLL,V1,V2,V3,VISKIN,VISMIN,IEL,IFC) turb.f: SUBROUTINE NORIND (JS3,JF3,JSKIP3,IWX,IWY,IFC,ISCH) turb.f: SUBROUTINE CWREF (XWLL,YWLL,ZWLL,UTW,ZNW,VTAN1,VTAN2,VTAN3, turb.f: SUBROUTINE COMTDIR (VTAN1,VTAN2,VTAN3,JWX,JWY,IWZ,IEL,IFC) turb.f: SUBROUTINE SUBGRID (UTW,ZNW,UW,ZW,ZL,ZU,UL,UU,AKVIS,UST1,IEL,IFC, turb.f: SUBROUTINE COMUFR (UST,U,Z,AKVIS,UST1,IEL,IFC,JWX,JWY) turb.f: SUBROUTINE COMLSQ turb.f: SUBROUTINE LSCALE turb.f: SUBROUTINE TLMASK (SMASK) turb.f: SUBROUTINE BCDIRTL (TLS,SMS,TMP) turb.f: SUBROUTINE FACEWL (S,IEL,IFC) turb.f: SUBROUTINE GETVAR (V,VP,RP) turb.f: SUBROUTINE INVCHK2 (A,B,N) turb.f: SUBROUTINE FACIND2 (JS1,JF1,JSKIP1,JS2,JF2,JSKIP2,IFC) bdry.f:C Assign fortran function boundary conditions to calcz.f: function pythag(a,b) comm_mpi.f: integer function numnodes() comm_mpi.f: integer function mynode() comm_mpi.f: real*8 function dnekclock() comm_mpi.f: real*8 function dnekclock_sync() comm_mpi.f: function isend(msgtag,x,len,jnid,jpid) comm_mpi.f: function irecv(msgtag,x,len) comm_mpi.f: function igl_running_sum(in) conduct.f:c Fill up user defined forcing function and collocate will the conduct.f: time = time-dt ! Set time to t^n-1 for user function conduct.f:c Set user specified volumetric forcing function (e.g. heat source). conduct.f:C Eulerian scheme, add convection term to forcing function conduct.f:c Eulerian scheme, add diffusion term to forcing function connect1.f: FUNCTION VOLUM0(P1,P2,P3,P0) connect1.f: FUNCTION CRSS2D(XY1,XY2,XY0) connect2.f:C check for fortran function as denoted by lower case bc's: connect2.f:C check for fortran function as denoted by lower case bc's: connect2.f:C check for fortran function as denoted by lower case bc's: cvode_driver.f:c f denotes the RHS function and is evaluated in fcvfun(). cvode_driver.f:c Compute RHS function f (allocated within cvode) dssum.f:c o note: a binary function pointer flavor exists. genbox.f: function ilsum(x,n) genxyz.f:C Load parameters for surface function FNC genxyz.f:C Given a function FNC and an initial guess (X1,X2), the routine genxyz.f: FUNCTION ZBRENT(X1,X2,TOL) genxyz.f:C of a function FNC known to lie between X1 and X2. The root, genxyz.f: FUNCTION FNC(ETA) genxyz.f: LOGICAL FUNCTION IFVCHK(VEC,I1,I2,I3) genxyz.f: REAL FUNCTION DOT(V1,V2,N) genxyz.f: function ressrf(x,c,cc) hmholtz.f: function vlsc32(r,b,m,n) ic.f:C (1) - User specified fortran function (default is zero i.c.) ic.f:C Fortran function initial conditions for temp/pass. scalars. ic.f:C Fortran function initial conditions for velocity. ic.f:C Fortran function initial conditions for turbulence k-e model ic.f:C Default is user specified fortran function (=0 if not specified) ic.f: function i1_from_char(s1) ic.f: integer function indx2(s1,l1,s2,l2) ic.f: INTEGER FUNCTION INDX1(S1,S2,L2) ic.f: INTEGER FUNCTION INDX_CUT(S1,S2,L2) ic.f:C User specified fortran function (=0 if not specified) ic.f: LOGICAL FUNCTION IFGTRL(VALUE,LINE) ic.f:C This complicated function is necessary thanks to the Ardent, ic.f: LOGICAL FUNCTION IFGTIL(IVALUE,LINE) ic.f:C This complicated function is necessary thanks to the Ardent, ic.f: logical function if_byte_swap_test(bytetest) induct.f:c Compute and add: (1) user specified forcing function (FX,FY,FZ) induct.f:C Eulerian scheme, add convection term to forcing function induct.f:C Eulerian scheme, add convection term to forcing function makeq.f:C Generate forcing function for the solution of a passive scalar. math.f: real function vlmin(vec,n) math.f: integer function ivlmin(vec,n) math.f: integer function ivlmax(vec,n) math.f: real function vlmax(vec,n) math.f: real function vlamax(vec,n) math.f: real function vlsum(vec,n) math.f:C Map and add to S a tensor product form of the three functions H1,H2,H3. math.f: function ltrunc(string,l) math.f: function mod1(i,n) math.f: $ 'WARNING: Attempt to take MOD(I,0) in function mod1.' math.f: integer function log2(k) math.f: real function vlsc2(x,y,n) math.f: real function vlsc21(x,y,n) math.f: function glsc3(a,b,mult,n) math.f: function glsc2(x,y,n) math.f: function glsc23(x,y,z,n) math.f: real function gl2norm(a,n) math.f: function glsum (x,n) math.f: real function glamax(a,n) math.f: real function glamin(a,n) math.f: function iglmin(a,n) math.f: function iglmax(a,n) math.f: function iglsum(a,n) math.f: integer*8 function i8glsum(a,n) math.f: function glmax(a,n) math.f: function glmin(a,n) math.f: function fmdian(a,n,ifok) math.f: function ivlsum(a,n) math.f: integer*8 function i8glmax(a,n) mpi_dummy.f: function mpi_wtick ( ) mpi_dummy.f: function mpi_wtime ( ) navier1.f:C Compute and add: (1) user specified forcing function (FX,FY,FZ) navier1.f:C Compute and add: (1) user specified forcing function (FX,FY,FZ) navier1.f:C Eulerian scheme, add convection term to forcing function navier4.f: FUNCTION VLSC3(X,Y,B,N) navier5.f: function facint(a,b,area,ifc,ie) navier5.f: function facint2(a,b,c,area,ifc,ie) navier5.f:c This routing builds a 1D filter with a transfer function that navier5.f:c Set up transfer function navier5.f: function ran1(idum) navier7.f: function mbw_csr(ia,ja,n) navier8.f: logical function iftuple_ialtb(a,b,key,nkey) navier8.f: logical function iftuple_altb(a,b,key,nkey) navier8.f: logical function iftuple_ianeb(a,b,key,nkey) pertsupport.f: function opnormOld(v1,v2,v3,weight) pertsupport.f: function opnorm2(v1,v2,v3) pertsupport.f: function Tnorm(temp) pertsupport.f: function dmnorm(v1,v2,v3,temp) pertsupport.f: function pert_inner_prod(i,j) ! weighted inner product vi^T vj perturb.f:c Compute and add: (1) user specified forcing function (FX,FY,FZ) perturb.f:C Eulerian scheme, add convection term to forcing function perturb.f:C Generate forcing function for the solution of a passive scalar. perturb.f:C Fill up user defined forcing function and collocate will the perturb.f:C Eulerian scheme, add convection term to forcing function perturb.f: function pert_inner_prod(i,j) ! weighted inner product vi^T vj perturb.f: function opnorm2(v1,v2,v3) perturb.f: function Tnorm(temp) perturb.f: function dmnorm(v1,v2,v3,temp) postpro.f:c Build 1D-filter based on the transfer function (tf) postpro.f:c This routing builds a 1D filter with transfer function diag() prepost.f: FUNCTION SUMFC (FF,SM,IFC) prepost.f: function i_find_prefix(prefix,imax) speclib.f:C [2] Abramowitz & Stegun: Handbook of Mathematical Functions, speclib.f: REAL*8 FUNCTION ENDW1 (N,ALPHA,BETA) speclib.f: REAL*8 FUNCTION ENDW2 (N,ALPHA,BETA) speclib.f: REAL*8 FUNCTION GAMMAF (X) speclib.f: REAL*8 FUNCTION PNORMJ (N,ALPHA,BETA) speclib.f: REAL FUNCTION HGJ (II,Z,ZGJ,NP,ALPHA,BETA) speclib.f: REAL*8 FUNCTION HGJD (II,Z,ZGJ,NP,ALPHA,BETA) speclib.f: REAL FUNCTION HGLJ (II,Z,ZGLJ,NP,ALPHA,BETA) speclib.f: REAL*8 FUNCTION HGLJD (I,Z,ZGLJ,NP,ALPHA,BETA) speclib.f: REAL FUNCTION HGLL (I,Z,ZGLL,NZ) speclib.f: REAL FUNCTION HGL (I,Z,ZGL,NZ) speclib.f: REAL FUNCTION PNLEG (Z,N) speclib.f: REAL FUNCTION PNDLEG (Z,N) subs1.f: FUNCTION FACDOT(A,B,IFACE1) subs1.f:C 2 for fortran function; subs1.f:C User specified fortran function (pff 2/13/01) subs1.f:C User specified fortran function subs1.f: function surf_mean(u,ifld,bc_in,ierr) From nek5000-users at lists.mcs.anl.gov Tue Jun 15 09:44:39 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 15 Jun 2010 09:44:39 -0500 (CDT) Subject: [Nek5000-users] Residuals In-Reply-To: References: <4C17848E.9020703@gmail.com> Message-ID: PS - I forgot to divide by dt in the routine below. To do this, dti = 1./dt call opcmult(uo,vo,wo,dti) after opcopy On Tue, 15 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > JC, > > Given that (v,u_t) = (v,r), where r is the residual, I would > assume that you can get the desired residual estimate by looking > at u_t := du/dt ~= || u^n - u^n-1 || / dt ? > > Typically, I would do this in userchk, creating a set of variables > in a common block, e.g. > > parameter (lt=lx1*ly1*lz1*lelt) > common /vold/ uo(lt),vo(lt),wo(lt) > real linf,l2,h1,semi > > n = nx1*ny1*nz1*nz1*nelv > > if (istep.gt.0) then > call opsub2 (uo,vo,wo,vx,vy,vz) > call normvc (h1,semi,l2,linf,uo,vo,wo) > if (nid.eq.0) write(6,1) istep,time,h1,semi,l2,linf > 1 format(i8,1p5e13.6,' resnorm') > endif > call opcopy (uo,vo,wo,vx,vy,vz) ! Save current velocity > > > Then "grep resnorm logfile > t.t" would put the time history > of this quantity into the file t.t, assuming your stdout is > directed to logfile. > > Paul > > > On Tue, 15 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Nek's, >> >> I have a question concerning residuals. >> I wanna run a calculation that yields to a stationnary flow. In order to be >> sure that my calculation has converged, I'd like to see the residuals. >> How/where could I output them ? >> >> Regards, >> JC >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> From nek5000-users at lists.mcs.anl.gov Tue Jun 15 09:46:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 15 Jun 2010 09:46:34 -0500 (CDT) Subject: [Nek5000-users] Residuals In-Reply-To: References: <4C17848E.9020703@gmail.com> Message-ID: Hi JC and Paul, there is a typo -- it should be n = nx1*ny1*nz1*nelv Best, Aleks On Tue, 15 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > PS - I forgot to divide by dt in the routine below. > > To do this, > > > dti = 1./dt > call opcmult(uo,vo,wo,dti) > > after opcopy > > > On Tue, 15 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> >> JC, >> >> Given that (v,u_t) = (v,r), where r is the residual, I would >> assume that you can get the desired residual estimate by looking >> at u_t := du/dt ~= || u^n - u^n-1 || / dt ? >> >> Typically, I would do this in userchk, creating a set of variables >> in a common block, e.g. >> >> parameter (lt=lx1*ly1*lz1*lelt) >> common /vold/ uo(lt),vo(lt),wo(lt) >> real linf,l2,h1,semi >> >> n = nx1*ny1*nz1*nz1*nelv >> >> if (istep.gt.0) then >> call opsub2 (uo,vo,wo,vx,vy,vz) >> call normvc (h1,semi,l2,linf,uo,vo,wo) >> if (nid.eq.0) write(6,1) istep,time,h1,semi,l2,linf >> 1 format(i8,1p5e13.6,' resnorm') >> endif >> call opcopy (uo,vo,wo,vx,vy,vz) ! Save current velocity >> >> >> Then "grep resnorm logfile > t.t" would put the time history >> of this quantity into the file t.t, assuming your stdout is >> directed to logfile. >> >> Paul >> >> >> On Tue, 15 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Nek's, >>> >>> I have a question concerning residuals. >>> I wanna run a calculation that yields to a stationnary flow. In order to >>> be sure that my calculation has converged, I'd like to see the residuals. >>> How/where could I output them ? >>> >>> Regards, >>> JC >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue Jun 15 16:00:20 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 15 Jun 2010 16:00:20 -0500 (CDT) Subject: [Nek5000-users] Nekmerge question In-Reply-To: <4BD073A7.30007@gmail.com> Message-ID: <542371377.572371276635620215.JavaMail.root@neo-mail-3> Hi all, I have a general question related to this thread:? Is there a tolerance for the conforming interfaces using prex's "import mesh" feature or do the element points need to be exactly the same?? Thanks! - Michael M. ----- Original Message ----- From: nek5000-users at lists. mcs . anl .gov To: nek5000-users at lists. mcs . anl .gov Sent: Thursday, April 22, 2010 11:04:55 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Nekmerge question No domain overlap is alrgiht , but I didn't know about the conforming interfaces. I'll pick a glance tomorow on how to get the locations of each edge from my outer mesh, and I'll mesh the inside one according to these locations. Thanks a lot. Jean-Christophe _______________________________________________ Nek5000-users mailing list Nek5000-users at lists. mcs . anl .gov https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 15 21:02:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 15 Jun 2010 21:02:00 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? Message-ID: <1371855551.622741276653720859.JavaMail.root@neo-mail-3> Hello All, I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)??? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. Regards, Michael M. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 15 22:56:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 15 Jun 2010 22:56:55 -0500 Subject: [Nek5000-users] Gradients in an object : Few queries for parallel setting. In-Reply-To: References: Message-ID: Paul, I updated the usr file with the changes, but I end up getting the following error. I tried to fix it, but couldn't succeed as I am not very familiar with how codes are parallelized. It would be great if you could give some suggestions on how I would have to proceed to dump out data (vxy for a particular object) from all the processors to a file. ------- Error : ------- 8 - MPI_WAITALL : Error code is in status [8] [] Aborting Program! Abort signaled by rank 8: Aborting program ! 40 - MPI_WAITALL : Error code is in status [40] [] Aborting Program! Abort signaled by rank 40: Aborting program ! Please find attached the usr with this email. Thanks Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: final.usr Type: application/octet-stream Size: 11153 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 16 19:22:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 16 Jun 2010 19:22:03 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: <1969799452.819291276734107503.JavaMail.root@neo-mail-3> Message-ID: <539354417.819311276734123032.JavaMail.root@neo-mail-3> Hi, I am still trying to figure this idea out, but I think I would need to access the connectivity/boundary condition information that is contained in the rea file. Does anyone know the array, or what to call in order to access this in the usr file?? Thanks again for any help! - Michael M. ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "Nekton User List" Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central Subject: [Nek5000-users] New Recycling BC method? Hello All, I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)??? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. Regards, Michael M. ? _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 16 21:08:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 16 Jun 2010 21:08:00 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: <539354417.819311276734123032.JavaMail.root@neo-mail-3> References: <539354417.819311276734123032.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, Access to the connectivity array wouldn't help in this case, given that the recycling bc needs to establish a _new_ connectivity that has nothing to do with the existing one. The examples use this approach of establishing a new connectivity. I'm confident that we can make the existing approach for any mesh that can legitimally employ the recycling bc - i.e., any mesh that has the same cross-sectional distribution of elements at the two planes of interest. An alternative is to use the general purpose interpolation routines. There may (or may not) be a performance issue -- we're looking into this w/ the help of a summer student. Please let me know if I can assist you w/ your specific case. Paul > I am still trying to figure this idea out, but I think I would need to > access the connectivity/boundary condition information that is contained > in the rea file. Does anyone know the array, or what to call in order to > access this in the usr file??? Thanks again for any help! > > > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New Recycling BC method? > > > > > Hello All, > > > > I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)????? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. > > > > Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). > > > > I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. > > > > Regards, > > Michael M. > > > ?? > _______________________________________________ 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 Jun 16 21:35:30 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 16 Jun 2010 21:35:30 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: <1137606886.837451276742119705.JavaMail.root@neo-mail-3> Message-ID: <26626584.837611276742130360.JavaMail.root@neo-mail-3> Hi Paul, Thanks for the reply.? The reason for the interest is due to the Gambit to Nek matlab code. We have had great success importing complex geometries with it, but now we run into the issue of the recycling boundary condition.? Gambit's ordering of the elements is not always consistent which?makes it impossible to use the current technique. Our solution was to create the portion that has the recycling in prex and then merge it with the complex part created in Gambit. However, this is proving to be very time consuming and troublesome (Element Mismatch Errors).? So, to avoid this I would like to come up with a new recycling?method that does not depend on the elements being in a specific order. My understanding is that the current method looks at the inflow, counts a certain number of elements up, copies this outflow from face?6 and puts it back into the inflow face 5. What I would like to do is replace how the inflow plane is connected to the outflow plane. My idea was to use the connectivity matrix to figure out what the element numbers and outflow faces are at a certain distance away from the inflow plane, and use these faces to connect.? The cross-section for the inflow and outflow plane would be the same, but you couldn't necessarily say that it is located, say inflow + 30 elements for example, OR that the outflow and inflow faces are all the same (face 5 for inflow, face 6 for outflow for example).? Do you think this is possible? In a way, you would be creating a new connectivity matrix that governs the recycling BC. Thanks! - Michael M. ----- Original Message ----- From: nek5000-users at lists. mcs . anl .gov To: nek5000-users at lists. mcs . anl .gov Sent: Wednesday, June 16, 2010 9:08:00 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] New Recycling BC method? Hi Michael, Access to the connectivity array wouldn't help in this case, given that the recycling bc needs to establish a _new_ connectivity that has nothing to do with the existing one. The examples use this approach of establishing a new connectivity. I'm confident that we can make the existing approach for any mesh that can legitimally employ the recycling bc - i.e., any mesh that has the same cross-sectional distribution of elements at the two planes of interest. An alternative is to use the general purpose interpolation routines. There may (or may not) be a performance issue -- we're looking into this w/ the help of a summer student. Please let me know if I can assist you w/ your specific case. Paul > I am still trying to figure this idea out, but I think I would need to > access the connectivity/boundary condition information that is contained > in the rea file. Does anyone know the array, or what to call in order to > access this in the usr file?? Thanks again for any help! > > > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: " Nekton User List" > Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New Recycling BC method? > > > > > Hello All, > > > > I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)??? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. > > > > Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). > > > > I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. > > > > Regards, > > Michael M. > > > ? > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists. mcs . anl .gov https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists. mcs . anl .gov https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 16 21:39:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 16 Jun 2010 21:39:59 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: <26626584.837611276742130360.JavaMail.root@neo-mail-3> References: <26626584.837611276742130360.JavaMail.root@neo-mail-3> Message-ID: Hi Micheal, I agree completely that it's best to avoid mix & match meshing. If you want to send me a gzipped .rea file produced by Gambit, I can take a look and see if I have any ideas. Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > Thanks for the reply.?? The reason for the interest is due to the Gambit to Nek matlab code. We have had great success importing complex geometries with it, but now we run into the issue of the recycling boundary condition.?? Gambit's ordering of the elements is not always consistent which??makes it impossible to use the current technique. > > > > Our solution was to create the portion that has the recycling in prex and then merge it with the complex part created in Gambit. However, this is proving to be very time consuming and troublesome (Element Mismatch Errors).?? So, to avoid this I would like to come up with a new recycling??method that does not depend on the elements being in a specific order. My understanding is that the current method looks at the inflow, counts a certain number of elements up, copies this outflow from face??6 and puts it back into the inflow face 5. > > > > What I would like to do is replace how the inflow plane is connected to the outflow plane. My idea was to use the connectivity matrix to figure out what the element numbers and outflow faces are at a certain distance away from the inflow plane, and use these faces to connect.?? The cross-section for the inflow and outflow plane would be the same, but you couldn't necessarily say that it is located, say inflow + 30 elements for example, OR that the outflow and inflow faces are all the same (face 5 for inflow, face 6 for outflow for example).?? > > > > Do you think this is possible? In a way, you would be creating a new connectivity matrix that governs the recycling BC. > > > > Thanks! > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: nek5000-users at lists. mcs . anl .gov > Sent: Wednesday, June 16, 2010 9:08:00 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Michael, Access to the connectivity array wouldn't help in this case, given that the recycling bc needs to establish a _new_ connectivity that has nothing to do with the existing one. The examples use this approach of establishing a new connectivity. I'm confident that we can make the existing approach for any mesh that can legitimally employ the recycling bc - i.e., any mesh that has the same cross-sectional distribution of elements at the two planes of interest. An alternative is to use the general purpose interpolation routines. There may (or may not) be a performance issue -- we're looking into this w/ the help of a summer student. Please let me know if I can assist you w/ your specific case. Paul > I am still trying to figure this idea out, but I think I would need to > access the connectivity/boundary condition information that is contained > in the rea file. Does anyone know the array, or what to call in order to > access this in the usr file??? Thanks again for a ny help! > > > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: " Nekton User List" > Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New Recycling BC method? > > > > > Hello All, > > > > I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)????? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. > > > > Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). > > > > I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. > > > > Regards, > > Michael M. > > > ?? > ___________________ ____________________________ 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 Jun 16 21:46:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 16 Jun 2010 21:46:16 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: Message-ID: <75064027.839461276742776976.JavaMail.root@neo-mail-3> Paul, The rea I have now from matlab/gambit has 960 elements.? Do you want me to create another, smaller rea that may make it easier to work with? The geometry by the way is a simple pipe flow. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, June 16, 2010 9:39:59 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] New Recycling BC method? Hi Micheal, I agree completely that it's best to avoid mix & match meshing. If you want to send me a gzipped .rea file produced by Gambit, I can take a look and see if I have any ideas. Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > Thanks for the reply.? The reason for the interest is due to the Gambit to Nek matlab code. We have had great success importing complex geometries with it, but now we run into the issue of the recycling boundary condition.? Gambit's ordering of the elements is not always consistent which?makes it impossible to use the current technique. > > > > Our solution was to create the portion that has the recycling in prex and then merge it with the complex part created in Gambit. However, this is proving to be very time consuming and troublesome (Element Mismatch Errors).? So, to avoid this I would like to come up with a new recycling?method that does not depend on the elements being in a specific order. My understanding is that the current method looks at the inflow, counts a certain number of elements up, copies this outflow from face?6 and puts it back into the inflow face 5. > > > > What I would like to do is replace how the inflow plane is connected to the outflow plane. My idea was to use the connectivity matrix to figure out what the element numbers and outflow faces are at a certain distance away from the inflow plane, and use these faces to connect.? The cross-section for the inflow and outflow plane would be the same, but you couldn't necessarily say that it is located, say inflow + 30 elements for example, OR that the outflow and inflow faces are all the same (face 5 for inflow, face 6 for outflow for example).? > > > > Do you think this is possible? In a way, you would be creating a new connectivity matrix that governs the recycling BC. > > > > Thanks! > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: nek5000-users at lists. mcs . anl .gov > Sent: Wednesday, June 16, 2010 9:08:00 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Michael, Access to the connectivity array wouldn't help in this case, given that the recycling bc needs to establish a _new_ connectivity that has nothing to do with the existing one. The examples use this approach of establishing a new connectivity. I'm confident that we can make the existing approach for any mesh that can legitimally employ the recycling bc - i.e., any mesh that has the same cross-sectional distribution of elements at the two planes of interest. An alternative is to use the general purpose interpolation routines. There may (or may not) be a performance issue -- we're looking into this w/ the help of a summer student. Please let me know if I can assist you w/ your specific case. Paul > I am still trying to figure this idea out, but I think I would need to > access the connectivity/boundary condition information that is contained > in the rea file. Does anyone know the array, or what to call in order to > access this in the usr file?? Thanks again for a ny help! > > > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: " Nekton User List" > Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New Recycling BC method? > > > > > Hello All, > > > > I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)??? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. > > > > Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). > > > > I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. > > > > Regards, > > Michael M. > > > ? > ___________________ ____________________________ 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 -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 16 21:47:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 16 Jun 2010 21:47:29 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: <75064027.839461276742776976.JavaMail.root@neo-mail-3> References: <75064027.839461276742776976.JavaMail.root@neo-mail-3> Message-ID: 960 is ok On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Paul, > > > > The rea I have now from matlab/gambit has 960 elements.?? Do you want me to create another, smaller rea that may make it easier to work with? > > > > The geometry by the way is a simple pipe flow. > > > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, 2010 9:39:59 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Micheal, I agree completely that it's best to avoid mix & match meshing. If you want to send me a gzipped .rea file produced by Gambit, I can take a look and see if I have any ideas. Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > Thanks for the reply.?? The reason for the interest is due to the Gambit to Nek matlab code. We have had great success importing complex geometries with it, but now we run into the issue of the recycling boundary condition.?? Gambit's ordering of the elements is not always consistent which??makes it impossible to use the current technique. > > > > Our solution was to create the portion that has the recycling in prex and then merge it with the complex part created in Gambit. However, this is proving to be very time consuming and troublesome (Element Mismatch Errors).?? So, to avoid this I would like to come up with a new recycling??method that does not depend on the elements being in a specific order. My u nderstanding is that the current method looks at the inflow, counts a certain number of elements up, copies this outflow from face??6 and puts it back into the inflow face 5. > > > > What I would like to do is replace how the inflow plane is connected to the outflow plane. My idea was to use the connectivity matrix to figure out what the element numbers and outflow faces are at a certain distance away from the inflow plane, and use these faces to connect.?? The cross-section for the inflow and outflow plane would be the same, but you couldn't necessarily say that it is located, say inflow + 30 elements for example, OR that the outflow and inflow faces are all the same (face 5 for inflow, face 6 for outflow for example).?? > > > > Do you think this is possible? In a way, you would be creating a new connectivity matrix that governs the recycling BC. > > > > Thanks! > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: nek5000-use rs at lists. mcs . anl .gov > Sent: Wednesday, June 16, 2010 9:08:00 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Michael, Access to the connectivity array wouldn't help in this case, given that the recycling bc needs to establish a _new_ connectivity that has nothing to do with the existing one. The examples use this approach of establishing a new connectivity. I'm confident that we can make the existing approach for any mesh that can legitimally employ the recycling bc - i.e., any mesh that has the same cross-sectional distribution of elements at the two planes of interest. An alternative is to use the general purpose interpolation routines. There may (or may not) be a performance issue -- we're looking into this w/ the help of a summer student. Please let me know if I can assist you w/ your specific case. Paul > I am still trying to figure this idea out, but I think I would need to > access the connectivity/boundary condition information that is contained > in the rea file. Does anyone know the array, or what to call in order to > access this in the usr file??? Thanks again for a ny help! > > > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: " Nekton User List" > Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New Recycling BC method? > > > > > Hello All, > > > > I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)????? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. > > > > Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). > > > > I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. > > > > Regards, > > Michael M. > > > ?? > ___________________ ____________________________ 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 Jun 16 21:52:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 16 Jun 2010 21:52:09 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: <1692141153.840581276743109707.JavaMail.root@neo-mail-3> Message-ID: <1719650562.840651276743128961.JavaMail.root@neo-mail-3> Paul, See attached for the rea. Thanks, Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, June 16, 2010 9:47:29 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] New Recycling BC method? 960 is ok On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Paul, > > > > The rea I have now from matlab/gambit has 960 elements.? Do you want me to create another, smaller rea that may make it easier to work with? > > > > The geometry by the way is a simple pipe flow. > > > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, 2010 9:39:59 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Micheal, I agree completely that it's best to avoid mix & match meshing. If you want to send me a gzipped .rea file produced by Gambit, I can take a look and see if I have any ideas. Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > Thanks for the reply.? The reason for the interest is due to the Gambit to Nek matlab code. We have had great success importing complex geometries with it, but now we run into the issue of the recycling boundary condition.? Gambit's ordering of the elements is not always consistent which?makes it impossible to use the current technique. > > > > Our solution was to create the portion that has the recycling in prex and then merge it with the complex part created in Gambit. However, this is proving to be very time consuming and troublesome (Element Mismatch Errors).? So, to avoid this I would like to come up with a new recycling?method that does not depend on the elements being in a specific order. My u nderstanding is that the current method looks at the inflow, counts a certain number of elements up, copies this outflow from face?6 and puts it back into the inflow face 5. > > > > What I would like to do is replace how the inflow plane is connected to the outflow plane. My idea was to use the connectivity matrix to figure out what the element numbers and outflow faces are at a certain distance away from the inflow plane, and use these faces to connect.? The cross-section for the inflow and outflow plane would be the same, but you couldn't necessarily say that it is located, say inflow + 30 elements for example, OR that the outflow and inflow faces are all the same (face 5 for inflow, face 6 for outflow for example).? > > > > Do you think this is possible? In a way, you would be creating a new connectivity matrix that governs the recycling BC. > > > > Thanks! > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: nek5000-use rs at lists. mcs . anl .gov > Sent: Wednesday, June 16, 2010 9:08:00 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Michael, Access to the connectivity array wouldn't help in this case, given that the recycling bc needs to establish a _new_ connectivity that has nothing to do with the existing one. The examples use this approach of establishing a new connectivity. I'm confident that we can make the existing approach for any mesh that can legitimally employ the recycling bc - i.e., any mesh that has the same cross-sectional distribution of elements at the two planes of interest. An alternative is to use the general purpose interpolation routines. There may (or may not) be a performance issue -- we're looking into this w/ the help of a summer student. Please let me know if I can assist you w/ your specific case. Paul > I am still trying to figure this idea out, but I think I would need to > access the connectivity/boundary condition information that is contained > in the rea file. Does anyone know the array, or what to call in order to > access this in the usr file?? Thanks again for a ny help! > > > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: " Nekton User List" > Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New Recycling BC method? > > > > > Hello All, > > > > I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)??? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. > > > > Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). > > > > I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. > > > > Regards, > > Michael M. > > > ? > ___________________ ____________________________ 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 _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GambitPipe.rea.gz Type: application/x-gzip Size: 52752 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 16 21:58:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 16 Jun 2010 21:58:53 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: <1719650562.840651276743128961.JavaMail.root@neo-mail-3> References: <1719650562.840651276743128961.JavaMail.root@neo-mail-3> Message-ID: Michael, got it... I should be able to send a fix by morning that will work for any instances in which slab at location A has same (arbitrary) topology orientation as slab at location B, as is the case in the example you sent. This won't cover all cases but would likely cover 90%. hth, Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Paul, > > > > See attached for the rea. Thanks, > > > > Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, 2010 9:47:29 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > 960 is ok On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Paul, > > > > The rea I have now from matlab/gambit has 960 elements.?? Do you want me to create another, smaller rea that may make it easier to work with? > > > > The geometry by the way is a simple pipe flow. > > > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, 2010 9:39:59 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Micheal, I agree completely that it's best to avoid mix & match meshing. If you want to send me a gzipped .rea file produced by Gambit, I can take a look and see if I have any ideas. Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > Thanks for the reply.?? The reason for the interest is due to the Gambit to Nek matlab code. We have had great success importing complex geometries with it, but no w we run into the issue of the recycling boundary condition.?? Gambit's ordering of the elements is not always consistent which??makes it impossible to use the current technique. > > > > Our solution was to create the portion that has the recycling in prex and then merge it with the complex part created in Gambit. However, this is proving to be very time consuming and troublesome (Element Mismatch Errors).?? So, to avoid this I would like to come up with a new recycling??method that does not depend on the elements being in a specific order. My u nderstanding is that the current method looks at the inflow, counts a certain number of elements up, copies this outflow from face??6 and puts it back into the inflow face 5. > > > > What I would like to do is replace how the inflow plane is connected to the outflow plane. My idea was to use the connectivity matrix to figure out what the element numbers and outflow faces are at a certain distance away from the inflow plane, and use t hese faces to connect.?? The cross-section for the inflow and outflow plane would be the same, but you couldn't necessarily say that it is located, say inflow + 30 elements for example, OR that the outflow and inflow faces are all the same (face 5 for inflow, face 6 for outflow for example).?? > > > > Do you think this is possible? In a way, you would be creating a new connectivity matrix that governs the recycling BC. > > > > Thanks! > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: nek5000-use rs at lists. mcs . anl .gov > Sent: Wednesday, June 16, 2010 9:08:00 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Michael, Access to the connectivity array wouldn't help in this case, given that the recycling bc needs to establish a _new_ connectivity that has nothing to do with the existing one. The examples use this approach of establishing a new connectivity. I'm confident that we ca n make the existing approach for any mesh that can legitimally employ the recycling bc - i.e., any mesh that has the same cross-sectional distribution of elements at the two planes of interest. An alternative is to use the general purpose interpolation routines. There may (or may not) be a performance issue -- we're looking into this w/ the help of a summer student. Please let me know if I can assist you w/ your specific case. Paul > I am still trying to figure this idea out, but I think I would need to > access the connectivity/boundary condition information that is contained > in the rea file. Does anyone know the array, or what to call in order to > access this in the usr file??? Thanks again for a ny help! > > > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: " Nekton User List" > Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New Recycling BC method? > > > > > Hello All, > > > > I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)????? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. > > > > Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). > > > > I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. > > > > Regards, > > Michael M. > > > ?? > ___________________ ____________________________ 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 > _______________________________________________ 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 Jun 16 22:00:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 16 Jun 2010 22:00:59 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: Message-ID: <1285751257.842531276743659787.JavaMail.root@neo-mail-3> Sounds great!? Thanks for looking into this! - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, June 16, 2010 9:58:53 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] New Recycling BC method? Michael, got it... I should be able to send a fix by morning that will work for any instances in which slab at location A has same (arbitrary) topology orientation as slab at location B, as is the case in the example you sent. This won't cover all cases but would likely cover 90%. hth, Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Paul, > > > > See attached for the rea. Thanks, > > > > Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, 2010 9:47:29 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > 960 is ok On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Paul, > > > > The rea I have now from matlab/gambit has 960 elements.? Do you want me to create another, smaller rea that may make it easier to work with? > > > > The geometry by the way is a simple pipe flow. > > > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, 2010 9:39:59 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Micheal, I agree completely that it's best to avoid mix & match meshing. If you want to send me a gzipped .rea file produced by Gambit, I can take a look and see if I have any ideas. Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > Thanks for the reply.? The reason for the interest is due to the Gambit to Nek matlab code. We have had great success importing complex geometries with it, but no w we run into the issue of the recycling boundary condition.? Gambit's ordering of the elements is not always consistent which?makes it impossible to use the current technique. > > > > Our solution was to create the portion that has the recycling in prex and then merge it with the complex part created in Gambit. However, this is proving to be very time consuming and troublesome (Element Mismatch Errors).? So, to avoid this I would like to come up with a new recycling?method that does not depend on the elements being in a specific order. My u nderstanding is that the current method looks at the inflow, counts a certain number of elements up, copies this outflow from face?6 and puts it back into the inflow face 5. > > > > What I would like to do is replace how the inflow plane is connected to the outflow plane. My idea was to use the connectivity matrix to figure out what the element numbers and outflow faces are at a certain distance away from the inflow plane, and use t hese faces to connect.? The cross-section for the inflow and outflow plane would be the same, but you couldn't necessarily say that it is located, say inflow + 30 elements for example, OR that the outflow and inflow faces are all the same (face 5 for inflow, face 6 for outflow for example).? > > > > Do you think this is possible? In a way, you would be creating a new connectivity matrix that governs the recycling BC. > > > > Thanks! > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: nek5000-use rs at lists. mcs . anl .gov > Sent: Wednesday, June 16, 2010 9:08:00 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Michael, Access to the connectivity array wouldn't help in this case, given that the recycling bc needs to establish a _new_ connectivity that has nothing to do with the existing one. The examples use this approach of establishing a new connectivity. I'm confident that we ca n make the existing approach for any mesh that can legitimally employ the recycling bc - i.e., any mesh that has the same cross-sectional distribution of elements at the two planes of interest. An alternative is to use the general purpose interpolation routines. There may (or may not) be a performance issue -- we're looking into this w/ the help of a summer student. Please let me know if I can assist you w/ your specific case. Paul > I am still trying to figure this idea out, but I think I would need to > access the connectivity/boundary condition information that is contained > in the rea file. Does anyone know the array, or what to call in order to > access this in the usr file?? Thanks again for a ny help! > > > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > To: " Nekton User List" > Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New Recycling BC method? > > > > > Hello All, > > > > I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)??? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. > > > > Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). > > > > I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. > > > > Regards, > > Michael M. > > > ? > ___________________ ____________________________ 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 > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Jun 20 13:26:28 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 20 Jun 2010 13:26:28 -0500 Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: <1285751257.842531276743659787.JavaMail.root@neo-mail-3> References: <1285751257.842531276743659787.JavaMail.root@neo-mail-3> Message-ID: Hi Paul, Were you able to find a solution for this? I was able to establish a new connectivity matrix for connecting an arbitrary inlet plane to an outflow plane that you specifiy by a number of elements. This could be called once at the beginning. I'm not sure how to use it though but it is a positive start. - Michael On Jun 16, 2010, at 10:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > Sounds great! Thanks for looking into this! > > > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, 2010 9:58:53 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Michael, got it... I should be able to send a fix by morning that > will work for any instances in which slab at location A has same > (arbitrary) topology orientation as slab at location B, as is the > case in the example you sent. This won't cover all cases but would > likely cover 90%. hth, Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov > wrote: > > > Paul, > > > > See attached for the rea. Thanks, > > > > > Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, > 2010 9:47:29 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000- > users] New Recycling BC method? > > 960 is ok On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov > wrote: > > > Paul, > > > > The rea I have now from matlab/gambit > has 960 elements. Do you want me to create another, smaller rea > that may make it easier to work with? > > > > The geometry by the > way is a simple pipe flow. > > > > - Michael > > > ----- Original > Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > > Sent: Wednesday, June 16, 2010 9:39:59 PM GMT -06:00 US/Canada > Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > > Hi Micheal, I agree completely that it's best to avoid mix & match > meshing. If you want to send me a gzipped .rea file produced by > Gambit, I can take a look and see if I have any ideas. Paul On Wed, > 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > > Thanks for the reply. The reason for the interest is due to > the Gambit to Nek matlab code. We have had great success importing > complex geometries with it, but no w we run into the issue of the > recycling boundary condition. Gambit's ordering of the elements is > not always consistent which makes it impossible to use the current > technique. > > > > Our solution was to create the portion that has > the recycling in prex and then merge it with the complex part > created in Gambit. However, this is proving to be very time > consuming and troublesome (Element Mismatch Errors). So, to avoid > this I would like to come up with a new recycling method that does > not depend on the elements being in a specific order. My u > nderstanding is that the current method looks at the inflow, counts > a certain number of elements up, copies this outflow from face 6 and > puts it back into the inflow face 5. > > > > What I would like to do > is replace how the inflow plane is connected to the outflow plane. > My idea was to use the connectivity matrix to figure out what the > element numbers and outflow faces are at a certain distance away > from the inflow plane, and use t hese faces to connect. The cross- > section for the inflow and outflow plane would be the same, but you > couldn't necessarily say that it is located, say inflow + 30 > elements for example, OR that the outflow and inflow faces are all > the same (face 5 for inflow, face 6 for outflow for example). > > > > > Do you think this is possible? In a way, you would be creating a > new connectivity matrix that governs the recycling BC. > > > > > Thanks! > > - Michael M. > > > ----- Original Message ----- > From: > nek5000-users at lists. mcs . anl .gov > To: nek5000-use rs at lists. > mcs . anl .gov > Sent: Wednesday, June 16, 2010 9:08:00 PM GMT > -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New > Recycling BC method? > > Hi Michael, Access to the connectivity > array wouldn't help in this case, given that the recycling bc needs > to establish a _new_ connectivity that has nothing to do with the > existing one. The examples use this approach of establishing a new > connectivity. I'm confident that we ca n make the existing approach > for any mesh that can legitimally employ the recycling bc - i.e., > any mesh that has the same cross-sectional distribution of elements > at the two planes of interest. An alternative is to use the general > purpose interpolation routines. There may (or may not) be a > performance issue -- we're looking into this w/ the help of a summer > student. Please let me know if I can assist you w/ your specific > case. Paul > I am still trying to figure this idea out, but I think > I would need to > access the connectivity/boundary condition > information that is contained > in the rea file. Does anyone know > the array, or what to call in order to > access this in the usr > file? Thanks again for a ny help! > > > > - Michael M. > > > ----- > Original Message ----- > From: nek5000-users at lists. mcs . anl .gov > > To: " Nekton User List" > Sent: Tuesday, June 15, 2010 9:02:00 PM > GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New > Recycling BC method? > > > > > Hello All, > > > > I am wondering if > there is another technique to set up a recycling boundary condition > that does not depend on the elements being in a certain order (say > based on element coordinates for instance)? I would like to pick > the recycling plane based on a given offset distance rather than a > number of elements. > > > > Also, the outflow plane faces may not > all necessarily be face 6 (and face 5 for the inflow plane). > > > > > I have tried going through the examples where a recycling BC is used > however I am finding it difficult to understand as my knowledge of > Fortan is still growing. Thanks for any help anyone can provide with > this idea. > > > > Regards, > > Michael M. > > > > > ___________________ ____________________________ 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 > > _______________________________________________ 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 -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Jun 20 20:12:14 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 20 Jun 2010 20:12:14 -0500 (CDT) Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: References: <1285751257.842531276743659787.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, We're working on an interpolation-based approach. >From the file you sent I can see that it could in general be confusing w/ the old approach. Paul PS - was the file you sent just a test, or for production purposes? I think more refinement near the walls would normally be in order. On Sun, 20 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Were you able to find a solution for this? > > I was able to establish a new connectivity matrix for connecting an > arbitrary inlet plane to an outflow plane that you specifiy by a number of > elements. This could be called once at the beginning. I'm not sure how to > use it though but it is a positive start. > > - Michael > > On Jun 16, 2010, at 10:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Sounds great! Thanks for looking into this! >> >> >> >> - Michael >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Wednesday, June 16, 2010 9:58:53 PM GMT -06:00 US/Canada Central >> Subject: Re: [Nek5000-users] New Recycling BC method? >> >> Michael, got it... I should be able to send a fix by morning that will >> work for any instances in which slab at location A has same (arbitrary) >> topology orientation as slab at location B, as is the case in the example >> you sent. This won't cover all cases but would likely cover 90%. hth, Paul >> On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Paul, > >> > > > See attached for the rea. Thanks, > > > > Michael > > > ----- >> Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: >> nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, 2010 9:47:29 >> PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New >> Recycling BC method? > > 960 is ok On Wed, 16 Jun 2010, >> nek5000-users at lists.mcs.anl.gov wrote: > > > Paul, > > > > The rea I have >> now from matlab/gambit has 960 elements. Do you want me to create >> another, smaller rea that may make it easier to work with? > > > > The >> geometry by the way is a simple pipe flow. > > > > - Michael > > > ----- >> Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: >> nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, 2010 9:39:59 >> PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New >> Recycling BC method? > > Hi Micheal, I agree completely that it's best to >> avoid mix & match meshing. If you want to send me a gzipped .rea file >> produced by Gambit, I can take a look and see if I have any ideas. Paul On >> Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > >> > > > Thanks for the reply. The reason for the interest is due to the >> Gambit to Nek matlab code. We have had great success importing complex >> geometries with it, but no w we run into the issue of the recycling >> boundary condition. Gambit's ordering of the elements is not always >> consistent which makes it impossible to use the current technique. > > > > >> Our solution was to create the portion that has the recycling in prex and >> then merge it with the complex part created in Gambit. However, this is >> proving to be very time consuming and troublesome (Element Mismatch >> Errors). So, to avoid this I would like to come up with a new recycling >> method that does not depend on the elements being in a specific order. My >> u nderstanding is that the current method looks at the inflow, counts a >> certain number of elements up, copies this outflow from face 6 and puts it >> back into the inflow face 5. > > > > What I would like to do is replace >> how the inflow plane is connected to the outflow plane. My idea was to use >> the connectivity matrix to figure out what the element numbers and outflow >> faces are at a certain distance away from the inflow plane, and use t hese >> faces to connect. The cross-section for the inflow and outflow plane >> would be the same, but you couldn't necessarily say that it is located, >> say inflow + 30 elements for example, OR that the outflow and inflow faces >> are all the same (face 5 for inflow, face 6 for outflow for example). > > >> > > Do you think this is possible? In a way, you would be creating a new >> connectivity matrix that governs the recycling BC. > > > > Thanks! > > - >> Michael M. > > > ----- Original Message ----- > From: nek5000-users at lists. >> mcs . anl .gov > To: nek5000-use rs at lists. mcs . anl .gov > Sent: >> Wednesday, June 16, 2010 9:08:00 PM GMT -06:00 US/Canada Central > >> Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Michael, >> Access to the connectivity array wouldn't help in this case, given that >> the recycling bc needs to establish a _new_ connectivity that has nothing >> to do with the existing one. The examples use this approach of >> establishing a new connectivity. I'm confident that we ca n make the >> existing approach for any mesh that can legitimally employ the recycling >> bc - i.e., any mesh that has the same cross-sectional distribution of >> elements at the two planes of interest. An alternative is to use the >> general purpose interpolation routines. There may (or may not) be a >> performance issue -- we're looking into this w/ the help of a summer >> student. Please let me know if I can assist you w/ your specific case. >> Paul > I am still trying to figure this idea out, but I think I would need >> to > access the connectivity/boundary condition information that is >> contained > in the rea file. Does anyone know the array, or what to call >> in order to > access this in the usr file? Thanks again for a ny help! > >> > > > - Michael M. > > > ----- Original Message ----- > From: >> nek5000-users at lists. mcs . anl .gov > To: " Nekton User List" > Sent: >> Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central > Subject: >> [Nek5000-users] New Recycling BC method? > > > > > Hello All, > > > > I am >> wondering if there is another technique to set up a recycling boundary >> condition that does not depend on the elements being in a certain order >> (say based on element coordinates for instance)? I would like to pick >> the recycling plane based on a given offset distance rather than a number >> of elements. > > > > Also, the outflow plane faces may not all necessarily >> be face 6 (and face 5 for the inflow plane). > > > > I have tried going >> through the examples where a recycling BC is used however I am finding it >> difficult to understand as my knowledge of Fortan is still growing. Thanks >> for any help anyone can provide with this idea. > > > > Regards, > > >> Michael M. > > > > ___________________ ____________________________ >> 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 > >> _______________________________________________ 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 Sun Jun 20 20:21:47 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 20 Jun 2010 20:21:47 -0500 Subject: [Nek5000-users] New Recycling BC method? In-Reply-To: References: <1285751257.842531276743659787.JavaMail.root@neo-mail-3> Message-ID: Hi Paul, It was for testing purposes. Thanks for the update! - Michael On Jun 20, 2010, at 8:12 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Michael, > > We're working on an interpolation-based approach. > >> From the file you sent I can see that it could in general > be confusing w/ the old approach. > > Paul > > PS - was the file you sent just a test, or for production > purposes? I think more refinement near the walls would > normally be in order. > > > > On Sun, 20 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Paul, >> >> Were you able to find a solution for this? >> >> I was able to establish a new connectivity matrix for connecting an >> arbitrary inlet plane to an outflow plane that you specifiy by a >> number of elements. This could be called once at the beginning. I'm >> not sure how to use it though but it is a positive start. >> >> - Michael >> >> On Jun 16, 2010, at 10:00 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Sounds great! Thanks for looking into this! >>> - Michael >>> ----- Original Message ----- >>> From: nek5000-users at lists.mcs.anl.gov >>> To: nek5000-users at lists.mcs.anl.gov >>> Sent: Wednesday, June 16, 2010 9:58:53 PM GMT -06:00 US/Canada >>> Central >>> Subject: Re: [Nek5000-users] New Recycling BC method? >>> Michael, got it... I should be able to send a fix by morning that >>> will work for any instances in which slab at location A has same >>> (arbitrary) topology orientation as slab at location B, as is the >>> case in the example you sent. This won't cover all cases but would >>> likely cover 90%. hth, Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov >>> wrote: > > > Paul, > > > > See attached for the rea. Thanks, > > >>> > > Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov >>> > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, >>> 2010 9:47:29 PM GMT -06:00 US/Canada Central > Subject: Re: >>> [Nek5000-users] New Recycling BC method? > > 960 is ok On Wed, 16 >>> Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Paul, > > > >>> > The rea I have now from matlab/gambit has 960 elements. Do you >>> want me to create another, smaller rea that may make it easier to >>> work with? > > > > The geometry by the way is a simple pipe flow. >>> > > > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov >>> > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, June 16, >>> 2010 9:39:59 PM GMT -06:00 US/Canada Central > Subject: Re: >>> [Nek5000-users] New Recycling BC method? > > Hi Micheal, I agree >>> completely that it's best to avoid mix & match meshing. If you >>> want to send me a gzipped .rea file produced by Gambit, I can take >>> a look and see if I have any ideas. Paul On Wed, 16 Jun 2010, nek5000-users at lists.mcs.anl.gov >>> wrote: > > > Hi Paul, > > > > Thanks for the reply. The reason >>> for the interest is due to the Gambit to Nek matlab code. We have >>> had great success importing complex geometries with it, but no w >>> we run into the issue of the recycling boundary condition. >>> Gambit's ordering of the elements is not always consistent which >>> makes it impossible to use the current technique. > > > > Our >>> solution was to create the portion that has the recycling in prex >>> and then merge it with the complex part created in Gambit. >>> However, this is proving to be very time consuming and troublesome >>> (Element Mismatch Errors). So, to avoid this I would like to come >>> up with a new recycling method that does not depend on the >>> elements being in a specific order. My u nderstanding is that the >>> current method looks at the inflow, counts a certain number of >>> elements up, copies this outflow from face 6 and puts it back into >>> the inflow face 5. > > > > What I would like to do is replace how >>> the inflow plane is connected to the outflow plane. My idea was to >>> use the connectivity matrix to figure out what the element numbers >>> and outflow faces are at a certain distance away from the inflow >>> plane, and use t hese faces to connect. The cross-section for the >>> inflow and outflow plane would be the same, but you couldn't >>> necessarily say that it is located, say inflow + 30 elements for >>> example, OR that the outflow and inflow faces are all the same >>> (face 5 for inflow, face 6 for outflow for example). > > > > Do >>> you think this is possible? In a way, you would be creating a new >>> connectivity matrix that governs the recycling BC. > > > > Thanks! >>> > > - Michael M. > > > ----- Original Message ----- > From: >>> nek5000-users at lists. mcs . anl .gov > To: nek5000-use rs at lists. >>> mcs . anl .gov > Sent: Wednesday, June 16, 2010 9:08:00 PM GMT >>> -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New >>> Recycling BC method? > > Hi Michael, Access to the connectivity >>> array wouldn't help in this case, given that the recycling bc >>> needs to establish a _new_ connectivity that has nothing to do >>> with the existing one. The examples use this approach of >>> establishing a new connectivity. I'm confident that we ca n make >>> the existing approach for any mesh that can legitimally employ the >>> recycling bc - i.e., any mesh that has the same cross-sectional >>> distribution of elements at the two planes of interest. An >>> alternative is to use the general purpose interpolation routines. >>> There may (or may not) be a performance issue -- we're looking >>> into this w/ the help of a summer student. Please let me know if I >>> can assist you w/ your specific case. Paul > I am still trying to >>> figure this idea out, but I think I would need to > access the >>> connectivity/boundary condition information that is contained > in >>> the rea file. Does anyone know the array, or what to call in order >>> to > access this in the usr file? Thanks again for a ny help! > > >>> > > - Michael M. > > > ----- Original Message ----- > From: >>> nek5000-users at lists. mcs . anl .gov > To: " Nekton User List" > >>> Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada >>> Central > Subject: [Nek5000-users] New Recycling BC method? > > > >>> > > Hello All, > > > > I am wondering if there is another >>> technique to set up a recycling boundary condition that does not >>> depend on the elements being in a certain order (say based on >>> element coordinates for instance)? I would like to pick the >>> recycling plane based on a given offset distance rather than a >>> number of elements. > > > > Also, the outflow plane faces may not >>> all necessarily be face 6 (and face 5 for the inflow plane). > > > >>> > I have tried going through the examples where a recycling BC is >>> used however I am finding it difficult to understand as my >>> knowledge of Fortan is still growing. Thanks for any help anyone >>> can provide with this idea. > > > > Regards, > > Michael M. > > >>> > > ___________________ ____________________________ 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 >>> > _______________________________________________ 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 > _______________________________________________ > 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 Jun 21 11:07:45 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 Jun 2010 11:07:45 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: <8398616.1714431277136461236.JavaMail.root@neo-mail-3> Message-ID: <1598223372.1714451277136465196.JavaMail.root@neo-mail-3> Hi, I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. - Michael M. Here is the output: test Input mesh tolerance (default 0.2): NOTE: smaller is better, but generous is more forgiving for bad meshes. .2 reading .rea file data ... start locglob_lexico: 8 60 480 0.20000000000000001 locglob: 1 1 480 locglob: 2 27 480 locglob: 3 42 480 locglob: 1 168 480 locglob: 2 168 480 locglob: 3 168 480 locglob: 1 168 480 locglob: 2 168 480 locglob: 3 168 480 done locglob_lexico: 168 168 480 4 start periodic vtx: 60 168 1 3 5 3 3.66325334E-04 1 shift 3 4 4 Matrix: x0 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 1 4 4 Matrix: x1 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 3 4 4 Matrix: z0 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 1 4 4 Matrix: z1 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.rea.gz Type: application/x-gzip Size: 7507 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 21 11:08:20 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 Jun 2010 11:08:20 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: <1598223372.1714451277136465196.JavaMail.root@neo-mail-3> References: <1598223372.1714451277136465196.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, I'll take a look... Paul On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. > > - Michael M. > > Here is the output: > > test > Input mesh tolerance (default 0.2): > NOTE: smaller is better, but generous is more forgiving for bad meshes. > .2 > reading .rea file data ... > start locglob_lexico: 8 60 480 0.20000000000000001 > locglob: 1 1 480 > locglob: 2 27 480 > locglob: 3 42 480 > locglob: 1 168 480 > locglob: 2 168 480 > locglob: 3 168 480 > locglob: 1 168 480 > locglob: 2 168 480 > locglob: 3 168 480 > done locglob_lexico: 168 168 480 4 > start periodic vtx: 60 168 > 1 3 5 3 3.66325334E-04 1 shift > 3 4 4 Matrix: x0 > 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 > 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 > 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 > 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 > 1 4 4 Matrix: x1 > 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 > 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 > 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 > 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 > 3 4 4 Matrix: z0 > 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 > 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 > 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 > 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 > 1 4 4 Matrix: z1 > 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 > 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 > 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 > 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 > 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL > 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL > > From nek5000-users at lists.mcs.anl.gov Mon Jun 21 20:11:33 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 03:11:33 +0200 Subject: [Nek5000-users] screen I/O Message-ID: <1277169093.3553.10.camel@localhost.localdomain> Hello all, Is there any simple way to reduce the amount of stuff written to the screen at each time step? When using many time steps, ~1e6, the size of the files gets pretty big. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Jun 21 20:20:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 Jun 2010 20:20:29 -0500 (CDT) Subject: [Nek5000-users] screen I/O In-Reply-To: <1277169093.3553.10.camel@localhost.localdomain> References: <1277169093.3553.10.camel@localhost.localdomain> Message-ID: Hi Frank, not at present, save commenting out the lines in question... Stefan and I have been discussing this and there will likely be a reduced mode in the future but at present we (or at least I) usually find the information too valuable w.r.t. debugging to do without. Paul On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, Is there any simple way to reduce the amount of stuff written to the screen at each time step? When using many time steps, ~1e6, the size of the files gets pretty big. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ 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 Jun 21 20:29:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 Jun 2010 21:29:21 -0400 Subject: [Nek5000-users] screen I/O In-Reply-To: References: <1277169093.3553.10.camel@localhost.localdomain> Message-ID: Hi neks, I've got a related question. Is there a way to write fewer points in a fld file, or to instruct VisIt to decrease the resolution? Visualization is becoming a bit computationally expensive with large fld files. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 21 20:35:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 Jun 2010 20:35:16 -0500 (CDT) Subject: [Nek5000-users] screen I/O In-Reply-To: References: <1277169093.3553.10.camel@localhost.localdomain> Message-ID: Hi David, There is a way, I believe, through some code that Aleks wrote - but I don't think this comes out in the std. nek format. Are you writing in binary, and writing only uvwpT ? (i.e., not writing the geometry in each file?) How frequently are you writing files ? Paul On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi neks, > > I've got a related question. Is there a way to write fewer points in a fld > file, or to instruct VisIt to decrease the resolution? Visualization is > becoming a bit computationally expensive with large fld files. > > Thanks, > > David > From nek5000-users at lists.mcs.anl.gov Mon Jun 21 20:40:30 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 Jun 2010 21:40:30 -0400 Subject: [Nek5000-users] screen I/O In-Reply-To: References: <1277169093.3553.10.camel@localhost.localdomain> Message-ID: Hi Paul, I'm not writing files very frequently; the problem is just the size of each file. I'm using the fld format. That's ASCII, right? How does one control whether the geometry is written in each file? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 22 00:27:39 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 00:27:39 -0500 (CDT) Subject: [Nek5000-users] screen I/O In-Reply-To: References: <1277169093.3553.10.camel@localhost.localdomain> Message-ID: Hi David, That can be binary, which is the std. In usrdat2, in your .usr file, set: param(66)=4 param(67)=4 Make certain that 'SIZE' and 'TOTAL' are included in that routine (which they normally would be). Paul On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > I'm not writing files very frequently; the problem is just the size of each > file. I'm using the fld format. That's ASCII, right? How does one control > whether the geometry is written in each file? > > Thanks, > > David > From nek5000-users at lists.mcs.anl.gov Tue Jun 22 01:47:35 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 01:47:35 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: <1598223372.1714451277136465196.JavaMail.root@neo-mail-3> References: <1598223372.1714451277136465196.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, It looks like the issue is related to the mesh and to tolerances. It appears to me that the periodic faces are not congruent - nearly so, but not 100%. I've changed my version of genmap to make the tolerance in the periodicity check reflect the user-prompted value. I'm not yet commiting this to the repo because I need to think more about the consequences. However, the attached code does work when you input ".1" for the tolerance prompt - and it flags an error when you put in .01 or smaller. Try diff'g this against your current version to see the change. Paul PS - rather than attaching, I'm placing in www.mcs.anl.gov/~fischer/genmap.f.gz On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. > > - Michael M. > > Here is the output: > > test > Input mesh tolerance (default 0.2): > NOTE: smaller is better, but generous is more forgiving for bad meshes. > .2 > reading .rea file data ... > start locglob_lexico: 8 60 480 0.20000000000000001 > locglob: 1 1 480 > locglob: 2 27 480 > locglob: 3 42 480 > locglob: 1 168 480 > locglob: 2 168 480 > locglob: 3 168 480 > locglob: 1 168 480 > locglob: 2 168 480 > locglob: 3 168 480 > done locglob_lexico: 168 168 480 4 > start periodic vtx: 60 168 > 1 3 5 3 3.66325334E-04 1 shift > 3 4 4 Matrix: x0 > 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 > 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 > 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 > 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 > 1 4 4 Matrix: x1 > 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 > 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 > 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 > 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 > 3 4 4 Matrix: z0 > 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 > 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 > 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 > 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 > 1 4 4 Matrix: z1 > 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 > 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 > 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 > 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 > 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL > 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL > > From nek5000-users at lists.mcs.anl.gov Tue Jun 22 05:00:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 12:00:58 +0200 Subject: [Nek5000-users] problem with turbCahnnel case Message-ID: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF527@EX7.d.ethz.ch> Hi Neks, I am a newbie and i am trying to learn Nek5000 from the examples. I run the TurbChannel case but i am not convinced by the results. If i plot the x velocity the results look fine but if i plot the y-velocity in an xz plane close to the wall (y=-0.9) the results show clear periodical patterns both in x and z that are believe are not Physical. Moreover these strong periodical structures coincide with the element's boundaries which is suspicious. I have tried to implement previous suggestions on the turbchannel case found on the mailing list( dt=0.025 and simple filtering) but i didn't notice improvements. Do you have any comments/suggestions on this? Do you think i am making a mistake in the plotting or in the settings ( i did a copy and paste of the case in the repository). Thank you for any help francesco -------------- next part -------------- A non-text attachment was scrubbed... Name: turbChannel20001.jpeg Type: image/jpeg Size: 79879 bytes Desc: turbChannel20001.jpeg URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 22 07:19:36 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 07:19:36 -0500 (CDT) Subject: [Nek5000-users] problem with turbCahnnel case In-Reply-To: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF527@EX7.d.ethz.ch> References: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF527@EX7.d.ethz.ch> Message-ID: Dear Francesco, Are you using 4 processors (or perhaps 8?) My guess is that the periodicity you're seeing is the imprint of the rand1 function on the initial conditions, which is not really random in this case since it gives the same result for each processor. Hence, you get this periodicity in the ICs. After you pass through transition, however, which typically occurs around a time of t ~ 150-200, the ICs are forgotten and you should end up w/ a nonperiodic problem. Paul On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Neks, > > I am a newbie and i am trying to learn Nek5000 from the examples. > > I run the TurbChannel case but i am not convinced by the results. > If i plot the x velocity the results look fine but if i plot the y-velocity in an xz plane close to the wall (y=-0.9) the results show clear periodical patterns both in x and z that are believe are not Physical. Moreover these strong periodical structures coincide with the element's boundaries which is suspicious. > > I have tried to implement previous suggestions on the turbchannel case found on the mailing list( dt=0.025 and simple filtering) > but i didn't notice improvements. > > Do you have any comments/suggestions on this? Do you think i am making a mistake in the plotting or in the settings ( i did a copy and paste of the case in the repository). > > Thank you for any help > francesco > From nek5000-users at lists.mcs.anl.gov Tue Jun 22 07:29:15 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 07:29:15 -0500 (CDT) Subject: [Nek5000-users] problem with turbCahnnel case In-Reply-To: References: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF527@EX7.d.ethz.ch> Message-ID: PS - note that you can circumvent the P-dependency by using a random number generator that is based on a P-independent generator. There is an example in the rayleigh/ray0.usr file in useric(). On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > Dear Francesco, > > Are you using 4 processors (or perhaps 8?) > > My guess is that the periodicity you're seeing is the imprint > of the rand1 function on the initial conditions, which is not > really random in this case since it gives the same result for > each processor. Hence, you get this periodicity in the ICs. > After you pass through transition, however, which typically > occurs around a time of t ~ 150-200, the ICs are forgotten > and you should end up w/ a nonperiodic problem. > > Paul > > > > On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> >> Hi Neks, >> >> I am a newbie and i am trying to learn Nek5000 from the examples. >> >> I run the TurbChannel case but i am not convinced by the results. >> If i plot the x velocity the results look fine but if i plot the y-velocity >> in an xz plane close to the wall (y=-0.9) the results show clear >> periodical patterns both in x and z that are believe are not Physical. >> Moreover these strong periodical structures coincide with the element's >> boundaries which is suspicious. >> >> I have tried to implement previous suggestions on the turbchannel case >> found on the mailing list( dt=0.025 and simple filtering) >> but i didn't notice improvements. >> >> Do you have any comments/suggestions on this? Do you think i am making a >> mistake in the plotting or in the settings ( i did a copy and paste of the >> case in the repository). >> >> Thank you for any help >> francesco >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue Jun 22 08:05:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 08:05:29 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: Message-ID: <995353536.1930071277211929696.JavaMail.root@neo-mail-3> Hi Paul, Is this tolerance used to check the physical coordinates of the periodic faces?? I was afraid that the faces might not be 100 % congruent, but the face cooridantes of the periodic sides should be within at least 0.01 I believe. I could be mistaken though. I am going to try another another geometry where the faces are not so extreme as in this case. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "Nekton User List" Sent: Tuesday, June 22, 2010 1:47:35 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Periodic BC & Genmap issue Hi Michael, It looks like the issue is related to the mesh and to tolerances. It appears to me that the periodic faces are not congruent - nearly so, but not 100%. I've changed my version of genmap to make the tolerance in the periodicity check reflect the user-prompted value. ?I'm not yet commiting this to the repo because I need to think more about the consequences. ?However, the attached code does work when you input ".1" for the tolerance prompt - and it flags an error when you put in .01 or smaller. ?Try diff'g this against your current version to see the change. Paul PS - rather than attaching, I'm placing in www.mcs.anl.gov/~fischer/genmap.f.gz On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. > > - Michael M. > > Here is the output: > > test > Input mesh tolerance (default 0.2): > NOTE: smaller is better, but generous is more forgiving for bad meshes. > .2 > reading .rea file data ... > start locglob_lexico: 8 60 480 0.20000000000000001 > locglob: 1 1 480 > locglob: 2 27 480 > locglob: 3 42 480 > locglob: 1 168 480 > locglob: 2 168 480 > locglob: 3 168 480 > locglob: 1 168 480 > locglob: 2 168 480 > locglob: 3 168 480 > done locglob_lexico: 168 168 480 4 > start periodic vtx: 60 168 > 1 3 5 3 3.66325334E-04 1 shift > 3 4 4 Matrix: x0 > 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 > 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 > 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 > 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 > 1 4 4 Matrix: x1 > 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 > 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 > 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 > 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 > 3 4 4 Matrix: z0 > 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 > 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 > 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 > 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 > 1 4 4 Matrix: z1 > 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 > 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 > 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 > 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 > 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL > 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 22 08:12:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 08:12:34 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: <995353536.1930071277211929696.JavaMail.root@neo-mail-3> References: <995353536.1930071277211929696.JavaMail.root@neo-mail-3> Message-ID: In fact, the tolerance was not previously used for the periodic check, only for the proximity check. The new code I sent propagates that tolerance into the periodic check -- diff against the old version and have a look, you'll see the structure. Let me know if you have any suggestions... Thanks! Paul On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > Is this tolerance used to check the physical coordinates of the periodic faces??? I was afraid that the faces might not be 100 % congruent, but the face cooridantes of the periodic sides should be within at least 0.01 I believe. I could be mistaken though. I am going to try another another geometry where the faces are not so extreme as in this case. > > > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, June 22, 2010 1:47:35 AM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] Periodic BC & Genmap issue > > > Hi Michael, > > It looks like the issue is related to the mesh and to tolerances. > It appears to me that the periodic faces are not congruent - nearly > so, but not 100%. > > I've changed my version of genmap to make the tolerance in the > periodicity check reflect the user-prompted value. ??I'm not yet > commiting this to the repo because I need to think more about the > consequences. ??However, the attached code does work when you input > ".1" for the tolerance prompt - and it flags an error when you put > in .01 or smaller. ??Try diff'g this against your current version > to see the change. > > Paul > > PS - rather than attaching, I'm placing in > www.mcs.anl.gov/~fischer/genmap.f.gz > > > On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. >> >> - Michael M. >> >> Here is the output: >> >> test >> Input mesh tolerance (default 0.2): >> NOTE: smaller is better, but generous is more forgiving for bad meshes. >> .2 >> reading .rea file data ... >> start locglob_lexico: 8 60 480 0.20000000000000001 >> locglob: 1 1 480 >> locglob: 2 27 480 >> locglob: 3 42 480 >> locglob: 1 168 480 >> locglob: 2 168 480 >> locglob: 3 168 480 >> locglob: 1 168 480 >> locglob: 2 168 480 >> locglob: 3 168 480 >> done locglob_lexico: 168 168 480 4 >> start periodic vtx: 60 168 >> 1 3 5 3 3.66325334E-04 1 shift >> 3 4 4 Matrix: x0 >> 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >> 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 >> 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 >> 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 >> 1 4 4 Matrix: x1 >> 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >> 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 >> 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 >> 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 >> 3 4 4 Matrix: z0 >> 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >> 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 >> 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 >> 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 >> 1 4 4 Matrix: z1 >> 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >> 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 >> 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 >> 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 >> 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL >> 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL >> >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue Jun 22 09:10:18 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 16:10:18 +0200 Subject: [Nek5000-users] problem with turbCahnnel case References: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF527@EX7.d.ethz.ch> Message-ID: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF529@EX7.d.ethz.ch> Thank you Paul, I run on 16 processors. I run the channel for much longer and I confirm that the periodicity starts to disappear at about time=65. Thank you francesco -----Original Message----- From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of nek5000-users at lists.mcs.anl.gov Sent: Tue 6/22/2010 2:29 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] problem with turbCahnnel case PS - note that you can circumvent the P-dependency by using a random number generator that is based on a P-independent generator. There is an example in the rayleigh/ray0.usr file in useric(). On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > Dear Francesco, > > Are you using 4 processors (or perhaps 8?) > > My guess is that the periodicity you're seeing is the imprint > of the rand1 function on the initial conditions, which is not > really random in this case since it gives the same result for > each processor. Hence, you get this periodicity in the ICs. > After you pass through transition, however, which typically > occurs around a time of t ~ 150-200, the ICs are forgotten > and you should end up w/ a nonperiodic problem. > > Paul > > > > On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> >> Hi Neks, >> >> I am a newbie and i am trying to learn Nek5000 from the examples. >> >> I run the TurbChannel case but i am not convinced by the results. >> If i plot the x velocity the results look fine but if i plot the y-velocity >> in an xz plane close to the wall (y=-0.9) the results show clear >> periodical patterns both in x and z that are believe are not Physical. >> Moreover these strong periodical structures coincide with the element's >> boundaries which is suspicious. >> >> I have tried to implement previous suggestions on the turbchannel case >> found on the mailing list( dt=0.025 and simple filtering) >> but i didn't notice improvements. >> >> Do you have any comments/suggestions on this? Do you think i am making a >> mistake in the plotting or in the settings ( i did a copy and paste of the >> case in the repository). >> >> Thank you for any help >> francesco >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Jun 22 10:21:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 10:21:58 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: Message-ID: <816536838.1958411277220118219.JavaMail.root@neo-mail-3> Paul, I am having trouble accessing the zipped file, when I try to decompress it tells me that it is not in gzip format. Perhaps try again, or another format? - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "Nekton User List" Sent: Tuesday, June 22, 2010 1:47:35 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Periodic BC & Genmap issue Hi Michael, It looks like the issue is related to the mesh and to tolerances. It appears to me that the periodic faces are not congruent - nearly so, but not 100%. I've changed my version of genmap to make the tolerance in the periodicity check reflect the user-prompted value. I'm not yet commiting this to the repo because I need to think more about the consequences. However, the attached code does work when you input ".1" for the tolerance prompt - and it flags an error when you put in .01 or smaller. Try diff'g this against your current version to see the change. Paul PS - rather than attaching, I'm placing in www.mcs.anl.gov/~fischer/genmap.f.gz On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. > > - Michael M. > > Here is the output: > > test > Input mesh tolerance (default 0.2): > NOTE: smaller is better, but generous is more forgiving for bad meshes. > .2 > reading .rea file data ... > start locglob_lexico: 8 60 480 0.20000000000000001 > locglob: 1 1 480 > locglob: 2 27 480 > locglob: 3 42 480 > locglob: 1 168 480 > locglob: 2 168 480 > locglob: 3 168 480 > locglob: 1 168 480 > locglob: 2 168 480 > locglob: 3 168 480 > done locglob_lexico: 168 168 480 4 > start periodic vtx: 60 168 > 1 3 5 3 3.66325334E-04 1 shift > 3 4 4 Matrix: x0 > 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 > 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 > 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 > 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 > 1 4 4 Matrix: x1 > 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 > 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 > 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 > 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 > 3 4 4 Matrix: z0 > 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 > 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 > 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 > 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 > 1 4 4 Matrix: z1 > 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 > 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 > 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 > 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 > 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL > 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 22 10:24:24 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 10:24:24 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: <816536838.1958411277220118219.JavaMail.root@neo-mail-3> References: <816536838.1958411277220118219.JavaMail.root@neo-mail-3> Message-ID: did you gunzip genmap.f.gz ? On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > > I am having trouble accessing the zipped file, when I try to decompress it tells me that it is not in gzip format. Perhaps try again, or another format? > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, June 22, 2010 1:47:35 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Periodic BC & Genmap issue > > > Hi Michael, > > It looks like the issue is related to the mesh and to tolerances. > It appears to me that the periodic faces are not congruent - nearly > so, but not 100%. > > I've changed my version of genmap to make the tolerance in the > periodicity check reflect the user-prompted value. I'm not yet > commiting this to the repo because I need to think more about the > consequences. However, the attached code does work when you input > ".1" for the tolerance prompt - and it flags an error when you put > in .01 or smaller. Try diff'g this against your current version > to see the change. > > Paul > > PS - rather than attaching, I'm placing in > www.mcs.anl.gov/~fischer/genmap.f.gz > > > On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. >> >> - Michael M. >> >> Here is the output: >> >> test >> Input mesh tolerance (default 0.2): >> NOTE: smaller is better, but generous is more forgiving for bad meshes. >> .2 >> reading .rea file data ... >> start locglob_lexico: 8 60 480 0.20000000000000001 >> locglob: 1 1 480 >> locglob: 2 27 480 >> locglob: 3 42 480 >> locglob: 1 168 480 >> locglob: 2 168 480 >> locglob: 3 168 480 >> locglob: 1 168 480 >> locglob: 2 168 480 >> locglob: 3 168 480 >> done locglob_lexico: 168 168 480 4 >> start periodic vtx: 60 168 >> 1 3 5 3 3.66325334E-04 1 shift >> 3 4 4 Matrix: x0 >> 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >> 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 >> 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 >> 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 >> 1 4 4 Matrix: x1 >> 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >> 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 >> 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 >> 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 >> 3 4 4 Matrix: z0 >> 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >> 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 >> 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 >> 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 >> 1 4 4 Matrix: z1 >> 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >> 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 >> 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 >> 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 >> 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL >> 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL >> >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue Jun 22 10:28:07 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 10:28:07 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: <816536838.1958411277220118219.JavaMail.root@neo-mail-3> References: <816536838.1958411277220118219.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, Try just grabbing "genmap.f" from the same locale... Paul On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > > I am having trouble accessing the zipped file, when I try to decompress it tells me that it is not in gzip format. Perhaps try again, or another format? > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, June 22, 2010 1:47:35 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Periodic BC & Genmap issue > > > Hi Michael, > > It looks like the issue is related to the mesh and to tolerances. > It appears to me that the periodic faces are not congruent - nearly > so, but not 100%. > > I've changed my version of genmap to make the tolerance in the > periodicity check reflect the user-prompted value. I'm not yet > commiting this to the repo because I need to think more about the > consequences. However, the attached code does work when you input > ".1" for the tolerance prompt - and it flags an error when you put > in .01 or smaller. Try diff'g this against your current version > to see the change. > > Paul > > PS - rather than attaching, I'm placing in > www.mcs.anl.gov/~fischer/genmap.f.gz > > > On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. >> >> - Michael M. >> >> Here is the output: >> >> test >> Input mesh tolerance (default 0.2): >> NOTE: smaller is better, but generous is more forgiving for bad meshes. >> .2 >> reading .rea file data ... >> start locglob_lexico: 8 60 480 0.20000000000000001 >> locglob: 1 1 480 >> locglob: 2 27 480 >> locglob: 3 42 480 >> locglob: 1 168 480 >> locglob: 2 168 480 >> locglob: 3 168 480 >> locglob: 1 168 480 >> locglob: 2 168 480 >> locglob: 3 168 480 >> done locglob_lexico: 168 168 480 4 >> start periodic vtx: 60 168 >> 1 3 5 3 3.66325334E-04 1 shift >> 3 4 4 Matrix: x0 >> 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >> 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 >> 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 >> 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 >> 1 4 4 Matrix: x1 >> 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >> 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 >> 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 >> 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 >> 3 4 4 Matrix: z0 >> 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >> 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 >> 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 >> 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 >> 1 4 4 Matrix: z1 >> 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >> 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 >> 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 >> 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 >> 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL >> 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL >> >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue Jun 22 10:39:01 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 10:39:01 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: Message-ID: <681754237.1962041277221141417.JavaMail.root@neo-mail-3> Paul, Yes I tried gzip and gunzip but it is telling me that it is not in a zipped format: gunzip genmap.f.gz gzip: genmap.f.gz: not in gzip format What do you mean by locale? ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Tuesday, June 22, 2010 10:24:24 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Periodic BC & Genmap issue did you gunzip genmap.f.gz ? On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > > I am having trouble accessing the zipped file, when I try to decompress it tells me that it is not in gzip format. Perhaps try again, or another format? > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, June 22, 2010 1:47:35 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Periodic BC & Genmap issue > > > Hi Michael, > > It looks like the issue is related to the mesh and to tolerances. > It appears to me that the periodic faces are not congruent - nearly > so, but not 100%. > > I've changed my version of genmap to make the tolerance in the > periodicity check reflect the user-prompted value. I'm not yet > commiting this to the repo because I need to think more about the > consequences. However, the attached code does work when you input > ".1" for the tolerance prompt - and it flags an error when you put > in .01 or smaller. Try diff'g this against your current version > to see the change. > > Paul > > PS - rather than attaching, I'm placing in > www.mcs.anl.gov/~fischer/genmap.f.gz > > > On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. >> >> - Michael M. >> >> Here is the output: >> >> test >> Input mesh tolerance (default 0.2): >> NOTE: smaller is better, but generous is more forgiving for bad meshes. >> .2 >> reading .rea file data ... >> start locglob_lexico: 8 60 480 0.20000000000000001 >> locglob: 1 1 480 >> locglob: 2 27 480 >> locglob: 3 42 480 >> locglob: 1 168 480 >> locglob: 2 168 480 >> locglob: 3 168 480 >> locglob: 1 168 480 >> locglob: 2 168 480 >> locglob: 3 168 480 >> done locglob_lexico: 168 168 480 4 >> start periodic vtx: 60 168 >> 1 3 5 3 3.66325334E-04 1 shift >> 3 4 4 Matrix: x0 >> 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >> 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 >> 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 >> 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 >> 1 4 4 Matrix: x1 >> 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >> 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 >> 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 >> 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 >> 3 4 4 Matrix: z0 >> 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >> 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 >> 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 >> 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 >> 1 4 4 Matrix: z1 >> 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >> 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 >> 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 >> 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 >> 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL >> 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL >> >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 22 10:40:57 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 10:40:57 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: <681754237.1962041277221141417.JavaMail.root@neo-mail-3> References: <681754237.1962041277221141417.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, not sure why gunzip didn't work - it worked here... but I've put the unzipped version in: www.mcs.anl.gov/~fischer/genmap.f Let me know if that works for you. Cheers, Paul On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > > Yes I tried gzip and gunzip but it is telling me that it is not in a zipped format: > > gunzip genmap.f.gz > gzip: genmap.f.gz: not in gzip format > > What do you mean by locale? > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Tuesday, June 22, 2010 10:24:24 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Periodic BC & Genmap issue > > > did you > > gunzip genmap.f.gz > > ? > > > On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Paul, >> >> I am having trouble accessing the zipped file, when I try to decompress it tells me that it is not in gzip format. Perhaps try again, or another format? >> >> - Michael >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: "Nekton User List" >> Sent: Tuesday, June 22, 2010 1:47:35 AM GMT -06:00 Guadalajara / Mexico City / Monterrey >> Subject: Re: [Nek5000-users] Periodic BC & Genmap issue >> >> >> Hi Michael, >> >> It looks like the issue is related to the mesh and to tolerances. >> It appears to me that the periodic faces are not congruent - nearly >> so, but not 100%. >> >> I've changed my version of genmap to make the tolerance in the >> periodicity check reflect the user-prompted value. I'm not yet >> commiting this to the repo because I need to think more about the >> consequences. However, the attached code does work when you input >> ".1" for the tolerance prompt - and it flags an error when you put >> in .01 or smaller. Try diff'g this against your current version >> to see the change. >> >> Paul >> >> PS - rather than attaching, I'm placing in >> www.mcs.anl.gov/~fischer/genmap.f.gz >> >> >> On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. >>> >>> - Michael M. >>> >>> Here is the output: >>> >>> test >>> Input mesh tolerance (default 0.2): >>> NOTE: smaller is better, but generous is more forgiving for bad meshes. >>> .2 >>> reading .rea file data ... >>> start locglob_lexico: 8 60 480 0.20000000000000001 >>> locglob: 1 1 480 >>> locglob: 2 27 480 >>> locglob: 3 42 480 >>> locglob: 1 168 480 >>> locglob: 2 168 480 >>> locglob: 3 168 480 >>> locglob: 1 168 480 >>> locglob: 2 168 480 >>> locglob: 3 168 480 >>> done locglob_lexico: 168 168 480 4 >>> start periodic vtx: 60 168 >>> 1 3 5 3 3.66325334E-04 1 shift >>> 3 4 4 Matrix: x0 >>> 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >>> 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 >>> 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 >>> 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 >>> 1 4 4 Matrix: x1 >>> 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >>> 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 >>> 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 >>> 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 >>> 3 4 4 Matrix: z0 >>> 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >>> 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 >>> 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 >>> 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 >>> 1 4 4 Matrix: z1 >>> 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >>> 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 >>> 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 >>> 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 >>> 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL >>> 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL >>> >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue Jun 22 10:44:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 22 Jun 2010 10:44:59 -0500 (CDT) Subject: [Nek5000-users] Periodic BC & Genmap issue In-Reply-To: Message-ID: <974675819.1963301277221499156.JavaMail.root@neo-mail-3> Hi, Yes, got it now. I don't know why it wasn't working either. I use the same thing to compress files, either way it's good now. Thanks Paul. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Tuesday, June 22, 2010 10:40:57 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Periodic BC & Genmap issue Hi Michael, not sure why gunzip didn't work - it worked here... but I've put the unzipped version in: www.mcs.anl.gov/~fischer/genmap.f Let me know if that works for you. Cheers, Paul On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > > Yes I tried gzip and gunzip but it is telling me that it is not in a zipped format: > > gunzip genmap.f.gz > gzip: genmap.f.gz: not in gzip format > > What do you mean by locale? > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Tuesday, June 22, 2010 10:24:24 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Periodic BC & Genmap issue > > > did you > > gunzip genmap.f.gz > > ? > > > On Tue, 22 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Paul, >> >> I am having trouble accessing the zipped file, when I try to decompress it tells me that it is not in gzip format. Perhaps try again, or another format? >> >> - Michael >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: "Nekton User List" >> Sent: Tuesday, June 22, 2010 1:47:35 AM GMT -06:00 Guadalajara / Mexico City / Monterrey >> Subject: Re: [Nek5000-users] Periodic BC & Genmap issue >> >> >> Hi Michael, >> >> It looks like the issue is related to the mesh and to tolerances. >> It appears to me that the periodic faces are not congruent - nearly >> so, but not 100%. >> >> I've changed my version of genmap to make the tolerance in the >> periodicity check reflect the user-prompted value. I'm not yet >> commiting this to the repo because I need to think more about the >> consequences. However, the attached code does work when you input >> ".1" for the tolerance prompt - and it flags an error when you put >> in .01 or smaller. Try diff'g this against your current version >> to see the change. >> >> Paul >> >> PS - rather than attaching, I'm placing in >> www.mcs.anl.gov/~fischer/genmap.f.gz >> >> >> On Mon, 21 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> I am running into an error when trying to use genmap. I believe it has to do with the periodic boundary conditions I have set up. I have checked the elements, and faces and indeed they are given correctly. This leads me to believe that there may be an issue with genmap. I have attached the rea file. This was to test the periodic faces for this geometry. The output is shown below, thanks for any help with this. >>> >>> - Michael M. >>> >>> Here is the output: >>> >>> test >>> Input mesh tolerance (default 0.2): >>> NOTE: smaller is better, but generous is more forgiving for bad meshes. >>> .2 >>> reading .rea file data ... >>> start locglob_lexico: 8 60 480 0.20000000000000001 >>> locglob: 1 1 480 >>> locglob: 2 27 480 >>> locglob: 3 42 480 >>> locglob: 1 168 480 >>> locglob: 2 168 480 >>> locglob: 3 168 480 >>> locglob: 1 168 480 >>> locglob: 2 168 480 >>> locglob: 3 168 480 >>> done locglob_lexico: 168 168 480 4 >>> start periodic vtx: 60 168 >>> 1 3 5 3 3.66325334E-04 1 shift >>> 3 4 4 Matrix: x0 >>> 1 x0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >>> 2 x0 -6.9998E-02 7.0969E-02 6.9026E-02 -6.9998E-02 >>> 3 x0 2.0879E-02 2.0879E-02 -2.0937E-02 -2.0821E-02 >>> 4 x0 8.3935E-03 8.0685E-03 -2.4856E-02 8.3935E-03 >>> 1 4 4 Matrix: x1 >>> 1 x1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >>> 2 x1 -7.0107E-02 -7.0107E-02 6.8930E-02 7.1286E-02 >>> 3 x1 2.0876E-02 -2.0824E-02 -2.0927E-02 2.0876E-02 >>> 4 x1 8.3867E-03 8.3867E-03 -2.4834E-02 8.0608E-03 >>> 3 4 4 Matrix: z0 >>> 1 z0 1.7389E-03 2.8363E-03 2.8363E-03 1.7389E-03 >>> 2 z0 -1.2500E+00 -1.1090E+00 -1.1110E+00 -1.2500E+00 >>> 3 z0 0.0000E+00 0.0000E+00 -4.1816E-02 -4.1700E-02 >>> 4 z0 -5.0620E-01 -5.0653E-01 -5.3945E-01 -5.0620E-01 >>> 1 4 4 Matrix: z1 >>> 1 z1 1.7389E-03 1.7389E-03 2.8351E-03 2.8351E-03 >>> 2 z1 -1.2500E+00 -1.2500E+00 -1.1110E+00 -1.1086E+00 >>> 3 z1 0.0000E+00 -4.1700E-02 -4.1803E-02 0.0000E+00 >>> 4 z1 4.9380E-01 4.9380E-01 4.6058E-01 4.9347E-01 >>> 3 4 3 1.00000000E-03 7.09692500E-02 abort: FACE MATCH FAIL >>> 1 3 5 7.09692500E-05 3.66325334E-04 abort: FACE MATCH FAIL >>> >>> >> _______________________________________________ >> 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 -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jun 24 09:16:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 16:16:55 +0200 Subject: [Nek5000-users] pressure boundary condition Message-ID: <4C2368D7.2040607@kit.edu> Dear NEKs, I wanted to ask which boundary condition is used for the pressure in nek?? are all pressure gradients normal to wall set tto zero?? because in my current simulation i have a pressure gradient normal to a wall and i am wondering why!? best, fred From nek5000-users at lists.mcs.anl.gov Thu Jun 24 09:29:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 09:29:27 -0500 (CDT) Subject: [Nek5000-users] pressure boundary condition In-Reply-To: <4C2368D7.2040607@kit.edu> References: <4C2368D7.2040607@kit.edu> Message-ID: Dear Fred, The pressure bcs are chosen to ensure div.U=0. For the Pn-Pn case, this involves addition of an appropriate inhomogeneity that cancels the b.l. divergence that arises from std. splitting formulations. For the Pn-Pn-2 case, there are no pressre bcs, only velocity bcs. Paul On Thu, 24 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear NEKs, > > I wanted to ask which boundary condition is used for the pressure in nek?? > are all pressure gradients normal to wall set tto zero?? because in my > current simulation i have a pressure gradient normal to a wall and i am > wondering why!? > > 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 Thu Jun 24 11:01:30 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 11:01:30 -0500 (CDT) Subject: [Nek5000-users] Conj HT problem w/ latest repo In-Reply-To: <2100881500.366751277395280479.JavaMail.root@neo-mail-3> Message-ID: <521011793.366851277395290197.JavaMail.root@neo-mail-3> Hi, I am having a problem running a conjugate heat transfer test case. I was able to get it to run with no problems on the repo I had (which I checked to be early 400's, 410 I believe, around April). I checked out the latest repo version and am now getting NaN values for Helmhotlz VEL X, Y, & Z. A few lines are shown below for Step 1. I have attached my case file. I am not sure what the issue is, nothing has changed other than the repo version I am now using. Thanks for any help. - Michael M. Starting time loop ... DT/DTCFL/DTFS/DTINIT 0.100E-01 0.293-316 0.247-322 0.100E-01 Step 1, t= 1.0000000E-02, DT= 1.0000000E-02, C= 0.000 0.0000E+00 0.0000E+00 Solving for heat Solving for fluid Temperature/Passive scalar solution 1.00000000000000002E-008 p22 1 2 New CG1-tolerance (RINIT*epsm) = 1.87930932840962565E-011 2.07249891917608222E-022 1 1 Helmholtz TEMP F: 1.8793E+02 1.0000E-08 1.0000E-01 1.0000E+02 1 2 Helmholtz TEMP F: 5.8007E+01 1.0000E-08 1.0000E-01 1.0000E+02 1 3 Helmholtz TEMP F: 1.9356E+01 1.0000E-08 1.0000E-01 1.0000E+02 1 4 Helmholtz TEMP F: 7.5782E+00 1.0000E-08 1.0000E-01 1.0000E+02 1 5 Helmholtz TEMP F: 2.7995E+00 1.0000E-08 1.0000E-01 1.0000E+02 1 6 Helmholtz TEMP F: 9.2434E-01 1.0000E-08 1.0000E-01 1.0000E+02 1 7 Helmholtz TEMP F: 3.6237E-01 1.0000E-08 1.0000E-01 1.0000E+02 1 8 Helmholtz TEMP F: 1.1048E-01 1.0000E-08 1.0000E-01 1.0000E+02 1 9 Helmholtz TEMP F: 3.2726E-02 1.0000E-08 1.0000E-01 1.0000E+02 1 10 Helmholtz TEMP F: 1.3437E-02 1.0000E-08 1.0000E-01 1.0000E+02 1 11 Helmholtz TEMP F: 4.3238E-03 1.0000E-08 1.0000E-01 1.0000E+02 1 12 Helmholtz TEMP F: 1.6986E-03 1.0000E-08 1.0000E-01 1.0000E+02 1 13 Helmholtz TEMP F: 6.5007E-04 1.0000E-08 1.0000E-01 1.0000E+02 1 14 Helmholtz TEMP F: 2.0208E-04 1.0000E-08 1.0000E-01 1.0000E+02 1 15 Helmholtz TEMP F: 6.5695E-05 1.0000E-08 1.0000E-01 1.0000E+02 1 16 Helmholtz TEMP F: 2.5632E-05 1.0000E-08 1.0000E-01 1.0000E+02 1 17 Helmholtz TEMP F: 8.2880E-06 1.0000E-08 1.0000E-01 1.0000E+02 1 18 Helmholtz TEMP F: 3.2190E-06 1.0000E-08 1.0000E-01 1.0000E+02 1 19 Helmholtz TEMP F: 1.1074E-06 1.0000E-08 1.0000E-01 1.0000E+02 1 20 Helmholtz TEMP F: 3.1244E-07 1.0000E-08 1.0000E-01 1.0000E+02 1 21 Helmholtz TEMP F: 1.2354E-07 1.0000E-08 1.0000E-01 1.0000E+02 1 22 Helmholtz TEMP F: 4.2673E-08 1.0000E-08 1.0000E-01 1.0000E+02 1 23 Helmholtz TEMP F: 1.5376E-08 1.0000E-08 1.0000E-01 1.0000E+02 1 24 Helmholtz TEMP F: 6.1053E-09 1.0000E-08 1.0000E-01 1.0000E+02 1 Hmholtz TEMP: 23 6.1053E-09 1.8793E+02 1.0000E-08 1 1.0000E-02 3.3134E-01 Heat done 1.00000000000000002E-008 p22 1 1 1 1 Helmholtz VELX F: NaN 1.0000E-08 1.0000E-02 1.0000E+02 1 2 Helmholtz VELX F: NaN 1.0000E-08 1.0000E-02 1.0000E+02 1 3 Helmholtz VELX F: NaN 1.0000E-08 1.0000E-02 1.0000E+02 1 4 Helmholtz VELX F: NaN 1.0000E-08 1.0000E-02 1.0000E+02 1 5 Helmholtz VELX F: NaN 1.0000E-08 1.0000E-02 1.0000E+02 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cht.tar Type: application/x-tar Size: 95928 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Thu Jun 24 11:22:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 11:22:03 -0500 Subject: [Nek5000-users] Periodic B.C and Genmap Issue Message-ID: Hi Paul, This post is in reference to the previous post by Michael (dated Jun 22). When I try to get a map file for a rea file that has periodic vertices, I get the following error. The rea file was generated the same way as before (Gambit -> Nek through Matlab). I checked on Matlab by plotting the periodic vertices and confirmed for a few faces that they are indeed periodic. Also, as you had earlier suggested (with the new genmap), I tried changing the tolerances fro 0.09 to 0.2 and I get the same periodic mismatch error. Could you provide any leads on where things are going wrong ? Please find below the error message. Thanks. Input (.rea) file name: domain Input mesh tolerance (default 0.2): NOTE: smaller is better, but generous is more forgiving for bad meshes. 0.09 reading .rea file data ... start locglob_lexico: 8 3912 31296 8.99999999999999967E-002 locglob: 1 1 31296 locglob: 2 36 31296 locglob: 3 1224 31296 locglob: 1 4851 31296 locglob: 2 4851 31296 locglob: 3 4851 31296 locglob: 1 4851 31296 locglob: 2 4851 31296 locglob: 3 4851 31296 done locglob_lexico: 4851 4851 31296 10 start periodic vtx: 3912 4851 abort: PERIODIC MISMATCH 2: 1093 1 P ie 0 1 je 4.14470000000000029E-003 0.0000000000000000 bc 8 quit Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jun 24 11:41:40 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 11:41:40 -0500 (CDT) Subject: [Nek5000-users] Periodic B.C and Genmap Issue In-Reply-To: References: Message-ID: Hi Shriram, What you need to do is to look at the genmap code for the "MISMATCH 2" flag and see what diagnositics are printed here. It seems that (perhaps) there is an issue w/ element 1093... ? Paul > 1093 1 P ie > 0 1 je On Thu, 24 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > This post is in reference to the previous post by Michael (dated Jun 22). > When I try to get a map file for a rea file that has periodic vertices, I > get the following error. The rea file was generated the same way as before > (Gambit -> Nek through Matlab). I checked on Matlab by plotting the periodic > vertices and confirmed for a few faces that they are indeed periodic. Also, > as you had earlier suggested (with the new genmap), I tried changing the > tolerances fro 0.09 to 0.2 and I get the same periodic mismatch error. Could > you provide any leads on where things are going wrong ? Please find below > the error message. Thanks. > > > Input (.rea) file name: > domain > Input mesh tolerance (default 0.2): > NOTE: smaller is better, but generous is more forgiving for bad meshes. > 0.09 > reading .rea file data ... > start locglob_lexico: 8 3912 31296 > 8.99999999999999967E-002 > locglob: 1 1 31296 > locglob: 2 36 31296 > locglob: 3 1224 31296 > locglob: 1 4851 31296 > locglob: 2 4851 31296 > locglob: 3 4851 31296 > locglob: 1 4851 31296 > locglob: 2 4851 31296 > locglob: 3 4851 31296 > done locglob_lexico: 4851 4851 31296 10 > start periodic vtx: 3912 4851 > > abort: PERIODIC MISMATCH 2: > 1093 1 P ie > 0 1 je > 4.14470000000000029E-003 0.0000000000000000 bc > > > 8 quit > > > > > Regards > Shriram > From nek5000-users at lists.mcs.anl.gov Thu Jun 24 12:08:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 12:08:58 -0500 Subject: [Nek5000-users] Periodic B.C and Genmap Issue In-Reply-To: References: Message-ID: Hi Paul, Thanks for the reply. I grep-ed to the source code and I think I found where the error is. Element 1093 (face 4 ) was the first periodic element that I have in my rea file and that is supposed to be periodic with element 1447 (face 4) . The line in my rea files reads as : P 1093 4 1447 4.00000 0.00000 0.00000 0.00000 It looks to me that genmap reads face 4 and element 1447 as 4.144700 (as seen from the error message). So, I changed the formatting a bit and it worked ! Just for future reference, could you let us know the exact spacing that is used in the rea file, specifically in the fluid boundary conditions. That would help us with Gambit-> Nek to handle periodic vertices as well. Thanks for your help. Regards Shriram Jagannathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jun 24 12:13:15 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 19:13:15 +0200 Subject: [Nek5000-users] Periodic B.C and Genmap Issue In-Reply-To: References: Message-ID: <0589552D-D6B6-467A-B574-126382C9E2FF@lav.mavt.ethz.ch> I think it makes more sense to go for a Gambit2Nek converter writing a .re2 file. Stefan On Jun 24, 2010, at 7:08 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Thanks for the reply. I grep-ed to the source code and I think I found where the error is. > Element 1093 (face 4 ) was the first periodic element that I have in my rea file and that is supposed to be periodic with element 1447 (face 4) . The line in my rea files reads as : > > P 1093 4 1447 4.00000 0.00000 0.00000 0.00000 > > It looks to me that genmap reads face 4 and element 1447 as 4.144700 (as seen from the error message). So, I changed the formatting a bit and it worked ! > > Just for future reference, could you let us know the exact spacing that is used in the rea file, specifically in the fluid boundary conditions. That would help us with Gambit-> Nek to handle periodic vertices as well. > > Thanks for your help. > > Regards > Shriram Jagannathan > _______________________________________________ > 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 Jun 24 12:24:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 19:24:25 +0200 Subject: [Nek5000-users] Periodic B.C and Genmap Issue References: Message-ID: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF52B@EX7.d.ethz.ch> Hi Paul, I am having a similar problem. I am trying to generate a mesh for a 3D periodic channel flow with periodic boundary conditions in x and z directions and walls on the y direction. I use genbox and then genmap. But i got the same error of Shriram. Note that i am having problems when i am using double periodic BCs : P ,P ,W ,W ,P ,P but single BCs works fine : P ,P ,W ,W ,W ,W W ,W ,W ,W ,P ,P W ,W ,P ,P ,W ,W Do you have a work around or a suggestion? Thank you francesco My error is reading .rea file data ... reading .re2 file data ... start locglob_lexico: 8 512 4096 0.2000000000000000 locglob: 1 1 4096 locglob: 2 9 4096 locglob: 3 81 4096 locglob: 1 729 4096 locglob: 2 729 4096 locglob: 3 729 4096 locglob: 1 729 4096 locglob: 2 729 4096 locglob: 3 729 4096 done locglob_lexico: 729 729 4096 8 start periodic vtx: 512 729 1 1 5 3 0.00000000E+00 1 shift abort: PERIODIC MISMATCH 2: 1 5 P ie 449 6 P je 449.0000000000000 0.0000000000000000E+000 bc My .box file is : turbChannel.rea 3 spatial dimension 1 number of fields # # comments: This is the box immediately behind the # refined cylinder in Ugo?s cyl+b.l. run. # # #======================================================== # Box 1 Pipe -8 -8 -8 Nelx Nely Nelz 0.0 6.28 1.0 x0 x1 ratio -1.0 1.0 1.0 y0 y1 ratio 0.0 3.14 1.0 z0 z1 ratio P ,P ,W ,W ,P ,P BC?s: (cbx0, cbx1, cby0, cby1, cbz0, cbz1) -----Original Message----- From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of nek5000-users at lists.mcs.anl.gov Sent: Thu 6/24/2010 6:22 PM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Periodic B.C and Genmap Issue Hi Paul, This post is in reference to the previous post by Michael (dated Jun 22). When I try to get a map file for a rea file that has periodic vertices, I get the following error. The rea file was generated the same way as before (Gambit -> Nek through Matlab). I checked on Matlab by plotting the periodic vertices and confirmed for a few faces that they are indeed periodic. Also, as you had earlier suggested (with the new genmap), I tried changing the tolerances fro 0.09 to 0.2 and I get the same periodic mismatch error. Could you provide any leads on where things are going wrong ? Please find below the error message. Thanks. Input (.rea) file name: domain Input mesh tolerance (default 0.2): NOTE: smaller is better, but generous is more forgiving for bad meshes. 0.09 reading .rea file data ... start locglob_lexico: 8 3912 31296 8.99999999999999967E-002 locglob: 1 1 31296 locglob: 2 36 31296 locglob: 3 1224 31296 locglob: 1 4851 31296 locglob: 2 4851 31296 locglob: 3 4851 31296 locglob: 1 4851 31296 locglob: 2 4851 31296 locglob: 3 4851 31296 done locglob_lexico: 4851 4851 31296 10 start periodic vtx: 3912 4851 abort: PERIODIC MISMATCH 2: 1093 1 P ie 0 1 je 4.14470000000000029E-003 0.0000000000000000 bc 8 quit Regards Shriram From nek5000-users at lists.mcs.anl.gov Thu Jun 24 12:25:43 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 12:25:43 -0500 Subject: [Nek5000-users] Periodic B.C and Genmap Issue In-Reply-To: <0589552D-D6B6-467A-B574-126382C9E2FF@lav.mavt.ethz.ch> References: <0589552D-D6B6-467A-B574-126382C9E2FF@lav.mavt.ethz.ch> Message-ID: Hi Stefan, I am not very familiar with the re2 format yet. I tried converting my rea file to re2 file and I still see that the error w/ formatting appears. Do you reckon writing in re2 format right out of Matlab ? If yes, could you give us any reference on how its structured ? Regards Shriram Jagannathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jun 24 12:29:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 19:29:06 +0200 Subject: [Nek5000-users] Periodic B.C and Genmap Issue In-Reply-To: References: <0589552D-D6B6-467A-B574-126382C9E2FF@lav.mavt.ethz.ch> Message-ID: Yes, your tool should write out a .re2 file! I'll try to write something. Stefan On Jun 24, 2010, at 7:25 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > I am not very familiar with the re2 format yet. I tried converting my rea file to re2 file and I still see that the error w/ formatting appears. Do you reckon writing in re2 format right out of Matlab ? If yes, could you give us any reference on how its structured ? > > Regards > Shriram Jagannathan > > > > _______________________________________________ > 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 Jun 24 12:30:39 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 12:30:39 -0500 Subject: [Nek5000-users] Periodic B.C and Genmap Issue In-Reply-To: References: <0589552D-D6B6-467A-B574-126382C9E2FF@lav.mavt.ethz.ch> Message-ID: Thanks a lot. That would certainly help us. Regards Shriram Jagannathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jun 24 13:29:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 13:29:04 -0500 (CDT) Subject: [Nek5000-users] Periodic B.C and Genmap Issue In-Reply-To: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF52B@EX7.d.ethz.ch> References: <746FBEEC05A8CC4B96669D2DDDEEAD27014FF52B@EX7.d.ethz.ch> Message-ID: There should normally be two spaces after each bc in genbox. Regarding format in the .rea file, this is a problem with mixed characters + numbers on the same input line, particularly when the input character string supports blanks. I typically resolve the issue by looking at the source. In this case, connect2.f in the nek/ repo indicates: IF (NELGT.LT.1000) THEN READ(9,50,ERR=500,END=500) $ CHTEMP, $ CBC(ISIDE,IEL,IFIELD),ID1,ID2, $ (BC(II,ISIDE,IEL,IFIELD),II=1,NBCREA) 50 FORMAT(A1,A3,2I3,5G14.6) ELSEIF (NELGT.LT.100000) THEN READ(9,51,ERR=500,END=500) $ CHTEMP, $ CBC(ISIDE,IEL,IFIELD),ID1,ID2, $ (BC(II,ISIDE,IEL,IFIELD),II=1,NBCREA) 51 FORMAT(A1,A3,I5,I1,5G14.6) ELSEIF (NELGT.LT.1000000) THEN READ(9,52,ERR=500,END=500) $ CHTEMP, $ CBC(ISIDE,IEL,IFIELD),ID1, $ (BC(II,ISIDE,IEL,IFIELD),II=1,NBCREA) 52 FORMAT(A1,A3,I6,5G14.6) ELSE ... Paul On Thu, 24 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > I am having a similar problem. > I am trying to generate a mesh for a 3D periodic channel flow with periodic > boundary conditions in x and z directions and walls on the y direction. > I use genbox and then genmap. But i got the same error of Shriram. > Note that i am having problems when i am using double periodic BCs : > P ,P ,W ,W ,P ,P > but single BCs works fine : > P ,P ,W ,W ,W ,W > W ,W ,W ,W ,P ,P > W ,W ,P ,P ,W ,W > > Do you have a work around or a suggestion? > > Thank you > francesco > > > > My error is > > > reading .rea file data ... > reading .re2 file data ... > start locglob_lexico: 8 512 4096 > 0.2000000000000000 > locglob: 1 1 4096 > locglob: 2 9 4096 > locglob: 3 81 4096 > locglob: 1 729 4096 > locglob: 2 729 4096 > locglob: 3 729 4096 > locglob: 1 729 4096 > locglob: 2 729 4096 > locglob: 3 729 4096 > done locglob_lexico: 729 729 4096 8 > start periodic vtx: 512 729 > 1 1 5 3 0.00000000E+00 1 shift > > abort: PERIODIC MISMATCH 2: > 1 5 P ie > 449 6 P je > 449.0000000000000 0.0000000000000000E+000 bc > > > My .box file is : > > > turbChannel.rea > 3 spatial dimension > 1 number of fields > # > # comments: This is the box immediately behind the > # refined cylinder in Ugo?s cyl+b.l. run. > # > # > #======================================================== > # > Box 1 Pipe > -8 -8 -8 Nelx Nely Nelz > 0.0 6.28 1.0 x0 x1 ratio > -1.0 1.0 1.0 y0 y1 ratio > 0.0 3.14 1.0 z0 z1 ratio > P ,P ,W ,W ,P ,P BC?s: (cbx0, cbx1, cby0, cby1, cbz0, cbz1) > > > > > > > > -----Original Message----- > From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of nek5000-users at lists.mcs.anl.gov > Sent: Thu 6/24/2010 6:22 PM > To: nek5000-users at lists.mcs.anl.gov > Subject: [Nek5000-users] Periodic B.C and Genmap Issue > > Hi Paul, > > This post is in reference to the previous post by Michael (dated Jun 22). > When I try to get a map file for a rea file that has periodic vertices, I > get the following error. The rea file was generated the same way as before > (Gambit -> Nek through Matlab). I checked on Matlab by plotting the periodic > vertices and confirmed for a few faces that they are indeed periodic. Also, > as you had earlier suggested (with the new genmap), I tried changing the > tolerances fro 0.09 to 0.2 and I get the same periodic mismatch error. Could > you provide any leads on where things are going wrong ? Please find below > the error message. Thanks. > > > Input (.rea) file name: > domain > Input mesh tolerance (default 0.2): > NOTE: smaller is better, but generous is more forgiving for bad meshes. > 0.09 > reading .rea file data ... > start locglob_lexico: 8 3912 31296 > 8.99999999999999967E-002 > locglob: 1 1 31296 > locglob: 2 36 31296 > locglob: 3 1224 31296 > locglob: 1 4851 31296 > locglob: 2 4851 31296 > locglob: 3 4851 31296 > locglob: 1 4851 31296 > locglob: 2 4851 31296 > locglob: 3 4851 31296 > done locglob_lexico: 4851 4851 31296 10 > start periodic vtx: 3912 4851 > > abort: PERIODIC MISMATCH 2: > 1093 1 P ie > 0 1 je > 4.14470000000000029E-003 0.0000000000000000 bc > > > 8 quit > > > > > Regards > Shriram > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Jun 24 14:11:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Jun 2010 14:11:58 -0500 (CDT) Subject: [Nek5000-users] Conj HT problem w/ latest repo In-Reply-To: <521011793.366851277395290197.JavaMail.root@neo-mail-3> Message-ID: <160354752.415811277406718213.JavaMail.root@neo-mail-3> Hi again, I believe I found the issue, something was wrong with my SIZE file. I am not sure at what point but I must have mistakenly done something to it without re alizing. It seems to be working now. ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "Nekton User List" Sent: Thursday, June 24, 2010 11:01:30 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: [Nek5000-users] Conj HT problem w/ latest repo Hi, I am having a problem running a conjugate heat transfer test case. I was able to get it to run with no problems on the repo I had (which I checked to be early 400's, 410 I believe, around April). I checked out the latest repo version and am now getting NaN values for Helmhotlz VEL X, Y, & Z. A few lines are shown below for Step 1. I have attached my case file. I am not sure what the issue is, nothing has changed other than the repo version I am now using. Thanks for any help. - Michael M. Starting time loop ... DT/DTCFL/DTFS/DTINIT 0.100E-01 0.293-316 0.247-322 0.100E-01 Step 1, t= 1.0000000E-02, DT= 1.0000000E-02, C= 0.000 0.0000E+00 0.0000E+00 Solving for heat Solving for fluid Temperature/Passive scalar solution 1.00000000000000002E-008 p22 1 2 New CG1-tolerance (RINIT*epsm) = 1.87930932840962565E-011 2.07249891917608222E-022 1 1 Helmholtz TEMP F: 1.8793E+02 1.0000E-08 1.0000E-01 1.0000E+02 1 2 Helmholtz TEMP F: 5.8007E+01 1.0000E-08 1.0000E-01 1.0000E+02 1 3 Helmholtz TEMP F: 1.9356E+01 1.0000E-08 1.0000E-01 1.0000E+02 1 4 Helmholtz TEMP F: 7.5782E+00 1.0000E-08 1.0000E-01 1.0000E+02 1 5 Helmholtz TEMP F: 2.7995E+00 1.0000E-08 1.0000E-01 1.0000E+02 1 6 Helmholtz TEMP F: 9.2434E-01 1.0000E-08 1.0000E-01 1.0000E+02 1 7 Helmholtz TEMP F: 3.6237E-01 1.0000E-08 1.0000E-01 1.0000E+02 1 8 Helmholtz TEMP F: 1.1048E-01 1.0000E-08 1.0000E-01 1.0000E+02 1 9 Helmholtz TEMP F: 3.2726E-02 1.0000E-08 1.0000E-01 1.0000E+02 1 10 Helmholtz TEMP F: 1.3437E-02 1.0000E-08 1.0000E-01 1.0000E+02 1 11 Helmholtz TEMP F: 4.3238E-03 1.0000E-08 1.0000E-01 1.0000E+02 1 12 Helmholtz TEMP F: 1.6986E-03 1.0000E-08 1.0000E-01 1.0000E+02 1 13 Helmholtz TEMP F: 6.5007E-04 1.0000E-08 1.0000E-01 1.0000E+02 1 14 Helmholtz TEMP F: 2.0208E-04 1.0000E-08 1.0000E-01 1.0000E+02 1 15 Helmholtz TEMP F: 6.5695E-05 1.0000E-08 1.0000E-01 1.0000E+02 1 16 Helmholtz TEMP F: 2.5632E-05 1.0000E-08 1.0000E-01 1.0000E+02 1 17 Helmholtz TEMP F: 8.2880E-06 1.0000E-08 1.0000E-01 1.0000E+02 1 18 Helmholtz TEMP F: 3.2190E-06 1.0000E-08 1.0000E-01 1.0000E+02 1 19 Helmholtz TEMP F: 1.1074E-06 1.0000E-08 1.0000E-01 1.0000E+02 1 20 Helmholtz TEMP F: 3.1244E-07 1.0000E-08 1.0000E-01 1.0000E+02 1 21 Helmholtz TEMP F: 1.2354E-07 1.0000E-08 1.0000E-01 1.0000E+02 1 22 Helmholtz TEMP F: 4.2673E-08 1.0000E-08 1.0000E-01 1.0000E+02 1 23 Helmholtz TEMP F: 1.5376E-08 1.0000E-08 1.0000E-01 1.0000E+02 1 24 Helmholtz TEMP F: 6.1053E-09 1.0000E-08 1.0000E-01 1.0000E+02 1 Hmholtz TEMP: 23 6.1053E-09 1.8793E+02 1.0000E-08 1 1.0000E-02 3.3134E-01 Heat done 1.00000000000000002E-008 p22 1 1 1 1 Helmholtz VELX F: NaN 1.0000E-08 1.0000E-02 1.0000E+02 1 2 Helmholtz VELX F: NaN 1.0000E-08 1.0000E-02 1.0000E+02 1 3 Helmholtz VELX F: NaN 1.0000E-08 1.0000E-02 1.0000E+02 1 4 Helmholtz VELX F: NaN 1.0000E-08 1.0000E-02 1.0000E+02 1 5 Helmholtz VELX F: NaN 1.0000E-08 1.0000E-02 1.0000E+02 _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 25 10:21:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 25 Jun 2010 10:21:48 -0500 Subject: [Nek5000-users] E INVALID BC FOUND in genfast Message-ID: Hi all, I am getting the following error when I try to run nek : *0 3912 BC FAIL* *EXIT: E INVALID BC FOUND in genfast 3912* * * I grep-ed to the source code to get an idea of what the error actually means, but I couldn't comprehend whats going on in the code (fast3d.f) . Could anybody tell me what this error actually means ? I checked the Boundary condition of the particular element (3912) and everything seems to be OK. Thanks for any help. Regards Shriram Jagannathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 25 13:39:43 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 25 Jun 2010 13:39:43 -0500 (CDT) Subject: [Nek5000-users] E INVALID BC FOUND in genfast In-Reply-To: References: Message-ID: Shriram, It's indicating that one of the bcs for element 3912 is not valid. What are those? Paul On Fri, 25 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi all, > > I am getting the following error when I try to run nek : > > *0 3912 BC FAIL* > *EXIT: E INVALID BC FOUND in genfast 3912* > > * > * > I grep-ed to the source code to get an idea of what the error actually > means, but I couldn't comprehend whats going on in the code (fast3d.f) . > Could anybody tell me what this error actually means ? I checked the > Boundary condition of the particular element (3912) and everything seems to > be OK. > Thanks for any help. > > Regards > Shriram Jagannathan > From nek5000-users at lists.mcs.anl.gov Fri Jun 25 16:06:02 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 25 Jun 2010 23:06:02 +0200 Subject: [Nek5000-users] file name size restriction Message-ID: <1277499962.8950.64.camel@localhost.localdomain> Hello all, There appears to be a restriction on the length of directory/file names: Beginning session: /hpc_home/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-18 timer accuracy: 0.0000000E+00 sec read .rea file forrtl: No such file or directory forrtl: severe (29): file not found, unit 9, file /hpc_home/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-m-0-dt-2.8e-4-time-100.0-N-8-Intel/delet.re As using long and descriptive names helps to recall what one did six months ago or so, would it be possible to increase the name length limit? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Sun Jun 27 11:10:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 27 Jun 2010 21:40:55 +0530 Subject: [Nek5000-users] [*] Re: MHD In-Reply-To: References: <4BF147B3.3060700@iitk.ac.in> Message-ID: <4C27780F.4040108@iitk.ac.in> Hi Aleks, Any pointer to the switches that one needs to turn on to solve for MHD using Nek5000? Thanks, Mani chandra On 05/17/2010 11:29 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Mani, > > I'll set up an MHD example. > > Best, > Aleks > > > On Mon, 17 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Paul and Stephan, >> >> I'd like to know how to setup nek5000 to solve for MHD equations. >> Maybe an example? >> >> 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 > From nek5000-users at lists.mcs.anl.gov Sun Jun 27 19:14:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 27 Jun 2010 19:14:49 -0500 Subject: [Nek5000-users] Turbjet/Recycling b.c and PNPN-2 basis Message-ID: Hello, I tried simulating the jet example with PnPn formulation and with a restart from a previous simulation with PnPn-2. With PnPn, I find that the recycling boundary condition and the velocity values are way off. The reason why I tried jet example w/ PnPn is because I am using the recycling b/c in a very similar way as the jet example and that too showed similar findings (with velocities being way off .. ). Is this because of the recycling b.c or because of the restart from PnPn-2 to PnPn ? I have attached the contours for both the PnPn and PnPn-2 versions herewith. Any hints would be very useful. Thanks. Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PNPN.png Type: image/png Size: 80610 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PNPN_2.png Type: image/png Size: 70819 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 28 22:56:56 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 28 Jun 2010 22:56:56 -0500 (CDT) Subject: [Nek5000-users] [*] Re: MHD In-Reply-To: <9992845.1205731277783331690.JavaMail.root@zimbra> Message-ID: <28003555.1205771277783816717.JavaMail.root@zimbra> Hi Mani, There are several things you have to do to get MHD working SIZE: lbx1=lx1, etc. lbx2=lx2, etc. lbelv=lelv,lbelt=lelt ldimt=2 ! at least -- when there are no passive scalars .rea/.re2: p29 = -Rm ! magnetic Reynolds number Boundary conditions for temperature (dummy field) and magnetic field .usr: in userchk... ifheat = .false. ! unless you are also solving for heat/passive scalar advection-diffusion equation if (istep.gt.0.and.mod(istep,iostep).eq.0) $ call outpost(bx,by,bz,pm,t,' ') ! dumps B-field as velocity field into .f/.fld files with even numbers in userbc/useric... set B-field through something like if (ifield.eq.1) then ux = -sys ! Velocity components uy = -cxc uz = sxc + cys elseif (ifield.eq.ifldmhd) then ! Magnetic field ux = eps*sin(y)*sin(0.57*z) uy = 0. uz = 0. endif I am still working on 3D MHD example Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Sunday, June 27, 2010 11:10:55 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] [*] Re: MHD Hi Aleks, Any pointer to the switches that one needs to turn on to solve for MHD using Nek5000? Thanks, Mani chandra On 05/17/2010 11:29 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Mani, > > I'll set up an MHD example. > > Best, > Aleks > > > On Mon, 17 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Paul and Stephan, >> >> I'd like to know how to setup nek5000 to solve for MHD equations. >> Maybe an example? >> >> 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 > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Jun 29 00:36:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 29 Jun 2010 11:06:23 +0530 Subject: [Nek5000-users] [*] Re: [*] Re: MHD In-Reply-To: <28003555.1205771277783816717.JavaMail.root@zimbra> References: <28003555.1205771277783816717.JavaMail.root@zimbra> Message-ID: <4C298657.1090809@iitk.ac.in> Thanks for the reply Alex. I'll await your example. Regards, Mani On 06/29/2010 09:26 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Mani, > > > There are several things you have to do to get MHD working > > > SIZE: > > lbx1=lx1, etc. > lbx2=lx2, etc. > lbelv=lelv,lbelt=lelt > > ldimt=2 ! at least -- when there are no passive scalars > > > > .rea/.re2: > > p29 = -Rm ! magnetic Reynolds number > > > Boundary conditions for temperature (dummy field) and magnetic field > > > > .usr: > > in userchk... > > ifheat = .false. ! unless you are also solving for heat/passive scalar advection-diffusion equation > > > if (istep.gt.0.and.mod(istep,iostep).eq.0) > $ call outpost(bx,by,bz,pm,t,' ') ! dumps B-field as velocity field into .f/.fld files with even numbers > > > in userbc/useric... > > set B-field through something like > > if (ifield.eq.1) then > > ux = -sys ! Velocity components > uy = -cxc > uz = sxc + cys > > elseif (ifield.eq.ifldmhd) then ! Magnetic field > > ux = eps*sin(y)*sin(0.57*z) > uy = 0. > uz = 0. > > endif > > > > I am still working on 3D MHD example > > > Best, > Aleks > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Sunday, June 27, 2010 11:10:55 AM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] [*] Re: MHD > > Hi Aleks, > > Any pointer to the switches that one needs to turn on to solve for > MHD using Nek5000? > > Thanks, > Mani chandra > On 05/17/2010 11:29 PM, nek5000-users at lists.mcs.anl.gov wrote: >> Hi Mani, >> >> I'll set up an MHD example. >> >> Best, >> Aleks >> >> >> On Mon, 17 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear Paul and Stephan, >>> >>> I'd like to know how to setup nek5000 to solve for MHD equations. >>> Maybe an example? >>> >>> 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 >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue Jun 29 11:53:10 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 29 Jun 2010 11:53:10 -0500 (CDT) Subject: [Nek5000-users] Periodic Mismatch 1 In-Reply-To: <854913795.1304101277830387098.JavaMail.root@neo-mail-3> Message-ID: <860107542.1304141277830390637.JavaMail.root@neo-mail-3> Hi, I am getting a 'Periodic Mismatch 1' error: abort: PERIODIC MISMATCH 1: 1 3 P ie 1 6 E je 6 1 E ke I grep'd to the error in genmap.f and from what I can tell this bit of code is checking to ensure that the elements and faces I have said are periodic, match up with the other corresponding elements and faces. From the error, it seems to think that face 3 of element 1 is Periodic, and then returns this error because of course it is not. I have attached the rea. I am not sure what the issue is here, and why it is not recognizing face 1 as periodic (as you will see in the rea, Elem 1 face 1 is periodic with elem 6 face 3). This error occurs at the first element. The values in the error message all seem to come from the periodic condition I have specified, but it is almost as if they are not in the correct order in the rea. >From my understanding: " P 1 1.00 6.00000 3.00000 0.00000 0.00000 0.00000 " states that element 1 face 1 is periodic with element 6 face 3. Thanks for any help with this, Michael M. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: domain.rea.gz Type: application/x-gzip Size: 214928 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 29 13:59:13 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 29 Jun 2010 13:59:13 -0500 (CDT) Subject: [Nek5000-users] Periodic Mismatch 1 In-Reply-To: <1770005851.1333961277837777422.JavaMail.root@neo-mail-3> Message-ID: <269427813.1334641277837953259.JavaMail.root@neo-mail-3> Hi, I was able to solve this by removing the element face count column. I now run into the following issue shown below. I was able to find the subroutine spec_bis_conn where this error occurs. I believe this has to do with the periodic faces I have set up. My question is whether the periodic faces need to be continuous: For example, the geometry is similar to fluid flow over a flat plate on both sides. The fluid is periodic, but separated by the solid thickness (this is a Conj HT problem). Essentially there is a "gap" in the periodic fluid portion if you can imagine. I saw a note in the routine that says something like "ensure that all graphs are connected", not sure if this is what it means. I tried making the fluid periodic on only one side of the plate and it worked, however when I make the other side (bottom of the plate) periodic with itself I get the following error. Any thoughts? Thanks - Michael M. start rec_bisect: 2006 done: 0.0% done: 1.0% done: 2.0% done: 3.0% infinite loop not connected 1 63 1 0 not connected 1 32 2 0 not connected 1 16 3 0 not connected 1 8 4 0 not connected 1 4 5 0 done: 4.0% not connected 13 31 6 0 Segmentation fault (core dumped) ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "Nekton User List" Sent: Tuesday, June 29, 2010 11:53:10 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Periodic Mismatch 1 Hi, I am getting a 'Periodic Mismatch 1' error: abort: PERIODIC MISMATCH 1: 1 3 P ie 1 6 E je 6 1 E ke I grep'd to the error in genmap.f and from what I can tell this bit of code is checking to ensure that the elements and faces I have said are periodic, match up with the other corresponding elements and faces. From the error, it seems to think that face 3 of element 1 is Periodic, and then returns this error because of course it is not. I have attached the rea. I am not sure what the issue is here, and why it is not recognizing face 1 as periodic (as you will see in the rea, Elem 1 face 1 is periodic with elem 6 face 3). This error occurs at the first element. The values in the error message all seem to come from the periodic condition I have specified, but it is almost as if they are not in the correct order in the rea. >From my understanding: " P 1 1.00 6.00000 3.00000 0.00000 0.00000 0.00000 " states that element 1 face 1 is periodic with element 6 face 3. Thanks for any help with this, Michael M. _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 29 14:09:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 29 Jun 2010 15:09:34 -0400 Subject: [Nek5000-users] Helmholtz error Message-ID: Hi nek users, I'm getting an error I don't understand, perhaps someone can help. I'm simulating the Boussinesq equations in a 2D box of aspect ratio 2 with periodic side BC, stress-free velocity and fixed-flux temperature on the top and bottom, and at a Rayleigh number of 10^8. My time step is 2^-6; and longer and there are CFL problems. The part of the logfile where the error first appears is below. Any idea? Thanks a lot, David 321 Hmholtz VELX: 1 1.8722E-04 9.4841E-04 3.0177E-02 321 5.5836E+03 3.0971E-03 1.8028E+06 16 alph1x 321 halpha 16 9.1147E+00 1.6433E-01 1.6202E-03 1.5295E-03 3.2457E-04 9.6963E-05 5.3573E-05 2.3766E-05 1.5049E-05 1.1283E-05 321 Hmholtz VELY: 1 4.5111E-04 3.0971E-03 3.0177E-02 321 16 alpha: 4.3959E-02 1.3360E-03 1.2680E-04 6.4401E-06 -3.8972E-06 3.2052E-06 7.4030E-06 3.4569E-06 2.8993E-06 1.4221E-06 321 16 3.5585E-04 1.2617E-07 2.8203E+03 alph12 321 U-Pres gmres: 3 2.6567E-09 4.1491E-09 1.2617E-07 1.5726E-03 2.5913E-03 321 DNORM, DIVEX 7.71505530689053011E-6 2.65666629955944499E-9 321 6.4200E-04 6.4809E-03 Fluid done 321 6.420000E-04 7.911223E-01 1.711772E+00 umax 321 0.6420E-03 t_av= 0.5000E+00 Ek= 0.1953E+00 Nu= 0.1000E+01 Step 322, t= 6.4400000E-04, DT= 2.0000000E-06, C= 0.000 5.4661E+00 9.7695E-03 Solving for heat Solving for fluid 322 Hmholtz TEMP: 1 9.9844E-03 6.0396E-01 2.4836E-02 322 6.4400E-04 1.0539E-03 Heat done 322 2.0339E+03 5.8756E-03 3.4616E+05 17 alph1x 322 halpha 17 3.3193E+00 1.0787E-01 5.3974E-04 9.8243E-04 3.7291E-04 2.3705E-04 5.1605E-05 3.4660E-05 1.1899E-05 1.1993E-05 322 Hmholtz VELX: 1 1.2039E-03 5.8756E-03 3.0705E-02 322 5.6870E+03 NaN NaN 17 alph1x 322 halpha 17 9.2834E+00 1.7756E-01 1.8590E-03 1.7684E-03 3.7603E-04 1.1302E-04 6.3138E-05 2.9137E-05 1.9115E-05 1.5046E-05 322 5000 **ERROR**: Failed in HMHOLTZ: VELY NaN NaN 3.0705E-02 322 17 alpha: NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN 322 17 NaN NaN NaN alph12 322 U-Pres gmres: 100 NaN 4.1491E-09 NaN 5.2696E-02 8.8512E-02 322 DNORM, DIVEX NaN NaN 322 6.4400E-04 6.0996E-01 Fluid done 322 6.440000E-04 -9.900000E+21 -9.900000E+21 umax 322 0.6440E-03 t_av= 0.5000E+00 Ek= NaN Nu= NaN Step 323, t= 6.4600000E-04, DT= 2.0000000E-06, C= 0.000 6.0793E+00 6.1319E-01 Solving for heat Solving for fluid 323 5000 **ERROR**: Failed in HMHOLTZ: TEMP NaN NaN 2.4836E-02 323 6.4600E-04 5.2047E-01 Heat done 323 NaN NaN NaN 18 alph1x 323 halpha 18 NaN NaN NaN NaN NaN -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 29 14:27:22 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 29 Jun 2010 14:27:22 -0500 (CDT) Subject: [Nek5000-users] Helmholtz error In-Reply-To: References: Message-ID: David, It looks as though you're hitting steady state. If you set param 94 to zero in your .rea file, this will correct the problem. It has to do with generation of an initial guess and having linearly-dependent vectors in the approximation space --- this can happen when there is no dynamics in the system. Note that your CFL is very small. You likely could increase your DT -- perhaps set param 12 to +2.e-4 (i.e., > 0). You could also set COURANT to be, say, 0.1, to be safe -- which is sometimes necessary for Boussinesq problems at early times (only). I would in this case also set IFCHAR to F, since there is no point in using the characteristics timestepper if CFL ~ 0.1. (See www.mcs.anl.gov/~fischer/oifs.pdf for an explanation.) Finally, > 321 DNORM, DIVEX 7.71505530689053011E-6 2.65666629955944499E-9 Indicates that you have a tighter tolerance for the pressure solver ( ~2.6e-9 ) than is realizable ( 7.7e-6 ). I'm guessing by the peculiar tolerance that you have set DIVERGENCE=0 in the .rea file (which is fine), and that the tolerance is thus set by TOLREL. You might be able to dial that back a bit --- but given that you have no flow and very little pressure iteration count, I'd leave it as is. Paul On Tue, 29 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi nek users, > > I'm getting an error I don't understand, perhaps someone can help. I'm > simulating the Boussinesq equations in a 2D box of aspect ratio 2 with > periodic side BC, stress-free velocity and fixed-flux temperature on the top > and bottom, and at a Rayleigh number of 10^8. My time step is 2^-6; and > longer and there are CFL problems. The part of the logfile where the error > first appears is below. Any idea? > > Thanks a lot, > > David > > > 321 Hmholtz VELX: 1 1.8722E-04 9.4841E-04 3.0177E-02 > 321 5.5836E+03 3.0971E-03 1.8028E+06 16 alph1x > 321 halpha 16 9.1147E+00 1.6433E-01 1.6202E-03 1.5295E-03 > 3.2457E-04 9.6963E-05 5.3573E-05 2.3766E-05 1.5049E-05 1.1283E-05 > > 321 Hmholtz VELY: 1 4.5111E-04 3.0971E-03 3.0177E-02 > 321 16 alpha: 4.3959E-02 1.3360E-03 1.2680E-04 6.4401E-06 > -3.8972E-06 3.2052E-06 7.4030E-06 3.4569E-06 2.8993E-06 1.4221E-06 > 321 16 3.5585E-04 1.2617E-07 2.8203E+03 alph12 > 321 U-Pres gmres: 3 2.6567E-09 4.1491E-09 1.2617E-07 > 1.5726E-03 2.5913E-03 > 321 DNORM, DIVEX 7.71505530689053011E-6 2.65666629955944499E-9 > 321 6.4200E-04 6.4809E-03 Fluid done > 321 6.420000E-04 7.911223E-01 1.711772E+00 umax > 321 0.6420E-03 t_av= 0.5000E+00 Ek= 0.1953E+00 Nu= 0.1000E+01 > Step 322, t= 6.4400000E-04, DT= 2.0000000E-06, C= 0.000 5.4661E+00 > 9.7695E-03 > Solving for heat > Solving for fluid > 322 Hmholtz TEMP: 1 9.9844E-03 6.0396E-01 2.4836E-02 > 322 6.4400E-04 1.0539E-03 Heat done > 322 2.0339E+03 5.8756E-03 3.4616E+05 17 alph1x > 322 halpha 17 3.3193E+00 1.0787E-01 5.3974E-04 9.8243E-04 > 3.7291E-04 2.3705E-04 5.1605E-05 3.4660E-05 1.1899E-05 1.1993E-05 > > 322 Hmholtz VELX: 1 1.2039E-03 5.8756E-03 3.0705E-02 > 322 5.6870E+03 NaN NaN 17 alph1x > 322 halpha 17 9.2834E+00 1.7756E-01 1.8590E-03 1.7684E-03 > 3.7603E-04 1.1302E-04 6.3138E-05 2.9137E-05 1.9115E-05 1.5046E-05 > > 322 5000 **ERROR**: Failed in HMHOLTZ: VELY NaN NaN > 3.0705E-02 > 322 17 alpha: NaN NaN NaN NaN > NaN NaN NaN NaN NaN NaN > 322 17 NaN NaN NaN alph12 > 322 U-Pres gmres: 100 NaN 4.1491E-09 NaN > 5.2696E-02 8.8512E-02 > 322 DNORM, DIVEX NaN NaN > 322 6.4400E-04 6.0996E-01 Fluid done > 322 6.440000E-04 -9.900000E+21 -9.900000E+21 umax > 322 0.6440E-03 t_av= 0.5000E+00 Ek= NaN Nu= NaN > Step 323, t= 6.4600000E-04, DT= 2.0000000E-06, C= 0.000 6.0793E+00 > 6.1319E-01 > Solving for heat > Solving for fluid > 323 5000 **ERROR**: Failed in HMHOLTZ: TEMP NaN NaN > 2.4836E-02 > 323 6.4600E-04 5.2047E-01 Heat done > 323 NaN NaN NaN 18 alph1x > 323 halpha 18 NaN NaN NaN NaN > NaN > From nek5000-users at lists.mcs.anl.gov Tue Jun 29 17:18:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 29 Jun 2010 17:18:04 -0500 (CDT) Subject: [Nek5000-users] Helmholtz error In-Reply-To: References: Message-ID: Hi David, The disadvatage of setting p94 to zero is that there is no accelerated convergence in pressure solver due to projection to the solution space. Setting DT>0 will results in an attempt to adjust DT to keep CFL constant set by p25 (COURANT) Another way of setting an iteration tolerence in pressure solver is explicitly to p21 (DIVERGENCE). Best, Aleks On Tue, 29 Jun 2010, David Goluskin wrote: > Thanks, Paul. That fixed it. Is there any disadvantage to having param 94 > set to zero rather than 5? Also, what does setting DT > 0 do? I have > indeed set DIVERGENCE to zero, as you told me this makes tolrel and tolabs > take over. What happens when DIVERGENCE is nonzero? > > Thanks, > > David > From nek5000-users at lists.mcs.anl.gov Wed Jun 30 18:54:46 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 30 Jun 2010 18:54:46 -0500 (CDT) Subject: [Nek5000-users] E INVALID BC FOUND in genfast In-Reply-To: Message-ID: <680386911.1626731277942086444.JavaMail.root@neo-mail-3> Hi Paul, I am also getting something similar, however it is referring to many elements with ?a "BC fail" and then gives the E INVALID BC FOUND. I have attached the case and output log for referrence. I checked the elements that?it is referring to and the BC's are good, so I'm not sure why it tells me this. I looked in fast3d.f and also couldn't figure out what "ierr and ierrmx" refer to. Could explain what this error means or what it is checking for? Thanks for any help! - Michael ? ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Friday, June 25, 2010 1:39:43 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] E INVALID BC FOUND in genfast Shriram, It's indicating that one of the bcs for element 3912 is not valid. What are those? Paul On Fri, 25 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi all, > > I am getting the following error when I try to run nek : > > ? *0 ? ? ? ?3912 ?BC FAIL* > *EXIT: E INVALID BC FOUND in genfast ? ? ? 3912* > > * > * > I grep-ed to the source code to get an idea of what the error actually > means, but I couldn't comprehend whats going on in the code (fast3d.f) . > Could anybody tell me what this error actually means ? I checked the > Boundary condition of the particular element (3912) and everything seems to > be OK. > Thanks for any help. > > Regards > Shriram Jagannathan > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 30 19:29:36 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 30 Jun 2010 19:29:36 -0500 (CDT) Subject: [Nek5000-users] E INVALID BC FOUND in genfast In-Reply-To: <680386911.1626731277942086444.JavaMail.root@neo-mail-3> References: <680386911.1626731277942086444.JavaMail.root@neo-mail-3> Message-ID: Michael, Shriram, . ierr is set to the element that has a problem . ierrmx is the maximum of ierr, taken over all processors. If more than one element has a problem, you won't know it because it will only flag the element having the largest number -- thus indicating that there is _a_ problem, but not the extent of the problem. (Flagging errors is tricky when you have millions of elements.) My general approach at this point would be something like the following. Suppose the troublesome element is 3192. Add the following code to the gen_fast routine: mid = gllnid(3192) ie = gllel (3192) if (mid.eq.nid) write(6,6) mid,ie,(cbc(k,ie,1),k=1,6) 6 format(2i8,6('.',a3,'.'),' BOUNDARY') when you then run the code and grep for BOUNDARY in the logfile you should see something like: 20 5 .v ..E ..E ..E ..E ..E . and not (say) 20 5 .v .. E .. E .. E .. E .. E . It's imperative that the BCs are 3 characters each and that the spaces are in the correct place. Only by printing the bcs can you see what bcs are really being passed to the code. Paul On Wed, 30 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > I am also getting something similar, however it is referring to many elements with > > ??a "BC fail" and then gives the E INVALID BC FOUND. I have attached the case > > and output log for referrence. > > > > I checked the elements that??it is referring to and the BC's are good, so I'm not sure > > why it tells me this. I looked in fast3d.f and also couldn't figure out what "ierr and ierrmx" > > refer to. Could explain what this error means or what it is checking for? Thanks > > for any help! > > > > - Michael > > ?? > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Friday, June 25, 2010 1:39:43 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] E INVALID BC FOUND in genfast > > > Shriram, > > It's indicating that one of the bcs for element 3912 is not valid. > > What are those? > > Paul > > > On Fri, 25 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi all, >> >> I am getting the following error when I try to run nek : >> >> ?? *0 ?? ?? ?? ??3912 ??BC FAIL* >> *EXIT: E INVALID BC FOUND in genfast ?? ?? ?? 3912* >> >> * >> * >> I grep-ed to the source code to get an idea of what the error actually >> means, but I couldn't comprehend whats going on in the code (fast3d.f) . >> Could anybody tell me what this error actually means ? I checked the >> Boundary condition of the particular element (3912) and everything seems to >> be OK. >> Thanks for any help. >> >> Regards >> Shriram Jagannathan >> > _______________________________________________ > 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 Jun 30 19:54:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 30 Jun 2010 19:54:06 -0500 (CDT) Subject: [Nek5000-users] E INVALID BC FOUND in genfast In-Reply-To: Message-ID: <1323735814.1636021277945646505.JavaMail.root@neo-mail-3> Ah, thanks very much for the insight! I was thinking that it was either a formatting issue or perhaps a tolerance issue, but after looking at my rea I already see where it may have gone wrong.? I'll add the below, and try again. Thanks again Paul! - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, June 30, 2010 7:29:36 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] E INVALID BC FOUND in genfast Michael, Shriram, . ierr is set to the element that has a problem . ierrmx is the maximum of ierr, taken over all processors. If more than one element has a problem, you won't know it because it will only flag the element having the largest number -- thus indicating that there is _a_ problem, but not the extent of the problem. (Flagging errors is tricky when you have millions of elements.) My general approach at this point would be something like the following. Suppose the troublesome element is 3192. Add the following code to the gen_fast routine: mid = gllnid(3192) ie = gllel (3192) if (mid.eq.nid) write(6,6) mid,ie,(cbc(k,ie,1),k=1,6) 6 format(2i8,6('.',a3,'.'),' BOUNDARY') when you then run the code and grep for BOUNDARY in the logfile you should see something like: 20 5 .v ..E ..E ..E ..E ..E . and not (say) 20 5 .v .. E .. E .. E .. E .. E . It's imperative that the BCs are 3 characters each and that the spaces are in the correct place. Only by printing the bcs can you see what bcs are really being passed to the code. Paul On Wed, 30 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > I am also getting something similar, however it is referring to many elements with > > ?a "BC fail" and then gives the E INVALID BC FOUND. I have attached the case > > and output log for referrence. > > > > I checked the elements that?it is referring to and the BC's are good, so I'm not sure > > why it tells me this. I looked in fast3d.f and also couldn't figure out what "ierr and ierrmx" > > refer to. Could explain what this error means or what it is checking for? Thanks > > for any help! > > > > - Michael > > ? > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Friday, June 25, 2010 1:39:43 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] E INVALID BC FOUND in genfast > > > Shriram, > > It's indicating that one of the bcs for element 3912 is not valid. > > What are those? > > Paul > > > On Fri, 25 Jun 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi all, >> >> I am getting the following error when I try to run nek : >> >> ? *0 ? ? ? ?3912 ?BC FAIL* >> *EXIT: E INVALID BC FOUND in genfast ? ? ? 3912* >> >> * >> * >> I grep-ed to the source code to get an idea of what the error actually >> means, but I couldn't comprehend whats going on in the code (fast3d.f) . >> Could anybody tell me what this error actually means ? I checked the >> Boundary condition of the particular element (3912) and everything seems to >> be OK. >> Thanks for any help. >> >> Regards >> Shriram Jagannathan >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 30 22:24:17 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 30 Jun 2010 22:24:17 -0500 Subject: [Nek5000-users] E INVALID BC FOUND in genfast In-Reply-To: <1323735814.1636021277945646505.JavaMail.root@neo-mail-3> References: <1323735814.1636021277945646505.JavaMail.root@neo-mail-3> Message-ID: Paul, Thanks for the reply. Earlier that day you had mentioned about the format in connect2.f and I looked at that and implemented in the rea file and that took care of the error. As you had pointed out earlier, the b.c was not a 3-character string and that is why I had the problem. Thanks again. Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: