Closed DanRyanIrish closed 4 months ago
Attention: Patch coverage is 42.88618%
with 281 lines
in your changes missing coverage. Please review.
Please upload report for BASE (
main@8021cd6
). Learn more about missing BASE report.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
ping @samaloney
@KriSun95 If you're happy with this, can you officially approve it?
@samaloney It would be good to get your approval here. The main things you should know about the new structure are:
legacy
, including the old model modules and the fitting_legacy
subpackage.models
subpackage. (Can you confirm you are happy with the name?) It has the following structure:
matrix.py
to hold Kris's future matrix modelresponse.py
Models specific to responses. I differentiate this from matrix.py because one could imagine a generla matrix model that isn't specific to a response. If response
turns out to be not needed because a generic matrix model is sufficient, this can be deleted in future.math.py
a module for mathematical models, e.g. a power-law. (Again, is this the right module name?photon
subpackage for photon/physical models. Is this the right name? Inside this so far is:thermal
subpackage for all code needed for thermal models. Currently, it includes the io.py
and thermal.py
modules. There are copies of these in the legacy
subpackage so they can be refactored into proper models without losing the old functionality for now.nonthermal
subpackage for future refactored nonthermal functions.Mainly the names and the structure is what I'd like your views on before merging. E.g., perhaps math.py
should be mathematical.py
so the path is models.mathematical.powerlaw
? More modules can be added in the future if needed of course, e.g. models.integrate
for the integrate
module now living in legacy
.
Over all I think this sounds good. I was just looking at some other existing packages and how they layout their models and some discussion we had before in #42.
Questions:
models
or modeling
don't really mindI think the integration stuff could live in it own module as it is essentially generic numerical integration.
My suggestion would be the following as I do like the idea of separating physically meaningful models from other mathematical or functionals ones.
.
└── models
├── models.py
├── instrument_response.py # don't need this now as Matrix would do
└── physical.py #these could be a directories/submodules if needed as you have
but the imports could be like this (updating the case for class v function)
from sunkit_spex.models.physical import thermal, thin_target, thick_target, warm_target
from sunlit_spex.models import Matrix
from sunkit_spex.models import Powerlaw
or if we find we have a lot of powerlaw or non_thermal models in the future we can change to
from sunkit_spex.models.powerlaw import MyFavPowerlaw
from sunkit_spex.models.pyhsical.nonthermal import WarmTarget, MediumHotTarget 😆
Also moving stuff around the namespace while annoying is possible so we aren't going to be stuck if we find we need to change we can so it really doesn't matter too much so going to approve this PR.
1. `models` or `modeling` don't really mind
OK. Let's stick with models
then, since there's no clear convention.
2. Why move the io inside the model?
The thermal io.py
was specifically for reading in CHIANTI tables for the thermal model. There's another io
in fitting_legacy
. There could be an io
module for reading spectral files as well. I agree this is messy. But perhaps changing the name from io
or moving it out later is an option too.
. └── models ├── models.py ├── instrument_response.py # don't need this now as Matrix would do └── physical.py #these could be a directories/submodules if needed as you have
OK. I'll change photon
to physical
. What would go in models.py
? Would this be equivalent to mathematical.py
, i.e. PowerLaw
?
or if we find we have a lot of powerlaw or non_thermal models in the future we can change to
from sunkit_spex.models.powerlaw import MyFavPowerlaw from sunkit_spex.models.pyhsical.nonthermal import WarmTarget, MediumHotTarget 😆
Even if there's a sunkit_spex.models.physical.nonthermal
subpackage/module, we can use the physical.__init__
to enable importing directly from sunkit_spex.models.physical
.
Ah. Do you mean that models.py
would hold things like PowerLaw
and MatrixModel
? As in generic, non-physical, non-instrumental models?
Ah. Do you mean that
models.py
would hold things likePowerLaw
andMatrixModel
? As in generic, non-physical, non-instrumental models?
Yea exactly anything that's not a physical model - if we find we have a too many we could create additional submodules/namespaces response
, or powerlaw
down the line.
OK, great. I've made those changes. Pending tests passing, can you approve this?
why is the thermal code duplicated in legacy and models? @DanRyanIrish
from Element:
why is the stix and rhessi “spec” code back in legacy? it’s kind of defunct now that we moved rhessi to “extern”
PR Description
This PR restructures the repo in line with the planned refactor. It moves the
fitting_legacy
subpackage and all model-related modules to a newlegacy
subpackage and creates a newmodels
subpackage. Currently, this holds a few empty subpackages and modules to show how it should/could be structured going forward.I suggest that we use this structure for our refactor, starting with the following:
MatrixModel
Spectrum
data container based onNDCube
in a newspectrum
subpackage, or decide that rawNDCube
s are sufficient.There would be more to do, but this would actually prove the fundamental pillars of our refactor.
Other crucial work involves refactoring the non-thermal functions and making them models.