electronsandstuff / easygdf Goto Github PK

At the moment, blocks in the GDF file are returned as a list which mirrors how they are stored in the file. However, this does make it more difficult to index entries in the file as an end user. Assuming there are no duplicate keys in the blocks list, it could be nice to return the data as a dict instead of a list. Since I would just be calling the original code that handles list-type block data I can have it return an error in the case of duplicate keys and tell the end user to handle it on their own with the list version.

The following code using integer IDs saves an initial distribution file with an empty ID array.

easygdf.save_initial_distribution(distname, ... ID=np.arange(x.shape[0])+1)

It works correctly when called like the following which will pass an array of floats.

easygdf.save_initial_distribution(distname, ... ID=np.arange(x.shape[0])+1.0)

The expected behavior is that easygdf either saves the integers or converts to floats if GPT requires IDs in the distribution file to be floats.

The new version looks awesome. One use case that looks like it might be missing is setting the particle ID numbers. This is actually used by people in BBL, when they are looking at core charges vs. shield charges and what have you. Its also useful for directly computing the particle trajectories (GPT has a method for that, but with easygdf, its basically just as easy to form the trajectories oneself in python). Can this be added? Or is it already there? I didn't see it in:

save_initial_distribution(f, x=None, y=None, z=None, GBx=None, GBy=None, GBz=None, ...)

Saves GPT compatible initial distribution file. All array objects must be the same length (IE the number of particles). If required values (either {x, y, z, GBx, GBy, GBz} or {x, y, z, Bx, By, Bz}) are missing, easyGDF will autofill them with zeros. Only specify the momentum or the velocity of particles, not both.

Parameters

f: filename or open file/stream-like object
x (default: None): numpy array, particle position
y (default: None):numpy array, particle position
z (default: None):numpy array, particle position
GBx (default: None):numpy array, particle momentum
GBy (default: None):numpy array, particle momentum
GBz (default: None):numpy array, particle momentum
Bx (default: None):numpy array, particle velocity
By (default: None):numpy array, particle velocity
Bz (default: None):numpy array, particle velocity
t (default: None):numpy array, particle spawn time
G (default: None):numpy array, Lorentz factor
m (default: None):numpy array, particle mass
q (default: None):numpy array, particle charge
nmacro (default: None):numpy array, number of macroparticles
rmacro (default: None):numpy array, macroparticle size
creation_time (default: current time): int/datetime object creation time written to header (default: time when file is written)
creator (default: "easygdf"): string written to header
destination (default: ""): string written to header
gdf_version (default: (1, 1)): tuple (int, int) written to header. (Don't change unless you like messing with low-level stuff)
creator_version (default: (2, 0)): tuple (int, int) written to header
destination_version (default: (0, 0)): tuple (int, int) written to header
dummy (default: (0, 0)): tuple (int, int) written to header
max_recurse (default: 16): Maximum recursion depth while saving blocks in GDF file

A lot of the data stored in GDF files (for instance, the screens or initial particle distributions) is row-like. I think pandas would be useful here. I don't want to add it as a required dependency, however, so I am thinking of adding some functions to help with pandas import/export, but only have them show up if the user has installed pandas already.

Just to let you know in easygdf.py for example, this use of assert below is incorrect, if someone runs in -O or -OO mode (not entirely unreasonable) then these asserts will never be run, and the error will be handed in an unpredictable way. This is elsewhere in the code as well. There should be a class inheriting Exception like GDFIOError (say) and that should be raised instead, so the user can maybe catch this, whereas catching an AssertionError is not a good idea. assert should really just be used as an interactive comment/sanity check I would say. Just something I noticed. Thanks for writing this nice package anyway, saved me some time this week.

assert isinstance(f, io.BufferedReader)
f.read(1)  # Trigger any IO errors here
assert is_gdf(f)