Create custom TMAP syntax #8
Comments
|
My general approach here is to modify THM-like input and objects, and modify as appropriate to capture necessary TMAP input and terminology. I'm still looking at BCs and "heat transfer" components in THM and figuring out what their mass transfer analogues should be in TMAP, but here's what enclosures and structures should look like: registerMooseObject("TMAPApp", Enclosure);
InputParameters
Enclosure::validParams()
{
params.addRequiredParam<std::string>("type", "Enclosure type ('functional' or 'boundary')");
params.addRequiredParam<std::string>("material", "Fluid material name");
params.addRequiredParam<FunctionName>("volume", "Volume of enclosure [m^3]");
params.addRequiredParam<FunctionName>("temperature", "Enclosure temperature [K]");
params.addRequiredParam<FunctionName>("pressure", "Enclosure pressure [Pa]");
params.addParam<FunctionName>("D_h", "Hydraulic diameter [m]"); // required if mass transfer correlation is to be used
params.addRequiredParam<std::vector<unsigned int>>("n_axial_elems", "Number of elements in each subsection along the main axis");
return params;
}
registerMooseObject("TMAPApp", PlateStructure);
InputParameters
PlateStructure::validParams()
{
params.addRequiredParam<std::vector<unsigned int>>("n_axial_elems", "Number of elements in each subsection along the main axis");
params.addParam<std::vector<Real>>("length", "Length of each axial section of the structure [m]"); // optional, for mass transfer
params.addRequiredParam<std::vector<Real>>("depths", "Depth of each transverse region [m]");
params.addRequiredParam<std::vector<unsigned int>>("n_depth_elems", "Number of elements of each transverse region");
params.addRequiredParam<std::vector<std::string>>("materials","Material name for each transverse region");
params.addParam<Real>("mult", 1.0, "Structure multiplicity; Number of identical structures represented by this one");
params.addRequiredParam<Real>("area", "Surface area of the plate [m^3]");
params.addParam<FunctionName>("initial_T", "Initial temperature [K]");
return params;
}
registerMooseObject("TMAPApp", CylindricalStructure);
InputParameters
CylindricalStructure::validParams()
{
params.addRequiredParam<std::vector<unsigned int>>("n_axial_elems", "Number of elements in each subsection along the main axis");
params.addParam<std::vector<Real>>("length", "Length of each axial section of the structure [m]"); // optional, for mass transfer
params.addRequiredParam<std::vector<Real>>("depths", "Depth of each radial region [m]");
params.addRequiredParam<std::vector<unsigned int>>("n_radial_elems", "Number of elements in each radial region");
params.addRequiredParam<std::vector<std::string>>("materials","Material name for each radial region");
params.addParam<Real>("mult", 1.0, "Structure multiplicity; Number of identical structures represented by this one");
params.addParam<FunctionName>("initial_T", "Initial temperature [K]");
// Both of the following optional; omission implies solid cylinder. For annulus (i.e. pipe), at least one required.
params.addParam<FunctionName>("inner_radius", 0., "Inner radius of the heat structure [m]");
params.addParam<FunctionName>("outer_radius", "Outer radius of the heat structure [m]");
return params;
}
registerMooseObject("TMAPApp", SphericalStructure);
InputParameters
SphericalStructure::validParams()
{
params.addRequiredParam<std::vector<Real>>("depths", "Depth of each radial region [m]");
params.addRequiredParam<std::vector<unsigned int>>("n_radial_elems", "Number of elements in each radial region");
params.addRequiredParam<std::vector<std::string>>("materials","Material name for each radial region");
params.addParam<Real>("mult", 1.0, "Structure multiplicity; Number of identical structures represented by this one");
params.addParam<FunctionName>("initial_T", "Initial temperature [K]");
// Both of the following optional; omission implies solid sphere. For spherical shell, at least one required.
params.addParam<FunctionName>("inner_radius", 0., "Inner radius of the heat structure [m]");
params.addParam<FunctionName>("outer_radius", "Outer radius of the heat structure [m]");
return params;
} |
|
@humrpw the way you've drawn things up here makes me intuitively think of an input file that looks like this: So that looks like a THM type input file. Alternatively you could have be the outer syntax. Which would you prefer? |
|
First one is good. I'm inclined to adopt THM-like input unless there's a particular reason not to. Plus this option gives flexibility to organize components within an input file in whatever order you like (not enclosures in one block, and structures in another block). |
|
Awesome. Option 1 was my preference |
|
This will mean we will need THM as a submodule in order for this to work, but I think that's totally fine. I also think @andrsd was considering moving |
|
Yes, the THM-like syntax would be better, IMO. Just keep in mind that refactoring the Component layer into a separate module would be a fairly large task. But, very useful, I think... |
|
Flows between enclosures we could handle one of two ways. Since these are always just user specified and therefore require little input, we could just make them part of enclosure blocks as in legacy TMAP: This is probably the most compact way to capture this input. But, if desirable or necessary for compatibility with THM, we could make this a separate component: |
|
This syntax won't work: You cannot specify one parameter multiple times. Also mixing parameter types makes it harder on the coding side - for example error handling, etc. However, you could do something like this: Just FYI. For your second example: You can do groups like Note that if you are specifying a component is has to have a This is what we would do with flow channels and junctions. Actually, we would have just one junction connecting the right ends of |
|
Ok @humrpw I've taken the first run at creating and then the What do you think? |
|
Notes which @humrpw can edit/add-to:
|
|
If you would also have a case where Just an idea... |
|
@singhgp4321 initial work done on this branch https://github.com/lindsayad/TMAP8/tree/syntax-8 for component syntax development |
Re-create val-1a test with components refs idaholab#8
…gPhysics live there Rework 1D structure to use a DiffusionPhysics refs idaholab#8
We want TMAP8 to feel like previous TMAPs, which means it should feel like a system code. In the MOOSE world probably the most similar comparison is THM. So we need to figure out what our blocks should be titled and look like. We will track our progress here.
@humrpw do you want to weigh-in on what you want the blocks to be? Should I simply copy all the block headers from the TMAP4 manual?
The text was updated successfully, but these errors were encountered: