2D Fourier-Basis problems saving and interpreting coefficient data

[alex...@gmail.com]

Hi,

I have two questions related to the 2D Fourier-basis doing:

xbasis = de.Fourier('x',128, interval=[-pi/2.,pi/2.])
bases.append(xbasis)
ybasis = de.Fourier('y',128, interval=[-pi/2.,pi/2.])
bases.append(ybasis)
domain = de.Domain(bases, grid_dtype='float', mesh=None)

The first question I have is related to the mode counting: For

kx = print(domain.elements(0))
ky = print(domain.elements(1))

I get that kx has 64 elements, while ky has 127 elements I have trouble understanding this asymmetry. Also any field that I define on this domain has in coefficient space 64x127 coefficients. Is Dedalus always 'by' hand adapt the half of the wave-vector coeffiicients - but only in x-direction or what happens here?

A second question concerns saving data in coefficient space. I noticed that when I have a variable, say theta, in a problem

variables = ['theta']
problem = de.IVP(domain, variables=variables)

I can add to the task list:

snap.add_task("theta")
snap.add_task("theta", layout='c',name="theta_c")

and all goes well. But If I have some other field, that is just coming from the substitutions

problem.substitutions["omega"] = "0.5 * ( cos(theta)*dx(theta) + sin(theta)*dy(theta) )"

and I do

snap.add_task("omega")
snap.add_task("omega", layout='c',name="omega_c")

I get the error message:

Traceback (most recent call last):
  File "/Users/program.py", line 277, in <module>
    solver.step(dt)
  File "/anaconda3/envs/dedalus/lib/python3.6/site-packages/dedalus/core/solvers.py", line 483, in step
    self.timestepper.step(self, dt)
  File "/anaconda3/envs/dedalus/lib/python3.6/site-packages/dedalus/core/timesteppers.py", line 559, in step
    evaluator.evaluate_scheduled(**evaluator_kw)
  File "/anaconda3/envs/dedalus/lib/python3.6/site-packages/dedalus/core/evaluator.py", line 107, in evaluate_scheduled
    self.evaluate_handlers(scheduled_handlers, wall_time=wall_time, sim_time=sim_time, iteration=iteration, **kw)
  File "/anaconda3/envs/dedalus/lib/python3.6/site-packages/dedalus/core/evaluator.py", line 146, in evaluate_handlers
    self.require_coeff_space(outputs)
  File "/anaconda3/envs/dedalus/lib/python3.6/site-packages/dedalus/core/evaluator.py", line 163, in require_coeff_space
    self.domain.dist.paths[index-1].decrement(current_fields)
  File "/anaconda3/envs/dedalus/lib/python3.6/site-packages/dedalus/core/distributor.py", line 349, in decrement
    self.decrement_single(field)
  File "/anaconda3/envs/dedalus/lib/python3.6/site-packages/dedalus/core/distributor.py", line 329, in decrement_single
    self.basis.forward(gdata, cdata, self.axis, field.meta[self.axis])
  File "/anaconda3/envs/dedalus/lib/python3.6/site-packages/dedalus/core/basis.py", line 746, in _forward_fftw
    cdata, gdata = self.check_arrays(cdata, gdata, axis)
  File "/anaconda3/envs/dedalus/lib/python3.6/site-packages/dedalus/core/basis.py", line 149, in check_arrays
    raise ValueError("gdata does not match grid_dtype: gdata = {}; grid_dtype = {}".format(gdata.dtype, self.grid_dtype))
ValueError: gdata does not match grid_dtype: gdata = complex128; grid_dtype = float6

It works if I comment out any of the two tasks though.

Thanks for your help in advance,
Alex

[Ben Brown]

Alex,

      I’ve had a similar experience with errors for substitution based outputs in coefficient space (grid data error).  This appears to have cropped up between successive versions of Dedalus itself, but I have not yet been able to bisect the error to find out where it was introduced. Your script may be simple enough to do this with. Would you mind emailing your script to the list?

—Ben

--
You received this message because you are subscribed to the Google Groups "Dedalus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dedalus-user...@googlegroups.com.
To post to this group, send email to dedalu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dedalus-users/ddb97cd8-68e5-4a5c-8a7e-9d5adde43cbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[alex...@gmail.com]

Hi Ben,

the attached script has the issues I described above. Any insights on the asymmetric k-modes? :)

Best,
Alex

[Jeffrey S. Oishi]

Alex,

Daniel answered your question about the asymmetric modes on the other thread, but to flesh it out a little bit:

Dedalus transforms the x dimension first, going from [grid in y, grid in x] to [grid in y, coefficient in x]. Thus, the first transform is real to complex, since you have real data on the grid (the grid_dtype sets this). The second transform must be complex to complex, since the mixed grid/coefficient space is complex. Thus the second transform will have the same number of plus and minus modes and zero: an odd number.

I hope this clarifies the situation.

Jeff

--

You received this message because you are subscribed to the Google Groups "Dedalus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dedalus-user...@googlegroups.com.
To post to this group, send email to dedalu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dedalus-users/72e30147-95d6-4e52-bf16-0e4cfbc47ca7%40googlegroups.com.

[alex...@gmail.com]

Hi Jeff (and Daniel),

thanks a lot for explaining that. So to be sure I understand: It is in principle doing what is written under the section "Higher dimension" in the numpy link https://docs.scipy.org/doc/numpy/reference/routines.fft.html (where the number of modes in both directions is the same), but the first transformation in practice only needs half the modes because the input is real? So that means the coefficient vector after the transformation in the x-direction is "by hand" amended with the conjugate values to then do the second transformation complex-to-complex, which gives eventually what is written under "Higher dimension" in the link?

Thanks again and best,
Alex

[Keaton Burns]

Hi Alex,

Dedalus is just performing an RFFT along the first axis, and a regular FFT along the subsequent axes.  The first transform (RFFT in x) gives the coefficients as a function of kx>0 and y.  The second transform (FFT in y) then gives the coefficients as function of kx>0 and ky (positive and negative).  This is basically the same as the numpy.rfftn function, except we do the real transform along the first axis rather than the last.

Thanks for bringing the output issue to our attention — I’ll try to patch up the bug soon.  In the mean time, a simple hack to work around this is to create an expression that is mathematically equivalent for one of the tasks, i.e.

snap.add_task("omega")

snap.add_task("2*omega - omega", layout='c',name="omega_c”)

Best,

-Keaton

--
You received this message because you are subscribed to the Google Groups "Dedalus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dedalus-user...@googlegroups.com.
To post to this group, send email to dedalu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dedalus-users/0a8b0274-fea1-442d-87cf-14ce6452a101%40googlegroups.com.

[Keaton Burns]

Hi Alex,

Just to follow up, I’ve pushed a patch that should fix this issue to the main repo.  It’s available now if you pull using version control.  It should be incorporated into an update that will appear on pip in the next couple weeks.

Best,

-Keaton