{"action":"created","issue":{"url":"https://api.github.com/repos/mit-crpg/openmc/issues/458","labels_url":"https://api.github.com/repos/mit-crpg/openmc/issues/458/labels{/name}","comments_url":"https://api.github.com/repos/mit-crpg/openmc/issues/458/comments","events_url":"https://api.github.com/repos/mit-crpg/openmc/issues/458/events","html_url":"https://github.com/mit-crpg/openmc/issues/458","id":107313174,"number":458,"title":"Input/output changes for next minor release","user":{"login":"paulromano","id":743095,"avatar_url":"https://avatars.githubusercontent.com/u/743095?v=3","gravatar_id":"","url":"https://api.github.com/users/paulromano","html_url":"https://github.com/paulromano","followers_url":"https://api.github.com/users/paulromano/followers","following_url":"https://api.github.com/users/paulromano/following{/other_user}","gists_url":"https://api.github.com/users/paulromano/gists{/gist_id}","starred_url":"https://api.github.com/users/paulromano/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/paulromano/subscriptions","organizations_url":"https://api.github.com/users/paulromano/orgs","repos_url":"https://api.github.com/users/paulromano/repos","events_url":"https://api.github.com/users/paulromano/events{/privacy}","received_events_url":"https://api.github.com/users/paulromano/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":13,"created_at":"2015-09-19T05:52:23Z","updated_at":"2015-09-24T12:25:02Z","closed_at":null,"body":"There are quite a few ways in which user input/output may change over time as new developments are added to the code. I think it would be good for us to start thinking about some of these changes and try to group them together as much as possible to limit the number of times we potentially disrupt users. To that end, I'm going to put up for discussion my own wishlist of changes to input/output and invite others to do the same.\r\n\r\n1. Extension of `<cell surfaces=\"...\" />` notation to include Boolean operations like union and difference. Further discussion on #60.\r\n2. Changes related to depletion\r\n    1. Ability to run multiple steps, each with a flux calculation, in general. Of course, this is required for depletion, but it may be useful to have for other things as well. We could also generalize the step to do other things as well. So effectively, the user could define the run sequence.\r\n    2. Ability to specify a material as depletable.\r\n3. Support for multiple particle types (source, tallies, particle production).\r\n4. Probably many changes to tallies due to #214\r\n5. Specify temperature for a material/cell. Cell probably makes more sense since temperature is not an intrinsic property of a material.\r\n6. For lattices and meshes, we should really use the term \"shape\" instead of \"dimension\" which is consistent with both Fortran (which has a `shape()` intrinsic) and numpy (whose array's have a shape attribute).\r\n7. Rename statepoint to simply \"state\". The \"point\" is a little superfluous.\r\n8. In statepoint files (or state files) and summary files, move away from using arbitrary constants for things like the run mode and instead just use strings. That should make it a little easier to maintain.\r\n9. Don't write a separate dataset with the size of arrays in HDF5 files if there is no need.\r\n\r\nI'll keep adding more things here as I think of them. Some of these changes I'd like to target for 0.8 if others are in agreement."},"comment":{"url":"https://api.github.com/repos/mit-crpg/openmc/issues/comments/142913863","html_url":"https://github.com/mit-crpg/openmc/issues/458#issuecomment-142913863","issue_url":"https://api.github.com/repos/mit-crpg/openmc/issues/458","id":142913863,"user":{"login":"wbinventor","id":209492,"avatar_url":"https://avatars.githubusercontent.com/u/209492?v=3","gravatar_id":"","url":"https://api.github.com/users/wbinventor","html_url":"https://github.com/wbinventor","followers_url":"https://api.github.com/users/wbinventor/followers","following_url":"https://api.github.com/users/wbinventor/following{/other_user}","gists_url":"https://api.github.com/users/wbinventor/gists{/gist_id}","starred_url":"https://api.github.com/users/wbinventor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wbinventor/subscriptions","organizations_url":"https://api.github.com/users/wbinventor/orgs","repos_url":"https://api.github.com/users/wbinventor/repos","events_url":"https://api.github.com/users/wbinventor/events{/privacy}","received_events_url":"https://api.github.com/users/wbinventor/received_events","type":"User","site_admin":false},"created_at":"2015-09-24T12:25:02Z","updated_at":"2015-09-24T12:25:02Z","body":"Philosophically, I agree with @smharper on this point of abstraction. However, I think this raises the more important point which is whether the development of OpenMC is / should be user-centric or developer-centric. Based on what I've seen, I think that the abstraction is very much focused on what developer's \"theoretically\" like from a software standpoint. Perhaps I'd be assuming too much to say that most users couldn't care less how beautiful the delegation of roles is between libraries used by the application as long as the 1) installation is super simple and 2) the inputs to the code are seamless and hide whatever layers of abstraction there may be.\r\n\r\nI certainly agree with @paulromano (and I think @smharper) that the depletion engine developed for OpenMC should be reusable. But I'm not convinced that following this philosophy for software development \"to a t\" in OpenMC is sustainable for a (largely) student developed and supported code. Without a lot of careful thought as to the software design, the extra \"degrees of freedom\" for development permitted by a system of interconnected codes would make it much more difficult for the annual influx of new novice student developers to climb the learning curve and code something useful. In an ideal world I would agree with @smharper on this completely, but we don't live in such a world, so I would be a hesitant supporter of this approach."}}