Giters

skuschel / postpic

The open-source particle-in-cell post-processor.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Broken `kspace` since merging #209

Ablinne opened this issue · comments

commented

Hi folks,

this is rather embarassing, because i really thought everything was fine with #209 when I merged it and I was quite sure i had tested the kspace-reconstruction functions properly.

However, I did not test them thoroughly enough. Actually the plot from the k-space reconstruction paper which should look like this:
Screenshot_20190816_145338
since the merge of PR #209 actually looks like:
Screenshot_20190816_151114

This means that the accuracy of the kspace-reconstruction in postpic has been bad on the master branch for the last 3 months. This should not be a huge deal for most cases, but everyone who has been using this function and the master branch after #209 should double check their results using a fix which I will push very soon.

I am hugely sorry for the inconvenience.

commented

Thanks a lot for spotting and fixing it!

Since this is the exact plot from your paper ( https://www.sciencedirect.com/science/article/pii/S2590055219300356 ) , do you want to add its creation to one of the integrated tests (in 'examples/')?

commented

Seems like a good idea, but currently it uses data from sdf files and sdf reader is not universally available. Could be executed conditionally if sdf is available.

commented

That is right, the examples should not rely on sdf. I can think of three ways of getting around this dependency:

  • Saving the E and B field using numpy and feeding them to the k-space routines manually. This would nicely show how different parameters are applied to the routines. Probably the clearest way to understand your routines.
  • Adding the fields to the dummy reader and using the k-space routines from there.
  • Convert sdf to hdf5, but keep the internal structure. The change to the epoch reader (to support hdf and sdf as underlying file format) should not be too excessive.

I am in favor of one of the first two options. What do you think?

commented

It will be hard to do this with this exact dataset, because this is from a 3D simulation and only the EM fields of that single dump are about 2 Gigabytes of data. Should be possible to make a similar but more lightweight example from a 2d simulation, but this will never use all the code paths.

commented

Sure it will never use all, but at least it would detect if something changes as you have shown in your graphic. Currently there is not way to test if the code does the right thing.

commented

Eample script added in #235