Comments (10)
After some digging, ugali/analysis/mcmc.py
references ugali/analysis/loglike.py
, where the source is made here. It looks like config.get(section) != None
, but config.get(section).get('source') == None
, so it ends up reading params == None
. If this function is forced to use params = config.get('source')
, then the params end up loading properly and we get out a g-i
isochrone. It's not clear to me whether this is the expected behavior, or if we want to throw an error when getting the section is not none but getting the source from the section is none. Disregarding that, a simple fix is writing the function like:
def createSource(config, section=None, **kwargs):
config = Config(config)
source = Source()
if (config.get(section) and config.get(section).get('source')) is not None:
params = config.get(section).get('source')
else:
params = config.get('source')
if params is not None:
source.load(params)
source.set_params(**kwargs)
return source
from ugali.
This lead to some other pieces of ugali breaking... suggesting that support for bands other than g-r
isn't universal, or I'm missing some masks:
Traceback (most recent call last):
File "./ugali/analysis/mcmc.py", line 352, in <module>
like = ugali.analysis.loglike.createLoglike(config,source)
File "/home/s1/smau/software/ugali/ugali/analysis/loglike.py", line 600, in createLoglike
observation = createObservation(config,lon,lat)
File "/home/s1/smau/software/ugali/ugali/analysis/loglike.py", line 549, in createObservation
mask = createMask(config,roi)
File "/home/s1/smau/software/ugali/ugali/analysis/loglike.py", line 564, in createMask
mask = ugali.observation.mask.Mask(config, roi)
File "/home/s1/smau/software/ugali/ugali/observation/mask.py", line 52, in __init__
self._photometricErrors()
File "/home/s1/smau/software/ugali/ugali/observation/mask.py", line 349, in _photometricErrors
pars_2 = MAGERR_PARAMS[release][band_2]
KeyError: 'i'
from ugali.
Didn't we talk about that last issue before? The updates to MAGERR_PARAMS
would need to be in ugali/utils/constants.py.
from ugali.
I also think that we want the fix to be a bit deeper than createSource
. When creating an isochrone it should always respect the bands provided in the config regardless of whether the source section exists or not. I think this means we need to dig into what the factory is doing when it creates the isochrone.
from ugali.
oh, I think my hacked changes to MAGERR_PARAMS
were lost when I updated my fork, which is why I was confused to get that error again. I agree that createSource
is not the root of the issue, but that's also the earliest place I see a config file getting passed to the Source
object.
from ugali.
Will we want to look for a config file whenever we create an isochrone (i.e. in the factory)? or do we just want to load more parameters whenever we do read in a config file? I'm not sure how we would make this check whenever initializing an isochrone, which is what I think would need to happen at the factory level if we wanted to do that.
from ugali.
That's a good point. We would like to retain the ability to create a source without a config, which means that createSource
is probably the place we need to do it. However, we want to have the default action be to read the proper mag_1
and mag_2
variables without any source defined.
from ugali.
Since we'll have to read this from the config file, how would this be best implemented? I've been playing around with it a bit, and we could have createSource
look in the isochrone
section of the config file and then on source.isochrone
. However, since the source
section just appears to be a wrapper for isochrone
and kernel
, I'm not sure if this is much better than being ambivalent to the existence of a source
section...
from ugali.
As far as running the mcmc, this has been resolved by adding band_1
and band_2
specifications to srcmdl.yaml
in the isochrone
section. Right now, this line will load the isochrone specified by the srcmdl and overwrite the isochrone loaded from the config file. If we want to use non-default isochrone parameters, then these should be specified in both config.yaml
and srcmdl.yaml
for now.
from ugali.
Thanks Sid, this sounds like the underlying issue.
The mcmc.py
script allows (too much) flexibility in defining the source model and fit parameters. Looking in mcmc.py
I think the order of operations is:
- Create the source from the
source
variable in themcmc
section of the config - If a
srcmdl
file is provided, then overwrite with the values from the section of thesrcmdl
file corresponding to the source name. - If coordinates are provided on the command line, then update the source centroid with the coordinates.
- If the
params
variable exists in themcmc
section of the config, then free the listed params in the source. - If
opts.grid
is set, then initialize the parameter values to the best fit from an initial grid scan.
Each of these pieces of functionality have been useful in the past, since they allow a lot of flexibility in the input parameters. For example:
- You can run the mcmc fit without a source model by just providing a set of coordinates.
- You can free specific parameters from the config without ever having to touch the srcmdl.
- You can fully specify all the details of the srcmdl if desired.
Clearly, this complexity and lack of documentation has been detrimental for users. I think we can deal with this in a few ways.
- We can reduce the functionality with the easiest option being that we require a
srcmdl
in order to fit a candidate. - We can better define and document the order of priority.
from ugali.
Related Issues (20)
- Absolute magnitude from generic isochrone color HOT 1
- Add background density to results
- User age/metallicity bounds not respected
- Fix string type check for py2/py3 HOT 2
- Update isochrone download scripts HOT 1
- Update ugali dwarf catalogs HOT 9
- Add catalog for diffuse structures
- Typo in DECam mesa isochrone IO HOT 1
- Fix IAU name generation HOT 1
- Output Galactic coordinates with uncertainties
- Change coordinate name to equatorial
- bug in plotMembership in ugali.utils.plotting
- Surface Brightness calculation in ugali.analysis.results.py should use azimuthally-averaged half-light radius HOT 4
- ugali.stats.peak_interval appears to be calculating the interval incorrectly HOT 3
- Add Martin surface brightness to results
- Rename master branch to main
- Move to GitHub actions
- Update Johnson-Cousin transformations HOT 1
- pip install options
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ugali.