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

Avoid writting DataFrame index into hotstart #68

Closed
wants to merge 4 commits into from

Conversation

algchyhao
Copy link
Contributor

Avoid writting the index of DataFrame into header "FILES:, which will cause the error of "ERROR 205: invalid keyword 0 (or 1)at line # of [FILE] section"

avoid writting the index of DataFrame  into header "FILES:, which will cause the error of "ERROR 205: invalid keyword 0 (or 1)at line # of [FILE] section"
avoid writting the index of DataFrame into header "FILES:, which will cause the error of "ERROR 205: invalid keyword 0 (or 1)at line # of [FILE] section"
@algchyhao
Copy link
Contributor Author

Don't know why checks failed yet, it works locally with Linux Python 27.

Hot Start file written error
read_table is deprecated
@aerispaha
Copy link
Member

@algchyhao, thanks for this contribution! I think the reason the checks are failing is because the index (as it is currently used in most dataframe model sections) is important when changing INP sections with swmmio. The index of each dataframe in the typical sections (e.g. [CONDUITS])contains the model element ID. The problem is not all sections of INP file follow the same format (e.g. [FILES]).

Because of this, the changes you've proposed cause issues in the version_control module, in which a lot of INP manipulations occur. To resolve this, we'll need to develop specific logic to handle each of the unusual INP sections. Check out issue #57 - there we're tracking our progress on handling all of the INP sections. When we resovle this PR, I think we should be able to checkout off the [FILES] section from #57.

As next step, can you put together a unit test that checks that we properly handle the [FILES] section? From there, I expect we'll need to develop some conditional logic that checks if the section we're parsing/writing is of this unusual format.

@aerispaha
Copy link
Member

This issue is being resolved in #165. Once that is merged, I think we can close out this PR ❤️

@aerispaha aerispaha closed this Dec 29, 2022
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