You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In #179, @samgdotson pointed out the implementation pulling from two databases, with one being implemented by hand, is not the most pythonic way to accomplish this goal.
The LWR .xml files automatically generated in scenarios/triso/deployment_calcs/ rely on the EIA database, which does not contain power. You can pull the power from the PRIS database, but they use different names for the reactors.
Describe the feature you'd like.
Currently, the powers are stored in a dictionary that I implemented by manually putting the power for each reactor from PRIS. The feature we would like is for the incorporation of the power to be programmatic not by hand.
Describe alternatives you've considered.
Another alternative would be to find a different database that contains all of the information required for the reactor archetypes, I have not found such a database.
A user could also flip this process and pull the reactors from the PRIS database and fill in with the EIA database. This does not solve the issue.
Additional context.
The reason I am pulling from this specific database is that it includes the most complete set of the information needed (state, license exp, start year, close year, type, vendor, name, core size) for the Cyclus files I am trying to generate--it also uses a name format I like the most, PRIS abbreviates the names in ways I don't think are always clear. Unfortunately, that does not include the power, latitude/longitude, assembly size, cycle time, or refuel time. Some of these are reasonable to assume (refuel time and cycle time, for example) and latitude/longitude are not required for function of the reactors in the simulation, but power is for sure required. As such, I have copied the powers from PRIS and stored them in the database.
How can this issue be closed?
This issue can either be closed by a PR that implements a fully programmatic version of the current code, or the determination that the method, as implemented, is sufficient.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
In #179, @samgdotson pointed out the implementation pulling from two databases, with one being implemented by hand, is not the most pythonic way to accomplish this goal.
The LWR
.xml
files automatically generated inscenarios/triso/deployment_calcs/
rely on the EIA database, which does not contain power. You can pull the power from the PRIS database, but they use different names for the reactors.Describe the feature you'd like.
Currently, the powers are stored in a dictionary that I implemented by manually putting the power for each reactor from PRIS. The feature we would like is for the incorporation of the power to be programmatic not by hand.
Describe alternatives you've considered.
Another alternative would be to find a different database that contains all of the information required for the reactor archetypes, I have not found such a database.
A user could also flip this process and pull the reactors from the PRIS database and fill in with the EIA database. This does not solve the issue.
Additional context.
The reason I am pulling from this specific database is that it includes the most complete set of the information needed (state, license exp, start year, close year, type, vendor, name, core size) for the Cyclus files I am trying to generate--it also uses a name format I like the most, PRIS abbreviates the names in ways I don't think are always clear. Unfortunately, that does not include the power, latitude/longitude, assembly size, cycle time, or refuel time. Some of these are reasonable to assume (refuel time and cycle time, for example) and latitude/longitude are not required for function of the reactors in the simulation, but power is for sure required. As such, I have copied the powers from PRIS and stored them in the database.
How can this issue be closed?
This issue can either be closed by a PR that implements a fully programmatic version of the current code, or the determination that the method, as implemented, is sufficient.
The text was updated successfully, but these errors were encountered: