-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add regression tests replicating current phat_small example run #140
Conversation
includes changes to various files to support explicit setting of library filenames overriding defaults includes a few PEP8 changes (coudn't resist)
Might be useful to upgrade the reading code to use something other than the extensions to decide the filetype
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems ok to me.
Imports on the tests should be back to relative imports
I do not know travis and astropy packaging to tell if anything is wrong with these parts.
For the stellib interpolation, I have a faster and simplified version
http://mfouesneau.github.io/docs/pystellibs/
We could think about adapting it into beast. It also has more libraries and handles different interpolators (mostly need to adapt the units, that are not astropy)
@@ -146,9 +146,9 @@ | |||
# MISTWeb() -- `rotation` param (choices: vvcrit0.0=default, vvcrit0.4) | |||
# | |||
# Default: PARSEC+CALIBRI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's COLIBRI (like te bird)
# Alternative: PARSEC1.2S -- old grid parameters | ||
oiso = isochrone.PadovaWeb(modeltype='parsec12s', filterPMS=True) | ||
#oiso = isochrone.PadovaWeb(modeltype='parsec12s', filterPMS=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the default works properly with BEAST. There are changes in the outputs that need some mapping to work (defining aliases and some testing)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not understand your comment. The line 151 does work in the BEAST in that it produces reasonable output. Can you be more specific?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
parsec12s and the latest version parsec12sr16 do not have the same output format and column names. This may generate bugs downstream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have not seen any bugs or issues between the two versions. I assume that this is handled in the parsec.py code. @lcjohnso any comments on this topic?
@@ -566,6 +570,9 @@ def add_spectral_properties(specgrid, filternames=None, filters=None, | |||
naming format to adopt for filternames and filters | |||
default value is '{0:s}_0' where the value will be the filter name | |||
|
|||
filterLib: str | |||
full filename to the filter library hd5 file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it a filename or filtername?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the full filename of the filter library file. This is needed for the travis testing as the library files are not in the source directory because the testing is done on an installed version of the beast. This allows the testing code to directly pass the location of the filter library file instead of it being in the default location.
This raises the issue of how to handle the library files for the installed version of the BEAST (should make this for those just using the beast). I've opened issue #141 for this.
@@ -4,7 +4,7 @@ | |||
import numpy as np | |||
import pytest | |||
|
|||
from . import extinction | |||
from beast.physicsmodel.dust import extinction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What absolute import? relative is better to use it without installing into the system.
from .. import extinction
from astropy.tests.helper import remote_data | ||
from astropy.table import Table | ||
|
||
from beast.physicsmodel.stars import isochrone |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as before. Imports should be relative as much as possible.
The Mac versus the linux issue is that the no dust photometry is slightly different between the Mac and Linux versions. The relevant error message from Mac run is below (as well as URL to the full output). As the file being tested to is from the linux run, this is showing that the calculation is 0.5% different between the Mac and Linux. I can dig deeper to see if this is some kind of edge case. I'm asking here to see if there is a "quick" fix or a known issue here. We use the scipy.integrate.trapz function for doing the integration. I should run the comparison of the two files outside of the testing system to compare the full file as the testing system stops when it finds the first issue. But I don't have access to a Mac, so need to get someone else to run the testing code on their Mac. Probably something to do on Monday during the BEAST@ST hack day. https://travis-ci.org/BEAST-Fitting/beast/jobs/306428490
E AssertionError: |
Issue seems to be that the radius is *slightly* (1e-14) different for a small number of models (<10 in test)
Difference in radii column may be due to differences in the results from np.power or np.sqrt. The differences are small (1e-14) and are for very few elements (< 10). No clear reason why, not clearly correlated to the logT or logL values. Putting Mac test with remote-data in the allowed failures. |
More info on the differences. The differences are not the same for different columns. This makes me think it might be due to how the numbers are being saved in the hdf5 file. Not clear how different columns could be different. For example, the radius differences should effect all the columns that depend on flux, but this does not seem to be the case. [kgordon@grimy comptests]$ python test_two_spec.py ***** logHST_ACS_WFC_F475W_nd ***** min/max diff [%]: -2.12102363115e-14 2.00556172964e-14 ***** radius ***** min/max diff [%]: -5.89805831405e-14 1.83949685264e-14 ***** logHST_ACS_WFC_F814W_nd ***** min/max diff [%]: -2.01701987515e-14 2.03811248134e-14 ***** logHST_WFC3_F336W_nd ***** min/max diff [%]: -2.09138723297e-14 2.0003631678e-14 ***** logHST_WFC3_F275W_nd ***** min/max diff [%]: -2.14910554968e-14 1.94470571415e-14 ***** logHST_WFC3_F110W_nd ***** min/max diff [%]: -2.07851307728e-14 2.03829590486e-14 |
Smells that it's a compiler issue: mac os uses LLVM and clang while linux uses GCC or g++. |
Yes. 1e-14 variations. Very small. Would like to understand to make sure it is not an indication of a bigger issue. |
Included moving most of the code in fit_metrics to fit_metrics_old. The fit_metrics code would not import in the built version of the beast and I could not figure out why. As a test, I created a simple version of the fit_metrics code and only included what was needed. This worked. So, there is something complicated with the inclusion of the C and python versions and the switching between them that I could not fix. We have only been using the python versions for a few years, and tests I did back in the day found them to have the same speed. Old code saved, so we can always go back.
This means it will be ignored for the testing coverage
Ready for merging! |
Bump. |
# Alternative: PARSEC1.2S -- old grid parameters | ||
oiso = isochrone.PadovaWeb(modeltype='parsec12s', filterPMS=True) | ||
#oiso = isochrone.PadovaWeb(modeltype='parsec12s', filterPMS=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again very careful, some parameters do not produce correct files on the parsec website when you use this model version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you be more specific?
I've run the BEAST with the parsec12s option and it works. Maybe the BEAST is not sensitive to the differences?
from astropy.tests.helper import remote_data | ||
from astropy import units | ||
|
||
from beast.observationmodel.observations import Observations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming beast is installed, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When running tests (with 'python setup.py tests' or via the travis service) the beast is first installed, then the tests are run. So this is as it should be.
One review is enough for merging. |
Add regression tests replicating current phat_small example run
The start of getting regression tests into the travis ci tests. Addresses #97.
The full phat_small model is run in stages and the output of each stage compared to cached versions of the files.
A number of changes needed to get the tests to run in the automated system where the code is run after being installed (not just cloned). Hence this work has also advanced the efforts to get the BEAST installable and working.
Changes include:
In the process, found that there are small differences between the linux and mac versions of the BEAST computations. Not clear why this is the case. Spent time trying to debug before, during, and after the Nov 2017 BEAST HackDay. Looks like it may be due to a small difference in the numerical computation between machine types.