New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove references to geom files in the code #450
Comments
What about this Database method: armi/armi/bookkeeping/db/database.py Line 78 in 190c0ca
and armi/armi/bookkeeping/db/database3.py Line 790 in 190c0ca
Are those |
@drewejohnson @keckler @jakehader Would any of you notice or care if ARMI finally dropped all support for the old Geometry XML files? First off, I'm not sure we have full, functioning support for the old XMLs any more. I assume I can nuke all references and support for the old Geometry XML files and it won't bother anyone. Tell me if I'm wrong. |
In fact, I would love it if XML support was dropped. |
The following files will need to be re-written in YAML and moved into a blueprints file:
Though, maybe some/all of them will be straight deletable. |
So, can you remind me the status of this? I know we removed support for XML case settings in #612 . But did we ever remove support for the XML geom file? I know that Jake said he would be fine with it, but did it ever actually happen? I can't find any record of that being finally deprecated. |
I would love to remove geom files entirely. There are still a couple of features blueprint files don't support that need translating over. I can't find my notes at the moment, but if memory serves, ARMI only supports ThetaRZ geometries through geomFiles, and not blueprint YAML files. So, the last couple geomFile-only features need to be supported by blueprint YAMLs, then we need to help everyone downstream translate their inputs, THEN we can finally remove geomFiles. |
Okay, I can only find the one feature left unsupported by blueprint files:
So, we need a blueprint/YAML format to replace the old XML for ThetaRZ: <reactor geom="ThetaRZ" symmetry="full core">
<assembly theta1="0" theta2="360.0" rad1="0" rad2="2.0" name="IC" azimuthalMesh="1" radialMesh="1"/>
<assembly theta1="0" theta2="180" rad1="2.0" rad2="3.0" name="MC" azimuthalMesh="1" radialMesh="1"/>
<assembly theta1="180" theta2="360" rad1="2.0" rad2="3.0" name="MC" azimuthalMesh="1" radialMesh="1"/>
<assembly theta1="0" theta2="360" rad1="3.0" rad2="4.0" name="OC" azimuthalMesh="1" radialMesh="1"/>
</reactor> |
I believe the YAML version of the ThetaRZ geom/xml file should look something like: armi/armi/tests/Godiva-blueprints.yaml Lines 296 to 334 in 0c6d0ae
|
According to @ntouran , the place in the code I need to improve to remove these geom files is in gridBlueprints.py, where we currently read the geom XML file versions of the RZ Theta blueprints. That will have to be improved to fully support all the little bits and pieces we use for RZ Theta XML blueprints. |
Okay, we definitely support basic RZTheta geometries in YAML format. Nick believes there are some extra pieces of information in the RZTheta geom files that isn't supported in RZTheta YAML files. So I need to find the specifics of what we don't support, and build support for it. |
This is still quite important. Though the features that XML geomFiles support for RZ-Theta geometries are still unknown to me. I believe the problem is something like: RZTheta "geomFiles" have some undocumented feature they support that isn't supported in our YAML blueprints.
Per our previous discussion: @opotowsky @albeanth |
Is there anyway we can give a deadline for folks to chime in on this? Then after the deadline we yank out the geom files and be done with it. |
Back in the day, we used to specify core layout in what was called a facemap or geom file. While we retain the code that supports this input mechanism (see https://github.com/terrapower/armi/blob/master/armi/reactor/systemLayoutInput.py), it is mostly there to enable the migration performed here:
armi/armi/reactor/blueprints/__init__.py
Line 524 in 190c0ca
Instead we recommend using grid blueprints instead. However, when these were completely separate input files, they became part of some major ARMI function signatures where input stuff gets passed around, usually as
geom
. We should try to remove as many of these as we can.Actually searching around, I'm not seeing as many as I remember (go us!), but a glaring example is in the Case class:
armi/armi/cases/case.py
Line 73 in 190c0ca
The text was updated successfully, but these errors were encountered: