Skip to content

Fix doc generation #869

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

Merged
merged 1 commit into from
Feb 21, 2024
Merged

Fix doc generation #869

merged 1 commit into from
Feb 21, 2024

Conversation

dstrain115
Copy link
Contributor

This document errors out with the following error:

"RuntimeError: maximum taylor expansion limit reached"

Changing the time to 0.9 eliminates the error. Better solutions or ideas welcome, but this at least allows the python notebooks to be generated.

This document errors out with the following error:

"RuntimeError: maximum taylor expansion limit reached"

Changing the time to 0.9 eliminates the error.  Better solutions or ideas welcome, but this at least allows the python notebooks to be generated.
@fdmalone
Copy link
Collaborator

Do we know when this started to fail?

@dstrain115
Copy link
Contributor Author

Do we know when this started to fail?

Not really. At least a month. It's been broken for a while, and we were not checking the email alias for doc generation for a while.

@fdmalone
Copy link
Collaborator

fdmalone commented Feb 21, 2024

My current guess is this accuracy threshold was never met for this example (it's set at 1e-15 (the example reaches 1e-14)). In fqe v0.3.0 this raises an error if the max number of iterations is reached before the threshold is breached. Looking back to v0.1.0 there was no warning raised. The notebook seems to be quite a bit older given that it's being pip installed as a git repo and not as a tagged release (there is a comment about updating this to pip install fqe once v0.1.0 is released).

It seems like the correct fix would be to update the accuracy threshold but this doesn't appear to be a controllable parameter from time_evolve. So for the moment I think your fix is the only way.

WDYT @ncrubin

@fdmalone
Copy link
Collaborator

although this seems pretty environment dependent, are there build logs somewhere / environment information. As a side note we should be testing the Openfermion notebooks ourselves periodically.

@fdmalone
Copy link
Collaborator

xref #853

@fdmalone fdmalone closed this Feb 21, 2024
@fdmalone fdmalone reopened this Feb 21, 2024
@dstrain115
Copy link
Contributor Author

Ah, interesting. Maybe we can also create a new issue to plumb out the error_threshold as a parameter as well. Let me know if you would like me to put in this fix for now.

@fdmalone
Copy link
Collaborator

fdmalone commented Feb 21, 2024

Yeah I will open a tracking issue, it's probably best to merge now to fix the docs at least. And we can make the unitary prettier again once the FQE / dependency issue is fixed. It's still not clear to me if this is some dependency change or it's just a flaky thing (although I would think it's deterministic), because I've successfully run the notebook locally in a different environment and can't quite pin down the combination of libraries necessary to reproduce.

@fdmalone
Copy link
Collaborator

Will you need a new openfermion release to fully fix this?

@dstrain115 dstrain115 merged commit c222913 into master Feb 21, 2024
@dstrain115
Copy link
Contributor Author

Will you need a new openfermion release to fully fix this?

I don't think so. Let's see if the doc generation gets fixed overnight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants