Investigate negative fluxes

[juanep97]

In this PR:

• allow the pipeline to continue after encountering a negative flux by using np.log10 (gives nan) instead of math.log10 (throws error). However this is slower and does not address the origin of this unexpected negative value.
• for that reasons, leave comments in the source code linking issue Investigate negative flux errors #24 .
• change hard-coded value by the expression that it comes from, to make it understandable.

Let's keep issue #24 open until we study better where it comes from exactly.

[morcuended]

Even if the pipeline keeps going with calculations, the results in this case are wrong, right? Do you want to allow that? Or simply let the pipeline exit loudly raising an error? In the second way, I would expect these problems to go less unnoticed than if you let the pipeline run "normally".
If this is related to data with whatever problem, there's probably nothing to do with it.

[juanep97]

These errors or invalid values are probably caused by bad data (we have to make sure, though). If the pipeline continues, and the data become NaNs, they will be automatically flagged. We can still see that there were errors by looking at the error messages. However if the pipeline just stops on the first error, every time there is a single bad point, we will loose whatever data was going to reduce after (worst case, the whole night).

Maybe we could implement an option stop_on_errors that jumps to the interpreted if activated, or just re-raises exceptions instead of continuing with a simple message. But in general it should be resilent to errors so no good data is lost.

[juanep97]

Let's write here whatever instances of this kind of errors we find and debug, so we can make an informed decision about how to treat them. I will add them in the Issue description as they come.

[morcuended]

These errors or invalid values are probably caused by bad data (we have to make sure, though). If the pipeline continues, and the data become NaNs, they will be automatically flagged. We can still see that there were errors by looking at the error messages. However if the pipeline just stops on the first error, every time there is a single bad point, we will loose whatever data was going to reduce after (worst case, the whole night).
Maybe we could implement an option stop_on_errors that jumps to the interpreted if activated, or just re-raises exceptions instead of continuing with a simple message. But in general it should be resilent to errors so no good data is lost.

Fair enough. Go ahead with the merge

[morcuended]

Let's write here whatever instances of this kind of errors we find and debug, so we can make an informed decision about how to treat them. I will add them in the Issue description as they come.

Better in the issue #24 than in this PR that will be closed when merging.