michael-petersen / exptool Goto Github PK

Just cropped up today when using eof.py on Unity.

exptool/basis/eof.py:129: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
data = yaml.load(cbufs.tostring())

Needs to be gone over?

Some compatibility code to read yaml if absolutely needed when pyyaml isn't found exists, but needs to be homogenised.

(In general, yaml handling could be better.)

I'm not sure which part of the code is being used most heavily right now, but there are definitely elements to be scrapped. Is this directory structure even right? Please review!

In both exptool.basis.eof and exptool.basis.spheresl, extrapolating to radii outside of the tabulated values gives false potential values. Check against original algorithm.

Starting to flag documentation that needs upgrading. Start with io, which will be the most likely access point for people.

At a given time step, the bar angle retrieved from pattern.find_barangle() is not the same as that found by running pattern.bar_fourier_compute(). Sample work flow below. Ex - at time index 556 in the simulation I'm looking at, pattern.find_barangle() gives 69.28 and pattern.bar_fourier_compute() gives ~1.4 (exact value depends on the chosen values for minr and maxr).

For find_barangle():

EOF2Dict = eof.read_binary_eof_coefficients_dict('sim_directory/outcoef.star.run2Fb')
DCp = eof.calculate_eof_phase(EOF2Dict)
eof.print_eof_barfile(DCp,simulation_directory='sim_directory/',\
                        simulation_name='2Fb',morder=2,norder=0)
BarInstance = pattern.BarDetermine()
BarInstance.read_bar('sim_directory/2Fb_m2n0_barpos.dat')
''' BarInstance.unwrap_bar_position()  - have tried with and without unwrapping'''
pattern.find_barangle(BarInstance.time[556], BarInstance, interpolate=False) #interpolate = True gives NaN, which seems to be a separate issue, but here I am giving an exact time in the simulation so no interpolation should be needed

For bar_fourier_compute():

file = psp_io.Input('sim_directory/OUT.run2Fb.00556',comp='star')
bangle = bar_fourier_compute(file.data['x'],file.data['y']) #have set various rmin, rmax

spheresl call in integrate is hardwired. Not fixing currently because a larger rewrite is needed?

Some psp_io calls in basis/potential.py need to be updated to follow the new particle structure.

In exptool.basis.potential, get_fields cannot handle transform=False. Why?

There are a few places in the code that assume that the file format is PSP, and have no flexibility for SPL and/or legacy format. I think the easiest fix here is just replacing the call to io.psp_io.Input() with a call to io.particle.Input(). Below, I've listed the files that explicitly call PSP_io.

Explicit psp_io calls:

• basis/potential.py
• orbits/orbit.py
• utils/integrate.py

There also appears to be different formats for the outcoef files, the SPL outcoef files cannot be read with the functionalities within basis/eof.py. SPL outcoef files can be read with io.outcoef. read_binary_eof_coefficients_old, but there doesn't appear to be an equivalent function for eof.read_binary_eof_coefficients_dict.

This is not ideal behaviour. I think the correct fix is to improve kde_pos (which might also mean jettisoning it). Worth looking at.

New warning about deprecation to run down -- feels like this could be made more clever anyway.

trapping.py:562: VisibleDeprecationWarning: Creating an ndarray from ragged nested sequences (which is a list-or-tuple of lists-or-tuples-or ndarrays with different lengths or shapes) is deprecated. If you meant to do this, you must specify 'dtype=object' when creating the ndarray
the_clusters = np.array([np.arctan(np.abs(np.array(K.clusters[i])[:,1])/np.abs(np.array(K.clusters[i])[:,0])) for i in range(0,k)])

Lots of undefined symbols if one tries

from exptool.basis._accumulate_c import r_to_xi,xi_to_r,d_xi_to_r,z_to_y,y_to_z

Needs a full going-over!

eof.compute_coefficient code still uses PSPInput as the old file stream. For example, PSPInput.xpos, which should be replace by PSPInput.x now

eof.basis: map_basis doesn't seem to read orders in correctly; no error obvious.

observables.visualize: timestamp reader is broken.

observables.visualize depends on the 'colormaps' package, which is not being installed, and is a Python 2 vestigial piece. Inspect and remove?

Corrupted file handling is pretty lackluster--failure mode tends to be obvious, but could be reported more clearly.

trapping.py is currently hard-wired to only accept psp_io.Input. This should be made flexible so that various inputs are taken in. It might actually be true that a primary io class wrapper should be written?

legacy=False should be the default, so that all functionality is enabled. Need to inspect other pieces of the codebase to see what breaks if legacy defaults to False.

Will try to find a few, then change the behaviour and look for bugs.

Is it ok if I comment out the following lines?
SL_Out.dump = PSPInput.infile in /basis/spheresl.py
EOF_Out.dump = PSPInput.infile in /basis/eof.py
What purpose do they serve?

Reasoning below -
If you transform into the bar frame, you can run get_fields just fine without adjustments to the eof or spheresl files. However, if you do NOT transform into the barframe, you get an error that PSPInput does not have a .infile attribute. I could build in a toggle to recognize if the PSPInput file is a BarTransform object or just a regular PSP file if, for some reason, just commenting out those two lines is a no-go

When compiling C extensions on infinity.iap.fr, I ran into:

exptool/basis/accumulate_c/_accumulate.c:1:10: fatal error: Python.h: No such file or directory

Need some way to find Python.h, or to circumvent?