refactor template/archetype model eval #293
Merged
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.
@abhi0395 this is an update to your best_fit_model branch (PR #283) to address some of my maintainability concerns. I've made enough changes that I'm doing this as a PR to your branch rather than updating your branch directly. Although this version is quite a bit different from your original branch, I learned a lot from your work about the various corner cases with MPI vs. multiprocessing, wavehashes out of order compared to camera bands, etc. so thanks for that initial solution which guided me for what to watch out for.
In the end the output files are the same except
Big Caveat: the evaluated Archetype+legendre models are not correct, which I think is due to issue #291 with the inconsistent definitions of legendre basis wavelengths and whether they span the entire brz wavelength range or only the individual cameras. Let's get that sorted out separately, and then revisit this model evaluation to make sure it uses the same pieces. We don't need this for Jura, but we will need it for Archetype runs post-Jura.
More details
The goal here is to have
Template.eval()
andArchetypes.eval()
"own" the concept of how to evaluate a model given coefficients and haverrdesi -> DistTargets.eval_models -> Target.eval_model
use those. This simplifies the bookkeeping to avoid things likeArchtype.get_best_archetype_model
having to know about templates just in case it is asked to evaluate something that isn't an archtype.get_best_model_spectra
,eval_model_for_one_spectra
, andeval_tdata
having significant conceptual overlap with previously existingeval
functions, but not actually using those. Instead of pulled pieces of those into the the other eval functions.I also updated some of the underlying messiness that made your original branch hard to implement:
set
operation changing the order).Please take a look at this, and then let's discuss any items that you disagree with and/or have a better idea for how to implement. Thanks.