openmc.Universe.name in geometry.xml?

User Support
1

Hello all,

A question about the name attribute of Universe: I’ve found that if I create universes with names, and then export them to the xml files, and then create a model object from the xml files, the Universe.name attribute isn’t copied over like it is with cells or materials. I’m guessing it’s because there is no universe xml elements to store the names in. Am I mistaken? Is there a workaround for this?

Thanks!
James

2

You’re not mistaken – at present, the way that OpenMC writes XML files, there is no <universe> element that is conceptually equivalent to the <cell> or <surface> element. Instead, the universe assigned to a cell is just given as an attribute, so there is no single place to write a universe name. I can’t think of an easy workaround for this unfortunately.

1 Like
3

@paulromano Is there any reason there couldn’t be a <universe> element that stores the name for a universe number? Preserving the name is pretty useful for automation.

4

That would be one easy way to get the information in, although in the case where no name is given it may seem a little odd no have an empty universe element. If we’re going to change up the XML, it might make more sense to just group cells logically under a <universe> element, i.e., something like

<universe id="1" name="My universe">
  <cell id="1" ... />
  <cell id="2" ... />
  <cell id="3" ... />
</universe>
<universe id="2" name="Your universe">
  <cell id="4" ... />
  <cell id="5" ... />
  <cell id="6" ... />
</universe>
5

I’m glad that this has prompted some discussion, and I second @tjlaboss , I’m using name attribute like keys in python, and so passing them into and out of XML files would be useful. A cheap workaround that I was thinking about was appending the universe information to the name of the cells inside that universe and then recreating the universe and adding the cells that way. Either way @paulromano , I understand that you’re probably hesitant to change the format of the XML files, but maybe if you’re staging some larger changes to the XML format, this could be included. Thanks.

1 Like
6

I’m all for changing the XML files in a way that makes more sense, but I do have to balance that against the cost of breaking everyone’s existing input files :slight_smile: It would be pretty trivial to implement this but will take a little extra work if we want to retain backward compatibility. As you suggest @pjb, perhaps we’d want to do this in conjunction with other changes in the XML formats, if any.

1 Like