From nek5000-users at lists.mcs.anl.gov Wed Mar 2 13:00:55 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 2 Mar 2011 13:00:55 -0600 Subject: [Nek5000-users] Calculating local skin friction coefficient Message-ID: <918ed1e731a2e63e950c631c1761112e.squirrel@webmail.uic.edu> Hello, I am trying to compute local skin friction coefficient (C_f) at bottom wall in a backward facing step. The flow is simulated at Re=5000. I need to figure this out to test the effect of time step size (dt) on transition to turbulence. Quantities used: tau_w = wall shear stress U_inf = reference velocity definition of C_f := 2 * tau_w/ rho*U_inf tau_w = -mu*du/dy ( at wall) C_f = 2 * nu * du/dy To compute C_f I am using use the following (code snippet): call comp_sij(sij,nij,vx,vy,vz,ur,us,ut,vr,vs,vt,wr,ws,wt) v = visc(j1,j2,1,e) ! from subroutine drgtrq() s12 = sij(j1,j2,1,4,e) s22 = sij(j1,j2,1,2,e) s32 = sij(j1,j2,1,5,e) Cf = 2*v*s12 Am I doing this right? Any help would be appreciated. Thanks, Harish. From nek5000-users at lists.mcs.anl.gov Wed Mar 2 13:32:54 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 2 Mar 2011 13:32:54 -0600 (CST) Subject: [Nek5000-users] Calculating local skin friction coefficient In-Reply-To: <918ed1e731a2e63e950c631c1761112e.squirrel@webmail.uic.edu> References: <918ed1e731a2e63e950c631c1761112e.squirrel@webmail.uic.edu> Message-ID: Hi Harish, I have not used comp_sij routine myself but from what I see in the source (navier5.f:2266) sij(i,4,e) = j* ! du/dy + dv/dx ... which is different from your goal of du/dy unless v is not a function of x. I am assuming you set your j1,j2 correctly for your boundary element surfaces and you solve for non-dimentional values. If you have constant properties then you do not need to fill up the array visc -- you can just use param(2) instead. It may be a good idea as usual to set a test problem with analytical non-trivial initial conditions and run it w/ nsteps=0 just to make sure you get the answer you want... Best, Aleks On Wed, 2 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I am trying to compute local skin friction coefficient (C_f) at bottom > wall in a backward facing step. The flow is simulated at Re=5000. I need > to figure this out to test the effect of time step size (dt) on transition > to turbulence. > > Quantities used: > tau_w = wall shear stress > U_inf = reference velocity > > definition of C_f := 2 * tau_w/ rho*U_inf > > tau_w = -mu*du/dy ( at wall) > > C_f = 2 * nu * du/dy > > To compute C_f I am using use the following (code snippet): > > call comp_sij(sij,nij,vx,vy,vz,ur,us,ut,vr,vs,vt,wr,ws,wt) > > v = visc(j1,j2,1,e) ! from subroutine drgtrq() > s12 = sij(j1,j2,1,4,e) > s22 = sij(j1,j2,1,2,e) > s32 = sij(j1,j2,1,5,e) > Cf = 2*v*s12 > > Am I doing this right? Any help would be 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 Wed Mar 2 13:45:54 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 2 Mar 2011 13:45:54 -0600 (CST) Subject: [Nek5000-users] Calculating local skin friction coefficient In-Reply-To: References: <918ed1e731a2e63e950c631c1761112e.squirrel@webmail.uic.edu> Message-ID: Hi Aleks, Thanks for your reply. I am solving for constant properties and in non-dimensional terms. I am using a modified drgtrq subroutine, so my j1,j2's are right. You are right that from navier5.f and my definition of s12, s12 = s(i,4,e) = j * ! du/dy + dv/dx But at wall dv/dx = 0, therefore s12 = du/dy That is why I was using s12 in my computation. I this wrong then. Thanks, Harish. On Wed, 2 Mar 2011 nek5000-users at lists.mcs.anl.gov wrote: > Hi Harish, > > I have not used comp_sij routine myself but from what I see in the source > (navier5.f:2266) > > sij(i,4,e) = j* ! du/dy + dv/dx > ... > which is different from your goal of du/dy unless v is not a function of > x. > > I am assuming you set your j1,j2 correctly for your boundary element > surfaces and you solve for non-dimentional values. If you have constant > properties then you do not need to fill up the array visc -- you can just > use param(2) instead. > > It may be a good idea as usual to set a test problem with analytical > non-trivial initial conditions and run it w/ nsteps=0 just to make sure > you get the answer you want... > > Best, > Aleks > > > > > > On Wed, 2 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello, > > > > I am trying to compute local skin friction coefficient (C_f) at bottom > > wall in a backward facing step. The flow is simulated at Re=5000. I need > > to figure this out to test the effect of time step size (dt) on transition > > to turbulence. > > > > Quantities used: > > tau_w = wall shear stress > > U_inf = reference velocity > > > > definition of C_f := 2 * tau_w/ rho*U_inf > > > > tau_w = -mu*du/dy ( at wall) > > > > C_f = 2 * nu * du/dy > > > > To compute C_f I am using use the following (code snippet): > > > > call comp_sij(sij,nij,vx,vy,vz,ur,us,ut,vr,vs,vt,wr,ws,wt) > > > > v = visc(j1,j2,1,e) ! from subroutine drgtrq() > > s12 = sij(j1,j2,1,4,e) > > s22 = sij(j1,j2,1,2,e) > > s32 = sij(j1,j2,1,5,e) > > Cf = 2*v*s12 > > > > Am I doing this right? Any help would be 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 Wed Mar 2 17:01:13 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 2 Mar 2011 17:01:13 -0600 (CST) Subject: [Nek5000-users] Calculating local skin friction coefficient In-Reply-To: References: <918ed1e731a2e63e950c631c1761112e.squirrel@webmail.uic.edu> Message-ID: Hi Harish, It seems to me you should just be able to use the torque_calc routine, applied to an object which is defined as a collection of faces. All that you have to do is to identify the faces. I usually write a routine "set_obj" to do this --- two examples of which can be found in ext_cyl turbChannel in /examples directory. Hope this helps. Paul On Wed, 2 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Aleks, > > Thanks for your reply. > > I am solving for constant properties and in non-dimensional terms. I am > using a modified drgtrq subroutine, so my j1,j2's are right. > > You are right that from navier5.f and my definition of s12, > > s12 = s(i,4,e) = j * ! du/dy + dv/dx > > But at wall dv/dx = 0, therefore > > s12 = du/dy > > That is why I was using s12 in my computation. I this wrong then. > > Thanks, > > Harish. > > On Wed, 2 Mar 2011 nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Harish, >> >> I have not used comp_sij routine myself but from what I see in the source >> (navier5.f:2266) >> >> sij(i,4,e) = j* ! du/dy + dv/dx >> ... >> which is different from your goal of du/dy unless v is not a function of >> x. >> >> I am assuming you set your j1,j2 correctly for your boundary element >> surfaces and you solve for non-dimentional values. If you have constant >> properties then you do not need to fill up the array visc -- you can just >> use param(2) instead. >> >> It may be a good idea as usual to set a test problem with analytical >> non-trivial initial conditions and run it w/ nsteps=0 just to make sure >> you get the answer you want... >> >> Best, >> Aleks >> >> >> >> >> >> On Wed, 2 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello, >>> >>> I am trying to compute local skin friction coefficient (C_f) at bottom >>> wall in a backward facing step. The flow is simulated at Re=5000. I need >>> to figure this out to test the effect of time step size (dt) on transition >>> to turbulence. >>> >>> Quantities used: >>> tau_w = wall shear stress >>> U_inf = reference velocity >>> >>> definition of C_f := 2 * tau_w/ rho*U_inf >>> >>> tau_w = -mu*du/dy ( at wall) >>> >>> C_f = 2 * nu * du/dy >>> >>> To compute C_f I am using use the following (code snippet): >>> >>> call comp_sij(sij,nij,vx,vy,vz,ur,us,ut,vr,vs,vt,wr,ws,wt) >>> >>> v = visc(j1,j2,1,e) ! from subroutine drgtrq() >>> s12 = sij(j1,j2,1,4,e) >>> s22 = sij(j1,j2,1,2,e) >>> s32 = sij(j1,j2,1,5,e) >>> Cf = 2*v*s12 >>> >>> Am I doing this right? Any help would be 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 Fri Mar 4 18:24:42 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 Mar 2011 18:24:42 -0600 Subject: [Nek5000-users] Degrees of freedom Message-ID: Hello Neks, I am busy writing my thesis, and I would like to report my degrees of freedom. I see underneath the "gridpoints unique/tot:" line something that says "dofs:". There are two numbers listed here. For me, the first one is 6441414 and the 2nd one is 4081752. This is probably a dumb question, but what are these two numbers representing? Thanks, -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Fri Mar 4 18:48:54 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 Mar 2011 18:48:54 -0600 (CST) Subject: [Nek5000-users] Degrees of freedom In-Reply-To: References: Message-ID: Josh, 4081752 is the number of pressure degrees of freedom the other is the number of velocity degrees of freedom (save that you need to multiply by 3, since there are 3 velocity components at each gridpoint). So, in effect, the first number is the rank of the Helmholtz operator for each of the 3 velocity components. Paul On Fri, 4 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello Neks, > > I am busy writing my thesis, and I would like to report my degrees of > freedom. I see underneath the "gridpoints unique/tot:" line something > that says "dofs:". There are two numbers listed here. For me, the > first one is 6441414 and the 2nd one is 4081752. > > This is probably a dumb question, but what are these two numbers representing? > > Thanks, > > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sat Mar 5 07:17:30 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 5 Mar 2011 18:47:30 +0530 Subject: [Nek5000-users] fields on a regular grid Message-ID: Dear NEK developers, We are trying to get velocity and temperature fields on a regular grid as separate arrays (not being dumped in some file). map2reg in postprocess.f seems to be doing that. However we are confused with the dimensionality of the output array in that function. Please help us in this regard. With best wishes Supriyo Paul -- Dr. Supriyo Paul Senior Project Scientist Department of Physics Indian Institute of Technology Kanpur 208 016 INDIA -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat Mar 5 08:13:29 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 5 Mar 2011 08:13:29 -0600 (CST) Subject: [Nek5000-users] fields on a regular grid In-Reply-To: References: Message-ID: Dear Supriyo, Is your original domain box shaped? Are you running in parallel? If so, how do you want your regular array partitioned across processors? Or do you want the regular array output to a file ? Paul On Sat, 5 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Dear NEK developers, > > We are trying to get velocity and temperature fields on a regular grid as > separate arrays (not being dumped in some file). > map2reg in postprocess.f seems to be doing that. However we are confused > with the dimensionality of the output array in that function. > > Please help us in this regard. > > With best wishes > > Supriyo Paul > > -- > Dr. Supriyo Paul > Senior Project Scientist > Department of Physics > Indian Institute of Technology > Kanpur 208 016 > INDIA > From nek5000-users at lists.mcs.anl.gov Sun Mar 6 04:14:33 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 6 Mar 2011 04:14:33 -0600 (CST) Subject: [Nek5000-users] fields on a regular grid In-Reply-To: References: Message-ID: Dear Supriyo, I'm quite certain we don't have what you desire, particularly since your input .rea file is not itself lexicographically ordered. One suggestion that I think would be of value is to generate your .rea file as a single tensor-product (i.e., lexicographically ordered) entity, by explicitly inputting the x- y- and z- ordinates. The new box file would look something like: 10 10 10 nelx,nely,nelz 0 .05 .1 .2 .35 .5 .65 .8 .9 .95 1. 0 .05 .1 .2 .35 .5 .65 .8 .9 .95 1. 0 .05 .1 .2 .35 .5 .65 .8 .9 .95 1. Note, because of the way genbox was written, you can have only 80 characters on an input line, so if you have more elements than can fit on a single line, you must wrap them. As an example, the following yields the same result as above: 10 10 10 nelx,nely,nelz 0 .05 .1 .2 .35 .5 .65 .8 .9 .95 1. 0 .05 .1 .2 .35 .5 .65 .8 .9 .95 1. 0 .05 .1 .2 .35 .5 .65 .8 .9 .95 1. I use a script or short f77 program to generate my desired coordinate lists. (The "negative" nelx option was just a shortcut to automatically provide commonly used distributions.) With the data organized in this way it will be easier to transfer into other formats. For example, you'll have some hope of doing tensor-product operations. If you already have a lot of data in your old layout you can use the grid-to-grid interpolation feature to transfer the data to the tensor-product-ordered mesh. See g2gi on the wiki page for how to do this. You should check the veracity of the g2gi output -- I would recommend interpolating the coordinates (xm1,ym1,zm1) as a test. Coming back to your original question, even once the data is in a regular SEM array, we don't have any parallel mechanism to repartition the n x n x n grid data onto P processors because we never have a need for such. We do have off-line serial routines that can transfer data from an nelx x nely x nelz array of Nth-order elements to an nxnxn array - this allows for analysis by FFTs etc. Also, if your elements on each processor compose a "perfect" block decomposition of the space, then you could locally reorganize the data into the sub-block of the global nxnxn array. That is, if you had, say, 16 processors and an 8x8x8 array of elements, with contiguous 2x2x2 blocs on each of the processors, then the remapping would be local. As I type this, I realize now that we have a tool that could be used to re-order the data. I'm going to express it under the assumption that your data is a proper tensor-product of nelx x nely x nelz elements --- if it is not, you simply need to figure out where in such an array element eg out of nelgv elements total is located. Assuming the (nelx,nely,nelz) layout such that nelgv=nelx*nely*nelz, then include 'SIZE' include 'TOTAL' include 'ZPER' integer e,eg,ex,ey,ez do e=1,nelv eg = lglel(e) call get_exyz(ex,ey,ez,eg,nelx,nely,nelz) : : : enddo would tell you the (ex,ey,ez) index for element e in your (nelx,nely,nelz) array. From this, you can discern your local 1D point sets {i,j,k} in [1:n,1:n,1:n] required for each element. Given this, you get a set of values {xi,yj,zk} in [0,1]^3 and you can use a tensor-product of 1D interpolators to map from element e to the desired u_ijk values. Use fd_weights_full in nek to generate the polynomial interpolants from the SEM mesh to your 1D coordinates. It will output an interpolation matrix. Then you need to apply this interpolator in a tensor-product fashion to each element e, e=1,nelv, on each processor. ("grep weights *.f" in the trunk/nek directory to see example usage). You then need to organize your nxnxn data according to your desired processor layout. If this requires data movement, I think you can use crystal_ituple_transfer and sort (grep crystal *.f). The key here is to exploit the underlying tensor-product layout of both the input and output data. This allows you to use a tensor-product of 1D interpolators, rather than general-purpose off-grid interpolation, which is more expensive and generally less accurate. A (very) good idea is to choose your "n" distribution so that none of the desired output values is on a spectral element boundary. Otherwise, there is ambiguity about which element or processor is responsible for keeping this value. Even if you decide to use a rule controlled by, say, less-than-or-equal, you can get into trouble because of floating-point round-off so that the data does not end up where you think it should. If this seems complicated, well, it is -- primarily because you desire to move between two data spaces. Again, I reiterate that we have these tools in serial (which is where we would typically post-process under such circumstances). Paul > > > Dear Paul, > Thanks for your prompt reply. We greatly appreciate it. > > Yes, our domain is box shape (3d). Our mesh is equal in all three > directions. Please > find attached the .box file for your reference. > > We are running NEK in parallel. We want the array to be equipartitioned > among all > the processors. Array size = cube_root(number_elements)*order_polynomial. > > We do not want the regular array to be output to a file. > > with regards, > > Supriyo > > > > On Sat, 5 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > Dear NEK developers, > > > > We are trying to get velocity and temperature fields on a regular grid as > > separate arrays (not being dumped in some file). > > map2reg in postprocess.f seems to be doing that. However we are confused > > with the dimensionality of the output array in that function. > > > > Please help us in this regard. > > > > With best wishes > > > > Supriyo Paul From nek5000-users at lists.mcs.anl.gov Tue Mar 8 15:58:04 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 8 Mar 2011 15:58:04 -0600 Subject: [Nek5000-users] Method to detect NaNs Message-ID: Hi Neks, I just wanted to pass on a method that may or may not be useful to you all. I'm sure manyf NEK simulations are run on machines where the hours aren't "free." Thus, it's nice to try and minimize any wasted hours as much as possible. So, if a simulation blows up, you want to end the simulation as quickly as possible so as to not waste any more precious computational time. While there are probably better solutions, I end up putting the following snippet into my userchk() if (u_max.ne.u_max) then if (nid.eq.0) print *,'Sim is blowing up!!' call exitt() endif where u_max is something I calculated before hand. An interesting property of NaNs I found after doing some googling is that NaNs are not equal to anything..even themselves. So, if you take some quantity, and compare it to itself, the only time it isn't equal to itself is if it is Not a Number. You can use this property to tell your simulation to quit. I've tested this out on a case that I knew would blow up on me and it worked perfectly. Hope you all find this helpful for "hazardous" jobs when you can't spare the time to monitor its progress at all times. -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Tue Mar 8 16:02:57 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 8 Mar 2011 16:02:57 -0600 (CST) Subject: [Nek5000-users] Method to detect NaNs In-Reply-To: References: Message-ID: Thanks for the tip Josh! It's a clever one that I had not thought of. I typically am running on a machine where I've set the compiler to halt execution on occurance of 1st NaN, but that doesn't address the issue you raise. Your solution is great. Paul On Tue, 8 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > I just wanted to pass on a method that may or may not be useful to you all. > > I'm sure manyf NEK simulations are run on machines where the hours > aren't "free." Thus, it's nice to try and minimize any wasted hours > as much as possible. So, if a simulation blows up, you want to end > the simulation as quickly as possible so as to not waste any more > precious computational time. > > While there are probably better solutions, I end up putting the > following snippet into my userchk() > > if (u_max.ne.u_max) then > if (nid.eq.0) print *,'Sim is blowing up!!' > call exitt() > endif > > where u_max is something I calculated before hand. An interesting > property of NaNs I found after doing some googling is that NaNs are > not equal to anything..even themselves. So, if you take some > quantity, and compare it to itself, the only time it isn't equal to > itself is if it is Not a Number. You can use this property to tell > your simulation to quit. I've tested this out on a case that I knew > would blow up on me and it worked perfectly. > > Hope you all find this helpful for "hazardous" jobs when you can't > spare the time to monitor its progress at all times. > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Mar 9 10:33:03 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 09 Mar 2011 11:33:03 -0500 Subject: [Nek5000-users] Prandtl number in the heat transport equation In-Reply-To: References: Message-ID: <1299688383.7783.132.camel@menorca.uottawa.ca> Hi, How can I set the Pr number in the fully-developed channel flow with scalar transport (constant but different scalar values at the walls)?. This parameter is part of the coefficient of the diffusive term in the heat transport equation (1/Re/Pr). Should I use parameters 7 (RHOCP) and 8 (CONDUCT) in the rea file?. Thanks. -- Alexandre Fabregat, PhD. Mail: afabrega at uottawa.ca Phone: 630 562-5800 (ext. 6293) Office: B207 Mechanical Engineering Department University of Ottawa 161 Louis Pasteur, K1N6N5, Ottawa ON From nek5000-users at lists.mcs.anl.gov Wed Mar 9 10:36:37 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 9 Mar 2011 10:36:37 -0600 (CST) Subject: [Nek5000-users] Prandtl number in the heat transport equation In-Reply-To: <1299688383.7783.132.camel@menorca.uottawa.ca> References: <1299688383.7783.132.camel@menorca.uottawa.ca> Message-ID: Hi Alexandre, You can take a look at nek5_svn/ examples/benard/ray_cr.usr to see how buoyancy term can be setup. There we set Pr=1 but you can define it as a combination of parameters from .rea file. Let me khow if you have further questions, Aleks On Wed, 9 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > How can I set the Pr number in the fully-developed channel flow with > scalar transport (constant but different scalar values at the walls)?. > This parameter is part of the coefficient of the diffusive term in the > heat transport equation (1/Re/Pr). > > Should I use parameters 7 (RHOCP) and 8 (CONDUCT) in the rea file?. > > Thanks. > > -- > Alexandre Fabregat, PhD. > > Mail: afabrega at uottawa.ca > Phone: 630 562-5800 (ext. 6293) > Office: B207 > > Mechanical Engineering Department > University of Ottawa > 161 Louis Pasteur, K1N6N5, Ottawa ON > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Mar 9 10:42:09 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 9 Mar 2011 10:42:09 -0600 (CST) Subject: [Nek5000-users] Prandtl number in the heat transport equation In-Reply-To: <1299688383.7783.132.camel@menorca.uottawa.ca> References: <1299688383.7783.132.camel@menorca.uottawa.ca> Message-ID: Hi Alex, I typically set p1 and p8 to unity, then set p2 = -Re and p8= -Pe, where Pe is the Peclet number and Pr is then Pe/Re. Paul On Wed, 9 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > How can I set the Pr number in the fully-developed channel flow with > scalar transport (constant but different scalar values at the walls)?. > This parameter is part of the coefficient of the diffusive term in the > heat transport equation (1/Re/Pr). > > Should I use parameters 7 (RHOCP) and 8 (CONDUCT) in the rea file?. > > Thanks. > > -- > Alexandre Fabregat, PhD. > > Mail: afabrega at uottawa.ca > Phone: 630 562-5800 (ext. 6293) > Office: B207 > > Mechanical Engineering Department > University of Ottawa > 161 Louis Pasteur, K1N6N5, Ottawa ON > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Mar 9 11:16:31 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 09 Mar 2011 12:16:31 -0500 Subject: [Nek5000-users] Prandtl number in the heat transport equation In-Reply-To: References: <1299688383.7783.132.camel@menorca.uottawa.ca> Message-ID: <1299690991.7783.136.camel@menorca.uottawa.ca> Hi Paul, p8=1 or p8=-Pe? Maybe you meant p7=-Pe?. Thanks On Wed, 2011-03-09 at 10:42 -0600, nek5000-users at lists.mcs.anl.gov wrote: > Hi Alex, > > I typically set p1 and p8 to unity, then set p2 = -Re and p8= -Pe, > where Pe is the Peclet number and Pr is then Pe/Re. > > Paul > > > On Wed, 9 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi, > > > > How can I set the Pr number in the fully-developed channel flow with > > scalar transport (constant but different scalar values at the walls)?. > > This parameter is part of the coefficient of the diffusive term in the > > heat transport equation (1/Re/Pr). > > > > Should I use parameters 7 (RHOCP) and 8 (CONDUCT) in the rea file?. > > > > Thanks. > > > > -- > > Alexandre Fabregat, PhD. > > > > Mail: afabrega at uottawa.ca > > Phone: 630 562-5800 (ext. 6293) > > Office: B207 > > > > Mechanical Engineering Department > > University of Ottawa > > 161 Louis Pasteur, K1N6N5, Ottawa ON > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Alexandre Fabregat, PhD. Mail: afabrega at uottawa.ca Phone: 630 562-5800 (ext. 6293) Office: B207 Mechanical Engineering Department University of Ottawa 161 Louis Pasteur, K1N6N5, Ottawa ON From nek5000-users at lists.mcs.anl.gov Wed Mar 9 11:33:06 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 9 Mar 2011 11:33:06 -0600 (CST) Subject: [Nek5000-users] Prandtl number in the heat transport equation In-Reply-To: <1299690991.7783.136.camel@menorca.uottawa.ca> References: <1299688383.7783.132.camel@menorca.uottawa.ca> <1299690991.7783.136.camel@menorca.uottawa.ca> Message-ID: Hi Alex, This would be common usage? -- Paul 1.00000 P001: DENSITY -10000. P002: VISCOS <-- Re=10,000 0.000000E+00 P003: BETAG 0.000000E+00 P004: GTHETA 0.000000E+00 P005: PGRADX 0.000000E+00 P006: 1.00000 P007: RHOCP -1000 P008: CONDUCT <-- Pe = 1,000 On Wed, 9 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > p8=1 or p8=-Pe? > > Maybe you meant p7=-Pe?. > > Thanks > > > On Wed, 2011-03-09 at 10:42 -0600, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Alex, >> >> I typically set p1 and p8 to unity, then set p2 = -Re and p8= -Pe, >> where Pe is the Peclet number and Pr is then Pe/Re. >> >> Paul >> >> >> On Wed, 9 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> How can I set the Pr number in the fully-developed channel flow with >>> scalar transport (constant but different scalar values at the walls)?. >>> This parameter is part of the coefficient of the diffusive term in the >>> heat transport equation (1/Re/Pr). >>> >>> Should I use parameters 7 (RHOCP) and 8 (CONDUCT) in the rea file?. >>> >>> Thanks. >>> >>> -- >>> Alexandre Fabregat, PhD. >>> >>> Mail: afabrega at uottawa.ca >>> Phone: 630 562-5800 (ext. 6293) >>> Office: B207 >>> >>> Mechanical Engineering Department >>> University of Ottawa >>> 161 Louis Pasteur, K1N6N5, Ottawa ON >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > Alexandre Fabregat, PhD. > > Mail: afabrega at uottawa.ca > Phone: 630 562-5800 (ext. 6293) > Office: B207 > > Mechanical Engineering Department > University of Ottawa > 161 Louis Pasteur, K1N6N5, Ottawa ON > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Mar 10 04:22:03 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 10 Mar 2011 11:22:03 +0100 Subject: [Nek5000-users] Rotating Frame work In-Reply-To: <535225313.10208711271856653391.JavaMail.root@neo-mail-3> References: <535225313.10208711271856653391.JavaMail.root@neo-mail-3> Message-ID: <4D78A64B.4030409@mech.kth.se> Hello! We are considering running some wind-turbine simulations using nek5000 and we are wondering if there is a rotating framework mode in the code? In principle one needs to add some extra forcing terms from the rotation. I wonder if one can do that implicitly. Also, we would like to use some type of pipe flow mesh with azimuthal symmetry. Is that possible? Best regards, Antonios From nek5000-users at lists.mcs.anl.gov Thu Mar 10 06:53:25 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 10 Mar 2011 06:53:25 -0600 (CST) Subject: [Nek5000-users] Rotating Frame work In-Reply-To: <4D78A64B.4030409@mech.kth.se> References: <535225313.10208711271856653391.JavaMail.root@neo-mail-3> <4D78A64B.4030409@mech.kth.se> Message-ID: Hi Antonios, I typically do this by explicitly adding a Coriolis term in userf, and, if I have solid-body rotation, applying a "v " boundary condition with the appropriate rotation to any stationary surfaces. Note that if you have variable density, you should also add a centrifugal force term - this can be important in some cases, though it is often neglected. The Coriolis treatment is explicit and can in some cases lead to a tighter timestep stability constraint than the std. CFL constraint, but I've not found that to be an issue in my (perhaps limited) experience. Paul On Thu, 10 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello! > We are considering running some wind-turbine simulations using nek5000 > and we are wondering if there is a rotating framework mode in the code? > In principle one needs to add some extra forcing terms from the > rotation. I wonder if one can do that implicitly. > Also, we would like to use some type of pipe flow mesh with azimuthal > symmetry. Is that possible? > Best regards, > Antonios > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Mar 10 08:55:02 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 10 Mar 2011 20:25:02 +0530 Subject: [Nek5000-users] fields on a regular grid In-Reply-To: References: Message-ID: Dear Paul, Thanks for your reply. And apologies too for replying so late. I was traveling which made replying to the mails quite difficult. Coming back to the problem, I agree that doing the job in the post processing mode would have been much easier. However, we can try your second suggestion. It looks quite complicated right now. Let us get back to you once we do that. with thanks and regards, Supriyo On 06/03/2011, nek5000-users at lists.mcs.anl.gov wrote: > > > Dear Supriyo, > > I'm quite certain we don't have what you desire, particularly > since your input .rea file is not itself lexicographically ordered. > > One suggestion that I think would be of value is to generate your > .rea file as a single tensor-product (i.e., lexicographically ordered) > entity, by explicitly inputting the x- y- and z- ordinates. The new > box file would look something like: > > 10 10 10 nelx,nely,nelz > 0 .05 .1 .2 .35 .5 .65 .8 .9 .95 1. > 0 .05 .1 .2 .35 .5 .65 .8 .9 .95 1. > 0 .05 .1 .2 .35 .5 .65 .8 .9 .95 1. > > > Note, because of the way genbox was written, you can have only 80 > characters on an input line, so if you have more elements than > can fit on a single line, you must wrap them. As an example, > the following yields the same result as above: > > > 10 10 10 nelx,nely,nelz > 0 .05 .1 .2 .35 > .5 .65 .8 .9 .95 1. > 0 .05 .1 .2 .35 > .5 .65 .8 .9 .95 1. > 0 .05 .1 .2 .35 > .5 .65 .8 .9 .95 1. > > > I use a script or short f77 program to generate my desired > coordinate lists. (The "negative" nelx option was just > a shortcut to automatically provide commonly used distributions.) > > With the data organized in this way it will be easier to transfer > into other formats. For example, you'll have some hope of doing > tensor-product operations. If you already have a lot of data > in your old layout you can use the grid-to-grid interpolation > feature to transfer the data to the tensor-product-ordered mesh. > See g2gi on the wiki page for how to do this. You should check > the veracity of the g2gi output -- I would recommend interpolating > the coordinates (xm1,ym1,zm1) as a test. > > Coming back to your original question, even once the data is > in a regular SEM array, we don't have any parallel mechanism > to repartition the n x n x n grid data onto P processors because > we never have a need for such. We do have off-line serial routines > that can transfer data from an nelx x nely x nelz array of Nth-order > elements to an nxnxn array - this allows for analysis by FFTs etc. > > Also, if your elements on each processor compose a "perfect" block > decomposition of the space, then you could locally reorganize the > data into the sub-block of the global nxnxn array. That is, if > you had, say, 16 processors and an 8x8x8 array of elements, with > contiguous 2x2x2 blocs on each of the processors, then the > remapping would be local. > > As I type this, I realize now that we have a tool that could be > used to re-order the data. I'm going to express it under > the assumption that your data is a proper tensor-product of > nelx x nely x nelz elements --- if it is not, you simply need > to figure out where in such an array element eg out of nelgv > elements total is located. > > Assuming the (nelx,nely,nelz) layout such that nelgv=nelx*nely*nelz, > then > > include 'SIZE' > include 'TOTAL' > include 'ZPER' > integer e,eg,ex,ey,ez > > do e=1,nelv > eg = lglel(e) > call get_exyz(ex,ey,ez,eg,nelx,nely,nelz) > : > : > : > enddo > > would tell you the (ex,ey,ez) index for element e in your (nelx,nely,nelz) > array. From this, you can discern your local 1D point sets > > {i,j,k} in [1:n,1:n,1:n] > > required for each element. Given this, you get a set of values > > {xi,yj,zk} in [0,1]^3 > > and you can use a tensor-product of 1D interpolators to map from > element e to the desired u_ijk values. Use fd_weights_full in > nek to generate the polynomial interpolants from the SEM mesh to > your 1D coordinates. It will output an interpolation matrix. > Then you need to apply this interpolator in a tensor-product > fashion to each element e, e=1,nelv, on each processor. > ("grep weights *.f" in the trunk/nek directory to see example > usage). > > You then need to organize your nxnxn data according to your desired > processor layout. If this requires data movement, I think you can > use crystal_ituple_transfer and sort (grep crystal *.f). > > The key here is to exploit the underlying tensor-product layout > of both the input and output data. This allows you to use a > tensor-product of 1D interpolators, rather than general-purpose > off-grid interpolation, which is more expensive and generally > less accurate. A (very) good idea is to choose your "n" distribution > so that none of the desired output values is on a spectral element > boundary. Otherwise, there is ambiguity about which element or > processor is responsible for keeping this value. Even if you decide > to use a rule controlled by, say, less-than-or-equal, you can get > into trouble because of floating-point round-off so that the data > does not end up where you think it should. > > If this seems complicated, well, it is -- primarily because you > desire to move between two data spaces. Again, I reiterate that > we have these tools in serial (which is where we would typically > post-process under such circumstances). > > > Paul > > > > > > > >> >> >> Dear Paul, >> Thanks for your prompt reply. We greatly appreciate it. >> >> Yes, our domain is box shape (3d). Our mesh is equal in all three >> directions. Please >> find attached the .box file for your reference. >> >> We are running NEK in parallel. We want the array to be equipartitioned >> among all >> the processors. Array size = cube_root(number_elements)*order_polynomial. >> >> We do not want the regular array to be output to a file. >> >> with regards, >> >> Supriyo >> >> >> >> On Sat, 5 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >> > Dear NEK developers, >> > >> > We are trying to get velocity and temperature fields on a regular grid >> > as >> > separate arrays (not being dumped in some file). >> > map2reg in postprocess.f seems to be doing that. However we are confused >> > with the dimensionality of the output array in that function. >> > >> > Please help us in this regard. >> > >> > With best wishes >> > >> > Supriyo Paul > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Dr. Supriyo Paul Senior Project Scientist Department of Physics Indian Institute of Technology Kanpur 208 016 INDIA From nek5000-users at lists.mcs.anl.gov Thu Mar 10 10:40:04 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 10 Mar 2011 17:40:04 +0100 Subject: [Nek5000-users] Rotating Frame work In-Reply-To: References: <535225313.10208711271856653391.JavaMail.root@neo-mail-3> <4D78A64B.4030409@mech.kth.se> Message-ID: <4D78FEE4.30708@mech.kth.se> Hi Paul, We will add the two forcing terms in userf. I thought maybe one could do it implicitly but since, as you say, it worked like that it is probably the simplest choice. Thank you. Antonios nek5000-users at lists.mcs.anl.gov wrote: > > Hi Antonios, > > I typically do this by explicitly adding a Coriolis term > in userf, and, if I have solid-body rotation, applying a "v " > boundary condition with the appropriate rotation to any > stationary surfaces. > > Note that if you have variable density, you should also > add a centrifugal force term - this can be important in > some cases, though it is often neglected. > > The Coriolis treatment is explicit and can in some cases > lead to a tighter timestep stability constraint than the > std. CFL constraint, but I've not found that to be an > issue in my (perhaps limited) experience. > > Paul > > > On Thu, 10 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello! >> We are considering running some wind-turbine simulations using nek5000 >> and we are wondering if there is a rotating framework mode in the code? >> In principle one needs to add some extra forcing terms from the >> rotation. I wonder if one can do that implicitly. >> Also, we would like to use some type of pipe flow mesh with azimuthal >> symmetry. Is that possible? >> Best regards, >> Antonios >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Mar 10 22:03:41 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 10 Mar 2011 23:03:41 -0500 Subject: [Nek5000-users] Restart with geometry changes Message-ID: <4D799F1D.3010409@vt.edu> Howdy Neks, I ran a simulation on a certain geometry, saved solution files and would now like to restart the same run from a given time step. The difference is that I have implemented a geometry change via usrdat, but when I reload the previous solution (which contains xyz), it overwrites my changes and uses the geometry on which the solution was originally computed. To work around this, is it OK to just comment out line 367 in ic.f? c call geom_reset(1) ! recompute geometric factors Would this cause the old data to be mapped onto the new grid? Thanks, Markus From nek5000-users at lists.mcs.anl.gov Fri Mar 11 07:15:08 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 11 Mar 2011 07:15:08 -0600 (CST) Subject: [Nek5000-users] Restart with geometry changes In-Reply-To: <4D799F1D.3010409@vt.edu> Message-ID: <1710688081.179027.1299849308941.JavaMail.root@zimbra.anl.gov> Hi Markus, I wonder whether to restart your solution from blah.fld without geometry -- say only velocity, pressure and temperature -- you can just set in .rea file blah.fld U P T Could you try that first? Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Thursday, March 10, 2011 10:03:41 PM Subject: [Nek5000-users] Restart with geometry changes Howdy Neks, I ran a simulation on a certain geometry, saved solution files and would now like to restart the same run from a given time step. The difference is that I have implemented a geometry change via usrdat, but when I reload the previous solution (which contains xyz), it overwrites my changes and uses the geometry on which the solution was originally computed. To work around this, is it OK to just comment out line 367 in ic.f? c call geom_reset(1) ! recompute geometric factors Would this cause the old data to be mapped onto the new grid? Thanks, Markus _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Mar 11 08:41:37 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 11 Mar 2011 08:41:37 -0600 (CST) Subject: [Nek5000-users] Restart with geometry changes In-Reply-To: <4D799F1D.3010409@vt.edu> References: <4D799F1D.3010409@vt.edu> Message-ID: Markus, If you're using .fld files, you can simply modify your .rea file: : : 1 PRESOLVE/RESTART OPTIONS ***** my_old.fld01 U P T time=0 : : : which tells nek to take _only_ U P T and from the .fld file (assuming they are present), and to not take anything else. Also, it tells it to reset time to 0 at the start of this calculation. Note that if you have, say, 2 PRESOLVE/RESTART OPTIONS ***** my_old.fld01 U P T time=0 my_old.fld02 P T it would take U from fld01 and P, T, and time from fld02. I don't believe we have this level of support in the .f0000 format yet, but I can possibly put someone on it. In your case (assuming you're using .f0000 format), you can instead do the following in usrdat2 (by which point nek knows the geometry, but has not yet read initial conditions): c----------------------------------------------------------------------- subroutine usrdat2 include 'SIZE' include 'TOTAL' parameter (ltt=lx1*ly1*lz1*lelt) common /cmygeom/ xmo(llt),ymo(llt),zmo(llt) call opcopy(xmo,ymo,zmo,xm1,ym1,zm1) ! Preserve my geometry return end c----------------------------------------------------------------------- subroutine usrchk include 'SIZE' include 'TOTAL' parameter (ltt=lx1*ly1*lz1*lelt) common /cmygeom/ xmo(llt),ymo(llt),zmo(llt) call opcopy(xm1,ym1,zm1,xmo,ymo,zmo) ! Restore my geometry call geom_reset(1) ! Force regen. of Jacobians etc. return end c----------------------------------------------------------------------- Paul On Thu, 10 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Howdy Neks, > > I ran a simulation on a certain geometry, saved solution files and would now > like to restart the same run from a given time step. The difference is that I > have implemented a geometry change via usrdat, but when I reload the previous > solution (which contains xyz), it overwrites my changes and uses the geometry > on which the solution was originally computed. > > To work around this, is it OK to just comment out line 367 in ic.f? > c call geom_reset(1) ! recompute geometric factors > Would this cause the old data to be mapped onto the new grid? > > Thanks, > Markus > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Mar 11 11:10:11 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 11 Mar 2011 12:10:11 -0500 Subject: [Nek5000-users] Restart with geometry changes In-Reply-To: References: <4D799F1D.3010409@vt.edu> Message-ID: Hi Paul, This post is making me wonder if I understand how restarting works. If I have some geometry in my .rea file, and I restart from a .fld file with different geometry, which geometry takes precedence? I had been assuming that nek interpolated the old data onto the mesh in the .rea file. And is the answer affected by whether or not the .fld file contains geometry data? I think only my fld01 files contain that. Best, David On Fri, Mar 11, 2011 at 9:41 AM, wrote: > > Markus, > > If you're using .fld files, you can simply modify your .rea file: > > : > : > 1 PRESOLVE/RESTART OPTIONS ***** > my_old.fld01 U P T time=0 > : > : > : > > > which tells nek to take _only_ U P T and from the .fld > file (assuming they are present), and to not take anything > else. Also, it tells it to reset time to 0 at the start > of this calculation. Note that if you have, say, > > 2 PRESOLVE/RESTART OPTIONS ***** > my_old.fld01 U P T time=0 > my_old.fld02 P T > > > it would take U from fld01 and P, T, and time from fld02. > > > I don't believe we have this level of support in the .f0000 > format yet, but I can possibly put someone on it. > > In your case (assuming you're using .f0000 format), you can > instead do the following in usrdat2 (by which point nek > knows the geometry, but has not yet read initial conditions): > > > c----------------------------------------------------------------------- > subroutine usrdat2 > include 'SIZE' > include 'TOTAL' > parameter (ltt=lx1*ly1*lz1*lelt) > common /cmygeom/ xmo(llt),ymo(llt),zmo(llt) > > call opcopy(xmo,ymo,zmo,xm1,ym1,zm1) ! Preserve my geometry > > return > end > c----------------------------------------------------------------------- > subroutine usrchk > include 'SIZE' > include 'TOTAL' > parameter (ltt=lx1*ly1*lz1*lelt) > common /cmygeom/ xmo(llt),ymo(llt),zmo(llt) > > call opcopy(xm1,ym1,zm1,xmo,ymo,zmo) ! Restore my geometry > > call geom_reset(1) ! Force regen. of Jacobians etc. > > return > end > c----------------------------------------------------------------------- > > > Paul > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Mar 11 14:06:56 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 11 Mar 2011 14:06:56 -0600 (CST) Subject: [Nek5000-users] Restart with geometry changes In-Reply-To: References: <4D799F1D.3010409@vt.edu> Message-ID: Hi David, Nek does the following: Sets geometry Reads I.C.s If you .fld file contains geometry, this supersedes the geometry that has been set unless you say otherwise. Paul On Fri, 11 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > This post is making me wonder if I understand how restarting works. If I > have some geometry in my .rea file, and I restart from a .fld file with > different geometry, which geometry takes precedence? I had been assuming > that nek interpolated the old data onto the mesh in the .rea file. And is > the answer affected by whether or not the .fld file contains geometry data? > I think only my fld01 files contain that. > > Best, > > David > > On Fri, Mar 11, 2011 at 9:41 AM, wrote: > >> >> Markus, >> >> If you're using .fld files, you can simply modify your .rea file: >> >> : >> : >> 1 PRESOLVE/RESTART OPTIONS ***** >> my_old.fld01 U P T time=0 >> : >> : >> : >> >> >> which tells nek to take _only_ U P T and from the .fld >> file (assuming they are present), and to not take anything >> else. Also, it tells it to reset time to 0 at the start >> of this calculation. Note that if you have, say, >> >> 2 PRESOLVE/RESTART OPTIONS ***** >> my_old.fld01 U P T time=0 >> my_old.fld02 P T >> >> >> it would take U from fld01 and P, T, and time from fld02. >> >> >> I don't believe we have this level of support in the .f0000 >> format yet, but I can possibly put someone on it. >> >> In your case (assuming you're using .f0000 format), you can >> instead do the following in usrdat2 (by which point nek >> knows the geometry, but has not yet read initial conditions): >> >> >> c----------------------------------------------------------------------- >> subroutine usrdat2 >> include 'SIZE' >> include 'TOTAL' >> parameter (ltt=lx1*ly1*lz1*lelt) >> common /cmygeom/ xmo(llt),ymo(llt),zmo(llt) >> >> call opcopy(xmo,ymo,zmo,xm1,ym1,zm1) ! Preserve my geometry >> >> return >> end >> c----------------------------------------------------------------------- >> subroutine usrchk >> include 'SIZE' >> include 'TOTAL' >> parameter (ltt=lx1*ly1*lz1*lelt) >> common /cmygeom/ xmo(llt),ymo(llt),zmo(llt) >> >> call opcopy(xm1,ym1,zm1,xmo,ymo,zmo) ! Restore my geometry >> >> call geom_reset(1) ! Force regen. of Jacobians etc. >> >> return >> end >> c----------------------------------------------------------------------- >> >> >> Paul >> >> >> >> > From nek5000-users at lists.mcs.anl.gov Mon Mar 14 06:24:37 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 14 Mar 2011 07:24:37 -0400 Subject: [Nek5000-users] Restart with geometry changes In-Reply-To: References: <4D799F1D.3010409@vt.edu> Message-ID: <4D7DFAF5.3080301@vt.edu> Hi, combining fld files for restart is a pretty slick feature! Since I started out with f000*, I used your .usr -routine, which worked perfectly. Thanks, Markus nek5000-users at lists.mcs.anl.gov wrote: > > Markus, > > If you're using .fld files, you can simply modify your .rea file: > > : > : > 1 PRESOLVE/RESTART OPTIONS ***** > my_old.fld01 U P T time=0 > : > : > : > > > which tells nek to take _only_ U P T and from the .fld > file (assuming they are present), and to not take anything > else. Also, it tells it to reset time to 0 at the start > of this calculation. Note that if you have, say, > > 2 PRESOLVE/RESTART OPTIONS ***** > my_old.fld01 U P T time=0 > my_old.fld02 P T > > > it would take U from fld01 and P, T, and time from fld02. > > > I don't believe we have this level of support in the .f0000 > format yet, but I can possibly put someone on it. > > In your case (assuming you're using .f0000 format), you can > instead do the following in usrdat2 (by which point nek > knows the geometry, but has not yet read initial conditions): > > > c----------------------------------------------------------------------- > subroutine usrdat2 > include 'SIZE' > include 'TOTAL' > parameter (ltt=lx1*ly1*lz1*lelt) > common /cmygeom/ xmo(llt),ymo(llt),zmo(llt) > > call opcopy(xmo,ymo,zmo,xm1,ym1,zm1) ! Preserve my geometry > > return > end > c----------------------------------------------------------------------- > subroutine usrchk > include 'SIZE' > include 'TOTAL' > parameter (ltt=lx1*ly1*lz1*lelt) > common /cmygeom/ xmo(llt),ymo(llt),zmo(llt) > > call opcopy(xm1,ym1,zm1,xmo,ymo,zmo) ! Restore my geometry > > call geom_reset(1) ! Force regen. of Jacobians > etc. > > return > end > c----------------------------------------------------------------------- > > > Paul > > > On Thu, 10 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Howdy Neks, >> >> I ran a simulation on a certain geometry, saved solution files and >> would now like to restart the same run from a given time step. The >> difference is that I have implemented a geometry change via usrdat, >> but when I reload the previous solution (which contains xyz), it >> overwrites my changes and uses the geometry on which the solution was >> originally computed. >> >> To work around this, is it OK to just comment out line 367 in ic.f? >> c call geom_reset(1) ! recompute geometric factors >> Would this cause the old data to be mapped onto the new grid? >> >> Thanks, >> Markus >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Mar 14 06:48:58 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 14 Mar 2011 07:48:58 -0400 Subject: [Nek5000-users] Arbitrary mesh deformation Message-ID: <4D7E00AA.1060200@vt.edu> Howdy neks, I am interested in deforming meshes (i.e. a wall surface shifted in the wall normal direction) with an arbitrary coordinate list - that means I have the new coordinates for every grid point, but they don't adhere to any particular mathematical function. What I did in the past is that I only used the deformation for the element corners (and nek would linearly interpolate in between). Depending on the element resolution, this yielded a more or less accurate first order approximation of the surface I intended to generate. My question is: can I use this procedure on every GL grid point? I know that the routine we currently use for complex surfaces approximates with 2nd order functions. Can one do sines/cosines/third or higher order as well? Or can the GL point shifting in usrdat2 be completely arbitrary? Thanks, Markus From nek5000-users at lists.mcs.anl.gov Mon Mar 14 08:29:58 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 14 Mar 2011 08:29:58 -0500 (CDT) Subject: [Nek5000-users] Arbitrary mesh deformation In-Reply-To: <4D7E00AA.1060200@vt.edu> References: <4D7E00AA.1060200@vt.edu> Message-ID: Markus, I often shift all of the GLL points - see the old primer.pdf either on my website or on the wiki, where it gives an example of how to do this within usrdat2(), which is the right place for it. There are some issues to be aware of. The main point is that you want to avoid, to the extent possible, messing up the GLL point distribrution. Let's consider a 1-D deformation --- think of it as your wall-normal direction. Assume y_old \in [0,1] and consider the following loop: do i=1,n y = ym1(i,1,1,1) ym1(i,1,1,1) = y*y enddo What does this do? It concentrates points near y=0. There are reasons you might want to do something like this (or a perhaps more severe stretching), say if you wanted to capture a boundary layer or whatever. Unfortunately, this mapping would not be good for the GLL (Gauss Lobatto Legendre) point distribution that is essential for stability of the high-order interpolants and for the accuracy of the quadrature rules used in nek. The mapping is OK at the element level, but not at the point level. What to do? One option is to go back and re-map the points interior to each element so that they locally satisfy a GLL distribution. There is a routine "fix_geom" that does essentially this. It implements the Gordon Hall mapping that is described in chapter 4 of Deville F & Mund. I've used it many times (even this weekend), but to date it's probably been used only by me -- which means that it hasn't been tested under a wide range of usage conditions. Thus, you'll need to let me know if it breaks. Coming back to your surface deformation, there are other issues. Suppose you want to deform a surface but don't have a "volumetric" deformation function (like above). How can you blend the surface deformation into the interior? One approach that I've used - also not yet perfect, but apparently functional for my cases to date - is to solve a sequence of Laplace equations, one each for "x" "y" and "z" where I specify the deformation on the surface as a Diriclet condition (0 meaning no deformation on that part of the surface). Because of the maximum principle, a Laplace solve makes a reasonable blending function and will move the entire mesh to accommodate the surface deformation. I usually run "fix geom" afterwards. I can provide an example. The key to having blending is that it spreads the local deformation over multiple elements, which is particularly important if you have very thin boundary layer elements near the surface that could otherwise end up inverted if the amplitude of the surface deformation were greater than the element thickness in the wall-normal direction. Finally, a 3rd option that I just coded up this weekend is to "skin" the mesh after it is set up --- Here, you add a thin layer of elements to a mesh that has been constructed (presumably, without the usual layer of boundary-layer resolving elements), but you add the skinning elements after the deformation. You can control which surfaces you skin - e.g., walls, while avoiding inlets and outlets. A 4th option, there are some routines called "match normal" and they will try to add curvature that will remove element faceting. We use these for our vascular flow modeling where we don't have an analytical expression for the surface in any case. hth, Paul On Mon, 14 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Howdy neks, > > I am interested in deforming meshes (i.e. a wall surface shifted in the wall > normal direction) with an arbitrary coordinate list - that means I have the > new coordinates for every grid point, but they don't adhere to any particular > mathematical function. > What I did in the past is that I only used the deformation for the element > corners (and nek would linearly interpolate in between). Depending on the > element resolution, this yielded a more or less accurate first order > approximation of the surface I intended to generate. > My question is: can I use this procedure on every GL grid point? I know that > the routine we currently use for complex surfaces approximates with 2nd order > functions. Can one do sines/cosines/third or higher order as well? Or can the > GL point shifting in usrdat2 be completely arbitrary? > > Thanks, > Markus > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Mar 14 20:57:05 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 14 Mar 2011 20:57:05 -0500 (CDT) Subject: [Nek5000-users] hpts issue: not dumping anything Message-ID: <1595940778.300721300154225413.JavaMail.root@neo-mail-3> Hi, I am having an issue with hpts.? The issue is on a machine with the operating system AIX 5.3.? The compilers are mpxlf for?Fortran, and mpcc for ?the C compiler. The history point routine works on all other machines I have used, except for this one. The simulation runs fine,?saying that it is dumping history points to hpts.out in the output log.? However, nothing is ever actually written to hpts.out, not even the header. I am not sure what the issue is. I suspect something with the compilers or operating system as this is the only difference between this case, and all other cases.?? Any thoughts? - Michael M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Mar 15 01:54:08 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 15 Mar 2011 01:54:08 -0500 (CDT) Subject: [Nek5000-users] hpts issue: not dumping anything In-Reply-To: <1595940778.300721300154225413.JavaMail.root@neo-mail-3> References: <1595940778.300721300154225413.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, I've had some experiences on IBM machines in the past where the file never appeared unless it was explicitly closed. Surprisingly, this was the case even if I properly exitted. I've not looked at the hpts source, but this may be the issue. Can you try closing the file prior to exitting? Obviously this is a pain in a situation where you want to let your run keep going until terminated by the end of your allocated block, but I wouldn't know anyway around it. There may be a compiler option to force it to not buffer the I/O so parsimoniously. Paul On Mon, 14 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi, > > > > I am having an issue with hpts.?? The issue is on a machine with the operating system AIX 5.3.?? The compilers > > are mpxlf for??Fortran, and mpcc for ??the C compiler. The history point routine works on all other machines I > > have used, except for this one. > > > > The simulation runs fine,??saying that it is dumping history points to hpts.out in the output log.?? However, nothing is ever actually written > > to hpts.out, not even the header. > > > > I am not sure what the issue is. I suspect something with the compilers or operating system as this is the only difference > > between this case, and all other cases.???? Any thoughts? > > > > - Michael M. From nek5000-users at lists.mcs.anl.gov Tue Mar 15 04:10:53 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 15 Mar 2011 10:10:53 +0100 Subject: [Nek5000-users] Bug in genmap? Message-ID: Hi I just recently got started familiarizing myself with Nek5000. Looks great, but I got into trouble with generating my own meshes. Is there a preferred way to report bugs? I couldn't find one. Anyway, using any simple boxmesh from the tutorials genmap throws an error when I try to build it myself. Typically: abort: PERIODIC MISMATCH 2: 1 2 P ie 0 0 je 0.0000000 0.0000000 bc 8 quit I found that in subroutine genmap.f/ rd_bc bc is declared as real*8 and not just real. So I changed subroutine rd_bc(cbc,bc,nel,ndim,ifield,io) c .Read Boundary Conditions (and connectivity data) character*3 cbc(6,nel) real*8 bc(5,6,nel) to subroutine rd_bc(cbc,bc,nel,ndim,ifield,io) c .Read Boundary Conditions (and connectivity data) character*3 cbc(6,nel) real bc(5,6,nel) and now it works for me. Best regards Mikael Mortensen Norwegian Defence Research Establishment (FFI) 2027, Kjeller Norway -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Mar 15 07:00:19 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 15 Mar 2011 07:00:19 -0500 (CDT) Subject: [Nek5000-users] Bug in genmap? In-Reply-To: References: Message-ID: Michael, Yes - I think you are correct. This is a good forum for reporting bugs. I encountered this problem awhile back but apparently did not properly update the repo. Hopefully I'll get this set today. Thanks for the feedback! Paul On Tue, 15 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi > > I just recently got started familiarizing myself with Nek5000. Looks great, > but I got into trouble with > generating my own meshes. Is there a preferred way to report bugs? I > couldn't find one. > Anyway, using any simple boxmesh from the tutorials genmap throws an error > when I try > to build it myself. Typically: > > abort: PERIODIC MISMATCH 2: > 1 2 P ie > 0 0 je > 0.0000000 0.0000000 bc > > > 8 quit > > I found that in subroutine genmap.f/ rd_bc bc is declared as real*8 and not > just real. So I changed > > subroutine rd_bc(cbc,bc,nel,ndim,ifield,io) > > c .Read Boundary Conditions (and connectivity data) > > character*3 cbc(6,nel) > real*8 bc(5,6,nel) > > to > > subroutine rd_bc(cbc,bc,nel,ndim,ifield,io) > > c .Read Boundary Conditions (and connectivity data) > > character*3 cbc(6,nel) > real bc(5,6,nel) > > and now it works for me. > > Best regards > > Mikael Mortensen > Norwegian Defence Research Establishment (FFI) > 2027, Kjeller Norway > From nek5000-users at lists.mcs.anl.gov Sat Mar 19 04:31:52 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 19 Mar 2011 04:31:52 -0500 (CDT) Subject: [Nek5000-users] Error while postprocessing Message-ID: Hi Mani, One thing I see is that the .usr file has only 9999 filenames declared, so you likely have a memory overwrite once you exceed this number of files. Can you check if this resolves your problem? Best regards, Paul > Dear Nek devs, > > I get the following error while trying to load .f000* field files > into Nek for post processing. I noticed that this happens only when > file.list has a large number of entries, in my case about 25000. > > call userchk > set initial conditions > Checking restart options: high_ray0.f00001 > Reading checkpoint data > 0 0 OPEN: high_ray0.f00001 > byte_read() :: can't fread after fwriting! > > > I have attached the log, file.list, .usr and SIZE files. > > Thanks, > Mani chandra From nek5000-users at lists.mcs.anl.gov Sat Mar 19 04:45:18 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 19 Mar 2011 15:15:18 +0530 Subject: [Nek5000-users] Error while postprocessing In-Reply-To: References: Message-ID: <4D847B2E.3080505@iitk.ac.in> Hi Paul, Thanks, that did it! Sorry for the bother. Regards, Mani chandra On 03/19/2011 03:01 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Mani, > > One thing I see is that the .usr file has only 9999 > filenames declared, so you likely have a memory overwrite > once you exceed this number of files. > > Can you check if this resolves your problem? > > Best regards, > > Paul > > > > >> Dear Nek devs, >> >> I get the following error while trying to load .f000* field >> files into Nek for post processing. I noticed that this happens only >> when file.list has a large number of entries, in my case about 25000. >> >> call userchk >> set initial conditions >> Checking restart options: high_ray0.f00001 >> Reading checkpoint data >> 0 0 OPEN: high_ray0.f00001 >> byte_read() :: can't fread after fwriting! >> >> >> I have attached the log, file.list, .usr and SIZE files. >> >> 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 Sat Mar 19 04:41:00 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 19 Mar 2011 04:41:00 -0500 (CDT) Subject: [Nek5000-users] Error while postprocessing In-Reply-To: <4D847B2E.3080505@iitk.ac.in> References: <4D847B2E.3080505@iitk.ac.in> Message-ID: No problem - happy to help! On Sat, 19 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Thanks, that did it! Sorry for the bother. > > Regards, > Mani chandra > > On 03/19/2011 03:01 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> >> Hi Mani, >> >> One thing I see is that the .usr file has only 9999 >> filenames declared, so you likely have a memory overwrite >> once you exceed this number of files. >> >> Can you check if this resolves your problem? >> >> Best regards, >> >> Paul >> >> >> >> >>> Dear Nek devs, >>> >>> I get the following error while trying to load .f000* field files >>> into Nek for post processing. I noticed that this happens only when >>> file.list has a large number of entries, in my case about 25000. >>> >>> call userchk >>> set initial conditions >>> Checking restart options: high_ray0.f00001 >>> Reading checkpoint data >>> 0 0 OPEN: high_ray0.f00001 >>> byte_read() :: can't fread after fwriting! >>> >>> >>> I have attached the log, file.list, .usr and SIZE files. >>> >>> 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 Mon Mar 21 18:36:18 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 Mar 2011 16:36:18 -0700 Subject: [Nek5000-users] Genmap Error with Periodic BC's Message-ID: Hello, This is similar to some previous posts, but I am not completely understanding the solution. I am receiving the error message below after running genmap with the default precision. Also below is my .box file. Thanks, John Box 1 this is the main channel -56 6 nelx,nely,nelz for Box) 0 14 1.0 x0 x1 ratio -1 -.9 -.5 .0 .5 .9 1 y0...yn P ,P ,W ,W , bc's) P ,P ,t ,t , bc's) reading .rea file data ... start locglob_lexico: 4 336 1344 0.20000000 locglob: 1 1 1344 locglob: 2 57 1344 locglob: 1 399 1344 locglob: 2 399 1344 done locglob_lexico: 399 399 1344 4 start periodic vtx: 336 399 abort: PERIODIC MISMATCH 2: 1 1 P ie 0 0 je 0.0000000 0.0000000 bc 8 quit From nek5000-users at lists.mcs.anl.gov Mon Mar 21 19:28:04 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 Mar 2011 19:28:04 -0500 (CDT) Subject: [Nek5000-users] Genmap Error with Periodic BC's In-Reply-To: References: Message-ID: Hi John, I just ran genbox & genmap on you .box file without problems. Check if your tools are updated. The current revision is #672. Harish On Mon, 21 Mar 2011 nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > This is similar to some previous posts, but I am not completely > understanding the solution. I am receiving the error message below > after running genmap with the default precision. Also below is my > .box file. > > Thanks, > > John > > > Box 1 this is the main channel > -56 6 nelx,nely,nelz for Box) > 0 14 1.0 x0 x1 ratio > -1 -.9 -.5 .0 .5 .9 1 y0...yn > P ,P ,W ,W , bc's) > P ,P ,t ,t , bc's) > > > reading .rea file data ... > start locglob_lexico: 4 336 1344 0.20000000 > locglob: 1 1 1344 > locglob: 2 57 1344 > locglob: 1 399 1344 > locglob: 2 399 1344 > done locglob_lexico: 399 399 1344 4 > start periodic vtx: 336 399 > > abort: PERIODIC MISMATCH 2: > 1 1 P ie > 0 0 je > 0.0000000 0.0000000 bc > > > 8 quit > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Mar 24 09:18:57 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Mar 2011 09:18:57 -0500 Subject: [Nek5000-users] Location based viscosity Message-ID: Hello Neks, This seems like it should be simple, but can somehow show me how I can vary viscosity based on a given x, y, z? I'm guessing I should be able to do this in uservp, looking at the var_visc example, but I don't immediately see a variable that I can edit in NEKUSE (like I could for ux, uy, etc....) Thanks, -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Thu Mar 24 09:34:22 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Mar 2011 09:34:22 -0500 (CDT) Subject: [Nek5000-users] Location based viscosity In-Reply-To: References: Message-ID: Hi Josh, How about setting "udiff" in uservp? Note that if you have more than one field (e.g., temperature and velocity) then you discriminate by ifield: if (ifield.eq.1) then ! viscosity udiff = my viscosity utrans = my rho elseif (ifield.eq.2) then ! conductivity udiff = my conductivity utrans = my rho C_p endif Note that technically, you should use the full stress tensor when doing this, since the d/dxj mu du_j/dx_i term no longer vanishes. Are you using PnPn, or PnPn-2 ? Paul On Thu, 24 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello Neks, > > This seems like it should be simple, but can somehow show me how I can > vary viscosity based on a given x, y, z? > > I'm guessing I should be able to do this in uservp, looking at the > var_visc example, but I don't immediately see a variable that I can > edit in NEKUSE (like I could for ux, uy, etc....) > > Thanks, > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Mar 24 10:06:53 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Mar 2011 10:06:53 -0500 (CDT) Subject: [Nek5000-users] Location based viscosity In-Reply-To: References: Message-ID: Hi Josh, make sure you accivating a call to uservp by either setting ifuservp = .true. say in usrdat2 passed through 'TOTAL' or by p30>0 in .rea Best, Aleks On Thu, 24 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Josh, > > How about setting "udiff" in uservp? > > Note that if you have more than one field (e.g., temperature and velocity) > then you discriminate by ifield: > > if (ifield.eq.1) then ! viscosity > > udiff = my viscosity > utrans = my rho > > elseif (ifield.eq.2) then ! conductivity > > udiff = my conductivity > utrans = my rho C_p > > endif > > > Note that technically, you should use the full stress tensor > when doing this, since the d/dxj mu du_j/dx_i > term no longer vanishes. > > Are you using PnPn, or PnPn-2 ? > > > Paul > > > On Thu, 24 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello Neks, >> >> This seems like it should be simple, but can somehow show me how I can >> vary viscosity based on a given x, y, z? >> >> I'm guessing I should be able to do this in uservp, looking at the >> var_visc example, but I don't immediately see a variable that I can >> edit in NEKUSE (like I could for ux, uy, etc....) >> >> Thanks, >> >> -- >> Josh Camp >> >> "All that is necessary for the triumph of evil is that good men do >> nothing" -- Edmund Burke >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Mar 24 10:22:08 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Mar 2011 10:22:08 -0500 Subject: [Nek5000-users] Location based viscosity In-Reply-To: References: Message-ID: Thanks Paul and Aleks, that helps a lot! I'm using Pn-Pn right now, but I think I'll switch to Pn-Pn-2 shortly. I understand the difference between the two formulations, but is there a reason where one might use one formulation over the other? (stability, speed, etc...) (Sorry if this question is off-subject) Josh On Thu, Mar 24, 2011 at 10:06 AM, wrote: > Hi Josh, > > make sure you accivating a call to uservp by either setting > > ? ? ?ifuservp = .true. > > say in usrdat2 passed through 'TOTAL' or by p30>0 in .rea > > Best, > Aleks > > > > On Thu, 24 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> >> Hi Josh, >> >> How about setting "udiff" in uservp? >> >> Note that if you have more than one field (e.g., temperature and velocity) >> then you discriminate by ifield: >> >> ? ? if (ifield.eq.1) ?then ?! viscosity >> >> ? ? ? ?udiff ? = my viscosity >> ? ? ? ?utrans ?= my rho >> >> ? ? elseif (ifield.eq.2) ?then ?! conductivity >> >> ? ? ? ?udiff ? = my conductivity >> ? ? ? ?utrans ?= my rho C_p >> >> ? ? endif >> >> >> Note that technically, you should use the full stress tensor >> when doing this, since the d/dxj mu du_j/dx_i >> term no longer vanishes. >> >> Are you using PnPn, or PnPn-2 ? >> >> >> Paul >> >> >> On Thu, 24 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello Neks, >>> >>> This seems like it should be simple, but can somehow show me how I can >>> vary viscosity based on a given x, y, z? >>> >>> I'm guessing I should be able to do this in uservp, looking at the >>> var_visc example, but I don't immediately see a variable that I can >>> edit in NEKUSE (like I could for ux, uy, etc....) >>> >>> Thanks, >>> >>> -- >>> Josh Camp >>> >>> "All that is necessary for the triumph of evil is that good men do >>> nothing" -- Edmund Burke >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/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 > -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Thu Mar 24 10:27:17 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 24 Mar 2011 10:27:17 -0500 (CDT) Subject: [Nek5000-users] Location based viscosity In-Reply-To: References: Message-ID: Hi Josh, PnPn generally works better for highly turbulent marginally resolved cases (the add'l pressure modes are useful). That solver is not quite up to the performance of the PnPn-2 yet - the pressure solver needs to be updated as soon as I get a chance - so the iteration counts are higher. The PnPn-2 stress formulation has been more extensively tested. For PnPn, you need to treat the variable stress explicitly, which means setting ifexplvis to true, as well as ifuservp. (See turbChannel example.) For moving meshes, you must use PnPn-2. For low Mach, PnPn. Paul On Thu, 24 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > Thanks Paul and Aleks, that helps a lot! > > I'm using Pn-Pn right now, but I think I'll switch to Pn-Pn-2 shortly. > I understand the difference between the two formulations, but is > there a reason where one might use one formulation over the other? > (stability, speed, etc...) (Sorry if this question is off-subject) > > Josh > > > On Thu, Mar 24, 2011 at 10:06 AM, wrote: >> Hi Josh, >> >> make sure you accivating a call to uservp by either setting >> >> ? ? ?ifuservp = .true. >> >> say in usrdat2 passed through 'TOTAL' or by p30>0 in .rea >> >> Best, >> Aleks >> >> >> >> On Thu, 24 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> >>> Hi Josh, >>> >>> How about setting "udiff" in uservp? >>> >>> Note that if you have more than one field (e.g., temperature and velocity) >>> then you discriminate by ifield: >>> >>> ? ? if (ifield.eq.1) ?then ?! viscosity >>> >>> ? ? ? ?udiff ? = my viscosity >>> ? ? ? ?utrans ?= my rho >>> >>> ? ? elseif (ifield.eq.2) ?then ?! conductivity >>> >>> ? ? ? ?udiff ? = my conductivity >>> ? ? ? ?utrans ?= my rho C_p >>> >>> ? ? endif >>> >>> >>> Note that technically, you should use the full stress tensor >>> when doing this, since the d/dxj mu du_j/dx_i >>> term no longer vanishes. >>> >>> Are you using PnPn, or PnPn-2 ? >>> >>> >>> Paul >>> >>> >>> On Thu, 24 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hello Neks, >>>> >>>> This seems like it should be simple, but can somehow show me how I can >>>> vary viscosity based on a given x, y, z? >>>> >>>> I'm guessing I should be able to do this in uservp, looking at the >>>> var_visc example, but I don't immediately see a variable that I can >>>> edit in NEKUSE (like I could for ux, uy, etc....) >>>> >>>> Thanks, >>>> >>>> -- >>>> Josh Camp >>>> >>>> "All that is necessary for the triumph of evil is that good men do >>>> nothing" -- Edmund Burke >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/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 >> > > > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > 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 Mar 27 16:01:59 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 27 Mar 2011 16:01:59 -0500 (CDT) Subject: [Nek5000-users] hpts issue: not dumping anything In-Reply-To: Message-ID: <1360622658.2519291301259719544.JavaMail.root@neo-mail-3> Hi Paul, Do you mean add to the hpts routine within postpro.f an explicit close( ) command after writing to hpts.out?? I see what you mean that nothing actually shows up unless the run is closed, in which case all of my data now appears. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "Nekton User List" Sent: Tuesday, March 15, 2011 1:54:08 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] hpts issue: not dumping anything Hi Michael, I've had some experiences on IBM machines in the past where the file never appeared unless it was explicitly closed. Surprisingly, this was the case even if I properly exitted. I've not looked at the hpts source, but this may be the issue. Can you try closing the file prior to exitting? Obviously this is a pain in a situation where you want to let your run keep going until terminated by the end of your allocated block, but I wouldn't know anyway around it. There may be a compiler option to force it to not buffer the I/O so parsimoniously. Paul On Mon, 14 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi, > > > > I am having an issue with hpts.? The issue is on a machine with the operating system AIX 5.3.? The compilers > > are mpxlf for?Fortran, and mpcc for ?the C compiler. The history point routine works on all other machines I > > have used, except for this one. > > > > The simulation runs fine,?saying that it is dumping history points to hpts.out in the output log.? However, nothing is ever actually written > > to hpts.out, not even the header. > > > > I am not sure what the issue is. I suspect something with the compilers or operating system as this is the only difference > > between this case, and all other cases.?? Any thoughts? > > > > - Michael M. _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Mar 27 17:06:26 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 27 Mar 2011 17:06:26 -0500 (CDT) Subject: [Nek5000-users] hpts issue: not dumping anything In-Reply-To: <1360622658.2519291301259719544.JavaMail.root@neo-mail-3> References: <1360622658.2519291301259719544.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, You would need to close it only after your run is done? Otherwise, it closes and (I guess) reopens after each call and then you for sure wouldn't get anything. It's hard for me to check w/o being on precisely the same platform. Unfortunately I'm on travel right now - otherwise we could perhaps sort it out through skype. Paul On Sun, 27 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > Do you mean add to the hpts routine within postpro.f an explicit close( ) command after writing to hpts.out??? I see what you mean > > that nothing actually shows up unless the run is closed, in which case all of my data now appears. > > > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, March 15, 2011 1:54:08 AM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] hpts issue: not dumping anything > > Hi Michael, I've had some experiences on IBM machines in the past where the file never appeared unless it was explicitly closed. Surprisingly, this was the case even if I properly exitted. I've not looked at the hpts source, but this may be the issue. Can you try closing the file prior to exitting? Obviously this is a pain in a situation where you want to let your run keep going until terminated by the end of your allocated block, but I wouldn't know anyway around it. There may be a compiler option to force it to not buffer the I/O so parsimoniously. Paul On Mon, 14 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi, > > > > I am having an issue with hpts.?? The issue is on a machine with the operating system AIX 5.3.?? The compilers > > are mpxlf for??Fortran, and mpcc for ??the C compiler. The history point routine works on all other machines I > > have used, except for this one. > > > > The simulation runs fine,??saying that it is dumping history points to hpts.ou t in the output log.?? However, nothing is ever actually written > > to hpts.out, not even the header. > > > > I am not sure what the issue is. I suspect something with the compilers or operating system as this is the only difference > > between this case, and all other cases.???? Any thoughts? > > > > - Michael M. > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Mar 28 07:21:19 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 28 Mar 2011 14:21:19 +0200 Subject: [Nek5000-users] hpts issue: not dumping anything In-Reply-To: References: <1360622658.2519291301259719544.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, Somehow your buffered I/O device does not get flushed when the nek5000 process ends! Typically the OS triggers a close of all open file handles which will flush the I/O buffer in case of a write access. I guess there is an easy way to fix this. Just flush the considered unit (file) explicitly every n timesteps in userchk(). Note: This is a quick and dirty workaround. Stefan On 3/28/11, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Michael, > > You would need to close it only after your > run is done? Otherwise, it closes and (I guess) > reopens after each call and then you for sure > wouldn't get anything. > > It's hard for me to check w/o being on precisely > the same platform. > > Unfortunately I'm on travel right now - otherwise > we could perhaps sort it out through skype. > > Paul > > On Sun, 27 Mar 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> >> >> Hi Paul, >> >> >> >> Do you mean add to the hpts routine within postpro.f an explicit close( ) >> command after writing to hpts.out?? I see what you mean >> >> that nothing actually shows up unless the run is closed, in which case all >> of my data now appears. >> >> >> >> - Michael >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: "Nekton User List" >> Sent: Tuesday, March 15, 2011 1:54:08 AM GMT -06:00 US/Canada Central >> Subject: Re: [Nek5000-users] hpts issue: not dumping anything >> >> Hi Michael, I've had some experiences on IBM machines in the past where >> the file never appeared unless it was explicitly closed. Surprisingly, >> this was the case even if I properly exitted. I've not looked at the hpts >> source, but this may be the issue. Can you try closing the file prior to >> exitting? Obviously this is a pain in a situation where you want to let >> your run keep going until terminated by the end of your allocated block, >> but I wouldn't know anyway around it. There may be a compiler option to >> force it to not buffer the I/O so parsimoniously. Paul On Mon, 14 Mar >> 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi, > > > > I am having >> an issue with hpts.? The issue is on a machine with the operating system >> AIX 5.3.? The compilers > > are mpxlf for?Fortran, and mpcc for ?the C >> compiler. The history point routine works on all other machines I > > have >> used, except for this one. > > > > The simulation runs fine,?saying that >> it is dumping history points to hpts.ou > t in the output log.? However, nothing is ever actually written > > to > hpts.out, not even the header. > > > > I am not sure what the issue is. I > suspect something with the compilers or operating system as this is the only > difference > > between this case, and all other cases.?? Any thoughts? > > > >> - Michael M. >> _______________________________________________ Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users