[Nek5000-users] element order range

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

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
>