From nek5000-users at lists.mcs.anl.gov Sat May 1 08:19:35 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 1 May 2010 08:19:35 -0500 Subject: [Nek5000-users] Restarting simulation from instantenous & average velocity field files In-Reply-To: References: Message-ID: <7d94b3080cd7e8cdcd19999b70d3c526.squirrel@webmail.uic.edu> Hi Paul & Stefan, Thanks for your replies. I read through the routine avg_all() and I am using that to compute averages. I am also using userchk subroutine in turbChannel case as a guideline. I am sorry for not being very clear about my simulations. For the DNS simulation I ran it for 10 flow throughs till quasi-stationary state is achieved. Then compute averages over 5 more flow throughs and finally compute fluctuations over 10 more flow throughs. Right now I am computing averages by setting up the simulation for all the 5 flow throughs at one time. At the end of 5 flow throughs I will end up with 2 fld* files. One for instantaneous (blah.fld*) and other for averages (avgblah.fld*). To continue with calculating fluctuations over the next 10 flow throughs. I need to read in the instantaneous and average field values to calculate fluctuations. Is there is possible to do this with the RESTART OPTIONS. Something like this, 2 PRESOLVE/RESTART OPTIONS ***** blah.fld01 X U P avgblah.fld01 Uavg Pavg I think there is one way around this. To calculate fluctuations, start from fresh averaging for next 10 flow throughs and not use the averages calculated from previous 5 flow throughs. I am not sure if this is the right way to go about it. Thanks for your help. I will test some cases out and will post any questions I have. Regards, Harish. On Fri, April 30, 2010 7:37 am, nek5000-users at lists.mcs.anl.gov wrote: > Harish, > > you can compute mean and variances based on the averages we computed in > avg_all(). > The averages E(X), E(X*X), E(X*Y) are stored in the common blocks defined > in AVG (make sure you set lxa in SIZE correct). > > The averages are dumped into different files (I/O freq can be adjusted > with param(68): > *.avg -- E(X) > *.rms -- E(X*X) > *.rm2 -- E(X*Y) > > If you have want to compute the mean and variance of multiple files, run > Nek in postprocessing mode and read the *.avg files and the *.rms files > using load_fld() and sum up the averages for every variable (you need some > temporary arrays for that). > > Then compute the variance as > > var(X) := E(X^X) - E(X)*E(X) > > Finally just dump the final arrays containing your mean and/or variances. > > hth, > Stefan > > > > > > > On Apr 30, 2010, at 2:16 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello Paul & Stefan, >> >> I am running a DNS simulation of backward facing simulation (BFS) at >> Re=3000. The Reynolds # is based on step height (h=1) & free stream >> velocity (ux = 1.0). The BFS geometry has 5184 elements and >> lx1=ly1=lz1=8. >> >> After running for about 10 flow throughs, we started computing averages. >> I >> want to restart simulation after 2 flow throughs, but I have 2 field >> files >> one for instantaneous (blah.fld01) and the other for average >> (avgblah.fld01). To continue computing averages I need to read in both >> the >> velocity field files. Is there an option to restart from 2 field files? >> Or >> how else can I do this? I will also require this option later for >> computing "rms" velocities. >> >> Thanks, >> >> Harish. >> >> >> >> >> _______________________________________________ >> 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 Sat May 1 12:39:15 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 1 May 2010 12:39:15 -0500 (CDT) Subject: [Nek5000-users] Restarting simulation from instantenous & average velocity field files In-Reply-To: <7d94b3080cd7e8cdcd19999b70d3c526.squirrel@webmail.uic.edu> References: <7d94b3080cd7e8cdcd19999b70d3c526.squirrel@webmail.uic.edu> Message-ID: If you're trying to compute the rms quantities, you can do these directly from the data generated by avg_all, which produces and etc. Given these, you have = - ^2 etc., so no need to rerun if you're after those statistics. Paul On Sat, 1 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul & Stefan, > > Thanks for your replies. > > I read through the routine avg_all() and I am using that to compute > averages. I am also using userchk subroutine in turbChannel case as a > guideline. > > I am sorry for not being very clear about my simulations. For the DNS > simulation I ran it for 10 flow throughs till quasi-stationary state is > achieved. Then compute averages over 5 more flow throughs and finally > compute fluctuations over 10 more flow throughs. > > Right now I am computing averages by setting up the simulation for all the > 5 flow throughs at one time. At the end of 5 flow throughs I will end up > with 2 fld* files. One for instantaneous (blah.fld*) and other for > averages (avgblah.fld*). > > To continue with calculating fluctuations over the next 10 flow throughs. > I need to read in the instantaneous and average field values to calculate > fluctuations. Is there is possible to do this with the RESTART OPTIONS. > Something like this, > > 2 PRESOLVE/RESTART OPTIONS ***** > blah.fld01 X U P > avgblah.fld01 Uavg Pavg > > I think there is one way around this. To calculate fluctuations, start > from fresh averaging for next 10 flow throughs and not use the averages > calculated from previous 5 flow throughs. I am not sure if this is the > right way to go about it. > > Thanks for your help. I will test some cases out and will post any > questions I have. > > Regards, > > Harish. > > > On Fri, April 30, 2010 7:37 am, nek5000-users at lists.mcs.anl.gov wrote: >> Harish, >> >> you can compute mean and variances based on the averages we computed in >> avg_all(). >> The averages E(X), E(X*X), E(X*Y) are stored in the common blocks defined >> in AVG (make sure you set lxa in SIZE correct). >> >> The averages are dumped into different files (I/O freq can be adjusted >> with param(68): >> *.avg -- E(X) >> *.rms -- E(X*X) >> *.rm2 -- E(X*Y) >> >> If you have want to compute the mean and variance of multiple files, run >> Nek in postprocessing mode and read the *.avg files and the *.rms files >> using load_fld() and sum up the averages for every variable (you need some >> temporary arrays for that). >> >> Then compute the variance as >> >> var(X) := E(X^X) - E(X)*E(X) >> >> Finally just dump the final arrays containing your mean and/or variances. >> >> hth, >> Stefan >> >> >> >> >> >> >> On Apr 30, 2010, at 2:16 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello Paul & Stefan, >>> >>> I am running a DNS simulation of backward facing simulation (BFS) at >>> Re=3000. The Reynolds # is based on step height (h=1) & free stream >>> velocity (ux = 1.0). The BFS geometry has 5184 elements and >>> lx1=ly1=lz1=8. >>> >>> After running for about 10 flow throughs, we started computing averages. >>> I >>> want to restart simulation after 2 flow throughs, but I have 2 field >>> files >>> one for instantaneous (blah.fld01) and the other for average >>> (avgblah.fld01). To continue computing averages I need to read in both >>> the >>> velocity field files. Is there an option to restart from 2 field files? >>> Or >>> how else can I do this? I will also require this option later for >>> computing "rms" velocities. >>> >>> Thanks, >>> >>> Harish. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 May 2 17:47:24 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 2 May 2010 17:47:24 -0500 (CDT) Subject: [Nek5000-users] Restarting simulation from instantenous & average velocity field files In-Reply-To: References: <7d94b3080cd7e8cdcd19999b70d3c526.squirrel@webmail.uic.edu> Message-ID: Hi Paul, Thanks for your info. on how to find the rms quantities. This will certainly save me a lot of computing time. Regards, Harish. On Sat, 1 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > > > If you're trying to compute the rms quantities, you can do > these directly from the data generated by avg_all, which > produces > > > > and etc. > > > Given these, you have > > > = - ^2 > > etc., so no need to rerun if you're after those statistics. > > Paul > > > > On Sat, 1 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul & Stefan, > > > > Thanks for your replies. > > > > I read through the routine avg_all() and I am using that to compute > > averages. I am also using userchk subroutine in turbChannel case as a > > guideline. > > > > I am sorry for not being very clear about my simulations. For the DNS > > simulation I ran it for 10 flow throughs till quasi-stationary state is > > achieved. Then compute averages over 5 more flow throughs and finally > > compute fluctuations over 10 more flow throughs. > > > > Right now I am computing averages by setting up the simulation for all the > > 5 flow throughs at one time. At the end of 5 flow throughs I will end up > > with 2 fld* files. One for instantaneous (blah.fld*) and other for > > averages (avgblah.fld*). > > > > To continue with calculating fluctuations over the next 10 flow throughs. > > I need to read in the instantaneous and average field values to calculate > > fluctuations. Is there is possible to do this with the RESTART OPTIONS. > > Something like this, > > > > 2 PRESOLVE/RESTART OPTIONS ***** > > blah.fld01 X U P > > avgblah.fld01 Uavg Pavg > > > > I think there is one way around this. To calculate fluctuations, start > > from fresh averaging for next 10 flow throughs and not use the averages > > calculated from previous 5 flow throughs. I am not sure if this is the > > right way to go about it. > > > > Thanks for your help. I will test some cases out and will post any > > questions I have. > > > > Regards, > > > > Harish. > > > > > > On Fri, April 30, 2010 7:37 am, nek5000-users at lists.mcs.anl.gov wrote: > >> Harish, > >> > >> you can compute mean and variances based on the averages we computed in > >> avg_all(). > >> The averages E(X), E(X*X), E(X*Y) are stored in the common blocks defined > >> in AVG (make sure you set lxa in SIZE correct). > >> > >> The averages are dumped into different files (I/O freq can be adjusted > >> with param(68): > >> *.avg -- E(X) > >> *.rms -- E(X*X) > >> *.rm2 -- E(X*Y) > >> > >> If you have want to compute the mean and variance of multiple files, run > >> Nek in postprocessing mode and read the *.avg files and the *.rms files > >> using load_fld() and sum up the averages for every variable (you need some > >> temporary arrays for that). > >> > >> Then compute the variance as > >> > >> var(X) := E(X^X) - E(X)*E(X) > >> > >> Finally just dump the final arrays containing your mean and/or variances. > >> > >> hth, > >> Stefan > >> > >> > >> > >> > >> > >> > >> On Apr 30, 2010, at 2:16 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hello Paul & Stefan, > >>> > >>> I am running a DNS simulation of backward facing simulation (BFS) at > >>> Re=3000. The Reynolds # is based on step height (h=1) & free stream > >>> velocity (ux = 1.0). The BFS geometry has 5184 elements and > >>> lx1=ly1=lz1=8. > >>> > >>> After running for about 10 flow throughs, we started computing averages. > >>> I > >>> want to restart simulation after 2 flow throughs, but I have 2 field > >>> files > >>> one for instantaneous (blah.fld01) and the other for average > >>> (avgblah.fld01). To continue computing averages I need to read in both > >>> the > >>> velocity field files. Is there an option to restart from 2 field files? > >>> Or > >>> how else can I do this? I will also require this option later for > >>> computing "rms" velocities. > >>> > >>> Thanks, > >>> > >>> Harish. > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 May 3 03:08:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 03 May 2010 10:08:09 +0200 Subject: [Nek5000-users] Calculating forces on sphere Message-ID: <4BDE8469.8010809@kit.edu> Dear Neks, for my case 'periodic channel flow around a sphere' I wanted to calculate the forces acting on the sphere. I've seen that there exists a 'drag_calc' subroutine in navier5.f. But as I understood I have to define my sphere as an object, that this works. Is this right?? Because until now the surface of the sphere is defined as 'wall'. And if I have to define it as an object, I wanted to ask if there is an easy and fast doing this? Is there maybe a way doing this similar to defining the boundary conditions with 'set entire level', or do I have to add all the faces of the sphere by hand in prenek?? Thanks a lot for you time. Best, Fred From nek5000-users at lists.mcs.anl.gov Mon May 3 03:13:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 10:13:03 +0200 Subject: [Nek5000-users] Calculating forces on sphere In-Reply-To: <4BDE8469.8010809@kit.edu> References: <4BDE8469.8010809@kit.edu> Message-ID: <92EF51D1-C7FE-4E1C-AF7E-E9ACC79081EF@lav.mavt.ethz.ch> Check how we do it in the trubChannel example (see set_obj). Stefan On May 3, 2010, at 10:08 AM, nek5000-users at lists.mcs.anl.gov wrote: > Dear Neks, > > for my case 'periodic channel flow around a sphere' I wanted to calculate the forces acting on the sphere. I've seen that there exists a 'drag_calc' subroutine in navier5.f. But as I understood I have to define my sphere as an object, that this works. Is this right?? Because until now the surface of the sphere is defined as 'wall'. > > And if I have to define it as an object, I wanted to ask if there is an easy and fast doing this? Is there maybe a way doing this similar to defining the boundary conditions with 'set entire level', or do I have to add all the faces of the sphere by hand in prenek?? > > Thanks a lot for you time. > > 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 Mon May 3 07:13:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 03 May 2010 14:13:25 +0200 Subject: [Nek5000-users] genbox error Message-ID: <1272888805.18612.127.camel@localhost.localdomain> Hello all, I have come across what may be an error in genbox. It concerns reading in data. If instead of 8 elements, 7 are used or if the trailing zeros are removed, all is fine. It almost seems as if genbox has a limitation on the length of the lines defining the element edges. Cheers, Frank Reading 32 = 8 4 4 elements for box 1. Reading 2 = error: 8 9 error: 0 5 The following is the input file: openboat2D.rea -2 spatial dimension 2 number of fields #======================================================== # # Open boat with the Marangoni effect at the top surface. # #======================================================== # Box 8 4 -4.000000 -3.946236 -3.806717 -3.497438 -3.000000 -2.500000 -2.000000 -1.500000 -1.000000 -5.000000 -3.347128 0.000000 3.754690 5.000000 W ,W ,W ,shl, V bc's ! NB: 3 characters each ! t ,t , , , T bc's ! You must have 2 spaces!! -- 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 May 3 08:26:20 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 08:26:20 -0500 Subject: [Nek5000-users] prex & pretex not working Message-ID: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> Hello, I am compiling prenek with GNU compilers, gfortran-4.3.2 and gcc-4.3.2. When I compile it without "BIGMEM" flag it gives an error, the output of it is attached (error.out). With "BIGMEM" flag turned on, there are no compiler errors (compile.out). But when I try to open pretex or prex, I get the following error. [harish at cmtl hole-in-center]$ prex Killed [harish at cmtl hole-in-center]$ pretex Killed All the other tools are working fine. Any help in solving this issue is appreciated. Thanks, Harish. -------------- next part -------------- A non-text attachment was scrubbed... Name: error.out Type: application/octet-stream Size: 3563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compile.out Type: application/octet-stream Size: 2732 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon May 3 08:37:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 15:37:38 +0200 Subject: [Nek5000-users] prex & pretex not working In-Reply-To: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> Message-ID: Hi Harish, unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ gfortran 4.5). Can you try again using another compiler? Stefan On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I am compiling prenek with GNU compilers, gfortran-4.3.2 and gcc-4.3.2. > When I compile it without "BIGMEM" flag it gives an error, the output of > it is attached (error.out). With "BIGMEM" flag turned on, there are no > compiler errors (compile.out). But when I try to open pretex or prex, I > get the following error. > > [harish at cmtl hole-in-center]$ prex > Killed > [harish at cmtl hole-in-center]$ pretex > Killed > > All the other tools are working fine. Any help in solving this issue is > appreciated. > > Thanks, > > Harish. > _______________________________________________ > 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 May 3 08:10:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 03 May 2010 09:10:16 -0400 Subject: [Nek5000-users] User feedback on Wiki Message-ID: <4BDECB38.9030703@vt.edu> Howdy Nek users, bundling user feedback from Dr. Duggleby's research group here at A&M, I started a "Not-only-for-Christmas-Nek-wishlist" on the wiki: https://nek5000.mcs.anl.gov/index.php/USER_feedback Please add to it any items you would like to see implemented/improved in the nek5000 package or other feedback. Markus From nek5000-users at lists.mcs.anl.gov Mon May 3 09:22:13 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 16:22:13 +0200 Subject: [Nek5000-users] User feedback on Wiki In-Reply-To: <4BDECB38.9030703@vt.edu> References: <4BDECB38.9030703@vt.edu> Message-ID: Thanks for the feedback. I just reorganized a few things including some preliminary replies. I am looking forward to a fruitful discussion. Stefan On May 3, 2010, at 3:10 PM, nek5000-users at lists.mcs.anl.gov wrote: > Howdy Nek users, > > bundling user feedback from Dr. Duggleby's research group here at A&M, I started a "Not-only-for-Christmas-Nek-wishlist" on the wiki: > > https://nek5000.mcs.anl.gov/index.php/USER_feedback > > Please add to it any items you would like to see implemented/improved in the nek5000 package or other feedback. > > 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 Mon May 3 09:34:13 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 09:34:13 -0500 (CDT) Subject: [Nek5000-users] prex & pretex not working In-Reply-To: References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> Message-ID: Hi Stefan, I do not have any other compiler on the cluster. I can give you my login to check the problem. Thanks, Harish. On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > Hi Harish, > > unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ gfortran 4.5). > Can you try again using another compiler? > > Stefan > > > On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello, > > > > I am compiling prenek with GNU compilers, gfortran-4.3.2 and gcc-4.3.2. > > When I compile it without "BIGMEM" flag it gives an error, the output of > > it is attached (error.out). With "BIGMEM" flag turned on, there are no > > compiler errors (compile.out). But when I try to open pretex or prex, I > > get the following error. > > > > [harish at cmtl hole-in-center]$ prex > > Killed > > [harish at cmtl hole-in-center]$ pretex > > Killed > > > > All the other tools are working fine. Any help in solving this issue is > > appreciated. > > > > Thanks, > > > > Harish. > > _______________________________________________ > > 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 May 3 09:38:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 16:38:41 +0200 Subject: [Nek5000-users] prex & pretex not working In-Reply-To: References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> Message-ID: Can you try on another Linux box? You can get the Intel compilers (non commercial usage) for free. Sorry I don't want to login into other machines unless it's really needed. Stefan On May 3, 2010, at 4:34 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > I do not have any other compiler on the cluster. I can give you my login > to check the problem. > > Thanks, > > Harish. > > On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Harish, >> >> unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ gfortran 4.5). >> Can you try again using another compiler? >> >> Stefan >> >> >> On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello, >>> >>> I am compiling prenek with GNU compilers, gfortran-4.3.2 and gcc-4.3.2. >>> When I compile it without "BIGMEM" flag it gives an error, the output of >>> it is attached (error.out). With "BIGMEM" flag turned on, there are no >>> compiler errors (compile.out). But when I try to open pretex or prex, I >>> get the following error. >>> >>> [harish at cmtl hole-in-center]$ prex >>> Killed >>> [harish at cmtl hole-in-center]$ pretex >>> Killed >>> >>> All the other tools are working fine. Any help in solving this issue is >>> appreciated. >>> >>> Thanks, >>> >>> Harish. >>> _______________________________________________ >>> 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 May 3 09:25:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 03 May 2010 10:25:12 -0400 Subject: [Nek5000-users] New code+recycling BC Message-ID: <4BDEDCC8.4050207@vt.edu> Hi, when updating the code from rev. 404 (oldvel.png) to 503 (newvel.png), I realized a problem with the recycling (periodic) boundary condition for a channel simulation I am doing - compare the attached pictures of velocity on the inflow plane (the inflow is the Y/Z plane). For the two cases, SIZE/SIZEu, .rea, the restart step and .usr are the exact same. Here are the relevant pieces from .usr. Have any of the functions changed or am I doing something wrong? It seems as if the element ordering is not what it was before. I did this based on the jet example. Thanks, Markus c----------------------------------------------------------------------- subroutine userbc (ix,iy,iz,iside,eg) include 'SIZE' include 'TOTAL' include 'NEKUSE' common /cvelbc/ uin(lx1,ly1,lz1,lelv) $ , vin(lx1,ly1,lz1,lelv) $ , win(lx1,ly1,lz1,lelv) $ , tin(lx1,ly1,lz1,lelv) integer e,eg e = gllel(eg) ux=uin(ix,iy,iz,e) uy=vin(ix,iy,iz,e) uz=win(ix,iy,iz,e) . .... c----------------------------------------------------------------------- subroutine userchk include 'SIZE' include 'TOTAL' include 'ZPER' ! for nelx,nely,nelz include 'RESTART' !Needs to be here for prepost to work common /cvlmsk/ vlmsk(lx1,ly1,lz1,lelt),vvol, & wt(lx1*ly1*lz1,lelt),vol_per integer e,f,eg,ninx,niny,ninz .c-----Computations for recycling BC speed = glsc2(vx,wt,n)/vol_per ! Where vol_per is the volume of the recycling box starg = 1.0 addtemp = 1.0 call set_inflow(starg,speed,addtemp) ! set up inflow BCs . .... c----------------------------------------------------------------------- subroutine set_inflow(starg,speed,addtemp) ! set up inflow BCs include 'SIZE' include 'TOTAL' integer icalld,e,eg,f save icalld data icalld /0/ common /cvelbc/ uin(lx1,ly1,lz1,lelv) $ , vin(lx1,ly1,lz1,lelv) $ , win(lx1,ly1,lz1,lelv) $ , tin(lx1,ly1,lz1,lelv) common /scruz/ ptr(lx1,ly1,lz1,lelv) integer ptr,gs_bc_hndl save gs_bc_hndl real ratio save ratio data ratio / 1. / common /nekmpi/ mid,mp,nekcomm,nekgroup,nekreal n = nx1*ny1*nz1*nelv if (icalld.eq.0) then icalld = 1 nxyz = nx1*ny1*nz1 do e=1,nelv eg = lglel(e) eo = nxyz*(eg-1) ! offset do i=1,nxyz ptr(i,1,1,e) = i+eo enddo do k=2,nz1-1 ! get rid of interior pointers do j=2,ny1-1 do i=2,nx1-1 ptr(i,j,k,e) = 0 enddo enddo enddo nface = 2*ndim do f=1,nface ! connect inflow to elems downstream ioff = nxyz*8 ! 5 elements in X to end of "periodic" sec. if (cbc(f,e,1).eq.'v ') then call iface_add(ptr,f,e,ioff,nx1,ny1,nz1) endif enddo enddo call gs_setup(gs_bc_hndl,ptr,n,nekcomm,np) ! connect v + downstream endif call copy(uin,vx,n) call copy(vin,vy,n) call copy(win,vz,n) call copy(tin,t,n) call col2(uin,v1mask,n) call col2(vin,v2mask,n) call col2(win,v3mask,n) call col2(tin,tmask,n) call gs_op(gs_bc_hndl,uin,1,1,0) ! 1 ==> + ! uin(inflow) = vx(slab_k) call gs_op(gs_bc_hndl,vin,1,1,0) ! 1 ==> + call gs_op(gs_bc_hndl,win,1,1,0) ! 1 ==> + call gs_op(gs_bc_hndl,tin,1,1,0) ! 1 ==> + if (speed.gt.0) then ratio = .5*(starg/speed + ratio) call cmult(uin,ratio,n) call cmult(vin,ratio,n) call cmult(win,ratio,n) call cadd(tin,addtemp,n) !Substract added heat endif return end -------------- next part -------------- A non-text attachment was scrubbed... Name: oldvel.png Type: image/png Size: 71571 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: newvel.png Type: image/png Size: 31195 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon May 3 10:24:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 17:24:04 +0200 Subject: [Nek5000-users] New code+recycling BC In-Reply-To: <4BDEDCC8.4050207@vt.edu> References: <4BDEDCC8.4050207@vt.edu> Message-ID: <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> Markus, is it only a viz issue or do you have some problems in Nek after upgrading to the latest release. Stefan On May 3, 2010, at 4:25 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > when updating the code from rev. 404 (oldvel.png) to 503 > (newvel.png), I realized a problem with the recycling > (periodic) boundary condition for a channel simulation I am doing - > compare the attached pictures of velocity on the inflow plane (the inflow is the Y/Z plane). For the two cases, SIZE/SIZEu, .rea, the restart step and .usr are the exact same. > > Here are the relevant pieces from .usr. Have any of the functions > changed or am I doing something wrong? It seems as if the element > ordering is not what it was before. > I did this based on the jet example. > > Thanks, > Markus > > > c----------------------------------------------------------------------- > subroutine userbc (ix,iy,iz,iside,eg) > include 'SIZE' > include 'TOTAL' > include 'NEKUSE' > > common /cvelbc/ uin(lx1,ly1,lz1,lelv) > $ , vin(lx1,ly1,lz1,lelv) > $ , win(lx1,ly1,lz1,lelv) > $ , tin(lx1,ly1,lz1,lelv) > > integer e,eg > > e = gllel(eg) > > ux=uin(ix,iy,iz,e) > uy=vin(ix,iy,iz,e) > uz=win(ix,iy,iz,e) > . > .... > > c----------------------------------------------------------------------- > subroutine userchk > include 'SIZE' > include 'TOTAL' > include 'ZPER' ! for nelx,nely,nelz > include 'RESTART' !Needs to be here for prepost to work > common /cvlmsk/ vlmsk(lx1,ly1,lz1,lelt),vvol, > & wt(lx1*ly1*lz1,lelt),vol_per > > integer e,f,eg,ninx,niny,ninz > > .c-----Computations for recycling BC > speed = glsc2(vx,wt,n)/vol_per ! Where vol_per is the volume of > the recycling box > starg = 1.0 > addtemp = 1.0 > call set_inflow(starg,speed,addtemp) ! set up inflow BCs > . > .... > > c----------------------------------------------------------------------- > subroutine set_inflow(starg,speed,addtemp) ! set up inflow BCs > > include 'SIZE' > include 'TOTAL' > > integer icalld,e,eg,f > save icalld > data icalld /0/ > > common /cvelbc/ uin(lx1,ly1,lz1,lelv) > $ , vin(lx1,ly1,lz1,lelv) > $ , win(lx1,ly1,lz1,lelv) > $ , tin(lx1,ly1,lz1,lelv) > > common /scruz/ ptr(lx1,ly1,lz1,lelv) > integer ptr,gs_bc_hndl > save gs_bc_hndl > > real ratio > save ratio > data ratio / 1. / > > common /nekmpi/ mid,mp,nekcomm,nekgroup,nekreal > > n = nx1*ny1*nz1*nelv > > if (icalld.eq.0) then > icalld = 1 > nxyz = nx1*ny1*nz1 > > do e=1,nelv > eg = lglel(e) > eo = nxyz*(eg-1) ! offset > do i=1,nxyz > ptr(i,1,1,e) = i+eo > enddo > > do k=2,nz1-1 ! get rid of interior pointers > do j=2,ny1-1 do i=2,nx1-1 > ptr(i,j,k,e) = 0 > enddo > enddo > enddo > > nface = 2*ndim > do f=1,nface ! connect inflow to elems downstream > ioff = nxyz*8 ! 5 elements in X to end of "periodic" sec. > if (cbc(f,e,1).eq.'v ') then > call iface_add(ptr,f,e,ioff,nx1,ny1,nz1) > endif > enddo > > enddo > > call gs_setup(gs_bc_hndl,ptr,n,nekcomm,np) ! connect v + > downstream > > endif > > call copy(uin,vx,n) > call copy(vin,vy,n) > call copy(win,vz,n) > call copy(tin,t,n) > > call col2(uin,v1mask,n) > call col2(vin,v2mask,n) > call col2(win,v3mask,n) > call col2(tin,tmask,n) > > call gs_op(gs_bc_hndl,uin,1,1,0) ! 1 ==> + ! uin(inflow) = > vx(slab_k) > call gs_op(gs_bc_hndl,vin,1,1,0) ! 1 ==> + > call gs_op(gs_bc_hndl,win,1,1,0) ! 1 ==> + > call gs_op(gs_bc_hndl,tin,1,1,0) ! 1 ==> + > > if (speed.gt.0) then > ratio = .5*(starg/speed + ratio) > call cmult(uin,ratio,n) > call cmult(vin,ratio,n) > call cmult(win,ratio,n) > call cadd(tin,addtemp,n) !Substract added heat > endif > > return > end > > > > _______________________________________________ > 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 May 3 10:28:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 17:28:04 +0200 Subject: [Nek5000-users] New code+recycling BC In-Reply-To: <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> References: <4BDEDCC8.4050207@vt.edu> <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> Message-ID: Can you dump a field file including the geometry and then visualize it using VisIt (your metadata file should only contain one single fld). Is it still messed up? Stefan On May 3, 2010, at 5:24 PM, nek5000-users at lists.mcs.anl.gov wrote: > Markus, > > is it only a viz issue or do you have some problems in Nek after upgrading to the latest release. > > Stefan > > > On May 3, 2010, at 4:25 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> when updating the code from rev. 404 (oldvel.png) to 503 >> (newvel.png), I realized a problem with the recycling >> (periodic) boundary condition for a channel simulation I am doing - >> compare the attached pictures of velocity on the inflow plane (the inflow is the Y/Z plane). For the two cases, SIZE/SIZEu, .rea, the restart step and .usr are the exact same. >> >> Here are the relevant pieces from .usr. Have any of the functions >> changed or am I doing something wrong? It seems as if the element >> ordering is not what it was before. >> I did this based on the jet example. >> >> Thanks, >> Markus >> >> >> c----------------------------------------------------------------------- >> subroutine userbc (ix,iy,iz,iside,eg) >> include 'SIZE' >> include 'TOTAL' >> include 'NEKUSE' >> >> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >> $ , vin(lx1,ly1,lz1,lelv) >> $ , win(lx1,ly1,lz1,lelv) >> $ , tin(lx1,ly1,lz1,lelv) >> >> integer e,eg >> >> e = gllel(eg) >> >> ux=uin(ix,iy,iz,e) >> uy=vin(ix,iy,iz,e) >> uz=win(ix,iy,iz,e) >> . >> .... >> >> c----------------------------------------------------------------------- >> subroutine userchk >> include 'SIZE' >> include 'TOTAL' >> include 'ZPER' ! for nelx,nely,nelz >> include 'RESTART' !Needs to be here for prepost to work >> common /cvlmsk/ vlmsk(lx1,ly1,lz1,lelt),vvol, >> & wt(lx1*ly1*lz1,lelt),vol_per >> >> integer e,f,eg,ninx,niny,ninz >> >> .c-----Computations for recycling BC >> speed = glsc2(vx,wt,n)/vol_per ! Where vol_per is the volume of >> the recycling box >> starg = 1.0 >> addtemp = 1.0 >> call set_inflow(starg,speed,addtemp) ! set up inflow BCs >> . >> .... >> >> c----------------------------------------------------------------------- >> subroutine set_inflow(starg,speed,addtemp) ! set up inflow BCs >> >> include 'SIZE' >> include 'TOTAL' >> >> integer icalld,e,eg,f >> save icalld >> data icalld /0/ >> >> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >> $ , vin(lx1,ly1,lz1,lelv) >> $ , win(lx1,ly1,lz1,lelv) >> $ , tin(lx1,ly1,lz1,lelv) >> >> common /scruz/ ptr(lx1,ly1,lz1,lelv) >> integer ptr,gs_bc_hndl >> save gs_bc_hndl >> >> real ratio >> save ratio >> data ratio / 1. / >> >> common /nekmpi/ mid,mp,nekcomm,nekgroup,nekreal >> >> n = nx1*ny1*nz1*nelv >> >> if (icalld.eq.0) then >> icalld = 1 >> nxyz = nx1*ny1*nz1 >> >> do e=1,nelv >> eg = lglel(e) >> eo = nxyz*(eg-1) ! offset >> do i=1,nxyz >> ptr(i,1,1,e) = i+eo >> enddo >> >> do k=2,nz1-1 ! get rid of interior pointers >> do j=2,ny1-1 do i=2,nx1-1 >> ptr(i,j,k,e) = 0 >> enddo >> enddo >> enddo >> >> nface = 2*ndim >> do f=1,nface ! connect inflow to elems downstream >> ioff = nxyz*8 ! 5 elements in X to end of "periodic" sec. >> if (cbc(f,e,1).eq.'v ') then >> call iface_add(ptr,f,e,ioff,nx1,ny1,nz1) >> endif >> enddo >> >> enddo >> >> call gs_setup(gs_bc_hndl,ptr,n,nekcomm,np) ! connect v + >> downstream >> >> endif >> >> call copy(uin,vx,n) >> call copy(vin,vy,n) >> call copy(win,vz,n) >> call copy(tin,t,n) >> >> call col2(uin,v1mask,n) >> call col2(vin,v2mask,n) >> call col2(win,v3mask,n) >> call col2(tin,tmask,n) >> >> call gs_op(gs_bc_hndl,uin,1,1,0) ! 1 ==> + ! uin(inflow) = >> vx(slab_k) >> call gs_op(gs_bc_hndl,vin,1,1,0) ! 1 ==> + >> call gs_op(gs_bc_hndl,win,1,1,0) ! 1 ==> + >> call gs_op(gs_bc_hndl,tin,1,1,0) ! 1 ==> + >> >> if (speed.gt.0) then >> ratio = .5*(starg/speed + ratio) >> call cmult(uin,ratio,n) >> call cmult(vin,ratio,n) >> call cmult(win,ratio,n) >> call cadd(tin,addtemp,n) !Substract added heat >> endif >> >> return >> end >> >> >> >> _______________________________________________ >> 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 May 3 10:45:42 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 10:45:42 -0500 Subject: [Nek5000-users] prex & pretex not working In-Reply-To: References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> Message-ID: Hi Stefan, I tried compiling prenek on NCSA-Abe machine with ifort & icc. I get the following error, its same error w/ and w/o "BIGMEM" flag. Thanks, Harish. ************************************************************************* icc -c -DUNDERSCORE -Dr8 xdriver.c xdriver.c(875): warning #266: function "fprep_" declared implicitly fprep_ (); /* run Fortran Main code */ ^ xdriver.c(123): (col. 5) remark: LOOP WAS VECTORIZED. xdriver.c(125): (col. 5) remark: LOOP WAS VECTORIZED. xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. xdriver.c(747): (col. 4) remark: LOOP WAS VECTORIZED. xdriver.c(823): (col. 4) remark: LOOP WAS VECTORIZED. xdriver.c(700): (col. 5) remark: LOOP WAS VECTORIZED. xdriver.c(333): (col. 5) remark: LOOP WAS VECTORIZED. xdriver.c(340): (col. 5) remark: LOOP WAS VECTORIZED. ifort -o /u/ac/kanch1/nek5_svn/trunk/tools/prex prenek.o curve.o edit.o build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o xdriver.o -L/usr/X11R6/lib64 -lX11 -lm prenek.o(.text+0x47d): In function `drivfc_': : relocation truncated to fit: R_X86_64_PC32 chaar_ prenek.o(.text+0x4f9): In function `drivfc_': : relocation truncated to fit: R_X86_64_PC32 chaar_ prenek.o(.text+0x50d): In function `drivfc_': : relocation truncated to fit: R_X86_64_PC32 basics_ prenek.o(.text+0x584): In function `drivfc_': : relocation truncated to fit: R_X86_64_PC32 devs_ prenek.o(.text+0x5b1): In function `drivfc_': : relocation truncated to fit: R_X86_64_PC32 chaar_ prenek.o(.text+0x62d): In function `drivfc_': : relocation truncated to fit: R_X86_64_PC32 chaar_ prenek.o(.text+0x667): In function `drivfc_': : relocation truncated to fit: R_X86_64_32S chaar_ prenek.o(.text+0x740): In function `drivfc_': : relocation truncated to fit: R_X86_64_PC32 modes_ prenek.o(.text+0x789): In function `drivfc_': : relocation truncated to fit: R_X86_64_PC32 chaar_ prenek.o(.text+0x7fc): In function `drivfc_': : relocation truncated to fit: R_X86_64_PC32 chaar_ prenek.o(.text+0x80c): In function `drivfc_': : additional relocation overflows omitted from the output make[1]: *** [prex] Error 1 make[1]: Leaving directory `/u/ac/kanch1/nek5_svn/trunk/tools/prenek' make: *** [all] Error 1 ************************************************************************** On Mon, May 3, 2010 9:38 am, nek5000-users at lists.mcs.anl.gov wrote: > Can you try on another Linux box? You can get the Intel compilers (non > commercial usage) for free. > Sorry I don't want to login into other machines unless it's really needed. > > Stefan > > On May 3, 2010, at 4:34 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Stefan, >> >> I do not have any other compiler on the cluster. I can give you my login >> to check the problem. >> >> Thanks, >> >> Harish. >> >> On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Harish, >>> >>> unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ >>> gfortran 4.5). >>> Can you try again using another compiler? >>> >>> Stefan >>> >>> >>> On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hello, >>>> >>>> I am compiling prenek with GNU compilers, gfortran-4.3.2 and >>>> gcc-4.3.2. >>>> When I compile it without "BIGMEM" flag it gives an error, the output >>>> of >>>> it is attached (error.out). With "BIGMEM" flag turned on, there are no >>>> compiler errors (compile.out). But when I try to open pretex or prex, >>>> I >>>> get the following error. >>>> >>>> [harish at cmtl hole-in-center]$ prex >>>> Killed >>>> [harish at cmtl hole-in-center]$ pretex >>>> Killed >>>> >>>> All the other tools are working fine. Any help in solving this issue >>>> is >>>> appreciated. >>>> >>>> Thanks, >>>> >>>> Harish. >>>> _______________________________________________ >>>> 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 May 3 10:54:22 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 17:54:22 +0200 Subject: [Nek5000-users] prex & pretex not working In-Reply-To: References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> Message-ID: <4D5AC257-4D39-4749-BF61-F898757CF542@lav.mavt.ethz.ch> I know. There was a problem report on the mailing list already. This was my answer: Ok I think I know a way to fix the Intel compiler problem. To compile prenek (prex) you need to enable the BIGMEM support so you have to use at least the medium memory model. However the Intel compilers wants you to link all Intel-Libs dynamically if you use another memory model than small. Just set F77= "ifort -shared-intel" and it should work! hth, Stefan On May 3, 2010, at 5:45 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > I tried compiling prenek on NCSA-Abe machine with ifort & icc. I get the > following error, its same error w/ and w/o "BIGMEM" flag. > > Thanks, > > Harish. > > ************************************************************************* > icc -c -DUNDERSCORE -Dr8 xdriver.c > xdriver.c(875): warning #266: function "fprep_" declared implicitly > fprep_ (); /* run Fortran Main code */ > ^ > > xdriver.c(123): (col. 5) remark: LOOP WAS VECTORIZED. > xdriver.c(125): (col. 5) remark: LOOP WAS VECTORIZED. > xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. > xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. > xdriver.c(747): (col. 4) remark: LOOP WAS VECTORIZED. > xdriver.c(823): (col. 4) remark: LOOP WAS VECTORIZED. > xdriver.c(700): (col. 5) remark: LOOP WAS VECTORIZED. > xdriver.c(333): (col. 5) remark: LOOP WAS VECTORIZED. > xdriver.c(340): (col. 5) remark: LOOP WAS VECTORIZED. > ifort -o /u/ac/kanch1/nek5_svn/trunk/tools/prex prenek.o curve.o edit.o > build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o > vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o > xdriver.o -L/usr/X11R6/lib64 -lX11 -lm > prenek.o(.text+0x47d): In function `drivfc_': > : relocation truncated to fit: R_X86_64_PC32 chaar_ > prenek.o(.text+0x4f9): In function `drivfc_': > : relocation truncated to fit: R_X86_64_PC32 chaar_ > prenek.o(.text+0x50d): In function `drivfc_': > : relocation truncated to fit: R_X86_64_PC32 basics_ > prenek.o(.text+0x584): In function `drivfc_': > : relocation truncated to fit: R_X86_64_PC32 devs_ > prenek.o(.text+0x5b1): In function `drivfc_': > : relocation truncated to fit: R_X86_64_PC32 chaar_ > prenek.o(.text+0x62d): In function `drivfc_': > : relocation truncated to fit: R_X86_64_PC32 chaar_ > prenek.o(.text+0x667): In function `drivfc_': > : relocation truncated to fit: R_X86_64_32S chaar_ > prenek.o(.text+0x740): In function `drivfc_': > : relocation truncated to fit: R_X86_64_PC32 modes_ > prenek.o(.text+0x789): In function `drivfc_': > : relocation truncated to fit: R_X86_64_PC32 chaar_ > prenek.o(.text+0x7fc): In function `drivfc_': > : relocation truncated to fit: R_X86_64_PC32 chaar_ > prenek.o(.text+0x80c): In function `drivfc_': > : additional relocation overflows omitted from the output > make[1]: *** [prex] Error 1 > make[1]: Leaving directory `/u/ac/kanch1/nek5_svn/trunk/tools/prenek' > make: *** [all] Error 1 > ************************************************************************** > > On Mon, May 3, 2010 9:38 am, nek5000-users at lists.mcs.anl.gov wrote: >> Can you try on another Linux box? You can get the Intel compilers (non >> commercial usage) for free. >> Sorry I don't want to login into other machines unless it's really needed. >> >> Stefan >> >> On May 3, 2010, at 4:34 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Stefan, >>> >>> I do not have any other compiler on the cluster. I can give you my login >>> to check the problem. >>> >>> Thanks, >>> >>> Harish. >>> >>> On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi Harish, >>>> >>>> unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ >>>> gfortran 4.5). >>>> Can you try again using another compiler? >>>> >>>> Stefan >>>> >>>> >>>> On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hello, >>>>> >>>>> I am compiling prenek with GNU compilers, gfortran-4.3.2 and >>>>> gcc-4.3.2. >>>>> When I compile it without "BIGMEM" flag it gives an error, the output >>>>> of >>>>> it is attached (error.out). With "BIGMEM" flag turned on, there are no >>>>> compiler errors (compile.out). But when I try to open pretex or prex, >>>>> I >>>>> get the following error. >>>>> >>>>> [harish at cmtl hole-in-center]$ prex >>>>> Killed >>>>> [harish at cmtl hole-in-center]$ pretex >>>>> Killed >>>>> >>>>> All the other tools are working fine. Any help in solving this issue >>>>> is >>>>> appreciated. >>>>> >>>>> Thanks, >>>>> >>>>> Harish. >>>>> _______________________________________________ >>>>> 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 May 3 12:10:32 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 12:10:32 -0500 (CDT) Subject: [Nek5000-users] prex & pretex not working In-Reply-To: <4D5AC257-4D39-4749-BF61-F898757CF542@lav.mavt.ethz.ch> References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> <4D5AC257-4D39-4749-BF61-F898757CF542@lav.mavt.ethz.ch> Message-ID: Hi Stefan, Sorry for missing out on that problem report. But I tried changing the F77 compiler as below and it does not work. "maketools all" does nothing. F77="ifort -shared-intel" Also, this is on a different linux box not on my cluster which has GNU compiler. Thanks, Harish. On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > I know. There was a problem report on the mailing list already. > > This was my answer: > > Ok I think I know a way to fix the Intel compiler problem. > > To compile prenek (prex) you need to enable the BIGMEM support so you have to use at least the medium memory model. However the Intel compilers wants you to link all Intel-Libs dynamically if you use another memory model than small. > > Just set F77= "ifort -shared-intel" and it should work! > > hth, > Stefan > > On May 3, 2010, at 5:45 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Stefan, > > > > I tried compiling prenek on NCSA-Abe machine with ifort & icc. I get the > > following error, its same error w/ and w/o "BIGMEM" flag. > > > > Thanks, > > > > Harish. > > > > ************************************************************************* > > icc -c -DUNDERSCORE -Dr8 xdriver.c > > xdriver.c(875): warning #266: function "fprep_" declared implicitly > > fprep_ (); /* run Fortran Main code */ > > ^ > > > > xdriver.c(123): (col. 5) remark: LOOP WAS VECTORIZED. > > xdriver.c(125): (col. 5) remark: LOOP WAS VECTORIZED. > > xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. > > xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. > > xdriver.c(747): (col. 4) remark: LOOP WAS VECTORIZED. > > xdriver.c(823): (col. 4) remark: LOOP WAS VECTORIZED. > > xdriver.c(700): (col. 5) remark: LOOP WAS VECTORIZED. > > xdriver.c(333): (col. 5) remark: LOOP WAS VECTORIZED. > > xdriver.c(340): (col. 5) remark: LOOP WAS VECTORIZED. > > ifort -o /u/ac/kanch1/nek5_svn/trunk/tools/prex prenek.o curve.o edit.o > > build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o > > vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o > > xdriver.o -L/usr/X11R6/lib64 -lX11 -lm > > prenek.o(.text+0x47d): In function `drivfc_': > > : relocation truncated to fit: R_X86_64_PC32 chaar_ > > prenek.o(.text+0x4f9): In function `drivfc_': > > : relocation truncated to fit: R_X86_64_PC32 chaar_ > > prenek.o(.text+0x50d): In function `drivfc_': > > : relocation truncated to fit: R_X86_64_PC32 basics_ > > prenek.o(.text+0x584): In function `drivfc_': > > : relocation truncated to fit: R_X86_64_PC32 devs_ > > prenek.o(.text+0x5b1): In function `drivfc_': > > : relocation truncated to fit: R_X86_64_PC32 chaar_ > > prenek.o(.text+0x62d): In function `drivfc_': > > : relocation truncated to fit: R_X86_64_PC32 chaar_ > > prenek.o(.text+0x667): In function `drivfc_': > > : relocation truncated to fit: R_X86_64_32S chaar_ > > prenek.o(.text+0x740): In function `drivfc_': > > : relocation truncated to fit: R_X86_64_PC32 modes_ > > prenek.o(.text+0x789): In function `drivfc_': > > : relocation truncated to fit: R_X86_64_PC32 chaar_ > > prenek.o(.text+0x7fc): In function `drivfc_': > > : relocation truncated to fit: R_X86_64_PC32 chaar_ > > prenek.o(.text+0x80c): In function `drivfc_': > > : additional relocation overflows omitted from the output > > make[1]: *** [prex] Error 1 > > make[1]: Leaving directory `/u/ac/kanch1/nek5_svn/trunk/tools/prenek' > > make: *** [all] Error 1 > > ************************************************************************** > > > > On Mon, May 3, 2010 9:38 am, nek5000-users at lists.mcs.anl.gov wrote: > >> Can you try on another Linux box? You can get the Intel compilers (non > >> commercial usage) for free. > >> Sorry I don't want to login into other machines unless it's really needed. > >> > >> Stefan > >> > >> On May 3, 2010, at 4:34 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hi Stefan, > >>> > >>> I do not have any other compiler on the cluster. I can give you my login > >>> to check the problem. > >>> > >>> Thanks, > >>> > >>> Harish. > >>> > >>> On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > >>> > >>>> Hi Harish, > >>>> > >>>> unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ > >>>> gfortran 4.5). > >>>> Can you try again using another compiler? > >>>> > >>>> Stefan > >>>> > >>>> > >>>> On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> I am compiling prenek with GNU compilers, gfortran-4.3.2 and > >>>>> gcc-4.3.2. > >>>>> When I compile it without "BIGMEM" flag it gives an error, the output > >>>>> of > >>>>> it is attached (error.out). With "BIGMEM" flag turned on, there are no > >>>>> compiler errors (compile.out). But when I try to open pretex or prex, > >>>>> I > >>>>> get the following error. > >>>>> > >>>>> [harish at cmtl hole-in-center]$ prex > >>>>> Killed > >>>>> [harish at cmtl hole-in-center]$ pretex > >>>>> Killed > >>>>> > >>>>> All the other tools are working fine. Any help in solving this issue > >>>>> is > >>>>> appreciated. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Harish. > >>>>> _______________________________________________ > >>>>> 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 May 3 13:05:08 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 20:05:08 +0200 Subject: [Nek5000-users] prex & pretex not working In-Reply-To: References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> <4D5AC257-4D39-4749-BF61-F898757CF542@lav.mavt.ethz.ch> Message-ID: <0F735E7F-123A-4E71-86A3-57817C15C590@lav.mavt.ethz.ch> Please send the output of './maketools prenek' Stefan On May 3, 2010, at 7:10 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > Sorry for missing out on that problem report. > > But I tried changing the F77 compiler as below and it does not work. > "maketools all" does nothing. > > F77="ifort -shared-intel" > > Also, this is on a different linux box not on my cluster which has GNU > compiler. > > Thanks, > > Harish. > > On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > >> I know. There was a problem report on the mailing list already. >> >> This was my answer: >> >> Ok I think I know a way to fix the Intel compiler problem. >> >> To compile prenek (prex) you need to enable the BIGMEM support so you have to use at least the medium memory model. However the Intel compilers wants you to link all Intel-Libs dynamically if you use another memory model than small. >> >> Just set F77= "ifort -shared-intel" and it should work! >> >> hth, >> Stefan >> >> On May 3, 2010, at 5:45 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Stefan, >>> >>> I tried compiling prenek on NCSA-Abe machine with ifort & icc. I get the >>> following error, its same error w/ and w/o "BIGMEM" flag. >>> >>> Thanks, >>> >>> Harish. >>> >>> ************************************************************************* >>> icc -c -DUNDERSCORE -Dr8 xdriver.c >>> xdriver.c(875): warning #266: function "fprep_" declared implicitly >>> fprep_ (); /* run Fortran Main code */ >>> ^ >>> >>> xdriver.c(123): (col. 5) remark: LOOP WAS VECTORIZED. >>> xdriver.c(125): (col. 5) remark: LOOP WAS VECTORIZED. >>> xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. >>> xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. >>> xdriver.c(747): (col. 4) remark: LOOP WAS VECTORIZED. >>> xdriver.c(823): (col. 4) remark: LOOP WAS VECTORIZED. >>> xdriver.c(700): (col. 5) remark: LOOP WAS VECTORIZED. >>> xdriver.c(333): (col. 5) remark: LOOP WAS VECTORIZED. >>> xdriver.c(340): (col. 5) remark: LOOP WAS VECTORIZED. >>> ifort -o /u/ac/kanch1/nek5_svn/trunk/tools/prex prenek.o curve.o edit.o >>> build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o >>> vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o >>> xdriver.o -L/usr/X11R6/lib64 -lX11 -lm >>> prenek.o(.text+0x47d): In function `drivfc_': >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>> prenek.o(.text+0x4f9): In function `drivfc_': >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>> prenek.o(.text+0x50d): In function `drivfc_': >>> : relocation truncated to fit: R_X86_64_PC32 basics_ >>> prenek.o(.text+0x584): In function `drivfc_': >>> : relocation truncated to fit: R_X86_64_PC32 devs_ >>> prenek.o(.text+0x5b1): In function `drivfc_': >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>> prenek.o(.text+0x62d): In function `drivfc_': >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>> prenek.o(.text+0x667): In function `drivfc_': >>> : relocation truncated to fit: R_X86_64_32S chaar_ >>> prenek.o(.text+0x740): In function `drivfc_': >>> : relocation truncated to fit: R_X86_64_PC32 modes_ >>> prenek.o(.text+0x789): In function `drivfc_': >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>> prenek.o(.text+0x7fc): In function `drivfc_': >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>> prenek.o(.text+0x80c): In function `drivfc_': >>> : additional relocation overflows omitted from the output >>> make[1]: *** [prex] Error 1 >>> make[1]: Leaving directory `/u/ac/kanch1/nek5_svn/trunk/tools/prenek' >>> make: *** [all] Error 1 >>> ************************************************************************** >>> >>> On Mon, May 3, 2010 9:38 am, nek5000-users at lists.mcs.anl.gov wrote: >>>> Can you try on another Linux box? You can get the Intel compilers (non >>>> commercial usage) for free. >>>> Sorry I don't want to login into other machines unless it's really needed. >>>> >>>> Stefan >>>> >>>> On May 3, 2010, at 4:34 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi Stefan, >>>>> >>>>> I do not have any other compiler on the cluster. I can give you my login >>>>> to check the problem. >>>>> >>>>> Thanks, >>>>> >>>>> Harish. >>>>> >>>>> On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>>> Hi Harish, >>>>>> >>>>>> unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ >>>>>> gfortran 4.5). >>>>>> Can you try again using another compiler? >>>>>> >>>>>> Stefan >>>>>> >>>>>> >>>>>> On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am compiling prenek with GNU compilers, gfortran-4.3.2 and >>>>>>> gcc-4.3.2. >>>>>>> When I compile it without "BIGMEM" flag it gives an error, the output >>>>>>> of >>>>>>> it is attached (error.out). With "BIGMEM" flag turned on, there are no >>>>>>> compiler errors (compile.out). But when I try to open pretex or prex, >>>>>>> I >>>>>>> get the following error. >>>>>>> >>>>>>> [harish at cmtl hole-in-center]$ prex >>>>>>> Killed >>>>>>> [harish at cmtl hole-in-center]$ pretex >>>>>>> Killed >>>>>>> >>>>>>> All the other tools are working fine. Any help in solving this issue >>>>>>> is >>>>>>> appreciated. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Harish. >>>>>>> _______________________________________________ >>>>>>> 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 May 3 13:14:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 13:14:48 -0500 (CDT) Subject: [Nek5000-users] prex & pretex not working In-Reply-To: <0F735E7F-123A-4E71-86A3-57817C15C590@lav.mavt.ethz.ch> References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> <4D5AC257-4D39-4749-BF61-F898757CF542@lav.mavt.ethz.ch> <0F735E7F-123A-4E71-86A3-57817C15C590@lav.mavt.ethz.ch> Message-ID: Hi Stefan, The command does not do anything. Here is the output of the command. It does not display anything. [kanch1 at honest3 tools]$ ./maketools prenek [kanch1 at honest3 tools]$ Thanks, Harish. On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > Please send the output of './maketools prenek' > > Stefan > > > On May 3, 2010, at 7:10 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Stefan, > > > > Sorry for missing out on that problem report. > > > > But I tried changing the F77 compiler as below and it does not work. > > "maketools all" does nothing. > > > > F77="ifort -shared-intel" > > > > Also, this is on a different linux box not on my cluster which has GNU > > compiler. > > > > Thanks, > > > > Harish. > > > > On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > > > >> I know. There was a problem report on the mailing list already. > >> > >> This was my answer: > >> > >> Ok I think I know a way to fix the Intel compiler problem. > >> > >> To compile prenek (prex) you need to enable the BIGMEM support so you have to use at least the medium memory model. However the Intel compilers wants you to link all Intel-Libs dynamically if you use another memory model than small. > >> > >> Just set F77= "ifort -shared-intel" and it should work! > >> > >> hth, > >> Stefan > >> > >> On May 3, 2010, at 5:45 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hi Stefan, > >>> > >>> I tried compiling prenek on NCSA-Abe machine with ifort & icc. I get the > >>> following error, its same error w/ and w/o "BIGMEM" flag. > >>> > >>> Thanks, > >>> > >>> Harish. > >>> > >>> ************************************************************************* > >>> icc -c -DUNDERSCORE -Dr8 xdriver.c > >>> xdriver.c(875): warning #266: function "fprep_" declared implicitly > >>> fprep_ (); /* run Fortran Main code */ > >>> ^ > >>> > >>> xdriver.c(123): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(125): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(747): (col. 4) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(823): (col. 4) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(700): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(333): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(340): (col. 5) remark: LOOP WAS VECTORIZED. > >>> ifort -o /u/ac/kanch1/nek5_svn/trunk/tools/prex prenek.o curve.o edit.o > >>> build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o > >>> vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o > >>> xdriver.o -L/usr/X11R6/lib64 -lX11 -lm > >>> prenek.o(.text+0x47d): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x4f9): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x50d): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 basics_ > >>> prenek.o(.text+0x584): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 devs_ > >>> prenek.o(.text+0x5b1): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x62d): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x667): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_32S chaar_ > >>> prenek.o(.text+0x740): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 modes_ > >>> prenek.o(.text+0x789): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x7fc): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x80c): In function `drivfc_': > >>> : additional relocation overflows omitted from the output > >>> make[1]: *** [prex] Error 1 > >>> make[1]: Leaving directory `/u/ac/kanch1/nek5_svn/trunk/tools/prenek' > >>> make: *** [all] Error 1 > >>> ************************************************************************** > >>> > >>> On Mon, May 3, 2010 9:38 am, nek5000-users at lists.mcs.anl.gov wrote: > >>>> Can you try on another Linux box? You can get the Intel compilers (non > >>>> commercial usage) for free. > >>>> Sorry I don't want to login into other machines unless it's really needed. > >>>> > >>>> Stefan > >>>> > >>>> On May 3, 2010, at 4:34 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Hi Stefan, > >>>>> > >>>>> I do not have any other compiler on the cluster. I can give you my login > >>>>> to check the problem. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Harish. > >>>>> > >>>>> On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > >>>>> > >>>>>> Hi Harish, > >>>>>> > >>>>>> unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ > >>>>>> gfortran 4.5). > >>>>>> Can you try again using another compiler? > >>>>>> > >>>>>> Stefan > >>>>>> > >>>>>> > >>>>>> On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> I am compiling prenek with GNU compilers, gfortran-4.3.2 and > >>>>>>> gcc-4.3.2. > >>>>>>> When I compile it without "BIGMEM" flag it gives an error, the output > >>>>>>> of > >>>>>>> it is attached (error.out). With "BIGMEM" flag turned on, there are no > >>>>>>> compiler errors (compile.out). But when I try to open pretex or prex, > >>>>>>> I > >>>>>>> get the following error. > >>>>>>> > >>>>>>> [harish at cmtl hole-in-center]$ prex > >>>>>>> Killed > >>>>>>> [harish at cmtl hole-in-center]$ pretex > >>>>>>> Killed > >>>>>>> > >>>>>>> All the other tools are working fine. Any help in solving this issue > >>>>>>> is > >>>>>>> appreciated. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Harish. > >>>>>>> _______________________________________________ > >>>>>>> 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 > > _______________________________________________ > 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 May 3 13:36:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 03 May 2010 20:36:59 +0200 Subject: [Nek5000-users] Solution for Re: genbox error In-Reply-To: <1272888805.18612.127.camel@localhost.localdomain> References: <1272888805.18612.127.camel@localhost.localdomain> Message-ID: <1272911819.18612.145.camel@localhost.localdomain> Hello all, Genbox has an issue in that the number of characters in a line for its input file was <= 80. This makes it impossible to have a large number of elements in one direction if one is specifying the element locations. A solution is to extend the line length to 9999999. A version with this change is at. http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/genbox.f The diff between old & new is: diff */genbox.f ../*1/g*/genbox.f 1157,1158c1157,1158 < character*9999999 string < character*1 string1(9999999) --- > character*80 string > character*1 string1(80) 1167c1167 < call blank(string,9999999) --- > call blank(string,80) 1174c1174 < len = ltrunc(string,9999999) --- > len = ltrunc(string,80) 1184,1185c1184,1185 < 80 format(a9999999) < 81 format(9999999a1) --- > 80 format(a80) > 81 format(80a1) On Mon, 2010-05-03 at 14:13 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I have come across what may be an error in genbox. It concerns reading > in data. If instead of 8 elements, 7 are used or if the trailing zeros > are removed, all is fine. It almost seems as if genbox has a limitation > on the length of the lines defining the element edges. > > Cheers, > Frank > > Reading 32 = 8 4 4 elements for box 1. > Reading 2 = > error: 8 9 > error: 0 5 > > > The following is the input file: > > openboat2D.rea > -2 spatial dimension > 2 number of fields > #======================================================== > # > # Open boat with the Marangoni effect at the top surface. > # > #======================================================== > # > Box > 8 4 > -4.000000 -3.946236 -3.806717 -3.497438 -3.000000 -2.500000 -2.000000 > -1.500000 -1.000000 > -5.000000 -3.347128 0.000000 3.754690 5.000000 > W ,W ,W ,shl, V bc's ! NB: 3 characters each ! > t ,t , , , T bc's ! You must have 2 spaces!! > > > > -- 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 May 3 13:47:05 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 20:47:05 +0200 Subject: [Nek5000-users] Solution for Re: genbox error In-Reply-To: <1272911819.18612.145.camel@localhost.localdomain> References: <1272888805.18612.127.camel@localhost.localdomain> <1272911819.18612.145.camel@localhost.localdomain> Message-ID: <9BC512BA-FAFB-407D-B8E1-F482C634214D@lav.mavt.ethz.ch> Please don't start distributing some code because it will end up in a mess! That's why we have a central and public available SVN server. If you think you know how to improve something please contact one of the developers. We will review the code and may add it to the repo. Stefan On May 3, 2010, at 8:36 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > Genbox has an issue in that the number of characters in a line for its > input file was <= 80. This makes it impossible to have a large number > of elements in one direction if one is specifying the element > locations. > > A solution is to extend the line length to 9999999. A version with this > change is at. > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/genbox.f > > The diff between old & new is: > > diff */genbox.f ../*1/g*/genbox.f > 1157,1158c1157,1158 > < character*9999999 string > < character*1 string1(9999999) > --- >> character*80 string >> character*1 string1(80) > 1167c1167 > < call blank(string,9999999) > --- >> call blank(string,80) > 1174c1174 > < len = ltrunc(string,9999999) > --- >> len = ltrunc(string,80) > 1184,1185c1184,1185 > < 80 format(a9999999) > < 81 format(9999999a1) > --- >> 80 format(a80) >> 81 format(80a1) > > > > > > > On Mon, 2010-05-03 at 14:13 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Hello all, >> >> I have come across what may be an error in genbox. It concerns reading >> in data. If instead of 8 elements, 7 are used or if the trailing zeros >> are removed, all is fine. It almost seems as if genbox has a limitation >> on the length of the lines defining the element edges. >> >> Cheers, >> Frank >> >> Reading 32 = 8 4 4 elements for box 1. >> Reading 2 = >> error: 8 9 >> error: 0 5 >> >> >> The following is the input file: >> >> openboat2D.rea >> -2 spatial dimension >> 2 number of fields >> #======================================================== >> # >> # Open boat with the Marangoni effect at the top surface. >> # >> #======================================================== >> # >> Box >> 8 4 >> -4.000000 -3.946236 -3.806717 -3.497438 -3.000000 -2.500000 -2.000000 >> -1.500000 -1.000000 >> -5.000000 -3.347128 0.000000 3.754690 5.000000 >> W ,W ,W ,shl, V bc's ! NB: 3 characters each ! >> t ,t , , , T bc's ! You must have 2 spaces!! >> >> >> >> > -- > 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 May 3 14:56:26 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 14:56:26 -0500 Subject: [Nek5000-users] Warning Message : L1/L2 DIV(V) Message-ID: Dear Developers, I am trying to run an LES in a turbine blade passage and I ran into this warning message during my production run: L1/L2 DIV(V) : 1.9224E-01 2.3951E+00 L1/L2 QTL : 1.9180E-01 2.3014E+00 L1/L2 DIV(V)-QTL: 4.3317E-04 6.6792E-01 WARNING: DIV(V)-QTL too large! I tried to grep it to the source code and found that the quantity QTL refers to the thermal divergence ( I do use usrdiv in my outlet ). But my case is purely from a fluids perspective and does not involve heat transfer. So I am wondering how QTL would pop up in my simulation. And I also noted that the error message comes up only when I use PN-PN basis function. I would like to know if this error message is a concern at all . Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 3 14:59:33 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 14:59:33 -0500 (CDT) Subject: [Nek5000-users] Solution for Re: genbox error In-Reply-To: <9BC512BA-FAFB-407D-B8E1-F482C634214D@lav.mavt.ethz.ch> Message-ID: <32128926.836061272916773169.JavaMail.root@zimbra> Hello, I disagree that genbox reuires a fix for meshes with large number of elements in one direction -- below is a part of .box file with nelx=27 written with each element coordinate per new line: Best, Aleks # Box 27 -106 -54 (nelx,nely,nelz for Box) 0.5378790 0.5463419 0.5556915 0.5663933 0.5789130 0.5936488 0.6109992 0.6329137 0.6599956 0.6928485 0.7320758 0.7782808 0.8320671 0.8933098 0.9533322 1.0101231 1.0637385 1.1142344 1.1616669 1.2060918 1.2475652 1.2890386 1.3305120 1.3719854 1.4134588 1.4549322 1.4964056 1.5378790 (x0,x1,gain or x ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, May 3, 2010 1:47:05 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Solution for Re: genbox error Please don't start distributing some code because it will end up in a mess! That's why we have a central and public available SVN server. If you think you know how to improve something please contact one of the developers. We will review the code and may add it to the repo. Stefan On May 3, 2010, at 8:36 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > Genbox has an issue in that the number of characters in a line for its > input file was <= 80. This makes it impossible to have a large number > of elements in one direction if one is specifying the element > locations. > > A solution is to extend the line length to 9999999. A version with this > change is at. > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/genbox.f > > The diff between old & new is: > > diff */genbox.f ../*1/g*/genbox.f > 1157,1158c1157,1158 > < character*9999999 string > < character*1 string1(9999999) > --- >> character*80 string >> character*1 string1(80) > 1167c1167 > < call blank(string,9999999) > --- >> call blank(string,80) > 1174c1174 > < len = ltrunc(string,9999999) > --- >> len = ltrunc(string,80) > 1184,1185c1184,1185 > < 80 format(a9999999) > < 81 format(9999999a1) > --- >> 80 format(a80) >> 81 format(80a1) > > > > > > > On Mon, 2010-05-03 at 14:13 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Hello all, >> >> I have come across what may be an error in genbox. It concerns reading >> in data. If instead of 8 elements, 7 are used or if the trailing zeros >> are removed, all is fine. It almost seems as if genbox has a limitation >> on the length of the lines defining the element edges. >> >> Cheers, >> Frank >> >> Reading 32 = 8 4 4 elements for box 1. >> Reading 2 = >> error: 8 9 >> error: 0 5 >> >> >> The following is the input file: >> >> openboat2D.rea >> -2 spatial dimension >> 2 number of fields >> #======================================================== >> # >> # Open boat with the Marangoni effect at the top surface. >> # >> #======================================================== >> # >> Box >> 8 4 >> -4.000000 -3.946236 -3.806717 -3.497438 -3.000000 -2.500000 -2.000000 >> -1.500000 -1.000000 >> -5.000000 -3.347128 0.000000 3.754690 5.000000 >> W ,W ,W ,shl, V bc's ! NB: 3 characters each ! >> t ,t , , , T bc's ! You must have 2 spaces!! >> >> >> >> > -- > 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 Mon May 3 15:05:43 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 22:05:43 +0200 Subject: [Nek5000-users] Warning Message : L1/L2 DIV(V) In-Reply-To: References: Message-ID: <96914446-9E95-4C23-B629-4D95BE82C3FE@lav.mavt.ethz.ch> The WARNING tells you that the divergence of your flow field is too large. It's hard to say why this happens because there are many possible reasons (wrong bc, resolution to low, timestep to large, etc.). I agree in your case the thermal divergence is ZERO. In your case the norms of div(v) and div(v)-qtl should be the same because qtl=0. Do you add some divergence to the outflow boundary? In this case the user specified divergence will be stored using qtl. Stefan On May 3, 2010, at 9:56 PM, nek5000-users at lists.mcs.anl.gov wrote: > Dear Developers, > > I am trying to run an LES in a turbine blade passage and I ran into this warning message during my production run: > > L1/L2 DIV(V) : 1.9224E-01 2.3951E+00 > L1/L2 QTL : 1.9180E-01 2.3014E+00 > L1/L2 DIV(V)-QTL: 4.3317E-04 6.6792E-01 > WARNING: DIV(V)-QTL too large! > > I tried to grep it to the source code and found that the quantity QTL refers to the thermal divergence ( I do use usrdiv in my outlet ). But my case is purely from a fluids perspective and does not involve heat transfer. So I am wondering how QTL would pop up in my simulation. And I also noted that the error message comes up only when I use PN-PN basis function. I would like to know if this error message is a concern at all . > > 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 Mon May 3 15:15:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 15:15:00 -0500 Subject: [Nek5000-users] Warning Message : L1/L2 DIV(V) In-Reply-To: References: Message-ID: Hi Stefan, I have 23k elements and an lx1=11, so I am guessing my resolution is reasonably good (32 Mil Nodes) . As regarding the boundary conditions, yes I do add some divergence at the outflow. I am running it at CFL of close to 2 with 2nd order time stepping. Would you recommend lowering the Courant to say 0.5 ? Even though the warning pops up, I don't see any crazy stuff happening in my flow . Regards Shriram Jagannathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 3 15:29:31 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 22:29:31 +0200 Subject: [Nek5000-users] Warning Message : L1/L2 DIV(V) In-Reply-To: References: Message-ID: <80DABCBE-EC89-48B8-B4C6-52780C1D2300@lav.mavt.ethz.ch> Well I cannot tell you if you resolution is large enough. As you know this depends on the scales you need to resolve. Is this a DNS resolution? If you do some large scale runs I recommend to run with lx1=8 and a larger number of elements. A high polynomial order N is typically not needed for engineering type problems. In addition there are several reason why you don't want to increase N more than needed: - CFL scales with 1/N^2 so with a higher N you have to use a smaller dt - the number of pressure iterations may depend on N (depending on your mesh and preconditioner) Are you using IFCHAR=T? Filtering? Dealiasing? You may want to post the logfile. Stefan On May 3, 2010, at 10:15 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > I have 23k elements and an lx1=11, so I am guessing my resolution is reasonably good (32 Mil Nodes) . As regarding the boundary conditions, yes I do add some divergence at the outflow. I am running it at CFL of close to 2 with 2nd order time stepping. Would you recommend lowering the Courant to say 0.5 ? Even though the warning pops up, I don't see any crazy stuff happening in my flow . > > > 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 Mon May 3 15:33:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 03 May 2010 22:33:53 +0200 Subject: [Nek5000-users] Solution for Re: genbox error In-Reply-To: <32128926.836061272916773169.JavaMail.root@zimbra> References: <32128926.836061272916773169.JavaMail.root@zimbra> Message-ID: <1272918833.18612.153.camel@localhost.localdomain> Hello Aleks, Yes, I see this would work also. I was (stubbornly) following the examples; everything on one line for each coordinate direction. Thanks, Frank On Mon, 2010-05-03 at 14:59 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I disagree that genbox reuires a fix for meshes with large number of elements in one direction -- below is a part of .box file with nelx=27 written with each element coordinate per new line: > > Best, > Aleks > > # > Box > 27 -106 -54 (nelx,nely,nelz for Box) > 0.5378790 > 0.5463419 > 0.5556915 > 0.5663933 > 0.5789130 > 0.5936488 > 0.6109992 > 0.6329137 > 0.6599956 > 0.6928485 > 0.7320758 > 0.7782808 > 0.8320671 > 0.8933098 > 0.9533322 > 1.0101231 > 1.0637385 > 1.1142344 > 1.1616669 > 1.2060918 > 1.2475652 > 1.2890386 > 1.3305120 > 1.3719854 > 1.4134588 > 1.4549322 > 1.4964056 > 1.5378790 (x0,x1,gain or x > > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, May 3, 2010 1:47:05 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] Solution for Re: genbox error > > Please don't start distributing some code because it will end up in a mess! That's why we have a central and public available SVN server. > > If you think you know how to improve something please contact one of the developers. We will review the code and may add it to the repo. > > Stefan > > On May 3, 2010, at 8:36 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > > > Genbox has an issue in that the number of characters in a line for its > > input file was <= 80. This makes it impossible to have a large number > > of elements in one direction if one is specifying the element > > locations. > > > > A solution is to extend the line length to 9999999. A version with this > > change is at. > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/genbox.f > > > > The diff between old & new is: > > > > diff */genbox.f ../*1/g*/genbox.f > > 1157,1158c1157,1158 > > < character*9999999 string > > < character*1 string1(9999999) > > --- > >> character*80 string > >> character*1 string1(80) > > 1167c1167 > > < call blank(string,9999999) > > --- > >> call blank(string,80) > > 1174c1174 > > < len = ltrunc(string,9999999) > > --- > >> len = ltrunc(string,80) > > 1184,1185c1184,1185 > > < 80 format(a9999999) > > < 81 format(9999999a1) > > --- > >> 80 format(a80) > >> 81 format(80a1) > > > > > > > > > > > > > > On Mon, 2010-05-03 at 14:13 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hello all, > >> > >> I have come across what may be an error in genbox. It concerns reading > >> in data. If instead of 8 elements, 7 are used or if the trailing zeros > >> are removed, all is fine. It almost seems as if genbox has a limitation > >> on the length of the lines defining the element edges. > >> > >> Cheers, > >> Frank > >> > >> Reading 32 = 8 4 4 elements for box 1. > >> Reading 2 = > >> error: 8 9 > >> error: 0 5 > >> > >> > >> The following is the input file: > >> > >> openboat2D.rea > >> -2 spatial dimension > >> 2 number of fields > >> #======================================================== > >> # > >> # Open boat with the Marangoni effect at the top surface. > >> # > >> #======================================================== > >> # > >> Box > >> 8 4 > >> -4.000000 -3.946236 -3.806717 -3.497438 -3.000000 -2.500000 -2.000000 > >> -1.500000 -1.000000 > >> -5.000000 -3.347128 0.000000 3.754690 5.000000 > >> W ,W ,W ,shl, V bc's ! NB: 3 characters each ! > >> t ,t , , , T bc's ! You must have 2 spaces!! > >> > >> > >> > >> > > -- > > 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 > _______________________________________________ > 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 May 3 15:39:01 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 22:39:01 +0200 Subject: [Nek5000-users] Solution for Re: genbox error In-Reply-To: <1272918833.18612.153.camel@localhost.localdomain> References: <32128926.836061272916773169.JavaMail.root@zimbra> <1272918833.18612.153.camel@localhost.localdomain> Message-ID: <421CE8B1-7986-427B-8A88-79967B587E5E@lav.mavt.ethz.ch> Thanks for bringing this up. That's a typical situation. We know Nek and the Tools are not straightforward to use and there are many undocumented tricks and options. It simply takes some time to become familiar with it. But I guess that's true for all software. Sorry for all the trouble. Stefan On May 3, 2010, at 10:33 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Aleks, > > Yes, I see this would work also. I was (stubbornly) following the > examples; everything on one line for each coordinate direction. > > Thanks, > Frank > > > On Mon, 2010-05-03 at 14:59 -0500, nek5000-users at lists.mcs.anl.gov > wrote: >> Hello, >> >> I disagree that genbox reuires a fix for meshes with large number of elements in one direction -- below is a part of .box file with nelx=27 written with each element coordinate per new line: >> >> Best, >> Aleks >> >> # >> Box >> 27 -106 -54 (nelx,nely,nelz for Box) >> 0.5378790 >> 0.5463419 >> 0.5556915 >> 0.5663933 >> 0.5789130 >> 0.5936488 >> 0.6109992 >> 0.6329137 >> 0.6599956 >> 0.6928485 >> 0.7320758 >> 0.7782808 >> 0.8320671 >> 0.8933098 >> 0.9533322 >> 1.0101231 >> 1.0637385 >> 1.1142344 >> 1.1616669 >> 1.2060918 >> 1.2475652 >> 1.2890386 >> 1.3305120 >> 1.3719854 >> 1.4134588 >> 1.4549322 >> 1.4964056 >> 1.5378790 (x0,x1,gain or x >> >> >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Monday, May 3, 2010 1:47:05 PM GMT -06:00 US/Canada Central >> Subject: Re: [Nek5000-users] Solution for Re: genbox error >> >> Please don't start distributing some code because it will end up in a mess! That's why we have a central and public available SVN server. >> >> If you think you know how to improve something please contact one of the developers. We will review the code and may add it to the repo. >> >> Stefan >> >> On May 3, 2010, at 8:36 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello all, >>> >>> Genbox has an issue in that the number of characters in a line for its >>> input file was <= 80. This makes it impossible to have a large number >>> of elements in one direction if one is specifying the element >>> locations. >>> >>> A solution is to extend the line length to 9999999. A version with this >>> change is at. >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/genbox.f >>> >>> The diff between old & new is: >>> >>> diff */genbox.f ../*1/g*/genbox.f >>> 1157,1158c1157,1158 >>> < character*9999999 string >>> < character*1 string1(9999999) >>> --- >>>> character*80 string >>>> character*1 string1(80) >>> 1167c1167 >>> < call blank(string,9999999) >>> --- >>>> call blank(string,80) >>> 1174c1174 >>> < len = ltrunc(string,9999999) >>> --- >>>> len = ltrunc(string,80) >>> 1184,1185c1184,1185 >>> < 80 format(a9999999) >>> < 81 format(9999999a1) >>> --- >>>> 80 format(a80) >>>> 81 format(80a1) >>> >>> >>> >>> >>> >>> >>> On Mon, 2010-05-03 at 14:13 +0200, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Hello all, >>>> >>>> I have come across what may be an error in genbox. It concerns reading >>>> in data. If instead of 8 elements, 7 are used or if the trailing zeros >>>> are removed, all is fine. It almost seems as if genbox has a limitation >>>> on the length of the lines defining the element edges. >>>> >>>> Cheers, >>>> Frank >>>> >>>> Reading 32 = 8 4 4 elements for box 1. >>>> Reading 2 = >>>> error: 8 9 >>>> error: 0 5 >>>> >>>> >>>> The following is the input file: >>>> >>>> openboat2D.rea >>>> -2 spatial dimension >>>> 2 number of fields >>>> #======================================================== >>>> # >>>> # Open boat with the Marangoni effect at the top surface. >>>> # >>>> #======================================================== >>>> # >>>> Box >>>> 8 4 >>>> -4.000000 -3.946236 -3.806717 -3.497438 -3.000000 -2.500000 -2.000000 >>>> -1.500000 -1.000000 >>>> -5.000000 -3.347128 0.000000 3.754690 5.000000 >>>> W ,W ,W ,shl, V bc's ! NB: 3 characters each ! >>>> t ,t , , , T bc's ! You must have 2 spaces!! >>>> >>>> >>>> >>>> >>> -- >>> 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 >> _______________________________________________ >> 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 May 3 15:52:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 15:52:25 -0500 Subject: [Nek5000-users] Warning Message : L1/L2 DIV(V) In-Reply-To: References: Message-ID: Hi Stefan, I am running an LES with the following parameters: 1. p101=3 and p103 =0.05(filter weight). 2. De aliasing enabled and set to 16. (lxd = 16 ) 4. lx1 = 11 3. Yes, IFCHAR is on and a CFL close to 2 is used. 4. I add some divergence to the flow outlet using the same procedure detailed in the examples. This is my first flow through the domain and I intend to run it for a couple more depending on the results. Thank you for the info on order of interpolation polynomial. I would have to refine my domain in order to match the resolution by reducing the lx1. I will look into it. Please find attached pieces of rea and log file stacked together in the attachment. Thanks. Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logfile Type: application/octet-stream Size: 12149 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon May 3 15:53:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 May 2010 15:53:50 -0500 (CDT) Subject: [Nek5000-users] Solution for Re: genbox error In-Reply-To: <1272911819.18612.145.camel@localhost.localdomain> References: <1272888805.18612.127.camel@localhost.localdomain> <1272911819.18612.145.camel@localhost.localdomain> Message-ID: There is no problem with having more than one line, however? Paul On Mon, 3 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, Genbox has an issue in that the number of characters in a line for its input file was <= 80. This makes it impossible to have a large number of elements in one direction if one is specifying the element locations. A solution is to extend the line length to 9999999. A version with this change is at. http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/genbox.f The diff between old & new is: diff */genbox.f ../*1/g*/genbox.f 1157,1158c1157,1158 < character*9999999 string < character*1 string1(9999999) --- > character*80 string > character*1 string1(80) 1167c1167 < call blank(string,9999999) --- > call blank(string,80) 1174c1174 < len = ltrunc(string,9999999) --- > len = ltrunc(string,80) 1184,1185c1184,1185 < 80 format(a9999999) < 81 format(9999999a1) --- > 80 format(a80) > 81 format(80a1) On Mon, 2010-05-03 at 14:13 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I have come across what may be an error in genbox. It concerns reading > in data. If instead of 8 elements, 7 are used or if the trailing zeros > are removed, all is fine. It almost seems as if genbox has a limitation > on the length of the lines defining the element edges. > > Cheers, > Frank > > Reading 32 = 8 4 4 elements for box 1. > Reading 2 = > error: 8 9 > error: 0 5 > > > The following is the input file: > > openboat2D.rea > -2 spatial dimension > 2 number of fields > #======================================================== > # > # Open boat with the Marangoni effect at the top surface. > # > #======================================================== > # > Box > 8 4 > -4.000000 -3.946236 -3.806717 -3.497438 -3.000000 -2.500000 -2.000000 > -1.500000 -1.000000 > -5.000000 -3.347128 0.000000 3.754690 5.000000 > W ,W ,W ,shl, V bc's ! NB: 3 characters each ! > t ,t , , , T bc's ! You must have 2 spaces!! > > > > -- 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 May 3 17:05:24 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 May 2010 00:05:24 +0200 Subject: [Nek5000-users] Warning Message : L1/L2 DIV(V) In-Reply-To: References: Message-ID: <86116E6C-2B31-4348-AC44-4981BAB91B55@lav.mavt.ethz.ch> You may want to use lx1=10 and compile Nek with K10_MXM in case your running on machine with AMD 10h processors. In addition you can lower the pressure tolerance to 5e-5 to save computational time. Is there a specific reason not to use the PN/PN-2 formulation? Your pressure iterations are quite high but I guess this is because of your mesh. At the moment the PN/PN does not support our multi-grid preconditioner and you're more sensitive to high aspect ratios (effected by the element size + N). Also please I recommned to use dt = -3e-3 and param(27)=2. Typically a Courant number of two gives you the best performance for the characteristics scheme. I may help to visualize the difference in divergence. Where are the high values (at element boundaries, domain boundaries, etc.)? In your case QTL contains the user specified divergence at the outflow. Stefan On May 3, 2010, at 10:52 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > I am running an LES with the following parameters: > > 1. p101=3 and p103 =0.05(filter weight). > 2. De aliasing enabled and set to 16. (lxd = 16 ) > 4. lx1 = 11 > 3. Yes, IFCHAR is on and a CFL close to 2 is used. > 4. I add some divergence to the flow outlet using the same procedure detailed in the examples. > > This is my first flow through the domain and I intend to run it for a couple more depending on the results. > > Thank you for the info on order of interpolation polynomial. I would have to refine my domain in order to match the resolution by reducing the lx1. I will look into it. > > Please find attached pieces of rea and log file stacked together in the attachment. Thanks. > > 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 Mon May 3 16:47:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 03 May 2010 23:47:50 +0200 Subject: [Nek5000-users] Boundary condition "I" Message-ID: <1272923270.18612.166.camel@localhost.localdomain> Hello all, Could anyone tell me what the boundary condition "I" means? 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 Tue May 4 05:01:46 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 May 2010 12:01:46 +0200 Subject: [Nek5000-users] Boundary condition "I" In-Reply-To: <1272923270.18612.166.camel@localhost.localdomain> References: <1272923270.18612.166.camel@localhost.localdomain> Message-ID: <89E0D814-67D2-457F-A9D7-67F8109DAB6E@lav.mavt.ethz.ch> check here: https://nek5000.mcs.anl.gov/index.php/Boundary_Definition Stefan On May 3, 2010, at 11:47 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > Could anyone tell me what the boundary condition "I" means? > > 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 May 3 17:10:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 04 May 2010 00:10:12 +0200 Subject: [Nek5000-users] Boundary condition "I" In-Reply-To: <89E0D814-67D2-457F-A9D7-67F8109DAB6E@lav.mavt.ethz.ch> References: <1272923270.18612.166.camel@localhost.localdomain> <89E0D814-67D2-457F-A9D7-67F8109DAB6E@lav.mavt.ethz.ch> Message-ID: <1272924612.18612.169.camel@localhost.localdomain> Hello Stefan, It is not listed there. It does appears in the code in more than a few places, so it appears to not fall under the statement "Anything else will be taken as zero flux". Cheers, Frank On Tue, 2010-05-04 at 12:01 +0200, nek5000-users at lists.mcs.anl.gov wrote: > check here: https://nek5000.mcs.anl.gov/index.php/Boundary_Definition > > Stefan > > > > On May 3, 2010, at 11:47 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > > > Could anyone tell me what the boundary condition "I" means? > > > > 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 Tue May 4 05:17:05 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 May 2010 12:17:05 +0200 Subject: [Nek5000-users] Boundary condition "I" In-Reply-To: <1272924612.18612.169.camel@localhost.localdomain> References: <1272923270.18612.166.camel@localhost.localdomain> <89E0D814-67D2-457F-A9D7-67F8109DAB6E@lav.mavt.ethz.ch> <1272924612.18612.169.camel@localhost.localdomain> Message-ID: <364003B9-0E43-463C-9F8B-351E03E41938@lav.mavt.ethz.ch> Well, it does not show up the in routines which apply the boundary conditions. Where does is it appear in the code? Stefan On May 4, 2010, at 12:10 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Stefan, > > It is not listed there. It does appears in the code in more than a few > places, so it appears to not fall under the statement "Anything else > will be taken as zero flux". > > Cheers, > Frank > > > On Tue, 2010-05-04 at 12:01 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> check here: https://nek5000.mcs.anl.gov/index.php/Boundary_Definition >> >> Stefan >> >> >> >> On May 3, 2010, at 11:47 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello all, >>> >>> Could anyone tell me what the boundary condition "I" means? >>> >>> 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 From nek5000-users at lists.mcs.anl.gov Mon May 3 17:21:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 04 May 2010 00:21:27 +0200 Subject: [Nek5000-users] Boundary condition "I" In-Reply-To: <364003B9-0E43-463C-9F8B-351E03E41938@lav.mavt.ethz.ch> References: <1272923270.18612.166.camel@localhost.localdomain> <89E0D814-67D2-457F-A9D7-67F8109DAB6E@lav.mavt.ethz.ch> <1272924612.18612.169.camel@localhost.localdomain> <364003B9-0E43-463C-9F8B-351E03E41938@lav.mavt.ethz.ch> Message-ID: <1272925287.18612.172.camel@localhost.localdomain> [root at frank nek]# grep -F "'I'" * bdry.f: IF ( HCODE(10,IH) .EQ. 'I' ) THEN navier5.f: IF (HCODE(10,II).NE.'I') GOTO 100 navier5.f: if (hcode(10,ii).EQ.'I') then navier5.f: if (hcode(10,ii).EQ.'I') then prepost.f: IF(HCODE(10,IH).EQ.'I') then prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 prepost.f: IF ( HCODE(10,II).NE.'I') GOTO 100 prepost.f: IF ( HCODE(10,II).NE.'I') GOTO 200 prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 [root at frank nek]# grep -F "'i'" * connect2.f:c IF(CBC3(3:3).NE.'i')NLINES=BC(1,ISIDE,IEL,IFIELD) connect2.f:c IF(CBC3(3:3).EQ.'i')NLINES=BC(4,ISIDE,IEL,IFIELD) On Tue, 2010-05-04 at 12:17 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Well, it does not show up the in routines which apply the boundary conditions. > Where does is it appear in the code? > > Stefan > > > On May 4, 2010, at 12:10 AM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello Stefan, > > > > It is not listed there. It does appears in the code in more than a few > > places, so it appears to not fall under the statement "Anything else > > will be taken as zero flux". > > > > Cheers, > > Frank > > > > > > On Tue, 2010-05-04 at 12:01 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> check here: https://nek5000.mcs.anl.gov/index.php/Boundary_Definition > >> > >> Stefan > >> > >> > >> > >> On May 3, 2010, at 11:47 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hello all, > >>> > >>> Could anyone tell me what the boundary condition "I" means? > >>> > >>> 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 Tue May 4 05:25:43 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 May 2010 12:25:43 +0200 Subject: [Nek5000-users] Boundary condition "I" In-Reply-To: <1272925287.18612.172.camel@localhost.localdomain> References: <1272923270.18612.166.camel@localhost.localdomain> <89E0D814-67D2-457F-A9D7-67F8109DAB6E@lav.mavt.ethz.ch> <1272924612.18612.169.camel@localhost.localdomain> <364003B9-0E43-463C-9F8B-351E03E41938@lav.mavt.ethz.ch> <1272925287.18612.172.camel@localhost.localdomain> Message-ID: <4F0E2C89-75C7-4DE7-A3D4-E83F57D23234@lav.mavt.ethz.ch> These things are not related to BCs. The 'I' in HCODE means integral. In connect2 we check if one ob the boundary condition tags _ends_ with an 'i' (don't mess it up with 'I '). hth, Stefan On May 4, 2010, at 12:21 AM, nek5000-users at lists.mcs.anl.gov wrote: > > > [root at frank nek]# grep -F "'I'" * > bdry.f: IF ( HCODE(10,IH) .EQ. 'I' ) THEN > navier5.f: IF (HCODE(10,II).NE.'I') GOTO 100 > navier5.f: if (hcode(10,ii).EQ.'I') then > navier5.f: if (hcode(10,ii).EQ.'I') then > prepost.f: IF(HCODE(10,IH).EQ.'I') then > prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 > prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 > prepost.f: IF ( HCODE(10,II).NE.'I') GOTO 100 > prepost.f: IF ( HCODE(10,II).NE.'I') GOTO 200 > prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 > [root at frank nek]# grep -F "'i'" * > connect2.f:c > IF(CBC3(3:3).NE.'i')NLINES=BC(1,ISIDE,IEL,IFIELD) > connect2.f:c > IF(CBC3(3:3).EQ.'i')NLINES=BC(4,ISIDE,IEL,IFIELD) > > > > On Tue, 2010-05-04 at 12:17 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Well, it does not show up the in routines which apply the boundary conditions. >> Where does is it appear in the code? >> >> Stefan >> >> >> On May 4, 2010, at 12:10 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello Stefan, >>> >>> It is not listed there. It does appears in the code in more than a few >>> places, so it appears to not fall under the statement "Anything else >>> will be taken as zero flux". >>> >>> Cheers, >>> Frank >>> >>> >>> On Tue, 2010-05-04 at 12:01 +0200, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> check here: https://nek5000.mcs.anl.gov/index.php/Boundary_Definition >>>> >>>> Stefan >>>> >>>> >>>> >>>> On May 3, 2010, at 11:47 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hello all, >>>>> >>>>> Could anyone tell me what the boundary condition "I" means? >>>>> >>>>> 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 From nek5000-users at lists.mcs.anl.gov Tue May 4 05:29:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 May 2010 12:29:58 +0200 Subject: [Nek5000-users] Boundary condition "I" In-Reply-To: <4F0E2C89-75C7-4DE7-A3D4-E83F57D23234@lav.mavt.ethz.ch> References: <1272923270.18612.166.camel@localhost.localdomain> <89E0D814-67D2-457F-A9D7-67F8109DAB6E@lav.mavt.ethz.ch> <1272924612.18612.169.camel@localhost.localdomain> <364003B9-0E43-463C-9F8B-351E03E41938@lav.mavt.ethz.ch> <1272925287.18612.172.camel@localhost.localdomain> <4F0E2C89-75C7-4DE7-A3D4-E83F57D23234@lav.mavt.ethz.ch> Message-ID: We typically use the I BC as a dummy tag for insulated (zero flux). Stefan On May 4, 2010, at 12:25 PM, nek5000-users at lists.mcs.anl.gov wrote: > These things are not related to BCs. The 'I' in HCODE means integral. In connect2 we check if one ob the boundary condition tags _ends_ with an 'i' (don't mess it up with 'I '). > > hth, > Stefan > > > On May 4, 2010, at 12:21 AM, nek5000-users at lists.mcs.anl.gov wrote: > >> >> >> [root at frank nek]# grep -F "'I'" * >> bdry.f: IF ( HCODE(10,IH) .EQ. 'I' ) THEN >> navier5.f: IF (HCODE(10,II).NE.'I') GOTO 100 >> navier5.f: if (hcode(10,ii).EQ.'I') then >> navier5.f: if (hcode(10,ii).EQ.'I') then >> prepost.f: IF(HCODE(10,IH).EQ.'I') then >> prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 >> prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 >> prepost.f: IF ( HCODE(10,II).NE.'I') GOTO 100 >> prepost.f: IF ( HCODE(10,II).NE.'I') GOTO 200 >> prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 >> [root at frank nek]# grep -F "'i'" * >> connect2.f:c >> IF(CBC3(3:3).NE.'i')NLINES=BC(1,ISIDE,IEL,IFIELD) >> connect2.f:c >> IF(CBC3(3:3).EQ.'i')NLINES=BC(4,ISIDE,IEL,IFIELD) >> >> >> >> On Tue, 2010-05-04 at 12:17 +0200, nek5000-users at lists.mcs.anl.gov >> wrote: >>> Well, it does not show up the in routines which apply the boundary conditions. >>> Where does is it appear in the code? >>> >>> Stefan >>> >>> >>> On May 4, 2010, at 12:10 AM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hello Stefan, >>>> >>>> It is not listed there. It does appears in the code in more than a few >>>> places, so it appears to not fall under the statement "Anything else >>>> will be taken as zero flux". >>>> >>>> Cheers, >>>> Frank >>>> >>>> >>>> On Tue, 2010-05-04 at 12:01 +0200, nek5000-users at lists.mcs.anl.gov >>>> wrote: >>>>> check here: https://nek5000.mcs.anl.gov/index.php/Boundary_Definition >>>>> >>>>> Stefan >>>>> >>>>> >>>>> >>>>> On May 3, 2010, at 11:47 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> Could anyone tell me what the boundary condition "I" means? >>>>>> >>>>>> 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 > > _______________________________________________ > 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 May 3 17:31:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 04 May 2010 00:31:21 +0200 Subject: [Nek5000-users] Boundary condition "I" In-Reply-To: <4F0E2C89-75C7-4DE7-A3D4-E83F57D23234@lav.mavt.ethz.ch> References: <1272923270.18612.166.camel@localhost.localdomain> <89E0D814-67D2-457F-A9D7-67F8109DAB6E@lav.mavt.ethz.ch> <1272924612.18612.169.camel@localhost.localdomain> <364003B9-0E43-463C-9F8B-351E03E41938@lav.mavt.ethz.ch> <1272925287.18612.172.camel@localhost.localdomain> <4F0E2C89-75C7-4DE7-A3D4-E83F57D23234@lav.mavt.ethz.ch> Message-ID: <1272925881.18612.176.camel@localhost.localdomain> Hi Stefan, OK, so it falls under the statement "Anything else will be taken as zero flux" and therefore could just as well be set to a blank? Cheers, Frank On Tue, 2010-05-04 at 12:25 +0200, nek5000-users at lists.mcs.anl.gov wrote: > These things are not related to BCs. The 'I' in HCODE means integral. In connect2 we check if one ob the boundary condition tags _ends_ with an 'i' (don't mess it up with 'I '). > > hth, > Stefan > > > On May 4, 2010, at 12:21 AM, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > [root at frank nek]# grep -F "'I'" * > > bdry.f: IF ( HCODE(10,IH) .EQ. 'I' ) THEN > > navier5.f: IF (HCODE(10,II).NE.'I') GOTO 100 > > navier5.f: if (hcode(10,ii).EQ.'I') then > > navier5.f: if (hcode(10,ii).EQ.'I') then > > prepost.f: IF(HCODE(10,IH).EQ.'I') then > > prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 > > prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 > > prepost.f: IF ( HCODE(10,II).NE.'I') GOTO 100 > > prepost.f: IF ( HCODE(10,II).NE.'I') GOTO 200 > > prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 > > [root at frank nek]# grep -F "'i'" * > > connect2.f:c > > IF(CBC3(3:3).NE.'i')NLINES=BC(1,ISIDE,IEL,IFIELD) > > connect2.f:c > > IF(CBC3(3:3).EQ.'i')NLINES=BC(4,ISIDE,IEL,IFIELD) > > > > > > > > On Tue, 2010-05-04 at 12:17 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Well, it does not show up the in routines which apply the boundary conditions. > >> Where does is it appear in the code? > >> > >> Stefan > >> > >> > >> On May 4, 2010, at 12:10 AM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hello Stefan, > >>> > >>> It is not listed there. It does appears in the code in more than a few > >>> places, so it appears to not fall under the statement "Anything else > >>> will be taken as zero flux". > >>> > >>> Cheers, > >>> Frank > >>> > >>> > >>> On Tue, 2010-05-04 at 12:01 +0200, nek5000-users at lists.mcs.anl.gov > >>> wrote: > >>>> check here: https://nek5000.mcs.anl.gov/index.php/Boundary_Definition > >>>> > >>>> Stefan > >>>> > >>>> > >>>> > >>>> On May 3, 2010, at 11:47 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Hello all, > >>>>> > >>>>> Could anyone tell me what the boundary condition "I" means? > >>>>> > >>>>> 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 > > _______________________________________________ > 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 Tue May 4 05:33:45 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 May 2010 12:33:45 +0200 Subject: [Nek5000-users] Boundary condition "I" In-Reply-To: <1272925881.18612.176.camel@localhost.localdomain> References: <1272923270.18612.166.camel@localhost.localdomain> <89E0D814-67D2-457F-A9D7-67F8109DAB6E@lav.mavt.ethz.ch> <1272924612.18612.169.camel@localhost.localdomain> <364003B9-0E43-463C-9F8B-351E03E41938@lav.mavt.ethz.ch> <1272925287.18612.172.camel@localhost.localdomain> <4F0E2C89-75C7-4DE7-A3D4-E83F57D23234@lav.mavt.ethz.ch> <1272925881.18612.176.camel@localhost.localdomain> Message-ID: <7C9546D5-3A67-4C64-9DB8-D99C2C2A2397@lav.mavt.ethz.ch> No I don't think a blank string would work. Also it's highly likely that the BC list on the Wiki is not complete! Stefan On May 4, 2010, at 12:31 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > OK, so it falls under the statement "Anything else will be taken as zero > flux" and therefore could just as well be set to a blank? > > Cheers, > Frank > > On Tue, 2010-05-04 at 12:25 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> These things are not related to BCs. The 'I' in HCODE means integral. In connect2 we check if one ob the boundary condition tags _ends_ with an 'i' (don't mess it up with 'I '). >> >> hth, >> Stefan >> >> >> On May 4, 2010, at 12:21 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> >>> >>> [root at frank nek]# grep -F "'I'" * >>> bdry.f: IF ( HCODE(10,IH) .EQ. 'I' ) THEN >>> navier5.f: IF (HCODE(10,II).NE.'I') GOTO 100 >>> navier5.f: if (hcode(10,ii).EQ.'I') then >>> navier5.f: if (hcode(10,ii).EQ.'I') then >>> prepost.f: IF(HCODE(10,IH).EQ.'I') then >>> prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 >>> prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 >>> prepost.f: IF ( HCODE(10,II).NE.'I') GOTO 100 >>> prepost.f: IF ( HCODE(10,II).NE.'I') GOTO 200 >>> prepost.f: IF (HCODE(10,II).NE.'I') GOTO 100 >>> [root at frank nek]# grep -F "'i'" * >>> connect2.f:c >>> IF(CBC3(3:3).NE.'i')NLINES=BC(1,ISIDE,IEL,IFIELD) >>> connect2.f:c >>> IF(CBC3(3:3).EQ.'i')NLINES=BC(4,ISIDE,IEL,IFIELD) >>> >>> >>> >>> On Tue, 2010-05-04 at 12:17 +0200, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Well, it does not show up the in routines which apply the boundary conditions. >>>> Where does is it appear in the code? >>>> >>>> Stefan >>>> >>>> >>>> On May 4, 2010, at 12:10 AM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hello Stefan, >>>>> >>>>> It is not listed there. It does appears in the code in more than a few >>>>> places, so it appears to not fall under the statement "Anything else >>>>> will be taken as zero flux". >>>>> >>>>> Cheers, >>>>> Frank >>>>> >>>>> >>>>> On Tue, 2010-05-04 at 12:01 +0200, nek5000-users at lists.mcs.anl.gov >>>>> wrote: >>>>>> check here: https://nek5000.mcs.anl.gov/index.php/Boundary_Definition >>>>>> >>>>>> Stefan >>>>>> >>>>>> >>>>>> >>>>>> On May 3, 2010, at 11:47 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> Could anyone tell me what the boundary condition "I" means? >>>>>>> >>>>>>> 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 >> >> _______________________________________________ >> 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 May 3 17:53:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 04 May 2010 00:53:27 +0200 Subject: [Nek5000-users] variable properties, uservp Message-ID: <1272927207.18612.185.camel@localhost.localdomain> Hello all, I am trying to understand how to set variable fluid properties depending on spatial location. I have two cases, for one "uservp" is never called, for the other it is. The difference in their *.rea files is as follows. I cannot see why in one case "uservp" is called as neither IFUSERVP=.true. or param(3)>0. Cheers, Frank [fmuldoo at tetra sim3]# diff *rea ../sim7/AR-.66-RE-1800-PR-04.0-dt-3.1e-5-time-006.0-grid-1-Intel/delet.rea | more 3c3 < 2 DIMENSIONAL RUN --- > 3 DIMENSIONAL RUN 6c6 < -1.00000 VISCOS --- > 1.00000 VISCOS 12c12 < 1.00000 CONDUCT --- > 0.25 CONDUCT 15,16c15,16 < 1000.0 NSTEPS < -5.e-6 DT --- > 193548 NSTEPS > -3.1e-05 DT 19c19 < 20.00000 IOSTEP --- > 1290 IOSTEP 25,26c25,26 < 1.000000E-07 DIVERGENCE < 1.000000E-07 HELMHOLTZ --- > 1.000000E-05 DIVERGENCE > 1.000000E-05 HELMHOLTZ 28,29c28,29 < 1.000000E-07 TOLREL < 1.000000E-07 TOLABS --- > 1.000000E-05 TOLREL > 1.000000E-05 TOLABS 39a40,45 > 0.000000E+00 XMAGNET > 0.000000E+00 NGRIDS > 0.000000E+00 NORDER2 > 0.000000E+00 NORDER3 > 0.000000E+00 NORDER4 > 0.000000E+00 NORDER5 46,51d51 < 1.000000E+00 p42=1 for std 2-level schwarz < 1.000000E+00 p43=1 etc. < 1.000000E+00 p44=1 < 0.000000E+00 < 0.000000E+00 < 0.3 Poisson ratio for mesh 107c107 < 0.05000 p103: filter strength, < 0 ==> no fil --- > 0.00000 p103: filter strength, < 0 ==> no fil 119c119 < T IFAXIS --- > F IFAXIS 125,126c125,126 < T IFMVBD < F IFCHAR --- > F IFMVBD > T IFCHAR -- 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 Tue May 4 06:01:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 May 2010 13:01:53 +0200 Subject: [Nek5000-users] variable properties, uservp In-Reply-To: <1272927207.18612.185.camel@localhost.localdomain> References: <1272927207.18612.185.camel@localhost.localdomain> Message-ID: <945C4203-6E18-40E8-AE59-BC601CD27BF2@lav.mavt.ethz.ch> uservp() is called if: IFUSERVP = true or param(30) > 0 or if you have a non-trivial 'Variable Property Data' section in your .rea file with MATYPE=2 Stefan On May 4, 2010, at 12:53 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I am trying to understand how to set variable fluid properties depending > on spatial location. I have two cases, for one "uservp" is never > called, for the other it is. The difference in their *.rea files is as > follows. I cannot see why in one case "uservp" is called as neither > IFUSERVP=.true. or param(3)>0. > > Cheers, > Frank > > [fmuldoo at tetra sim3]# diff > *rea ../sim7/AR-.66-RE-1800-PR-04.0-dt-3.1e-5-time-006.0-grid-1-Intel/delet.rea | more > 3c3 > < 2 DIMENSIONAL RUN > --- >> 3 DIMENSIONAL RUN > 6c6 > < -1.00000 VISCOS > --- >> 1.00000 VISCOS > 12c12 > < 1.00000 CONDUCT > --- >> 0.25 CONDUCT > 15,16c15,16 > < 1000.0 NSTEPS > < -5.e-6 DT > --- >> 193548 NSTEPS >> -3.1e-05 DT > 19c19 > < 20.00000 IOSTEP > --- >> 1290 IOSTEP > 25,26c25,26 > < 1.000000E-07 DIVERGENCE > < 1.000000E-07 HELMHOLTZ > --- >> 1.000000E-05 DIVERGENCE >> 1.000000E-05 HELMHOLTZ > 28,29c28,29 > < 1.000000E-07 TOLREL > < 1.000000E-07 TOLABS > --- >> 1.000000E-05 TOLREL >> 1.000000E-05 TOLABS > 39a40,45 >> 0.000000E+00 XMAGNET >> 0.000000E+00 NGRIDS >> 0.000000E+00 NORDER2 >> 0.000000E+00 NORDER3 >> 0.000000E+00 NORDER4 >> 0.000000E+00 NORDER5 > 46,51d51 > < 1.000000E+00 p42=1 for std 2-level schwarz > < 1.000000E+00 p43=1 etc. > < 1.000000E+00 p44=1 > < 0.000000E+00 > < 0.000000E+00 > < 0.3 Poisson ratio for mesh > 107c107 > < 0.05000 p103: filter strength, < 0 ==> no fil > --- >> 0.00000 p103: filter strength, < 0 ==> no fil > 119c119 > < T IFAXIS > --- >> F IFAXIS > 125,126c125,126 > < T IFMVBD > < F IFCHAR > --- >> F IFMVBD >> T IFCHAR > > > > > -- > 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 Tue May 4 07:22:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 May 2010 07:22:53 -0500 Subject: [Nek5000-users] Generating curved sides with genbox? Message-ID: Hello, Is it possible to generate curved sides with genbox? Or do I have to use prex for generating it? Is there a small example of generating a simple cylinder mesh? Thanks, Harish. From nek5000-users at lists.mcs.anl.gov Tue May 4 17:39:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 May 2010 18:39:16 -0400 Subject: [Nek5000-users] New code+recycling BC In-Reply-To: References: <4BDEDCC8.4050207@vt.edu> <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> Message-ID: <1273012756.4be0a2146ad1e@webmail.vt.edu> Hiu, sorry about the delay, to make sure I regenerated the problem. I did as you suggested, it is still messed up when opening the first fld dump in VisIt with the meta file containing only one file. What I meant by element ordering is the way the recycling b.c. is set up, where the "outflow" face of recycling box is established by counting a number of elements downstream from the inflow, as it is done in the jet example. I have a suspicion that something changed there (not in my .rea file, though). The problem came about when updating Nek from 404 to 503, I did not change Visit. Thanks, Markus Quoting nek5000-users at lists.mcs.anl.gov: > Can you dump a field file including the geometry and then visualize it using > VisIt (your metadata file should only contain one single fld). Is it still > messed up? > > Stefan > > > On May 3, 2010, at 5:24 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Markus, > > > > is it only a viz issue or do you have some problems in Nek after upgrading > to the latest release. > > > > Stefan > > > > > > On May 3, 2010, at 4:25 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Hi, > >> > >> when updating the code from rev. 404 (oldvel.png) to 503 > >> (newvel.png), I realized a problem with the recycling > >> (periodic) boundary condition for a channel simulation I am doing - > >> compare the attached pictures of velocity on the inflow plane (the inflow > is the Y/Z plane). For the two cases, SIZE/SIZEu, .rea, the restart step and > .usr are the exact same. > >> > >> Here are the relevant pieces from .usr. Have any of the functions > >> changed or am I doing something wrong? It seems as if the element > >> ordering is not what it was before. > >> I did this based on the jet example. > >> > >> Thanks, > >> Markus > >> > >> > >> c----------------------------------------------------------------------- > >> subroutine userbc (ix,iy,iz,iside,eg) > >> include 'SIZE' > >> include 'TOTAL' > >> include 'NEKUSE' > >> > >> common /cvelbc/ uin(lx1,ly1,lz1,lelv) > >> $ , vin(lx1,ly1,lz1,lelv) > >> $ , win(lx1,ly1,lz1,lelv) > >> $ , tin(lx1,ly1,lz1,lelv) > >> > >> integer e,eg > >> > >> e = gllel(eg) > >> > >> ux=uin(ix,iy,iz,e) > >> uy=vin(ix,iy,iz,e) > >> uz=win(ix,iy,iz,e) > >> . > >> .... > >> > >> c----------------------------------------------------------------------- > >> subroutine userchk > >> include 'SIZE' > >> include 'TOTAL' > >> include 'ZPER' ! for nelx,nely,nelz > >> include 'RESTART' !Needs to be here for prepost to work > >> common /cvlmsk/ vlmsk(lx1,ly1,lz1,lelt),vvol, > >> & wt(lx1*ly1*lz1,lelt),vol_per > >> > >> integer e,f,eg,ninx,niny,ninz > >> > >> .c-----Computations for recycling BC > >> speed = glsc2(vx,wt,n)/vol_per ! Where vol_per is the volume of > >> the recycling box > >> starg = 1.0 > >> addtemp = 1.0 > >> call set_inflow(starg,speed,addtemp) ! set up inflow BCs > >> . > >> .... > >> > >> c----------------------------------------------------------------------- > >> subroutine set_inflow(starg,speed,addtemp) ! set up inflow BCs > >> > >> include 'SIZE' > >> include 'TOTAL' > >> > >> integer icalld,e,eg,f > >> save icalld > >> data icalld /0/ > >> > >> common /cvelbc/ uin(lx1,ly1,lz1,lelv) > >> $ , vin(lx1,ly1,lz1,lelv) > >> $ , win(lx1,ly1,lz1,lelv) > >> $ , tin(lx1,ly1,lz1,lelv) > >> > >> common /scruz/ ptr(lx1,ly1,lz1,lelv) > >> integer ptr,gs_bc_hndl > >> save gs_bc_hndl > >> > >> real ratio > >> save ratio > >> data ratio / 1. / > >> > >> common /nekmpi/ mid,mp,nekcomm,nekgroup,nekreal > >> > >> n = nx1*ny1*nz1*nelv > >> > >> if (icalld.eq.0) then > >> icalld = 1 > >> nxyz = nx1*ny1*nz1 > >> > >> do e=1,nelv > >> eg = lglel(e) > >> eo = nxyz*(eg-1) ! offset > >> do i=1,nxyz > >> ptr(i,1,1,e) = i+eo > >> enddo > >> > >> do k=2,nz1-1 ! get rid of interior pointers > >> do j=2,ny1-1 do i=2,nx1-1 > >> ptr(i,j,k,e) = 0 > >> enddo > >> enddo > >> enddo > >> > >> nface = 2*ndim > >> do f=1,nface ! connect inflow to elems downstream > >> ioff = nxyz*8 ! 5 elements in X to end of "periodic" sec. > >> if (cbc(f,e,1).eq.'v ') then > >> call iface_add(ptr,f,e,ioff,nx1,ny1,nz1) > >> endif > >> enddo > >> > >> enddo > >> > >> call gs_setup(gs_bc_hndl,ptr,n,nekcomm,np) ! connect v + > >> downstream > >> > >> endif > >> > >> call copy(uin,vx,n) > >> call copy(vin,vy,n) > >> call copy(win,vz,n) > >> call copy(tin,t,n) > >> > >> call col2(uin,v1mask,n) > >> call col2(vin,v2mask,n) > >> call col2(win,v3mask,n) > >> call col2(tin,tmask,n) > >> > >> call gs_op(gs_bc_hndl,uin,1,1,0) ! 1 ==> + ! uin(inflow) = > >> vx(slab_k) > >> call gs_op(gs_bc_hndl,vin,1,1,0) ! 1 ==> + > >> call gs_op(gs_bc_hndl,win,1,1,0) ! 1 ==> + > >> call gs_op(gs_bc_hndl,tin,1,1,0) ! 1 ==> + > >> > >> if (speed.gt.0) then > >> ratio = .5*(starg/speed + ratio) > >> call cmult(uin,ratio,n) > >> call cmult(vin,ratio,n) > >> call cmult(win,ratio,n) > >> call cadd(tin,addtemp,n) !Substract added heat > >> endif > >> > >> return > >> end > >> > >> > >> > >> _______________________________________________ > >> 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 May 5 01:52:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 5 May 2010 08:52:03 +0200 Subject: [Nek5000-users] New code+recycling BC In-Reply-To: <1273012756.4be0a2146ad1e@webmail.vt.edu> References: <4BDEDCC8.4050207@vt.edu> <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> <1273012756.4be0a2146ad1e@webmail.vt.edu> Message-ID: <996888BA-3BDB-4FFA-BEDA-6E86261F80DA@lav.mavt.ethz.ch> Hi Markus, yes we changed glo_num to be an 8-byte integer array. Unfortunately we did not update the examples. I'll update the turbJet example. Stefan On May 5, 2010, at 12:39 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hiu, > > sorry about the delay, to make sure I regenerated the problem. > > I did as you suggested, it is still messed up when opening the first fld dump in > VisIt with the meta file containing only one file. > > What I meant by element ordering is the way the recycling b.c. is set up, where > the "outflow" face of recycling box is established by counting a number of > elements downstream from the inflow, as it is done in the jet example. I have a > suspicion that something changed there (not in my .rea file, though). > The problem came about when updating Nek from 404 to 503, I did not change > Visit. > > Thanks, > Markus > > > > Quoting nek5000-users at lists.mcs.anl.gov: > >> Can you dump a field file including the geometry and then visualize it using >> VisIt (your metadata file should only contain one single fld). Is it still >> messed up? >> >> Stefan >> >> >> On May 3, 2010, at 5:24 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Markus, >>> >>> is it only a viz issue or do you have some problems in Nek after upgrading >> to the latest release. >>> >>> Stefan >>> >>> >>> On May 3, 2010, at 4:25 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi, >>>> >>>> when updating the code from rev. 404 (oldvel.png) to 503 >>>> (newvel.png), I realized a problem with the recycling >>>> (periodic) boundary condition for a channel simulation I am doing - >>>> compare the attached pictures of velocity on the inflow plane (the inflow >> is the Y/Z plane). For the two cases, SIZE/SIZEu, .rea, the restart step and >> .usr are the exact same. >>>> >>>> Here are the relevant pieces from .usr. Have any of the functions >>>> changed or am I doing something wrong? It seems as if the element >>>> ordering is not what it was before. >>>> I did this based on the jet example. >>>> >>>> Thanks, >>>> Markus >>>> >>>> >>>> c----------------------------------------------------------------------- >>>> subroutine userbc (ix,iy,iz,iside,eg) >>>> include 'SIZE' >>>> include 'TOTAL' >>>> include 'NEKUSE' >>>> >>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>> $ , vin(lx1,ly1,lz1,lelv) >>>> $ , win(lx1,ly1,lz1,lelv) >>>> $ , tin(lx1,ly1,lz1,lelv) >>>> >>>> integer e,eg >>>> >>>> e = gllel(eg) >>>> >>>> ux=uin(ix,iy,iz,e) >>>> uy=vin(ix,iy,iz,e) >>>> uz=win(ix,iy,iz,e) >>>> . >>>> .... >>>> >>>> c----------------------------------------------------------------------- >>>> subroutine userchk >>>> include 'SIZE' >>>> include 'TOTAL' >>>> include 'ZPER' ! for nelx,nely,nelz >>>> include 'RESTART' !Needs to be here for prepost to work >>>> common /cvlmsk/ vlmsk(lx1,ly1,lz1,lelt),vvol, >>>> & wt(lx1*ly1*lz1,lelt),vol_per >>>> >>>> integer e,f,eg,ninx,niny,ninz >>>> >>>> .c-----Computations for recycling BC >>>> speed = glsc2(vx,wt,n)/vol_per ! Where vol_per is the volume of >>>> the recycling box >>>> starg = 1.0 >>>> addtemp = 1.0 >>>> call set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>> . >>>> .... >>>> >>>> c----------------------------------------------------------------------- >>>> subroutine set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>> >>>> include 'SIZE' >>>> include 'TOTAL' >>>> >>>> integer icalld,e,eg,f >>>> save icalld >>>> data icalld /0/ >>>> >>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>> $ , vin(lx1,ly1,lz1,lelv) >>>> $ , win(lx1,ly1,lz1,lelv) >>>> $ , tin(lx1,ly1,lz1,lelv) >>>> >>>> common /scruz/ ptr(lx1,ly1,lz1,lelv) >>>> integer ptr,gs_bc_hndl >>>> save gs_bc_hndl >>>> >>>> real ratio >>>> save ratio >>>> data ratio / 1. / >>>> >>>> common /nekmpi/ mid,mp,nekcomm,nekgroup,nekreal >>>> >>>> n = nx1*ny1*nz1*nelv >>>> >>>> if (icalld.eq.0) then >>>> icalld = 1 >>>> nxyz = nx1*ny1*nz1 >>>> >>>> do e=1,nelv >>>> eg = lglel(e) >>>> eo = nxyz*(eg-1) ! offset >>>> do i=1,nxyz >>>> ptr(i,1,1,e) = i+eo >>>> enddo >>>> >>>> do k=2,nz1-1 ! get rid of interior pointers >>>> do j=2,ny1-1 do i=2,nx1-1 >>>> ptr(i,j,k,e) = 0 >>>> enddo >>>> enddo >>>> enddo >>>> >>>> nface = 2*ndim >>>> do f=1,nface ! connect inflow to elems downstream >>>> ioff = nxyz*8 ! 5 elements in X to end of "periodic" sec. >>>> if (cbc(f,e,1).eq.'v ') then >>>> call iface_add(ptr,f,e,ioff,nx1,ny1,nz1) >>>> endif >>>> enddo >>>> >>>> enddo >>>> >>>> call gs_setup(gs_bc_hndl,ptr,n,nekcomm,np) ! connect v + >>>> downstream >>>> >>>> endif >>>> >>>> call copy(uin,vx,n) >>>> call copy(vin,vy,n) >>>> call copy(win,vz,n) >>>> call copy(tin,t,n) >>>> >>>> call col2(uin,v1mask,n) >>>> call col2(vin,v2mask,n) >>>> call col2(win,v3mask,n) >>>> call col2(tin,tmask,n) >>>> >>>> call gs_op(gs_bc_hndl,uin,1,1,0) ! 1 ==> + ! uin(inflow) = >>>> vx(slab_k) >>>> call gs_op(gs_bc_hndl,vin,1,1,0) ! 1 ==> + >>>> call gs_op(gs_bc_hndl,win,1,1,0) ! 1 ==> + >>>> call gs_op(gs_bc_hndl,tin,1,1,0) ! 1 ==> + >>>> >>>> if (speed.gt.0) then >>>> ratio = .5*(starg/speed + ratio) >>>> call cmult(uin,ratio,n) >>>> call cmult(vin,ratio,n) >>>> call cmult(win,ratio,n) >>>> call cadd(tin,addtemp,n) !Substract added heat >>>> endif >>>> >>>> return >>>> end >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 May 5 12:22:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 05 May 2010 19:22:03 +0200 Subject: [Nek5000-users] History points Message-ID: <4BE1A93B.2050005@gmail.com> Hello Nek's, I have a few questions on how to use the history points. I have seen on the wiki the following stuff: > > > History points > > Specify grid points to monitor the specified variables in time. Example: > > ***** HISTORY AND INTEGRAL DATA ***** > 1 POINTS. Var, Hcode, I, J, K, IEL > UV P H 2 2 1 4 > > > NOTE: > > * Make sure LHIS in SIZEu is large enough > I bet Var stands for variable, but what do Hcode, I, J, K, and IEL stand for ? Once you have specified the location of your history point, let's say a point on the centerline of a stenotic flow at whatever streamwise station, how do you get the data concerning this history point? Do you have to change anything else in the output specification section ? I have tried to add the wiki lines up there directly in my blah.rea but once I ran the code I did not get any new files other than the expected blah.fld's. Regards, Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 5 15:17:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 5 May 2010 15:17:21 -0500 (CDT) Subject: [Nek5000-users] History points In-Reply-To: <24704078.910321273090452592.JavaMail.root@zimbra> Message-ID: <28131667.910811273090641866.JavaMail.root@zimbra> Hi Jean-Christophe, This examples forces Nek5000 to output into the file blah.sch a time trace (H) of pressure (P), x & y velocity components (UV) for a point located in the element w/ global number IEL and collocation coordinates I,J K. Use 'grep History logfile' to get coordinates of the points. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, May 5, 2010 12:22:03 PM GMT -06:00 US/Canada Central Subject: [Nek5000-users] History points Hello Nek's, I have a few questions on how to use the history points. I have seen on the wiki the following stuff: History points Specify grid points to monitor the specified variables in time. Example: ***** HISTORY AND INTEGRAL DATA ***** 1 POINTS. Var, Hcode, I, J, K, IEL UV P H 2 2 1 4 NOTE: ? Make sure LHIS in SIZEu is large enough I bet Var stands for variable, but what do Hcode, I, J, K, and IEL stand for ? Once you have specified the location of your history point, let's say a point on the centerline of a stenotic flow at whatever streamwise station, how do you get the data concerning this history point? Do you have to change anything else in the output specification section ? I have tried to add the wiki lines up there directly in my blah.rea but once I ran the code I did not get any new files other than the expected blah.fld's. Regards, Jean-Christophe _______________________________________________ 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 May 5 16:35:07 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 05 May 2010 23:35:07 +0200 Subject: [Nek5000-users] History points In-Reply-To: <28131667.910811273090641866.JavaMail.root@zimbra> References: <28131667.910811273090641866.JavaMail.root@zimbra> Message-ID: <1273095307.26502.43.camel@localhost.localdomain> Hi Aleks, One question; what exactly is 'grep History logfile'? Cheers, Frank On Wed, 2010-05-05 at 15:17 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Jean-Christophe, > > This examples forces Nek5000 to output into the file blah.sch a time trace (H) of pressure (P), x & y velocity components (UV) for a point located in the element w/ global number IEL and collocation coordinates I,J K. > > Use 'grep History logfile' to get coordinates of the points. > > Aleks > > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, May 5, 2010 12:22:03 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] History points > > > Hello Nek's, > > I have a few questions on how to use the history points. > I have seen on the wiki the following stuff: > > > History points > > > Specify grid points to monitor the specified variables in time. Example: ***** HISTORY AND INTEGRAL DATA ***** > 1 POINTS. Var, Hcode, I, J, K, IEL > UV P H 2 2 1 4 > > NOTE: > > ? Make sure LHIS in SIZEu is large enough > I bet Var stands for variable, but what do Hcode, I, J, K, and IEL stand for ? > > Once you have specified the location of your history point, let's say a point on the centerline of a stenotic flow at whatever streamwise station, how do you get the data concerning this history point? Do you have to change anything else in the output specification section ? I have tried to add the wiki lines up there directly in my blah.rea but once I ran the code I did not get any new files other than the expected blah.fld's. > > Regards, > Jean-Christophe > > _______________________________________________ > 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 Wed May 5 16:37:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 5 May 2010 23:37:44 +0200 Subject: [Nek5000-users] History points In-Reply-To: <1273095307.26502.43.camel@localhost.localdomain> References: <28131667.910811273090641866.JavaMail.root@zimbra> <1273095307.26502.43.camel@localhost.localdomain> Message-ID: Thanks Aleks. Concerning grep, it is a linux command that searches for the string History in the logfile. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 5 16:45:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 05 May 2010 23:45:11 +0200 Subject: [Nek5000-users] History points In-Reply-To: References: <28131667.910811273090641866.JavaMail.root@zimbra> <1273095307.26502.43.camel@localhost.localdomain> Message-ID: <1273095913.26502.50.camel@localhost.localdomain> Hi Aleks, My question is what is the logfile? Perhaps you mean the output that NEK writes to the screen? If so, then one would know the location of the point at which data is being dumped only after entering the i,j,k and element # of the point in the *.rea file.... Cheers, Frank On Wed, 2010-05-05 at 23:37 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Thanks Aleks. > Concerning grep, it is a linux command that searches for the string > History in the logfile. > _______________________________________________ > 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 May 6 03:14:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 06 May 2010 10:14:21 +0200 Subject: [Nek5000-users] Reading binary data Message-ID: <4BE27A5D.5070600@kit.edu> Dear Neks, I have written a small Matlab function to read in the binary result files. Mostly I understood the structure including the header and the structure of the data. After reading in the data (in my case I only wrote x,y,z,u,v,w,p) there was still some information in the result file. See % ??? for i=1:252 rest(i)=fread(fid,1,'float'); end in the function. Can you explain me what is this?? I added the Matlab function. Best , Fred -------------- next part -------------- A non-text attachment was scrubbed... Name: nek_readbin.m Type: text/x-objcsrc Size: 1881 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Thu May 6 04:21:32 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 06 May 2010 11:21:32 +0200 Subject: [Nek5000-users] History points In-Reply-To: <1273095913.26502.50.camel@localhost.localdomain> References: <28131667.910811273090641866.JavaMail.root@zimbra> <1273095307.26502.43.camel@localhost.localdomain> <1273095913.26502.50.camel@localhost.localdomain> Message-ID: <4BE28A1C.3000004@gmail.com> I ran the stenosis example adding the following lines to the .rea file: > ***** HISTORY AND INTEGRAL DATA ***** > 1 POINTS. Var, Hcode, I,J,K,IEL > UV P H 1 1 1 50 At the moment I do not really care about where is my probe, I just want to learn how to use it that's all. But eventhough I swith HSTEP to a positive value, nothing is written in the .sch file. Did I make something wrong or forgot to switch something on ? O.o Regards, Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 6 06:34:15 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 May 2010 06:34:15 -0500 (CDT) Subject: [Nek5000-users] History points In-Reply-To: <4BE28A1C.3000004@gmail.com> References: <28131667.910811273090641866.JavaMail.root@zimbra> <1273095307.26502.43.camel@localhost.localdomain> <1273095913.26502.50.camel@localhost.localdomain> <4BE28A1C.3000004@gmail.com> Message-ID: Jean-Christoph, Because the history points line contains characters, it is essential to match the format for that particular line. The UV P H and integers must lie in the specified columns. For 3D, a typical line would be: UVWPT H 1 1 6 228 Paul On Thu, 6 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > I ran the stenosis example adding the following lines to the .rea file: > >> ***** HISTORY AND INTEGRAL DATA ***** >> 1 POINTS. Var, Hcode, I,J,K,IEL >> UV P H 1 1 1 50 > At the moment I do not really care about where is my probe, I just want to > learn how to use it that's all. But eventhough I swith HSTEP to a positive > value, nothing is written in the .sch file. > Did I make something wrong or forgot to switch something on ? O.o > > Regards, > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Thu May 6 07:18:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 May 2010 14:18:03 +0200 Subject: [Nek5000-users] Reading binary data In-Reply-To: <4BE27A5D.5070600@kit.edu> References: <4BE27A5D.5070600@kit.edu> Message-ID: <91598305-520A-42D2-8FC9-102C3E22DF77@lav.mavt.ethz.ch> Hi Fred, header: 132 bytes endian test tag: 4 bytes element mapping: nel* 4 bytes data: nfields*nxyz*nel* wdsizo (where wdsizo is 4 or 8 bytes) metadata (min/max values): nfields*2*nel * 4 bytes Stefan On May 6, 2010, at 10:14 AM, nek5000-users at lists.mcs.anl.gov wrote: > Dear Neks, > > I have written a small Matlab function to read in the binary result files. Mostly I understood the structure including the header and the structure of the data. After reading in the data (in my case I only wrote x,y,z,u,v,w,p) there was still some information in the result file. See > % ??? > for i=1:252 > rest(i)=fread(fid,1,'float'); > end > in the function. Can you explain me what is this?? I added the Matlab function. > > Best , Fred > function [x,y,z,u,v,w,p,nel1,nmax,time,step] = nek_readbin(file) > % Function nek_readbin > % > % Open *0.f0** binary NEK5000 result file > % Call: [x,y,z,u,v,w,p,ne,nmax,time,step]=nek_readbin('file') > % > % Author: Frederik Folke > % Date: 06/05/2010 > > %------------------------------------------------------------------------% > %clear all > > % Read header of ouput-file > [a,n,nx,ny,nz,nel1,nel2,time,step]=... > textread(file,'%5c %d %d %d %d %d %d %f %d' ,1); > %source code from prepost.f > % write(hdr,1) wdsizo,nxo,nyo,nzo,nelo,nelgt,time,istep,fid0,nfileoo > % $ , (rdcode1(i),i=1,10) ! 74+20=94 > %1 format('#std',1x,i1,1x,i2,1x,i2,1x,i2,1x,i10,1x,i10,1x,e20.13, > % $ 1x,i9,1x,i6,1x,i6,1x,10a) > clear a; > > %------------------------------------------------------------------------% > % Open result file and skip header > fid=fopen(file) > for i=1:52 > bin(i)=fread(fid,1,'int'); > end > > nmax=(nx*ny*nz); > > % Initialize x,y,z,u,v,w,p > x2=zeros(nmax*nel1,1); > y2=zeros(nmax*nel1,1); > z2=zeros(nmax*nel1,1); > u2=zeros(nmax*nel1,1); > v2=zeros(nmax*nel1,1); > w2=zeros(nmax*nel1,1); > p2=zeros(nmax*nel1,1); > > % Read data (here: x,y,z,u,v,w,p) > k=0; > l=0; > m=0; > for i=1:nel1 %maybe nel2?? > for j=1:nmax > k=k+1; > x2(k)=fread(fid,1,'float'); > end > for j=1:nmax > l=l+1; > y2(l)=fread(fid,1,'float'); > end > for j=1:nmax > m=m+1; > z2(m)=fread(fid,1,'float'); > end > end > > > k=0; > l=0; > m=0; > n=0; > for i=1:nel1 %maybe nel2?? > for j=1:nmax > k=k+1; > u2(k)=fread(fid,1,'float'); > end > for j=1:nmax > l=l+1; > v2(l)=fread(fid,1,'float'); > end > for j=1:nmax > m=m+1; > w2(m)=fread(fid,1,'float'); > end > end > > k=0; > for i=1:nel1 %maybe nel2?? > for j=1:nmax > k=k+1; > p2(k)=fread(fid,1,'float'); > end > end > > % ??? > for i=1:252 > rest(i)=fread(fid,1,'float'); > end > > fclose('all'); > > end_______________________________________________ > 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 May 6 07:58:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 May 2010 07:58:58 -0500 (CDT) Subject: [Nek5000-users] History points In-Reply-To: <27243243.923891273150601672.JavaMail.root@zimbra> Message-ID: <5070153.923981273150738078.JavaMail.root@zimbra> Hi Frank, If you run Nek5000 with a script like nek5_svn/trunk/tools/scripts/nekb or nek5_svn/trunk/tools/scripts/nekbmpi the output will be redirected in a file blah.log* and linked to logfile. It is convenient to navigate the logfile (and the code) with unix/linux command 'grep', e.g. grep "C=" logfile shows CFL versus time, etc. Use man grep to see all the options for the command grep. Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, May 5, 2010 4:45:11 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] History points Hi Aleks, My question is what is the logfile? Perhaps you mean the output that NEK writes to the screen? If so, then one would know the location of the point at which data is being dumped only after entering the i,j,k and element # of the point in the *.rea file.... Cheers, Frank On Wed, 2010-05-05 at 23:37 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Thanks Aleks. > Concerning grep, it is a linux command that searches for the string > History in the logfile. > _______________________________________________ > 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 Thu May 6 08:24:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 May 2010 08:24:25 -0500 (CDT) Subject: [Nek5000-users] History points In-Reply-To: <21783109.924501273151868899.JavaMail.root@zimbra> Message-ID: <9683387.924911273152265683.JavaMail.root@zimbra> P.S. Yes, Frank, the exact coordinates of the history points are written only when the code rans. But if for history points you choose the collocation points on the boundary of a spectral element -- those that have I,J,K equal to either 1 or lx1 -- than you can find out their coordinates from .rea ASCII file after the line *** MESH DATA *** where coordinates of the element edges are written. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, May 5, 2010 4:45:11 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] History points Hi Aleks, My question is what is the logfile? Perhaps you mean the output that NEK writes to the screen? If so, then one would know the location of the point at which data is being dumped only after entering the i,j,k and element # of the point in the *.rea file.... Cheers, Frank On Wed, 2010-05-05 at 23:37 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Thanks Aleks. > Concerning grep, it is a linux command that searches for the string > History in the logfile. > _______________________________________________ > 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 Thu May 6 08:49:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 May 2010 15:49:41 +0200 Subject: [Nek5000-users] History points In-Reply-To: <9683387.924911273152265683.JavaMail.root@zimbra> References: <9683387.924911273152265683.JavaMail.root@zimbra> Message-ID: Hi Guys, yes the history point module needs a major overhaul. I don't like the way it works! In fact we could do a much better job using our interpolation tool. I just coded something up (without testing the code snipplet) very quicky but I think I should work out of the box. How does it work: - create a 'hpts.in' file line 1: number of points line 2: X,Y,Z coordinates of a point 1 .... line n+1: X,Y,Z coordinates of point n - set lpart >= n in the SIZE file - call hpts() in userchk() The results will be written to 'hpts.out' . Enjoy -Stefan ---------------------------------------------------------------------------------------------------------------------- subroutine hpts c c dump velocity, temperature and ps-scalars for a given list c of points (read from file hpts.in) into a file (hpts.out) c INCLUDE 'SIZE' INCLUDE 'TOTAL' parameter(nmax=lpart,nfldmax=ldim+ldimt) parameter(mi=4,mr=1+2*ldim+nfldmax) real rTL(mr,nmax) integer iTL(mi,nmax) common /itlcb/ iTL common /rtlcb/ rTL common /outtmp / wrk(lx1,ly1,lz1,lelt,nfldmax) character*80 fname integer icalld,npoints,icount save icalld,npoints,icount data icalld /0/ data npoints /0/ data icount /0/ nxyz = nx1*ny1*nz1 ntot = nxyz*nelt if(icalld.eq.0) then icalld = 1 npoints = 0 write(6,*) 'reading hpts.in' open(50,file='hpts.in',status='old') read(50,*) npoints write(6,*) 'found ', npoints, ' points' do i = 1,npoints read(50,*) (rTL(1+j,i),j=1,ndim) enddo close(50) bb_tol = 1e-8 ! bounding-box test tolerance call intpts_setup(bb_tol) open(50,file='hpts.out',status='new') write(50,'(A)') '# time vx vy [vz] T PS1 PS2 ...' endif nflds = nfield + ndim-1 ! number of fields you want to interpolate ! pack working array call copy(wrk(1,1,1,1,1),vx,ntot) call copy(wrk(1,1,1,1,2),vy,ntot) if(if3d) call copy(wrk(1,1,1,1,2),vz,ntot) do i = 1,nfield-1 call copy(wrk(1,1,1,1,ndim+i),T(1,1,1,1,i),ntot) enddo ! interpolate call intpts(wrk,nflds,iTL,mi,rTL,mr,npoints,nmax) ! write interpolation results to file if(nid.eq.0) then do ip = 1,npoints write(50,'(1p20E15.7)') time, & (rTL(1+2*ndim+ifld,ip), ifld=1,nflds) enddo endif return end On May 6, 2010, at 3:24 PM, nek5000-users at lists.mcs.anl.gov wrote: > P.S. > > Yes, Frank, the exact coordinates of the history points are written only when the code rans. > > But if for history points you choose the collocation points on the boundary of a spectral element -- those that have I,J,K equal to either 1 or lx1 -- than you can find out their coordinates from .rea ASCII file after the line > > *** MESH DATA *** > > where coordinates of the element edges are written. > > Aleks > > > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, May 5, 2010 4:45:11 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] History points > > Hi Aleks, > > My question is what is the logfile? Perhaps you mean the output that > NEK writes to the screen? If so, then one would know the location of > the point at which data is being dumped only after entering the i,j,k > and element # of the point in the *.rea file.... > > Cheers, > Frank > > On Wed, 2010-05-05 at 23:37 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Thanks Aleks. >> Concerning grep, it is a linux command that searches for the string >> History in the logfile. >> _______________________________________________ >> 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 Thu May 6 09:01:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 May 2010 16:01:53 +0200 Subject: [Nek5000-users] History points In-Reply-To: References: <9683387.924911273152265683.JavaMail.root@zimbra> Message-ID: I will add this routine including some corrections to the latest repo. It should be considered as a first step trying to replace the old history point handling. Stefan On May 6, 2010, at 3:49 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Guys, > > yes the history point module needs a major overhaul. I don't like the way it works! > In fact we could do a much better job using our interpolation tool. > > I just coded something up (without testing the code snipplet) very quicky but I think I should work out of the box. > > How does it work: > > - create a 'hpts.in' file > line 1: number of points > line 2: X,Y,Z coordinates of a point 1 > .... > line n+1: X,Y,Z coordinates of point n > > - set lpart >= n in the SIZE file > > - call hpts() in userchk() > > The results will be written to 'hpts.out' . > > Enjoy > -Stefan > > > ---------------------------------------------------------------------------------------------------------------------- > > subroutine hpts > c > c dump velocity, temperature and ps-scalars for a given list > c of points (read from file hpts.in) into a file (hpts.out) > c > INCLUDE 'SIZE' > INCLUDE 'TOTAL' > > parameter(nmax=lpart,nfldmax=ldim+ldimt) > parameter(mi=4,mr=1+2*ldim+nfldmax) > real rTL(mr,nmax) > integer iTL(mi,nmax) > common /itlcb/ iTL > common /rtlcb/ rTL > > common /outtmp / wrk(lx1,ly1,lz1,lelt,nfldmax) > > character*80 fname > integer icalld,npoints,icount > save icalld,npoints,icount > data icalld /0/ > data npoints /0/ > data icount /0/ > > nxyz = nx1*ny1*nz1 > ntot = nxyz*nelt > > if(icalld.eq.0) then > icalld = 1 > npoints = 0 > > write(6,*) 'reading hpts.in' > open(50,file='hpts.in',status='old') > read(50,*) npoints > write(6,*) 'found ', npoints, ' points' > do i = 1,npoints > read(50,*) (rTL(1+j,i),j=1,ndim) > enddo > close(50) > > bb_tol = 1e-8 ! bounding-box test tolerance > call intpts_setup(bb_tol) > > open(50,file='hpts.out',status='new') > write(50,'(A)') '# time vx vy [vz] T PS1 PS2 ...' > endif > > nflds = nfield + ndim-1 ! number of fields you want to interpolate > > ! pack working array > call copy(wrk(1,1,1,1,1),vx,ntot) > call copy(wrk(1,1,1,1,2),vy,ntot) > if(if3d) call copy(wrk(1,1,1,1,2),vz,ntot) > do i = 1,nfield-1 > call copy(wrk(1,1,1,1,ndim+i),T(1,1,1,1,i),ntot) > enddo > > ! interpolate > call intpts(wrk,nflds,iTL,mi,rTL,mr,npoints,nmax) > > ! write interpolation results to file > if(nid.eq.0) then > do ip = 1,npoints > write(50,'(1p20E15.7)') time, > & (rTL(1+2*ndim+ifld,ip), ifld=1,nflds) > enddo > endif > > return > end > > > > On May 6, 2010, at 3:24 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> P.S. >> >> Yes, Frank, the exact coordinates of the history points are written only when the code rans. >> >> But if for history points you choose the collocation points on the boundary of a spectral element -- those that have I,J,K equal to either 1 or lx1 -- than you can find out their coordinates from .rea ASCII file after the line >> >> *** MESH DATA *** >> >> where coordinates of the element edges are written. >> >> Aleks >> >> >> >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Wednesday, May 5, 2010 4:45:11 PM GMT -06:00 US/Canada Central >> Subject: Re: [Nek5000-users] History points >> >> Hi Aleks, >> >> My question is what is the logfile? Perhaps you mean the output that >> NEK writes to the screen? If so, then one would know the location of >> the point at which data is being dumped only after entering the i,j,k >> and element # of the point in the *.rea file.... >> >> Cheers, >> Frank >> >> On Wed, 2010-05-05 at 23:37 +0200, nek5000-users at lists.mcs.anl.gov >> wrote: >>> Thanks Aleks. >>> Concerning grep, it is a linux command that searches for the string >>> History in the logfile. >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 May 6 09:41:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 May 2010 09:41:50 -0500 (CDT) Subject: [Nek5000-users] History points In-Reply-To: References: <9683387.924911273152265683.JavaMail.root@zimbra> Message-ID: excellent - thanks Stefan! On Thu, 6 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > I will add this routine including some corrections to the latest repo. > It should be considered as a first step trying to replace the old history point handling. > > Stefan > > > On May 6, 2010, at 3:49 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Guys, >> >> yes the history point module needs a major overhaul. I don't like the way it works! >> In fact we could do a much better job using our interpolation tool. >> >> I just coded something up (without testing the code snipplet) very quicky but I think I should work out of the box. >> >> How does it work: >> >> - create a 'hpts.in' file >> line 1: number of points >> line 2: X,Y,Z coordinates of a point 1 >> .... >> line n+1: X,Y,Z coordinates of point n >> >> - set lpart >= n in the SIZE file >> >> - call hpts() in userchk() >> >> The results will be written to 'hpts.out' . >> >> Enjoy >> -Stefan >> >> >> ---------------------------------------------------------------------------------------------------------------------- >> >> subroutine hpts >> c >> c dump velocity, temperature and ps-scalars for a given list >> c of points (read from file hpts.in) into a file (hpts.out) >> c >> INCLUDE 'SIZE' >> INCLUDE 'TOTAL' >> >> parameter(nmax=lpart,nfldmax=ldim+ldimt) >> parameter(mi=4,mr=1+2*ldim+nfldmax) >> real rTL(mr,nmax) >> integer iTL(mi,nmax) >> common /itlcb/ iTL >> common /rtlcb/ rTL >> >> common /outtmp / wrk(lx1,ly1,lz1,lelt,nfldmax) >> >> character*80 fname >> integer icalld,npoints,icount >> save icalld,npoints,icount >> data icalld /0/ >> data npoints /0/ >> data icount /0/ >> >> nxyz = nx1*ny1*nz1 >> ntot = nxyz*nelt >> >> if(icalld.eq.0) then >> icalld = 1 >> npoints = 0 >> >> write(6,*) 'reading hpts.in' >> open(50,file='hpts.in',status='old') >> read(50,*) npoints >> write(6,*) 'found ', npoints, ' points' >> do i = 1,npoints >> read(50,*) (rTL(1+j,i),j=1,ndim) >> enddo >> close(50) >> >> bb_tol = 1e-8 ! bounding-box test tolerance >> call intpts_setup(bb_tol) >> >> open(50,file='hpts.out',status='new') >> write(50,'(A)') '# time vx vy [vz] T PS1 PS2 ...' >> endif >> >> nflds = nfield + ndim-1 ! number of fields you want to interpolate >> >> ! pack working array >> call copy(wrk(1,1,1,1,1),vx,ntot) >> call copy(wrk(1,1,1,1,2),vy,ntot) >> if(if3d) call copy(wrk(1,1,1,1,2),vz,ntot) >> do i = 1,nfield-1 >> call copy(wrk(1,1,1,1,ndim+i),T(1,1,1,1,i),ntot) >> enddo >> >> ! interpolate >> call intpts(wrk,nflds,iTL,mi,rTL,mr,npoints,nmax) >> >> ! write interpolation results to file >> if(nid.eq.0) then >> do ip = 1,npoints >> write(50,'(1p20E15.7)') time, >> & (rTL(1+2*ndim+ifld,ip), ifld=1,nflds) >> enddo >> endif >> >> return >> end >> >> >> >> On May 6, 2010, at 3:24 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> P.S. >>> >>> Yes, Frank, the exact coordinates of the history points are written only when the code rans. >>> >>> But if for history points you choose the collocation points on the boundary of a spectral element -- those that have I,J,K equal to either 1 or lx1 -- than you can find out their coordinates from .rea ASCII file after the line >>> >>> *** MESH DATA *** >>> >>> where coordinates of the element edges are written. >>> >>> Aleks >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: nek5000-users at lists.mcs.anl.gov >>> To: nek5000-users at lists.mcs.anl.gov >>> Sent: Wednesday, May 5, 2010 4:45:11 PM GMT -06:00 US/Canada Central >>> Subject: Re: [Nek5000-users] History points >>> >>> Hi Aleks, >>> >>> My question is what is the logfile? Perhaps you mean the output that >>> NEK writes to the screen? If so, then one would know the location of >>> the point at which data is being dumped only after entering the i,j,k >>> and element # of the point in the *.rea file.... >>> >>> Cheers, >>> Frank >>> >>> On Wed, 2010-05-05 at 23:37 +0200, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Thanks Aleks. >>>> Concerning grep, it is a linux command that searches for the string >>>> History in the logfile. >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 May 7 16:03:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 07 May 2010 23:03:27 +0200 Subject: [Nek5000-users] History points In-Reply-To: References: <9683387.924911273152265683.JavaMail.root@zimbra> Message-ID: <1273266207.3394.21.camel@localhost.localdomain> Hello Stefan, It seems that this (very useful!) tool has not made it into the repository. I tested out the code snippet you provided and am passing on my results. It seems perhaps that it does not work with multiple processes. Cheers, Frank call userchk reading hpts.in found 2 points reading hpts.in found 2 points reading hpts.in found 2 points reading hpts.in found 2 points reading hpts.in found 2 points reading hpts.in found 2 points reading hpts.in found 2 points reading hpts.in found 2 points forrtl: File exists forrtl: File exists forrtl: File exists forrtl: File exists forrtl: File exists forrtl: severe (10): cannot overwrite existing file, unit 50, file /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-5.0e-5-tim e-.0005-grid-2-Intel/hpts.out Image PC Routine Line Source libintlc.so.5 00002B60A8F4CB1D Unknown Unknown Unknown libintlc.so.5 00002B60A8F4B625 Unknown Unknown Unknown libifcore.so.5 00002B60A8808C65 Unknown Unknown Unknown libifcore.so.5 00002B60A8779DC5 Unknown Unknown Unknown libifcore.so.5 00002B60A877955F Unknown Unknown Unknown libifcore.so.5 00002B60A87956D7 Unknown Unknown Unknown nek5000 000000000040470B Unknown Unknown Unknown nek5000 0000000000406D75 Unknown Unknown Unknown nek5000 00000000004059B5 Unknown Unknown Unknown nek5000 00000000004036AC Unknown forrtl: severe (10): cannot overwrite existing file, unit 50, file /data/fmuldoo/engineering-marangoni-flows /sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-5.0e-5-time-.0005-grid-2-Intel/hpts.out Image PC Routine Line Source libintlc.so.5 00002ABBBCCE9B1D Unknown Unknown Unknown libintlc.so.5 00002ABBBCCE8625 Unknown Unknown Unknown libifcore.so.5 00002ABBBC5A5C65 Unknown Unknown Unknown libifcore.so.5 00002ABBBC516DC5 Unknown Unknown Unknown libifcore.so.5 00002ABBBC51655F Unknown Unknown Unknown libifcore.so.5 00002ABBBC5326D7 Unknown Unknown Unknown nek5000 000000000040470B Unknown Unknown Unknown nek5000 0000000000406D75 Unknown Unknown Unknown nek5000 00000000004059B5 Unknown Unknown Unknown nek5000 00000000004036AC Unknown forrtl: severe (10): cannot overwrite existing file, unit 50, file /data/fmuldoo/engineering-marangoni-flows /sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-5.0e-5-time-.0005-grid-2-Intel/hpts.out Image PC Routine Line Source libintlc.so.5 00002B33F93D8B1D Unknown Unknown Unknown libintlc.so.5 00002B33F93D7625 Unknown Unknown Unknown libifcore.so.5 00002B33F8C94C65 Unknown Unknown Unknown libifcore.so.5 00002B33F8C05DC5 Unknown Unknown Unknown libifcore.so.5 00002B33F8C0555F Unknown Unknown Unknown libifcore.so.5 00002B33F8C216D7 Unknown Unknown Unknown nek5000 000000000040470B Unknown Unknown Unknown nek5000 0000000000406D75 Unknown Unknown Unknown nek5000 00000000004059B5 Unknown Unknown Unknown nek5000 00000000004036AC Unknown Unknown Unknown libc.so.6 00000030B041D994 Unknown Unknown Unknown nek5000 00000000004035A9 Unknown Unknown Unknown On Thu, 2010-05-06 at 15:49 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hi Guys, > > yes the history point module needs a major overhaul. I don't like the way it works! > In fact we could do a much better job using our interpolation tool. > > I just coded something up (without testing the code snipplet) very quicky but I think I should work out of the box. > > How does it work: > > - create a 'hpts.in' file > line 1: number of points > line 2: X,Y,Z coordinates of a point 1 > .... > line n+1: X,Y,Z coordinates of point n > > - set lpart >= n in the SIZE file > > - call hpts() in userchk() > > The results will be written to 'hpts.out' . > > Enjoy > -Stefan > > > ---------------------------------------------------------------------------------------------------------------------- > > subroutine hpts > c > c dump velocity, temperature and ps-scalars for a given list > c of points (read from file hpts.in) into a file (hpts.out) > c > INCLUDE 'SIZE' > INCLUDE 'TOTAL' > > parameter(nmax=lpart,nfldmax=ldim+ldimt) > parameter(mi=4,mr=1+2*ldim+nfldmax) > real rTL(mr,nmax) > integer iTL(mi,nmax) > common /itlcb/ iTL > common /rtlcb/ rTL > > common /outtmp / wrk(lx1,ly1,lz1,lelt,nfldmax) > > character*80 fname > integer icalld,npoints,icount > save icalld,npoints,icount > data icalld /0/ > data npoints /0/ > data icount /0/ > > nxyz = nx1*ny1*nz1 > ntot = nxyz*nelt > > if(icalld.eq.0) then > icalld = 1 > npoints = 0 > > write(6,*) 'reading hpts.in' > open(50,file='hpts.in',status='old') > read(50,*) npoints > write(6,*) 'found ', npoints, ' points' > do i = 1,npoints > read(50,*) (rTL(1+j,i),j=1,ndim) > enddo > close(50) > > bb_tol = 1e-8 ! bounding-box test tolerance > call intpts_setup(bb_tol) > > open(50,file='hpts.out',status='new') > write(50,'(A)') '# time vx vy [vz] T PS1 PS2 ...' > endif > > nflds = nfield + ndim-1 ! number of fields you want to interpolate > > ! pack working array > call copy(wrk(1,1,1,1,1),vx,ntot) > call copy(wrk(1,1,1,1,2),vy,ntot) > if(if3d) call copy(wrk(1,1,1,1,2),vz,ntot) > do i = 1,nfield-1 > call copy(wrk(1,1,1,1,ndim+i),T(1,1,1,1,i),ntot) > enddo > > ! interpolate > call intpts(wrk,nflds,iTL,mi,rTL,mr,npoints,nmax) > > ! write interpolation results to file > if(nid.eq.0) then > do ip = 1,npoints > write(50,'(1p20E15.7)') time, > & (rTL(1+2*ndim+ifld,ip), ifld=1,nflds) > enddo > endif > > return > end > > > > On May 6, 2010, at 3:24 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > P.S. > > > > Yes, Frank, the exact coordinates of the history points are written only when the code rans. > > > > But if for history points you choose the collocation points on the boundary of a spectral element -- those that have I,J,K equal to either 1 or lx1 -- than you can find out their coordinates from .rea ASCII file after the line > > > > *** MESH DATA *** > > > > where coordinates of the element edges are written. > > > > Aleks > > > > > > > > > > > > ----- Original Message ----- > > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > > Sent: Wednesday, May 5, 2010 4:45:11 PM GMT -06:00 US/Canada Central > > Subject: Re: [Nek5000-users] History points > > > > Hi Aleks, > > > > My question is what is the logfile? Perhaps you mean the output that > > NEK writes to the screen? If so, then one would know the location of > > the point at which data is being dumped only after entering the i,j,k > > and element # of the point in the *.rea file.... > > > > Cheers, > > Frank > > > > On Wed, 2010-05-05 at 23:37 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Thanks Aleks. > >> Concerning grep, it is a linux command that searches for the string > >> History in the logfile. > >> _______________________________________________ > >> 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 > > _______________________________________________ > 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 May 7 19:06:13 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 8 May 2010 02:06:13 +0200 Subject: [Nek5000-users] History points In-Reply-To: <1273266207.3394.21.camel@localhost.localdomain> References: <9683387.924911273152265683.JavaMail.root@zimbra> <1273266207.3394.21.camel@localhost.localdomain> Message-ID: <96C933D5-97B3-473C-8BC3-8268E03662B7@lav.mavt.ethz.ch> Frank, I have not submitted it yet. Yes your right, some changes are needed to run it in parallel. Stefan On May 7, 2010, at 11:03 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Stefan, > > It seems that this (very useful!) tool has not made it into the > repository. I tested out the code snippet you provided and am passing > on my results. It seems perhaps that it does not work with multiple > processes. > > Cheers, > Frank > > > call userchk > reading hpts.in > found 2 points > reading hpts.in > found 2 points > reading hpts.in > found 2 points > reading hpts.in > found 2 points > reading hpts.in > found 2 points > reading hpts.in > found 2 points > reading hpts.in > found 2 points > reading hpts.in > found 2 points > forrtl: File exists > forrtl: File exists > forrtl: File exists > forrtl: File exists > forrtl: File exists > forrtl: severe (10): cannot overwrite existing file, unit 50, > file /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-5.0e-5-tim > e-.0005-grid-2-Intel/hpts.out > Image PC Routine Line > Source > libintlc.so.5 00002B60A8F4CB1D Unknown Unknown > Unknown > libintlc.so.5 00002B60A8F4B625 Unknown Unknown > Unknown > libifcore.so.5 00002B60A8808C65 Unknown Unknown > Unknown > libifcore.so.5 00002B60A8779DC5 Unknown Unknown > Unknown > libifcore.so.5 00002B60A877955F Unknown Unknown > Unknown > libifcore.so.5 00002B60A87956D7 Unknown Unknown > Unknown > nek5000 000000000040470B Unknown Unknown > Unknown > nek5000 0000000000406D75 Unknown Unknown > Unknown > nek5000 00000000004059B5 Unknown Unknown > Unknown > nek5000 00000000004036AC Unknown forrtl: severe > (10): cannot overwrite existing file, unit 50, > file /data/fmuldoo/engineering-marangoni-flows > /sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-5.0e-5-time-.0005-grid-2-Intel/hpts.out > Image PC Routine Line > Source > libintlc.so.5 00002ABBBCCE9B1D Unknown Unknown > Unknown > libintlc.so.5 00002ABBBCCE8625 Unknown Unknown > Unknown > libifcore.so.5 00002ABBBC5A5C65 Unknown Unknown > Unknown > libifcore.so.5 00002ABBBC516DC5 Unknown Unknown > Unknown > libifcore.so.5 00002ABBBC51655F Unknown Unknown > Unknown > libifcore.so.5 00002ABBBC5326D7 Unknown Unknown > Unknown > nek5000 000000000040470B Unknown Unknown > Unknown > nek5000 0000000000406D75 Unknown Unknown > Unknown > nek5000 00000000004059B5 Unknown Unknown > Unknown > nek5000 00000000004036AC Unknown forrtl: severe > (10): cannot overwrite existing file, unit 50, > file /data/fmuldoo/engineering-marangoni-flows > /sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-5.0e-5-time-.0005-grid-2-Intel/hpts.out > Image PC Routine Line > Source > libintlc.so.5 00002B33F93D8B1D Unknown Unknown > Unknown > libintlc.so.5 00002B33F93D7625 Unknown Unknown > Unknown > libifcore.so.5 00002B33F8C94C65 Unknown Unknown > Unknown > libifcore.so.5 00002B33F8C05DC5 Unknown Unknown > Unknown > libifcore.so.5 00002B33F8C0555F Unknown Unknown > Unknown > libifcore.so.5 00002B33F8C216D7 Unknown Unknown > Unknown > nek5000 000000000040470B Unknown Unknown > Unknown > nek5000 0000000000406D75 Unknown Unknown > Unknown > nek5000 00000000004059B5 Unknown Unknown > Unknown > nek5000 00000000004036AC Unknown Unknown > Unknown > libc.so.6 00000030B041D994 Unknown Unknown > Unknown > nek5000 00000000004035A9 Unknown Unknown > Unknown > > > > On Thu, 2010-05-06 at 15:49 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Guys, >> >> yes the history point module needs a major overhaul. I don't like the way it works! >> In fact we could do a much better job using our interpolation tool. >> >> I just coded something up (without testing the code snipplet) very quicky but I think I should work out of the box. >> >> How does it work: >> >> - create a 'hpts.in' file >> line 1: number of points >> line 2: X,Y,Z coordinates of a point 1 >> .... >> line n+1: X,Y,Z coordinates of point n >> >> - set lpart >= n in the SIZE file >> >> - call hpts() in userchk() >> >> The results will be written to 'hpts.out' . >> >> Enjoy >> -Stefan >> >> >> ---------------------------------------------------------------------------------------------------------------------- >> >> subroutine hpts >> c >> c dump velocity, temperature and ps-scalars for a given list >> c of points (read from file hpts.in) into a file (hpts.out) >> c >> INCLUDE 'SIZE' >> INCLUDE 'TOTAL' >> >> parameter(nmax=lpart,nfldmax=ldim+ldimt) >> parameter(mi=4,mr=1+2*ldim+nfldmax) >> real rTL(mr,nmax) >> integer iTL(mi,nmax) >> common /itlcb/ iTL >> common /rtlcb/ rTL >> >> common /outtmp / wrk(lx1,ly1,lz1,lelt,nfldmax) >> >> character*80 fname >> integer icalld,npoints,icount >> save icalld,npoints,icount >> data icalld /0/ >> data npoints /0/ >> data icount /0/ >> >> nxyz = nx1*ny1*nz1 >> ntot = nxyz*nelt >> >> if(icalld.eq.0) then >> icalld = 1 >> npoints = 0 >> >> write(6,*) 'reading hpts.in' >> open(50,file='hpts.in',status='old') >> read(50,*) npoints >> write(6,*) 'found ', npoints, ' points' >> do i = 1,npoints >> read(50,*) (rTL(1+j,i),j=1,ndim) >> enddo >> close(50) >> >> bb_tol = 1e-8 ! bounding-box test tolerance >> call intpts_setup(bb_tol) >> >> open(50,file='hpts.out',status='new') >> write(50,'(A)') '# time vx vy [vz] T PS1 PS2 ...' >> endif >> >> nflds = nfield + ndim-1 ! number of fields you want to interpolate >> >> ! pack working array >> call copy(wrk(1,1,1,1,1),vx,ntot) >> call copy(wrk(1,1,1,1,2),vy,ntot) >> if(if3d) call copy(wrk(1,1,1,1,2),vz,ntot) >> do i = 1,nfield-1 >> call copy(wrk(1,1,1,1,ndim+i),T(1,1,1,1,i),ntot) >> enddo >> >> ! interpolate >> call intpts(wrk,nflds,iTL,mi,rTL,mr,npoints,nmax) >> >> ! write interpolation results to file >> if(nid.eq.0) then >> do ip = 1,npoints >> write(50,'(1p20E15.7)') time, >> & (rTL(1+2*ndim+ifld,ip), ifld=1,nflds) >> enddo >> endif >> >> return >> end >> >> >> >> On May 6, 2010, at 3:24 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> P.S. >>> >>> Yes, Frank, the exact coordinates of the history points are written only when the code rans. >>> >>> But if for history points you choose the collocation points on the boundary of a spectral element -- those that have I,J,K equal to either 1 or lx1 -- than you can find out their coordinates from .rea ASCII file after the line >>> >>> *** MESH DATA *** >>> >>> where coordinates of the element edges are written. >>> >>> Aleks >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: nek5000-users at lists.mcs.anl.gov >>> To: nek5000-users at lists.mcs.anl.gov >>> Sent: Wednesday, May 5, 2010 4:45:11 PM GMT -06:00 US/Canada Central >>> Subject: Re: [Nek5000-users] History points >>> >>> Hi Aleks, >>> >>> My question is what is the logfile? Perhaps you mean the output that >>> NEK writes to the screen? If so, then one would know the location of >>> the point at which data is being dumped only after entering the i,j,k >>> and element # of the point in the *.rea file.... >>> >>> Cheers, >>> Frank >>> >>> On Wed, 2010-05-05 at 23:37 +0200, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Thanks Aleks. >>>> Concerning grep, it is a linux command that searches for the string >>>> History in the logfile. >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 May 10 08:09:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 May 2010 15:09:11 +0200 Subject: [Nek5000-users] perturbing interior variables Message-ID: <1273496952.3394.135.camel@localhost.localdomain> Hello all, I am trying to perturb the temperature in a small part of the flow. However, I only wish to perturb in the interior and not on a boundary. I have the following in "userchk". If I instead looped from "k=1,nz1" instead of "k=2,nz1-1", would this change the BC's? The general question would be, does changing uvw & T in "userchk" change BC's or does "userbc" override what is done in "userchk"? Cheers, Frank do 100 iel=1,nelv do 100 k=2,nz1-1 do 100 j=2,ny1-1 do 100 i=2,nx1-1 if(((xm1(i,j,k,iel)-1.1)**2 & + (ym1(i,j,k,iel)-1.1)**2 & + (zm1(i,j,k,iel)-.45)**2)**.5.le..25)then t(i,j,k,iel)=.99*t(i,j,k,iel) endif enddo !n 100 continue -- 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 May 10 09:36:22 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 May 2010 09:36:22 -0500 Subject: [Nek5000-users] Warning Message : L1/L2 DIV(V) In-Reply-To: References: Message-ID: Hi Stefan, I apologize for the delay in replying to your questions. 1. In earlier conversation I was told that PN-PN formulation has resulted in better accuracy. As such, I am not sure how one would choose which basis (PN-PN / PN-PN-2) is appropriate for their problem. I am working in transitional flows. Would you recommend any particular choice of basis for this type of applications ? 2. Yes, I believe I am running it on AMD 10h processors. I will compile with K10_MXM for my production run. Thanks. 3. As regarding the divergence : Though the warning pops up every step, nothing blows up in my simulation. The high values ( that are acceptable) are at the outflow where we add some divergence to the flow. 4. I did observe one thing, If I lower the courant to very low value, the error drops down but not by a huge margin. Thanks Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 10 09:53:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 May 2010 16:53:55 +0200 Subject: [Nek5000-users] Warning Message : L1/L2 DIV(V) In-Reply-To: References: Message-ID: <9DADF8A0-C569-4078-864C-B743BD4D7B13@lav.mavt.ethz.ch> > 1. In earlier conversation I was told that PN-PN formulation has resulted in better accuracy. As such, I am not sure how one would choose which basis (PN-PN / PN-PN-2) is appropriate for their problem. I am working in transitional flows. Would you recommend any particular choice of basis for this type of applications ? In general I would recommend to use the PN/PN formulation. However there are some features (e.g. moving mesh, free surface flows, MHD, etc.) which only work for PN/PN-2 for now. In addition we don't have the SEMG multigrid preconditioner in place for PN/PN. So depending on your mesh the cost of the pressure solve is higher (more iterations are needed for a given tolerance) although the cost is usually lower per iteration for PN/PN (no interpolation is needed). > 2. Yes, I believe I am running it on AMD 10h processors. I will compile with K10_MXM for my production run. Thanks. For the moment the tuned version is only available for lx1=10 and lx1=8! > 3. As regarding the divergence : Though the warning pops up every step, nothing blows up in my simulation. The high values ( that are acceptable) are at the outflow where we add some divergence to the flow. Sure you will have some pretty large values at the outflow. That's ok but I am confused by the large L2-norm of the difference in divergence. > 4. I did observe one thing, If I lower the courant to very low value, the error drops down but not by a huge margin. Yes there is a time step effect but usually your limited by spatial resolution. Stefan From nek5000-users at lists.mcs.anl.gov Mon May 10 11:00:17 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 May 2010 11:00:17 -0500 (CDT) Subject: [Nek5000-users] perturbing interior variables In-Reply-To: <1273496952.3394.135.camel@localhost.localdomain> References: <1273496952.3394.135.camel@localhost.localdomain> Message-ID: Hi Frank, I assume that you refer to t(i,j,k,iel) as temperature -- to be safe it should be t(i,j,k,iel,1)... In timestepping loop, subroutine userchk is called last by one -- right before the last one -- prepost which dumps field files .f or .fld -- see nek5_svn/trunk/nek/drive1.f: DO ISTEP=1,NSTEPS call nek_advance call userchk call prepost (.false.,'his') if (lastep .eq. 1) goto 1001B ENDDO while, as I can see, userbc for a passive scalar is called from a chain of subroutines nek_advance > heat > cdscal > BCNEUSC/BCDIRSC This means that perturbation of temperature at the boundary won't be overwritten in userbc. One way to apply perturbation everywhere including the element faces that are not on the boundary of your domain is simply to multiply your perturbation factor by a function that goes to zero on the boundaries, e.g.: t(i,j,k,iel,1)=.99*t(i,j,k,iel,1)*(xm1(i,j,k,iel)**2.-1.) in case the boundary surface plane is at x=1 & x=-1 Best, Aleks On Mon, 10 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, I am trying to perturb the temperature in a small part of the flow. However, I only wish to perturb in the interior and not on a boundary. I have the following in "userchk". If I instead looped from "k=1,nz1" instead of "k=2,nz1-1", would this change the BC's? The general question would be, does changing uvw & T in "userchk" change BC's or does "userbc" override what is done in "userchk"? Cheers, Frank do 100 iel=1,nelv do 100 k=2,nz1-1 do 100 j=2,ny1-1 do 100 i=2,nx1-1 if(((xm1(i,j,k,iel)-1.1)**2 & + (ym1(i,j,k,iel)-1.1)**2 & + (zm1(i,j,k,iel)-.45)**2)**.5.le..25)then t(i,j,k,iel)=.99*t(i,j,k,iel) endif enddo !n 100 continue -- 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 May 10 11:01:22 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 May 2010 18:01:22 +0200 Subject: [Nek5000-users] RE : prex & pretex not working In-Reply-To: References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> <4D5AC257-4D39-4749-BF61-F898757CF542@lav.mavt.ethz.ch> <0F735E7F-123A-4E71-86A3-57817C15C590@lav.mavt.ethz.ch>, Message-ID: <5313C3E0D03CB044A289CAC54D804C120157A2F1EBA8@BVMBX1.univ-lyon1.fr> Hello Neks, I ran an svn update this morning (rev 510). Since then I can't compile prex/prenek anymore. I tried with and without the big memory support enabled. Here is what I get in both cases : [17:46:58 michael at dsktp-lmfa:~/Codes/nek5_svn/trunk/tools ] $ ./maketools prenek ---------------------- Make prenek... ---------------------- [: 23: prenek: unexpected operator [: 23: prenek: unexpected operator make[1]: entrant dans le r?pertoire ? /home/michael/Codes/nek5_svn/trunk/tools/prenek ? gfortran -mcmodel=medium -o /home/michael/bin/prex prenek.o curve.o edit.o build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o xdriver.o -L/usr/X11R6/lib -lX11 -lm prenek.o: In function `fprep_': prenek.f:(.text+0x111): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o prenek.f:(.text+0x32b): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o prenek.o: In function `read_params_': prenek.f:(.text+0x625): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o prenek.f:(.text+0x641): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o prenek.f:(.text+0x71b): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o prenek.f:(.text+0x7d6): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o prenek.f:(.text+0x859): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o prenek.f:(.text+0x8dc): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o prenek.f:(.text+0x966): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o prenek.f:(.text+0x96e): relocation truncated to fit: R_X86_64_PC32 against symbol `param_' defined in COMMON section in prenek.o prenek.f:(.text+0x97b): additional relocation overflows omitted from the output collect2: ld returned 1 exit status make[1]: *** [prex] Erreur 1 make[1]: quittant le r?pertoire ? /home/michael/Codes/nek5_svn/trunk/tools/prenek ? make: *** [all] Erreur 1 [17:47:51 michael at dsktp-lmfa:~/Codes/nek5_svn/trunk/tools ] $ Do you have any idea on what is happening there? Is it compulsory to switch to the Intel ifort compiler for the new version of prenek? Thanks in advance for any help. Best, 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 : lundi 3 mai 2010 20:14 ? : nek5000-users at lists.mcs.anl.gov Objet : Re: [Nek5000-users] prex & pretex not working Hi Stefan, The command does not do anything. Here is the output of the command. It does not display anything. [kanch1 at honest3 tools]$ ./maketools prenek [kanch1 at honest3 tools]$ Thanks, Harish. On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > Please send the output of './maketools prenek' > > Stefan > > > On May 3, 2010, at 7:10 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Stefan, > > > > Sorry for missing out on that problem report. > > > > But I tried changing the F77 compiler as below and it does not work. > > "maketools all" does nothing. > > > > F77="ifort -shared-intel" > > > > Also, this is on a different linux box not on my cluster which has GNU > > compiler. > > > > Thanks, > > > > Harish. > > > > On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > > > >> I know. There was a problem report on the mailing list already. > >> > >> This was my answer: > >> > >> Ok I think I know a way to fix the Intel compiler problem. > >> > >> To compile prenek (prex) you need to enable the BIGMEM support so you have to use at least the medium memory model. However the Intel compilers wants you to link all Intel-Libs dynamically if you use another memory model than small. > >> > >> Just set F77= "ifort -shared-intel" and it should work! > >> > >> hth, > >> Stefan > >> > >> On May 3, 2010, at 5:45 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hi Stefan, > >>> > >>> I tried compiling prenek on NCSA-Abe machine with ifort & icc. I get the > >>> following error, its same error w/ and w/o "BIGMEM" flag. > >>> > >>> Thanks, > >>> > >>> Harish. > >>> > >>> ************************************************************************* > >>> icc -c -DUNDERSCORE -Dr8 xdriver.c > >>> xdriver.c(875): warning #266: function "fprep_" declared implicitly > >>> fprep_ (); /* run Fortran Main code */ > >>> ^ > >>> > >>> xdriver.c(123): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(125): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(747): (col. 4) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(823): (col. 4) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(700): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(333): (col. 5) remark: LOOP WAS VECTORIZED. > >>> xdriver.c(340): (col. 5) remark: LOOP WAS VECTORIZED. > >>> ifort -o /u/ac/kanch1/nek5_svn/trunk/tools/prex prenek.o curve.o edit.o > >>> build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o > >>> vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o > >>> xdriver.o -L/usr/X11R6/lib64 -lX11 -lm > >>> prenek.o(.text+0x47d): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x4f9): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x50d): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 basics_ > >>> prenek.o(.text+0x584): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 devs_ > >>> prenek.o(.text+0x5b1): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x62d): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x667): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_32S chaar_ > >>> prenek.o(.text+0x740): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 modes_ > >>> prenek.o(.text+0x789): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x7fc): In function `drivfc_': > >>> : relocation truncated to fit: R_X86_64_PC32 chaar_ > >>> prenek.o(.text+0x80c): In function `drivfc_': > >>> : additional relocation overflows omitted from the output > >>> make[1]: *** [prex] Error 1 > >>> make[1]: Leaving directory `/u/ac/kanch1/nek5_svn/trunk/tools/prenek' > >>> make: *** [all] Error 1 > >>> ************************************************************************** > >>> > >>> On Mon, May 3, 2010 9:38 am, nek5000-users at lists.mcs.anl.gov wrote: > >>>> Can you try on another Linux box? You can get the Intel compilers (non > >>>> commercial usage) for free. > >>>> Sorry I don't want to login into other machines unless it's really needed. > >>>> > >>>> Stefan > >>>> > >>>> On May 3, 2010, at 4:34 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Hi Stefan, > >>>>> > >>>>> I do not have any other compiler on the cluster. I can give you my login > >>>>> to check the problem. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Harish. > >>>>> > >>>>> On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > >>>>> > >>>>>> Hi Harish, > >>>>>> > >>>>>> unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ > >>>>>> gfortran 4.5). > >>>>>> Can you try again using another compiler? > >>>>>> > >>>>>> Stefan > >>>>>> > >>>>>> > >>>>>> On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> I am compiling prenek with GNU compilers, gfortran-4.3.2 and > >>>>>>> gcc-4.3.2. > >>>>>>> When I compile it without "BIGMEM" flag it gives an error, the output > >>>>>>> of > >>>>>>> it is attached (error.out). With "BIGMEM" flag turned on, there are no > >>>>>>> compiler errors (compile.out). But when I try to open pretex or prex, > >>>>>>> I > >>>>>>> get the following error. > >>>>>>> > >>>>>>> [harish at cmtl hole-in-center]$ prex > >>>>>>> Killed > >>>>>>> [harish at cmtl hole-in-center]$ pretex > >>>>>>> Killed > >>>>>>> > >>>>>>> All the other tools are working fine. Any help in solving this issue > >>>>>>> is > >>>>>>> appreciated. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Harish. > >>>>>>> _______________________________________________ > >>>>>>> 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 > > _______________________________________________ > 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 May 10 11:10:13 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 May 2010 18:10:13 +0200 Subject: [Nek5000-users] RE : prex & pretex not working In-Reply-To: <5313C3E0D03CB044A289CAC54D804C120157A2F1EBA8@BVMBX1.univ-lyon1.fr> References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> <4D5AC257-4D39-4749-BF61-F898757CF542@lav.mavt.ethz.ch> <0F735E7F-123A-4E71-86A3-57817C15C590@lav.mavt.ethz.ch>, <5313C3E0D03CB044A289CAC54D804C120157A2F1EBA8@BVMBX1.univ-lyon1.fr> Message-ID: You have to enable BIGMEM otherwise prenek will not compile unless you lower the memory footprint. I just tried to compile prenek with the GNU compilers and there was no problem? It looks like your maketools is messed up. Did you do a 'svn update'? If yes. please do the following: cd ~/nek5_svn/trunk; rm -rf tools; svn update tools hth, Stefan On May 10, 2010, at 6:01 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Neks, > > I ran an svn update this morning (rev 510). Since then I can't compile prex/prenek anymore. I tried with and without the big memory support enabled. Here is what I get in both cases : > > [17:46:58 michael at dsktp-lmfa:~/Codes/nek5_svn/trunk/tools ] $ ./maketools prenek > ---------------------- > Make prenek... > ---------------------- > [: 23: prenek: unexpected operator > [: 23: prenek: unexpected operator > make[1]: entrant dans le r?pertoire ? /home/michael/Codes/nek5_svn/trunk/tools/prenek ? > gfortran -mcmodel=medium -o /home/michael/bin/prex prenek.o curve.o edit.o build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o xdriver.o -L/usr/X11R6/lib -lX11 -lm > prenek.o: In function `fprep_': > prenek.f:(.text+0x111): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o > prenek.f:(.text+0x32b): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o > prenek.o: In function `read_params_': > prenek.f:(.text+0x625): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o > prenek.f:(.text+0x641): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o > prenek.f:(.text+0x71b): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x7d6): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x859): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x8dc): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x966): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x96e): relocation truncated to fit: R_X86_64_PC32 against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x97b): additional relocation overflows omitted from the output > collect2: ld returned 1 exit status > make[1]: *** [prex] Erreur 1 > make[1]: quittant le r?pertoire ? /home/michael/Codes/nek5_svn/trunk/tools/prenek ? > make: *** [all] Erreur 1 > [17:47:51 michael at dsktp-lmfa:~/Codes/nek5_svn/trunk/tools ] $ > > > Do you have any idea on what is happening there? > Is it compulsory to switch to the Intel ifort compiler for the new version of prenek? > > Thanks in advance for any help. > Best, > > > 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 : lundi 3 mai 2010 20:14 > ? : nek5000-users at lists.mcs.anl.gov > Objet : Re: [Nek5000-users] prex & pretex not working > > Hi Stefan, > > The command does not do anything. Here is the output of the command. It > does not display anything. > > [kanch1 at honest3 tools]$ ./maketools prenek > [kanch1 at honest3 tools]$ > > Thanks, > > Harish. > > On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > >> Please send the output of './maketools prenek' >> >> Stefan >> >> >> On May 3, 2010, at 7:10 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Stefan, >>> >>> Sorry for missing out on that problem report. >>> >>> But I tried changing the F77 compiler as below and it does not work. >>> "maketools all" does nothing. >>> >>> F77="ifort -shared-intel" >>> >>> Also, this is on a different linux box not on my cluster which has GNU >>> compiler. >>> >>> Thanks, >>> >>> Harish. >>> >>> On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> I know. There was a problem report on the mailing list already. >>>> >>>> This was my answer: >>>> >>>> Ok I think I know a way to fix the Intel compiler problem. >>>> >>>> To compile prenek (prex) you need to enable the BIGMEM support so you have to use at least the medium memory model. However the Intel compilers wants you to link all Intel-Libs dynamically if you use another memory model than small. >>>> >>>> Just set F77= "ifort -shared-intel" and it should work! >>>> >>>> hth, >>>> Stefan >>>> >>>> On May 3, 2010, at 5:45 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi Stefan, >>>>> >>>>> I tried compiling prenek on NCSA-Abe machine with ifort & icc. I get the >>>>> following error, its same error w/ and w/o "BIGMEM" flag. >>>>> >>>>> Thanks, >>>>> >>>>> Harish. >>>>> >>>>> ************************************************************************* >>>>> icc -c -DUNDERSCORE -Dr8 xdriver.c >>>>> xdriver.c(875): warning #266: function "fprep_" declared implicitly >>>>> fprep_ (); /* run Fortran Main code */ >>>>> ^ >>>>> >>>>> xdriver.c(123): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(125): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(747): (col. 4) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(823): (col. 4) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(700): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(333): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(340): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> ifort -o /u/ac/kanch1/nek5_svn/trunk/tools/prex prenek.o curve.o edit.o >>>>> build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o >>>>> vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o >>>>> xdriver.o -L/usr/X11R6/lib64 -lX11 -lm >>>>> prenek.o(.text+0x47d): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x4f9): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x50d): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 basics_ >>>>> prenek.o(.text+0x584): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 devs_ >>>>> prenek.o(.text+0x5b1): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x62d): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x667): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_32S chaar_ >>>>> prenek.o(.text+0x740): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 modes_ >>>>> prenek.o(.text+0x789): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x7fc): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x80c): In function `drivfc_': >>>>> : additional relocation overflows omitted from the output >>>>> make[1]: *** [prex] Error 1 >>>>> make[1]: Leaving directory `/u/ac/kanch1/nek5_svn/trunk/tools/prenek' >>>>> make: *** [all] Error 1 >>>>> ************************************************************************** >>>>> >>>>> On Mon, May 3, 2010 9:38 am, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> Can you try on another Linux box? You can get the Intel compilers (non >>>>>> commercial usage) for free. >>>>>> Sorry I don't want to login into other machines unless it's really needed. >>>>>> >>>>>> Stefan >>>>>> >>>>>> On May 3, 2010, at 4:34 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> >>>>>>> Hi Stefan, >>>>>>> >>>>>>> I do not have any other compiler on the cluster. I can give you my login >>>>>>> to check the problem. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Harish. >>>>>>> >>>>>>> On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: >>>>>>> >>>>>>>> Hi Harish, >>>>>>>> >>>>>>>> unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ >>>>>>>> gfortran 4.5). >>>>>>>> Can you try again using another compiler? >>>>>>>> >>>>>>>> Stefan >>>>>>>> >>>>>>>> >>>>>>>> On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I am compiling prenek with GNU compilers, gfortran-4.3.2 and >>>>>>>>> gcc-4.3.2. >>>>>>>>> When I compile it without "BIGMEM" flag it gives an error, the output >>>>>>>>> of >>>>>>>>> it is attached (error.out). With "BIGMEM" flag turned on, there are no >>>>>>>>> compiler errors (compile.out). But when I try to open pretex or prex, >>>>>>>>> I >>>>>>>>> get the following error. >>>>>>>>> >>>>>>>>> [harish at cmtl hole-in-center]$ prex >>>>>>>>> Killed >>>>>>>>> [harish at cmtl hole-in-center]$ pretex >>>>>>>>> Killed >>>>>>>>> >>>>>>>>> All the other tools are working fine. Any help in solving this issue >>>>>>>>> is >>>>>>>>> appreciated. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Harish. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >> >> _______________________________________________ >> 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 May 10 11:15:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 May 2010 18:15:38 +0200 Subject: [Nek5000-users] perturbing interior variables In-Reply-To: References: <1273496952.3394.135.camel@localhost.localdomain> Message-ID: The heat solver calls BCDIRSC which will apply Dirichlet bcs. All 't ' boundary points call userbc so you have the full control over the values at the boundary. Stefan On May 10, 2010, at 6:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > > I assume that you refer to t(i,j,k,iel) as temperature -- to be safe it should be t(i,j,k,iel,1)... > > > In timestepping loop, subroutine userchk is called last by one -- right before the last one -- prepost which dumps field files .f or .fld -- see nek5_svn/trunk/nek/drive1.f: > > DO ISTEP=1,NSTEPS > call nek_advance > call userchk > call prepost (.false.,'his') > if (lastep .eq. 1) goto 1001B > ENDDO > > while, as I can see, userbc for a passive scalar is called from a chain of subroutines nek_advance > heat > cdscal > BCNEUSC/BCDIRSC > > This means that perturbation of temperature at the boundary won't be overwritten in userbc. > > > One way to apply perturbation everywhere including the element faces that are not on the boundary of your domain is simply to multiply your perturbation factor by a function that goes to zero on the boundaries, e.g.: > > t(i,j,k,iel,1)=.99*t(i,j,k,iel,1)*(xm1(i,j,k,iel)**2.-1.) > > in case the boundary surface plane is at x=1 & x=-1 > > Best, > Aleks > > > > > > > On Mon, 10 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello all, > > I am trying to perturb the temperature in a small part of the flow. > However, I only wish to perturb in the interior and not on a boundary. > I have the following in "userchk". If I instead looped from "k=1,nz1" > instead of "k=2,nz1-1", would this change the BC's? The general > question would be, does changing uvw & T in "userchk" change BC's or > does "userbc" override what is done in "userchk"? > > Cheers, > Frank > > do 100 iel=1,nelv > do 100 k=2,nz1-1 > do 100 j=2,ny1-1 > do 100 i=2,nx1-1 > if(((xm1(i,j,k,iel)-1.1)**2 > & + (ym1(i,j,k,iel)-1.1)**2 > & + (zm1(i,j,k,iel)-.45)**2)**.5.le..25)then > t(i,j,k,iel)=.99*t(i,j,k,iel) > endif > enddo !n > 100 continue > > > > > -- > 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 Mon May 10 11:30:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 May 2010 18:30:29 +0200 Subject: [Nek5000-users] RE : RE : prex & pretex not working In-Reply-To: References: <6e6a5f15e5ad7a802b68292365d0d5a1.squirrel@webmail.uic.edu> <4D5AC257-4D39-4749-BF61-F898757CF542@lav.mavt.ethz.ch> <0F735E7F-123A-4E71-86A3-57817C15C590@lav.mavt.ethz.ch>, <5313C3E0D03CB044A289CAC54D804C120157A2F1EBA8@BVMBX1.univ-lyon1.fr>, Message-ID: <5313C3E0D03CB044A289CAC54D804C120157A2F1EBA9@BVMBX1.univ-lyon1.fr> Hello Stefan, this was indeed a problem with the maketools file (I can't figure out what happened...) . Your solution worked just fine. Thanks for the quick and efficient reply. Best, 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 : lundi 10 mai 2010 18:10 ? : nek5000-users at lists.mcs.anl.gov Objet : Re: [Nek5000-users] RE : prex & pretex not working You have to enable BIGMEM otherwise prenek will not compile unless you lower the memory footprint. I just tried to compile prenek with the GNU compilers and there was no problem? It looks like your maketools is messed up. Did you do a 'svn update'? If yes. please do the following: cd ~/nek5_svn/trunk; rm -rf tools; svn update tools hth, Stefan On May 10, 2010, at 6:01 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Neks, > > I ran an svn update this morning (rev 510). Since then I can't compile prex/prenek anymore. I tried with and without the big memory support enabled. Here is what I get in both cases : > > [17:46:58 michael at dsktp-lmfa:~/Codes/nek5_svn/trunk/tools ] $ ./maketools prenek > ---------------------- > Make prenek... > ---------------------- > [: 23: prenek: unexpected operator > [: 23: prenek: unexpected operator > make[1]: entrant dans le r?pertoire ? /home/michael/Codes/nek5_svn/trunk/tools/prenek ? > gfortran -mcmodel=medium -o /home/michael/bin/prex prenek.o curve.o edit.o build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o xdriver.o -L/usr/X11R6/lib -lX11 -lm > prenek.o: In function `fprep_': > prenek.f:(.text+0x111): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o > prenek.f:(.text+0x32b): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o > prenek.o: In function `read_params_': > prenek.f:(.text+0x625): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o > prenek.f:(.text+0x641): relocation truncated to fit: R_X86_64_PC32 against symbol `devs_' defined in COMMON section in prenek.o > prenek.f:(.text+0x71b): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x7d6): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x859): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x8dc): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x966): relocation truncated to fit: R_X86_64_32S against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x96e): relocation truncated to fit: R_X86_64_PC32 against symbol `param_' defined in COMMON section in prenek.o > prenek.f:(.text+0x97b): additional relocation overflows omitted from the output > collect2: ld returned 1 exit status > make[1]: *** [prex] Erreur 1 > make[1]: quittant le r?pertoire ? /home/michael/Codes/nek5_svn/trunk/tools/prenek ? > make: *** [all] Erreur 1 > [17:47:51 michael at dsktp-lmfa:~/Codes/nek5_svn/trunk/tools ] $ > > > Do you have any idea on what is happening there? > Is it compulsory to switch to the Intel ifort compiler for the new version of prenek? > > Thanks in advance for any help. > Best, > > > 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 : lundi 3 mai 2010 20:14 > ? : nek5000-users at lists.mcs.anl.gov > Objet : Re: [Nek5000-users] prex & pretex not working > > Hi Stefan, > > The command does not do anything. Here is the output of the command. It > does not display anything. > > [kanch1 at honest3 tools]$ ./maketools prenek > [kanch1 at honest3 tools]$ > > Thanks, > > Harish. > > On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: > >> Please send the output of './maketools prenek' >> >> Stefan >> >> >> On May 3, 2010, at 7:10 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Stefan, >>> >>> Sorry for missing out on that problem report. >>> >>> But I tried changing the F77 compiler as below and it does not work. >>> "maketools all" does nothing. >>> >>> F77="ifort -shared-intel" >>> >>> Also, this is on a different linux box not on my cluster which has GNU >>> compiler. >>> >>> Thanks, >>> >>> Harish. >>> >>> On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> I know. There was a problem report on the mailing list already. >>>> >>>> This was my answer: >>>> >>>> Ok I think I know a way to fix the Intel compiler problem. >>>> >>>> To compile prenek (prex) you need to enable the BIGMEM support so you have to use at least the medium memory model. However the Intel compilers wants you to link all Intel-Libs dynamically if you use another memory model than small. >>>> >>>> Just set F77= "ifort -shared-intel" and it should work! >>>> >>>> hth, >>>> Stefan >>>> >>>> On May 3, 2010, at 5:45 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi Stefan, >>>>> >>>>> I tried compiling prenek on NCSA-Abe machine with ifort & icc. I get the >>>>> following error, its same error w/ and w/o "BIGMEM" flag. >>>>> >>>>> Thanks, >>>>> >>>>> Harish. >>>>> >>>>> ************************************************************************* >>>>> icc -c -DUNDERSCORE -Dr8 xdriver.c >>>>> xdriver.c(875): warning #266: function "fprep_" declared implicitly >>>>> fprep_ (); /* run Fortran Main code */ >>>>> ^ >>>>> >>>>> xdriver.c(123): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(125): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(869): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(747): (col. 4) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(823): (col. 4) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(700): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(333): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> xdriver.c(340): (col. 5) remark: LOOP WAS VECTORIZED. >>>>> ifort -o /u/ac/kanch1/nek5_svn/trunk/tools/prex prenek.o curve.o edit.o >>>>> build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o >>>>> vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o >>>>> xdriver.o -L/usr/X11R6/lib64 -lX11 -lm >>>>> prenek.o(.text+0x47d): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x4f9): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x50d): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 basics_ >>>>> prenek.o(.text+0x584): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 devs_ >>>>> prenek.o(.text+0x5b1): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x62d): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x667): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_32S chaar_ >>>>> prenek.o(.text+0x740): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 modes_ >>>>> prenek.o(.text+0x789): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x7fc): In function `drivfc_': >>>>> : relocation truncated to fit: R_X86_64_PC32 chaar_ >>>>> prenek.o(.text+0x80c): In function `drivfc_': >>>>> : additional relocation overflows omitted from the output >>>>> make[1]: *** [prex] Error 1 >>>>> make[1]: Leaving directory `/u/ac/kanch1/nek5_svn/trunk/tools/prenek' >>>>> make: *** [all] Error 1 >>>>> ************************************************************************** >>>>> >>>>> On Mon, May 3, 2010 9:38 am, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> Can you try on another Linux box? You can get the Intel compilers (non >>>>>> commercial usage) for free. >>>>>> Sorry I don't want to login into other machines unless it's really needed. >>>>>> >>>>>> Stefan >>>>>> >>>>>> On May 3, 2010, at 4:34 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> >>>>>>> Hi Stefan, >>>>>>> >>>>>>> I do not have any other compiler on the cluster. I can give you my login >>>>>>> to check the problem. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Harish. >>>>>>> >>>>>>> On Mon, 3 May 2010 nek5000-users at lists.mcs.anl.gov wrote: >>>>>>> >>>>>>>> Hi Harish, >>>>>>>> >>>>>>>> unfortunately I cannot reproduce the problem over there (gcc 4.2.1/ >>>>>>>> gfortran 4.5). >>>>>>>> Can you try again using another compiler? >>>>>>>> >>>>>>>> Stefan >>>>>>>> >>>>>>>> >>>>>>>> On May 3, 2010, at 3:26 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I am compiling prenek with GNU compilers, gfortran-4.3.2 and >>>>>>>>> gcc-4.3.2. >>>>>>>>> When I compile it without "BIGMEM" flag it gives an error, the output >>>>>>>>> of >>>>>>>>> it is attached (error.out). With "BIGMEM" flag turned on, there are no >>>>>>>>> compiler errors (compile.out). But when I try to open pretex or prex, >>>>>>>>> I >>>>>>>>> get the following error. >>>>>>>>> >>>>>>>>> [harish at cmtl hole-in-center]$ prex >>>>>>>>> Killed >>>>>>>>> [harish at cmtl hole-in-center]$ pretex >>>>>>>>> Killed >>>>>>>>> >>>>>>>>> All the other tools are working fine. Any help in solving this issue >>>>>>>>> is >>>>>>>>> appreciated. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Harish. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >> >> _______________________________________________ >> 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 May 11 05:08:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 15:38:38 +0530 Subject: [Nek5000-users] Compilation failing with gfortran Message-ID: <4BE92CA6.1080806@iitk.ac.in> Hi, I'm using mpif77 with gfortran underneath and I'm not able to compile any of the examples of the latest code (which I downloaded today). The error is: /home/guest/nek5_svn/trunk/nek/navier8.f: In function 'setvert3d': /home/guest/nek5_svn/trunk/nek/navier8.f:2322: internal compiler error: in expand_expr_real_1, at expr.c:6846 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [obj/navier8.o] Error 1 However an earlier version of the code which I've been using for a couple of months works fine. Attached is the compiler.out. I've noticed that the input files are slightly different. Do we not need SESSION.NAME any more? Regards, Mani chandra -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: compiler.out URL: From nek5000-users at lists.mcs.anl.gov Tue May 11 06:00:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 13:00:49 +0200 Subject: [Nek5000-users] Compilation failing with gfortran In-Reply-To: <4BE92CA6.1080806@iitk.ac.in> References: <4BE92CA6.1080806@iitk.ac.in> Message-ID: <50168544-3F76-43DA-A5A1-1A2943EFE666@lav.mavt.ethz.ch> What Nek version did you use before you changed to the latest release? Stefan On May 11, 2010, at 12:08 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I'm using mpif77 with gfortran underneath and I'm not able to compile any of the examples of the latest code (which I downloaded today). > > The error is: > > /home/guest/nek5_svn/trunk/nek/navier8.f: In function 'setvert3d': > /home/guest/nek5_svn/trunk/nek/navier8.f:2322: internal compiler error: in expand_expr_real_1, at expr.c:6846 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > make: *** [obj/navier8.o] Error 1 > > However an earlier version of the code which I've been using for a couple of months works fine. Attached is the compiler.out. I've noticed that the input files are slightly different. Do we not need SESSION.NAME any more? > > > Regards, > Mani chandra > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue May 11 05:31:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 12:31:58 +0200 Subject: [Nek5000-users] Compilation failing with gfortran In-Reply-To: <4BE92CA6.1080806@iitk.ac.in> References: <4BE92CA6.1080806@iitk.ac.in> Message-ID: <1273573918.3394.160.camel@localhost.localdomain> Hello Mani, An "internal compiler error" is just that, a problem concerning the compiler. The right step is to submit a detailed bug report to them, after checking that it is repeatable with the latest gfortran. They will fix such problems and sometimes do so quite quickly (from personal experience). While doubtless there is a workaround that the developers could come up with, doing so would most likely be a improper use of their time. The most efficient solution for all concerned is to fix the source of the error and not the symptom. Cheers, Frank On Tue, 2010-05-11 at 15:38 +0530, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I'm using mpif77 with gfortran underneath and I'm not able to > compile any of the examples of the latest code (which I downloaded today). > > The error is: > > /home/guest/nek5_svn/trunk/nek/navier8.f: In function 'setvert3d': > /home/guest/nek5_svn/trunk/nek/navier8.f:2322: internal compiler error: > in expand_expr_real_1, at expr.c:6846 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > make: *** [obj/navier8.o] Error 1 > > However an earlier version of the code which I've been using for a > couple of months works fine. Attached is the compiler.out. I've noticed > that the input files are slightly different. Do we not need SESSION.NAME > any more? > > > Regards, > Mani chandra > _______________________________________________ > 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 Tue May 11 05:30:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 12:30:58 +0200 Subject: [Nek5000-users] perturbing interior variables In-Reply-To: References: <1273496952.3394.135.camel@localhost.localdomain> Message-ID: <1273573858.3394.158.camel@localhost.localdomain> Thanks for the replies, Aleks and Stefan. I am still not clear on one point though. Are changes made to temperature or velocity on boundaries in "userchk" at each time step irrelevant since they are overwritten by calls to "userbc"? Cheers, Frank On Mon, 2010-05-10 at 18:15 +0200, nek5000-users at lists.mcs.anl.gov wrote: > The heat solver calls BCDIRSC which will apply Dirichlet bcs. All 't ' boundary points call userbc so you have the full control over the values at the boundary. > > Stefan > > > > > On May 10, 2010, at 6:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Frank, > > > > > > I assume that you refer to t(i,j,k,iel) as temperature -- to be safe it should be t(i,j,k,iel,1)... > > > > > > In timestepping loop, subroutine userchk is called last by one -- right before the last one -- prepost which dumps field files .f or .fld -- see nek5_svn/trunk/nek/drive1.f: > > > > DO ISTEP=1,NSTEPS > > call nek_advance > > call userchk > > call prepost (.false.,'his') > > if (lastep .eq. 1) goto 1001B > > ENDDO > > > > while, as I can see, userbc for a passive scalar is called from a chain of subroutines nek_advance > heat > cdscal > BCNEUSC/BCDIRSC > > > > This means that perturbation of temperature at the boundary won't be overwritten in userbc. > > > > > > One way to apply perturbation everywhere including the element faces that are not on the boundary of your domain is simply to multiply your perturbation factor by a function that goes to zero on the boundaries, e.g.: > > > > t(i,j,k,iel,1)=.99*t(i,j,k,iel,1)*(xm1(i,j,k,iel)**2.-1.) > > > > in case the boundary surface plane is at x=1 & x=-1 > > > > Best, > > Aleks > > > > > > > > > > > > > > On Mon, 10 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Hello all, > > > > I am trying to perturb the temperature in a small part of the flow. > > However, I only wish to perturb in the interior and not on a boundary. > > I have the following in "userchk". If I instead looped from "k=1,nz1" > > instead of "k=2,nz1-1", would this change the BC's? The general > > question would be, does changing uvw & T in "userchk" change BC's or > > does "userbc" override what is done in "userchk"? > > > > Cheers, > > Frank > > > > do 100 iel=1,nelv > > do 100 k=2,nz1-1 > > do 100 j=2,ny1-1 > > do 100 i=2,nx1-1 > > if(((xm1(i,j,k,iel)-1.1)**2 > > & + (ym1(i,j,k,iel)-1.1)**2 > > & + (zm1(i,j,k,iel)-.45)**2)**.5.le..25)then > > t(i,j,k,iel)=.99*t(i,j,k,iel) > > endif > > enddo !n > > 100 continue > > > > > > > > > > -- > > 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 > > _______________________________________________ > 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 Tue May 11 06:18:19 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 16:48:19 +0530 Subject: [Nek5000-users] [*] Re: Compilation failing with gfortran In-Reply-To: <50168544-3F76-43DA-A5A1-1A2943EFE666@lav.mavt.ethz.ch> References: <4BE92CA6.1080806@iitk.ac.in> <50168544-3F76-43DA-A5A1-1A2943EFE666@lav.mavt.ethz.ch> Message-ID: <4BE93CFB.2040806@iitk.ac.in> Hi, I don't know the revision number but the one I was using did not have the examples benard, conj_ht, fs_hydro, peris, rayleigh and shear4. Is there someway I can get the revision number? Mani chandra On 05/11/2010 04:30 PM, nek5000-users at lists.mcs.anl.gov wrote: > What Nek version did you use before you changed to the latest release? > > Stefan > > On May 11, 2010, at 12:08 PM, nek5000-users at lists.mcs.anl.gov wrote: > > >> Hi, >> >> I'm using mpif77 with gfortran underneath and I'm not able to compile any of the examples of the latest code (which I downloaded today). >> >> The error is: >> >> /home/guest/nek5_svn/trunk/nek/navier8.f: In function 'setvert3d': >> /home/guest/nek5_svn/trunk/nek/navier8.f:2322: internal compiler error: in expand_expr_real_1, at expr.c:6846 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> make: *** [obj/navier8.o] Error 1 >> >> However an earlier version of the code which I've been using for a couple of months works fine. Attached is the compiler.out. I've noticed that the input files are slightly different. Do we not need SESSION.NAME any more? >> >> >> 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 Tue May 11 06:40:02 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 17:10:02 +0530 Subject: [Nek5000-users] [*] Re: Compilation failing with gfortran In-Reply-To: <1273573918.3394.160.camel@localhost.localdomain> References: <4BE92CA6.1080806@iitk.ac.in> <1273573918.3394.160.camel@localhost.localdomain> Message-ID: <4BE94212.6090608@iitk.ac.in> Hi, Good point. I checked with the latest version of gfortran and it worked. Sorry for the bother. Regards, Mani chandra On 05/11/2010 04:01 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Mani, > > An "internal compiler error" is just that, a problem concerning the > compiler. The right step is to submit a detailed bug report to them, > after checking that it is repeatable with the latest gfortran. They > will fix such problems and sometimes do so quite quickly (from personal > experience). While doubtless there is a workaround that the developers > could come up with, doing so would most likely be a improper use of > their time. The most efficient solution for all concerned is to fix the > source of the error and not the symptom. > > Cheers, > Frank > > On Tue, 2010-05-11 at 15:38 +0530, nek5000-users at lists.mcs.anl.gov > wrote: > >> Hi, >> >> I'm using mpif77 with gfortran underneath and I'm not able to >> compile any of the examples of the latest code (which I downloaded today). >> >> The error is: >> >> /home/guest/nek5_svn/trunk/nek/navier8.f: In function 'setvert3d': >> /home/guest/nek5_svn/trunk/nek/navier8.f:2322: internal compiler error: >> in expand_expr_real_1, at expr.c:6846 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> make: *** [obj/navier8.o] Error 1 >> >> However an earlier version of the code which I've been using for a >> couple of months works fine. Attached is the compiler.out. I've noticed >> that the input files are slightly different. Do we not need SESSION.NAME >> any more? >> >> >> Regards, >> Mani chandra >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> From nek5000-users at lists.mcs.anl.gov Tue May 11 06:59:47 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 06:59:47 -0500 (CDT) Subject: [Nek5000-users] perturbing interior variables In-Reply-To: <1273573858.3394.158.camel@localhost.localdomain> References: <1273496952.3394.135.camel@localhost.localdomain> <1273573858.3394.158.camel@localhost.localdomain> Message-ID: Hi Frank, Boundary values will be set by userbc(). There is no opportunity to intercede between userbc() being called and the solver. (In effect, userbc() _is_ the opportunity to intercede.) userchk is called at the end of each step and therefore effectively at the beginning of the next. Perturbing there will work - you can perturb all values and rest assured that values on Dirichlet surfaces will be overwritten by userbc. Values on Neumann surfaces, however, would not be reset by userbc. hth, Paul On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Thanks for the replies, Aleks and Stefan. I am still not clear on one point though. Are changes made to temperature or velocity on boundaries in "userchk" at each time step irrelevant since they are overwritten by calls to "userbc"? Cheers, Frank On Mon, 2010-05-10 at 18:15 +0200, nek5000-users at lists.mcs.anl.gov wrote: > The heat solver calls BCDIRSC which will apply Dirichlet bcs. All 't ' boundary points call userbc so you have the full control over the values at the boundary. > > Stefan > > > > > On May 10, 2010, at 6:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Frank, > > > > > > I assume that you refer to t(i,j,k,iel) as temperature -- to be safe it should be t(i,j,k,iel,1)... > > > > > > In timestepping loop, subroutine userchk is called last by one -- right before the last one -- prepost which dumps field files .f or .fld -- see nek5_svn/trunk/nek/drive1.f: > > > > DO ISTEP=1,NSTEPS > > call nek_advance > > call userchk > > call prepost (.false.,'his') > > if (lastep .eq. 1) goto 1001B > > ENDDO > > > > while, as I can see, userbc for a passive scalar is called from a chain of subroutines nek_advance > heat > cdscal > BCNEUSC/BCDIRSC > > > > This means that perturbation of temperature at the boundary won't be overwritten in userbc. > > > > > > One way to apply perturbation everywhere including the element faces that are not on the boundary of your domain is simply to multiply your perturbation factor by a function that goes to zero on the boundaries, e.g.: > > > > t(i,j,k,iel,1)=.99*t(i,j,k,iel,1)*(xm1(i,j,k,iel)**2.-1.) > > > > in case the boundary surface plane is at x=1 & x=-1 > > > > Best, > > Aleks > > > > > > > > > > > > > > On Mon, 10 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Hello all, > > > > I am trying to perturb the temperature in a small part of the flow. > > However, I only wish to perturb in the interior and not on a boundary. > > I have the following in "userchk". If I instead looped from "k=1,nz1" > > instead of "k=2,nz1-1", would this change the BC's? The general > > question would be, does changing uvw & T in "userchk" change BC's or > > does "userbc" override what is done in "userchk"? > > > > Cheers, > > Frank > > > > do 100 iel=1,nelv > > do 100 k=2,nz1-1 > > do 100 j=2,ny1-1 > > do 100 i=2,nx1-1 > > if(((xm1(i,j,k,iel)-1.1)**2 > > & + (ym1(i,j,k,iel)-1.1)**2 > > & + (zm1(i,j,k,iel)-.45)**2)**.5.le..25)then > > t(i,j,k,iel)=.99*t(i,j,k,iel) > > endif > > enddo !n > > 100 continue > > > > > > > > > > -- > > 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 > > _______________________________________________ > 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 Tue May 11 07:06:02 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 14:06:02 +0200 Subject: [Nek5000-users] [*] Re: Compilation failing with gfortran In-Reply-To: <4BE93CFB.2040806@iitk.ac.in> References: <4BE92CA6.1080806@iitk.ac.in> <50168544-3F76-43DA-A5A1-1A2943EFE666@lav.mavt.ethz.ch> <4BE93CFB.2040806@iitk.ac.in> Message-ID: <41521B02-C405-4E08-A56F-AAC3ACBE7849@lav.mavt.ethz.ch> svn info On May 11, 2010, at 1:18 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I don't know the revision number but the one I was using did not have the examples benard, conj_ht, fs_hydro, peris, rayleigh and shear4. Is there someway I can get the revision number? > > Mani chandra > On 05/11/2010 04:30 PM, nek5000-users at lists.mcs.anl.gov wrote: >> What Nek version did you use before you changed to the latest release? >> >> Stefan >> >> On May 11, 2010, at 12:08 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> >>> Hi, >>> >>> I'm using mpif77 with gfortran underneath and I'm not able to compile any of the examples of the latest code (which I downloaded today). >>> >>> The error is: >>> >>> /home/guest/nek5_svn/trunk/nek/navier8.f: In function 'setvert3d': >>> /home/guest/nek5_svn/trunk/nek/navier8.f:2322: internal compiler error: in expand_expr_real_1, at expr.c:6846 >>> Please submit a full bug report, >>> with preprocessed source if appropriate. >>> See for instructions. >>> make: *** [obj/navier8.o] Error 1 >>> >>> However an earlier version of the code which I've been using for a couple of months works fine. Attached is the compiler.out. I've noticed that the input files are slightly different. Do we not need SESSION.NAME any more? >>> >>> >>> 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 May 11 07:38:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 07:38:27 -0500 (CDT) Subject: [Nek5000-users] perturbing interior variables In-Reply-To: References: <1273496952.3394.135.camel@localhost.localdomain> <1273573858.3394.158.camel@localhost.localdomain> Message-ID: Hi Frank, One additional note. It's important that your perturbed T() be continuous. This could be done, e.g., via the following code in userchk if (istep.eq.0) then n=nx1*ny1*nz1*nelt do i=1,n t(i,1,1,1,1) = t(i,1,1,1,1) + perturbation of choice enddo call dsavg(t) endif The dsavg() will ensure that T is continuous. If T is not continuous at the beginning, it will be discontinous forever since we only solve for delta T and then add this to T. Paul On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Frank, > > Boundary values will be set by userbc(). > > There is no opportunity to intercede between userbc() being called > and the solver. (In effect, userbc() _is_ the opportunity to > intercede.) > > userchk is called at the end of each step and therefore effectively > at the beginning of the next. Perturbing there will work - you can > perturb all values and rest assured that values on Dirichlet surfaces > will be overwritten by userbc. Values on Neumann surfaces, however, > would not be reset by userbc. > > hth, > > Paul > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Thanks for the replies, Aleks and Stefan. I am still not clear on one > point though. Are changes made to temperature or velocity on boundaries > in "userchk" at each time step irrelevant since they are overwritten by > calls to "userbc"? > > Cheers, > Frank > > > On Mon, 2010-05-10 at 18:15 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> The heat solver calls BCDIRSC which will apply Dirichlet bcs. All 't ' >> boundary points call userbc so you have the full control over the values at >> the boundary. >> >> Stefan >> >> >> >> >> On May 10, 2010, at 6:00 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> > Hi Frank, >> > > > I assume that you refer to t(i,j,k,iel) as temperature -- to be safe >> it should be t(i,j,k,iel,1)... >> > > > In timestepping loop, subroutine userchk is called last by one -- >> right before the last one -- prepost which dumps field files .f or .fld -- >> see nek5_svn/trunk/nek/drive1.f: >> > > DO ISTEP=1,NSTEPS >> > call nek_advance >> > call userchk >> > call prepost (.false.,'his') >> > if (lastep .eq. 1) goto 1001B >> > ENDDO >> > > while, as I can see, userbc for a passive scalar is called from a chain >> of subroutines nek_advance > heat > cdscal > BCNEUSC/BCDIRSC >> > > This means that perturbation of temperature at the boundary won't be >> overwritten in userbc. >> > > > One way to apply perturbation everywhere including the element faces >> that are not on the boundary of your domain is simply to multiply your >> perturbation factor by a function that goes to zero on the boundaries, >> e.g.: >> > > t(i,j,k,iel,1)=.99*t(i,j,k,iel,1)*(xm1(i,j,k,iel)**2.-1.) >> > > in case the boundary surface plane is at x=1 & x=-1 >> > > Best, >> > Aleks >> > > > > > > > On Mon, 10 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >> > >> Hello all, >> > > I am trying to perturb the temperature in a small part of the flow. >> > However, I only wish to perturb in the interior and not on a boundary. >> > I have the following in "userchk". If I instead looped from "k=1,nz1" >> > instead of "k=2,nz1-1", would this change the BC's? The general >> > question would be, does changing uvw & T in "userchk" change BC's or >> > does "userbc" override what is done in "userchk"? >> > > Cheers, >> > Frank >> > > do 100 iel=1,nelv >> > do 100 k=2,nz1-1 >> > do 100 j=2,ny1-1 >> > do 100 i=2,nx1-1 >> > if(((xm1(i,j,k,iel)-1.1)**2 >> > & + (ym1(i,j,k,iel)-1.1)**2 >> > & + (zm1(i,j,k,iel)-.45)**2)**.5.le..25)then >> > t(i,j,k,iel)=.99*t(i,j,k,iel) >> > endif >> > enddo !n >> > 100 continue >> > > > > > -- > 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 >> >> _______________________________________________ >> 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 Tue May 11 08:16:28 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 09:16:28 -0400 Subject: [Nek5000-users] New code+recycling BC In-Reply-To: <996888BA-3BDB-4FFA-BEDA-6E86261F80DA@lav.mavt.ethz.ch> References: <4BDEDCC8.4050207@vt.edu> <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> <1273012756.4be0a2146ad1e@webmail.vt.edu> <996888BA-3BDB-4FFA-BEDA-6E86261F80DA@lav.mavt.ethz.ch> Message-ID: <4BE958AC.9060000@vt.edu> Hi, thanks for the update. I looked at the jet example and can't quite figure out what to change such that my case works with the new code. My domain has a box consisting of 9 elements in the "periodic" x-direction, 12 elements in y and 8 elements in z. The inflow is the y/z plane. The numbering is such that the first periodic slab is from element 1 (inflow) to 9, then 10 to 19, ... 12 times (in y) to 100-108. Then all other elements (the "non-periodic" part) follow, which are a total of 444 per x/y plane. Thus, the next 12 slabs (at the second level in z) would start with 445-453, 454-462, ...12 times, and so forth. Here is the part that is giving me trouble, since I don't know what to assign for n_in_pipe and ne_per_slab. c Connect slab next to the last with inflow (recycling method) if(istep.eq.0) then call izero(glo_num,n) do e=1,nelv eg = lglel(e) if (eg.le.n_in_pipe) then do j=1,nx1*ny1 ! Only on FACE 5 (inflow) iloc = j + nxyz*(e -1) glo_num(iloc) = j + nxyz*(eg-1) ieshift = eg + (nslab-1)*ne_per_slab ishift = j + nxyz*(ieshift-1) if (eg.le.ne_per_slab) glo_num(iloc) = ishift enddo endif enddo call gs_setup(gs_bc_hndl,glo_num,n,nekcomm,mp) endif Thanks, Markus nek5000-users at lists.mcs.anl.gov wrote: > Hi Markus, > > yes we changed glo_num to be an 8-byte integer array. Unfortunately we did not update the examples. I'll update the turbJet example. > > Stefan > > > On May 5, 2010, at 12:39 AM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hiu, >> >> sorry about the delay, to make sure I regenerated the problem. >> >> I did as you suggested, it is still messed up when opening the first fld dump in >> VisIt with the meta file containing only one file. >> >> What I meant by element ordering is the way the recycling b.c. is set up, where >> the "outflow" face of recycling box is established by counting a number of >> elements downstream from the inflow, as it is done in the jet example. I have a >> suspicion that something changed there (not in my .rea file, though). >> The problem came about when updating Nek from 404 to 503, I did not change >> Visit. >> >> Thanks, >> Markus >> >> >> >> Quoting nek5000-users at lists.mcs.anl.gov: >> >>> Can you dump a field file including the geometry and then visualize it using >>> VisIt (your metadata file should only contain one single fld). Is it still >>> messed up? >>> >>> Stefan >>> >>> >>> On May 3, 2010, at 5:24 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Markus, >>>> >>>> is it only a viz issue or do you have some problems in Nek after upgrading >>> to the latest release. >>>> Stefan >>>> >>>> >>>> On May 3, 2010, at 4:25 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi, >>>>> >>>>> when updating the code from rev. 404 (oldvel.png) to 503 >>>>> (newvel.png), I realized a problem with the recycling >>>>> (periodic) boundary condition for a channel simulation I am doing - >>>>> compare the attached pictures of velocity on the inflow plane (the inflow >>> is the Y/Z plane). For the two cases, SIZE/SIZEu, .rea, the restart step and >>> .usr are the exact same. >>>>> Here are the relevant pieces from .usr. Have any of the functions >>>>> changed or am I doing something wrong? It seems as if the element >>>>> ordering is not what it was before. >>>>> I did this based on the jet example. >>>>> >>>>> Thanks, >>>>> Markus >>>>> >>>>> >>>>> c----------------------------------------------------------------------- >>>>> subroutine userbc (ix,iy,iz,iside,eg) >>>>> include 'SIZE' >>>>> include 'TOTAL' >>>>> include 'NEKUSE' >>>>> >>>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>>> $ , vin(lx1,ly1,lz1,lelv) >>>>> $ , win(lx1,ly1,lz1,lelv) >>>>> $ , tin(lx1,ly1,lz1,lelv) >>>>> >>>>> integer e,eg >>>>> >>>>> e = gllel(eg) >>>>> >>>>> ux=uin(ix,iy,iz,e) >>>>> uy=vin(ix,iy,iz,e) >>>>> uz=win(ix,iy,iz,e) >>>>> . >>>>> .... >>>>> >>>>> c----------------------------------------------------------------------- >>>>> subroutine userchk >>>>> include 'SIZE' >>>>> include 'TOTAL' >>>>> include 'ZPER' ! for nelx,nely,nelz >>>>> include 'RESTART' !Needs to be here for prepost to work >>>>> common /cvlmsk/ vlmsk(lx1,ly1,lz1,lelt),vvol, >>>>> & wt(lx1*ly1*lz1,lelt),vol_per >>>>> >>>>> integer e,f,eg,ninx,niny,ninz >>>>> >>>>> .c-----Computations for recycling BC >>>>> speed = glsc2(vx,wt,n)/vol_per ! Where vol_per is the volume of >>>>> the recycling box >>>>> starg = 1.0 >>>>> addtemp = 1.0 >>>>> call set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>>> . >>>>> .... >>>>> >>>>> c----------------------------------------------------------------------- >>>>> subroutine set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>>> >>>>> include 'SIZE' >>>>> include 'TOTAL' >>>>> >>>>> integer icalld,e,eg,f >>>>> save icalld >>>>> data icalld /0/ >>>>> >>>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>>> $ , vin(lx1,ly1,lz1,lelv) >>>>> $ , win(lx1,ly1,lz1,lelv) >>>>> $ , tin(lx1,ly1,lz1,lelv) >>>>> >>>>> common /scruz/ ptr(lx1,ly1,lz1,lelv) >>>>> integer ptr,gs_bc_hndl >>>>> save gs_bc_hndl >>>>> >>>>> real ratio >>>>> save ratio >>>>> data ratio / 1. / >>>>> >>>>> common /nekmpi/ mid,mp,nekcomm,nekgroup,nekreal >>>>> >>>>> n = nx1*ny1*nz1*nelv >>>>> >>>>> if (icalld.eq.0) then >>>>> icalld = 1 >>>>> nxyz = nx1*ny1*nz1 >>>>> >>>>> do e=1,nelv >>>>> eg = lglel(e) >>>>> eo = nxyz*(eg-1) ! offset >>>>> do i=1,nxyz >>>>> ptr(i,1,1,e) = i+eo >>>>> enddo >>>>> >>>>> do k=2,nz1-1 ! get rid of interior pointers >>>>> do j=2,ny1-1 do i=2,nx1-1 >>>>> ptr(i,j,k,e) = 0 >>>>> enddo >>>>> enddo >>>>> enddo >>>>> >>>>> nface = 2*ndim >>>>> do f=1,nface ! connect inflow to elems downstream >>>>> ioff = nxyz*8 ! 5 elements in X to end of "periodic" sec. >>>>> if (cbc(f,e,1).eq.'v ') then >>>>> call iface_add(ptr,f,e,ioff,nx1,ny1,nz1) >>>>> endif >>>>> enddo >>>>> >>>>> enddo >>>>> >>>>> call gs_setup(gs_bc_hndl,ptr,n,nekcomm,np) ! connect v + >>>>> downstream >>>>> >>>>> endif >>>>> >>>>> call copy(uin,vx,n) >>>>> call copy(vin,vy,n) >>>>> call copy(win,vz,n) >>>>> call copy(tin,t,n) >>>>> >>>>> call col2(uin,v1mask,n) >>>>> call col2(vin,v2mask,n) >>>>> call col2(win,v3mask,n) >>>>> call col2(tin,tmask,n) >>>>> >>>>> call gs_op(gs_bc_hndl,uin,1,1,0) ! 1 ==> + ! uin(inflow) = >>>>> vx(slab_k) >>>>> call gs_op(gs_bc_hndl,vin,1,1,0) ! 1 ==> + >>>>> call gs_op(gs_bc_hndl,win,1,1,0) ! 1 ==> + >>>>> call gs_op(gs_bc_hndl,tin,1,1,0) ! 1 ==> + >>>>> >>>>> if (speed.gt.0) then >>>>> ratio = .5*(starg/speed + ratio) >>>>> call cmult(uin,ratio,n) >>>>> call cmult(vin,ratio,n) >>>>> call cmult(win,ratio,n) >>>>> call cadd(tin,addtemp,n) !Substract added heat >>>>> endif >>>>> >>>>> return >>>>> end >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Tue May 11 09:15:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 16:15:00 +0200 Subject: [Nek5000-users] New code+recycling BC In-Reply-To: <4BE958AC.9060000@vt.edu> References: <4BDEDCC8.4050207@vt.edu> <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> <1273012756.4be0a2146ad1e@webmail.vt.edu> <996888BA-3BDB-4FFA-BEDA-6E86261F80DA@lav.mavt.ethz.ch> <4BE958AC.9060000@vt.edu> Message-ID: <20550D8B-5C41-4F70-A01C-0F100EBAF4F2@lav.mavt.ethz.ch> Hi Markus, we only changed glo_num to be an 8-byte integer. That's it! Stefan On May 11, 2010, at 3:16 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > thanks for the update. I looked at the jet example and can't quite figure out what to change such that my case works with the new code. > > My domain has a box consisting of 9 elements in the "periodic" x-direction, 12 elements in y and 8 elements in z. The inflow is the y/z plane. > The numbering is such that the first periodic slab is from element 1 (inflow) to 9, then 10 to 19, ... 12 times (in y) to 100-108. Then all other elements (the "non-periodic" part) follow, which are a total of 444 per x/y plane. Thus, the next 12 slabs (at the second level in z) would start with 445-453, 454-462, ...12 times, and so forth. > > Here is the part that is giving me trouble, since I don't know what to assign for n_in_pipe and ne_per_slab. > > c Connect slab next to the last with inflow (recycling method) > if(istep.eq.0) then > call izero(glo_num,n) > do e=1,nelv > eg = lglel(e) > if (eg.le.n_in_pipe) then > do j=1,nx1*ny1 ! Only on FACE 5 (inflow) > iloc = j + nxyz*(e -1) > glo_num(iloc) = j + nxyz*(eg-1) > ieshift = eg + (nslab-1)*ne_per_slab > ishift = j + nxyz*(ieshift-1) > if (eg.le.ne_per_slab) glo_num(iloc) = ishift > enddo > endif > enddo > call gs_setup(gs_bc_hndl,glo_num,n,nekcomm,mp) > endif > > Thanks, > Markus > > > > nek5000-users at lists.mcs.anl.gov wrote: >> Hi Markus, >> yes we changed glo_num to be an 8-byte integer array. Unfortunately we did not update the examples. I'll update the turbJet example. >> Stefan >> On May 5, 2010, at 12:39 AM, nek5000-users at lists.mcs.anl.gov wrote: >>> Hiu, >>> >>> sorry about the delay, to make sure I regenerated the problem. >>> >>> I did as you suggested, it is still messed up when opening the first fld dump in >>> VisIt with the meta file containing only one file. >>> >>> What I meant by element ordering is the way the recycling b.c. is set up, where >>> the "outflow" face of recycling box is established by counting a number of >>> elements downstream from the inflow, as it is done in the jet example. I have a >>> suspicion that something changed there (not in my .rea file, though). >>> The problem came about when updating Nek from 404 to 503, I did not change >>> Visit. >>> >>> Thanks, >>> Markus >>> >>> >>> >>> Quoting nek5000-users at lists.mcs.anl.gov: >>> >>>> Can you dump a field file including the geometry and then visualize it using >>>> VisIt (your metadata file should only contain one single fld). Is it still >>>> messed up? >>>> >>>> Stefan >>>> >>>> >>>> On May 3, 2010, at 5:24 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Markus, >>>>> >>>>> is it only a viz issue or do you have some problems in Nek after upgrading >>>> to the latest release. >>>>> Stefan >>>>> >>>>> >>>>> On May 3, 2010, at 4:25 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> when updating the code from rev. 404 (oldvel.png) to 503 >>>>>> (newvel.png), I realized a problem with the recycling >>>>>> (periodic) boundary condition for a channel simulation I am doing - >>>>>> compare the attached pictures of velocity on the inflow plane (the inflow >>>> is the Y/Z plane). For the two cases, SIZE/SIZEu, .rea, the restart step and >>>> .usr are the exact same. >>>>>> Here are the relevant pieces from .usr. Have any of the functions >>>>>> changed or am I doing something wrong? It seems as if the element >>>>>> ordering is not what it was before. >>>>>> I did this based on the jet example. >>>>>> >>>>>> Thanks, >>>>>> Markus >>>>>> >>>>>> >>>>>> c----------------------------------------------------------------------- >>>>>> subroutine userbc (ix,iy,iz,iside,eg) >>>>>> include 'SIZE' >>>>>> include 'TOTAL' >>>>>> include 'NEKUSE' >>>>>> >>>>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>>>> $ , vin(lx1,ly1,lz1,lelv) >>>>>> $ , win(lx1,ly1,lz1,lelv) >>>>>> $ , tin(lx1,ly1,lz1,lelv) >>>>>> >>>>>> integer e,eg >>>>>> >>>>>> e = gllel(eg) >>>>>> >>>>>> ux=uin(ix,iy,iz,e) >>>>>> uy=vin(ix,iy,iz,e) >>>>>> uz=win(ix,iy,iz,e) >>>>>> . >>>>>> .... >>>>>> >>>>>> c----------------------------------------------------------------------- >>>>>> subroutine userchk >>>>>> include 'SIZE' >>>>>> include 'TOTAL' >>>>>> include 'ZPER' ! for nelx,nely,nelz >>>>>> include 'RESTART' !Needs to be here for prepost to work >>>>>> common /cvlmsk/ vlmsk(lx1,ly1,lz1,lelt),vvol, >>>>>> & wt(lx1*ly1*lz1,lelt),vol_per >>>>>> >>>>>> integer e,f,eg,ninx,niny,ninz >>>>>> >>>>>> .c-----Computations for recycling BC >>>>>> speed = glsc2(vx,wt,n)/vol_per ! Where vol_per is the volume of >>>>>> the recycling box >>>>>> starg = 1.0 >>>>>> addtemp = 1.0 >>>>>> call set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>>>> . >>>>>> .... >>>>>> >>>>>> c----------------------------------------------------------------------- >>>>>> subroutine set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>>>> >>>>>> include 'SIZE' >>>>>> include 'TOTAL' >>>>>> >>>>>> integer icalld,e,eg,f >>>>>> save icalld >>>>>> data icalld /0/ >>>>>> >>>>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>>>> $ , vin(lx1,ly1,lz1,lelv) >>>>>> $ , win(lx1,ly1,lz1,lelv) >>>>>> $ , tin(lx1,ly1,lz1,lelv) >>>>>> >>>>>> common /scruz/ ptr(lx1,ly1,lz1,lelv) >>>>>> integer ptr,gs_bc_hndl >>>>>> save gs_bc_hndl >>>>>> >>>>>> real ratio >>>>>> save ratio >>>>>> data ratio / 1. / >>>>>> >>>>>> common /nekmpi/ mid,mp,nekcomm,nekgroup,nekreal >>>>>> >>>>>> n = nx1*ny1*nz1*nelv >>>>>> >>>>>> if (icalld.eq.0) then >>>>>> icalld = 1 >>>>>> nxyz = nx1*ny1*nz1 >>>>>> >>>>>> do e=1,nelv >>>>>> eg = lglel(e) >>>>>> eo = nxyz*(eg-1) ! offset >>>>>> do i=1,nxyz >>>>>> ptr(i,1,1,e) = i+eo >>>>>> enddo >>>>>> >>>>>> do k=2,nz1-1 ! get rid of interior pointers >>>>>> do j=2,ny1-1 do i=2,nx1-1 >>>>>> ptr(i,j,k,e) = 0 >>>>>> enddo >>>>>> enddo >>>>>> enddo >>>>>> >>>>>> nface = 2*ndim >>>>>> do f=1,nface ! connect inflow to elems downstream >>>>>> ioff = nxyz*8 ! 5 elements in X to end of "periodic" sec. >>>>>> if (cbc(f,e,1).eq.'v ') then >>>>>> call iface_add(ptr,f,e,ioff,nx1,ny1,nz1) >>>>>> endif >>>>>> enddo >>>>>> >>>>>> enddo >>>>>> >>>>>> call gs_setup(gs_bc_hndl,ptr,n,nekcomm,np) ! connect v + >>>>>> downstream >>>>>> >>>>>> endif >>>>>> >>>>>> call copy(uin,vx,n) >>>>>> call copy(vin,vy,n) >>>>>> call copy(win,vz,n) >>>>>> call copy(tin,t,n) >>>>>> >>>>>> call col2(uin,v1mask,n) >>>>>> call col2(vin,v2mask,n) >>>>>> call col2(win,v3mask,n) >>>>>> call col2(tin,tmask,n) >>>>>> >>>>>> call gs_op(gs_bc_hndl,uin,1,1,0) ! 1 ==> + ! uin(inflow) = >>>>>> vx(slab_k) >>>>>> call gs_op(gs_bc_hndl,vin,1,1,0) ! 1 ==> + >>>>>> call gs_op(gs_bc_hndl,win,1,1,0) ! 1 ==> + >>>>>> call gs_op(gs_bc_hndl,tin,1,1,0) ! 1 ==> + >>>>>> >>>>>> if (speed.gt.0) then >>>>>> ratio = .5*(starg/speed + ratio) >>>>>> call cmult(uin,ratio,n) >>>>>> call cmult(vin,ratio,n) >>>>>> call cmult(win,ratio,n) >>>>>> call cadd(tin,addtemp,n) !Substract added heat >>>>>> endif >>>>>> >>>>>> return >>>>>> end >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Tue May 11 09:22:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 09:22:48 -0500 (CDT) Subject: [Nek5000-users] New code+recycling BC In-Reply-To: <4BE958AC.9060000@vt.edu> References: <4BDEDCC8.4050207@vt.edu> <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> <1273012756.4be0a2146ad1e@webmail.vt.edu> <996888BA-3BDB-4FFA-BEDA-6E86261F80DA@lav.mavt.ethz.ch> <4BE958AC.9060000@vt.edu> Message-ID: Hi Markus, izero(glo_num,n) should be rewritten as a loop, since glo_num is int8 but izero is looking for i4. Also, if glo_num is declared locally in that routine, it needs to be updated to integer*8. And, finally, if you anticipate more than 2 billion points (total) then ishift and nxyz should be declared to be integer*8 Thanks for bringing this to my attention - I can see that I need to do the same in my codes. Paul On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > thanks for the update. I looked at the jet example and can't quite figure out > what to change such that my case works with the new code. > > My domain has a box consisting of 9 elements in the "periodic" x-direction, > 12 elements in y and 8 elements in z. The inflow is the y/z plane. > The numbering is such that the first periodic slab is from element 1 (inflow) > to 9, then 10 to 19, ... 12 times (in y) to 100-108. Then all other elements > (the "non-periodic" part) follow, which are a total of 444 per x/y plane. > Thus, the next 12 slabs (at the second level in z) would start with 445-453, > 454-462, ...12 times, and so forth. > > Here is the part that is giving me trouble, since I don't know what to assign > for n_in_pipe and ne_per_slab. > > c Connect slab next to the last with inflow (recycling method) > if(istep.eq.0) then > call izero(glo_num,n) > do e=1,nelv > eg = lglel(e) > if (eg.le.n_in_pipe) then > do j=1,nx1*ny1 ! Only on FACE 5 (inflow) > iloc = j + nxyz*(e -1) > glo_num(iloc) = j + nxyz*(eg-1) > ieshift = eg + (nslab-1)*ne_per_slab > ishift = j + nxyz*(ieshift-1) > if (eg.le.ne_per_slab) glo_num(iloc) = ishift > enddo > endif > enddo > call gs_setup(gs_bc_hndl,glo_num,n,nekcomm,mp) > endif > > Thanks, > Markus > > > > nek5000-users at lists.mcs.anl.gov wrote: >> Hi Markus, >> >> yes we changed glo_num to be an 8-byte integer array. Unfortunately we did >> not update the examples. I'll update the turbJet example. >> >> Stefan >> >> >> On May 5, 2010, at 12:39 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hiu, >>> >>> sorry about the delay, to make sure I regenerated the problem. >>> >>> I did as you suggested, it is still messed up when opening the first fld >>> dump in >>> VisIt with the meta file containing only one file. >>> >>> What I meant by element ordering is the way the recycling b.c. is set up, >>> where >>> the "outflow" face of recycling box is established by counting a number of >>> elements downstream from the inflow, as it is done in the jet example. I >>> have a >>> suspicion that something changed there (not in my .rea file, though). >>> The problem came about when updating Nek from 404 to 503, I did not change >>> Visit. >>> >>> Thanks, >>> Markus >>> >>> >>> >>> Quoting nek5000-users at lists.mcs.anl.gov: >>> >>>> Can you dump a field file including the geometry and then visualize it >>>> using >>>> VisIt (your metadata file should only contain one single fld). Is it >>>> still >>>> messed up? >>>> >>>> Stefan >>>> >>>> >>>> On May 3, 2010, at 5:24 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Markus, >>>>> >>>>> is it only a viz issue or do you have some problems in Nek after >>>>> upgrading >>>> to the latest release. >>>>> Stefan >>>>> >>>>> >>>>> On May 3, 2010, at 4:25 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> when updating the code from rev. 404 (oldvel.png) to 503 >>>>>> (newvel.png), I realized a problem with the recycling >>>>>> (periodic) boundary condition for a channel simulation I am doing - >>>>>> compare the attached pictures of velocity on the inflow plane (the >>>>>> inflow >>>> is the Y/Z plane). For the two cases, SIZE/SIZEu, .rea, the restart step >>>> and >>>> .usr are the exact same. >>>>>> Here are the relevant pieces from .usr. Have any of the functions >>>>>> changed or am I doing something wrong? It seems as if the element >>>>>> ordering is not what it was before. >>>>>> I did this based on the jet example. >>>>>> >>>>>> Thanks, >>>>>> Markus >>>>>> >>>>>> >>>>>> c----------------------------------------------------------------------- >>>>>> subroutine userbc (ix,iy,iz,iside,eg) >>>>>> include 'SIZE' >>>>>> include 'TOTAL' >>>>>> include 'NEKUSE' >>>>>> >>>>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>>>> $ , vin(lx1,ly1,lz1,lelv) >>>>>> $ , win(lx1,ly1,lz1,lelv) >>>>>> $ , tin(lx1,ly1,lz1,lelv) >>>>>> >>>>>> integer e,eg >>>>>> >>>>>> e = gllel(eg) >>>>>> >>>>>> ux=uin(ix,iy,iz,e) >>>>>> uy=vin(ix,iy,iz,e) >>>>>> uz=win(ix,iy,iz,e) >>>>>> . >>>>>> .... >>>>>> >>>>>> c----------------------------------------------------------------------- >>>>>> subroutine userchk >>>>>> include 'SIZE' >>>>>> include 'TOTAL' >>>>>> include 'ZPER' ! for nelx,nely,nelz >>>>>> include 'RESTART' !Needs to be here for prepost to work >>>>>> common /cvlmsk/ vlmsk(lx1,ly1,lz1,lelt),vvol, >>>>>> & wt(lx1*ly1*lz1,lelt),vol_per >>>>>> >>>>>> integer e,f,eg,ninx,niny,ninz >>>>>> >>>>>> .c-----Computations for recycling BC >>>>>> speed = glsc2(vx,wt,n)/vol_per ! Where vol_per is the volume of >>>>>> the recycling box >>>>>> starg = 1.0 >>>>>> addtemp = 1.0 >>>>>> call set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>>>> . >>>>>> .... >>>>>> >>>>>> c----------------------------------------------------------------------- >>>>>> subroutine set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>>>> >>>>>> include 'SIZE' >>>>>> include 'TOTAL' >>>>>> >>>>>> integer icalld,e,eg,f >>>>>> save icalld >>>>>> data icalld /0/ >>>>>> >>>>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>>>> $ , vin(lx1,ly1,lz1,lelv) >>>>>> $ , win(lx1,ly1,lz1,lelv) >>>>>> $ , tin(lx1,ly1,lz1,lelv) >>>>>> >>>>>> common /scruz/ ptr(lx1,ly1,lz1,lelv) >>>>>> integer ptr,gs_bc_hndl >>>>>> save gs_bc_hndl >>>>>> >>>>>> real ratio >>>>>> save ratio >>>>>> data ratio / 1. / >>>>>> >>>>>> common /nekmpi/ mid,mp,nekcomm,nekgroup,nekreal >>>>>> >>>>>> n = nx1*ny1*nz1*nelv >>>>>> >>>>>> if (icalld.eq.0) then >>>>>> icalld = 1 >>>>>> nxyz = nx1*ny1*nz1 >>>>>> >>>>>> do e=1,nelv >>>>>> eg = lglel(e) >>>>>> eo = nxyz*(eg-1) ! offset >>>>>> do i=1,nxyz >>>>>> ptr(i,1,1,e) = i+eo >>>>>> enddo >>>>>> >>>>>> do k=2,nz1-1 ! get rid of interior pointers >>>>>> do j=2,ny1-1 do i=2,nx1-1 >>>>>> ptr(i,j,k,e) = 0 >>>>>> enddo >>>>>> enddo >>>>>> enddo >>>>>> >>>>>> nface = 2*ndim >>>>>> do f=1,nface ! connect inflow to elems downstream >>>>>> ioff = nxyz*8 ! 5 elements in X to end of "periodic" >>>>>> sec. >>>>>> if (cbc(f,e,1).eq.'v ') then >>>>>> call iface_add(ptr,f,e,ioff,nx1,ny1,nz1) >>>>>> endif >>>>>> enddo >>>>>> >>>>>> enddo >>>>>> >>>>>> call gs_setup(gs_bc_hndl,ptr,n,nekcomm,np) ! connect v + >>>>>> downstream >>>>>> >>>>>> endif >>>>>> >>>>>> call copy(uin,vx,n) >>>>>> call copy(vin,vy,n) >>>>>> call copy(win,vz,n) >>>>>> call copy(tin,t,n) >>>>>> >>>>>> call col2(uin,v1mask,n) >>>>>> call col2(vin,v2mask,n) >>>>>> call col2(win,v3mask,n) >>>>>> call col2(tin,tmask,n) >>>>>> >>>>>> call gs_op(gs_bc_hndl,uin,1,1,0) ! 1 ==> + ! uin(inflow) = >>>>>> vx(slab_k) >>>>>> call gs_op(gs_bc_hndl,vin,1,1,0) ! 1 ==> + >>>>>> call gs_op(gs_bc_hndl,win,1,1,0) ! 1 ==> + >>>>>> call gs_op(gs_bc_hndl,tin,1,1,0) ! 1 ==> + >>>>>> >>>>>> if (speed.gt.0) then >>>>>> ratio = .5*(starg/speed + ratio) >>>>>> call cmult(uin,ratio,n) >>>>>> call cmult(vin,ratio,n) >>>>>> call cmult(win,ratio,n) >>>>>> call cadd(tin,addtemp,n) !Substract added heat >>>>>> endif >>>>>> >>>>>> return >>>>>> end >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Tue May 11 11:20:24 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 18:20:24 +0200 Subject: [Nek5000-users] problem with closed internal boundaries Message-ID: <5313C3E0D03CB044A289CAC54D804C120157D55BF78D@BVMBX1.univ-lyon1.fr> Hello Neks, I'm trying to model a flow past an obstacle in a channel. As a first step I would like to do a 2D simulation. I'm encountering some problems during the geometry data generation in the nek5000 execution : it looks like the program can only generate NaN values although genmap seems to work well on the .rea file. I can also reopen the rea file with prenek without any problems. Do you have any idea what is going wrong here? Is it problematic to have a closed internal boundary condition? Thanks in advance for any help. Best, Michael B -------------- next part -------------- A non-text attachment was scrubbed... Name: cylonly.rea Type: application/octet-stream Size: 8928 bytes Desc: cylonly.rea URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cylonly.usr Type: application/octet-stream Size: 2801 bytes Desc: cylonly.usr URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: out Type: application/octet-stream Size: 13745 bytes Desc: out URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cylonly.map Type: application/octet-stream Size: 526 bytes Desc: cylonly.map URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SIZE Type: application/octet-stream Size: 2873 bytes Desc: SIZE URL: From nek5000-users at lists.mcs.anl.gov Tue May 11 13:31:10 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 20:31:10 +0200 Subject: [Nek5000-users] problem with closed internal boundaries In-Reply-To: <5313C3E0D03CB044A289CAC54D804C120157D55BF78D@BVMBX1.univ-lyon1.fr> References: <5313C3E0D03CB044A289CAC54D804C120157D55BF78D@BVMBX1.univ-lyon1.fr> Message-ID: <1273602670.3394.200.camel@localhost.localdomain> Hello Michael, I am by no means knowledgeable concerning NEK, but will put my two-cents in by saying that I believe that all dimensions in the z-direction must be 1. However, you have "parameter (lz2=lz1-2)" and "parameter (lz3=lz2)". Cheers, Frank On Tue, 2010-05-11 at 18:20 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hello Neks, > > I'm trying to model a flow past an obstacle in a channel. As a first step I would like to do a 2D simulation. > I'm encountering some problems during the geometry data generation in the nek5000 execution : it looks like the program can only generate NaN values although genmap seems to work well on the .rea file. > I can also reopen the rea file with prenek without any problems. > > Do you have any idea what is going wrong here? > Is it problematic to have a closed internal boundary condition? > Thanks in advance for any help. > > Best, > > > Michael B > _______________________________________________ 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 Tue May 11 13:57:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 20:57:11 +0200 Subject: [Nek5000-users] RE : problem with closed internal boundaries In-Reply-To: <1273602670.3394.200.camel@localhost.localdomain> References: <5313C3E0D03CB044A289CAC54D804C120157D55BF78D@BVMBX1.univ-lyon1.fr>, <1273602670.3394.200.camel@localhost.localdomain> Message-ID: <5313C3E0D03CB044A289CAC54D804C120157D55BF78E@BVMBX1.univ-lyon1.fr> Hello Frank, thanks for the quick answer. The Nek team should be relieved that the community is growing and that some users start to be able to help the newbies. I tried what you recommended and now that you've said it, it looks obvious that all the z parameters should be 1 for a 2D case, but this isn't changing a thing. I still get those NaNs. Do you have any other idea? Best, Michael ________________________________________ 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 : mardi 11 mai 2010 20:31 ? : nek5000-users at lists.mcs.anl.gov Objet : Re: [Nek5000-users] problem with closed internal boundaries Hello Michael, I am by no means knowledgeable concerning NEK, but will put my two-cents in by saying that I believe that all dimensions in the z-direction must be 1. However, you have "parameter (lz2=lz1-2)" and "parameter (lz3=lz2)". Cheers, Frank On Tue, 2010-05-11 at 18:20 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hello Neks, > > I'm trying to model a flow past an obstacle in a channel. As a first step I would like to do a 2D simulation. > I'm encountering some problems during the geometry data generation in the nek5000 execution : it looks like the program can only generate NaN values although genmap seems to work well on the .rea file. > I can also reopen the rea file with prenek without any problems. > > Do you have any idea what is going wrong here? > Is it problematic to have a closed internal boundary condition? > Thanks in advance for any help. > > Best, > > > Michael B > _______________________________________________ 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 Tue May 11 14:08:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 21:08:58 +0200 Subject: [Nek5000-users] RE : problem with closed internal boundaries In-Reply-To: <5313C3E0D03CB044A289CAC54D804C120157D55BF78E@BVMBX1.univ-lyon1.fr> References: <5313C3E0D03CB044A289CAC54D804C120157D55BF78D@BVMBX1.univ-lyon1.fr>, <1273602670.3394.200.camel@localhost.localdomain> <5313C3E0D03CB044A289CAC54D804C120157D55BF78E@BVMBX1.univ-lyon1.fr> Message-ID: <51EE531E-220B-42C1-A642-3C62CF84823C@lav.mavt.ethz.ch> Hmm, it's strange that array declarations with a negative lz2 are excepted by the compiler. What compiler do you use? Stefan On May 11, 2010, at 8:57 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Frank, > > thanks for the quick answer. The Nek team should be relieved that the community is growing and that some users start to be able to help the newbies. > I tried what you recommended and now that you've said it, it looks obvious that all the z parameters should be 1 for a 2D case, but this isn't changing a thing. I still get those NaNs. > > Do you have any other idea? > > Best, > > > Michael > ________________________________________ > 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 : mardi 11 mai 2010 20:31 > ? : nek5000-users at lists.mcs.anl.gov > Objet : Re: [Nek5000-users] problem with closed internal boundaries > > Hello Michael, > > I am by no means knowledgeable concerning NEK, but will put my two-cents > in by saying that I believe that all dimensions in the z-direction must > be 1. However, you have "parameter (lz2=lz1-2)" and "parameter > (lz3=lz2)". > > Cheers, > Frank > > > On Tue, 2010-05-11 at 18:20 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Hello Neks, >> >> I'm trying to model a flow past an obstacle in a channel. As a first step I would like to do a 2D simulation. >> I'm encountering some problems during the geometry data generation in the nek5000 execution : it looks like the program can only generate NaN values although genmap seems to work well on the .rea file. >> I can also reopen the rea file with prenek without any problems. >> >> Do you have any idea what is going wrong here? >> Is it problematic to have a closed internal boundary condition? >> Thanks in advance for any help. >> >> Best, >> >> >> Michael B >> _______________________________________________ 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 Tue May 11 14:10:01 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 21:10:01 +0200 Subject: [Nek5000-users] RE : problem with closed internal boundaries In-Reply-To: <5313C3E0D03CB044A289CAC54D804C120157D55BF78E@BVMBX1.univ-lyon1.fr> References: <5313C3E0D03CB044A289CAC54D804C120157D55BF78D@BVMBX1.univ-lyon1.fr> , <1273602670.3394.200.camel@localhost.localdomain> <5313C3E0D03CB044A289CAC54D804C120157D55BF78E@BVMBX1.univ-lyon1.fr> Message-ID: <1273605002.3394.205.camel@localhost.localdomain> Hi Michael, It seems that perhaps your mesh and/or grid mapping is messed up. The numbers concerning your mesh in your "out" file are huge: verify mesh topology 9.90000000000000105E+021 -9.90000000000000105E+021 Xrange 9.90000000000000105E+021 -9.90000000000000105E+021 Yrange 9.90000000000000105E+021 -9.90000000000000105E+021 Zrange done :: verify mesh topology >From one of my simulations: verify mesh topology -1.51515151515152 1.51515151515152 Xrange -1.51515151515152 1.51515151515152 Yrange -0.500000000000000 0.500000000000000 Zrange done :: verify mesh topology Cheers, Frank On Tue, 2010-05-11 at 20:57 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hello Frank, > > thanks for the quick answer. The Nek team should be relieved that the community is growing and that some users start to be able to help the newbies. > I tried what you recommended and now that you've said it, it looks obvious that all the z parameters should be 1 for a 2D case, but this isn't changing a thing. I still get those NaNs. > > Do you have any other idea? > > Best, > > > Michael > ________________________________________ > 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 : mardi 11 mai 2010 20:31 > ? : nek5000-users at lists.mcs.anl.gov > Objet : Re: [Nek5000-users] problem with closed internal boundaries > > Hello Michael, > > I am by no means knowledgeable concerning NEK, but will put my two-cents > in by saying that I believe that all dimensions in the z-direction must > be 1. However, you have "parameter (lz2=lz1-2)" and "parameter > (lz3=lz2)". > > Cheers, > Frank > > > On Tue, 2010-05-11 at 18:20 +0200, nek5000-users at lists.mcs.anl.gov > wrote: > > Hello Neks, > > > > I'm trying to model a flow past an obstacle in a channel. As a first step I would like to do a 2D simulation. > > I'm encountering some problems during the geometry data generation in the nek5000 execution : it looks like the program can only generate NaN values although genmap seems to work well on the .rea file. > > I can also reopen the rea file with prenek without any problems. > > > > Do you have any idea what is going wrong here? > > Is it problematic to have a closed internal boundary condition? > > Thanks in advance for any help. > > > > Best, > > > > > > Michael B > > _______________________________________________ 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 Tue May 11 15:38:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 15:38:03 -0500 (CDT) Subject: [Nek5000-users] g95 and nekton In-Reply-To: <53BD119A-0552-4660-8145-2811ACBEF3D4@mac.com> References: <53BD119A-0552-4660-8145-2811ACBEF3D4@mac.com> Message-ID: Hi Andrew, cc'g to the User's list where many knowledgeable people might have insight... Particularly w.r.t. gfortran on a mac. Paul On Tue, 11 May 2010, Andrew Siegel wrote: > Paul: I give up. Do you know if we have pgf or ifort (intel) compilers that > we can install locally? > If not I'm going to buy a few. Hate having to login and move data just to do > simple runs. From nek5000-users at lists.mcs.anl.gov Tue May 11 16:38:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 23:38:06 +0200 Subject: [Nek5000-users] perturbing interior variables In-Reply-To: References: <1273496952.3394.135.camel@localhost.localdomain> <1273573858.3394.158.camel@localhost.localdomain> Message-ID: <1273613886.27302.5.camel@localhost.localdomain> Hi Paul, I'm not quite sure what you mean here, am assuming you have in mind continuous across element boundaries. At present, some simulations are running where at a certain time, the temperature field is perturbed as in the code segment below. Would the absence of "dsavg" cause a problem regardless of whether one loops from "k=2,nz1-1" or "k=1,nz1" etc.? Also, is "dsavg" needed when dealing with velocity? Cheers, Frank if(time>1. .and. time<= 1.+2.5*dt)then write(*,*)'Symmetry breaking' vmax=.01 ; tmax=.99 ; radius=1.5 ; radius_s=.25 nlocations_perturbed=3 do 100 iel=1,nelv do 100 k=2,nz1-1 do 100 j=2,ny1-1 do 100 i=2,nx1-1 do n=1,nlocations_perturbed angle = acos(-1.)*2.*(n-1.)/nlocations_perturbed x1=radius*cos(angle) ; y1=radius*sin(angle) if(((xm1(i,j,k,iel)-x1)**2 & + (ym1(i,j,k,iel)-y1)**2 & + (zm1(i,j,k,iel)-.45)**2)**.5.le.radius_s)then t(i,j,k,iel,1)=tmax*t(i,j,k,iel,1) endif enddo !n 100 continue endif !time>1. .and. time<= 1.+2.*dt On Tue, 2010-05-11 at 07:38 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > One additional note. > > It's important that your perturbed T() be continuous. > > This could be done, e.g., via the following code in userchk > > if (istep.eq.0) then > n=nx1*ny1*nz1*nelt > do i=1,n > t(i,1,1,1,1) = t(i,1,1,1,1) + perturbation of choice > enddo > call dsavg(t) > endif > > The dsavg() will ensure that T is continuous. If T is not > continuous at the beginning, it will be discontinous forever > since we only solve for delta T and then add this to T. > > > Paul > > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > Hi Frank, > > > > Boundary values will be set by userbc(). > > > > There is no opportunity to intercede between userbc() being called > > and the solver. (In effect, userbc() _is_ the opportunity to > > intercede.) > > > > userchk is called at the end of each step and therefore effectively > > at the beginning of the next. Perturbing there will work - you can > > perturb all values and rest assured that values on Dirichlet surfaces > > will be overwritten by userbc. Values on Neumann surfaces, however, > > would not be reset by userbc. > > > > hth, > > > > Paul > > > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Thanks for the replies, Aleks and Stefan. I am still not clear on one > > point though. Are changes made to temperature or velocity on boundaries > > in "userchk" at each time step irrelevant since they are overwritten by > > calls to "userbc"? > > > > Cheers, > > Frank > > > > > > On Mon, 2010-05-10 at 18:15 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> The heat solver calls BCDIRSC which will apply Dirichlet bcs. All 't ' > >> boundary points call userbc so you have the full control over the values at > >> the boundary. > >> > >> Stefan > >> > >> > >> > >> > >> On May 10, 2010, at 6:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >> > Hi Frank, > >> > > > I assume that you refer to t(i,j,k,iel) as temperature -- to be safe > >> it should be t(i,j,k,iel,1)... > >> > > > In timestepping loop, subroutine userchk is called last by one -- > >> right before the last one -- prepost which dumps field files .f or .fld -- > >> see nek5_svn/trunk/nek/drive1.f: > >> > > DO ISTEP=1,NSTEPS > >> > call nek_advance > >> > call userchk > >> > call prepost (.false.,'his') > >> > if (lastep .eq. 1) goto 1001B > >> > ENDDO > >> > > while, as I can see, userbc for a passive scalar is called from a chain > >> of subroutines nek_advance > heat > cdscal > BCNEUSC/BCDIRSC > >> > > This means that perturbation of temperature at the boundary won't be > >> overwritten in userbc. > >> > > > One way to apply perturbation everywhere including the element faces > >> that are not on the boundary of your domain is simply to multiply your > >> perturbation factor by a function that goes to zero on the boundaries, > >> e.g.: > >> > > t(i,j,k,iel,1)=.99*t(i,j,k,iel,1)*(xm1(i,j,k,iel)**2.-1.) > >> > > in case the boundary surface plane is at x=1 & x=-1 > >> > > Best, > >> > Aleks > >> > > > > > > > On Mon, 10 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> > >> Hello all, > >> > > I am trying to perturb the temperature in a small part of the flow. > >> > However, I only wish to perturb in the interior and not on a boundary. > >> > I have the following in "userchk". If I instead looped from "k=1,nz1" > >> > instead of "k=2,nz1-1", would this change the BC's? The general > >> > question would be, does changing uvw & T in "userchk" change BC's or > >> > does "userbc" override what is done in "userchk"? > >> > > Cheers, > >> > Frank > >> > > do 100 iel=1,nelv > >> > do 100 k=2,nz1-1 > >> > do 100 j=2,ny1-1 > >> > do 100 i=2,nx1-1 > >> > if(((xm1(i,j,k,iel)-1.1)**2 > >> > & + (ym1(i,j,k,iel)-1.1)**2 > >> > & + (zm1(i,j,k,iel)-.45)**2)**.5.le..25)then > >> > t(i,j,k,iel)=.99*t(i,j,k,iel) > >> > endif > >> > enddo !n > >> > 100 continue > >> > > > > > -- > 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 > >> > >> _______________________________________________ > >> 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 Tue May 11 17:14:28 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 17:14:28 -0500 (CDT) Subject: [Nek5000-users] perturbing interior variables In-Reply-To: <1273613886.27302.5.camel@localhost.localdomain> References: <1273496952.3394.135.camel@localhost.localdomain> <1273573858.3394.158.camel@localhost.localdomain> <1273613886.27302.5.camel@localhost.localdomain> Message-ID: Hi Frank, Yes - any function that is supposed to be continuous should be so at timestep 0, else there will be problems. For the Pn-Pn-2 formulation, pressure is discontinuous, so there is no issue for pressure in this case. However, one would call dsavg for vx, vy,vz and T --- This is already done in ic.f following standard initialization procedures. It likely wouldn't need to be done if you range strictly over the element interiors, i,j,k \in [2,...,nx1]^3 --- but it wouldn't hurt in any case. Paul On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, I'm not quite sure what you mean here, am assuming you have in mind continuous across element boundaries. At present, some simulations are running where at a certain time, the temperature field is perturbed as in the code segment below. Would the absence of "dsavg" cause a problem regardless of whether one loops from "k=2,nz1-1" or "k=1,nz1" etc.? Also, is "dsavg" needed when dealing with velocity? Cheers, Frank if(time>1. .and. time<= 1.+2.5*dt)then write(*,*)'Symmetry breaking' vmax=.01 ; tmax=.99 ; radius=1.5 ; radius_s=.25 nlocations_perturbed=3 do 100 iel=1,nelv do 100 k=2,nz1-1 do 100 j=2,ny1-1 do 100 i=2,nx1-1 do n=1,nlocations_perturbed angle = acos(-1.)*2.*(n-1.)/nlocations_perturbed x1=radius*cos(angle) ; y1=radius*sin(angle) if(((xm1(i,j,k,iel)-x1)**2 & + (ym1(i,j,k,iel)-y1)**2 & + (zm1(i,j,k,iel)-.45)**2)**.5.le.radius_s)then t(i,j,k,iel,1)=tmax*t(i,j,k,iel,1) endif enddo !n 100 continue endif !time>1. .and. time<= 1.+2.*dt On Tue, 2010-05-11 at 07:38 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > One additional note. > > It's important that your perturbed T() be continuous. > > This could be done, e.g., via the following code in userchk > > if (istep.eq.0) then > n=nx1*ny1*nz1*nelt > do i=1,n > t(i,1,1,1,1) = t(i,1,1,1,1) + perturbation of choice > enddo > call dsavg(t) > endif > > The dsavg() will ensure that T is continuous. If T is not > continuous at the beginning, it will be discontinous forever > since we only solve for delta T and then add this to T. > > > Paul > > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > Hi Frank, > > > > Boundary values will be set by userbc(). > > > > There is no opportunity to intercede between userbc() being called > > and the solver. (In effect, userbc() _is_ the opportunity to > > intercede.) > > > > userchk is called at the end of each step and therefore effectively > > at the beginning of the next. Perturbing there will work - you can > > perturb all values and rest assured that values on Dirichlet surfaces > > will be overwritten by userbc. Values on Neumann surfaces, however, > > would not be reset by userbc. > > > > hth, > > > > Paul > > > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Thanks for the replies, Aleks and Stefan. I am still not clear on one > > point though. Are changes made to temperature or velocity on boundaries > > in "userchk" at each time step irrelevant since they are overwritten by > > calls to "userbc"? > > > > Cheers, > > Frank > > > > > > On Mon, 2010-05-10 at 18:15 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> The heat solver calls BCDIRSC which will apply Dirichlet bcs. All 't ' > >> boundary points call userbc so you have the full control over the values at > >> the boundary. > >> > >> Stefan > >> > >> > >> > >> > >> On May 10, 2010, at 6:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >> > Hi Frank, > >> > > > I assume that you refer to t(i,j,k,iel) as temperature -- to be safe > >> it should be t(i,j,k,iel,1)... > >> > > > In timestepping loop, subroutine userchk is called last by one -- > >> right before the last one -- prepost which dumps field files .f or .fld -- > >> see nek5_svn/trunk/nek/drive1.f: > >> > > DO ISTEP=1,NSTEPS > >> > call nek_advance > >> > call userchk > >> > call prepost (.false.,'his') > >> > if (lastep .eq. 1) goto 1001B > >> > ENDDO > >> > > while, as I can see, userbc for a passive scalar is called from a chain > >> of subroutines nek_advance > heat > cdscal > BCNEUSC/BCDIRSC > >> > > This means that perturbation of temperature at the boundary won't be > >> overwritten in userbc. > >> > > > One way to apply perturbation everywhere including the element faces > >> that are not on the boundary of your domain is simply to multiply your > >> perturbation factor by a function that goes to zero on the boundaries, > >> e.g.: > >> > > t(i,j,k,iel,1)=.99*t(i,j,k,iel,1)*(xm1(i,j,k,iel)**2.-1.) > >> > > in case the boundary surface plane is at x=1 & x=-1 > >> > > Best, > >> > Aleks > >> > > > > > > > On Mon, 10 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> > >> Hello all, > >> > > I am trying to perturb the temperature in a small part of the flow. > >> > However, I only wish to perturb in the interior and not on a boundary. > >> > I have the following in "userchk". If I instead looped from "k=1,nz1" > >> > instead of "k=2,nz1-1", would this change the BC's? The general > >> > question would be, does changing uvw & T in "userchk" change BC's or > >> > does "userbc" override what is done in "userchk"? > >> > > Cheers, > >> > Frank > >> > > do 100 iel=1,nelv > >> > do 100 k=2,nz1-1 > >> > do 100 j=2,ny1-1 > >> > do 100 i=2,nx1-1 > >> > if(((xm1(i,j,k,iel)-1.1)**2 > >> > & + (ym1(i,j,k,iel)-1.1)**2 > >> > & + (zm1(i,j,k,iel)-.45)**2)**.5.le..25)then > >> > t(i,j,k,iel)=.99*t(i,j,k,iel) > >> > endif > >> > enddo !n > >> > 100 continue > >> > > > > > -- > 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 > >> > >> _______________________________________________ > >> 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 From nek5000-users at lists.mcs.anl.gov Tue May 11 17:20:56 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 12 May 2010 00:20:56 +0200 Subject: [Nek5000-users] perturbing interior variables In-Reply-To: References: <1273496952.3394.135.camel@localhost.localdomain> <1273573858.3394.158.camel@localhost.localdomain> <1273613886.27302.5.camel@localhost.localdomain> Message-ID: <1273616456.27302.11.camel@localhost.localdomain> On Tue, 2010-05-11 at 17:14 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Yes - any function that is supposed to be continuous should be > so at timestep 0, else there will be problems. Hi Paul, But if one is perturbing the velocity and/or temperature not at t=0 but at a later time (in "userchk") then "dsavg" should still be called? Cheers, Frank > > For the Pn-Pn-2 formulation, pressure is discontinuous, so there > is no issue for pressure in this case. > > However, one would call dsavg for vx, vy,vz and T --- > > This is already done in ic.f following standard initialization > procedures. > > It likely wouldn't need to be done if you range strictly over > the element interiors, i,j,k \in [2,...,nx1]^3 --- but it > wouldn't hurt in any case. > > Paul > > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > I'm not quite sure what you mean here, am assuming you have in mind > continuous across element boundaries. At present, some simulations are > running where at a certain time, the temperature field is perturbed as > in the code segment below. Would the absence of "dsavg" cause a problem > regardless of whether one loops from "k=2,nz1-1" or "k=1,nz1" etc.? > Also, is "dsavg" needed when dealing with velocity? > > Cheers, > Frank > > if(time>1. .and. time<= 1.+2.5*dt)then > write(*,*)'Symmetry breaking' > vmax=.01 ; tmax=.99 ; radius=1.5 ; radius_s=.25 > nlocations_perturbed=3 > do 100 iel=1,nelv > do 100 k=2,nz1-1 > do 100 j=2,ny1-1 > do 100 i=2,nx1-1 > do n=1,nlocations_perturbed > angle = acos(-1.)*2.*(n-1.)/nlocations_perturbed > x1=radius*cos(angle) ; y1=radius*sin(angle) > if(((xm1(i,j,k,iel)-x1)**2 > & + (ym1(i,j,k,iel)-y1)**2 > & + (zm1(i,j,k,iel)-.45)**2)**.5.le.radius_s)then > t(i,j,k,iel,1)=tmax*t(i,j,k,iel,1) > endif > enddo !n > 100 continue > endif !time>1. .and. time<= 1.+2.*dt > > > On Tue, 2010-05-11 at 07:38 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Hi Frank, > > > > One additional note. > > > > It's important that your perturbed T() be continuous. > > > > This could be done, e.g., via the following code in userchk > > > > if (istep.eq.0) then > > n=nx1*ny1*nz1*nelt > > do i=1,n > > t(i,1,1,1,1) = t(i,1,1,1,1) + perturbation of choice > > enddo > > call dsavg(t) > > endif > > > > The dsavg() will ensure that T is continuous. If T is not > > continuous at the beginning, it will be discontinous forever > > since we only solve for delta T and then add this to T. > > > > > > Paul > > > > > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > > > > > Hi Frank, > > > > > > Boundary values will be set by userbc(). > > > > > > There is no opportunity to intercede between userbc() being called > > > and the solver. (In effect, userbc() _is_ the opportunity to > > > intercede.) > > > > > > userchk is called at the end of each step and therefore effectively > > > at the beginning of the next. Perturbing there will work - you can > > > perturb all values and rest assured that values on Dirichlet surfaces > > > will be overwritten by userbc. Values on Neumann surfaces, however, > > > would not be reset by userbc. > > > > > > hth, > > > > > > Paul > > > > > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > >> Thanks for the replies, Aleks and Stefan. I am still not clear on one > > > point though. Are changes made to temperature or velocity on boundaries > > > in "userchk" at each time step irrelevant since they are overwritten by > > > calls to "userbc"? > > > > > > Cheers, > > > Frank > > > > > > > > > On Mon, 2010-05-10 at 18:15 +0200, nek5000-users at lists.mcs.anl.gov > > > wrote: > > >> The heat solver calls BCDIRSC which will apply Dirichlet bcs. All 't ' > > >> boundary points call userbc so you have the full control over the values at > > >> the boundary. > > >> > > >> Stefan > > >> > > >> > > >> > > >> > > >> On May 10, 2010, at 6:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > > >> > > >> > Hi Frank, > > >> > > > I assume that you refer to t(i,j,k,iel) as temperature -- to be safe > > >> it should be t(i,j,k,iel,1)... > > >> > > > In timestepping loop, subroutine userchk is called last by one -- > > >> right before the last one -- prepost which dumps field files .f or .fld -- > > >> see nek5_svn/trunk/nek/drive1.f: > > >> > > DO ISTEP=1,NSTEPS > > >> > call nek_advance > > >> > call userchk > > >> > call prepost (.false.,'his') > > >> > if (lastep .eq. 1) goto 1001B > > >> > ENDDO > > >> > > while, as I can see, userbc for a passive scalar is called from a chain > > >> of subroutines nek_advance > heat > cdscal > BCNEUSC/BCDIRSC > > >> > > This means that perturbation of temperature at the boundary won't be > > >> overwritten in userbc. > > >> > > > One way to apply perturbation everywhere including the element faces > > >> that are not on the boundary of your domain is simply to multiply your > > >> perturbation factor by a function that goes to zero on the boundaries, > > >> e.g.: > > >> > > t(i,j,k,iel,1)=.99*t(i,j,k,iel,1)*(xm1(i,j,k,iel)**2.-1.) > > >> > > in case the boundary surface plane is at x=1 & x=-1 > > >> > > Best, > > >> > Aleks > > >> > > > > > > > On Mon, 10 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > >> > >> Hello all, > > >> > > I am trying to perturb the temperature in a small part of the flow. > > >> > However, I only wish to perturb in the interior and not on a boundary. > > >> > I have the following in "userchk". If I instead looped from "k=1,nz1" > > >> > instead of "k=2,nz1-1", would this change the BC's? The general > > >> > question would be, does changing uvw & T in "userchk" change BC's or > > >> > does "userbc" override what is done in "userchk"? > > >> > > Cheers, > > >> > Frank > > >> > > do 100 iel=1,nelv > > >> > do 100 k=2,nz1-1 > > >> > do 100 j=2,ny1-1 > > >> > do 100 i=2,nx1-1 > > >> > if(((xm1(i,j,k,iel)-1.1)**2 > > >> > & + (ym1(i,j,k,iel)-1.1)**2 > > >> > & + (zm1(i,j,k,iel)-.45)**2)**.5.le..25)then > > >> > t(i,j,k,iel)=.99*t(i,j,k,iel) > > >> > endif > > >> > enddo !n > > >> > 100 continue > > >> > > > > > -- > 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 > > >> > > >> _______________________________________________ > > >> 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 Tue May 11 17:40:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 17:40:41 -0500 (CDT) Subject: [Nek5000-users] perturbing interior variables In-Reply-To: <1273616456.27302.11.camel@localhost.localdomain> References: <1273496952.3394.135.camel@localhost.localdomain> <1273573858.3394.158.camel@localhost.localdomain> <1273613886.27302.5.camel@localhost.localdomain> <1273616456.27302.11.camel@localhost.localdomain> Message-ID: Hi Frank, Yes. You can call dsavg() on each timestep and you'd be ok. It simply projects the solution onto the space of continuous functions. If it's already there, then it won't change anything. Note, if you are doing conjugate heat transfer or have a problem with a different topology for u and T (e.g., periodic bcs for u but not for T), then you would need: ifield=1 call dsavg(vx) call dsavg(vy) call dsavg(vz) ifield=2 call dsavg(t) In 99.9% of all cases run with Nek, however, you can ignore this last comment. Paul On Wed, 12 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > On Tue, 2010-05-11 at 17:14 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Yes - any function that is supposed to be continuous should be > so at timestep 0, else there will be problems. Hi Paul, But if one is perturbing the velocity and/or temperature not at t=0 but at a later time (in "userchk") then "dsavg" should still be called? Cheers, Frank > > For the Pn-Pn-2 formulation, pressure is discontinuous, so there > is no issue for pressure in this case. > > However, one would call dsavg for vx, vy,vz and T --- > > This is already done in ic.f following standard initialization > procedures. > > It likely wouldn't need to be done if you range strictly over > the element interiors, i,j,k \in [2,...,nx1]^3 --- but it > wouldn't hurt in any case. > > Paul > > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > I'm not quite sure what you mean here, am assuming you have in mind > continuous across element boundaries. At present, some simulations are > running where at a certain time, the temperature field is perturbed as > in the code segment below. Would the absence of "dsavg" cause a problem > regardless of whether one loops from "k=2,nz1-1" or "k=1,nz1" etc.? > Also, is "dsavg" needed when dealing with velocity? > > Cheers, > Frank > > if(time>1. .and. time<= 1.+2.5*dt)then > write(*,*)'Symmetry breaking' > vmax=.01 ; tmax=.99 ; radius=1.5 ; radius_s=.25 > nlocations_perturbed=3 > do 100 iel=1,nelv > do 100 k=2,nz1-1 > do 100 j=2,ny1-1 > do 100 i=2,nx1-1 > do n=1,nlocations_perturbed > angle = acos(-1.)*2.*(n-1.)/nlocations_perturbed > x1=radius*cos(angle) ; y1=radius*sin(angle) > if(((xm1(i,j,k,iel)-x1)**2 > & + (ym1(i,j,k,iel)-y1)**2 > & + (zm1(i,j,k,iel)-.45)**2)**.5.le.radius_s)then > t(i,j,k,iel,1)=tmax*t(i,j,k,iel,1) > endif > enddo !n > 100 continue > endif !time>1. .and. time<= 1.+2.*dt > > > On Tue, 2010-05-11 at 07:38 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Hi Frank, > > > > One additional note. > > > > It's important that your perturbed T() be continuous. > > > > This could be done, e.g., via the following code in userchk > > > > if (istep.eq.0) then > > n=nx1*ny1*nz1*nelt > > do i=1,n > > t(i,1,1,1,1) = t(i,1,1,1,1) + perturbation of choice > > enddo > > call dsavg(t) > > endif > > > > The dsavg() will ensure that T is continuous. If T is not > > continuous at the beginning, it will be discontinous forever > > since we only solve for delta T and then add this to T. > > > > > > Paul > > > > > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > > > > > Hi Frank, > > > > > > Boundary values will be set by userbc(). > > > > > > There is no opportunity to intercede between userbc() being called > > > and the solver. (In effect, userbc() _is_ the opportunity to > > > intercede.) > > > > > > userchk is called at the end of each step and therefore effectively > > > at the beginning of the next. Perturbing there will work - you can > > > perturb all values and rest assured that values on Dirichlet surfaces > > > will be overwritten by userbc. Values on Neumann surfaces, however, > > > would not be reset by userbc. > > > > > > hth, > > > > > > Paul > > > > > > On Tue, 11 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > >> Thanks for the replies, Aleks and Stefan. I am still not clear on one > > > point though. Are changes made to temperature or velocity on boundaries > > > in "userchk" at each time step irrelevant since they are overwritten by > > > calls to "userbc"? > > > > > > Cheers, > > > Frank > > > > > > > > > On Mon, 2010-05-10 at 18:15 +0200, nek5000-users at lists.mcs.anl.gov > > > wrote: > > >> The heat solver calls BCDIRSC which will apply Dirichlet bcs. All 't ' > > >> boundary points call userbc so you have the full control over the values at > > >> the boundary. > > >> > > >> Stefan > > >> > > >> > > >> > > >> > > >> On May 10, 2010, at 6:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > > >> > > >> > Hi Frank, > > >> > > > I assume that you refer to t(i,j,k,iel) as temperature -- to be safe > > >> it should be t(i,j,k,iel,1)... > > >> > > > In timestepping loop, subroutine userchk is called last by one -- > > >> right before the last one -- prepost which dumps field files .f or .fld -- > > >> see nek5_svn/trunk/nek/drive1.f: > > >> > > DO ISTEP=1,NSTEPS > > >> > call nek_advance > > >> > call userchk > > >> > call prepost (.false.,'his') > > >> > if (lastep .eq. 1) goto 1001B > > >> > ENDDO > > >> > > while, as I can see, userbc for a passive scalar is called from a chain > > >> of subroutines nek_advance > heat > cdscal > BCNEUSC/BCDIRSC > > >> > > This means that perturbation of temperature at the boundary won't be > > >> overwritten in userbc. > > >> > > > One way to apply perturbation everywhere including the element faces > > >> that are not on the boundary of your domain is simply to multiply your > > >> perturbation factor by a function that goes to zero on the boundaries, > > >> e.g.: > > >> > > t(i,j,k,iel,1)=.99*t(i,j,k,iel,1)*(xm1(i,j,k,iel)**2.-1.) > > >> > > in case the boundary surface plane is at x=1 & x=-1 > > >> > > Best, > > >> > Aleks > > >> > > > > > > > On Mon, 10 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > >> > >> Hello all, > > >> > > I am trying to perturb the temperature in a small part of the flow. > > >> > However, I only wish to perturb in the interior and not on a boundary. > > >> > I have the following in "userchk". If I instead looped from "k=1,nz1" > > >> > instead of "k=2,nz1-1", would this change the BC's? The general > > >> > question would be, does changing uvw & T in "userchk" change BC's or > > >> > does "userbc" override what is done in "userchk"? > > >> > > Cheers, > > >> > Frank > > >> > > do 100 iel=1,nelv > > >> > do 100 k=2,nz1-1 > > >> > do 100 j=2,ny1-1 > > >> > do 100 i=2,nx1-1 > > >> > if(((xm1(i,j,k,iel)-1.1)**2 > > >> > & + (ym1(i,j,k,iel)-1.1)**2 > > >> > & + (zm1(i,j,k,iel)-.45)**2)**.5.le..25)then > > >> > t(i,j,k,iel)=.99*t(i,j,k,iel) > > >> > endif > > >> > enddo !n > > >> > 100 continue > > >> > > > > > -- > 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 > > >> > > >> _______________________________________________ > > >> 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 From nek5000-users at lists.mcs.anl.gov Tue May 11 17:49:52 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 12 May 2010 00:49:52 +0200 Subject: [Nek5000-users] RE : problem with closed internal boundaries In-Reply-To: <1273605002.3394.205.camel@localhost.localdomain> References: <5313C3E0D03CB044A289CAC54D804C120157D55BF78D@BVMBX1.univ-lyon1.fr> , <1273602670.3394.200.camel@localhost.localdomain> <5313C3E0D03CB044A289CAC54D804C120157D55BF78E@BVMBX1.univ-lyon1.fr>, <1273605002.3394.205.camel@localhost.localdomain> Message-ID: <5313C3E0D03CB044A289CAC54D804C120157D55BF78F@BVMBX1.univ-lyon1.fr> Hi Stefan, as compilers, I use mpif77 and mpicc for the makenek, and gfortran and mpicc for the maketools (assuming that prenek and/or genmap compilation could have an influence here). Frank, indeed my whole geometry, as interpreted by nek5000, is messed up. That's the point but I have no clue where this problem is coming from. Cheers, Michael ________________________________________ 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 : mardi 11 mai 2010 21:10 ? : nek5000-users at lists.mcs.anl.gov Objet : Re: [Nek5000-users] RE : problem with closed internal boundaries Hi Michael, It seems that perhaps your mesh and/or grid mapping is messed up. The numbers concerning your mesh in your "out" file are huge: verify mesh topology 9.90000000000000105E+021 -9.90000000000000105E+021 Xrange 9.90000000000000105E+021 -9.90000000000000105E+021 Yrange 9.90000000000000105E+021 -9.90000000000000105E+021 Zrange done :: verify mesh topology >From one of my simulations: verify mesh topology -1.51515151515152 1.51515151515152 Xrange -1.51515151515152 1.51515151515152 Yrange -0.500000000000000 0.500000000000000 Zrange done :: verify mesh topology Cheers, Frank On Tue, 2010-05-11 at 20:57 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hello Frank, > > thanks for the quick answer. The Nek team should be relieved that the community is growing and that some users start to be able to help the newbies. > I tried what you recommended and now that you've said it, it looks obvious that all the z parameters should be 1 for a 2D case, but this isn't changing a thing. I still get those NaNs. > > Do you have any other idea? > > Best, > > > Michael > ________________________________________ > 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 : mardi 11 mai 2010 20:31 > ? : nek5000-users at lists.mcs.anl.gov > Objet : Re: [Nek5000-users] problem with closed internal boundaries > > Hello Michael, > > I am by no means knowledgeable concerning NEK, but will put my two-cents > in by saying that I believe that all dimensions in the z-direction must > be 1. However, you have "parameter (lz2=lz1-2)" and "parameter > (lz3=lz2)". > > Cheers, > Frank > > > On Tue, 2010-05-11 at 18:20 +0200, nek5000-users at lists.mcs.anl.gov > wrote: > > Hello Neks, > > > > I'm trying to model a flow past an obstacle in a channel. As a first step I would like to do a 2D simulation. > > I'm encountering some problems during the geometry data generation in the nek5000 execution : it looks like the program can only generate NaN values although genmap seems to work well on the .rea file. > > I can also reopen the rea file with prenek without any problems. > > > > Do you have any idea what is going wrong here? > > Is it problematic to have a closed internal boundary condition? > > Thanks in advance for any help. > > > > Best, > > > > > > Michael B > > _______________________________________________ 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 From nek5000-users at lists.mcs.anl.gov Tue May 11 17:59:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 12 May 2010 00:59:25 +0200 Subject: [Nek5000-users] cylindrical mesh & cyl_box Message-ID: <1273618765.27302.20.camel@localhost.localdomain> Hello all, I notice that there is a routine "cyl_box" in "genbox.f". It seems that this routine generates meshes for cylindrical geometries. Does anyone out there use this routine and/or have any documentation on it? 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 Tue May 11 18:16:07 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 May 2010 18:16:07 -0500 (CDT) Subject: [Nek5000-users] cylindrical mesh & cyl_box In-Reply-To: <1273618765.27302.20.camel@localhost.localdomain> References: <1273618765.27302.20.camel@localhost.localdomain> Message-ID: Hi Frank, I tried to resurrect this capability a couple weeks back but somehow couldn't make it go... I need to unravel it. It is designed to do the obvious but obviously hasn't been supported for awhile. Hopefully I can get back to it in the near future. Paul On Wed, 12 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, I notice that there is a routine "cyl_box" in "genbox.f". It seems that this routine generates meshes for cylindrical geometries. Does anyone out there use this routine and/or have any documentation on it? 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 Tue May 11 18:20:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 12 May 2010 01:20:06 +0200 Subject: [Nek5000-users] RE : problem with closed internal boundaries In-Reply-To: <5313C3E0D03CB044A289CAC54D804C120157D55BF78F@BVMBX1.univ-lyon1.fr> References: <5313C3E0D03CB044A289CAC54D804C120157D55BF78D@BVMBX1.univ-lyon1.fr> , <1273602670.3394.200.camel@localhost.localdomain> <5313C3E0D03CB044A289CAC54D804C120157D55BF78E@BVMBX1.univ-lyon1.fr> , <1273605002.3394.205.camel@localhost.localdomain> <5313C3E0D03CB044A289CAC54D804C120157D55BF78F@BVMBX1.univ-lyon1.fr> Message-ID: <1273620006.27302.26.camel@localhost.localdomain> Hi Michael, I just ran your case and all seems OK. I built a new *.map but it turned out to be the same as yours. Everything is at: http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/a Cheers, Frank On Wed, 2010-05-12 at 00:49 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > as compilers, I use mpif77 and mpicc for the makenek, and gfortran and mpicc for the maketools (assuming that prenek and/or genmap compilation could have an influence here). > > Frank, indeed my whole geometry, as interpreted by nek5000, is messed up. That's the point but I have no clue where this problem is coming from. > > Cheers, > > > Michael > ________________________________________ > 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 : mardi 11 mai 2010 21:10 > ? : nek5000-users at lists.mcs.anl.gov > Objet : Re: [Nek5000-users] RE : problem with closed internal boundaries > > Hi Michael, > > It seems that perhaps your mesh and/or grid mapping is messed up. The > numbers concerning your mesh in your "out" file are huge: > > verify mesh topology > 9.90000000000000105E+021 -9.90000000000000105E+021 Xrange > 9.90000000000000105E+021 -9.90000000000000105E+021 Yrange > 9.90000000000000105E+021 -9.90000000000000105E+021 Zrange > done :: verify mesh topology > > > >From one of my simulations: > > > verify mesh topology > -1.51515151515152 1.51515151515152 Xrange > -1.51515151515152 1.51515151515152 Yrange > -0.500000000000000 0.500000000000000 Zrange > done :: verify mesh topology > > > Cheers, > Frank > > > On Tue, 2010-05-11 at 20:57 +0200, nek5000-users at lists.mcs.anl.gov > wrote: > > Hello Frank, > > > > thanks for the quick answer. The Nek team should be relieved that the community is growing and that some users start to be able to help the newbies. > > I tried what you recommended and now that you've said it, it looks obvious that all the z parameters should be 1 for a 2D case, but this isn't changing a thing. I still get those NaNs. > > > > Do you have any other idea? > > > > Best, > > > > > > Michael > > ________________________________________ > > 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 : mardi 11 mai 2010 20:31 > > ? : nek5000-users at lists.mcs.anl.gov > > Objet : Re: [Nek5000-users] problem with closed internal boundaries > > > > Hello Michael, > > > > I am by no means knowledgeable concerning NEK, but will put my two-cents > > in by saying that I believe that all dimensions in the z-direction must > > be 1. However, you have "parameter (lz2=lz1-2)" and "parameter > > (lz3=lz2)". > > > > Cheers, > > Frank > > > > > > On Tue, 2010-05-11 at 18:20 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > > > Hello Neks, > > > > > > I'm trying to model a flow past an obstacle in a channel. As a first step I would like to do a 2D simulation. > > > I'm encountering some problems during the geometry data generation in the nek5000 execution : it looks like the program can only generate NaN values although genmap seems to work well on the .rea file. > > > I can also reopen the rea file with prenek without any problems. > > > > > > Do you have any idea what is going wrong here? > > > Is it problematic to have a closed internal boundary condition? > > > Thanks in advance for any help. > > > > > > Best, > > > > > > > > > Michael B > > > _______________________________________________ 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 Wed May 12 04:15:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 12 May 2010 11:15:03 +0200 Subject: [Nek5000-users] RE : RE : problem with closed internal boundaries In-Reply-To: <1273620006.27302.26.camel@localhost.localdomain> References: <5313C3E0D03CB044A289CAC54D804C120157D55BF78D@BVMBX1.univ-lyon1.fr> , <1273602670.3394.200.camel@localhost.localdomain> <5313C3E0D03CB044A289CAC54D804C120157D55BF78E@BVMBX1.univ-lyon1.fr> , <1273605002.3394.205.camel@localhost.localdomain> <5313C3E0D03CB044A289CAC54D804C120157D55BF78F@BVMBX1.univ-lyon1.fr>, <1273620006.27302.26.camel@localhost.localdomain> Message-ID: <5313C3E0D03CB044A289CAC54D804C120157D55BF790@BVMBX1.univ-lyon1.fr> Hi Frank, Indeed, the case is ok now and I got it running this morning. I guess I corrupted my SIZE file in some way, trying to correct it. Thank you very much for your time. cheers, Michael PS : @Nek Team : should we put a [SOLVED] in front of a subject when a solution is found for an easier sorting? ________________________________________ 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 : mercredi 12 mai 2010 01:20 ? : nek5000-users at lists.mcs.anl.gov Objet : Re: [Nek5000-users] RE : problem with closed internal boundaries Hi Michael, I just ran your case and all seems OK. I built a new *.map but it turned out to be the same as yours. Everything is at: http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/a Cheers, Frank On Wed, 2010-05-12 at 00:49 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > as compilers, I use mpif77 and mpicc for the makenek, and gfortran and mpicc for the maketools (assuming that prenek and/or genmap compilation could have an influence here). > > Frank, indeed my whole geometry, as interpreted by nek5000, is messed up. That's the point but I have no clue where this problem is coming from. > > Cheers, > > > Michael > ________________________________________ > 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 : mardi 11 mai 2010 21:10 > ? : nek5000-users at lists.mcs.anl.gov > Objet : Re: [Nek5000-users] RE : problem with closed internal boundaries > > Hi Michael, > > It seems that perhaps your mesh and/or grid mapping is messed up. The > numbers concerning your mesh in your "out" file are huge: > > verify mesh topology > 9.90000000000000105E+021 -9.90000000000000105E+021 Xrange > 9.90000000000000105E+021 -9.90000000000000105E+021 Yrange > 9.90000000000000105E+021 -9.90000000000000105E+021 Zrange > done :: verify mesh topology > > > >From one of my simulations: > > > verify mesh topology > -1.51515151515152 1.51515151515152 Xrange > -1.51515151515152 1.51515151515152 Yrange > -0.500000000000000 0.500000000000000 Zrange > done :: verify mesh topology > > > Cheers, > Frank > > > On Tue, 2010-05-11 at 20:57 +0200, nek5000-users at lists.mcs.anl.gov > wrote: > > Hello Frank, > > > > thanks for the quick answer. The Nek team should be relieved that the community is growing and that some users start to be able to help the newbies. > > I tried what you recommended and now that you've said it, it looks obvious that all the z parameters should be 1 for a 2D case, but this isn't changing a thing. I still get those NaNs. > > > > Do you have any other idea? > > > > Best, > > > > > > Michael > > ________________________________________ > > 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 : mardi 11 mai 2010 20:31 > > ? : nek5000-users at lists.mcs.anl.gov > > Objet : Re: [Nek5000-users] problem with closed internal boundaries > > > > Hello Michael, > > > > I am by no means knowledgeable concerning NEK, but will put my two-cents > > in by saying that I believe that all dimensions in the z-direction must > > be 1. However, you have "parameter (lz2=lz1-2)" and "parameter > > (lz3=lz2)". > > > > Cheers, > > Frank > > > > > > On Tue, 2010-05-11 at 18:20 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > > > Hello Neks, > > > > > > I'm trying to model a flow past an obstacle in a channel. As a first step I would like to do a 2D simulation. > > > I'm encountering some problems during the geometry data generation in the nek5000 execution : it looks like the program can only generate NaN values although genmap seems to work well on the .rea file. > > > I can also reopen the rea file with prenek without any problems. > > > > > > Do you have any idea what is going wrong here? > > > Is it problematic to have a closed internal boundary condition? > > > Thanks in advance for any help. > > > > > > Best, > > > > > > > > > Michael B > > > _______________________________________________ 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 From nek5000-users at lists.mcs.anl.gov Wed May 12 13:49:33 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 12 May 2010 20:49:33 +0200 Subject: [Nek5000-users] creating circular mesh Message-ID: <1273690174.27302.45.camel@localhost.localdomain> Hello all, Is there anyone out there who has a script/input for meshing a circular pipe/cylinder using "pretex"? 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 Fri May 14 22:16:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 14 May 2010 23:16:55 -0400 Subject: [Nek5000-users] prex & pretex not working Message-ID: <4BEE1227.3010508@vt.edu> Hi, this is in response to Harish's mail from Mon May 3 13:14:48 CDT 2010. Not sure if your problems are solved now, but I had similar issues on a Fedora 12 machine with gcc/gfortran 4.4.3-4.fc12, where prenek would compile fine (with BIGMEM=true) but would just get killed after startup of prex (the window pops up shortly, but vanishes without displaying anything). I could fix it by updating to and compiling with gcc&gfortran-4.5. Using new gfortran and older gcc4.4.3 resulted in the same error. @Developers: Further, I think the reason for not getting any output from the maketools is the following lines in "maketools", where I assume the echo and exit calls should be exchanged in order (and a typo) to get a clean output (at least on my system nothing showed for an unknown f77 compiler). " *) exit 1 echo "Error: Unkown compiler!" ;; " to " *) echo "Error: Unknown compiler!" exit 1 ;; " Markus From nek5000-users at lists.mcs.anl.gov Fri May 14 22:36:19 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 14 May 2010 23:36:19 -0400 Subject: [Nek5000-users] New code+recycling BC In-Reply-To: <996888BA-3BDB-4FFA-BEDA-6E86261F80DA@lav.mavt.ethz.ch> References: <4BDEDCC8.4050207@vt.edu> <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> <1273012756.4be0a2146ad1e@webmail.vt.edu> <996888BA-3BDB-4FFA-BEDA-6E86261F80DA@lav.mavt.ethz.ch> Message-ID: <4BEE16B3.9010800@vt.edu> Hi, Thanks for the help, I guess I based my approach on a much older version since pointer numbering was done much differently. Anyhow, I got it to work now, if someone wants to build a recycling inflow boundary condition based on the jet example here are some hopefully useful hints (that were not obvious to me): in the jet example, the inflow pipe is build on the x/y plane (where on each x/y plane there are 84 elements, which is ne_per_slab), and there are 8 layers in z (n_slab). The rest of the domain (surroundings where jet flows into) has all element numbers higher than 8*84. For these reasons, it works to define a pointer to the recycling face for each inlet face element (which you know are elements 1-84 globally) as "ieshift=eg+(nslab-1)*ne_per_slab". Markus nek5000-users at lists.mcs.anl.gov wrote: > Hi Markus, > > yes we changed glo_num to be an 8-byte integer array. Unfortunately we did not update the examples. I'll update the turbJet example. > > Stefan > > > On May 5, 2010, at 12:39 AM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hiu, >> >> sorry about the delay, to make sure I regenerated the problem. >> >> I did as you suggested, it is still messed up when opening the first fld dump in >> VisIt with the meta file containing only one file. >> >> What I meant by element ordering is the way the recycling b.c. is set up, where >> the "outflow" face of recycling box is established by counting a number of >> elements downstream from the inflow, as it is done in the jet example. I have a >> suspicion that something changed there (not in my .rea file, though). >> The problem came about when updating Nek from 404 to 503, I did not change >> Visit. >> >> Thanks, >> Markus >> >> >> >> Quoting nek5000-users at lists.mcs.anl.gov: >> >>> Can you dump a field file including the geometry and then visualize it using >>> VisIt (your metadata file should only contain one single fld). Is it still >>> messed up? >>> >>> Stefan >>> >>> >>> On May 3, 2010, at 5:24 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Markus, >>>> >>>> is it only a viz issue or do you have some problems in Nek after upgrading >>> to the latest release. >>>> Stefan >>>> >>>> >>>> On May 3, 2010, at 4:25 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi, >>>>> >>>>> when updating the code from rev. 404 (oldvel.png) to 503 >>>>> (newvel.png), I realized a problem with the recycling >>>>> (periodic) boundary condition for a channel simulation I am doing - >>>>> compare the attached pictures of velocity on the inflow plane (the inflow >>> is the Y/Z plane). For the two cases, SIZE/SIZEu, .rea, the restart step and >>> .usr are the exact same. >>>>> Here are the relevant pieces from .usr. Have any of the functions >>>>> changed or am I doing something wrong? It seems as if the element >>>>> ordering is not what it was before. >>>>> I did this based on the jet example. >>>>> >>>>> Thanks, >>>>> Markus >>>>> >>>>> >>>>> c----------------------------------------------------------------------- >>>>> subroutine userbc (ix,iy,iz,iside,eg) >>>>> include 'SIZE' >>>>> include 'TOTAL' >>>>> include 'NEKUSE' >>>>> >>>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>>> $ , vin(lx1,ly1,lz1,lelv) >>>>> $ , win(lx1,ly1,lz1,lelv) >>>>> $ , tin(lx1,ly1,lz1,lelv) >>>>> >>>>> integer e,eg >>>>> >>>>> e = gllel(eg) >>>>> >>>>> ux=uin(ix,iy,iz,e) >>>>> uy=vin(ix,iy,iz,e) >>>>> uz=win(ix,iy,iz,e) >>>>> . >>>>> .... >>>>> >>>>> c----------------------------------------------------------------------- >>>>> subroutine userchk >>>>> include 'SIZE' >>>>> include 'TOTAL' >>>>> include 'ZPER' ! for nelx,nely,nelz >>>>> include 'RESTART' !Needs to be here for prepost to work >>>>> common /cvlmsk/ vlmsk(lx1,ly1,lz1,lelt),vvol, >>>>> & wt(lx1*ly1*lz1,lelt),vol_per >>>>> >>>>> integer e,f,eg,ninx,niny,ninz >>>>> >>>>> .c-----Computations for recycling BC >>>>> speed = glsc2(vx,wt,n)/vol_per ! Where vol_per is the volume of >>>>> the recycling box >>>>> starg = 1.0 >>>>> addtemp = 1.0 >>>>> call set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>>> . >>>>> .... >>>>> >>>>> c----------------------------------------------------------------------- >>>>> subroutine set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>>> >>>>> include 'SIZE' >>>>> include 'TOTAL' >>>>> >>>>> integer icalld,e,eg,f >>>>> save icalld >>>>> data icalld /0/ >>>>> >>>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>>> $ , vin(lx1,ly1,lz1,lelv) >>>>> $ , win(lx1,ly1,lz1,lelv) >>>>> $ , tin(lx1,ly1,lz1,lelv) >>>>> >>>>> common /scruz/ ptr(lx1,ly1,lz1,lelv) >>>>> integer ptr,gs_bc_hndl >>>>> save gs_bc_hndl >>>>> >>>>> real ratio >>>>> save ratio >>>>> data ratio / 1. / >>>>> >>>>> common /nekmpi/ mid,mp,nekcomm,nekgroup,nekreal >>>>> >>>>> n = nx1*ny1*nz1*nelv >>>>> >>>>> if (icalld.eq.0) then >>>>> icalld = 1 >>>>> nxyz = nx1*ny1*nz1 >>>>> >>>>> do e=1,nelv >>>>> eg = lglel(e) >>>>> eo = nxyz*(eg-1) ! offset >>>>> do i=1,nxyz >>>>> ptr(i,1,1,e) = i+eo >>>>> enddo >>>>> >>>>> do k=2,nz1-1 ! get rid of interior pointers >>>>> do j=2,ny1-1 do i=2,nx1-1 >>>>> ptr(i,j,k,e) = 0 >>>>> enddo >>>>> enddo >>>>> enddo >>>>> >>>>> nface = 2*ndim >>>>> do f=1,nface ! connect inflow to elems downstream >>>>> ioff = nxyz*8 ! 5 elements in X to end of "periodic" sec. >>>>> if (cbc(f,e,1).eq.'v ') then >>>>> call iface_add(ptr,f,e,ioff,nx1,ny1,nz1) >>>>> endif >>>>> enddo >>>>> >>>>> enddo >>>>> >>>>> call gs_setup(gs_bc_hndl,ptr,n,nekcomm,np) ! connect v + >>>>> downstream >>>>> >>>>> endif >>>>> >>>>> call copy(uin,vx,n) >>>>> call copy(vin,vy,n) >>>>> call copy(win,vz,n) >>>>> call copy(tin,t,n) >>>>> >>>>> call col2(uin,v1mask,n) >>>>> call col2(vin,v2mask,n) >>>>> call col2(win,v3mask,n) >>>>> call col2(tin,tmask,n) >>>>> >>>>> call gs_op(gs_bc_hndl,uin,1,1,0) ! 1 ==> + ! uin(inflow) = >>>>> vx(slab_k) >>>>> call gs_op(gs_bc_hndl,vin,1,1,0) ! 1 ==> + >>>>> call gs_op(gs_bc_hndl,win,1,1,0) ! 1 ==> + >>>>> call gs_op(gs_bc_hndl,tin,1,1,0) ! 1 ==> + >>>>> >>>>> if (speed.gt.0) then >>>>> ratio = .5*(starg/speed + ratio) >>>>> call cmult(uin,ratio,n) >>>>> call cmult(vin,ratio,n) >>>>> call cmult(win,ratio,n) >>>>> call cadd(tin,addtemp,n) !Substract added heat >>>>> endif >>>>> >>>>> return >>>>> end >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Sat May 15 00:09:31 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 10:39:31 +0530 Subject: [Nek5000-users] RB convection with high Rayleigh numbers Message-ID: <4BEE2C8B.2070205@iitk.ac.in> Hi, I'm trying to simulate RB convection in a 2D box of aspect ratio 2:1. I'd like to simulate cases with Rayleigh numbers of the order of 10^7 - 10^8. But I'm barely able to do 10^5 and that too with a time step of 10^-6. For the mesh I took 8 spectral elements in the x direction and 4 spectral elements in the y direction with 48 points within each of them. Is there any way one can reach higher Ra numbers? Regards, Mani chandra From nek5000-users at lists.mcs.anl.gov Sat May 15 00:20:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 10:50:54 +0530 Subject: [Nek5000-users] Zero flux boundary conditions Message-ID: <4BEE2F36.5020401@iitk.ac.in> Dear Nek devs, How does one put in zero-flux boundary conditions for temperature? The nek wiki says that anything other than the primitive boundary conditions will be taken as zero-flux but in the benard example, the "zero-flux" condition for velocity was put in using the SYM boundary condition which is a primitive boundary condition as shown in the nek wiki. Could you please clarify? Regards, Mani chandra From nek5000-users at lists.mcs.anl.gov Sat May 15 01:51:46 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 08:51:46 +0200 Subject: [Nek5000-users] Zero flux boundary conditions In-Reply-To: <4BEE2F36.5020401@iitk.ac.in> References: <4BEE2F36.5020401@iitk.ac.in> Message-ID: <1273906306.3219.52.camel@localhost.localdomain> Hello Mani, Use the "I" boundary condition to do this. Cheers, Frank On Sat, 2010-05-15 at 10:50 +0530, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nek devs, > > How does one put in zero-flux boundary conditions for temperature? > The nek wiki says that anything other than the primitive boundary > conditions will be taken as zero-flux but in the benard example, the > "zero-flux" condition for velocity was put in using the SYM boundary > condition which is a primitive boundary condition as shown in the nek > wiki. Could you please clarify? > > Regards, > Mani chandra > _______________________________________________ > 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 Sat May 15 03:15:39 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 13:45:39 +0530 Subject: [Nek5000-users] [*] Re: Zero flux boundary conditions In-Reply-To: <1273906306.3219.52.camel@localhost.localdomain> References: <4BEE2F36.5020401@iitk.ac.in> <1273906306.3219.52.camel@localhost.localdomain> Message-ID: <4BEE582B.9040301@iitk.ac.in> Hi Frank, Thanks for that. I ran the code with "I" boundary condition and it produces the same result as with "SYM" boundary condition. Regards, Mani chandra On 05/15/2010 12:21 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Mani, > > Use the "I" boundary condition to do this. > > Cheers, > Frank > > On Sat, 2010-05-15 at 10:50 +0530, nek5000-users at lists.mcs.anl.gov > wrote: > >> Dear Nek devs, >> >> How does one put in zero-flux boundary conditions for temperature? >> The nek wiki says that anything other than the primitive boundary >> conditions will be taken as zero-flux but in the benard example, the >> "zero-flux" condition for velocity was put in using the SYM boundary >> condition which is a primitive boundary condition as shown in the nek >> wiki. Could you please clarify? >> >> Regards, >> Mani chandra >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> From nek5000-users at lists.mcs.anl.gov Sat May 15 03:41:18 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 10:41:18 +0200 Subject: [Nek5000-users] prex & pretex not working In-Reply-To: <4BEE1227.3010508@vt.edu> References: <4BEE1227.3010508@vt.edu> Message-ID: The unknown compiler handling is fixed in the latest release. Stefan On May 15, 2010, at 5:16 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > this is in response to Harish's mail from Mon May 3 13:14:48 CDT 2010. > > Not sure if your problems are solved now, but I had similar issues on a Fedora 12 machine with gcc/gfortran 4.4.3-4.fc12, where prenek would compile fine (with BIGMEM=true) but would just get killed after startup of prex (the window pops up shortly, but vanishes without displaying anything). > I could fix it by updating to and compiling with gcc&gfortran-4.5. Using new gfortran and older gcc4.4.3 resulted in the same error. > > @Developers: Further, I think the reason for not getting any output from the maketools is the following lines in "maketools", where I assume the echo and exit calls should be exchanged in order (and a typo) to get a clean output (at least on my system nothing showed for an unknown f77 compiler). > " > *) exit 1 > echo "Error: Unkown compiler!" > ;; > " > > to > > " > *) echo "Error: Unknown compiler!" > exit 1 > ;; > " > > 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 Sat May 15 03:44:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 10:44:48 +0200 Subject: [Nek5000-users] New code+recycling BC In-Reply-To: <4BEE16B3.9010800@vt.edu> References: <4BDEDCC8.4050207@vt.edu> <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> <1273012756.4be0a2146ad1e@webmail.vt.edu> <996888BA-3BDB-4FFA-BEDA-6E86261F80DA@lav.mavt.ethz.ch> <4BEE16B3.9010800@vt.edu> Message-ID: <8BDF521E-FC86-4306-A835-7BBA1E3028C9@lav.mavt.ethz.ch> Hi Markus, only the declaration of glo_num as integer*8 has changed! Stefan On May 15, 2010, at 5:36 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > Thanks for the help, I guess I based my approach on a much older version since pointer numbering was done much differently. > Anyhow, I got it to work now, if someone wants to build a recycling inflow boundary condition based on the jet example here are some hopefully useful hints (that were not obvious to me): > in the jet example, the inflow pipe is build on the x/y plane (where on each x/y plane there are 84 elements, which is ne_per_slab), and there are 8 layers in z (n_slab). The rest of the domain (surroundings where jet flows into) has all element numbers higher than 8*84. > For these reasons, it works to define a pointer to the recycling face for each inlet face element (which you know are elements 1-84 globally) as "ieshift=eg+(nslab-1)*ne_per_slab". > > Markus > > > nek5000-users at lists.mcs.anl.gov wrote: >> Hi Markus, >> yes we changed glo_num to be an 8-byte integer array. Unfortunately we did not update the examples. I'll update the turbJet example. >> Stefan >> On May 5, 2010, at 12:39 AM, nek5000-users at lists.mcs.anl.gov wrote: >>> Hiu, >>> >>> sorry about the delay, to make sure I regenerated the problem. >>> >>> I did as you suggested, it is still messed up when opening the first fld dump in >>> VisIt with the meta file containing only one file. >>> >>> What I meant by element ordering is the way the recycling b.c. is set up, where >>> the "outflow" face of recycling box is established by counting a number of >>> elements downstream from the inflow, as it is done in the jet example. I have a >>> suspicion that something changed there (not in my .rea file, though). >>> The problem came about when updating Nek from 404 to 503, I did not change >>> Visit. >>> >>> Thanks, >>> Markus >>> >>> >>> >>> Quoting nek5000-users at lists.mcs.anl.gov: >>> >>>> Can you dump a field file including the geometry and then visualize it using >>>> VisIt (your metadata file should only contain one single fld). Is it still >>>> messed up? >>>> >>>> Stefan >>>> >>>> >>>> On May 3, 2010, at 5:24 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Markus, >>>>> >>>>> is it only a viz issue or do you have some problems in Nek after upgrading >>>> to the latest release. >>>>> Stefan >>>>> >>>>> >>>>> On May 3, 2010, at 4:25 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> when updating the code from rev. 404 (oldvel.png) to 503 >>>>>> (newvel.png), I realized a problem with the recycling >>>>>> (periodic) boundary condition for a channel simulation I am doing - >>>>>> compare the attached pictures of velocity on the inflow plane (the inflow >>>> is the Y/Z plane). For the two cases, SIZE/SIZEu, .rea, the restart step and >>>> .usr are the exact same. >>>>>> Here are the relevant pieces from .usr. Have any of the functions >>>>>> changed or am I doing something wrong? It seems as if the element >>>>>> ordering is not what it was before. >>>>>> I did this based on the jet example. >>>>>> >>>>>> Thanks, >>>>>> Markus >>>>>> >>>>>> >>>>>> c----------------------------------------------------------------------- >>>>>> subroutine userbc (ix,iy,iz,iside,eg) >>>>>> include 'SIZE' >>>>>> include 'TOTAL' >>>>>> include 'NEKUSE' >>>>>> >>>>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>>>> $ , vin(lx1,ly1,lz1,lelv) >>>>>> $ , win(lx1,ly1,lz1,lelv) >>>>>> $ , tin(lx1,ly1,lz1,lelv) >>>>>> >>>>>> integer e,eg >>>>>> >>>>>> e = gllel(eg) >>>>>> >>>>>> ux=uin(ix,iy,iz,e) >>>>>> uy=vin(ix,iy,iz,e) >>>>>> uz=win(ix,iy,iz,e) >>>>>> . >>>>>> .... >>>>>> >>>>>> c----------------------------------------------------------------------- >>>>>> subroutine userchk >>>>>> include 'SIZE' >>>>>> include 'TOTAL' >>>>>> include 'ZPER' ! for nelx,nely,nelz >>>>>> include 'RESTART' !Needs to be here for prepost to work >>>>>> common /cvlmsk/ vlmsk(lx1,ly1,lz1,lelt),vvol, >>>>>> & wt(lx1*ly1*lz1,lelt),vol_per >>>>>> >>>>>> integer e,f,eg,ninx,niny,ninz >>>>>> >>>>>> .c-----Computations for recycling BC >>>>>> speed = glsc2(vx,wt,n)/vol_per ! Where vol_per is the volume of >>>>>> the recycling box >>>>>> starg = 1.0 >>>>>> addtemp = 1.0 >>>>>> call set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>>>> . >>>>>> .... >>>>>> >>>>>> c----------------------------------------------------------------------- >>>>>> subroutine set_inflow(starg,speed,addtemp) ! set up inflow BCs >>>>>> >>>>>> include 'SIZE' >>>>>> include 'TOTAL' >>>>>> >>>>>> integer icalld,e,eg,f >>>>>> save icalld >>>>>> data icalld /0/ >>>>>> >>>>>> common /cvelbc/ uin(lx1,ly1,lz1,lelv) >>>>>> $ , vin(lx1,ly1,lz1,lelv) >>>>>> $ , win(lx1,ly1,lz1,lelv) >>>>>> $ , tin(lx1,ly1,lz1,lelv) >>>>>> >>>>>> common /scruz/ ptr(lx1,ly1,lz1,lelv) >>>>>> integer ptr,gs_bc_hndl >>>>>> save gs_bc_hndl >>>>>> >>>>>> real ratio >>>>>> save ratio >>>>>> data ratio / 1. / >>>>>> >>>>>> common /nekmpi/ mid,mp,nekcomm,nekgroup,nekreal >>>>>> >>>>>> n = nx1*ny1*nz1*nelv >>>>>> >>>>>> if (icalld.eq.0) then >>>>>> icalld = 1 >>>>>> nxyz = nx1*ny1*nz1 >>>>>> >>>>>> do e=1,nelv >>>>>> eg = lglel(e) >>>>>> eo = nxyz*(eg-1) ! offset >>>>>> do i=1,nxyz >>>>>> ptr(i,1,1,e) = i+eo >>>>>> enddo >>>>>> >>>>>> do k=2,nz1-1 ! get rid of interior pointers >>>>>> do j=2,ny1-1 do i=2,nx1-1 >>>>>> ptr(i,j,k,e) = 0 >>>>>> enddo >>>>>> enddo >>>>>> enddo >>>>>> >>>>>> nface = 2*ndim >>>>>> do f=1,nface ! connect inflow to elems downstream >>>>>> ioff = nxyz*8 ! 5 elements in X to end of "periodic" sec. >>>>>> if (cbc(f,e,1).eq.'v ') then >>>>>> call iface_add(ptr,f,e,ioff,nx1,ny1,nz1) >>>>>> endif >>>>>> enddo >>>>>> >>>>>> enddo >>>>>> >>>>>> call gs_setup(gs_bc_hndl,ptr,n,nekcomm,np) ! connect v + >>>>>> downstream >>>>>> >>>>>> endif >>>>>> >>>>>> call copy(uin,vx,n) >>>>>> call copy(vin,vy,n) >>>>>> call copy(win,vz,n) >>>>>> call copy(tin,t,n) >>>>>> >>>>>> call col2(uin,v1mask,n) >>>>>> call col2(vin,v2mask,n) >>>>>> call col2(win,v3mask,n) >>>>>> call col2(tin,tmask,n) >>>>>> >>>>>> call gs_op(gs_bc_hndl,uin,1,1,0) ! 1 ==> + ! uin(inflow) = >>>>>> vx(slab_k) >>>>>> call gs_op(gs_bc_hndl,vin,1,1,0) ! 1 ==> + >>>>>> call gs_op(gs_bc_hndl,win,1,1,0) ! 1 ==> + >>>>>> call gs_op(gs_bc_hndl,tin,1,1,0) ! 1 ==> + >>>>>> >>>>>> if (speed.gt.0) then >>>>>> ratio = .5*(starg/speed + ratio) >>>>>> call cmult(uin,ratio,n) >>>>>> call cmult(vin,ratio,n) >>>>>> call cmult(win,ratio,n) >>>>>> call cadd(tin,addtemp,n) !Substract added heat >>>>>> endif >>>>>> >>>>>> return >>>>>> end >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Sat May 15 08:27:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 08:27:44 -0500 (CDT) Subject: [Nek5000-users] RB convection with high Rayleigh numbers In-Reply-To: <9336018.1196621273929859551.JavaMail.root@zimbra> Message-ID: <3061053.1196641273930064044.JavaMail.root@zimbra> Hi Mani, A while back I was able to simulate 3D convection between stress-free surfaces at Rayleigh number Ra=1e6 (and Taylor number 5e5) with 4600 elements (and lx1=6) using time step 1e-5. I remember that to get to Ra=1e6 I had to get lower Ra solution first and then use it as initial condition. Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Saturday, May 15, 2010 12:09:31 AM GMT -06:00 US/Canada Central Subject: [Nek5000-users] RB convection with high Rayleigh numbers Hi, I'm trying to simulate RB convection in a 2D box of aspect ratio 2:1. I'd like to simulate cases with Rayleigh numbers of the order of 10^7 - 10^8. But I'm barely able to do 10^5 and that too with a time step of 10^-6. For the mesh I took 8 spectral elements in the x direction and 4 spectral elements in the y direction with 48 points within each of them. Is there any way one can reach higher Ra numbers? Regards, Mani chandra _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Sat May 15 06:06:30 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 07:06:30 -0400 Subject: [Nek5000-users] New code+recycling BC In-Reply-To: <996888BA-3BDB-4FFA-BEDA-6E86261F80DA@lav.mavt.ethz.ch> References: <4BDEDCC8.4050207@vt.edu> <7647C3C2-64D1-4E6F-948F-77785F49C5F5@lav.mavt.ethz.ch> <1273012756.4be0a2146ad1e@webmail.vt.edu> <996888BA-3BDB-4FFA-BEDA-6E86261F80DA@lav.mavt.ethz.ch> Message-ID: <4BEE8036.2040302@vt.edu> Hi, you are right, I had based my code on an example Paul had sent earlier, not the jet. That's why the shift numbering logic was different. Thanks again for the help, Markus nek5000-users at lists.mcs.anl.gov wrote: > Hi Markus, > > yes we changed glo_num to be an 8-byte integer array. Unfortunately we did not update the examples. I'll update the turbJet example. > > Stefan > From nek5000-users at lists.mcs.anl.gov Sat May 15 10:35:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 10:35:38 -0500 (CDT) Subject: [Nek5000-users] RB convection with high Rayleigh numbers In-Reply-To: <4BEE2C8B.2070205@iitk.ac.in> References: <4BEE2C8B.2070205@iitk.ac.in> Message-ID: Hi Mani, I've not tried to go this high yet, but there are several std techniques to pushing the envelope. First, you should try to get an estimate of your expected resolution requirements at the target Ra. Then, guess that you might want to run that simulation at say, lx1=10 or 12; and build the corresponding mesh (number of elements in x and y); but start the compuation at much lower Ra, with lx1=4, say. Then work your way up in Ra, say by a factor of 10 in each successive run, while also increasing lx1 as needed. Note that for the flow in a box, you might find it faster to use the fast tensor-product solver for the pressure, if using the Pn-Pn-2 method --- this is not always the case, but for some very difficult problems (e.g., highly refined meshes), it does work better. Paul On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I'm trying to simulate RB convection in a 2D box of aspect ratio 2:1. I'd > like to simulate cases with Rayleigh numbers of the order of 10^7 - 10^8. But > I'm barely able to do 10^5 and that too with a time step of 10^-6. For the > mesh I took 8 spectral elements in the x direction and 4 spectral elements in > the y direction with 48 points within each of them. Is there any way one can > reach higher Ra numbers? > > Regards, > Mani chandra > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sat May 15 10:37:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 10:37:21 -0500 (CDT) Subject: [Nek5000-users] Zero flux boundary conditions In-Reply-To: <4BEE2F36.5020401@iitk.ac.in> References: <4BEE2F36.5020401@iitk.ac.in> Message-ID: You need two bcs - one for fluid and one for T. For the flow, "SYM" will be stress free (u.nhat=0, du/dn=0) "W " will be homogeneous Dirichlet (u=0) For temperature, use "I " which is insulated (zero flux). Paul On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nek devs, > > How does one put in zero-flux boundary conditions for temperature? The > nek wiki says that anything other than the primitive boundary conditions will > be taken as zero-flux but in the benard example, the "zero-flux" condition > for velocity was put in using the SYM boundary condition which is a primitive > boundary condition as shown in the nek wiki. Could you please clarify? > > Regards, > Mani chandra > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sat May 15 10:45:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 17:45:53 +0200 Subject: [Nek5000-users] prex segmentation fault Message-ID: <1273938353.3219.76.camel@localhost.localdomain> Hello all, I am running into a segmentation fault when using "prex" on my 32 bit laptop. This occurs when using both the gfortran and ifort compilers. More info below, the first is from the Intel compiler, the second from gfortran. [root at frank temp4]# uname -a Linux frank 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 21:18:02 EST 2007 i686 i686 i386 GNU/Linux [root at frank tools]# gdb prex GNU gdb Red Hat Linux (6.6-16.fc7rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/local/programs/nek5000/nek5/trunk/tools/bin/prex (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) -Adobe-Helvetica-Medium-R-Normal--12-120-75-75-P-67-ISO8859-1 Program received signal SIGSEGV, Segmentation fault. 0x0092c68a in memmove () from /lib/libc.so.6 [root at frank tools]# gdb prex GNU gdb Red Hat Linux (6.6-16.fc7rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/local/programs/nek5000/nek5/trunk/tools/bin/prex (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) -Adobe-Helvetica-Medium-R-Normal--12-120-75-75-P-67-ISO8859-1 Program received signal SIGSEGV, Segmentation fault. 0x0092c68a in memmove () from /lib/libc.so.6 (gdb) where #0 0x0092c68a in memmove () from /lib/libc.so.6 #1 0x0017994c in _gfortran_copy_string () from /usr/lib/libgfortran.so.1 #2 0x0809ddca in data_ () #3 0x080494d2 in fprep_ () #4 0x080ea1a9 in mainc_ () #5 0x080a662b in MAIN__ () #6 0x080ea1d7 in main () (gdb) -- 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 Sat May 15 14:00:42 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 16 May 2010 00:30:42 +0530 Subject: [Nek5000-users] [*] Re: RB convection with high Rayleigh numbers In-Reply-To: References: <4BEE2C8B.2070205@iitk.ac.in> Message-ID: <4BEEEF5A.3080303@iitk.ac.in> Hi Paul, Thanks for the reply. I have a doubt whether one should increase the polynomial order or the number of elements with a fixed order for this case. As I understand from your illustration of the rotating cone case, increasing the polynomial order leads to a much better solution than with the same number of points generated using more elements with a lower order polynomial. Also how do I use the fast tensor-product solver? Is there some flag that I need to turn on? Regards, Mani chandra On 05/15/2010 09:05 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Mani, > > I've not tried to go this high yet, but there are several std > techniques to pushing the envelope. > > First, you should try to get an estimate of your expected resolution > requirements at the target Ra. Then, guess that you might want to > run that simulation at say, lx1=10 or 12; and build the corresponding > mesh (number of elements in x and y); but start the compuation at > much lower Ra, with lx1=4, say. > > Then work your way up in Ra, say by a factor of 10 in each successive > run, while also increasing lx1 as needed. > > Note that for the flow in a box, you might find it faster to use > the fast tensor-product solver for the pressure, if using the Pn-Pn-2 > method --- this is not always the case, but for some very difficult > problems (e.g., highly refined meshes), it does work better. > > Paul > > > On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> I'm trying to simulate RB convection in a 2D box of aspect ratio >> 2:1. I'd like to simulate cases with Rayleigh numbers of the order of >> 10^7 - 10^8. But I'm barely able to do 10^5 and that too with a time >> step of 10^-6. For the mesh I took 8 spectral elements in the x >> direction and 4 spectral elements in the y direction with 48 points >> within each of them. Is there any way one can reach higher Ra numbers? >> >> 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 Sat May 15 14:03:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 14:03:49 -0500 (CDT) Subject: [Nek5000-users] prex segmentation fault In-Reply-To: <1273938353.3219.76.camel@localhost.localdomain> References: <1273938353.3219.76.camel@localhost.localdomain> Message-ID: Frank, Try reducing nelm in basics.inc and recompiling. I'll try this w/ ifort -- I've only used it w/ pgf77 in recent years and Stefan does not use prex, so that part has not been as thoroughly checked as the rest of the code. Paul On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, I am running into a segmentation fault when using "prex" on my 32 bit laptop. This occurs when using both the gfortran and ifort compilers. More info below, the first is from the Intel compiler, the second from gfortran. [root at frank temp4]# uname -a Linux frank 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 21:18:02 EST 2007 i686 i686 i386 GNU/Linux [root at frank tools]# gdb prex GNU gdb Red Hat Linux (6.6-16.fc7rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/local/programs/nek5000/nek5/trunk/tools/bin/prex (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) -Adobe-Helvetica-Medium-R-Normal--12-120-75-75-P-67-ISO8859-1 Program received signal SIGSEGV, Segmentation fault. 0x0092c68a in memmove () from /lib/libc.so.6 [root at frank tools]# gdb prex GNU gdb Red Hat Linux (6.6-16.fc7rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/local/programs/nek5000/nek5/trunk/tools/bin/prex (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) -Adobe-Helvetica-Medium-R-Normal--12-120-75-75-P-67-ISO8859-1 Program received signal SIGSEGV, Segmentation fault. 0x0092c68a in memmove () from /lib/libc.so.6 (gdb) where #0 0x0092c68a in memmove () from /lib/libc.so.6 #1 0x0017994c in _gfortran_copy_string () from /usr/lib/libgfortran.so.1 #2 0x0809ddca in data_ () #3 0x080494d2 in fprep_ () #4 0x080ea1a9 in mainc_ () #5 0x080a662b in MAIN__ () #6 0x080ea1d7 in main () (gdb) -- 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 Sat May 15 14:20:05 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 21:20:05 +0200 Subject: [Nek5000-users] prex segmentation fault In-Reply-To: References: <1273938353.3219.76.camel@localhost.localdomain> Message-ID: <1273951205.3219.84.camel@localhost.localdomain> On Sat, 2010-05-15 at 14:03 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > Try reducing nelm in basics.inc and recompiling. > > I'll try this w/ ifort -- I've only used it w/ pgf77 in recent > years and Stefan does not use prex, so that part has not been > as thoroughly checked as the rest of the code. Hi Paul, Thanks, that worked. So not everyone else uses "prex"? I had thought that was pretty much the only option. What other tools are people using for meshing? Cheers, Frank > > Paul > > > On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > I am running into a segmentation fault when using "prex" on my 32 bit > laptop. This occurs when using both the gfortran and ifort compilers. > More info below, the first is from the Intel compiler, the second from > gfortran. > > [root at frank temp4]# uname -a > Linux frank 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 21:18:02 EST 2007 i686 > i686 i386 GNU/Linux > > [root at frank tools]# gdb prex > GNU gdb Red Hat Linux (6.6-16.fc7rh) > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-redhat-linux-gnu"... > (no debugging symbols found) > Using host libthread_db library "/lib/libthread_db.so.1". > (gdb) run > Starting program: /usr/local/programs/nek5000/nek5/trunk/tools/bin/prex > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > -Adobe-Helvetica-Medium-R-Normal--12-120-75-75-P-67-ISO8859-1 > > Program received signal SIGSEGV, Segmentation fault. > 0x0092c68a in memmove () from /lib/libc.so.6 > > > > > [root at frank tools]# gdb prex > GNU gdb Red Hat Linux (6.6-16.fc7rh) > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-redhat-linux-gnu"... > (no debugging symbols found) > Using host libthread_db library "/lib/libthread_db.so.1". > (gdb) run > Starting program: /usr/local/programs/nek5000/nek5/trunk/tools/bin/prex > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > -Adobe-Helvetica-Medium-R-Normal--12-120-75-75-P-67-ISO8859-1 > > Program received signal SIGSEGV, Segmentation fault. > 0x0092c68a in memmove () from /lib/libc.so.6 > (gdb) where > #0 0x0092c68a in memmove () from /lib/libc.so.6 > #1 0x0017994c in _gfortran_copy_string () > from /usr/lib/libgfortran.so.1 > #2 0x0809ddca in data_ () > #3 0x080494d2 in fprep_ () > #4 0x080ea1a9 in mainc_ () > #5 0x080a662b in MAIN__ () > #6 0x080ea1d7 in main () > (gdb) > > -- > 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 Sat May 15 18:08:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 18:08:21 -0500 (CDT) Subject: [Nek5000-users] [*] Re: RB convection with high Rayleigh numbers In-Reply-To: <4BEEEF5A.3080303@iitk.ac.in> References: <4BEE2C8B.2070205@iitk.ac.in> <4BEEEF5A.3080303@iitk.ac.in> Message-ID: Hi Mani, What type of bcs are you using ? I'm testing out a case, just to help scope out resolution requirements, etc. Paul On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Thanks for the reply. I have a doubt whether one should increase the > polynomial order or the number of elements with a fixed order for this case. > As I understand from your illustration of the rotating cone case, increasing > the polynomial order leads to a much better solution than with the same > number of points generated using more elements with a lower order polynomial. > > Also how do I use the fast tensor-product solver? Is there some flag that I > need to turn on? > > Regards, > Mani chandra > On 05/15/2010 09:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> Hi Mani, >> >> I've not tried to go this high yet, but there are several std >> techniques to pushing the envelope. >> >> First, you should try to get an estimate of your expected resolution >> requirements at the target Ra. Then, guess that you might want to >> run that simulation at say, lx1=10 or 12; and build the corresponding >> mesh (number of elements in x and y); but start the compuation at >> much lower Ra, with lx1=4, say. >> >> Then work your way up in Ra, say by a factor of 10 in each successive >> run, while also increasing lx1 as needed. >> >> Note that for the flow in a box, you might find it faster to use >> the fast tensor-product solver for the pressure, if using the Pn-Pn-2 >> method --- this is not always the case, but for some very difficult >> problems (e.g., highly refined meshes), it does work better. >> >> Paul >> >> >> On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> I'm trying to simulate RB convection in a 2D box of aspect ratio 2:1. >>> I'd like to simulate cases with Rayleigh numbers of the order of 10^7 - >>> 10^8. But I'm barely able to do 10^5 and that too with a time step of >>> 10^-6. For the mesh I took 8 spectral elements in the x direction and 4 >>> spectral elements in the y direction with 48 points within each of them. >>> Is there any way one can reach higher Ra numbers? >>> >>> 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 Sat May 15 22:44:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 May 2010 22:44:55 -0500 (CDT) Subject: [Nek5000-users] [*] Re: RB convection with high Rayleigh numbers In-Reply-To: <4BEEEF5A.3080303@iitk.ac.in> References: <4BEE2C8B.2070205@iitk.ac.in> <4BEEEF5A.3080303@iitk.ac.in> Message-ID: Hi Mani, I've added an example of a case that should run out to Ra=10^8 in the /benard directory of the repo (high_ray.blah is the case). I've run this with lx1=5, lxd=9 and it will get to Ra=10^8. (In reality, I ran tests with 4 separate runs, 10^k, k=5,6,7,8. I then a created "high_ray.usr" file that would march through this sequence in a single run...) Once you establish the flow at the desired Ra, you can then bump lx1 to say 7 or 8 --- that should be sufficient for Ra=10^8 I think. Even lx1=5 is looking pretty good with the given mesh. Also, you can reduce the CFL in the .rea file and increase Torder to 3, so that you will increase your temporal accuracy. I initially set the parameters so that it would march quickly to Ra=10^8. The high-Ra test case uses periodic bcs and a uniform mesh in X. If you want vertical walls then you should likely use a nonuniform mesh in X. The "high_ray.box" file shows how the nonuniform mesh in Y is created. A similar set up could be used for nonuniformity in both X and Y. Paul On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Thanks for the reply. I have a doubt whether one should increase the > polynomial order or the number of elements with a fixed order for this case. > As I understand from your illustration of the rotating cone case, increasing > the polynomial order leads to a much better solution than with the same > number of points generated using more elements with a lower order polynomial. > > Also how do I use the fast tensor-product solver? Is there some flag that I > need to turn on? > > Regards, > Mani chandra > On 05/15/2010 09:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> Hi Mani, >> >> I've not tried to go this high yet, but there are several std >> techniques to pushing the envelope. >> >> First, you should try to get an estimate of your expected resolution >> requirements at the target Ra. Then, guess that you might want to >> run that simulation at say, lx1=10 or 12; and build the corresponding >> mesh (number of elements in x and y); but start the compuation at >> much lower Ra, with lx1=4, say. >> >> Then work your way up in Ra, say by a factor of 10 in each successive >> run, while also increasing lx1 as needed. >> >> Note that for the flow in a box, you might find it faster to use >> the fast tensor-product solver for the pressure, if using the Pn-Pn-2 >> method --- this is not always the case, but for some very difficult >> problems (e.g., highly refined meshes), it does work better. >> >> Paul >> >> >> On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> I'm trying to simulate RB convection in a 2D box of aspect ratio 2:1. >>> I'd like to simulate cases with Rayleigh numbers of the order of 10^7 - >>> 10^8. But I'm barely able to do 10^5 and that too with a time step of >>> 10^-6. For the mesh I took 8 spectral elements in the x direction and 4 >>> spectral elements in the y direction with 48 points within each of them. >>> Is there any way one can reach higher Ra numbers? >>> >>> 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 Sun May 16 00:29:07 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 16 May 2010 10:59:07 +0530 Subject: [Nek5000-users] [*] Re: [*] Re: RB convection with high Rayleigh numbers In-Reply-To: References: <4BEE2C8B.2070205@iitk.ac.in> <4BEEEF5A.3080303@iitk.ac.in> Message-ID: <4BEF82A3.9030502@iitk.ac.in> Hi Paul, Thank you for your time on this problem. The geometry is a 2D box with no-slip velocity boundary conditions on all sides and the temperature boundary conditions are insulating on the side walls and the usual fixed temperatures on the top and bottom walls. I will try out your code immediately. Regards, Mani chandra On 05/16/2010 09:14 AM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Mani, > > I've added an example of a case that should run out to Ra=10^8 > in the /benard directory of the repo (high_ray.blah is the case). > > I've run this with lx1=5, lxd=9 and it will get to Ra=10^8. > (In reality, I ran tests with 4 separate runs, 10^k, k=5,6,7,8. I then > a created "high_ray.usr" file that would march through this sequence > in a single run...) > > Once you establish the flow at the desired Ra, you can then > bump lx1 to say 7 or 8 --- that should be sufficient for Ra=10^8 > I think. Even lx1=5 is looking pretty good with the given mesh. > > > Also, you can reduce the CFL in the .rea file and increase Torder > to 3, so that you will increase your temporal accuracy. > > I initially set the parameters so that it would march quickly > to Ra=10^8. > > The high-Ra test case uses periodic bcs and a uniform mesh in X. > If you want vertical walls then you should likely use a nonuniform > mesh in X. The "high_ray.box" file shows how the nonuniform mesh in > Y is created. A similar set up could be used for nonuniformity > in both X and Y. > > > Paul > > > > On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Paul, >> >> Thanks for the reply. I have a doubt whether one should increase >> the polynomial order or the number of elements with a fixed order for >> this case. As I understand from your illustration of the rotating >> cone case, increasing the polynomial order leads to a much better >> solution than with the same number of points generated using more >> elements with a lower order polynomial. >> >> Also how do I use the fast tensor-product solver? Is there some flag >> that I need to turn on? >> >> Regards, >> Mani chandra >> On 05/15/2010 09:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>> Hi Mani, >>> >>> I've not tried to go this high yet, but there are several std >>> techniques to pushing the envelope. >>> >>> First, you should try to get an estimate of your expected resolution >>> requirements at the target Ra. Then, guess that you might want to >>> run that simulation at say, lx1=10 or 12; and build the corresponding >>> mesh (number of elements in x and y); but start the compuation at >>> much lower Ra, with lx1=4, say. >>> >>> Then work your way up in Ra, say by a factor of 10 in each successive >>> run, while also increasing lx1 as needed. >>> >>> Note that for the flow in a box, you might find it faster to use >>> the fast tensor-product solver for the pressure, if using the Pn-Pn-2 >>> method --- this is not always the case, but for some very difficult >>> problems (e.g., highly refined meshes), it does work better. >>> >>> Paul >>> >>> >>> On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi, >>>> >>>> I'm trying to simulate RB convection in a 2D box of aspect ratio >>>> 2:1. I'd like to simulate cases with Rayleigh numbers of the order >>>> of 10^7 - 10^8. But I'm barely able to do 10^5 and that too with a >>>> time step of 10^-6. For the mesh I took 8 spectral elements in the >>>> x direction and 4 spectral elements in the y direction with 48 >>>> points within each of them. Is there any way one can reach higher >>>> Ra numbers? >>>> >>>> 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 Sun May 16 06:13:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 16 May 2010 06:13:00 -0500 (CDT) Subject: [Nek5000-users] [*] Re: [*] Re: RB convection with high Rayleigh numbers In-Reply-To: <4BEF82A3.9030502@iitk.ac.in> References: <4BEE2C8B.2070205@iitk.ac.in> <4BEEEF5A.3080303@iitk.ac.in> <4BEF82A3.9030502@iitk.ac.in> Message-ID: Hi Mani, Note that your other email did not go to the users list because of the size of the attachments. I got it though and tried it. It looks like the following steps should work --- .reduce COURANT to 2.0 instead of 5.0 .set TORDER=2 .set initial DT (param 12) to .001 .reduce lx1 to 5 and lxd to 8 in your SIZE file I tried this and it seems to work ok, save that I ran my case w/ Pr=1 (param 2). Your case w/ p2=6.8 is a bit harder, so you may need to also use the reduced initial Ra values per your .usr file. Once you are at the target Ra, you can increase lx1, lxd, and Torder, then restart. The issue with the walls is that they trap the fluid in the corner. Then when the heating is turned on you get a stagnant hot spot that builds up until it finally goes unstable --- this happens on a timescale faster than the early-time convective timescale (which is relatively long until the flow really starts moving), so the explicit treatment of the buoyancy leads to an instability. Reducing Courant to 2.0 instead of 5.0 forces nek5000 to reduce dt more severely. Note that we're able to exceed CFL of unity for convection because of the OIFS convective time integrator. The explicit Boussinesq forcing, however, has it's own timestep restriction and tends to dominate the stability constraints at early times until the flow is moving. Paul On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Thank you for your time on this problem. The geometry is a 2D box with > no-slip velocity boundary conditions on all sides and the temperature > boundary conditions are insulating on the side walls and the usual fixed > temperatures on the top and bottom walls. I will try out your code > immediately. > > Regards, > Mani chandra > On 05/16/2010 09:14 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >> Hi Mani, >> >> I've added an example of a case that should run out to Ra=10^8 >> in the /benard directory of the repo (high_ray.blah is the case). >> >> I've run this with lx1=5, lxd=9 and it will get to Ra=10^8. >> (In reality, I ran tests with 4 separate runs, 10^k, k=5,6,7,8. I then a >> created "high_ray.usr" file that would march through this sequence in a >> single run...) >> >> Once you establish the flow at the desired Ra, you can then >> bump lx1 to say 7 or 8 --- that should be sufficient for Ra=10^8 >> I think. Even lx1=5 is looking pretty good with the given mesh. >> >> >> Also, you can reduce the CFL in the .rea file and increase Torder >> to 3, so that you will increase your temporal accuracy. >> >> I initially set the parameters so that it would march quickly >> to Ra=10^8. >> >> The high-Ra test case uses periodic bcs and a uniform mesh in X. >> If you want vertical walls then you should likely use a nonuniform >> mesh in X. The "high_ray.box" file shows how the nonuniform mesh in Y is >> created. A similar set up could be used for nonuniformity >> in both X and Y. >> >> >> Paul >> >> >> >> On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Paul, >>> >>> Thanks for the reply. I have a doubt whether one should increase the >>> polynomial order or the number of elements with a fixed order for this >>> case. As I understand from your illustration of the rotating cone case, >>> increasing the polynomial order leads to a much better solution than with >>> the same number of points generated using more elements with a lower order >>> polynomial. >>> >>> Also how do I use the fast tensor-product solver? Is there some flag that >>> I need to turn on? >>> >>> Regards, >>> Mani chandra >>> On 05/15/2010 09:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>> Hi Mani, >>>> >>>> I've not tried to go this high yet, but there are several std >>>> techniques to pushing the envelope. >>>> >>>> First, you should try to get an estimate of your expected resolution >>>> requirements at the target Ra. Then, guess that you might want to >>>> run that simulation at say, lx1=10 or 12; and build the corresponding >>>> mesh (number of elements in x and y); but start the compuation at >>>> much lower Ra, with lx1=4, say. >>>> >>>> Then work your way up in Ra, say by a factor of 10 in each successive >>>> run, while also increasing lx1 as needed. >>>> >>>> Note that for the flow in a box, you might find it faster to use >>>> the fast tensor-product solver for the pressure, if using the Pn-Pn-2 >>>> method --- this is not always the case, but for some very difficult >>>> problems (e.g., highly refined meshes), it does work better. >>>> >>>> Paul >>>> >>>> >>>> On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm trying to simulate RB convection in a 2D box of aspect ratio 2:1. >>>>> I'd like to simulate cases with Rayleigh numbers of the order of 10^7 - >>>>> 10^8. But I'm barely able to do 10^5 and that too with a time step of >>>>> 10^-6. For the mesh I took 8 spectral elements in the x direction and 4 >>>>> spectral elements in the y direction with 48 points within each of them. >>>>> Is there any way one can reach higher Ra numbers? >>>>> >>>>> 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 >> > > _______________________________________________ > 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 May 16 09:25:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 16 May 2010 09:25:04 -0500 (CDT) Subject: [Nek5000-users] RB convection with high Rayleigh numbers In-Reply-To: References: <4BEE2C8B.2070205@iitk.ac.in> <4BEEEF5A.3080303@iitk.ac.in> <4BEF82A3.9030502@iitk.ac.in> Message-ID: Hi Mani, I find that I need to use something like: argt = (t8-time)/0.05 if (time.gt.t8) ra = 1.e7 + 0.9e8*(1-exp(argt)) to get the run to transition smoothly to the higher Ra values, but this seems to work. Paul On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Mani, > > Note that your other email did not go to the users list because > of the size of the attachments. I got it though and tried it. > > It looks like the following steps should work --- > > .reduce COURANT to 2.0 instead of 5.0 > .set TORDER=2 > .set initial DT (param 12) to .001 > .reduce lx1 to 5 and lxd to 8 in your SIZE file > > > I tried this and it seems to work ok, save that I ran my > case w/ Pr=1 (param 2). > > Your case w/ p2=6.8 is a bit harder, so you may need to also > use the reduced initial Ra values per your .usr file. > > Once you are at the target Ra, you can increase lx1, lxd, and > Torder, then restart. > > > The issue with the walls is that they trap the fluid in the > corner. Then when the heating is turned on you get a stagnant hot spot that > builds up until it finally goes unstable --- this happens on a timescale > faster than the > early-time convective timescale (which is relatively long > until the flow really starts moving), so the explicit > treatment of the buoyancy leads to an instability. > > Reducing Courant to 2.0 instead of 5.0 forces nek5000 to > reduce dt more severely. Note that we're able to exceed > CFL of unity for convection because of the OIFS convective > time integrator. The explicit Boussinesq forcing, however, > has it's own timestep restriction and tends to dominate the > stability constraints at early times until the flow is moving. > > Paul > > > > > > On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Paul, >> >> Thank you for your time on this problem. The geometry is a 2D box with >> no-slip velocity boundary conditions on all sides and the temperature >> boundary conditions are insulating on the side walls and the usual fixed >> temperatures on the top and bottom walls. I will try out your code >> immediately. >> >> Regards, >> Mani chandra >> On 05/16/2010 09:14 AM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>> Hi Mani, >>> >>> I've added an example of a case that should run out to Ra=10^8 >>> in the /benard directory of the repo (high_ray.blah is the case). >>> >>> I've run this with lx1=5, lxd=9 and it will get to Ra=10^8. >>> (In reality, I ran tests with 4 separate runs, 10^k, k=5,6,7,8. I then a >>> created "high_ray.usr" file that would march through this sequence in a >>> single run...) >>> >>> Once you establish the flow at the desired Ra, you can then >>> bump lx1 to say 7 or 8 --- that should be sufficient for Ra=10^8 >>> I think. Even lx1=5 is looking pretty good with the given mesh. >>> >>> >>> Also, you can reduce the CFL in the .rea file and increase Torder >>> to 3, so that you will increase your temporal accuracy. >>> >>> I initially set the parameters so that it would march quickly >>> to Ra=10^8. >>> >>> The high-Ra test case uses periodic bcs and a uniform mesh in X. >>> If you want vertical walls then you should likely use a nonuniform >>> mesh in X. The "high_ray.box" file shows how the nonuniform mesh in Y is >>> created. A similar set up could be used for nonuniformity >>> in both X and Y. >>> >>> >>> Paul >>> >>> >>> >>> On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi Paul, >>>> >>>> Thanks for the reply. I have a doubt whether one should increase the >>>> polynomial order or the number of elements with a fixed order for this >>>> case. As I understand from your illustration of the rotating cone case, >>>> increasing the polynomial order leads to a much better solution than with >>>> the same number of points generated using more elements with a lower >>>> order polynomial. >>>> >>>> Also how do I use the fast tensor-product solver? Is there some flag that >>>> I need to turn on? >>>> >>>> Regards, >>>> Mani chandra >>>> On 05/15/2010 09:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>> Hi Mani, >>>>> >>>>> I've not tried to go this high yet, but there are several std >>>>> techniques to pushing the envelope. >>>>> >>>>> First, you should try to get an estimate of your expected resolution >>>>> requirements at the target Ra. Then, guess that you might want to >>>>> run that simulation at say, lx1=10 or 12; and build the corresponding >>>>> mesh (number of elements in x and y); but start the compuation at >>>>> much lower Ra, with lx1=4, say. >>>>> >>>>> Then work your way up in Ra, say by a factor of 10 in each successive >>>>> run, while also increasing lx1 as needed. >>>>> >>>>> Note that for the flow in a box, you might find it faster to use >>>>> the fast tensor-product solver for the pressure, if using the Pn-Pn-2 >>>>> method --- this is not always the case, but for some very difficult >>>>> problems (e.g., highly refined meshes), it does work better. >>>>> >>>>> Paul >>>>> >>>>> >>>>> On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm trying to simulate RB convection in a 2D box of aspect ratio >>>>>> 2:1. I'd like to simulate cases with Rayleigh numbers of the order of >>>>>> 10^7 - 10^8. But I'm barely able to do 10^5 and that too with a time >>>>>> step of 10^-6. For the mesh I took 8 spectral elements in the x >>>>>> direction and 4 spectral elements in the y direction with 48 points >>>>>> within each of them. Is there any way one can reach higher Ra numbers? >>>>>> >>>>>> 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 >>> >> >> _______________________________________________ >> 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 May 16 10:35:19 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 16 May 2010 21:05:19 +0530 Subject: [Nek5000-users] [*] Re: RB convection with high Rayleigh numbers In-Reply-To: References: <4BEE2C8B.2070205@iitk.ac.in> <4BEEEF5A.3080303@iitk.ac.in> <4BEF82A3.9030502@iitk.ac.in> Message-ID: <4BF010B7.1060405@iitk.ac.in> Hi Paul, The runs are coming along very nicely (so far). I'm right now in Ra = 10^7 and see some very interesting dynamics. Thanks for all the advice (on a Sunday!). Regards, Mani chandra On 05/16/2010 07:55 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Mani, > > I find that I need to use something like: > > argt = (t8-time)/0.05 > if (time.gt.t8) ra = 1.e7 + 0.9e8*(1-exp(argt)) > > to get the run to transition smoothly to the higher Ra > values, but this seems to work. > > Paul > > > > On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> >> Hi Mani, >> >> Note that your other email did not go to the users list because >> of the size of the attachments. I got it though and tried it. >> >> It looks like the following steps should work --- >> >> .reduce COURANT to 2.0 instead of 5.0 >> .set TORDER=2 >> .set initial DT (param 12) to .001 >> .reduce lx1 to 5 and lxd to 8 in your SIZE file >> >> >> I tried this and it seems to work ok, save that I ran my >> case w/ Pr=1 (param 2). >> >> Your case w/ p2=6.8 is a bit harder, so you may need to also >> use the reduced initial Ra values per your .usr file. >> >> Once you are at the target Ra, you can increase lx1, lxd, and >> Torder, then restart. >> >> >> The issue with the walls is that they trap the fluid in the >> corner. Then when the heating is turned on you get a stagnant hot >> spot that builds up until it finally goes unstable --- this happens >> on a timescale faster than the >> early-time convective timescale (which is relatively long >> until the flow really starts moving), so the explicit >> treatment of the buoyancy leads to an instability. >> >> Reducing Courant to 2.0 instead of 5.0 forces nek5000 to >> reduce dt more severely. Note that we're able to exceed >> CFL of unity for convection because of the OIFS convective >> time integrator. The explicit Boussinesq forcing, however, >> has it's own timestep restriction and tends to dominate the >> stability constraints at early times until the flow is moving. >> >> Paul >> >> >> >> >> >> On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Paul, >>> >>> Thank you for your time on this problem. The geometry is a 2D box >>> with no-slip velocity boundary conditions on all sides and the >>> temperature boundary conditions are insulating on the side walls and >>> the usual fixed temperatures on the top and bottom walls. I will try >>> out your code immediately. >>> >>> Regards, >>> Mani chandra >>> On 05/16/2010 09:14 AM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>> Hi Mani, >>>> >>>> I've added an example of a case that should run out to Ra=10^8 >>>> in the /benard directory of the repo (high_ray.blah is the case). >>>> >>>> I've run this with lx1=5, lxd=9 and it will get to Ra=10^8. >>>> (In reality, I ran tests with 4 separate runs, 10^k, k=5,6,7,8. I >>>> then a created "high_ray.usr" file that would march through this >>>> sequence in a single run...) >>>> >>>> Once you establish the flow at the desired Ra, you can then >>>> bump lx1 to say 7 or 8 --- that should be sufficient for Ra=10^8 >>>> I think. Even lx1=5 is looking pretty good with the given mesh. >>>> >>>> >>>> Also, you can reduce the CFL in the .rea file and increase Torder >>>> to 3, so that you will increase your temporal accuracy. >>>> >>>> I initially set the parameters so that it would march quickly >>>> to Ra=10^8. >>>> >>>> The high-Ra test case uses periodic bcs and a uniform mesh in X. >>>> If you want vertical walls then you should likely use a nonuniform >>>> mesh in X. The "high_ray.box" file shows how the nonuniform mesh >>>> in Y is created. A similar set up could be used for nonuniformity >>>> in both X and Y. >>>> >>>> >>>> Paul >>>> >>>> >>>> >>>> On Sun, 16 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> Thanks for the reply. I have a doubt whether one should >>>>> increase the polynomial order or the number of elements with a >>>>> fixed order for this case. As I understand from your illustration >>>>> of the rotating cone case, increasing the polynomial order leads >>>>> to a much better solution than with the same number of points >>>>> generated using more elements with a lower order polynomial. >>>>> >>>>> Also how do I use the fast tensor-product solver? Is there some >>>>> flag that I need to turn on? >>>>> >>>>> Regards, >>>>> Mani chandra >>>>> On 05/15/2010 09:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> >>>>>> Hi Mani, >>>>>> >>>>>> I've not tried to go this high yet, but there are several std >>>>>> techniques to pushing the envelope. >>>>>> >>>>>> First, you should try to get an estimate of your expected resolution >>>>>> requirements at the target Ra. Then, guess that you might want to >>>>>> run that simulation at say, lx1=10 or 12; and build the >>>>>> corresponding >>>>>> mesh (number of elements in x and y); but start the compuation at >>>>>> much lower Ra, with lx1=4, say. >>>>>> >>>>>> Then work your way up in Ra, say by a factor of 10 in each >>>>>> successive >>>>>> run, while also increasing lx1 as needed. >>>>>> >>>>>> Note that for the flow in a box, you might find it faster to use >>>>>> the fast tensor-product solver for the pressure, if using the >>>>>> Pn-Pn-2 >>>>>> method --- this is not always the case, but for some very difficult >>>>>> problems (e.g., highly refined meshes), it does work better. >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> On Sat, 15 May 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm trying to simulate RB convection in a 2D box of aspect >>>>>>> ratio 2:1. I'd like to simulate cases with Rayleigh numbers of >>>>>>> the order of 10^7 - 10^8. But I'm barely able to do 10^5 and >>>>>>> that too with a time step of 10^-6. For the mesh I took 8 >>>>>>> spectral elements in the x direction and 4 spectral elements in >>>>>>> the y direction with 48 points within each of them. Is there any >>>>>>> way one can reach higher Ra numbers? >>>>>>> >>>>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 May 17 08:42:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 17 May 2010 19:12:11 +0530 Subject: [Nek5000-users] MHD Message-ID: <4BF147B3.3060700@iitk.ac.in> Dear Paul and Stephan, I'd like to know how to setup nek5000 to solve for MHD equations. Maybe an example? Regards, Mani chandra From nek5000-users at lists.mcs.anl.gov Mon May 17 09:26:32 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 17 May 2010 16:26:32 +0200 Subject: [Nek5000-users] MPI Profiling Message-ID: <530A2DC6-D0A1-4878-A807-08A50B7AB1CC@lav.mavt.ethz.ch> Dear all, I added some automatic MPI profiling capabilities to Nek. To simplify the implementation I used weak aliases for the MPI wrappers. Unfortunately those are not supported on all platforms (e.g. MAC OS X) so you may have to disable the timing module (see makenek). I will work on a more portable solution in the meantime. Cheers, Stefan From nek5000-users at lists.mcs.anl.gov Mon May 17 10:41:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 17 May 2010 17:41:11 +0200 Subject: [Nek5000-users] change order when restarting Message-ID: <4BF16397.2070702@kit.edu> dear neks, is it possible to rise/reduce the order (NORDER) when i restart my run?? respectively is nek capable to interpolate a output file from a lower to a higher order when i use the same elements?? best, fred From nek5000-users at lists.mcs.anl.gov Mon May 17 10:44:05 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 17 May 2010 17:44:05 +0200 Subject: [Nek5000-users] change order when restarting In-Reply-To: <4BF16397.2070702@kit.edu> References: <4BF16397.2070702@kit.edu> Message-ID: <1C9701C9-500E-47A8-A490-75BE8D6EE5E4@lav.mavt.ethz.ch> Yes, but due to memory constraints the following relation must hold: N_new >= N_old-6 hth, Stefan On May 17, 2010, at 5:41 PM, nek5000-users at lists.mcs.anl.gov wrote: > dear neks, > > is it possible to rise/reduce the order (NORDER) when i restart my run?? respectively is nek capable to interpolate a output file from a lower to a higher order when i use the same elements?? > > 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 Mon May 17 10:46:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 17 May 2010 17:46:27 +0200 Subject: [Nek5000-users] change order when restarting In-Reply-To: <1C9701C9-500E-47A8-A490-75BE8D6EE5E4@lav.mavt.ethz.ch> References: <4BF16397.2070702@kit.edu> <1C9701C9-500E-47A8-A490-75BE8D6EE5E4@lav.mavt.ethz.ch> Message-ID: <43E418AF-6669-4C20-B32F-CA04DE90F954@lav.mavt.ethz.ch> Also keep in mind that NORDER (specified in the rea-file) is not used by the solver. The polynomial order has to be specified by lx1,ly1,lz1 in the SIZE file. Stefan On May 17, 2010, at 5:44 PM, nek5000-users at lists.mcs.anl.gov wrote: > Yes, but due to memory constraints the following relation must hold: > > N_new >= N_old-6 > > hth, > Stefan > > > On May 17, 2010, at 5:41 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> dear neks, >> >> is it possible to rise/reduce the order (NORDER) when i restart my run?? respectively is nek capable to interpolate a output file from a lower to a higher order when i use the same elements?? >> >> best, fred >> _______________________________________________ >> 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 May 17 12:59:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 17 May 2010 12:59:59 -0500 (CDT) Subject: [Nek5000-users] MHD In-Reply-To: <4BF147B3.3060700@iitk.ac.in> References: <4BF147B3.3060700@iitk.ac.in> Message-ID: 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 > From nek5000-users at lists.mcs.anl.gov Mon May 17 13:17:37 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 17 May 2010 23:47:37 +0530 Subject: [Nek5000-users] [*] Re: MHD In-Reply-To: References: <4BF147B3.3060700@iitk.ac.in> Message-ID: <4BF18841.9070300@iitk.ac.in> Thanks Aleks! 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 Tue May 18 06:06:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 18 May 2010 06:06:00 -0500 (CDT) Subject: [Nek5000-users] right-handed box elements In-Reply-To: References: Message-ID: Hi Mani, Re. your question about right-handed elements, it's important that your x- y- and z- input values in the .box file are ascending. Paul From nek5000-users at lists.mcs.anl.gov Tue May 18 06:57:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 18 May 2010 17:27:11 +0530 Subject: [Nek5000-users] [*] right-handed box elements In-Reply-To: References: Message-ID: <4BF28097.7000604@iitk.ac.in> On 05/18/2010 04:36 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Mani, > > Re. your question about right-handed elements, it's important that > your x- y- and z- input values in the .box file are ascending. > > Paul > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > Hi Paul, I checked and indeed all my x, y and z values are ascending. For ex: Box 1 -8 -8 -8 0.0 0.2 1.25 0.0 0.2 1.25 0.0 0.2 1.25 W , ,W , ,W ,??? I , ,I , ,t ,??? So, this particular box starts at x=0 and ends at x=.2 and so on for y and z. Is this the correct format? This is what I did for all 27 boxes. P.S Am sorry about the oversized mail. I tried to compress it and get it to under 512 kb but it looks like I miscalculated. Regards, Mani chandra From nek5000-users at lists.mcs.anl.gov Tue May 18 10:41:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 18 May 2010 10:41:00 -0500 Subject: [Nek5000-users] Hpts subroutine Message-ID: Hello, This email is in regards to the hpts subroutine that was added to the repo 513 and subsequent versions. A part of the code snippet from postpro.f ( subroutine hpts ) is pasted below : call copy(wrk(1,1,1,1,2),vy,ntot) if(if3d) call copy(wrk(1,1,1,1,2),vz,ntot) could the second line be " if(if3d) call copy(wrk(1,1,1,1,3),vz,ntot) " else vz would then be overwritten over vy ? Along the same lines, I would like to know what one would have to change to output the pressure values as well. Thanks Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 18 10:52:05 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 18 May 2010 17:52:05 +0200 Subject: [Nek5000-users] Hpts subroutine In-Reply-To: References: Message-ID: Yes you're right this is a bug. I just coded that up very quickly and haven't had the time to check it. I will fix it and add support for pressure. Stefan On May 18, 2010, at 5:41 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > This email is in regards to the hpts subroutine that was added to the repo 513 and subsequent versions. > A part of the code snippet from postpro.f ( subroutine hpts ) is pasted below : > > > > call copy(wrk(1,1,1,1,2),vy,ntot) > if(if3d) call copy(wrk(1,1,1,1,2),vz,ntot) > > > > could the second line be " if(if3d) call copy(wrk(1,1,1,1,3),vz,ntot) " else vz would then be overwritten over vy ? > > Along the same lines, I would like to know what one would have to change to output the pressure values as well. > > Thanks > 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 Tue May 18 12:28:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 18 May 2010 22:58:16 +0530 Subject: [Nek5000-users] interpolation example does not work Message-ID: <4BF2CE30.8090002@iitk.ac.in> Hi, The interpolation example given in the wiki gives a segmentation fault. A debugger reveals that the function as defined in postpro.f takes in 9 arguments whereas in the example, only 7 are given. What should be the last two arguments? The debug report is reproduced below: Program received signal SIGSEGV, Segmentation fault. 0x00000000005453fa in intpts (fieldin=..., nfld=2, itl=..., mi=4, rtl=..., mr=7, n=1, iffind=Cannot access memory at address 0x100000001 ) at /home/mc/nek5_svn/trunk/nek/postpro.f:436 436 subroutine intpts(fieldin,nfld,iTl,mi,rTl,mr,n,iffind,ih) Thanks, Mani chandra From nek5000-users at lists.mcs.anl.gov Tue May 18 12:28:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 18 May 2010 19:28:27 +0200 Subject: [Nek5000-users] interpolation example does not work In-Reply-To: <4BF2CE30.8090002@iitk.ac.in> References: <4BF2CE30.8090002@iitk.ac.in> Message-ID: Mani, yes, the API of the interpolation routines have changed and I am in the process to update the Wiki etc. Hang on Stefan On May 18, 2010, at 7:28 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > The interpolation example given in the wiki gives a segmentation fault. A debugger reveals that the function as defined in postpro.f takes in 9 arguments whereas in the example, only 7 are given. What should be the last two arguments? > > The debug report is reproduced below: > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000005453fa in intpts (fieldin=..., nfld=2, itl=..., mi=4, rtl=..., mr=7, n=1, iffind=Cannot access memory at address 0x100000001 > ) at /home/mc/nek5_svn/trunk/nek/postpro.f:436 > 436 subroutine intpts(fieldin,nfld,iTl,mi,rTl,mr,n,iffind,ih) > > > Thanks, > Mani chandra > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue May 18 13:08:37 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 18 May 2010 20:08:37 +0200 Subject: [Nek5000-users] interpolation example does not work In-Reply-To: References: <4BF2CE30.8090002@iitk.ac.in> Message-ID: <3028B920-C7EA-4E9B-8DC7-972A75B2FC20@lav.mavt.ethz.ch> Mani, I just updated the repo and the Wiki. Why don't you give it a whirl. Stefan On May 18, 2010, at 7:28 PM, nek5000-users at lists.mcs.anl.gov wrote: > Mani, > > yes, the API of the interpolation routines have changed and I am in the process to update the Wiki etc. > > Hang on > Stefan > > On May 18, 2010, at 7:28 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> The interpolation example given in the wiki gives a segmentation fault. A debugger reveals that the function as defined in postpro.f takes in 9 arguments whereas in the example, only 7 are given. What should be the last two arguments? >> >> The debug report is reproduced below: >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00000000005453fa in intpts (fieldin=..., nfld=2, itl=..., mi=4, rtl=..., mr=7, n=1, iffind=Cannot access memory at address 0x100000001 >> ) at /home/mc/nek5_svn/trunk/nek/postpro.f:436 >> 436 subroutine intpts(fieldin,nfld,iTl,mi,rTl,mr,n,iffind,ih) >> >> >> Thanks, >> 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 Tue May 18 13:17:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 18 May 2010 20:17:34 +0200 Subject: [Nek5000-users] interpolation example does not work In-Reply-To: <3028B920-C7EA-4E9B-8DC7-972A75B2FC20@lav.mavt.ethz.ch> References: <4BF2CE30.8090002@iitk.ac.in> <3028B920-C7EA-4E9B-8DC7-972A75B2FC20@lav.mavt.ethz.ch> Message-ID: Note hpts() will replace at some point the old history point stuff but some additional work is needed. For the moment the pressure is not automatically mapped but the following should work: call prepost_map(0) call hpts() call prepost_map(1) Later on, we call hpts() in prepost() where we map the pressure anyway. hth, Stefan On May 18, 2010, at 8:08 PM, nek5000-users at lists.mcs.anl.gov wrote: > Mani, > > I just updated the repo and the Wiki. Why don't you give it a whirl. > > Stefan > > On May 18, 2010, at 7:28 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Mani, >> >> yes, the API of the interpolation routines have changed and I am in the process to update the Wiki etc. >> >> Hang on >> Stefan >> >> On May 18, 2010, at 7:28 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> The interpolation example given in the wiki gives a segmentation fault. A debugger reveals that the function as defined in postpro.f takes in 9 arguments whereas in the example, only 7 are given. What should be the last two arguments? >>> >>> The debug report is reproduced below: >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x00000000005453fa in intpts (fieldin=..., nfld=2, itl=..., mi=4, rtl=..., mr=7, n=1, iffind=Cannot access memory at address 0x100000001 >>> ) at /home/mc/nek5_svn/trunk/nek/postpro.f:436 >>> 436 subroutine intpts(fieldin,nfld,iTl,mi,rTl,mr,n,iffind,ih) >>> >>> >>> Thanks, >>> 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 May 18 23:36:40 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 19 May 2010 10:06:40 +0530 Subject: [Nek5000-users] [*] Re: interpolation example does not work In-Reply-To: <3028B920-C7EA-4E9B-8DC7-972A75B2FC20@lav.mavt.ethz.ch> References: <4BF2CE30.8090002@iitk.ac.in> <3028B920-C7EA-4E9B-8DC7-972A75B2FC20@lav.mavt.ethz.ch> Message-ID: <4BF36AD8.2040402@iitk.ac.in> Thank you Stefan. Regards, Mani chandra On 05/18/2010 11:38 PM, nek5000-users at lists.mcs.anl.gov wrote: > Mani, > > I just updated the repo and the Wiki. Why don't you give it a whirl. > > Stefan > > On May 18, 2010, at 7:28 PM, nek5000-users at lists.mcs.anl.gov wrote: > > >> Mani, >> >> yes, the API of the interpolation routines have changed and I am in the process to update the Wiki etc. >> >> Hang on >> Stefan >> >> On May 18, 2010, at 7:28 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> >>> Hi, >>> >>> The interpolation example given in the wiki gives a segmentation fault. A debugger reveals that the function as defined in postpro.f takes in 9 arguments whereas in the example, only 7 are given. What should be the last two arguments? >>> >>> The debug report is reproduced below: >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x00000000005453fa in intpts (fieldin=..., nfld=2, itl=..., mi=4, rtl=..., mr=7, n=1, iffind=Cannot access memory at address 0x100000001 >>> ) at /home/mc/nek5_svn/trunk/nek/postpro.f:436 >>> 436 subroutine intpts(fieldin,nfld,iTl,mi,rTl,mr,n,iffind,ih) >>> >>> >>> Thanks, >>> 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 Wed May 19 01:39:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 19 May 2010 12:09:04 +0530 Subject: [Nek5000-users] [*] Re: [*] right-handed box elements In-Reply-To: <4BF28097.7000604@iitk.ac.in> References: <4BF28097.7000604@iitk.ac.in> Message-ID: <4BF38788.2080608@iitk.ac.in> Hi Paul, Got the error! Boxes 9, 18 and 27 were in the wrong order. Thanks for the info. Regards, Mani chandra On 05/18/2010 05:27 PM, nek5000-users at lists.mcs.anl.gov wrote: > On 05/18/2010 04:36 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> Hi Mani, >> >> Re. your question about right-handed elements, it's important that >> your x- y- and z- input values in the .box file are ascending. >> >> Paul >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > Hi Paul, > > I checked and indeed all my x, y and z values are ascending. For ex: > > Box 1 > -8 -8 -8 > 0.0 0.2 1.25 > 0.0 0.2 1.25 > 0.0 0.2 1.25 > W , ,W , ,W ,??? > I , ,I , ,t ,??? > > So, this particular box starts at x=0 and ends at x=.2 and so on for y > and z. Is this the correct format? This is what I did for all 27 boxes. > > P.S Am sorry about the oversized mail. I tried to compress it and get > it to under 512 kb but it looks like I miscalculated. > > Regards, > Mani chandra > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed May 19 04:48:05 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 19 May 2010 11:48:05 +0200 Subject: [Nek5000-users] new build system Message-ID: <177CE4DE-E6DA-4F14-89FC-F6026ECB12D7@lav.mavt.ethz.ch> Dear Nek users, we have an ongoing discussion about a new build system for Nek. What do you think about the current build system? How easy is it to compile Nek? What can be improved / What's missing? One major complain was that the current build system does not follow the standard procedure of configure; make; make install. We may want to follow the standard more closely. One idea would be to have a nekconfigure.in file to specify the compiler, flags, etc. and you need to run nekconfigure to create a makefile for your environment. After that you can use the classical GNU make utility to compile the code. Your feedback is welcome! Cheers, Stefan From nek5000-users at lists.mcs.anl.gov Wed May 19 06:04:08 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 19 May 2010 16:34:08 +0530 Subject: [Nek5000-users] [*] new build system In-Reply-To: <177CE4DE-E6DA-4F14-89FC-F6026ECB12D7@lav.mavt.ethz.ch> References: <177CE4DE-E6DA-4F14-89FC-F6026ECB12D7@lav.mavt.ethz.ch> Message-ID: <4BF3C5A8.2020604@iitk.ac.in> Hi, So far I've had no problems with the current build system. Infact it was quite easy to use, given that we only need to change options in the makenek script to fine tune the build. But if you want to change it, how about using the cmake system? In addition to doing the same thing as the proposed nekconfigure.in, it give pretty output while compiling:P. Regards, Mani chandra On 05/19/2010 03:18 PM, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nek users, > > we have an ongoing discussion about a new build system for Nek. > > What do you think about the current build system? > How easy is it to compile Nek? > What can be improved / What's missing? > > One major complain was that the current build system does not follow the standard procedure of configure; make; make install. > > We may want to follow the standard more closely. One idea would be to have a nekconfigure.in file to specify the compiler, flags, etc. and you need to run nekconfigure to create a makefile for your environment. After that you can use the classical GNU make utility to compile the code. > > Your feedback is welcome! > > > Cheers, > Stefan > > > > _______________________________________________ > 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 May 19 06:07:07 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 19 May 2010 13:07:07 +0200 Subject: [Nek5000-users] [*] new build system In-Reply-To: <4BF3C5A8.2020604@iitk.ac.in> References: <177CE4DE-E6DA-4F14-89FC-F6026ECB12D7@lav.mavt.ethz.ch> <4BF3C5A8.2020604@iitk.ac.in> Message-ID: Well cmake is not available on all machines and we don't want to start distributing it with the source. Thanks for your feedback. Stefan On May 19, 2010, at 1:04 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > So far I've had no problems with the current build system. Infact it was quite easy to use, given that we only need to change options in the makenek script to fine tune the build. > > But if you want to change it, how about using the cmake system? In addition to doing the same thing as the proposed nekconfigure.in, it give pretty output while compiling:P. > > Regards, > Mani chandra > On 05/19/2010 03:18 PM, nek5000-users at lists.mcs.anl.gov wrote: >> Dear Nek users, >> >> we have an ongoing discussion about a new build system for Nek. >> >> What do you think about the current build system? >> How easy is it to compile Nek? >> What can be improved / What's missing? >> >> One major complain was that the current build system does not follow the standard procedure of configure; make; make install. >> >> We may want to follow the standard more closely. One idea would be to have a nekconfigure.in file to specify the compiler, flags, etc. and you need to run nekconfigure to create a makefile for your environment. After that you can use the classical GNU make utility to compile the code. >> >> Your feedback is welcome! >> >> >> Cheers, >> Stefan >> >> >> >> _______________________________________________ >> 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 May 19 07:53:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 19 May 2010 14:53:23 +0200 Subject: [Nek5000-users] new build system In-Reply-To: <177CE4DE-E6DA-4F14-89FC-F6026ECB12D7@lav.mavt.ethz.ch> References: <177CE4DE-E6DA-4F14-89FC-F6026ECB12D7@lav.mavt.ethz.ch> Message-ID: <1274273603.3703.38.camel@localhost.localdomain> Hello all, No major complaints with the compile procedure. For one thing, I must say I am very impressed by the speed at which the code compiles! Very surprising considering the capabilities of NEK. One suggestion would be to have a way to build testing and production versions. The testing version would be compiled with all the debug switches on (i.e. check bounds etc.) and would be used when users are making changes in the *.usr file and debugging. The production version would use compile switches that the development team finds to be best for speed on particular platforms. Cheers, Frank On Wed, 2010-05-19 at 11:48 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nek users, > > we have an ongoing discussion about a new build system for Nek. > > What do you think about the current build system? > How easy is it to compile Nek? > What can be improved / What's missing? > > One major complain was that the current build system does not follow the standard procedure of configure; make; make install. > > We may want to follow the standard more closely. One idea would be to have a nekconfigure.in file to specify the compiler, flags, etc. and you need to run nekconfigure to create a makefile for your environment. After that you can use the classical GNU make utility to compile the code. > > Your feedback is welcome! > > > Cheers, > Stefan > > > > _______________________________________________ > 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 Wed May 19 09:51:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 19 May 2010 16:51:58 +0200 Subject: [Nek5000-users] new build system In-Reply-To: <1274273603.3703.38.camel@localhost.localdomain> References: <177CE4DE-E6DA-4F14-89FC-F6026ECB12D7@lav.mavt.ethz.ch> <1274273603.3703.38.camel@localhost.localdomain> Message-ID: <12F2CBB1-AF64-44CB-8012-39EE726E90D8@lav.mavt.ethz.ch> Well the GNU make utility allows you to compile using multiple threads (make -jNTHREADS). Checking array bounds at runtime is a compiler feature which we cannot use because of things like: subroutine foo(a,n) real a(1) do i = 1,n a(i) enddo The compiler would think a of size 1 although we're passing in with the correct size n. However we plan to introduce a debug preprocessor symbol making the solver more verbose. Stefan On May 19, 2010, at 2:53 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > No major complaints with the compile procedure. For one thing, I must > say I am very impressed by the speed at which the code compiles! Very > surprising considering the capabilities of NEK. > > One suggestion would be to have a way to build testing and production > versions. The testing version would be compiled with all the debug > switches on (i.e. check bounds etc.) and would be used when users are > making changes in the *.usr file and debugging. The production version > would use compile switches that the development team finds to be best > for speed on particular platforms. > > Cheers, > Frank > > > On Wed, 2010-05-19 at 11:48 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Dear Nek users, >> >> we have an ongoing discussion about a new build system for Nek. >> >> What do you think about the current build system? >> How easy is it to compile Nek? >> What can be improved / What's missing? >> >> One major complain was that the current build system does not follow the standard procedure of configure; make; make install. >> >> We may want to follow the standard more closely. One idea would be to have a nekconfigure.in file to specify the compiler, flags, etc. and you need to run nekconfigure to create a makefile for your environment. After that you can use the classical GNU make utility to compile the code. >> >> Your feedback is welcome! >> >> >> Cheers, >> Stefan >> >> >> >> _______________________________________________ >> 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 Wed May 19 17:25:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 19 May 2010 17:25:54 -0500 Subject: [Nek5000-users] Seg fault (may be from Hpts routine) Message-ID: Hello Stefan, I tried the updated hpts routine ( version 518 ) and was having seg fault issues. I tried under two different compilers ( intel and pgi ) and was getting the seg fault error in both cases. I tried the same case without calling the hpts routine and that works fine. Error -1 : [i124-101:13913] *** Process received signal *** [i124-101:13913] Signal: Segmentation fault (11) [i124-101:13913] Signal code: Address not mapped (1) [i124-101:13913] Failing at address: 0x1e29b000 Is that an issue with compiler /mpi or something else ? Thanks for any help. Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 20 03:30:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 10:30:48 +0200 Subject: [Nek5000-users] Data output Message-ID: <4BF4F338.3070107@gmail.com> Hi Nek's, I have a little question concerning data output. I have read that it was possible to drop data on different mesh, regular / GLL / GL. The one I am interested in is the regular mesh, and there comes my problem. I added ifreguo = .true. to the usercheck subroutine in the axi example, but I actually get no difference when it comes to the .fld file. I assume that I miss a step, but where ? Regards, Jean-Christophe From nek5000-users at lists.mcs.anl.gov Thu May 20 03:43:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 10:43:41 +0200 Subject: [Nek5000-users] Data output In-Reply-To: <4BF4F338.3070107@gmail.com> References: <4BF4F338.3070107@gmail.com> Message-ID: Do you dump *.f???? or *.fld?? files? Stefan On May 20, 2010, at 10:30 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > I have a little question concerning data output. I have read that it was possible to drop data on different mesh, regular / GLL / GL. The one I am interested in is the regular mesh, and there comes my problem. > > I added ifreguo = .true. to the usercheck subroutine in the axi example, but I actually get no difference when it comes to the .fld file. I assume that I miss a step, but where ? > > Regards, > Jean-Christophe > _______________________________________________ > 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 May 20 04:10:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 11:10:21 +0200 Subject: [Nek5000-users] Data output In-Reply-To: References: <4BF4F338.3070107@gmail.com> Message-ID: <012DE15D-B30B-4AE9-BC37-6985675824D4@lav.mavt.ethz.ch> In this case we use a uniform point distribution within the reference element instead of the GLL points. Note, if the elements are deformed the output will not be uniform strictly speaking. This feature is only support if you use the new binary output format (*.f????). There is another tricky issue: Make sure that you include the right CB (RESTART) in the subroutine you set ifreguo = .true. and remember to turn it off if you don't need it anymore. I just realized that this is error prone and I will move ifreguo into another CB for greater accessibility (e.g. TOTAL). Sorry for all the trouble Stefan On May 20, 2010, at 10:43 AM, nek5000-users at lists.mcs.anl.gov wrote: > Do you dump *.f???? or *.fld?? files? > > Stefan > > > On May 20, 2010, at 10:30 AM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Nek's, >> >> I have a little question concerning data output. I have read that it was possible to drop data on different mesh, regular / GLL / GL. The one I am interested in is the regular mesh, and there comes my problem. >> >> I added ifreguo = .true. to the usercheck subroutine in the axi example, but I actually get no difference when it comes to the .fld file. I assume that I miss a step, but where ? >> >> Regards, >> Jean-Christophe >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu May 20 04:19:08 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 14:49:08 +0530 Subject: [Nek5000-users] Visit messing up Message-ID: <4BF4FE8C.5060101@iitk.ac.in> Hi, Sometimes, randomly visit messes up the visualization, as shown in the attached picture. The mesh is supposed to be that of a 3D box. Reloading the database does not work. The simulation seems to be going ok and nek is running fine. I'm using Visit 1.12.2 svn revision 9638 and nek svn revision 518. Any clue as to why this is happening? Thanks, Mani chandra -------------- next part -------------- A non-text attachment was scrubbed... Name: mesh.jpeg Type: image/jpeg Size: 164108 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Thu May 20 04:20:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 11:20:00 +0200 Subject: [Nek5000-users] Visit messing up In-Reply-To: <4BF4FE8C.5060101@iitk.ac.in> References: <4BF4FE8C.5060101@iitk.ac.in> Message-ID: Are you using just a single fld-file? Please post your visit meta-data file (e.g. visit.nek5000) and the output of head -n1 foo.fXXXX | strings to get the ASCII string at the very beginning of your first fld-file. Stefan On May 20, 2010, at 11:19 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > Sometimes, randomly visit messes up the visualization, as shown in the attached picture. The mesh is supposed to be that of a 3D box. Reloading the database does not work. The simulation seems to be going ok and nek is running fine. I'm using Visit 1.12.2 svn revision 9638 and nek svn revision 518. Any clue as to why this is happening? > > Thanks, > Mani chandra > From nek5000-users at lists.mcs.anl.gov Thu May 20 04:28:20 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 11:28:20 +0200 Subject: [Nek5000-users] Visit messing up In-Reply-To: <4BF4FE8C.5060101@iitk.ac.in> References: <4BF4FE8C.5060101@iitk.ac.in> Message-ID: <1274347700.3241.15.camel@localhost.localdomain> Hello Mani, Switch to the latest (2.0.0) Visit version. There was a problem in older versions (at least on 32 bit machines) that is now fixed. Cheers, Frank On Thu, 2010-05-20 at 14:49 +0530, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > Sometimes, randomly visit messes up the visualization, as shown in > the attached picture. The mesh is supposed to be that of a 3D box. > Reloading the database does not work. The simulation seems to be going > ok and nek is running fine. I'm using Visit 1.12.2 svn revision 9638 and > nek svn revision 518. Any clue as to why this is happening? > > Thanks, > Mani chandra > _______________________________________________ > 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 May 20 04:36:31 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 15:06:31 +0530 Subject: [Nek5000-users] [*] Re: Visit messing up In-Reply-To: References: <4BF4FE8C.5060101@iitk.ac.in> Message-ID: <4BF5029F.5090503@iitk.ac.in> Hi, I'm using 43 files. Output of head -n1 foo.fXXXX | strings #std 4 5 5 5 37632 37632 0.1000000000000E-02 1 0 1 UPT Attached is the database file. It contains NEK3D version: 1.0 filetemplate: high_ray%d.f%04d firsttimestep: 1 numtimesteps: 43 Mani chandra On 05/20/2010 02:50 PM, nek5000-users at lists.mcs.anl.gov wrote: > Are you using just a single fld-file? > > Please post your visit meta-data file (e.g. visit.nek5000) and the output of > > head -n1 foo.fXXXX | strings > > to get the ASCII string at the very beginning of your first fld-file. > > Stefan > > > On May 20, 2010, at 11:19 AM, nek5000-users at lists.mcs.anl.gov wrote: > > >> Hi, >> >> Sometimes, randomly visit messes up the visualization, as shown in the attached picture. The mesh is supposed to be that of a 3D box. Reloading the database does not work. The simulation seems to be going ok and nek is running fine. I'm using Visit 1.12.2 svn revision 9638 and nek svn revision 518. Any clue as to why this is happening? >> >> Thanks, >> Mani chandra >> >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vis.nek3d URL: From nek5000-users at lists.mcs.anl.gov Thu May 20 04:39:56 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 11:39:56 +0200 Subject: [Nek5000-users] [*] Re: Visit messing up In-Reply-To: <4BF5029F.5090503@iitk.ac.in> References: <4BF4FE8C.5060101@iitk.ac.in> <4BF5029F.5090503@iitk.ac.in> Message-ID: <2062EE50-A969-4373-A00F-FC1EDCE6A360@lav.mavt.ethz.ch> Is this the output of high_ray01.f0001? In this case there is no geometry (coordinates) in your fld-file (there is not X in the variable encoder only UPT). Stefan On May 20, 2010, at 11:36 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I'm using 43 files. > > Output of head -n1 foo.fXXXX | strings > > #std 4 5 5 5 37632 37632 0.1000000000000E-02 1 0 1 UPT > > Attached is the database file. It contains > > NEK3D > version: 1.0 > filetemplate: high_ray%d.f%04d > firsttimestep: 1 > numtimesteps: 43 > > > Mani chandra > > On 05/20/2010 02:50 PM, nek5000-users at lists.mcs.anl.gov wrote: >> Are you using just a single fld-file? >> >> Please post your visit meta-data file (e.g. visit.nek5000) and the output of >> >> head -n1 foo.fXXXX | strings >> >> to get the ASCII string at the very beginning of your first fld-file. >> >> Stefan >> >> >> On May 20, 2010, at 11:19 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >> >>> Hi, >>> >>> Sometimes, randomly visit messes up the visualization, as shown in the attached picture. The mesh is supposed to be that of a 3D box. Reloading the database does not work. The simulation seems to be going ok and nek is running fine. I'm using Visit 1.12.2 svn revision 9638 and nek svn revision 518. Any clue as to why this is happening? >>> >>> Thanks, >>> 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 Thu May 20 04:35:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 11:35:48 +0200 Subject: [Nek5000-users] Visit messing up In-Reply-To: <1274347700.3241.15.camel@localhost.localdomain> References: <4BF4FE8C.5060101@iitk.ac.in> <1274347700.3241.15.camel@localhost.localdomain> Message-ID: <808EA6B8-A7F3-4E97-B8DE-2F785451EBD7@lav.mavt.ethz.ch> The problem might be something else! We assume that the first fld-file loaded into VisIt comes with mesh-coordinates. If the coordinates are missing you'll get a similar behavior. Stefan Sometimes it happens that users don't have On May 20, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Mani, > > Switch to the latest (2.0.0) Visit version. There was a problem in > older versions (at least on 32 bit machines) that is now fixed. > > Cheers, > Frank > > > On Thu, 2010-05-20 at 14:49 +0530, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi, >> >> Sometimes, randomly visit messes up the visualization, as shown in >> the attached picture. The mesh is supposed to be that of a 3D box. >> Reloading the database does not work. The simulation seems to be going >> ok and nek is running fine. I'm using Visit 1.12.2 svn revision 9638 and >> nek svn revision 518. Any clue as to why this is happening? >> >> Thanks, >> Mani chandra >> _______________________________________________ >> 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 Thu May 20 04:50:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 11:50:09 +0200 Subject: [Nek5000-users] Data output In-Reply-To: <012DE15D-B30B-4AE9-BC37-6985675824D4@lav.mavt.ethz.ch> References: <4BF4F338.3070107@gmail.com> <012DE15D-B30B-4AE9-BC37-6985675824D4@lav.mavt.ethz.ch> Message-ID: <4BF505D1.1000705@gmail.com> Well I have been using .fld files because I just cannot remember how to switch to .f???? :-[ Including the right CB, I should have the following userchk subroutine: subroutine userchk include 'SIZE' include 'TOTAL' include 'RESTART' ifreguo = .true. return end Is that correct ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 20 04:59:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 15:29:50 +0530 Subject: [Nek5000-users] [*] Re: Visit messing up In-Reply-To: <808EA6B8-A7F3-4E97-B8DE-2F785451EBD7@lav.mavt.ethz.ch> References: <4BF4FE8C.5060101@iitk.ac.in> <1274347700.3241.15.camel@localhost.localdomain> <808EA6B8-A7F3-4E97-B8DE-2F785451EBD7@lav.mavt.ethz.ch> Message-ID: <4BF50816.7000308@iitk.ac.in> Hi Stefan, Thanks for diagnosing the problem. Yes, the output is of high_ray0.f0001. No wonder, this always happens when I put the "firsttimestep" to something other than 1. So is there some switch that controls the output of coordinates? Thanks, Mani chandra On 05/20/2010 03:05 PM, nek5000-users at lists.mcs.anl.gov wrote: > The problem might be something else! > We assume that the first fld-file loaded into VisIt comes with mesh-coordinates. > If the coordinates are missing you'll get a similar behavior. > > Stefan > > Sometimes it happens that users don't have > > > On May 20, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: > > >> Hello Mani, >> >> Switch to the latest (2.0.0) Visit version. There was a problem in >> older versions (at least on 32 bit machines) that is now fixed. >> >> Cheers, >> Frank >> >> >> On Thu, 2010-05-20 at 14:49 +0530, nek5000-users at lists.mcs.anl.gov >> wrote: >> >>> Hi, >>> >>> Sometimes, randomly visit messes up the visualization, as shown in >>> the attached picture. The mesh is supposed to be that of a 3D box. >>> Reloading the database does not work. The simulation seems to be going >>> ok and nek is running fine. I'm using Visit 1.12.2 svn revision 9638 and >>> nek svn revision 518. Any clue as to why this is happening? >>> >>> Thanks, >>> Mani chandra >>> _______________________________________________ >>> 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 Thu May 20 05:31:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 16:01:54 +0530 Subject: [Nek5000-users] [*] Re: Data output In-Reply-To: <4BF505D1.1000705@gmail.com> References: <4BF4F338.3070107@gmail.com> <012DE15D-B30B-4AE9-BC37-6985675824D4@lav.mavt.ethz.ch> <4BF505D1.1000705@gmail.com> Message-ID: <4BF50F9A.4060900@iitk.ac.in> Hi, param(66) and param(67) should be changed to 1 if you want to use .f????. Also make sure these values are not changed in userchk file. In some examples these two parameters are set to 4 and I find that nek then outputs in fld format. Cheers, Mani chandra On 05/20/2010 03:20 PM, nek5000-users at lists.mcs.anl.gov wrote: > Well I have been using .fld files because I just cannot remember how > to switch to .f???? :-[ > Including the right CB, I should have the following userchk subroutine: > > subroutine userchk > include 'SIZE' > include 'TOTAL' > include 'RESTART' > > ifreguo = .true. > > return > end > > Is that correct ? > > > _______________________________________________ > 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 May 20 06:16:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 13:16:04 +0200 Subject: [Nek5000-users] Data output In-Reply-To: <4BF505D1.1000705@gmail.com> References: <4BF4F338.3070107@gmail.com> <012DE15D-B30B-4AE9-BC37-6985675824D4@lav.mavt.ethz.ch> <4BF505D1.1000705@gmail.com> Message-ID: <22988D3C-7616-45DB-BCC2-6AA5D5A92DFD@lav.mavt.ethz.ch> Yes that's correct! The I/O format is controlled by the following rea-file parameters: input: param(67) output: param(66) Use negative number for ASCII else it will be BINARY. In some cases param(66)/param(67) is hardwired in the usr-file. In this case they're set to 4 to work with the _old_ BINARY format (needed for prex). I strongly recommend the new BINARY format because it gives you the best performance and a lot of features are only supported in this mode! Stefan On May 20, 2010, at 11:50 AM, nek5000-users at lists.mcs.anl.gov wrote: > Well I have been using .fld files because I just cannot remember how to switch to .f???? :-[ > Including the right CB, I should have the following userchk subroutine: > > subroutine userchk > include 'SIZE' > include 'TOTAL' > include 'RESTART' > > ifreguo = .true. > > return > end > > Is that correct ? > > _______________________________________________ > 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 May 20 06:21:26 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 13:21:26 +0200 Subject: [Nek5000-users] [*] Re: Visit messing up In-Reply-To: <4BF50816.7000308@iitk.ac.in> References: <4BF4FE8C.5060101@iitk.ac.in> <1274347700.3241.15.camel@localhost.localdomain> <808EA6B8-A7F3-4E97-B8DE-2F785451EBD7@lav.mavt.ethz.ch> <4BF50816.7000308@iitk.ac.in> Message-ID: The OUTPUT section in the rea-files controls what data will be dumped into a fld-file. So if you want to dump the coordinates just set: ***** OUTPUT FIELD SPECIFICATION ***** X SPECIFICATIONS FOLLOW T COORDINATES Sometimes you don't want to dump the coordinates at every I/O step (to save space). In this case we the following in usrchk(): ifxyo = .true. ! Turn on xyz output if (istep.gt.iostep) ifxyo = .false. ! Turn off xyz output after first dump hth, Stefan On May 20, 2010, at 11:59 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > Thanks for diagnosing the problem. Yes, the output is of high_ray0.f0001. No wonder, this always happens when I put the "firsttimestep" to something other than 1. So is there some switch that controls the output of coordinates? > > Thanks, > Mani chandra > > On 05/20/2010 03:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >> The problem might be something else! >> We assume that the first fld-file loaded into VisIt comes with mesh-coordinates. >> If the coordinates are missing you'll get a similar behavior. >> >> Stefan >> >> Sometimes it happens that users don't have >> >> >> On May 20, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >> >>> Hello Mani, >>> >>> Switch to the latest (2.0.0) Visit version. There was a problem in >>> older versions (at least on 32 bit machines) that is now fixed. >>> >>> Cheers, >>> Frank >>> >>> >>> On Thu, 2010-05-20 at 14:49 +0530, nek5000-users at lists.mcs.anl.gov >>> wrote: >>> >>>> Hi, >>>> >>>> Sometimes, randomly visit messes up the visualization, as shown in >>>> the attached picture. The mesh is supposed to be that of a 3D box. >>>> Reloading the database does not work. The simulation seems to be going >>>> ok and nek is running fine. I'm using Visit 1.12.2 svn revision 9638 and >>>> nek svn revision 518. Any clue as to why this is happening? >>>> >>>> Thanks, >>>> Mani chandra >>>> _______________________________________________ >>>> 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 >> >> > > _______________________________________________ > 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 May 20 07:06:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 17:36:03 +0530 Subject: [Nek5000-users] [*] Re: [*] Re: Visit messing up In-Reply-To: References: <4BF4FE8C.5060101@iitk.ac.in> <1274347700.3241.15.camel@localhost.localdomain> <808EA6B8-A7F3-4E97-B8DE-2F785451EBD7@lav.mavt.ethz.ch> <4BF50816.7000308@iitk.ac.in> Message-ID: <4BF525AB.2000506@iitk.ac.in> Thank you Stefan. I checked and indeed the coordinates switch was "F". On 05/20/2010 04:51 PM, nek5000-users at lists.mcs.anl.gov wrote: > The OUTPUT section in the rea-files controls what data will be dumped into a fld-file. > So if you want to dump the coordinates just set: > > ***** OUTPUT FIELD SPECIFICATION ***** > X SPECIFICATIONS FOLLOW > T COORDINATES > > Sometimes you don't want to dump the coordinates at every I/O step (to save space). In this case we the following in usrchk(): > > ifxyo = .true. ! Turn on xyz output > if (istep.gt.iostep) ifxyo = .false. ! Turn off xyz output after first dump > > > hth, > Stefan > > > On May 20, 2010, at 11:59 AM, nek5000-users at lists.mcs.anl.gov wrote: > > >> Hi Stefan, >> >> Thanks for diagnosing the problem. Yes, the output is of high_ray0.f0001. No wonder, this always happens when I put the "firsttimestep" to something other than 1. So is there some switch that controls the output of coordinates? >> >> Thanks, >> Mani chandra >> >> On 05/20/2010 03:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> The problem might be something else! >>> We assume that the first fld-file loaded into VisIt comes with mesh-coordinates. >>> If the coordinates are missing you'll get a similar behavior. >>> >>> Stefan >>> >>> Sometimes it happens that users don't have >>> >>> >>> On May 20, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>> >>> >>>> Hello Mani, >>>> >>>> Switch to the latest (2.0.0) Visit version. There was a problem in >>>> older versions (at least on 32 bit machines) that is now fixed. >>>> >>>> Cheers, >>>> Frank >>>> >>>> >>>> On Thu, 2010-05-20 at 14:49 +0530, nek5000-users at lists.mcs.anl.gov >>>> wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> Sometimes, randomly visit messes up the visualization, as shown in >>>>> the attached picture. The mesh is supposed to be that of a 3D box. >>>>> Reloading the database does not work. The simulation seems to be going >>>>> ok and nek is running fine. I'm using Visit 1.12.2 svn revision 9638 and >>>>> nek svn revision 518. Any clue as to why this is happening? >>>>> >>>>> Thanks, >>>>> Mani chandra >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > From nek5000-users at lists.mcs.anl.gov Thu May 20 07:08:31 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 07:08:31 -0500 (CDT) Subject: [Nek5000-users] [*] Re: [*] Re: Visit messing up In-Reply-To: <4BF525AB.2000506@iitk.ac.in> References: <4BF4FE8C.5060101@iitk.ac.in> <1274347700.3241.15.camel@localhost.localdomain> <808EA6B8-A7F3-4E97-B8DE-2F785451EBD7@lav.mavt.ethz.ch> <4BF50816.7000308@iitk.ac.in> <4BF525AB.2000506@iitk.ac.in> Message-ID: It's generally better to control the geometry through userchk via: ifxyo = .true. if (istep.gt.iostep) ifxyo = .false. so that you don't have geometry in each and every file. In future versions of the visit reader it will read the geometry from any file that contains geometry, which will impact performance in cases where each file contains geometry. It's clear that one of the things we need to do in nek is to make it default to always dumping geometry in the first file, so that users are not troubled w/ this. Hopefully we can do that in the next few days. (There is also a minor flaw in the above approach in that if you are using the less-used IOTIME trigger, with IOSTEP=0, you would get geometry with each output file.) Paul On Thu, 20 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Thank you Stefan. I checked and indeed the coordinates switch was "F". > > On 05/20/2010 04:51 PM, nek5000-users at lists.mcs.anl.gov wrote: >> The OUTPUT section in the rea-files controls what data will be dumped into >> a fld-file. >> So if you want to dump the coordinates just set: >> >> ***** OUTPUT FIELD SPECIFICATION ***** >> X SPECIFICATIONS FOLLOW >> T COORDINATES >> >> Sometimes you don't want to dump the coordinates at every I/O step (to save >> space). In this case we the following in usrchk(): >> >> ifxyo = .true. ! Turn on xyz output >> if (istep.gt.iostep) ifxyo = .false. ! Turn off xyz output after >> first dump >> >> >> hth, >> Stefan >> >> >> On May 20, 2010, at 11:59 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >> >>> Hi Stefan, >>> >>> Thanks for diagnosing the problem. Yes, the output is of >>> high_ray0.f0001. No wonder, this always happens when I put the >>> "firsttimestep" to something other than 1. So is there some switch that >>> controls the output of coordinates? >>> >>> Thanks, >>> Mani chandra >>> >>> On 05/20/2010 03:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> The problem might be something else! >>>> We assume that the first fld-file loaded into VisIt comes with >>>> mesh-coordinates. >>>> If the coordinates are missing you'll get a similar behavior. >>>> >>>> Stefan >>>> >>>> Sometimes it happens that users don't have >>>> >>>> >>>> On May 20, 2010, at 11:28 AM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>> >>>> >>>>> Hello Mani, >>>>> >>>>> Switch to the latest (2.0.0) Visit version. There was a problem in >>>>> older versions (at least on 32 bit machines) that is now fixed. >>>>> >>>>> Cheers, >>>>> Frank >>>>> >>>>> >>>>> On Thu, 2010-05-20 at 14:49 +0530, nek5000-users at lists.mcs.anl.gov >>>>> wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Sometimes, randomly visit messes up the visualization, as shown in >>>>>> the attached picture. The mesh is supposed to be that of a 3D box. >>>>>> Reloading the database does not work. The simulation seems to be going >>>>>> ok and nek is running fine. I'm using Visit 1.12.2 svn revision 9638 >>>>>> and >>>>>> nek svn revision 518. Any clue as to why this is happening? >>>>>> >>>>>> Thanks, >>>>>> Mani chandra >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>> _______________________________________________ >>> 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 Thu May 20 07:41:28 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 14:41:28 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: <1271696352.9761.13.camel@localhost.localdomain> References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> <1271693940.9761.2.camel@localhost.localdomain> <1271695308.9761.10.camel@localhost.localdomain> <1271696352.9761.13.camel@localhost.localdomain> Message-ID: <4BF52DF8.5010405@gmail.com> Hi Nek's, I am studying the flow through a 2D axisymmetric stenosis, and I use Visit 1.11.1 to visualize the data. Nevertheless, I will need to use Tecplot soon as one of my workmate developed various post-process/stability analysis tools I'll need. I have to tried to use Visit to export my data, using its tecplot converter, but I got the following error message: Unable to export database: viewer: The pipeline object is being used improperly: The Tecplot writer only supports meshes with a topological dimension of 3. Do you know if the latest release of Visit supports 2D export to Tecplot ? Or did a "blah.f???? to tecplot" converter finally came out ? Thanks a lot, JC -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 20 07:49:36 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 14:49:36 +0200 Subject: [Nek5000-users] change order when restarting In-Reply-To: <43E418AF-6669-4C20-B32F-CA04DE90F954@lav.mavt.ethz.ch> References: <43E418AF-6669-4C20-B32F-CA04DE90F954@lav.mavt.ethz.ch> Message-ID: <4BF52FE0.20307@kit.edu> thx a lot!! but i only have to full fill this restriction when i reduce my order, or?? cause otherwise this relation is alway full filled! best, fred From nek5000-users at lists.mcs.anl.gov Thu May 20 07:50:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 14:50:49 +0200 Subject: [Nek5000-users] change order when restarting In-Reply-To: <4BF52FE0.20307@kit.edu> References: <43E418AF-6669-4C20-B32F-CA04DE90F954@lav.mavt.ethz.ch> <4BF52FE0.20307@kit.edu> Message-ID: Yes! On May 20, 2010, at 2:49 PM, nek5000-users at lists.mcs.anl.gov wrote: > thx a lot!! > > but i only have to full fill this restriction when i reduce my order, or?? cause otherwise this relation is alway full filled! > > 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 May 20 07:52:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 14:52:34 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: <4BF52DF8.5010405@gmail.com> References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> <1271693940.9761.2.camel@localhost.localdomain> <1271695308.9761.10.camel@localhost.localdomain> <1271696352.9761.13.camel@localhost.localdomain> <4BF52DF8.5010405@gmail.com> Message-ID: <7711D0FA-8F88-4A0A-A316-A479CBA8C69C@lav.mavt.ethz.ch> Hi, even in the latest VisIt release the export capabilities to TecPlot are quite limited although 2D is support now. Stefan On May 20, 2010, at 2:41 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > I am studying the flow through a 2D axisymmetric stenosis, and I use Visit 1.11.1 to visualize the data. > Nevertheless, I will need to use Tecplot soon as one of my workmate developed various post-process/stability analysis tools I'll need. > I have to tried to use Visit to export my data, using its tecplot converter, but I got the following error message: > Unable to export database: viewer: The pipeline object is being used improperly: The Tecplot writer only supports meshes with a topological dimension of 3. > Do you know if the latest release of Visit supports 2D export to Tecplot ? > Or did a "blah.f???? to tecplot" converter finally came out ? > > Thanks a lot, > JC > _______________________________________________ > 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 May 20 18:11:42 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 May 2010 19:11:42 -0400 Subject: [Nek5000-users] Seg fault (may be from Hpts routine) In-Reply-To: References: Message-ID: <1274397102.4bf5c1ae3ce7e@webmail.vt.edu> Hi Stefan, the latest revision (519) fixed the seg fault for me, but I keep getting error messages about the history points not being within the mesh even though they are. WARNING: point not within mesh xy[z]: ! -0.2000000E+00 0.3000000E+00 Do you have the same issue? Also, I was wondering if in the following from postpro.f ---- ! locate points (iel,iproc,r,s,t) if(iffind) then call findpts(ipth,iTl(3,1),iTlS, & iTl(1,1),iTlS, & iTL(2,1),iTlS, & rTl(nndim+2,1),rTlS, & rTl(1,1),rTlS, & rTl(2,1),rTlS, & rTl(3,1),rTlS, & rTl(4,1),rTlS,n) nh(ih) = n ! store number of points for a given handle endif --- the 5th line should read & iTl(2,1),iTlS, (small "l" in iTl)? Thanks, Markus Quoting nek5000-users at lists.mcs.anl.gov: > Hello Stefan, > > I tried the updated hpts routine ( version 518 ) and was having seg fault > issues. I tried under two different compilers ( intel and pgi ) and was > getting the seg fault error in both cases. I tried the same case without > calling the hpts routine and that works fine. > > Error -1 : > > [i124-101:13913] *** Process received signal *** > [i124-101:13913] Signal: Segmentation fault (11) > [i124-101:13913] Signal code: Address not mapped (1) > [i124-101:13913] Failing at address: 0x1e29b000 > > > Is that an issue with compiler /mpi or something else ? Thanks for any help. > > Regards > Shriram > From nek5000-users at lists.mcs.anl.gov Thu May 20 23:50:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 21 May 2010 06:50:54 +0200 Subject: [Nek5000-users] Seg fault (may be from Hpts routine) References: <1274397102.4bf5c1ae3ce7e@webmail.vt.edu> Message-ID: Markus, Fortran is not case sensitive so that's not a problem. The warning you get is a feature and not a bug. It seems like this point is really outside the mesh (using a tolerance of 1e-13). Are you sure you have a point GLL point at _exactly_ this location? The reason I am asking is the following: Mesh coordinates generated by e.g. prex, genbox are in single precision which can be tricky in this case. Stefan -----Original Message----- From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of nek5000-users at lists.mcs.anl.gov Sent: Fri 5/21/2010 01:11 To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Seg fault (may be from Hpts routine) Hi Stefan, the latest revision (519) fixed the seg fault for me, but I keep getting error messages about the history points not being within the mesh even though they are. WARNING: point not within mesh xy[z]: ! -0.2000000E+00 0.3000000E+00 Do you have the same issue? Also, I was wondering if in the following from postpro.f ---- ! locate points (iel,iproc,r,s,t) if(iffind) then call findpts(ipth,iTl(3,1),iTlS, & iTl(1,1),iTlS, & iTL(2,1),iTlS, & rTl(nndim+2,1),rTlS, & rTl(1,1),rTlS, & rTl(2,1),rTlS, & rTl(3,1),rTlS, & rTl(4,1),rTlS,n) nh(ih) = n ! store number of points for a given handle endif --- the 5th line should read & iTl(2,1),iTlS, (small "l" in iTl)? Thanks, Markus Quoting nek5000-users at lists.mcs.anl.gov: > Hello Stefan, > > I tried the updated hpts routine ( version 518 ) and was having seg fault > issues. I tried under two different compilers ( intel and pgi ) and was > getting the seg fault error in both cases. I tried the same case without > calling the hpts routine and that works fine. > > Error -1 : > > [i124-101:13913] *** Process received signal *** > [i124-101:13913] Signal: Segmentation fault (11) > [i124-101:13913] Signal code: Address not mapped (1) > [i124-101:13913] Failing at address: 0x1e29b000 > > > Is that an issue with compiler /mpi or something else ? Thanks for any help. > > 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 Fri May 21 00:09:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 21 May 2010 07:09:04 +0200 Subject: [Nek5000-users] Seg fault (may be from Hpts routine) In-Reply-To: References: <1274397102.4bf5c1ae3ce7e@webmail.vt.edu> Message-ID: <3A61D7C9-55A1-4C70-B2EB-5BE00AD273BB@lav.mavt.ethz.ch> with _exactly_ I mean to machine precision Stefan On May 21, 2010, at 6:50 AM, nek5000-users at lists.mcs.anl.gov wrote: > Markus, > > Fortran is not case sensitive so that's not a problem. > The warning you get is a feature and not a bug. > > It seems like this point is really outside the mesh (using a tolerance of 1e-13). > Are you sure you have a point GLL point at _exactly_ this location? > > The reason I am asking is the following: > Mesh coordinates generated by e.g. prex, genbox are in single precision which can be tricky in this case. > > > Stefan > > > -----Original Message----- > From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of nek5000-users at lists.mcs.anl.gov > Sent: Fri 5/21/2010 01:11 > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Seg fault (may be from Hpts routine) > > Hi Stefan, > > the latest revision (519) fixed the seg fault for me, but I keep getting error > messages about the history points not being within the mesh even though they > are. > WARNING: point not within mesh xy[z]: ! -0.2000000E+00 0.3000000E+00 > > Do you have the same issue? > > > Also, I was wondering if in the following from postpro.f > ---- > ! locate points (iel,iproc,r,s,t) > if(iffind) then > call findpts(ipth,iTl(3,1),iTlS, > & iTl(1,1),iTlS, > & iTL(2,1),iTlS, > & rTl(nndim+2,1),rTlS, > & rTl(1,1),rTlS, > & rTl(2,1),rTlS, > & rTl(3,1),rTlS, > & rTl(4,1),rTlS,n) > nh(ih) = n ! store number of points for a given handle > endif > --- > the 5th line should read > & iTl(2,1),iTlS, > (small "l" in iTl)? > > > Thanks, > Markus > > > > Quoting nek5000-users at lists.mcs.anl.gov: > >> Hello Stefan, >> >> I tried the updated hpts routine ( version 518 ) and was having seg fault >> issues. I tried under two different compilers ( intel and pgi ) and was >> getting the seg fault error in both cases. I tried the same case without >> calling the hpts routine and that works fine. >> >> Error -1 : >> >> [i124-101:13913] *** Process received signal *** >> [i124-101:13913] Signal: Segmentation fault (11) >> [i124-101:13913] Signal code: Address not mapped (1) >> [i124-101:13913] Failing at address: 0x1e29b000 >> >> >> Is that an issue with compiler /mpi or something else ? Thanks for any help. >> >> Regards >> Shriram >> > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri May 21 02:42:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 21 May 2010 13:12:03 +0530 Subject: [Nek5000-users] Increasing data_files%d.f%04d to data_files%d.f%05d Message-ID: <4BF6394B.2030202@iitk.ac.in> Hi, How can one increase the maximum number of data_files that can be printed? After .f9999, nek stops outputting binary files, which is probably due to the %04 restriction. I'd like to know how to increase this limit. Thanks, Mani chandra From nek5000-users at lists.mcs.anl.gov Fri May 21 02:44:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 21 May 2010 09:44:59 +0200 Subject: [Nek5000-users] Increasing data_files%d.f%04d to data_files%d.f%05d In-Reply-To: <4BF6394B.2030202@iitk.ac.in> References: <4BF6394B.2030202@iitk.ac.in> Message-ID: Wow you produced more than 9999 fld-files with a single NEK run? If you really want to have more digits you have to modify the source since we thought 4 digits would be enough. Stefan On May 21, 2010, at 9:42 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > How can one increase the maximum number of data_files that can be printed? After .f9999, nek stops outputting binary files, which is probably due to the %04 restriction. I'd like to know how to increase this limit. > > > Thanks, > Mani chandra > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri May 21 04:26:52 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 21 May 2010 14:56:52 +0530 Subject: [Nek5000-users] [*] Re: Increasing data_files%d.f%04d to data_files%d.f%05d In-Reply-To: References: <4BF6394B.2030202@iitk.ac.in> Message-ID: <4BF651DC.7000908@iitk.ac.in> Well, basically I am storing all the data and then post processing with load_fld and your hpts subroutine. Maybe I should output less of the binary and output probe data as the code is running. Anyway, I can always put the last file and restart but thought that it'd be more convenient to just increase the maximum limit since the code keeps running even after f9999. Thanks anyway, Cheers, Mani chandra On 05/21/2010 01:14 PM, nek5000-users at lists.mcs.anl.gov wrote: > Wow you produced more than 9999 fld-files with a single NEK run? > If you really want to have more digits you have to modify the source since we thought 4 digits would be enough. > > Stefan > > > On May 21, 2010, at 9:42 AM, nek5000-users at lists.mcs.anl.gov wrote: > > >> Hi, >> >> How can one increase the maximum number of data_files that can be printed? After .f9999, nek stops outputting binary files, which is probably due to the %04 restriction. I'd like to know how to increase this limit. >> >> >> Thanks, >> 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 Fri May 21 07:34:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 21 May 2010 07:34:27 -0500 (CDT) Subject: [Nek5000-users] Increasing data_files%d.f%04d to data_files%d.f%05d In-Reply-To: <29015193.1376351274444619581.JavaMail.root@zimbra> Message-ID: <4097257.1376551274445267011.JavaMail.root@zimbra> Hi Mani, You can switch to .fld files -- it outposts correctly up to 99999 Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Friday, May 21, 2010 2:44:59 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Increasing data_files%d.f%04d to data_files%d.f%05d Wow you produced more than 9999 fld-files with a single NEK run? If you really want to have more digits you have to modify the source since we thought 4 digits would be enough. Stefan On May 21, 2010, at 9:42 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > How can one increase the maximum number of data_files that can be printed? After .f9999, nek stops outputting binary files, which is probably due to the %04 restriction. I'd like to know how to increase this limit. > > > Thanks, > 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 Fri May 21 11:39:51 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 21 May 2010 18:39:51 +0200 Subject: [Nek5000-users] NEKTON and Gambit Message-ID: <1274459991.8195.55.camel@localhost.localdomain> 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 From nek5000-users at lists.mcs.anl.gov Fri May 21 14:09:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 21 May 2010 19:09:16 +0000 Subject: [Nek5000-users] NEKTON and Gambit In-Reply-To: <1274459991.8195.55.camel@localhost.localdomain> References: <1274459991.8195.55.camel@localhost.localdomain> Message-ID: <863382522-1274468899-cardhu_decombobulator_blackberry.rim.net-1997583008-@bda416.bisx.prod.on.blackberry> 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 From nek5000-users at lists.mcs.anl.gov Fri May 21 14:21:20 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 21 May 2010 21:21:20 +0200 Subject: [Nek5000-users] NEKTON and Gambit In-Reply-To: <863382522-1274468899-cardhu_decombobulator_blackberry.rim.net-1997583008-@bda416.bisx.prod.on.blackberry> References: <1274459991.8195.55.camel@localhost.localdomain> <863382522-1274468899-cardhu_decombobulator_blackberry.rim.net-1997583008-@bda416.bisx.prod.on.blackberry> Message-ID: <1274469680.8195.84.camel@localhost.localdomain> 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 From nek5000-users at lists.mcs.anl.gov Sat May 22 13:37:47 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 22 May 2010 13:37:47 -0500 (CDT) Subject: [Nek5000-users] NEKTON and Gambit In-Reply-To: <1274469680.8195.84.camel@localhost.localdomain> Message-ID: <594293907.283401274553467407.JavaMail.root@neo-mail-3> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 24 15:52:35 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 May 2010 13:52:35 -0700 Subject: [Nek5000-users] Full restart capabilities References: Message-ID: Hello, In an older version of nekton, I was able to perform a clean restart, where I included both a blah.fld** file and the next two (or three) time steps, so when I restarted, I had enough successive time slices to pick up exactly where I left off. This is in contrast to a simple restart where I just include just the last blah.fld** file. I am not sure how to do this in the new nekton... Is the full restart capability still there? Thanks, Janet Scheel ----------------------------------- Janet Scheel Assistant Professor of Physics Occidental College 1600 Campus Road, M21 Los Angeles, CA 90041 (323) 259-2777 jscheel at oxy.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2906 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon May 24 16:37:51 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 May 2010 16:37:51 -0500 (CDT) Subject: [Nek5000-users] Full restart capabilities In-Reply-To: References: Message-ID: Hi Janet, I think so.... but I've not done it myself for some time... Hopefully we can get this sorted out for you. Ideally, we'd have that capability with full 64-bit arithmetic... I'm not certain of the current state for this part of the code. Paul On Mon, 24 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > In an older version of nekton, I was able to perform a clean restart, where > I included both a blah.fld** file and the next two (or three) time steps, > so when I restarted, I had enough successive time slices to pick up > exactly where I left off. This is in contrast to a simple restart > where I just include just the last blah.fld** file. > > I am not sure how to do this in the new nekton... Is the > full restart capability still there? > > Thanks, > > Janet Scheel > ----------------------------------- > Janet Scheel > Assistant Professor of Physics > Occidental College > 1600 Campus Road, M21 > Los Angeles, CA 90041 > (323) 259-2777 > jscheel at oxy.edu > > > > From nek5000-users at lists.mcs.anl.gov Tue May 25 04:30:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 May 2010 11:30:09 +0200 Subject: [Nek5000-users] A good way to approximate second derivatives? Message-ID: Hello! This is the first time I write to this list. I am a PhD student at KTH Mechanics, and use Nek5000 mostly to get steady solutions for my linear stability calculations (where the steadiness is imposed geometrically, by boundary conditions) on 2D wakes and jets. The stability calculation is performed on a different grid, in another code. I wrote a script where I interpolate the solution form Nek5000 exactly to my stability grid using the Legendre basis functions, and for the flow variables (U,V,P) and their first derivatives this works fine. However, now I am using the same steady solution to calculate stability with surface tension (since for slowly developing flows the steady state without surface tension can still be used). In this new setting, the second derivatives (Uxx,Uyy,Vxx,Vyy) are also needed. Therefore I wonder if there is any standard way to approximate the second derivatives of the flow variables in Nek5000? The basis functions are only C1-continuous across the element boundaries, and even if they would have been continuous, the second derivatives are always noisy, e.g. if taken from experimental data. Currently I use finite differences combined with a smooth function in Matlab with a 5-point moving average. Thank you for input or better ideas, Outi Tammisola From nek5000-users at lists.mcs.anl.gov Tue May 25 05:00:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 May 2010 12:00:59 +0200 Subject: [Nek5000-users] A good way to approximate second derivatives? In-Reply-To: References: Message-ID: <4BFB9FDB.9080606@mech.kth.se> Hi Outi, You can use call sethlm(h1,h2,intype) ! intype = 0 gives laplacian call axhelm(vx2,vx,h1,h2,1,1) ! d^2(u)dx^2 + d^2(u)dy^2 + d^2(u)dz^2 Johan nek5000-users at lists.mcs.anl.gov wrote: > Hello! > > This is the first time I write to this list. > I am a PhD student at KTH Mechanics, and use Nek5000 mostly to get > steady solutions for my linear stability calculations (where the > steadiness is imposed geometrically, by boundary conditions) on 2D > wakes and jets. The stability calculation is performed on a different > grid, in another code. > > I wrote a script where I interpolate the solution form Nek5000 exactly > to my stability grid using the Legendre basis functions, and for the > flow variables (U,V,P) and their first derivatives this works fine. > However, now I am using the same steady solution to calculate > stability with surface tension (since for slowly developing flows the > steady state without surface tension can still be used). In this new > setting, the second derivatives (Uxx,Uyy,Vxx,Vyy) are also needed. > > Therefore I wonder if there is any standard way to approximate the > second derivatives of the flow variables in Nek5000? > The basis functions are only C1-continuous across the element > boundaries, and even if they would have been continuous, the second > derivatives are always noisy, e.g. if taken from experimental data. > Currently I use finite differences combined with a smooth function in > Matlab with a 5-point moving average. > > Thank you for input or better ideas, > > Outi Tammisola > > > > > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Johan Ohlsson Department of Mechanics, KTH SE-100 44, Stockholm, Sweden Phone: +46 8 7906876 E-mail: johan at mech.kth.se From nek5000-users at lists.mcs.anl.gov Tue May 25 05:37:51 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 May 2010 12:37:51 +0200 Subject: [Nek5000-users] A good way to approximate second derivatives? In-Reply-To: <4BFB9FDB.9080606@mech.kth.se> References: <4BFB9FDB.9080606@mech.kth.se> Message-ID: <5FABC888-C9A7-4B27-AA6A-6449230AF867@lav.mavt.ethz.ch> I am afraid that's not correct. This way you compute the weak laplacian and you're missing the boundary term. Stefan On May 25, 2010, at 12:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Outi, > > You can use > > call sethlm(h1,h2,intype) ! intype = 0 gives laplacian > > call axhelm(vx2,vx,h1,h2,1,1) ! d^2(u)dx^2 + d^2(u)dy^2 + d^2(u)dz^2 > > > Johan > > nek5000-users at lists.mcs.anl.gov wrote: >> Hello! >> >> This is the first time I write to this list. >> I am a PhD student at KTH Mechanics, and use Nek5000 mostly to get >> steady solutions for my linear stability calculations (where the >> steadiness is imposed geometrically, by boundary conditions) on 2D >> wakes and jets. The stability calculation is performed on a different >> grid, in another code. >> >> I wrote a script where I interpolate the solution form Nek5000 exactly >> to my stability grid using the Legendre basis functions, and for the >> flow variables (U,V,P) and their first derivatives this works fine. >> However, now I am using the same steady solution to calculate >> stability with surface tension (since for slowly developing flows the >> steady state without surface tension can still be used). In this new >> setting, the second derivatives (Uxx,Uyy,Vxx,Vyy) are also needed. >> >> Therefore I wonder if there is any standard way to approximate the >> second derivatives of the flow variables in Nek5000? >> The basis functions are only C1-continuous across the element >> boundaries, and even if they would have been continuous, the second >> derivatives are always noisy, e.g. if taken from experimental data. >> Currently I use finite differences combined with a smooth function in >> Matlab with a 5-point moving average. >> >> Thank you for input or better ideas, >> >> Outi Tammisola >> >> >> >> >> >> >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > -- > Johan Ohlsson > Department of Mechanics, KTH > SE-100 44, Stockholm, Sweden > Phone: +46 8 7906876 > E-mail: johan at mech.kth.se > > _______________________________________________ > 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 May 25 05:39:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 May 2010 12:39:53 +0200 Subject: [Nek5000-users] A good way to approximate second derivatives? In-Reply-To: References: Message-ID: <7B24E7EB-C2FD-406B-BF4F-346E700E0E5D@lav.mavt.ethz.ch> Hi Outi, check how we compute the derivatives in wgradm1(). In general strong 2nd derivates d/di [d/dj u] can be computed by a sequence of wgradm1() and dssum(). Example: d/dx[ d/dy u ], d/dy [ d/dy u], d/dz [ d/dy u] call wgradm1(uddx,uddy,uddz,u,nelt) call vec_dssum(uddx,uddy,uddz,nx1,ny1,nz1) call wgradm1(ud2dx,ud2dy,ud2dz,uddy,nelt) all vec_dssum(ud2dx,ud2dy,ud2dz,nx1,ny1,nz1) You're right the derivatives are in general not in H1 because there are not in C0. That's why you need to call dssum() to make the derivative field continuous across elemental boundaries. Stefan On May 25, 2010, at 11:30 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello! > > This is the first time I write to this list. > I am a PhD student at KTH Mechanics, and use Nek5000 mostly to get steady solutions for my linear stability calculations (where the steadiness is imposed geometrically, by boundary conditions) on 2D wakes and jets. The stability calculation is performed on a different grid, in another code. > > I wrote a script where I interpolate the solution form Nek5000 exactly to my stability grid using the Legendre basis functions, and for the flow variables (U,V,P) and their first derivatives this works fine. However, now I am using the same steady solution to calculate stability with surface tension (since for slowly developing flows the steady state without surface tension can still be used). In this new setting, the second derivatives (Uxx,Uyy,Vxx,Vyy) are also needed. > > Therefore I wonder if there is any standard way to approximate the second derivatives of the flow variables in Nek5000? > The basis functions are only C1-continuous across the element boundaries, and even if they would have been continuous, the second derivatives are always noisy, e.g. if taken from experimental data. > Currently I use finite differences combined with a smooth function in Matlab with a 5-point moving average. > > Thank you for input or better ideas, > > Outi Tammisola > > > > > > > > _______________________________________________ > 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 May 25 06:39:51 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 May 2010 06:39:51 -0500 (CDT) Subject: [Nek5000-users] A good way to approximate second derivatives? In-Reply-To: References: Message-ID: Hi Outi, Nek5000 supports free-surface motion and does not require 2nd derivatives, using the same approach that is used for the 2nd-order Laplace operator, namely, by transfering one of the derivatives to the test functions. The description of the implementation can be found in Lee W. Ho's MIT thesis http://dspace.mit.edu/handle/1721.1/14293 Note that one of our example problems, fs_hydro, implements a linear stability test with results described in www.mcs.anl.gov/~fischer/users.pdf I'm not certain if this is what you're needing? Paul On Tue, 25 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello! > > This is the first time I write to this list. > I am a PhD student at KTH Mechanics, and use Nek5000 mostly to get steady > solutions for my linear stability calculations (where the steadiness is > imposed geometrically, by boundary conditions) on 2D wakes and jets. The > stability calculation is performed on a different grid, in another code. > > I wrote a script where I interpolate the solution form Nek5000 exactly to my > stability grid using the Legendre basis functions, and for the flow variables > (U,V,P) and their first derivatives this works fine. However, now I am using > the same steady solution to calculate stability with surface tension (since > for slowly developing flows the steady state without surface tension can > still be used). In this new setting, the second derivatives (Uxx,Uyy,Vxx,Vyy) > are also needed. > > Therefore I wonder if there is any standard way to approximate the second > derivatives of the flow variables in Nek5000? > The basis functions are only C1-continuous across the element boundaries, and > even if they would have been continuous, the second derivatives are always > noisy, e.g. if taken from experimental data. > Currently I use finite differences combined with a smooth function in Matlab > with a 5-point moving average. > > Thank you for input or better ideas, > > Outi Tammisola > > > > > > > > _______________________________________________ > 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 May 25 10:16:14 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 May 2010 17:16:14 +0200 Subject: [Nek5000-users] A good way to approximate second derivatives? In-Reply-To: References: Message-ID: <9E4A343F-BD0A-4EF1-8D84-5DF64A6CC4A9@mech.kth.se> Thanks to everybody for answers. I will proceed tomorrow and see which one I should implement (I am going away for a conference trip, and will return with possible follow-up questions in June). Just a quick comment to the suggestion below, on solving the linear stability problem also in Nek5000: I would be interested to do that, and I have heard there exists a linear version of Nek5000 which could be used. However, then the ALE- formulation would also need to be linearised around the steady position of the interface. Is that done already, or could that be done? Also very interesting would be to calculate the steady state with surface tension in Nek5000. I have two media (say, water and air), the stresses of which need to be coupled on an interface involving surface tension, which I assume is possible in the stress formulation. The boundary conditions that I use would then not stabilise the time- dependent flow field anymore, but I assume one could use some sort of filtering, or an iterative procedure instead of ALE formulation. Regards, Outi 25 maj 2010 kl. 13.39 skrev nek5000-users at lists.mcs.anl.gov: > > Hi Outi, > > Nek5000 supports free-surface motion and does not require > 2nd derivatives, using the same approach that is used for > the 2nd-order Laplace operator, namely, by transfering one > of the derivatives to the test functions. > > The description of the implementation can be found in Lee W. Ho's > MIT thesis > > http://dspace.mit.edu/handle/1721.1/14293 > > Note that one of our example problems, fs_hydro, implements > a linear stability test with results described in > > www.mcs.anl.gov/~fischer/users.pdf > > I'm not certain if this is what you're needing? > > Paul > > > > On Tue, 25 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello! >> >> This is the first time I write to this list. >> I am a PhD student at KTH Mechanics, and use Nek5000 mostly to get >> steady solutions for my linear stability calculations (where the >> steadiness is imposed geometrically, by boundary conditions) on 2D >> wakes and jets. The stability calculation is performed on a >> different grid, in another code. >> >> I wrote a script where I interpolate the solution form Nek5000 >> exactly to my stability grid using the Legendre basis functions, >> and for the flow variables (U,V,P) and their first derivatives this >> works fine. However, now I am using the same steady solution to >> calculate stability with surface tension (since for slowly >> developing flows the steady state without surface tension can still >> be used). In this new setting, the second derivatives >> (Uxx,Uyy,Vxx,Vyy) are also needed. >> >> Therefore I wonder if there is any standard way to approximate the >> second derivatives of the flow variables in Nek5000? >> The basis functions are only C1-continuous across the element >> boundaries, and even if they would have been continuous, the second >> derivatives are always noisy, e.g. if taken from experimental data. >> Currently I use finite differences combined with a smooth function >> in Matlab with a 5-point moving average. >> >> Thank you for input or better ideas, >> >> Outi Tammisola >> >> >> >> >> >> >> >> _______________________________________________ >> 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 May 25 11:15:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 May 2010 12:15:21 -0400 Subject: [Nek5000-users] genmap Message-ID: Hi Neks, Is anyone having trouble with genmap in the latest build (519)? I believe I last used genmap in version 503 without problems, but now when I try to run it, it immediately says "Killed". Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 25 11:18:45 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 May 2010 18:18:45 +0200 Subject: [Nek5000-users] genmap In-Reply-To: References: Message-ID: I increased the maximum number of elements and therefore the memory footprint. How much memory do you have on your system? Also the output of 'ulimit -a' would help. Stefan On May 25, 2010, at 6:15 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > Is anyone having trouble with genmap in the latest build (519)? I believe I last used genmap in version 503 without problems, but now when I try to run it, it immediately says "Killed". > > 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 May 25 14:15:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 May 2010 14:15:53 -0500 Subject: [Nek5000-users] Seg fault (may be from Hpts routine) In-Reply-To: References: Message-ID: Hi Stefan, This post is a follow-up to the earlier post by Markus. Do the points in the hpts.in file _have_ to be a GLL point ? If yes, is there some other way to monitor the flow at a point that is not a GLL point ? Anticipating that the vertices from VisIt would correspond to the mesh, I plugged in few points into the hpts.in file, but I still get the warning : WARNING: point not within mesh xy[z]: ! 0.4303500E+00 -0.9883920E-01 0.6029920E+00 I think, I am missing something here. Any hints would be helpful. Thanks. Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue May 25 14:18:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 May 2010 21:18:49 +0200 Subject: [Nek5000-users] Seg fault (may be from Hpts routine) In-Reply-To: References: Message-ID: <05C38D81-5BFE-40E8-A7EC-95EAB2FF1931@lav.mavt.ethz.ch> I am working on that. I'll let you know when it's fixed. Stefan On May 25, 2010, at 9:15 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > This post is a follow-up to the earlier post by Markus. Do the points in the hpts.in file _have_ to be a GLL point ? If yes, is there some other way to monitor the flow at a point that is not a GLL point ? > > Anticipating that the vertices from VisIt would correspond to the mesh, I plugged in few points into the hpts.in file, but I still get the warning : > > WARNING: point not within mesh xy[z]: ! 0.4303500E+00 -0.9883920E-01 0.6029920E+00 > > I think, I am missing something here. Any hints would be helpful. Thanks. > > Regards > Shriram > > _______________________________________________ > 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 May 26 09:37:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 26 May 2010 14:37:50 +0000 Subject: [Nek5000-users] MHD in a sphere Message-ID: Dear Aleks Saw your recent post that you would supply an example for MHD. I am looking to solve the MHD problem in a sphere (velocity, temperature and magnetic induction equations). Also need to set the boundary conditions for the electric current (conducting/insulating). Any help would be great.. many thanks Binod _________________________________________________________________ http://clk.atdmt.com/UKM/go/195013117/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 26 12:31:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 26 May 2010 12:31:29 -0500 (CDT) Subject: [Nek5000-users] MHD in a sphere In-Reply-To: Message-ID: <22404700.120601274895089813.JavaMail.root@zimbra> Hi Binod, I am still working on setup of 3D MHD example problem that can be added to the repo & buidbot. One thing to keep in mind that the code currently works only for boundary conditions on B field of the same type as velocity boundary condition. We are planning to make it more general in the future. Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, May 26, 2010 9:37:50 AM GMT -06:00 US/Canada Central Subject: [Nek5000-users] MHD in a sphere Dear Aleks Saw your recent post that you would supply an example for MHD. I am looking to solve the MHD problem in a sphere (velocity, temperature and magnetic induction equations). Also need to set the boundary conditions for the electric current (conducting/insulating). Any help would be great.. many thanks Binod Get a free e-mail account with Hotmail. Sign-up now. _______________________________________________ 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 May 26 12:17:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 26 May 2010 13:17:06 -0400 Subject: [Nek5000-users] genmap In-Reply-To: References: Message-ID: 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 Thu May 27 10:34:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 27 May 2010 10:34:27 -0500 Subject: [Nek5000-users] Qustions about averaging for a 2D case Message-ID: Hi, I am running a 2D DNS simulation of backward facing step combustor with a microjet. The microjet is placed on the step at 0.5H from the bottom wall. The incoming velocity is U_o = 12.5 m/s and the microjet velocity is 25 m/s. After running the case for 10 flow throughs, I started averaging over the next 8 flow throughs. But the results for averaging don't exactly look right. The geometry used and the averaged x-velocity colorfill contours can be seen in the image at link below. http://www2.uic.edu/~hkanch1/avg_mj10000.bmp I have tried averaging twice, once over 5 flow throughs and other over 8 flow throughs. Both time getting similar results. Here are the parameters that I am setting in the .rea file. ************************************************************************ 103 Parameters from file:/home/harish/nek5_examples/2D_bfs/mj_2d/mj1.rea 1 1.00000 DENSITY 2 1.556e-5 VISCOS 4 1.00000 GTHETA 7 1.00000 RHOCP 8 0.100000E-01 CONDUCT 11 128000.00 NSTEPS 12 -0.0000010 DT 15 128000 IOSTEP 18 0.500000E-01 GRID 19 -1.00000 INTYPE 20 5.00000 NORDER 21 1.000000E-07 DIVERGENCE 22 1.000000E-09 HELMHOLTZ 24 0.100000E-01 TOLREL 25 0.100000E-01 TOLABS 26 2.000000 COURANT 27 3.00000 TORDER 28 0.000000E+00 49 0.000000E+00 66 4.00000 write form (0), unform(1), universal(2) 67 4.00000 read form (0), unform (1), universal(2) 93 20.00000E+00 Number of pressure sol'ns saved 94 5.000000E+00 start saving pressure soln's after this 95 5.000000E+00 start saving pressure soln's after this 99 3.00000 p99 = 3 --> dealias turned on 103 0.01 103 filter weight IFTRAN = T IFFLOW = T IFHEAT = F IFSPLIT = T IFLOMACH = F IFUSERVP = F IFUSERMV = F IFSTRS = F IFCHAR = T IFCYCLIC = F IFAXIS = F IFMVBD = F IFMELT = F IFMODEL = F IFKEPS = F IFMOAB = F IFSYNC = T ************************************************************************ At the outflow, I am using the "fill_div(usrdiv)" subroutine provided in the "peris.usr" example. Is it possible the value of "vnmo_desire = 5.0", that I set, is too high? I choose this value because at lower values the simulation would blow up. Is there a way to calculate this value based on incoming velocity? Thanks for all the help, Harish From nek5000-users at lists.mcs.anl.gov Thu May 27 15:19:08 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 27 May 2010 15:19:08 -0500 (CDT) Subject: [Nek5000-users] mpich2? (fwd) Message-ID: Hi Stefan, Any ideas? Thanks! Paul ---------- Forwarded message ---------- Date: Thu, 27 May 2010 16:15:14 -0400 (EDT) From: Tamay Ozgokmen To: Zongjun Hu Cc: fischer at mcs.anl.gov Subject: mpich2? Hi Paul, I installed latest code on one of UM's linux clusters but have trouble to get p4c running; it gets stuck after the prelims. See below. Any ideas...? (I will be out of touch for a few hours, unfortunately, a later meeting...) Tamay gs_setup: 379187 unique labels shared pairwise times (avg, min, max): 0.0235193 0.0224905 0.043084 crystal router : 0.00944349 0.00717771 0.029574 used all_to_all method: crystal router setupds time 2.5930E+00 seconds 3 4 2545856 131072 setvert3d: 6 8149312 16537920 8149312 8149312 call usrsetvert done :: usrsetvert gs_setup: 1062197 unique labels shared pairwise times (avg, min, max): 0.0277191 0.0266448 0.0471066 crystal router : 0.0466603 0.0462395 0.0471185 used all_to_all method: pairwise setupds time 5.2800E+00 seconds 4 6 8149312 131072 setup h1 coarse grid, nx_crs= 2 call usrsetvert done :: usrsetvert gs_setup: 40385 unique labels shared pairwise times (avg, min, max): 0.000733222 0.00068059 0.000779104 crystal router : 0.00111822 0.00108392 0.00117099 all reduce : 0.0248416 0.0245946 0.0251968 used all_to_all method: pairwise gs_setup: 40385 unique labels shared pairwise times (avg, min, max): 0.000738662 0.000688004 0.000781512 crystal router : 0.00110533 0.00107729 0.00113969 all reduce : 0.0281804 0.0244667 0.0450669 used all_to_all method: pairwise rank 87 in job 1 n0422_55429 caused collective abort of all ranks exit status of rank 87: killed by signal 9 rank 88 in job 1 n0422_55429 caused collective abort of all ranks exit status of rank 88: killed by signal 9 rank 12 in job 1 n0422_55429 caused collective abort of all ranks exit status of rank 12: killed by signal 9 rank 50 in job 1 n0422_55429 caused collective abort of all ranks exit status of rank 50: killed by signal 9 rank 16 in job 1 n0422_55429 caused collective abort of all ranks exit status of rank 16: killed by signal 9 Job /share/apps/lsf/7.0/linux2.6-glibc2.3-x86_64/bin/mpich2_wrapper ./nek5000