[Nek5000-users] element order range

[nek5000-users at lists.mcs.anl.gov]

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