Skip to Content.
Sympa Menu

opal - Re: [Opal] usage of 1DDynamic field map

opal AT

Subject: The OPAL Discussion Forum

List archive

Re: [Opal] usage of 1DDynamic field map

Chronological Thread  
  • From: Philippe Piot <philippe.piot AT>
  • To: Dragos Constantin <dragos.constantin AT>
  • Cc: opal <opal AT>
  • Subject: Re: [Opal] usage of 1DDynamic field map
  • Date: Thu, 20 Jan 2022 17:42:30 -0600
  • Authentication-results:; iprev=pass ( smtp.remote-ip=; spf=pass; dkim=pass header.s=20210112 header.a=rsa-sha256; dmarc=pass

This is solved! (and sorry for spamming)

  Very good point indeed. I was correlating final coordinates with the initial ones emitted from a cathode and was implicitly assuming the particle ordering is conserved but that is not the case in parallel (of course!). So I should have kept track of the particle Id. Once I took care of this bookkeeping matter, the results are as expected. Thank you

Sorry all; this was a self-inflicted problem!!  -- Philippe. 

On Thu, Jan 20, 2022 at 5:19 PM Dragos Constantin <dragos.constantin AT> wrote:
Hi Philippe,
This reminds me of the FFT function in Matlab. One has to use a function
called 'fftshift' to obtain a correct matrix representation of the outcome.
From the definition of 'fftshift':

"Y = fftshift(X) rearranges a Fourier transform X by shifting the zero-
frequency component to the center of the array."

The plot of the FFT without applying the fftshift looks like your plots.

I am also getting similar results when I reshape a vector to a matrix using a
wrong sequence for the indices. If the reshape order is not done right the
surface plot will look like your plots.

It might be that your post-processing python script is doing something funny
with the indices. Try to swap x and y when you build your matrices and see if
that helps. I am not sure if a simple x-y swap would fix the np dependence
(np=number of mpi processes).

Please report back if you find the issue.


Archive powered by MHonArc 2.6.19.

Top of Page