Optimizer
Ok, optimizer is ready. I'm still documenting the code perhaps, but I'd somewhat rather do that from mainline so that others can review and suggest things.
This merge will not affect GWINC core, although maybe review main.py to make sure I didn't screw something up when I refactored the FOM argparsing into a function (reuse!)
To show what that this can do, I made some documentation and a tutorial in the docs folder. I have also added the doc compilation to the CI config. You can see it at
https://lee-mcculler.docs.ligo.org/pygwinc/optimizer/overview.html
Merge request reports
Activity
mentioned in issue #14
added 1 commit
- 24791444 - cleaning up and making the ability to do single-optimization runs
added 1 commit
- b9fcae0b - added an "initial" config and made __dir__ better for hdfstruct
This optimizer tooling looks pretty cool, but I'm not convinced it needs to be included directly into the pygwinc package. It looks like it would function just as well as a separate package that just wraps gwinc. I think the gwinc core package should really just focus on the noise calculations, and not be burdened with maintaining other code which is not part of that core mission. The API should obviously be amenable to optimization, but I'm not sure the package needs to include a particular optimization implementation inside of it. I imagine that users will want to experiment with many different optimization algorithms and techniques, and I don't think that gwinc itself should be in the business of maintaining those particular implementations.
I'm open to arguments why this needs to be included here, but I would just as soon create a separate gwinc/optimizer group/package for this and other optimizers.
Edited by Jameson RollinsOk, I can see the argument for making them separate. My only argument would be that it is pretty tightly coupled to the noise calculation code so that it can choose when to recalculate each curve. As long as I can factor that out and make it a maintained API then we should be good. I could make that noise calculator code the primary gwinc call so we don't need to maintain two implementations. This would also likely make it become more of an object that can be modified via inheritance.
I'm not sure how to do the git adjustments to keep some of the other additions and edits. I factored out the FOM parser which we should keep, as well as a handful of other things (like adding some necessary methods to Struct).
Can I just pull the larger optimizer code out of the branch and request the merge, or should I somehow rebase so that the optimizer is never included (a fair amount of work...).
-
We can definitely make the core more amenable to optimization, via some kind of memoization. And it probably makes the most sense to do that in the core itself, since it would be applicable to all optimization wrappers. Might be worthwhile to discuss potential architectures, so we can keep things simple. I feel like we can probably do something with e.g. decorators without completely re-factoring the core.
git is super amenable to this kind of refactorization. Just create a new branch and cherry pick the commits you want, or just branch and do a rebase -i to prune out the commits you don't want.
In general I would prefer a cleaner commit history anyway, which can also be pretty easily achieved with git rebase -i and ammends when necessary.
