fix: handle logarithm/exponentiation of luminosity #23
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I stumbled upon an issue with the "luminosity" value not being treated correctly, and tried to solve it:
The history_colums.list does not include the non-logarithmic luminosity as "L", but as "luminosity". Because of this, the usual treatment of logarithmic and non-logarithmic values does not work, necessitating an explicit case for catching this. While the value "L" is available in the profile_columns.list, it coexists with "luminosity" there, leading to potential problems should anyone use this column title.
This patch fixes this by explicitly checking for the existence of "luminosity" in the log files in the case of a key error that could not be resolved by the other cases specified, or "log_L" should "luminosity" be asked for but not found.
I am looking forward to feedback on this, best,
Lucas