Zero thickness dft array output

[HomerReid]

Initial stab at addressing #321

[HomerReid]

For DFT fields defined on a volume of zero thickness in one or more directions, the dft_array routines now collapse the two-pixel-thick regions in those dimensions to one-pixel thick regions. Calling conventions, etc. are unchanged. I tested that it behaved properly in a few 2D and 3D situations involving DFT flux regions of zero thickness in various directions.

Similarly, when the output_dft routines for DFT fields on volumes of zero thickness are called, the raw DFT file output is now bypassed in favor of fetching the fields in array form (with two-pixel thick regions for zero-width dimensions properly condensed to single-pixel thickness) and then exporting the compressed array to HDF5. I verified that this works for a couple of cases. Unfortunately, after writing the HDF5 file it seems to be core dumping from my python script. I haven't been able to track this down.

[ChristopherHogan]

In case you were unaware, you can usually get a backtrace by running the script through gdb:

$ gdb python
(gdb) run path/to/script.py

Fee free to send me the script if you want help troubleshooting.

[HomerReid]

Thanks, yes, I've been trying this and also running in valgrind. The difficulty is that valgrind produces a massive torrent of errors, almost all of which seem to be referencing python code. At first I thought it might have something to do with python reference counting and the complications of passing C++-allocated objects back to python codes. However, my C++ code does some allocation and deletion, but only on the C++ side, and the allocated/deleted objects are not passed back to python, so it's not clear why I'm getting so many python-related errors.

I am wondering if it might have to do with using the raw, low-level h5file::write routine instead of the higher-level routines like the ones in h5fields. In this case the full array to be written to disk is available on a single core, so I don't need the HDF5 export to happen on all processors, and in fact I have that code enclosed in a if (am_master()){} block. But it seems this might be problematic, and I will next try using the higher-level interface.

[ChristopherHogan]

valgrind produces a massive torrent of errors

If you use Python 3.6, you can change the allocator with an environment variable. That plus the python suppressions file here makes the output much easier to parse. I do something like:

PYTHONMALLOC=malloc valgrind --track-origins=yes --suppressions=/path/to/valigrind-python.supp python script.py

More info here.

[HomerReid]

Fixes #321.

• Fixed the core-dump issue in the HDF5 output for DFT fields on degenerate volumes. Both output_dft and get_dft_array now return arrays that are 1 pixel thick in dimensions where the underlying volume had zero thickness.

• Updated python/tests/dft_fields.py unit test to check proper collapsing of zero-thickness dimensions in DFT field arrays and HDF5 file output.

The unit test is passing and I have done some of my own testing, but it would be good to have others take a look at this to check that it does the right thing in some real-world examples, such as perhaps the original example from Erik Shipton that motivated this improvement.

One subtlety is that the scheme implemented here assumes that DFT field components are weighted by interpolation weights, so that we need only sum (i.e. not average) the two entries in the two-pixel array straddling a zero-thickness dimension. However, for exporting DFT fields to HDF5 files and in-memory arrays, I actually don't include the interpolation weight; if the weight is built into the field components in the dft_chunk, I remove it before exporting the component to array or disk. Thus I assumed that I would have to reinstate the weight for the purposes of this routine---although this would change the normalization of field components compared to cases in which there are no degenerate dimensions. I did some testing with and without the interpolation weights retained, but I couldn't tell which was correct.

[HomerReid]

Updated to fix a subtlety that caused freezing on some multiprocessor runs for HDF5 output of DFT fields on volumes with zero-thickness dimensions. The issue was that, depending on chunking, processors may not all agree on the number of DFT frequencies, which was problematic for the handling of zero-thickness dimensions in DFT arrays. Fixed by adding an appropriate call to max_to_all().

[stevengj]

Note that there is a int max_to_all(int in) method

[HomerReid]

My mistake. This call started out as a call to max_to_master, for which there doesn't appear to be an int-valued version. For micro-revisions like this, in the interest of speeding the pace of development I really encourage you to go ahead and make the revisions yourself.