FIX: Undefined symbols in CompiledModel are automatically set to zero #90
You can set up filtering with warnings similarly, I think. IMO logging should be reserved for looking at what happened in history and shouldn't be used to let the user know that something went wrong at runtime.
Also I believe logging output has historically been more tricky to make visible in jupyter notebooks without manually importing logging and setting the log level. So from that and a binder or jupyter hub perspective, I'd like to see this in
All that being said, is this worth issuing a warning in logging or otherwise?
This particular warning (undefined symbol) has saved me a few times when I typo'd a FUNCTION name or forgot to define it. It helped me figure out why I was getting nonsensical results. Usually an undefined symbol is a mistake, and if I were designing TDBs from scratch I would make it an error, but setting it to zero matches the behavior in TC and is sometimes convenient when building new databases.
I'll take a look at changing the warning method from logging to the warnings module here and also in calculate.
For the record, the way to programmatically capture logging output is discussed here: http://alanwsmith.com/capturing-python-log-output-in-a-variable
With the key part of it reproduced here
import logging import io ### Create the logger logger = logging.getLogger('basic_logger') logger.setLevel(logging.DEBUG) ### Setup the console handler with a StringIO object log_capture_string = io.StringIO() ch = logging.StreamHandler(log_capture_string) ch.setLevel(logging.DEBUG) ### Optionally add a formatter formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s') ch.setFormatter(formatter) ### Add the console handler to the logger logger.addHandler(ch) ### Send log messages. logger.debug('debug message') logger.info('info message') logger.warn('warn message') logger.error('error message') logger.critical('critical message') ### Pull the contents back into a string and close the stream log_contents = log_capture_string.getvalue() log_capture_string.close() ### Output as lower case to prove it worked. print(log_contents.lower())
… R-K gradient evaluation when coefficient matrix is empty but the symbol matrix is non-empty
…nitial database support Closes pycalphad#4 and pycalphad#90 * A new internal API is introduced for generic fitting of parameters to datasets in the ``OptimizerBase`` class. The MCMC optimizer in emcee was migrated to this API (the ``mcmc_fit`` function is now deprecated, but still works until the next major version of ESPEI). A simple SciPy-based optimizer was implemented using this API. * Parameter selection can now be passed initial databases with parameters (e.g. for adding magnetic or other parameters manually). * pycalphad's reference state support can now be used to properly reference out different types of model contributions (ideal mixing, magnetic, etc.). This is especially useful for DFT thermochemical data which does not include model contributions from ideal mixing or magnetic heat capacity. Useful for experimental data which does include ideal mixing (previously ESPEI assumed all data * Datasets and input YAML files now have a tag system where tags that are specified in the input YAML can override any keys/values in the JSON datasets at runtime. This is useful for tagging data with different weights/model contribution exclusions (e.g. DFT tags may get lower weights and can be set to exclude model contributions). If no tags are applied, removing ideal mixing from all thermochemical data is applied automatically for backwards compatibility. This backwards compatibility feature will be removed in the next major version of ESPEI (all model contributions will be included by default and exclusions must be specified manually). * Errors in the ZPF error function are no longer swallowed with -np.inf error. Any errors should be reported as bugs. * Fix bug where subsets of symbols to fit are not built properly for thermochemical data * Pre-building callables is temporarily disabled in multiprocessing because SymEngine objects cannot be pickled. * Add initial database support to parameter generation with test * Failing test for model contributions with initial database * Working subtract out model contributions (one dataset) * Fix for excluded model contributions per mole atom * Add test for mixed dataset types * Filter annoying warnings in the parameter selection ridge code. * Remove a print in the tests * Add ability to include ideal mix in the datasets * Including model contributions is almost certainly wrong, since it could only apply to ideal and it wouldn't work * Add ability to apply tags to datasets, requires tinydb>=3.8 * Enabling tagging * Enable an input Database in the YAML schema for parameter generation * Cleanup of a log * Remove newline * WIP: Simplify kwarg passing in error functions. Next steps: do all data processing outside. Build thermochemical phase models with exclusions * Enhance get_prop_data by allowing for additional queries * Factor out thermochemical data wrangling and Model building so that the Model exclusions * Turn off removing ideal mixing by default in paramselect. Now it is only driven by the exclude_model_contributions A backwards compatibility setting was added to automatically add exclude_model_contributions: [ideal] if none are present in the single phase datasets. This will be removed in ESPEI 0.8 (1 major version). Include docs on how to use tags * Fix some documentation for excluded_model_contributions * Fix input database * Print ideal mixing warning * Don't add ideal exclusions until tags are applied * Default recursive glob to glob for JSON files * Profiling: More efficient access to Datasets by ds["Phase"] rather than ds.Phase according to profiling. * Fix reference to missing models * Fix the callables generated for thermochemical error calculation by shifting the reference state properly for formation data. Fix building callables to correctly build if the property is _FORM (remove form from callable building) * Add support for new pycalphad build callables and reference states in thermochemical data * Support pycalphad's new build_callables v.T and v.P requirements * Update to pycalphad's new callables API * Add more detailed ZPF error logging * Cleanup dead code * Fix tests for callables changes. lnprob test still failing because of a convex hull issue * Currently fails because of an error in lower convex hull, so I am uncommenting in order to catch and raise this error appropriately In the future, all errors should be removed, likely. * Update docs with version 0+unknown information * Update instructions for building development environment * add nose to test suite instructions * Update YAML to user a loader, silencing warning * xfail the failure tests for now * Switching logging of ZPF error details from trace to debug * Clean up debug statements which are too noisy * Refactor to common setup to setup_context * Switch to OptimizerBase backend * Update tests for EmceeOptimizer API * Add code for series of fits * Fix context bug where symbol subsets are not built properly for thermochemical data * Update context to time the phase models * Update thermochemical parameters->symbols_to_fit API * Test optimizer and make tests green * Update 0.7 change log * Enable/disable making callables depending on whether or not there is a scheduler. This should be removed eventually. * pycalhpad 0.8 deps in CI * Install all packages by hand in travis. Update to testing py37 drop py35 (conda forge not building packages) * Use pycalphad build matrix * Remove DEPLOY_ENC_LABEL * Don't test on mac * Dont use xvfb because there are no more matplotlib tests * Remove pytest stuff from setup.cfg * Matplotlib Travis fix * Matplotlib Travis fix * Matplotlib Travis fix * Add object inheritance to OptimizerBase (py27)