Hello All,
There currently does not exist any installation instructions for statepoint.py (that I could find) other than a mention on this page that it should be on your PYTHONPATH. It doesn’t even tell you that the file is in src/utils. Furthermore the installation instructions don’t tell you to run the setup.py file in this directory.
Furthermore the documentation inside of statepoint itself is fairly minimal and could definitely be fleshed out.
So my question is are there plans to address the above and make the processing tools more of first class citizens? I’d love to be able to “from openmc import statepoint”. For my personal use I am pretty sure I can figure out what I need to do (with possible help from the mailing list). However, at this point, I couldn’t turn around and give my code to a third party user because I have no guarantees that OpenMC’s would be installed correctly or even that they would be present at all!
Also, don’t get me wrong. I love that you are shipping processing tools with the code! That is awesome. But if you are going to do something, it should have equal footing.
Thanks!
Be Well
Anthony
Hey Anthony,
The file in question was originally designed by a single developer for private use and managed to make its into the repo, where demand for it has been rising. Accordingly, this file is currently undergoing serious modifications, and hopefully a pull request will be issued relatively soon for it. This PR will be built on top of some additional functionality which is also under development. Unfortunately, due to the nature of binary output formats, this update may not be available until a future main release of OpenMC, as the files it is reading from will not match the format of the current release. It may be possible to push the new documentation for some of the methods to the main branch without a major release, but I cannot guarantee this as I have not seen the relevant code.
In the meantime, if you do have questions about its current functionality, or need help understanding what’s going on, feel free to ask.
Best,
Derek Lax
Hey Anthony,
The file in question was originally designed by a single developer for
private use and managed to make its into the repo, where demand for it has
been rising. Accordingly, this file is currently undergoing serious
modifications, and hopefully a pull request will be issued relatively soon
for it. This PR will be built on top of some additional functionality which
is also under development. Unfortunately, due to the nature of binary
output formats, this update may not be available until a future main
release of OpenMC, as the files it is reading from will not match the
format of the current release. It may be possible to push the new
documentation for some of the methods to the main branch without a major
release, but I cannot guarantee this as I have not seen the relevant code.
Hello Derek!
Thanks for the explanation. I am glad that there is a plan and I certainly
understand the need to update and improve code in backwards incompible ways
:). Could you clarify what you mean by main/major release? Does this mean
v0.6 or v1.0?
Also do you have a rough expectation of when this will come out? I ask
because I have a contract due in ~15 months and we are trying to decide
between serpent and openmc as a default backend right now. This issue
won't be a deal breaker either way but it is helpful in terms of managing
expectations.
In the meantime, if you do have questions about its current functionality,
or need help understanding what's going on, feel free to ask.
Thanks, will do!
Be Well
Anthony
Hey Anthony,
I can answer your question in the follow way. I would consider any tagged release a major release. For our development purposes, a minor release generally only encompasses bug fixes and updates that do not affect the code’s functionality. This would include documentation updates. As for an expectation of when this would come out, that depends on how much the statepoint.py file has been changed. If the changes retain the methods and their interfaces, I feel safe in saying that the documentation should be available in a PR to the main branch within 30 days, hopefully less. If this is not the case, and the modifications change the methods functionality, then I do not know when it will be.
Best,
Derek Lax
Hey Anthony,
I can answer your question in the follow way. I would consider any tagged
release a major release. For our development purposes, a minor release
generally only encompasses bug fixes and updates that do not affect the
code's functionality.
Hi Derek,
Thanks for clarifying. I'd like to note though that these do not follow
the normal definitions as described by semantic versioning (
http://semver.org/) which is why I was a little unclear before. Also note
that github's release mechanism itself recommends semantic versioning (
Release Your Software - The GitHub Blog).
This would include documentation updates. As for an expectation of when
this would come out, that depends on how much the statepoint.py file has
been changed. If the changes retain the methods and their interfaces, I
feel safe in saying that the documentation should be available in a PR to
the main branch within 30 days, hopefully less. If this is not the case,
and the modifications change the methods functionality, then I do not know
when it will be.
Since we got a bit sidetracked here, I'd like to restate my original plea
that you please add statepoint.py to the installation instructions and make
the analysis tools part of the standard install procedure. Since there is
no code being added this should be fully backwards compatible. I can open
an issue to this effect if you'd like. Thanks!
Be Well
Anthony
Hi Anthony,
My apologies for the semantic debate. My previous statement which you quoted may not have been thorough enough. The statepoint.py file that you have access to was not designed to general use. It was designed by a single user for personal use. Accordingly, it is not tested nor fully developed. To include it in the installation instructions in its current state along with the rest of the files under utils would be unfair both to the users and the developers as it is incomplete. Currently there is work in progress to bring this file to the level of performance where we would be comfortable with that. The updated file is being designed around newer code, which in my understanding may have an entirely different API. Either way, unfortunately I am not at liberty to change milestones.
If I am still failing to understand what you are saying, feel free to open an issue so that another pair of eyes will look at it.
Best,
Derek
To add a few thoughts – I originally wrote the statepoint.py module at a time when OpenMC was rapidly coming together, and so while I don’t agree that it was solely intended for my own personal use (it was not), I will be the first to admit that it is neither well thought out nor well documented. I’m glad that there is work-in-progress on a better designed replacement. To that end, I’ll work with the development team to figure out what an appropriate timeline is, and if we decide that the replacement won’t make it to a near-term release, then we will certainly make sure that better documentation on the current version is made available.
Regarding versioning – we do generally try to follow semantic versioning. But, remember that OpenMC is 0.y.z, which means we reserve the right to break anything at any time 
Right now, our “minor” and “patch” versions are more like “major” and “minor/patch”. So a significant change to statepoint.py would increment the minor version.
Regarding installation – our CMakeLists.txt (only on develop branch) does run ‘python setup.py install --user’. Not the cleanest thing ever, but it works (let me know if you have better ideas). The most recent release unfortunately does not do that; in fact there was no setup.py with it either.
Lastly, it’s really exciting to hear that you are considering using OpenMC for work on a contract! Do let us know if you have specific needs or if there are areas where you think things can improve (obviously a cleaner Python API is on our mind already), and we’ll do our best to support you.
Best regards,
Paul
Hi Derek, Paul,
The point on installation is perfect. Running setup.py from cmake is exactly want I wanted! It is good to know that most of the things that I want have already been addresses or are in the pipeline. This is great.
And for the record, you all have been superb about support so far. If I was the only one involved, this would be the deciding factor for me. I’ll be sure to ask more questions as time goes on :).
As some of you (Paul certainly) know my heart is with open source. I am very excited to see a fully open nuclear engineering stack emerging. I think that it is going to be great!
Be Well
Anthony