pyCalculations/derivatives, VlsvWriter updates

[alhom]

-VlsvWriter update for VisIt vlsv plugin compatibility
-VlsvReader utilities for reading, crude down- and upsampling, read_fg_var_as_volumetric
-pyCalculations/derivatives.py: Poynting flux and div thereof, curvature and ballooning criteria (w/ Jonas)

[markusbattarbee]

Interesting helper routines and quite a few of them. If there's now an effort of fleshing out this analysator fsgrid functionality, would you mind adding these as well?

def get_fsgrid_cellsize (and using it in these functions)
read_fsgrid_variable_cellid(self,name, cellids=-1,operator="pass")
where for each requested cellid, it finds the mean fsgrid value
get_cellid_at_fsgrid_index(i,j,k)

[markusbattarbee]

Good extension of functionality (though a lot of helper functions which makes the files more cumbersome to read through). My main issue with this is that now we have helper functions for numerical operations and physical variables and criteria both in derivatives.py and plot_helpers.py. So now we have lots of near-duplicates, leading to bloating and potential conflicts in how different functions expect input.

I think it would be preferable to use the existing framework of expressions (where you give a funciton a dictionary of variables and it does with them what it needs to), and perhaps, for clarity, split mathematical helper functions into a separate file under pyCalculations (but not necessarily derivatives, what an odd name). Or even two files, one for 2D, one for 3D.

[alhom]

Yes, it's a bit awkward to have these separate (and frankly, I wasn't really sure what would be the best approach to begin with - so this ballooning stuff got collated to derivatives.py), but there were a couple of reasons to have this bunch on its own for the time being:

• reliance on fsgrid variables (and re-centering them!), which have been somewhat fiddly to work with
• the expectation that the outputs are to be written back to a sidecar, instead of being only used as an expression in plotting (so, not relying on plot_helpers top-level variables, or 2D plane choices for output formatting, either)

I could see some (or even most) of these as reducers, even - at least in principle, the operators there could be extended with differential ops (though, calling those data_reducers_ is a bit much!). Thoughts?

[alhom]

This is still supplanted by an incoming PR to chop this up a bit.

[alhom]

implemented in master!