Addresses #17 where Henrique was having problems because data contains np.nan for magnitudes and magnitude errors, and any magnitude errors that are <=0.0 (GPz by default takes the log of the errors). This adds a simple mask check to the data processing to get rid of those values. It also adds a new parameter where you can set the value to replace the negative magnitude errors with in each band. I tested this on some data where I replaces inputs so that they had some NaNs and negative mag errors and all were caught and replaced.
[ ] I have written unit tests or justified all instances of #pragma: no cover; in the case of a bugfix, a new test that breaks as a result of the bug has been added
[ ] My code contains relevant comments and necessary documentation for future maintainers; the change is reflected in applicable demos/tutorials (with output cleared!) and added/updated docstrings use the NumPy docstring format
[ ] Any breaking changes, described above, are accompanied by backwards compatibility and deprecation warnings
Addresses #17 where Henrique was having problems because data contains np.nan for magnitudes and magnitude errors, and any magnitude errors that are <=0.0 (GPz by default takes the log of the errors). This adds a simple mask check to the data processing to get rid of those values. It also adds a new parameter where you can set the value to replace the negative magnitude errors with in each band. I tested this on some data where I replaces inputs so that they had some NaNs and negative mag errors and all were caught and replaced.
Code Quality
#pragma: no cover; in the case of a bugfix, a new test that breaks as a result of the bug has been added