Is your feature request related to a problem? Please describe.
At present, the different classes rely on different parameters names declaring extracellular recording sites:
PointSourcePotential and similar uses ndarrays x,y,z in Cartesian coordinates,OneSphereVolumeConductor uses ndarray r in spherical coordinates,FourSphereVolumeConductor uses r_electrodes in Cartesian,InfiniteHomogeneousVolCondMEG uses sensor_locations etc.- For class
InfiniteVolumeConductor the user must specify relative measurement location r as input to the get_transformation_matrix,
NYheadmodel something else altogether
These internal inconsistencies needs to be resolved and conform to the same structure, e.g.,
class Whatever(LinearModel):
'''Some description
Parameters
------------
cell: CellGeometry object
r_probe: ndarray
shape (n_contacts, 3) array of extracellular measurement locations in absolute Cartesian coordinates (µm)
'''
def __init__(self, cell, r_probe, **kwargs):
super.__init__(cell=cell)
self.r_probe = r_probe
....
In a similar vein the source locations in case of dipoles should be declared with the same parameter, e.g., r_source.
A good timeline to incorporate would be for future LFPy-2.3 (https://github.com/LFPy/LFPy/projects/2) which may break backwards compatibility anyway.
Is your feature request related to a problem? Please describe.
At present, the different classes rely on different parameters names declaring extracellular recording sites:
PointSourcePotentialand similar uses ndarraysx,y,zin Cartesian coordinates,OneSphereVolumeConductor usesndarrayrin spherical coordinates,FourSphereVolumeConductorusesr_electrodesin Cartesian,InfiniteHomogeneousVolCondMEGusessensor_locationsetc.InfiniteVolumeConductorthe user must specify relative measurement locationras input to theget_transformation_matrix,NYheadmodelsomething else altogetherThese internal inconsistencies needs to be resolved and conform to the same structure, e.g.,
In a similar vein the source locations in case of dipoles should be declared with the same parameter, e.g.,
r_source.A good timeline to incorporate would be for future LFPy-2.3 (https://github.com/LFPy/LFPy/projects/2) which may break backwards compatibility anyway.