[Nek5000-users] element order range

Tue Sep 14 13:43:47 CDT 2010

Stefan,

Thanks for the offer.  If you'd like to look, I put the relevant files in a .tar.gz file at

http://michaelasprague.com/couette_scale.tar.gz

It's fairly simple.  The dimensions are (Lx,Ly,Lz) = (6,5,1) with periodic BCs in x and y.  At z = 0, (ux,uy,uz) = (0,0,0) and at z = 1, (ux,uy,uz)=(1,0,0).  

The domain is discretized as (Nx,Ny,Nz)=(24,16,16), and N = 13.

Please let me know if you have any suggestions for parameter improvements and/or need more information.

--Mike

On Sep 14, 2010, at 11:37 AM, <nek5000-users at lists.mcs.anl.gov> wrote:

> Mike:
> 
> If you're ready with the NEK case we're more than happy to have a look at it.
> Sometimes it can get a little bit tricky to find the right solver parameters to get the most out of it.
> 
> We're very interested into comparisons like this!
> 
> -Stefan
> 
> 
> ----- Original Message -----
> From: nek5000-users at lists.mcs.anl.gov
> To: nek5000-users at lists.mcs.anl.gov
> Sent: Tuesday, September 14, 2010 12:31:40 PM GMT -06:00 US/Canada Central
> Subject: Re: [Nek5000-users] element order range
> 
> Paul,
> 
> Thanks for that info and for the document.  Both are very helpful.
> 
> There's interest here in using OpenFOAM (second-order finite-volume), and I'm interested to see how Nek does in a head to head comparison.  We're using turbulent planar Couette flow as our comparison test case with Re = 8000 (See, e.g. Sullivan et al. (JFM 404, 2000).  We're looking at accuracy for a given number of grid points and scalability over 16-1024 cores.
> 
> I'll let you know how things turn out with the comparison.
> 
> --Mike
> 
> 
> On Sep 14, 2010, at 10:33 AM, <nek5000-users at lists.mcs.anl.gov> wrote:
> 
>> 
>> Hi Mike,
>> 
>> I've run with N=120 in the past and just this past
>> week was running w/ N=64.  (I had to bump up a couple
>> of parameters past the 40 or 50 mark to do so.)
>> 
>> Stefan has run the Pn-Pn variant with N=1 (lx1=2).
>> 
>> lx1=6-12 is the general sweet spot for the code because
>> of the way the operators are evaluated...
>> 
>> When comparing to a low-order code it's generally best
>> to compare for an equal number of gridpoints - i.e.,
>> roughly the same resolution.  The main reason for this is that
>> higher order does not buy you increased resolution. (The
>> Nyquist sampling theorem dictates at least 2*k points are
>> required to resolve a signal of wavenumber k.)   What the
>> high-order method gains is improved accuracy for the modes
>> that _are_ resolved.   My goal is to try to ensure that
>> the performance is comparable to a low-order code - i.e.,
>> that costs are not inordinate w/ N.
>> 
>> What type of comparison did you have in mind ?  You might
>> be interested in:  www.mcs.anl.gov/~fischer/users.pdf
>> which is a work-in-progress.
>> 
>> Paul
>> 
>> 
>> 
>> On Tue, 14 Sep 2010, nek5000-users at lists.mcs.anl.gov wrote:
>> 
>>> Hello All.
>>> 
>>> I am doing some tests of Nek5000 against a low-order code.  Under "Performance tips", it is recommended to "design your resolution (mesh) for N=7 or N=9"
>>> 
>>> Are there any limitations on the range of values for N?  For example, what is the smallest N and largest N that the code can/has been run with?    What are the limitations with running at, say, N = 16?
>>> 
>>> Thanks.
>>> --Mike
>>> 
>>> 
>>> _______________________________________________
>>> Nek5000-users mailing list
>>> Nek5000-users at lists.mcs.anl.gov
>>> https://lists.mcs.anl.gov/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