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.,
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 ndarraysx,y,z
in Cartesian coordinates,OneSphereVolumeConductor uses
ndarrayr
in spherical coordinates,FourSphereVolumeConductor
usesr_electrodes
in Cartesian,InfiniteHomogeneousVolCondMEG
usessensor_locations
etc.InfiniteVolumeConductor
the user must specify relative measurement locationr
as input to theget_transformation_matrix
,NYheadmodel
something 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.