Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

DenovoMP Dependencies List

Variables

Input variable names:


First set of command line args:

interactiveInput:Boolean

fileNameToCreate: String

userAnnularPellet: String


Define the geometry based on an experiment:

geometryFromAnExperiment: Boolean

neutronicsFromAnExperiment: Boolean


Get the multipin options and offsets:

multipin: Boolean

multipinFile: String

multipinData: ReadsFileIntoDatabase(multipinFile) Npins: Integer

xOffset: Integer

yOffset: Integer

zOffset: Integer

subchannel: Boolean

subchannelSize: Integer


Get the pellet geometries (Define to either use a predefined mesh file or define the clad and pellet):

PelletInfo.height =geomOBJ.PelletHeight

PelletInfo.meshFileName = geomOBJ.PelletMesh

PelletInfo.numElements = geomOBJ.elements[1]


CladInfo.meshFileName = geomOBJ.CladMesh

CladInfo.iradius = geomOBJ.CladRadiusIn

CladInfo.oradius = geomOBJ.CladRadiusOut

CladInfo.numElements_pellet = geomOBJ.elements[0]

CladInfo.material = geomOBJ.cladMaterial

PelletInfo.material = geomOBJ.pelletMaterial

PelletInfo.radius = geomOBJ.PelletRadius


PelletInfo.meshFileName = Util_IO.getStringValue( defaults, "pelletMeshName" )

PelletInfo.height = float( Util_IO.getStringValue( defaults, "heightOfFuel" ) )


Define the pellet and clad geometry/mesh/operator options: simPellets: Boolean


numPellets:


numPelletsStr: String

PelletInfo.height

PelletInfo.radius

PelletInfo.meshType

PelletInfo.meshFileName


PelletInfo.radMesh

PelletInfo.axMesh


simClad


CladInfo.meshFileName

CladInfo.meshType

CladInfo.iradius

CladInfo.oradius

CladInfo.height

CladInfo.radMesh

CladInfo.azMesh

CladInfo.axMesh


Thermal Options:

simTemp:Boolean

simTempOnClad:Boolean

simTempOnPellets: Boolean

cladOuterThrmalBoundaryDB: String

thermalDB: String

GapModelDB:String

useThermalDefaults:String


Options to allow input of lists of gap conductance values:

useTimeH: Boolean

updatingGapHdB: String

updatingGapHdB: String

updatingGapHdBList: String?


Updating Gap Conductance Model with experiment specific geometry info:

This place does some logical statements with the GapModelDBList.


Determine if using a gap model or commenting out the reference:

useGapModel: Boolean


simOxide:Boolean


Mechanical Options:


simDisp:Boolean

simDispOnPellets: Bollean

simDispOnClad: Boolean

numberOfLoadingSteps: int


mechanicsDBList:List

pointLoadDBList:List

usePointLoad:Boolean

numberOfLoadingStepsStr: String

numberofLoadingSteps: int?


Solution Options:

useSolverDefaults:Boolean

domDecomp:Boolean

initGuessStr: String

initGuess:float

mechRefTempStri: String

mechRefTemp: float

thermalSolverDB

thermalSolverDBList:List


pelletMechanicsSolverDB cladMechanicsSolverDB


Edit Properties:

editPelletMAterials: boolean

editAllPelletMAterials:Boolean

materialString:String

PelletInfo.material = materialString


editCladMaterial:Boolean


Developer Interface: ?


There are a few local variables


Dependencies

Some notes: Default should probably mean, "Don't change the value". It would get chaotic if a value was adjusted due to a dependency, and then re-adjusted back to default if the default value can also be another value too.


default should be ignored as a forced change for the time being.


Some of these values are "Multiple parents, change value, then hide" kinds of scenarios. Eventually this will have to be specified for clarity as the dependency plugin process is developed.


There is still a chance that there will be cross dependencies. For example, say there are 3 elements A, B, C and listed in this order. Lets assume A depends on B and A depends on C (but A does not depend on B and C concurrently). With the way ICE works, it goes in the order of placement. In other words, C will be the final decider of a value adjustment on A, sometimes regardless of B.


Arguments before start:

interactiveInput: Boolean - Required to see if the program asks questions or is just fed input.

fileNameToCreate: String - File to be created upon completion. inputMultiPellet common name for it.

useAnnularPellet:


Database Path dependency- HAS TO EXIST

dataDirectory - list to DB.Defaults. ->renamed as defaults in the prog


If geometryFromAnExperiment (Generating Geometry from an experiment) is no, then neutronicsFromAnExperiment = no


If Npins >1 && len(xOffset) >1 && len(yOffset) > 1 then Grab subchannel


IF subchannel == y && if defaultSubchannelBoundaryDatabase == "database/DB.CladOuterThermalRobinBC" then

cladOuterThermalBoundaryDatabase == database/DB.CladOuterThermalSubchannelBC


If simTemp == y && simClad == n then

simTempOnClad = n

simTempOnPellets = default


If simTemp == y && simClad == y then

cladOuterThermalBoundaryDB = default

cladOuterThermalBoundaryDBList = default from cladOuterThermalBoundaryDB


If simPellets = y

simTempOnPellets = default

simTempOnClad = default

If simPellets = n

simTempOnPellets = n

simTempOnClad = default


This whole area deals with if simTempOnPellets == y && simTempOnClad == y

GapModelDB = default from GapThermalConductanceDatabase

GapModelDBList = GapModelDB

useTimeH = defaults from useTimeDependentGapH

updatingGapHdB = defaults from gapConductanceFile

useGapModel = defaults from useGapConductanceModel


if numPellets == 1

thermalDB = default from singlePelletAndCladThermalDatabase


if numPellets > 1

thermalDB = default from pelletsAndCladThermalDatabase


if useTimeH == y

updatingGapHdBList = updatingGapHdB into database


if (GapModelDBList name and P2C)[0] == GapConductanceModelRadial then

Thickness and radius inside P2C GapModelDBList should be replaced with

Thickness = PelletInfo.radius = CladInfo.iradius

radius = PelletInfo.radius


if(GapModelDBList, name, C2P)[0] == Gap ConductanceModelRadial then

Thickness and radius inside C2P GapModelDBList should be replaced with

Thickness = CladInfo.iradius - PelletInfo.radius

radius = CladInfo.iradius


This whole area deals with if simTempOnPellets == n && simTempOnClad == y


This whole area deals with if simTempOnPellets == y && simTempOnClad == n

if numPellets == 1

thermalDB = singlePelletOnlyThermalDatabase

if numPellets > 1

thermalDB = pelletsOnlyThermalDatabase


This whole area deals with if simTempOnPellets == n && simTempOnClad == n

simTemp = n


if simTemp = y

thermalDBList = read File into DB (thermalDB)


simTemp = y && simTempOnClad = y

thermalDBList.extend(cladOuterThermalBoundaryDBList)


simTemp = y && simTempOnClad = y && simTempOnPellets = y

thermalDBList.extend(GapModelDBList)


simTemp = y && simTempOnClad = y && simTempOnPellets = y && useGapModel == n

Util_IO.commentField( thermalDBList, "LocalModel", '"P2CThermalModel"' )

Util_IO.commentField( thermalDBList, "LocalModel", '"C2PThermalModel"' )


if simTempOnClad == "y" and simTempOnPellets == "n" or simTempOnClad == "n" and simTempOnPellets == "y"

Util_IO.commentField( thermalDBList, "LocalModel", '"P2CThermalModel"' )

Util_IO.commentField( thermalDBList, "LocalModel", '"C2PThermalModel"' )


if simTempOnClad == y

simOxide = default


if simTempOnClad = n

simOxide = n


This whole area deals with if simDisp = y

Something I noticed here: Many of these if statements do not change the value. And quite honestly, I think many of these could be a two parent relationship instead of 3. In other words, simDispOnClad and simDispOnPellets only care about their respective simClad and simPellets attrbiute and if simDisp is true. ~ SFH: 20121012 @ 2:49pm.


numberOfLoadingStepsStr = defaults numberOfLoadingSteps


if usePointLoad == y

pointLoadDB = from defaults

pointLoadDBList = readFileIntoDatabase (pointLoadDB)


if simClad = n

simDispOnClad = n

simDispOnPellets = default


if simClad = y && simPellets = y

simDispOnPellets = default

simDispOnClad = defaults


if simClad = y && simPellets = n

simDispOnPellets = n

simDispOnClad = default


This whole area deals with if simDispOnPellets = y && simDispOnClad == y && simDisp = y

if numPellets == 1

mechanicsDB = defaults from singlePelletAndCladMechanicsDatabase if numPellets > 1

mechanicsDB = defaults from pelletsAndCladMechanicsDatabase


This whole area deals with if simDispOnPellets = n && simDispOnClad == y && simDisp = y

mechanicsDB = cladOnlyMEchanicsDatabase


This whole area deals with if simDispOnPellets = y && simDispOnClad == n && simDisp = y

mechanicsDB = cladOnlyMechanicsDatabase


if numPellets == 1

mechanicsDB = defaults from singlePelletOnlyMechanicsDatabase

if numPellets > 1

mechanicsDB = defaults from pelletsOnlyMechanicsDatabase


if simDispOnPellets == n && simDispOnClad == n then

simDisp = n


if (simDisp = y) then

mechanicsDBList = readFileIntoDatabase (mechanicsDB)


if( simTemp == y) then

thermalSolverDB = defaults

thermalSolverDBList = readFileIntoDatabase(thermalSolverDB)


if simDispOnPellets = y

pelletsMechanicsSolverDB = defaults

pelletMechanicsSolverDBList = readFrileIntoDatabase (pelletMechanicsSolverDB)


if simDispOnClad = y

cladMechanicsSolverDB = defaults

cladMechanicsSolverDBList = readFrileIntoDatabase (cladMechanicsSolverDB)


if editPelletMaterials == y

editAllPelletMaterials = defaults

materialString - defaults

PelletInfo.material = materialString


      • Then go into the database and replace the word Material and Pellet with some random materialString???


if editCladMaterials == y

editAllCladMaterials = defaults

materialString - defaults

CladInfo.material = materialString


      • Then go into the database and replace the word Material and Clad with some random materialString???


This next section will create a neutronicsDatabase based on information provided previously. This assumes if the neutronicDB is not none


The following section assumes neutronicsDB != none and neutronicsFromAnExperiment == n


if simClad == y && simPellets == y

nfuel = numPellets

nclad = 1

if simClad = n && simPellets = y

nfuel = numPellets

nclad = 0

if simClad = y && simPellets = n

nfuel = 0

nclad = 1

if simClad == n && simPellets = n


nmeshes = nfuel + nclad


This is a section of code in the input generator. It makes more sense than to try to "section" it off. Important parts will be bolded

meshNameList = __
            if ( nfuel>0 ):
              meshNameList += '\"pellet_1\"'
              for i in xrange ( nfuel-1 ):
                meshNameList += ', \"pellet_' + str( i+2 ) +'\"'
            if ( nclad>0 ):
              if ( nfuel>0 ):
                meshNameList += ', \"clad\"'
              else:
                meshNameList += '\"clad\"'
            Util_IO.replaceField(neutronicsDBList, "meshNames", meshNameList)
            Util_IO.replaceField(neutronicsDBList, "sizPowerShapes", str( nmeshes ) )
 
            powers =      Util_IO.getFieldValues(neutronicsDBList, "powerMagnitudes")
            ntimes = int( Util_IO.getStringValue(neutronicsDBList, "numTimeSteps") )
 
            if (len(powers)


Everything else writes things to a file. Will get back to on a later date.

Types of Dependency Classification

Documenting the types of behavior is one of the ways to map the different values and how they handle on the GUI portion in ICE. Most of these variables have a tendency to be not only multi-parent, but also require the values to be tweaked based upon their parent's state.

  • Single-Parent enabling/disabling view of child. This piece requires that if the parent is "True" or "enabled", the child should be shown on the GUI.
  • Single Parent Opposite enabling/disabling view of child. This piece requires that if the parent is "False" or "disabled", the child should be shown on the GUI.
  • Multiple Parent enabling.disabling view of child. This piece requires that if both parents are "True" or "Enabled", the child should be shown on the GUI.
  • Multiple Parent Opposite enabling.disabling view of child. This piece requires that if both parents are "false" or "disabled", the child should be shown on the GUI.
  • Single-Parent manipulating the current value of a child. This piece states that the child's value could be manipulated by parent's current state. In this case, this could be a string editing or string replacement.
  • Single-Parent manipulating the current value of a child computationally. This piece states that the child's value could be manipulated by parent's current state. In this case, this could be overriding the default values with an adjustment value.

Coding ideas: Having to override "Entry" for each individual piece will be tiresome and EXTREMELY tedious. There probably needs to be a way to rework the stylistic approach of these types to incorporate some kind of "multiple-chain reaction" or possibly a way to utilize "the decorator" pattern for dependency handling.

Back to the top