Heat structure material improvements

[moosebuild]

Imported from idaholab/thm#163 by @andrsd at Nov 24, 2020 04:16PM MST

Mentioned merge requests:

• Using ADVariableValue in Materials (!528)
• Allow heat structure cylindrical and plate to use Materials syntax (!540)

---

Enhancement Description

This would perform a number of changes to the heat structure materials classes:

• [ ] Make new base class from SolidMaterialProperties (call it SolidProperties) defining properties API:
  • rho(T, point)
  • cp(T, point)
  • k(T, point)
• [ ] Rename SolidMaterialProperties to FunctionSolidProperties.
• [ ] Rename SolidMaterial to SolidPropertiesMaterial.
• [ ] Rename HeatStructureMaterials syntax to SolidProperties.

Enhancement Rationale

The feature changes are the following:

• Add the ability to have spatial dependency in solid properties. This is similar to the ability to have radially varying properties; a solid region can have a varying material composition along its length.
• Add the ability to define new classes for defining properties in ways other than supplying Functions. One disadvantage of being bound to Functions is that the Jacobians cannot be captured correctly when there is temperature dependence, but the proposed flexibility can remedy this. For example, one could make the class SS304SolidProperties that defines SS304 properties so that users do not need to look up all of the properties of SS304, which can be error-prone.

The renaming changes are suggested to be parallel to the FluidProperties structure.

Possible Enhancement Impact

Some syntax would need to be deprecated.

[moosebuild]

Imported from idaholab/thm#163 by @andrsd at Nov 24, 2020 04:23PM MST

---

@andrsd I wanted to get your input on this before I started. At the very least, I'd like to achieve the additional functionality mentioned here, for the models I'm implementing in Sockeye.

By Hansel, Joshua E on 2020-11-24T23:23:09 (imported from GitLab project)

[moosebuild]

Imported from idaholab/thm#163 by @andrsd at Nov 30, 2020 08:55AM MST

---

You are right that the support for heat structure materials needs to be improved, but I don't think this is the right direction.

Some time ago, April Novak was trying to build a SolidProperties module for MOOSE (it might still be somewhere) which had a parallel approach to what we do with fluid properties. There was a positive feedback from the user base, but it was decided that we need to submit that 810 questionnaire - which I did, but IDK what happened after that. Most likely, it got stuck somewhere. In ideal case, we should be aiming towards that kind design. Maybe we could look at the PR and see how to use it.

To me, the HeatStructureMaterials is basically obsolete and needs to be completely replaced with something that allows much greater flexibility. Or maybe we keep it around for quick and dirty prototyping. Also, we should be respecting the underlying design in the heat_conduction module, since we build on top of that. Any bigger deviations from it will bring big problems in future - and we want to avoid that as much as possible. The one thing in particular is that HC module in MOOSE splits the 3 material properties (rho, cp, k) into 2 materials, one for rho and one for cp and k. I am not a big fan of that, but there was some good reason for that - I remember the design started with specifying all 3 properties in one material.

Also, the ability to specify a material from a database (as in "I want to use SS316") would be nice and I am in support of that. I am not sure if April solved that problem somehow in her PR, but the biggest problem with solid properties was that they can depend on arbitrary variables (T, burnup, and IDK what else).

By Andrs, David on 2020-11-30T15:55:22 (imported from GitLab project)

[moosebuild]

Imported from idaholab/thm#163 by @andrsd at Nov 30, 2020 08:58AM MST

---

One more thing, I was already thinking about this improvement, because I will need a lot of flexibility for the NASA setup with flow channels and 3D heat structure, but I don't have a clear idea what I need and how I want users to do that in the input file...

So, I am still thinking about this...

By Andrs, David on 2020-11-30T15:58:44 (imported from GitLab project)

[moosebuild]

Imported from idaholab/thm#163 by @andrsd at Nov 30, 2020 09:50AM MST

---

the biggest problem with solid properties was that they can depend on arbitrary variables (T, burnup, and IDK what else)

This to me suggests that perhaps there is not a single API for computing these properties: the API should depend on the application. That in turn suggests that maybe this shouldn't be something defined at the MOOSE level but that each application should just have its own system.

By Hansel, Joshua E on 2020-11-30T16:50:32 (imported from GitLab project)

[moosebuild]

Imported from idaholab/thm#163 by @andrsd at Nov 30, 2020 10:48AM MST

---

...there is not a single API for computing these properties...

Correct, there is not a single API.

...this shouldn't be something defined at the MOOSE level...

Well, at MOOSE level, you don't have this problem. You build your material classed, you bring all stuff you need into it, and you build the input file accordingly.

The problem at THM-based application (non-THM apps do not have this problem) level is that you don't know what kind of dependencies users want/will want. Then, with every new combination you start wrapping stuff so it fits into your API.

Therefore, ideally, we would not wrap anything and we would use the Material system where this problem does not exist...

By Andrs, David on 2020-11-30T17:48:52 (imported from GitLab project)

[moosebuild]

Imported from idaholab/thm#163 by @andrsd at Nov 30, 2020 11:12AM MST

---

Therefore, ideally, we would not wrap anything and we would use the Material system where this problem does not exist...

Yeah, this is definitely the most flexible solution here. I'm guessing the original design in THM was to make it a little easier for the user, since otherwise they need to do the following:

• write their own material for temperature-dependent properties instead of using all of the different Functions already available. Maybe with ParsedMaterial this is not needed so much anymore.
• name properties according to our convention or pass those material properties to the heat structure.

• provide the right block for the material, according to our block naming convention.

  By Hansel, Joshua E on 2020-11-30T18:12:09 (imported from GitLab project)

[moosebuild]

Imported from idaholab/thm#163 by @andrsd at Nov 30, 2020 11:30AM MST

---

Another note is that with our current system in THM, we don't even get Jacobians if there is temperature dependence.

I'm in favor of moving to Materials and skipping the middleman.

By Hansel, Joshua E on 2020-11-30T18:30:47 (imported from GitLab project)

[moosebuild]

Closed at Aug 02, 2021 11:20AM MST.