From nek5000-users at lists.mcs.anl.gov Wed Feb 6 04:50:33 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 6 Feb 2013 11:50:33 +0100 Subject: [Nek5000-users] Steady Stokes solver Message-ID: Hi Nek's, I was wondering if any one has some exemples on how to set up the steady Stokes solver? Regards, -- Jean-Christophe LOISEAU -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Feb 6 09:06:09 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 6 Feb 2013 09:06:09 -0600 (CST) Subject: [Nek5000-users] Steady Stokes solver In-Reply-To: References: Message-ID: Hi Jean-Christophe, I've added 'kov_st_stokes' to the examples suite. You can compare the .rea file to the standard Kovasznay case. Note that steady Stokes works only for PN-PN-2 (lx2=lx1-2, etc.) Best regards, Paul On Wed, 6 Feb 2013, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > I was wondering if any one has some exemples on how to set up the steady > Stokes solver? > > Regards, > > -- > Jean-Christophe LOISEAU > From nek5000-users at lists.mcs.anl.gov Wed Feb 6 16:43:09 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 07 Feb 2013 00:43:09 +0200 Subject: [Nek5000-users] problems in installation Message-ID: Hi, I have just installed Nek5000. I followed the instructions found in the website, but it seems that it doesn't work. Do you have step-by-step instructions? for those who are not expert of linux OS? Many thanks Barak Galanti PS: I am interested in DNS simulations, especially turbulence. From nek5000-users at lists.mcs.anl.gov Thu Feb 7 04:19:52 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 7 Feb 2013 11:19:52 +0100 Subject: [Nek5000-users] Steady Stokes solver In-Reply-To: References: Message-ID: Thanks a lot Paul. I'll look into this within the next few days and I'll get back to you if I have any questions. Regards, 2013/2/6 > > Hi Jean-Christophe, > > I've added 'kov_st_stokes' to the examples suite. > > You can compare the .rea file to the standard Kovasznay case. > > Note that steady Stokes works only for PN-PN-2 (lx2=lx1-2, etc.) > > Best regards, > > Paul > > > > On Wed, 6 Feb 2013, nek5000-users at lists.mcs.anl.**govwrote: > > Hi Nek's, >> >> I was wondering if any one has some exemples on how to set up the steady >> Stokes solver? >> >> Regards, >> >> -- >> Jean-Christophe LOISEAU >> >> ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -- JC -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Feb 10 12:11:15 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 10 Feb 2013 19:11:15 +0100 Subject: [Nek5000-users] opdiv and multd In-Reply-To: <869885403.25443.1292350049972.JavaMail.root@zimbra.anl.gov> References: <4D07AE57.5040000@lav.mavt.ethz.ch> <869885403.25443.1292350049972.JavaMail.root@zimbra.anl.gov> Message-ID: Howdy Nek's, I have a question regarding axhelm (and other routines likes ophinv). Paul wrote: *"As an example, axhelm does not multiply by the (negative) Laplacian. Instead, it creates (for h1==1, h2==0): * * w = A * u * * = grad^T B grad u * * where B is the mass matrix." * So basically if (h1==1,h2==0), you only need to multiply by the inverse of the mass matrix to get laplacian(u) (+ some direct stiffness sumation). Am I right? What about if h1==0 and h2==1? What does axhelm return in this case? Same question about ophinv: subroutine ophinv (out1,out2,out3,inp1,inp2,inp3,h1,h2,tolh,nmxi) C---------------------------------------------------------------------- C C OUT = (H1*A+H2*B)-1 * INP (implicit) I presume that if (h1==1,h2==0), it solves: laplacian(out) = input. Is that right? What about (h1==0,h2==1) again? Regards and happy chinesse new year! 2010/12/14 > dssum() is just a wrapper for call gs_op() which takes only the input > field from the dssum call. But I agree in general it's a good idea to call > all subroutines with the correct arguments. > > -Stefan > > > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Tuesday, December 14, 2010 6:50:15 PM > Subject: Re: [Nek5000-users] opdiv and multd > > Sorry i have to do a correction. > > A user point it out that the subroutine is defined as dssum(u,nx,ny,nz) > in dssum.f . > Thus it should be called with 4 arguments : > > call dssum(RES(1),nx1,ny1,nz1) > > This did not give me problems and it seems to me that nx,ny,nz are not > used. > But it is better to be aware of it since i do not know how the compiler > will read the wrong call. > > Sorry about that. > francesco > > > > > On 12/08/2010 04:02 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > > Thanks Francesco! > > > > Paul > > > > > > On Wed, 8 Dec 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Thank you Paul, > >> that solved the problem. > >> > >> The correct result is obtained by : > >> call multd (RES(1),vx,rym2,sym2,tym2,2,iflg) > >> call dssum(RES(1)) > >> call col2(RES(1),binvm1,lt) > >> > >> francesco > >> > >> > >> > >> On 12/08/2010 02:17 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>> > >>> Hi Francesco, > >>> > >>> Several of the routines internal to nek are the so-called weak > >>> derivatives, implying that they somehow involve the mass matrix > >>> or the transpose of the operator, so it takes a bit of investigation > >>> to understand precisely what each operator is doing. (Note that the > >>> functionality also differs slightly between PN-PN and PN-PN-2 > >>> formulations.) > >>> > >>> As an example, axhelm does not multiply by the (negative) Laplacian. > >>> Instead, it creates (for h1==1, h2==0): > >>> > >>> w = A * u > >>> > >>> = grad^T B grad u > >>> > >>> where B is the mass matrix. > >>> > >>> Similarly, opdiv is most likely returning d = B*grad u (or perhaps > >>> the negative of this). Moreover, d is returned on the pressure > >>> mesh (mesh 2), which is the same as the velocity mesh (mesh 1) for > >>> the PN-PN formulation that you use. > >>> > >>> In Nek, the mass matrix is diagonal and the mesh 1 inverse is stored > >>> in binvm1. It seems probable that you'll get the correct result > >>> after > >>> > >>> call col2(d,binvm1,n) > >>> > >>> where d holds the output of opdiv and n is the number of points on > >>> mesh 1, assuming you're using PN-Pn. > >>> > >>> Paul > >>> > >>> > >>> > >>> On Wed, 8 Dec 2010, nek5000-users at lists.mcs.anl.gov wrote: > >>> > >>>> Hi all, > >>>> > >>>> I am having some problems using the subroutines opdiv and multd. > >>>> For some reasons they do not give me correct results. > >>>> Do they need any special treatment or precautions? > >>>> > >>>> I was trying to compute the divergence of a 3D field, and i > >>>> realized that in my case the multd subroutine used > >>>> by opdiv does not gives good results, while the same derivative > >>>> computed from gram1 gives no problems. > >>>> > >>>> For example, I overwrite an analytical field : > >>>> > >>>> ... > >>>> parameter(lt=lx1*ly1*lz1*lelt) > >>>> real Res(lt) > >>>> ... > >>>> vx(i,j,k,e)= 1.0*sin(x)*cos(y)*cos(z) > >>>> ... > >>>> call print_line(vx) > >>>> ... > >>>> iflg = 1 > >>>> call multd (RES(1),vx,rym2,sym2,tym2,2,iflg) > >>>> call print_line(Res(1) ) > >>>> > >>>> call gradm1(work1,Res(1),work2,vx) > >>>> call print_line(Res(1) ) > >>>> ... > >>>> if (lx2.ne.lx1) then > >>>> ... > >>>> STOP > >>>> endif > >>>> > >>>> > >>>> and print output a (xr,:,zr) the result (performed by print_line) . > >>>> In vxi.eps i compare the result (lines) with the analytical > >>>> solution( symbols). The result of multd is not correct while all > >>>> the others match perfectly the analytical solution. > >>>> In vxy.eps i plot only the result of multd. Note that on y i have > >>>> 12 elements the same number of peaks of the solution. > >>>> > >>>> Does anybody have an idea on how to fix this? > >>>> > >>>> Thank you very much for any help or suggestion > >>>> > >>>> francesco > >>>> > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> Nek5000-users mailing list > >>> Nek5000-users at lists.mcs.anl.gov > >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/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 > -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Feb 13 03:35:54 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 13 Feb 2013 10:35:54 +0100 Subject: [Nek5000-users] cyclic boundary conditions and pnpn-2 Message-ID: Dear Nek users, I am running both linear and nonlinear simulations of the flow over a rotating disk. To decrease the domain size, I use a circular sector of the disk which is made possible through the cyclic boundary conditions. When I use the cyclic boundary conditions for my nonlinear simulations together with pnpn-2 they blow up. I am not entirely sure why, although, I am currently just using pnpn instead. However, when I use these boundary conditions for my linear simulations, I have to use pnpn-2 since the perturbation solver is only implemented for this specific case, and this seems to work fine. I am also not sure why this works fine whereas the nonlinear case blows up (?). Anyway, my main question is if there are any plans to develop the pnpn-2 case for the cyclic boundary conditions in the nonlinear case? Or maybe what I'm wondering is if this would be an easy task to do? We are experiencing that it is faster to run with pnpn-2 than with pnpn and this would thus be an advantage. Best regards, Ellinor ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From nek5000-users at lists.mcs.anl.gov Wed Feb 13 07:10:28 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 13 Feb 2013 14:10:28 +0100 Subject: [Nek5000-users] turbulent heat transfer Message-ID: Dear all we are trying to make calculations of turbulent heat transfer in a pipe. Everything seems to work fine with the velocity field, however this is not the case for the temperature. It seems as if the convection for the temperature equation is switched off. So, we obtain a turbulent velocity distribution but a laminar temperature distribution. We have tried several thermal boundary condtions and at the moment we are just fixing the temperature at the wall T=0 and adding a heat source qvol=1. In the following we add details of the case. Thanks for your help Regards, Alex rea file ****** PARAMETERS ***** 2.6099999 NEKTON VERSION 3 DIMENSIONAL RUN 103 PARAMETERS FOLLOW 1.00000 p001 DENSITY -750. p002 VISCOS 0.00000 p003 0.00000 p004 0.00000 p005 0.00000 p006 1.00000 p007 RHOCP -0.7 p008 CONDUCT [...] 13 LOGICAL SWITCHES FOLLOW T IFFLOW T IFHEAT T IFTRAN T T F F F F F F F F F IFNAV & IFADVC (convection in P.S. fields) F F T T T T T T T T T T IFTMSH (IF mesh for this field is T mesh) F IFAXIS F IFSTRS F IFSPLIT F IFMGRID F IFMODEL F IFKEPS F IFMVBD F IFCHAR [...] usr file [...] c----------------------------- ------------------------------------------ subroutine userf (ix,iy,iz,ieg) include 'SIZE' include 'TOTAL' include 'NEKUSE' ffx = 0.0 ffy = 0.0 ffz = 2.0 return end c----------------------------------------------------------------------- subroutine userq (ix,iy,iz,ieg) include 'SIZE' include 'TOTAL' include 'NEKUSE' qvol = 1.0 source = 0.0 return end c----------------------------------------------------------------------- [...] -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Feb 13 08:08:43 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 13 Feb 2013 08:08:43 -0600 (CST) Subject: [Nek5000-users] turbulent heat transfer In-Reply-To: References: Message-ID: Hi Alex, I see you have ifadv set to T, which is correct. However, I also see that your conductivity is -.7, which implies your Peclet number is 0.7 ---- (assuming your Reynolds number is 750). Is this what you want ? Also, are you using periodic boundary conditions? If so, it takes a bit of care to get meaningful forcing conditions, particularly for the fixed-temperature boundary condition. (This condition leads to determination of an eigenvalue to find the fully-developed flow conditions, which have a bulk temperature scaling like exp(-lambda x). I can point you to some techniques for developing such conditions if you'd like.) Paul On Wed, 13 Feb 2013, nek5000-users at lists.mcs.anl.gov wrote: > Dear all > > we are trying to make calculations of turbulent heat transfer in a > pipe. Everything seems to work fine > with the velocity field, however this is not the case for the > temperature. It seems as if the convection > for the temperature equation is switched off. So, we obtain a > turbulent velocity distribution but a laminar temperature > distribution. > > We have tried several thermal boundary condtions and at the moment we > are just fixing the temperature at the wall > T=0 and adding a heat source qvol=1. In the following we add details > of the case. > > Thanks for your help > > Regards, > Alex > > rea file > ****** PARAMETERS ***** > 2.6099999 NEKTON VERSION > 3 DIMENSIONAL RUN > 103 PARAMETERS FOLLOW > 1.00000 p001 DENSITY > -750. p002 VISCOS > 0.00000 p003 > 0.00000 p004 > 0.00000 p005 > 0.00000 p006 > 1.00000 p007 RHOCP > -0.7 p008 CONDUCT > [...] > 13 LOGICAL SWITCHES FOLLOW > T IFFLOW > T IFHEAT > T IFTRAN > T T F F F F F F F F F IFNAV & IFADVC (convection in P.S. fields) > F F T T T T T T T T T T IFTMSH (IF mesh for this field is T mesh) > F IFAXIS > F IFSTRS > F IFSPLIT > F IFMGRID > F IFMODEL > F IFKEPS > F IFMVBD > F IFCHAR > [...] > > usr file > [...] > c----------------------------- > ------------------------------------------ > subroutine userf (ix,iy,iz,ieg) > include 'SIZE' > include 'TOTAL' > include 'NEKUSE' > > ffx = 0.0 > ffy = 0.0 > ffz = 2.0 > > return > end > c----------------------------------------------------------------------- > subroutine userq (ix,iy,iz,ieg) > include 'SIZE' > include 'TOTAL' > include 'NEKUSE' > > qvol = 1.0 > source = 0.0 > > return > end > c----------------------------------------------------------------------- > [...] > From nek5000-users at lists.mcs.anl.gov Wed Feb 13 08:31:09 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 13 Feb 2013 08:31:09 -0600 (CST) Subject: [Nek5000-users] major nek tools update In-Reply-To: References: Message-ID: Dear Neks, I wanted to alert you to a couple of revisions in the Nek toolset, aimed primarily at multi-million element mesh development. First, there is a major revision in prenek that aims to incorporate several new features, including the ability to merge multi-million element meshes (fewer than ~10 million, still), support for object definition when creating 2D meshes, and a fair amount of general cleanup. No doubt, things will break (for those of you who might be using prenek).... Please email this list with any issues and we'll seek to resolve them as quickly as possible. In addition to the prenek update, there has been an overhaul of potential formatting issues in serveral of the tools that arise in when one has periodic boundary conditions with E > 1,000,000. The new formats should work for E up to 2 billion. We are still putting the finishing touches on some of the tools (e.g., rea2re2 and n2to3), and expect these to be finished in a couple of days. I would thus recommend performing an svn update on the entire tools and nek directory, particularly if you are working in the high E limit. Thanks for your continued interest in Nek5000! Paul From nek5000-users at lists.mcs.anl.gov Wed Feb 13 08:48:27 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 13 Feb 2013 15:48:27 +0100 Subject: [Nek5000-users] turbulent heat transfer In-Reply-To: References: Message-ID: Dear Paul thanks for your quick answer. We thought we were imposing the Prandtl number since in the web we found the following information P008 CONDUCT conductivity for the case of constant properties (see parameter P030) if <0, it defines the Prandtl number Is the previous information not correct? Should we fix the conductivity to -750*0.7 or to 750*0.7 ? Concerning the boundary conditions we are indeed using periodic boundary conditions. However, we are not interested in the constant temperature case. We were using it for testing (since we errouneously thought it was easier). In the end we will impose the heat flux. Thanks again Best Regards, Alex 2013/2/13 > > Hi Alex, > > I see you have ifadv set to T, which is correct. > > However, I also see that your conductivity is -.7, which > implies your Peclet number is 0.7 ---- (assuming your Reynolds number is > 750). Is this what you want ? > > Also, are you using periodic boundary conditions? > If so, it takes a bit of care to get meaningful > forcing conditions, particularly for the fixed-temperature > boundary condition. (This condition leads to determination > of an eigenvalue to find the fully-developed flow conditions, > which have a bulk temperature scaling like exp(-lambda x). > I can point you to some techniques for developing such conditions if you'd > like.) > > Paul > > > > > On Wed, 13 Feb 2013, nek5000-users at lists.mcs.anl.**govwrote: > > Dear all >> >> we are trying to make calculations of turbulent heat transfer in a >> pipe. Everything seems to work fine >> with the velocity field, however this is not the case for the >> temperature. It seems as if the convection >> for the temperature equation is switched off. So, we obtain a >> turbulent velocity distribution but a laminar temperature >> distribution. >> >> We have tried several thermal boundary condtions and at the moment we >> are just fixing the temperature at the wall >> T=0 and adding a heat source qvol=1. In the following we add details >> of the case. >> >> Thanks for your help >> >> Regards, >> Alex >> >> rea file >> ****** PARAMETERS ***** >> 2.6099999 NEKTON VERSION >> 3 DIMENSIONAL RUN >> 103 PARAMETERS FOLLOW >> 1.00000 p001 DENSITY >> -750. p002 VISCOS >> 0.00000 p003 >> 0.00000 p004 >> 0.00000 p005 >> 0.00000 p006 >> 1.00000 p007 RHOCP >> -0.7 p008 CONDUCT >> [...] >> 13 LOGICAL SWITCHES FOLLOW >> T IFFLOW >> T IFHEAT >> T IFTRAN >> T T F F F F F F F F F IFNAV & IFADVC (convection in P.S. fields) >> F F T T T T T T T T T T IFTMSH (IF mesh for this field is T mesh) >> F IFAXIS >> F IFSTRS >> F IFSPLIT >> F IFMGRID >> F IFMODEL >> F IFKEPS >> F IFMVBD >> F IFCHAR >> [...] >> >> usr file >> [...] >> c----------------------------- >> ------------------------------**------------ >> subroutine userf (ix,iy,iz,ieg) >> include 'SIZE' >> include 'TOTAL' >> include 'NEKUSE' >> >> ffx = 0.0 >> ffy = 0.0 >> ffz = 2.0 >> >> return >> end >> c-----------------------------**------------------------------** >> ------------ >> subroutine userq (ix,iy,iz,ieg) >> include 'SIZE' >> include 'TOTAL' >> include 'NEKUSE' >> >> qvol = 1.0 >> source = 0.0 >> >> return >> end >> c-----------------------------**------------------------------** >> ------------ >> [...] >> >> ______________________________**_________________ > 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 Feb 13 08:53:18 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 13 Feb 2013 08:53:18 -0600 (CST) Subject: [Nek5000-users] turbulent heat transfer In-Reply-To: References: Message-ID: Dear Alex, OK... that's clearly an error in the documentation. As with param 2, a negative param 8 implies p8=1/|p8|, so that |input value| = Peclet number. My apologies for the confusion. We'll update the wiki. Thanks, Paul On Wed, 13 Feb 2013, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul > > thanks for your quick answer. We thought we were imposing the Prandtl > number since in the > web we found the following information > > P008 CONDUCT conductivity for the case of constant properties (see > parameter P030) if <0, it defines the Prandtl number > > Is the previous information not correct? > Should we fix the conductivity to -750*0.7 or to 750*0.7 ? > > Concerning the boundary conditions we are indeed using periodic boundary > conditions. > However, we are not interested in the > constant temperature case. We were using it for testing (since we > errouneously thought it > was easier). In the end we will impose > the heat flux. > > Thanks again > > Best Regards, > Alex > > 2013/2/13 > >> >> Hi Alex, >> >> I see you have ifadv set to T, which is correct. >> >> However, I also see that your conductivity is -.7, which >> implies your Peclet number is 0.7 ---- (assuming your Reynolds number is >> 750). Is this what you want ? >> >> Also, are you using periodic boundary conditions? >> If so, it takes a bit of care to get meaningful >> forcing conditions, particularly for the fixed-temperature >> boundary condition. (This condition leads to determination >> of an eigenvalue to find the fully-developed flow conditions, >> which have a bulk temperature scaling like exp(-lambda x). >> I can point you to some techniques for developing such conditions if you'd >> like.) >> >> Paul >> >> >> >> >> On Wed, 13 Feb 2013, nek5000-users at lists.mcs.anl.**govwrote: >> >> Dear all >>> >>> we are trying to make calculations of turbulent heat transfer in a >>> pipe. Everything seems to work fine >>> with the velocity field, however this is not the case for the >>> temperature. It seems as if the convection >>> for the temperature equation is switched off. So, we obtain a >>> turbulent velocity distribution but a laminar temperature >>> distribution. >>> >>> We have tried several thermal boundary condtions and at the moment we >>> are just fixing the temperature at the wall >>> T=0 and adding a heat source qvol=1. In the following we add details >>> of the case. >>> >>> Thanks for your help >>> >>> Regards, >>> Alex >>> >>> rea file >>> ****** PARAMETERS ***** >>> 2.6099999 NEKTON VERSION >>> 3 DIMENSIONAL RUN >>> 103 PARAMETERS FOLLOW >>> 1.00000 p001 DENSITY >>> -750. p002 VISCOS >>> 0.00000 p003 >>> 0.00000 p004 >>> 0.00000 p005 >>> 0.00000 p006 >>> 1.00000 p007 RHOCP >>> -0.7 p008 CONDUCT >>> [...] >>> 13 LOGICAL SWITCHES FOLLOW >>> T IFFLOW >>> T IFHEAT >>> T IFTRAN >>> T T F F F F F F F F F IFNAV & IFADVC (convection in P.S. fields) >>> F F T T T T T T T T T T IFTMSH (IF mesh for this field is T mesh) >>> F IFAXIS >>> F IFSTRS >>> F IFSPLIT >>> F IFMGRID >>> F IFMODEL >>> F IFKEPS >>> F IFMVBD >>> F IFCHAR >>> [...] >>> >>> usr file >>> [...] >>> c----------------------------- >>> ------------------------------**------------ >>> subroutine userf (ix,iy,iz,ieg) >>> include 'SIZE' >>> include 'TOTAL' >>> include 'NEKUSE' >>> >>> ffx = 0.0 >>> ffy = 0.0 >>> ffz = 2.0 >>> >>> return >>> end >>> c-----------------------------**------------------------------** >>> ------------ >>> subroutine userq (ix,iy,iz,ieg) >>> include 'SIZE' >>> include 'TOTAL' >>> include 'NEKUSE' >>> >>> qvol = 1.0 >>> source = 0.0 >>> >>> return >>> end >>> c-----------------------------**------------------------------** >>> ------------ >>> [...] >>> >>> ______________________________**_________________ >> 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 Feb 13 09:01:40 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 13 Feb 2013 09:01:40 -0600 (CST) Subject: [Nek5000-users] turbulent heat transfer In-Reply-To: References: Message-ID: PS - sorry - I forgot to answer your question about how to set p8. I guess I would set p2=-750 and p8 = -(750*0.7) On Wed, 13 Feb 2013, nek5000-users at lists.mcs.anl.gov wrote: > > > Dear Alex, > > OK... that's clearly an error in the documentation. > > As with param 2, a negative param 8 implies p8=1/|p8|, > so that |input value| = Peclet number. > > My apologies for the confusion. We'll update the wiki. > > Thanks, > > Paul > > > > On Wed, 13 Feb 2013, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Paul >> >> thanks for your quick answer. We thought we were imposing the Prandtl >> number since in the >> web we found the following information >> >> P008 CONDUCT conductivity for the case of constant properties (see >> parameter P030) if <0, it defines the Prandtl number >> >> Is the previous information not correct? >> Should we fix the conductivity to -750*0.7 or to 750*0.7 ? >> >> Concerning the boundary conditions we are indeed using periodic boundary >> conditions. >> However, we are not interested in the >> constant temperature case. We were using it for testing (since we >> errouneously thought it >> was easier). In the end we will impose >> the heat flux. >> >> Thanks again >> >> Best Regards, >> Alex >> >> 2013/2/13 >> >>> >>> Hi Alex, >>> >>> I see you have ifadv set to T, which is correct. >>> >>> However, I also see that your conductivity is -.7, which >>> implies your Peclet number is 0.7 ---- (assuming your Reynolds number is >>> 750). Is this what you want ? >>> >>> Also, are you using periodic boundary conditions? >>> If so, it takes a bit of care to get meaningful >>> forcing conditions, particularly for the fixed-temperature >>> boundary condition. (This condition leads to determination >>> of an eigenvalue to find the fully-developed flow conditions, >>> which have a bulk temperature scaling like exp(-lambda x). >>> I can point you to some techniques for developing such conditions if you'd >>> like.) >>> >>> Paul >>> >>> >>> >>> >>> On Wed, 13 Feb 2013, >>> nek5000-users at lists.mcs.anl.**govwrote: >>> >>> Dear all >>>> >>>> we are trying to make calculations of turbulent heat transfer in a >>>> pipe. Everything seems to work fine >>>> with the velocity field, however this is not the case for the >>>> temperature. It seems as if the convection >>>> for the temperature equation is switched off. So, we obtain a >>>> turbulent velocity distribution but a laminar temperature >>>> distribution. >>>> >>>> We have tried several thermal boundary condtions and at the moment we >>>> are just fixing the temperature at the wall >>>> T=0 and adding a heat source qvol=1. In the following we add details >>>> of the case. >>>> >>>> Thanks for your help >>>> >>>> Regards, >>>> Alex >>>> >>>> rea file >>>> ****** PARAMETERS ***** >>>> 2.6099999 NEKTON VERSION >>>> 3 DIMENSIONAL RUN >>>> 103 PARAMETERS FOLLOW >>>> 1.00000 p001 DENSITY >>>> -750. p002 VISCOS >>>> 0.00000 p003 >>>> 0.00000 p004 >>>> 0.00000 p005 >>>> 0.00000 p006 >>>> 1.00000 p007 RHOCP >>>> -0.7 p008 CONDUCT >>>> [...] >>>> 13 LOGICAL SWITCHES FOLLOW >>>> T IFFLOW >>>> T IFHEAT >>>> T IFTRAN >>>> T T F F F F F F F F F IFNAV & IFADVC (convection in P.S. fields) >>>> F F T T T T T T T T T T IFTMSH (IF mesh for this field is T mesh) >>>> F IFAXIS >>>> F IFSTRS >>>> F IFSPLIT >>>> F IFMGRID >>>> F IFMODEL >>>> F IFKEPS >>>> F IFMVBD >>>> F IFCHAR >>>> [...] >>>> >>>> usr file >>>> [...] >>>> c----------------------------- >>>> ------------------------------**------------ >>>> subroutine userf (ix,iy,iz,ieg) >>>> include 'SIZE' >>>> include 'TOTAL' >>>> include 'NEKUSE' >>>> >>>> ffx = 0.0 >>>> ffy = 0.0 >>>> ffz = 2.0 >>>> >>>> return >>>> end >>>> c-----------------------------**------------------------------** >>>> ------------ >>>> subroutine userq (ix,iy,iz,ieg) >>>> include 'SIZE' >>>> include 'TOTAL' >>>> include 'NEKUSE' >>>> >>>> qvol = 1.0 >>>> source = 0.0 >>>> >>>> return >>>> end >>>> c-----------------------------**------------------------------** >>>> ------------ >>>> [...] >>>> >>>> ______________________________**_________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.**gov >>> https://lists.mcs.anl.gov/**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 Feb 13 09:06:05 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 13 Feb 2013 20:36:05 +0530 Subject: [Nek5000-users] major nek tools update In-Reply-To: References: Message-ID: Hello I am having trouble compiling tools. I get this error. I am on mac snow leopard. Thanks praveen ---------------------- Make prenek... ---------------------- gfortran -mcmodel=medium -c prenek.f gfortran -mcmodel=medium -c curve.f gfortran -mcmodel=medium -c edit.f gfortran -mcmodel=medium -c build.f build.f:2521.15: if (.not.iflow) ifld0=2 1 Error: Operand of .not. operator at (1) is INTEGER(4) build.f:2525.18: if (.not.iflow) read(47,*) ans ! dummy read 1 Error: Operand of .not. operator at (1) is INTEGER(4) build.f:3560.13: iftmp =ifgrid 1 Warning: Extension: Conversion from LOGICAL(4) to INTEGER(4) at (1) build.f:3566.16: ifgrid=iftmp 1 Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1) build.f:3578.19: ifgrid=iftmp 1 Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1) build.f:3622.16: ifgrid=iftmp 1 Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1) build.f:3652.22: ifgrid=iftmp 1 Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1) build.f:3672.13: ifgrid=iftmp 1 Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1) make[1]: *** [build.o] Error 1 make: *** [all] Error 1 On Wed, Feb 13, 2013 at 8:01 PM, wrote: > > > Dear Neks, > > I wanted to alert you to a couple of revisions in > the Nek toolset, aimed primarily at multi-million > element mesh development. > > First, there is a major revision in prenek that aims to incorporate > several new features, including > the ability to merge multi-million element meshes (fewer > than ~10 million, still), support for object definition when > creating 2D meshes, and a fair amount of general cleanup. > > No doubt, things will break (for those of you who might > be using prenek).... Please email this list with any > issues and we'll seek to resolve them as quickly as > possible. > > In addition to the prenek update, there has been an > overhaul of potential formatting issues in serveral > of the tools that arise in when one has periodic boundary conditions with > E > 1,000,000. The new formats should work for E up to 2 billion. We > are still putting the > finishing touches on some of the tools (e.g., rea2re2 > and n2to3), and expect these to be finished in a couple > of days. > > I would thus recommend performing an svn update on the > entire tools and nek directory, particularly if you are working in the > high E limit. > > Thanks for your continued interest in Nek5000! > > Paul > > ______________________________**_________________ > 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 Feb 13 09:25:24 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 13 Feb 2013 09:25:24 -0600 (CST) Subject: [Nek5000-users] major nek tools update In-Reply-To: References: Message-ID: Thanks Praveen!... OK... I see I haven't rigorously tested against enough compilers... Will follow-up with an email once I clean up this and a few other items. Paul On Wed, 13 Feb 2013, nek5000-users at lists.mcs.anl.gov wrote: > Hello > > I am having trouble compiling tools. I get this error. I am on mac snow > leopard. > > Thanks > praveen > > ---------------------- > Make prenek... > ---------------------- > gfortran -mcmodel=medium -c prenek.f > gfortran -mcmodel=medium -c curve.f > gfortran -mcmodel=medium -c edit.f > gfortran -mcmodel=medium -c build.f > build.f:2521.15: > > if (.not.iflow) ifld0=2 > 1 > Error: Operand of .not. operator at (1) is INTEGER(4) > build.f:2525.18: > > if (.not.iflow) read(47,*) ans ! dummy read > 1 > Error: Operand of .not. operator at (1) is INTEGER(4) > build.f:3560.13: > > iftmp =ifgrid > 1 > Warning: Extension: Conversion from LOGICAL(4) to INTEGER(4) at (1) > build.f:3566.16: > > ifgrid=iftmp > 1 > Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1) > build.f:3578.19: > > ifgrid=iftmp > 1 > Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1) > build.f:3622.16: > > ifgrid=iftmp > 1 > Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1) > build.f:3652.22: > > ifgrid=iftmp > 1 > Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1) > build.f:3672.13: > > ifgrid=iftmp > 1 > Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1) > make[1]: *** [build.o] Error 1 > make: *** [all] Error 1 > > > > On Wed, Feb 13, 2013 at 8:01 PM, wrote: > >> >> >> Dear Neks, >> >> I wanted to alert you to a couple of revisions in >> the Nek toolset, aimed primarily at multi-million >> element mesh development. >> >> First, there is a major revision in prenek that aims to incorporate >> several new features, including >> the ability to merge multi-million element meshes (fewer >> than ~10 million, still), support for object definition when >> creating 2D meshes, and a fair amount of general cleanup. >> >> No doubt, things will break (for those of you who might >> be using prenek).... Please email this list with any >> issues and we'll seek to resolve them as quickly as >> possible. >> >> In addition to the prenek update, there has been an >> overhaul of potential formatting issues in serveral >> of the tools that arise in when one has periodic boundary conditions with >> E > 1,000,000. The new formats should work for E up to 2 billion. We >> are still putting the >> finishing touches on some of the tools (e.g., rea2re2 >> and n2to3), and expect these to be finished in a couple >> of days. >> >> I would thus recommend performing an svn update on the >> entire tools and nek directory, particularly if you are working in the >> high E limit. >> >> Thanks for your continued interest in Nek5000! >> >> Paul >> >> ______________________________**_________________ >> 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 Feb 18 11:53:35 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 18 Feb 2013 17:53:35 +0000 Subject: [Nek5000-users] Rayleigh Benard with symmetry BCs Message-ID: My apologies upfront for any simple misconceptions as I'm new to nek. I have successfully run the included 2d RB example and thought things looked reasonable. I then changed the mesh to an aspect ratio 2, 4x8 element mesh and modified the boundary conditions to be 'SYM' sidewalls and 'SYM' (free-slip) for the top and bottom velocity (see attached rea and map file). Without changing anything else from the example (I did not modify SIZE) the velocities appear to blow up, and I get a series of errors like the following in the logfile: 1 100 **ERROR**: Failed in HMHOLTZ: TEMP 1.4999E-02 3.7064E+01 2.4836E-03 1 2.0000E-02 6.0370E-03 Heat done 1 100 **ERROR**: Failed in HMHOLTZ: VELX 2.8743E-21 1.7086E-16 2.3416E-23 0.000000000000000E+000 p22 1 1 New CG1-tolerance (RINIT*epsm) = 1.010379228335448E-010 2.341589846098494E-023 1 100 **ERROR**: Failed in HMHOLTZ: VELY 1.0837E-01 1.0104E+03 1.0104E-10 New CG2-tolerance (RINIT*10-5/10-10) = 2.795810823528297E-003 3.472834773690102E-025 Do I need to adjust the tolerances because the mesh/BCs are different? I don't think it matters, but I ran this on 16 procs (there are 16 per node on the machine I'm using). -Jared CCS2/CNLS Postdoctoral Research Associate Los Alamos National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: NEK.map URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NEK.rea Type: application/octet-stream Size: 30722 bytes Desc: NEK.rea URL: From nek5000-users at lists.mcs.anl.gov Mon Feb 18 12:24:26 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 18 Feb 2013 12:24:26 -0600 Subject: [Nek5000-users] Rayleigh Benard with symmetry BCs In-Reply-To: References: Message-ID: Hi Jared, If you send me your .box file, I will check that just in case. Also, I see you are using variable time steps, so try reducing the target Courant number to 1/2. Another thing to be aware of with variable time stepping: if the Rayleigh number is large and the simulation starts from a static state, the exponentially growing velocities might still cause the CFL condition to be violated. The solution to this is to decrease the maximum allowed time step, DT. This is unlikely to be your problem at the current Rayleigh number, however. -David On Mon, Feb 18, 2013 at 11:53 AM, wrote: > My apologies upfront for any simple misconceptions as I'm new to nek. > > I have successfully run the included 2d RB example and thought things > looked reasonable. I then changed the mesh to an aspect ratio 2, 4x8 > element mesh and modified the boundary conditions to be 'SYM' sidewalls and > 'SYM' (free-slip) for the top and bottom velocity (see attached rea and map > file). > > Without changing anything else from the example (I did not modify SIZE) > the velocities appear to blow up, and I get a series of errors like the > following in the logfile: > > 1 100 **ERROR**: Failed in HMHOLTZ: TEMP 1.4999E-02 > 3.7064E+01 2.4836E-03 > 1 2.0000E-02 6.0370E-03 Heat done > > 1 100 **ERROR**: Failed in HMHOLTZ: VELX 2.8743E-21 > 1.7086E-16 2.3416E-23 > 0.000000000000000E+000 p22 1 1 > New CG1-tolerance (RINIT*epsm) = 1.010379228335448E-010 > 2.341589846098494E-023 > > > 1 100 **ERROR**: Failed in HMHOLTZ: VELY 1.0837E-01 > 1.0104E+03 1.0104E-10 > New CG2-tolerance (RINIT*10-5/10-10) = 2.795810823528297E-003 > 3.472834773690102E-025 > > > > Do I need to adjust the tolerances because the mesh/BCs are different? > > > I don't think it matters, but I ran this on 16 procs (there are 16 per > node on the machine I'm using). > > -Jared > > CCS2/CNLS Postdoctoral Research Associate > Los Alamos National Laboratory > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > On Mon, Feb 18, 2013 at 11:53 AM, wrote: > My apologies upfront for any simple misconceptions as I'm new to nek. > > I have successfully run the included 2d RB example and thought things > looked reasonable. I then changed the mesh to an aspect ratio 2, 4x8 > element mesh and modified the boundary conditions to be 'SYM' sidewalls and > 'SYM' (free-slip) for the top and bottom velocity (see attached rea and map > file). > > Without changing anything else from the example (I did not modify SIZE) > the velocities appear to blow up, and I get a series of errors like the > following in the logfile: > > 1 100 **ERROR**: Failed in HMHOLTZ: TEMP 1.4999E-02 > 3.7064E+01 2.4836E-03 > 1 2.0000E-02 6.0370E-03 Heat done > > 1 100 **ERROR**: Failed in HMHOLTZ: VELX 2.8743E-21 > 1.7086E-16 2.3416E-23 > 0.000000000000000E+000 p22 1 1 > New CG1-tolerance (RINIT*epsm) = 1.010379228335448E-010 > 2.341589846098494E-023 > > > 1 100 **ERROR**: Failed in HMHOLTZ: VELY 1.0837E-01 > 1.0104E+03 1.0104E-10 > New CG2-tolerance (RINIT*10-5/10-10) = 2.795810823528297E-003 > 3.472834773690102E-025 > > > > Do I need to adjust the tolerances because the mesh/BCs are different? > > > I don't think it matters, but I ran this on 16 procs (there are 16 per > node on the machine I'm using). > > -Jared > > CCS2/CNLS Postdoctoral Research Associate > Los Alamos National Laboratory > > _______________________________________________ > 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 Feb 18 13:57:19 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 18 Feb 2013 19:57:19 +0000 Subject: [Nek5000-users] Rayleigh Benard with symmetry BCs In-Reply-To: References: , Message-ID: David- Here is the .box file I used to generate the mesh. I noticed the CFL target number issue, it looks like nek resets it to 0.5 anyway. -Jared CCS2/CNLS Postdoctoral Research Associate Los Alamos National Laboratory ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Monday, February 18, 2013 11:24 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Rayleigh Benard with symmetry BCs Hi Jared, If you send me your .box file, I will check that just in case. Also, I see you are using variable time steps, so try reducing the target Courant number to 1/2. Another thing to be aware of with variable time stepping: if the Rayleigh number is large and the simulation starts from a static state, the exponentially growing velocities might still cause the CFL condition to be violated. The solution to this is to decrease the maximum allowed time step, DT. This is unlikely to be your problem at the current Rayleigh number, however. -David On Mon, Feb 18, 2013 at 11:53 AM, > wrote: My apologies upfront for any simple misconceptions as I'm new to nek. I have successfully run the included 2d RB example and thought things looked reasonable. I then changed the mesh to an aspect ratio 2, 4x8 element mesh and modified the boundary conditions to be 'SYM' sidewalls and 'SYM' (free-slip) for the top and bottom velocity (see attached rea and map file). Without changing anything else from the example (I did not modify SIZE) the velocities appear to blow up, and I get a series of errors like the following in the logfile: 1 100 **ERROR**: Failed in HMHOLTZ: TEMP 1.4999E-02 3.7064E+01 2.4836E-03 1 2.0000E-02 6.0370E-03 Heat done 1 100 **ERROR**: Failed in HMHOLTZ: VELX 2.8743E-21 1.7086E-16 2.3416E-23 0.000000000000000E+000 p22 1 1 New CG1-tolerance (RINIT*epsm) = 1.010379228335448E-010 2.341589846098494E-023 1 100 **ERROR**: Failed in HMHOLTZ: VELY 1.0837E-01 1.0104E+03 1.0104E-10 New CG2-tolerance (RINIT*10-5/10-10) = 2.795810823528297E-003 3.472834773690102E-025 Do I need to adjust the tolerances because the mesh/BCs are different? I don't think it matters, but I ran this on 16 procs (there are 16 per node on the machine I'm using). -Jared CCS2/CNLS Postdoctoral Research Associate Los Alamos National Laboratory _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users On Mon, Feb 18, 2013 at 11:53 AM, > wrote: My apologies upfront for any simple misconceptions as I'm new to nek. I have successfully run the included 2d RB example and thought things looked reasonable. I then changed the mesh to an aspect ratio 2, 4x8 element mesh and modified the boundary conditions to be 'SYM' sidewalls and 'SYM' (free-slip) for the top and bottom velocity (see attached rea and map file). Without changing anything else from the example (I did not modify SIZE) the velocities appear to blow up, and I get a series of errors like the following in the logfile: 1 100 **ERROR**: Failed in HMHOLTZ: TEMP 1.4999E-02 3.7064E+01 2.4836E-03 1 2.0000E-02 6.0370E-03 Heat done 1 100 **ERROR**: Failed in HMHOLTZ: VELX 2.8743E-21 1.7086E-16 2.3416E-23 0.000000000000000E+000 p22 1 1 New CG1-tolerance (RINIT*epsm) = 1.010379228335448E-010 2.341589846098494E-023 1 100 **ERROR**: Failed in HMHOLTZ: VELY 1.0837E-01 1.0104E+03 1.0104E-10 New CG2-tolerance (RINIT*10-5/10-10) = 2.795810823528297E-003 3.472834773690102E-025 Do I need to adjust the tolerances because the mesh/BCs are different? I don't think it matters, but I ran this on 16 procs (there are 16 per node on the machine I'm using). -Jared CCS2/CNLS Postdoctoral Research Associate Los Alamos National Laboratory _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: my_ray.box Type: application/octet-stream Size: 638 bytes Desc: my_ray.box URL: From nek5000-users at lists.mcs.anl.gov Mon Feb 18 14:02:45 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 18 Feb 2013 14:02:45 -0600 Subject: [Nek5000-users] Rayleigh Benard with symmetry BCs In-Reply-To: References: Message-ID: Hi Jared, I think boundary condition designators in the .box file must be 3 characters, so when you change W to SYM, for instance, you would remove the 2 spaces following W. See if this works: SYM,SYM,SYM,SYM, SYM,SYM,t ,t , -David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Feb 19 09:55:22 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 19 Feb 2013 15:55:22 +0000 Subject: [Nek5000-users] Rayleigh Benard with symmetry BCs In-Reply-To: References: , Message-ID: David- I think this may have gotten past this issue. It now appears that the Helmholtz solver is converging (if I make DT small enough). However I can't get this to run longer than 30 seconds of wall clock time. Is there something I'm missing that could be causing this? -Jared CCS2/CNLS Postdoctoral Research Associate Los Alamos National Laboratory ________________________________ From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov] Sent: Monday, February 18, 2013 1:02 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Rayleigh Benard with symmetry BCs Hi Jared, I think boundary condition designators in the .box file must be 3 characters, so when you change W to SYM, for instance, you would remove the 2 spaces following W. See if this works: SYM,SYM,SYM,SYM, SYM,SYM,t ,t , -David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Feb 27 05:52:23 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 27 Feb 2013 19:52:23 +0800 Subject: [Nek5000-users] Impose inflow conditions from another simulation Message-ID: Hello nek5000-users, I have a data file obtained through a RANS simulation that I would like to use as the inflow condition for my subsequent nek5000 simulation. May I know whether there is an efficient subroutine which allows me to interpolate the RANS data onto the spectral-element mesh or, at least, allows me to dump out the nodal points at the inlet so that I can perform the interpolation and assignment? I will be performing a parallel simulation involving 300000 elements. Hence I will be grateful if someone could provide me with an efficient method. Thanks in advance. Ng Jee Hann (Mr.) PhD Student. Department of Mechanical Engineering, National University of Singapore, 9 Engineering Drive 1, Singapore 117576. -------------- next part -------------- An HTML attachment was scrubbed... URL: