Skip to content
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

FIX: Undefined symbols in CompiledModel are automatically set to zero #90

merged 8 commits into from May 9, 2017


Copy link

@richardotis richardotis commented May 5, 2017

Fixes gh-54.

The warning mechanism here (using the logging module) is the same as what is used in calculate to emit the same warning for Model, but it is different from the mechanism (using the warnings module) in equilibrium. I think there may be some kind of reason why I originally picked the logging module (perhaps some ability to redirect or disable messages selectively), but it did not seem to catch on with me for whatever reason. I am also not sure how to do the equivalent of warnings.catch_warnings with the logging module to programmatically verify we are emitting the correct warnings in the test.

@richardotis richardotis requested a review from bocklund May 5, 2017 21:14
Copy link

bocklund commented May 6, 2017

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 warnings unless there were a compelling reason to use logging.

All that being said, is this worth issuing a warning in logging or otherwise?

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

For the record, the way to programmatically capture logging output is discussed here:

With the key part of it reproduced here

import logging
import io

### Create the logger
logger = logging.getLogger('basic_logger')

### Setup the console handler with a StringIO object
log_capture_string = io.StringIO()
ch = logging.StreamHandler(log_capture_string)

### Optionally add a formatter
formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')

### Add the console handler to the logger

### Send log messages. 
logger.debug('debug message')'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()

### Output as lower case to prove it worked. 

Copy link

@bocklund bocklund left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. Do you think we should check that the parameters were actually set to zero by looking at the calculation result? Maybe something hard coded that ensures that we don't accidentally set undefined parameters to 1 or -10000 in the future?

Copy link
Collaborator Author

Good idea.

Copy link

@bocklund bocklund left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ready to merge

Copy link
Collaborator Author

@bocklund Trying to figure out why the Linux py27 tests are hanging. I thought maybe it's a dependency issue but the previous commit runs fine when restarted.

Copy link
Collaborator Author

I cannot reproduce this in a clean local py27 environment.

Copy link
Collaborator Author

The coverage check looks bugged but otherwise everything passes, so I'll merge.

@richardotis richardotis merged commit 5bc5ed3 into develop May 9, 2017
@richardotis richardotis deleted the fix_issue54 branch November 14, 2018 23:53
bocklund added a commit to bocklund/pycalphad that referenced this pull request Aug 17, 2021
…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


* 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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

2 participants