MMS in z-direction

[JensMadsen]

I am trying to MMS the DDZ operator. I get reasonable low errors but I experience that the errors is an order of magnitude bigger on the boundary than in the interior of the domain. The function I use is n_ = cos(phi+ delta)_sin(8_phi+0.31)

Below are plot for delta = 1.123 and delta = 0, repectively

What is interesting is that the delta 16 takes 16 RHS evaluation whereas the other case takes 179 RHS evaluations.

Is this a bug or am I making some sort of stupid error??

I should mention that zmin = 0, Zmax = 1, zperiod = 1

[d7919]

Is this with master or next and which DDZ operator are you testing?

[JensMadsen]

it is in the master branch.

I test:

ddt(n) = DDZ(n)

here is a convergence plot

[JensMadsen]

I added a Z part to the examples/MMS/diffusion2. You get the same behavior.

I get convergence but the nuber of right hand side evaluations again changes if I shift the function in the z-direction, which is unexpected. Could it be an error when we pass the RHS to e.g. Pvode? The old ghost z point?

[dschwoerer]

I can reproduce this only with FFT.

All other diff methods don't have this artefact.

Also the convergence is expected, if the high frequencies are resolved, accuracy jumps, and after that a finer grid does not further improvement.

As for the fact that the errors at the edge of the domain - I assume that phi may not be precise enough.

I am voting to close this issue ...

[bendudson]

Agreed. This convergence behaviour is expected for FFTs. Ideally this would be documented somewhere in the MMS testing section of the manual.

[JensMadsen]

@bendudson This issue was not addressing the jump in the convergence plot which as you state is expected for FFTs but rather that the error it very high near boundaries and that the # rhs evaluations change dramatically if gradients exist in the vicinity of the boundary :-) Still vote for closing the issue :-)

[bendudson]

Thanks Jens! Good to hear from you, I hope you are well. Do you think this indicates a bug? Just to clarify: the x axes on the plots above are the Z direction i.e. periodic? Could this indicate that somehow the function is not quite periodic in Z?

Could the problem be that TWOPI is not sufficiently high accuracy? https://github.com/boutproject/BOUT-dev/blob/master/src/field/field_factory.cxx#L214 It's defined to 13 digits here: https://github.com/boutproject/BOUT-dev/blob/master/include/bout/constants.hxx#L13 but perhaps the calculation of z is truncating it?

[d7919]

With a very rough test (input = cos(z + delta), expected = -sin(z+delta), error = max(abs(ddz(input)-expected),true)) it seems the maximum error actually increases linearly with the number of grid points (for delta =1.123 at least). With delta = 0. the error does not change with grid point count. WIth delta = 0.001 there is a minimal change in error with mz.

Switching to input = sin and expected = cos, there is indeed a strong variation with mz even for delta = 0.0

[d7919]

If I change method to C4 I can partially reproduce the issue. For delta=0.0 (with the original test case) I find that scanning in mz the error bottoms out at ~1e-13 reached at ~ mz = 4096. For delta = 1.123 the error bottoms out at ~1e-11 at ~mz = 1024.

[d7919]

A plot of the max difference as a function of nz for two methods and two values of delta.

[d7919]

Possibly related (although possibly not) -- I've made a plot representing the non-uniformity of the grid at the boundary. I create a field that is just z, I then take the ratio of (z[0]+TWOPI - z[-1])/(z[1]-z[0]) and save the magnitude of this ratio minus 1 and this is shown in the plot below. The non-uniformity is quite small but does increase with nz. This might be expected to have less impact where the derivatives are small (as field values mostly cancel anyway) and more impact where the derivative is large (fields values combine). There's structure in this plot that isn't apparent in the plots of error.

[d7919]

The below shows an additional curve. The only difference here is in include/bout/constants.hxx where I have redefined TWOPI = 2 * PI;

Note the nonuniformity is not strongly modified with this change (see below) so could still be related to the overall linear trend that we see.

[d7919]

It may be helpful to note that FFTW provide plots of rms error of a single transform and these are described at http://www.fftw.org/accuracy/method.html (see for example data http://www.fftw.org/accuracy/Pentium4-3.60GHz-icc/).

This data on fftw and the close behaviour of the fft and c4 methods at large scale suggests the error trend seen here is a separate issue.

[JensMadsen]

My question was whether the behaviour was different near the boundary(see 'error' in original post). yes x is z in the plot :-) sorry :-)

... @bendudson everything in my new life is going great. I have just been working 15 days from capetown of course windsurfing a few hours every day ;-)

[bendudson]

If the period was not quite 2pi, then the last cell (wrapping around) would be a slightly different size to the other cells. This would produce a bigger error at the edges. This might not be the reason though... working hypothesis.

[JensMadsen]

yes could be :-) a cosine shifted should do the same if it is an issue with the bnd