Non-deterministic ordering of printed component attributes

I am writing ARMI cases programmatically, and then as each case is created, using the writeInputs method to print the blueprints file. I happened to notice that each time the blueprints file is written, the ordering of written component attributes (i.e. material, temperature, dimensions) changes, even when nothing has changed between the cases. Even if I just write the same case twice by executing my scripts twice in a row, the ordering may change.

It would be nice for the ordering to stay the same so that the written input files can be easily diff-ed against each other.

A quick look into ARMI makes me think that this is actually an issue with yamlize, but confirmation of that would be helpful. This seems odd, considering Python now enforces dictionaries to be insertion-ordered. But if it is something within ARMI, my feeling is that it would be beneficial to update, if possible.

[john-science]

Okay, so this is kind of our problem.

Essentially, Yamlize is really good about deterministically ordering elements before they get written out to the YAML file.

But we go out of our way to edit the items that go into the YAML file on the fly, after Yamlize does all of it’s setup and organization. For instance, in all the methods called addDegreeOfFreedom() in suiteBuilder.py:

https://github.com/terrapower/armi/blob/49ae3fd7b1a2934dbf0f642d9429bb4b1c75ab99/armi/cases/suiteBuilder.py#L274-L277

I can say that I have made a TON of YAML files with our code testing this bug, and they are very largely deterministically ordered. You have to get 4 levels down into the data heirachy inside them to start seeing non-deterministic ordering.

I am looking to see if there is a low-time-cost way of solving this.

[john-science]

It’s an interesting point.

The major reason I discounted this idea to begin with is that several downstream projects (that import ARMI) don’t want PYTHONHASHSEED to be set. For instance, if you are running Monte Carlo simulations, you might/probably want the full power of your pseduo-random-number generators.

Perhaps setting the seed in ARMI wouldn’t affect downstream projects. Or perhaps we could make it so. But:

1. I would need proof we can make that safe.
2. For those downstream projects that don’t want the seed set, the YAMLs would be non-deterministic again.