{"action":"created","issue":{"url":"https://api.github.com/repos/mit-crpg/openmc/issues/773","repository_url":"https://api.github.com/repos/mit-crpg/openmc","labels_url":"https://api.github.com/repos/mit-crpg/openmc/issues/773/labels{/name}","comments_url":"https://api.github.com/repos/mit-crpg/openmc/issues/773/comments","events_url":"https://api.github.com/repos/mit-crpg/openmc/issues/773/events","html_url":"https://github.com/mit-crpg/openmc/pull/773","id":196575788,"number":773,"title":"Material.add_material(...) method","user":{"login":"samuelshaner","id":1244537,"avatar_url":"https://avatars.githubusercontent.com/u/1244537?v=3","gravatar_id":"","url":"https://api.github.com/users/samuelshaner","html_url":"https://github.com/samuelshaner","followers_url":"https://api.github.com/users/samuelshaner/followers","following_url":"https://api.github.com/users/samuelshaner/following{/other_user}","gists_url":"https://api.github.com/users/samuelshaner/gists{/gist_id}","starred_url":"https://api.github.com/users/samuelshaner/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/samuelshaner/subscriptions","organizations_url":"https://api.github.com/users/samuelshaner/orgs","repos_url":"https://api.github.com/users/samuelshaner/repos","events_url":"https://api.github.com/users/samuelshaner/events{/privacy}","received_events_url":"https://api.github.com/users/samuelshaner/received_events","type":"User","site_admin":false},"labels":[{"id":129101,"url":"https://api.github.com/repos/mit-crpg/openmc/labels/Other%20Enhancement","name":"Other Enhancement","color":"e102d8","default":false},{"id":208504460,"url":"https://api.github.com/repos/mit-crpg/openmc/labels/Python%20API","name":"Python API","color":"bfd4f2","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-12-20T03:07:51Z","updated_at":"2016-12-30T16:37:12Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/mit-crpg/openmc/pulls/773","html_url":"https://github.com/mit-crpg/openmc/pull/773","diff_url":"https://github.com/mit-crpg/openmc/pull/773.diff","patch_url":"https://github.com/mit-crpg/openmc/pull/773.patch"},"body":"This short PR adds an `add_material(...)` method to the Material object in the Python API. This method is useful when trying to homogenize multiple materials by atom percent (e.g. for the C5G7 benchmark or water/structural materials in BEAVRS) or weight percent (e.g. for the TREAT fuel/graphite blocks). The `add_material(...)` is structured such that it expands a given material into its constituent nuclides and adds the nuclides to the base material. \r\n\r\nWhile this method is handy, there are some caveats that haven't been addressed in this PR. Since the temperature is set by material or cell, a material can only be added to another material if they have the same temperature. Also, since s(a,b) are set on a material basis, there is the possibility of a material having multiple s(a,b) for the same nuclide. I'm not sure how OpenMC treats these cases, but it doesn't appear that an error is given.\r\n\r\nTwo materials can be homogenized as follows:\r\n\r\n    fuel = openmc.Material()\r\n    fuel.set_density('g/cm3', 10.0)\r\n    fuel.add_element('U', 1.0, enrichment=2.5)\r\n    fuel.add_element('O', 2.0)\r\n\r\n    clad = openmc.Material()\r\n    clad.set_density('g/cm3', 6.55)\r\n    clad.add_element('Zr', 1.0)\r\n \r\n    fuel_clad = openmc.Material()\r\n    fuel_clad.add_material(fuel, 0.9, 'ao')\r\n    fuel_clad.add_material(clad, 0.1, 'ao')\r\n\r\nThis PR builds on PR #771"},"comment":{"url":"https://api.github.com/repos/mit-crpg/openmc/issues/comments/269792171","html_url":"https://github.com/mit-crpg/openmc/pull/773#issuecomment-269792171","issue_url":"https://api.github.com/repos/mit-crpg/openmc/issues/773","id":269792171,"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},"created_at":"2016-12-30T16:37:12Z","updated_at":"2016-12-30T16:37:12Z","body":"Ugh, yeah this is getting messy. So the ENDF thermal scattering files themselves don't really say \"use this for these nuclides\". That is something that an NJOY user has to specify (ACER, card 8a) which explains why you're seeing differences between different data libraries. As far as I can tell, the fact that NNDC assigns both Be9 and O16 on the \"Be in BeO\" table is wrong (same with \"O in BeO\"). There is an [older evaluation](https://www-nds.iaea.org/public/download-endf/ENDF-B-VI-8/THERMAL-SCATTERING/mat/endf-b-vi-8_tsl_27.txt) of BeO that is supposed to be used for both Be and O, but since ENDF/B-VII.1, they've been separated. Probably an issue of someone using an old input with the newer files. The other problem is that NJOY evidently only lets you assign three nuclides. It's not clear at all to me what happens for something like Zr in ZrH where you have 5 naturally-occurring isotopes.\r\n\r\nThe last issue you mention should be an easy fix regardless of whether we're changing what S(a,b) tables get attached to or not.\r\n\r\nI'll have to think more about your proposed change. At present, I lean towards keeping things as they are. Since the information we need to store is the mapping of S(a,b) table -> set of nuclides, it seems appropriate to me that that is done at the level of a material. I would not want to store an attribute that indicates for each nuclide in each material whether it has an S(a,b) table attached (could end up wasting a lot of memory to stores zeros for, say, a large reactor model that is being depleted).\r\n\r\nAnother alternative is to specifically have moderator nuclides (this approach is used by MC21/NDEX). That is, you could create a material with `<nuclide name=\"H_in_H2O\" ... />` or something like that. I can imagine two different implementations of such a scheme:\r\n1. Explicitly create these nuclides, e.g., add functionality to our `openmc.data` API to create a moderator nuclide. The moderator nuclide would have its own HDF5 data.\r\n2. Have code on the OpenMC Fortran side preprocess data to create these moderator nuclides. In our `nuclides(:)` array, you could have two separate entries for H1, one representing free H1 and the other H1 bound in H2O. They would both contain the same free atom data but one of them would also have S(a,b) data attached.\r\n\r\nI don't think there's really a \"best\" option. They all have pros and cons. I would also think of the decision as being three different pieces:\r\n1. The abstraction presented to the user.\r\n2. The abstraction for how the data is stored on disk.\r\n3. The abstraction for how data is stored in memory within OpenMC.\r\n\r\nThe three don't necessarily have to all be the same. Keeping the abstraction more in line with how ACE works makes it easier to convert data/inputs and to compare codes on an equal footing. Moving away from the ACE abstraction gives us a little more freedom to represent things as we think they should be."}}
{"actor":{"display_login":"paulromano"}}