Export to MOOSE

[GiudGiud]

@cticenhour @simopier Exporting to MOOSE and MOOSE-based apps (TMAP8..) could be done through the input file in a variety of ways. We could have directly the whole MOOSE syntax output. Or just the difficult part (like the CSV file)

This would be a substitute to coding in C++ a library which we can link from a MOOSE code.

A few options:

• MOOSE can read parsed/analytical expressions as ParsedFunction or as ParsedMaterial The first one is usually for f(x,y,z,t) a function but some materials pass other arguments to the functions like f(temperature, pressure) instead. Careful that most materials do f(x,y,z,t), especially GenericFunctionMaterial The second one can couple in variables (temperature, pressure etc), other material properties, integral quantities etc. https://mooseframework.inl.gov/source/functions/MooseParsedFunction.html https://mooseframework.inl.gov/source/materials/ParsedMaterial.html Example 1 ParsedFunction

  [Functions]
  [k_func]
  type = ParsedFunction
  value = sin(pi*x) + 0.5
  []
  []
  [Materials]
  [./heat]
  type = HeatConductionMaterial
  block = 1
  temp = temp
  thermal_conductivity_temperature_function = k_func
  specific_heat_temperature_function = c_func
  [../]
  []

  Example 2 ParsedMaterial

  [Materials]
  [phasemap]
  type = ParsedMaterial
  f_name = phase
  args = 'eta2 eta3'
  function = 'if(eta3>0.5,1,0)-if(eta2>0.5,1,0)'
  outputs = exodus
  []
  []

• Functions may be defined from their x and y data. This is the most convenient when an analytical function/correlation does not exist. For example:

  [Functions]
  [k_function]
  type = PiecewiseLinear
  x = '0 1 2'
  y = '4 5 7'
  [../]
  []

• Tabulated or CSV data Example 1 with CSV data for a piecewise linear data

  [Functions]
  [k_function]
  type = PiecewiseLinear
  data_file = piecewise_linear_columns.csv #Will generate error because data is expected in rows
  [../]
  []
  [Materials]
  [./heat]
  type = HeatConductionMaterial
  block = 1
  temp = temp
  thermal_conductivity_temperature_function = k_func
  specific_heat_temperature_function = c_func
  [../]
  []

  Example 2 with tabulated data in a CSV file. This is for fluid properties

  [FluidProperties]
  [./co2]
  type = CO2FluidProperties
  [../]
  [./tabulated]
  type = TabulatedBicubicFluidProperties
  fp = co2
  interpolated_properties = 'density enthalpy viscosity internal_energy k c cv cp entropy'
  # fluid_property_file = fluid_properties.csv
  save_file = true
  construct_pT_from_ve = false
  construct_pT_from_vh = false
  # error_on_out_of_bounds = false
  
  # Tabulation range
  temperature_min = 280
  temperature_max = 600
  pressure_min = 1e5
  pressure_max = 3e6
  
  # Newton parameters
  tolerance = 1e-8
  T_initial_guess = 350
  p_initial_guess = 1.5e5
  [../]
  []

[RemDelaporteMathurin]

@GiudGiud

These H transport properties are most of the time (if not always) Arrhenius laws evolving with temperature only as:

D = D_0 * exp (-E_D/k_B/T)

where D_0 is the pre-exponential factor, E_D is the activation energy, k_B is the Boltzmann constant and T the temperature.

An Arrhenius property is therefore completely defined by the pre-exponential and activation energy.

So I think the functionnal approach is the way to go.

@stephen-dixon you are using such properties too, would you have anything to add?

[stephen-dixon]

Hey Remi. yeah I generally just hand code the pre-exponential factors and activation energies into the input files and have material objects that calculate Arrhhenius law properties from them. If I were going to automate it for simple calculations I think I'd prefer a json export of your DB and I could either have a quick pre-processor in python, or add a helper class in moose to read the json and extract the data from a named material directly (moose already inlcudes a great c++ json library). Part of the moose philosophy seems to be that any peripheral functionality not directly involved in actually running the simulation (the test framework, the input interface, visualisation, etc.) is all handled in python and my feeling is that json is already a first-class data object in python.

But the quickest way to integrate something moose-specific I guess would be either the csv dump that can be used immediately without any adapters on the moose side, or a list of copy-pasteable ParsedMaterial HIT (moose input) blocks.

One comment on the csv input is just that I think it will be linearly interpolated so you may have to have a lot of data-points? I kind of feel that calculating the function is better, especially as function parsers exist in the input system.

if you were generating moose-syntax material blocks directly I think they'd look a bit like this below (arrays are space-delimited lists). Personally I'm trying to hard-code the Arrhhenius relations under the hood in my app so I can just accept the input variables (D0, E, and lists of trap properties) in the input file. So, although I probably wouldn't use it in this format, it could be nice and immediately useable for other moose users in general? Could also be worth checking with the TMAP8 team what format they'd find most useful?

[unique_name]
    type = ParsedMaterial
    f_name = D
    function = 'D0 * exp(- E/(kb*T))'
    constant_names =          'D0   E     kb'
    constant_expressions = '1.0   0.0  8.6e-5'
    args = T
 []

[RemDelaporteMathurin]

Following up on this, we now have an automatic upload of the whole database (entries with all attributes) to a standard JSON file.

The dataset is compiled and attached to the release

I believe this can solve most integration issues as JSON files are very easy to work with and can be used by any application.

What are your thoughts? @GiudGiud @stephen-dixon

[stephen-dixon]

Love it!

[GiudGiud]

We have a JSON reader in MOOSE. Now I think we just need to write a MaterialFromJSON or something more specialized.

I have only skimmed the first few entries, there is a temperature dependence and then the selection of material / author / etc, right?

[RemDelaporteMathurin]

Yes. Each entry (property) is follows an Arrhenius law.

Entries are defined by two Arrhenius parameters (a pre-exponential factor and an activation energy), a material, a temperature range, referencing attributes (source, author, year, doi, etc...).

@cticenhour @simopier feel free to add if I forgot anything

[GiudGiud]

I could see a JSONReader user object that internalizes the JSON file as some sort of map (though maybe that s a little difficult because of the types, we ll see, later C++ versions have some flexibility there)

then a Material1DFromJSON that can access that directory at the right keys and read a 1D profile of a coefficient wrt to temperature.

[RemDelaporteMathurin]

though maybe that s a little difficult because of the types

I think the types in the json files are rather standards: floats, strings, tables...

[GiudGiud]

Sounds good

@RemDelaporteMathurin just an update, we are figuring out what kind of funding we'll have on fusion work before getting started here. The end-of-FY wrap up is always heated too. But it will get done.

[RemDelaporteMathurin]

@GiudGiud no probs! I shall close this issue in the meantime and we can open it when needed.