@paulromano, my thoughts are that this bug we have identified should be tracked for correcting. This can cause unexpected results that careful users may not catch. Example, User A has an OPENMC_CROSS_SECTIONS environment variable set up, then attempts to change this with the python API materials.cross_section function, compiles and runs with python options --generate and --run, sees no error, but does not check that the cross section set actually changed. User A would unknowingly get the wrong answer. It affects limited users under limited conditions, but still, should be fixed.
I have some time to work on this issue, and I have git set up, so perhaps I can help with getting this through the process.
The --generate and --run options are specific to this assembly example. Normally, when you run the script without the flags, it doesn’t do anything. Perhaps it might be better to have --generate turned on by default to prevent confusion. In any event, what’s happening is that the Model class will automatically generate a Materials instance based on what materials appear in the geometry if one is not specifically assigned (model.materials = ...). A better solution than what is suggested before would be to have:
and then run with --generate as normal. This ensures that a new Materials object (that doesn’t have the cross sections set) isn’t created when the XML files are being written.
Thanks for the info. I understand it is an interrelation to not assigning the materials to your model your model. It still feels like an insidious trap that should be fixed. I.E. make the model class that generates the materials also pull in the cross section assignment if available, or just require the materials be assigned to the model. I actually prefer forcing users to explicitly assign things rather than have auto actions happen to avoid exactly this sort of bug creeping in.
I’m not sure I agree with you that this is a bug. You are talking about an example script not behaving the way that you expect, but to me it makes sense. The purpose of using the Model class is so that you only have to call the export_to_xml method once. If you want to specify materials.cross_sections while using the Model class, the clear way to do this is to assign model.materials = ... and then model.export_to_xml() rather than manually calling materials.export_to_xml.
OpenMC is an open source code and anyone is welcome to propose changes. If you think there are changes in this script that would make the behavior less confusing, I would encourage you to submit proposed changes via a pull request.
I agree, it is more like unexpected behavior (to me) than a bug. I was expecting to just specify a different cross_section set and be counting neutrons. And it has caught other users as well per the thread.
Where I am landing (my opinion that is) is that the model class should not auto-create or populate the materials into the model or rather, if it does, it should also get the materials cross_sections and other such options as well. But I certainly agree that it is better to assign the materials explicitly to the model.
I really do appreciate the thoughts and discussion.
Just to close the loop, the recommended changes worked as expected. I wanted to get your opinion on this behavior because I was not convinced putting this into a pull request is worth the effort. Where I have landed is, no, a pull request for changing the way the Model class auto-generates a materials object is not in order. I expect more users will scratch their heads on this in the future, but I also expect that this thread will be enough to get them back on track.