Difficulty creating a ADMatReactionNodalKernel class to use materials to define reaction rates

[simopier]

Initial question:

'I have been trying to create the ADMatReactionNodalKernel class because I think it would be very useful for TMAP8, but I am running into an issue that I have not been able to fix.

I updated conda and moose both this morning again, but when I try to ‘make’ TMAP8 with the new files, I get the following error:

Compiling C++ (in opt mode) /Users/simopa/projects/TMAP8/build/unity_src/nodal_kernels_Unity.C...
In file included from /Users/simopa/projects/TMAP8/build/unity_src/nodal_kernels_Unity.C:2:
/Users/simopa/projects/TMAP8/src/nodal_kernels/ADMatReactionNodalKernel.C:29:10: error: use of undeclared identifier 'getADMaterialProperty'; did you mean 'ADMaterialProperty'?
_mob(getADMaterialProperty("mob_name"))
^
/Users/simopa/projects/moose/framework/build/header_symlinks/MaterialProperty.h:339:7: note: 'ADMaterialProperty' declared here
class ADMaterialProperty : public MaterialPropertyBase<T, true>
^
1 error generated.
make: *** [/Users/simopa/projects/TMAP8/build/unity_src/nodal_kernels_Unity.x86_64-apple-darwin13.4.0.opt.lo] Error 1
make: *** Waiting for unfinished jobs....

I do not understand how to solve it. Looking at the ADMatReaction kernel, it also uses ‘getADMaterialProperty’ and I don’t see why it should be different here. Any suggestions?

Thank you!'

[simopier]

Answer:

'Nodal kernels won’t work with the current material system unfortunately. Materials are associated with subdomains, e.g. volumes. You can imagine that at an interface between materials, unless you specify an element side, the value of a material property can be discontinuous and worse undefined. What value for the property should be used? It could be even worse for a node: you could be at the corner of 8 subdomains for a hex mesh!

If it’s an expression you have, and your property is not a function of the nonlinear degrees of freedom, why not use a function parameter to keep the expression in the NodalKernel generic? The AD system can still handle the derivatives of that for you.

For the general question of kernel vs nodal kernel: let’s use the correct mathematical solution. If we don’t have spatial derivatives I think we should do nodal kernels. And as to the practical challenge of how we implement it (a function, a material, hard-coded in the kernel) let’s just do what’s quickest and easiest for now and I think in the future we will have better solutions (although a function still could be a great solution even going forward depending on your use case). For instance I have plans for doing on-demand property evaluation at any point in the domain. This would be a viable solution even when your property is a function of the nonlinear degrees of freedom.'

[lindsayad]

The action in Crane takes each reaction (in this case T2 + H2O → HTO + HT), parses the string into reactants and products, and automatically constructs the source and sink terms for each species. This does what you want to avoid, though, because each species has a new kernel added for every reaction it's involved in. It looks like you are trying to create a single kernel that calculates the total reaction rate for that species; is that right?

I think if we made an automated action process, we wouldn't really care how we compose this, e.g. one kernel per reaction or one kernel per species. The general MOOSE mantra is to be as modular as possible so by that criterion one kernel per reaction is the way to go.

@keniley1 ignoring for the moment that you're ultimately constructing Kernels, do you think your action parsing of the input file is general enough to be useful to us? Let's imagine that we somehow have a parameter that controls whether you create nodal kernels or kernels depending on the user's desire.

[lindsayad]

And let's also pretend for the moment that we have materials that work for both kernels and nodal kernels.

[keniley1]

@keniley1 ignoring for the moment that you're ultimately constructing Kernels, do you think your action parsing of the input file is general enough to be useful to us? Let's imagine that we somehow have a parameter that controls whether you create nodal kernels or kernels depending on the user's desire.

Yeah, at its most basic level Crane's action is just a string parser. It takes a string like this:

e + Ar -> e + e + Ar+ : {1e-9*Te^(-0.5)}

And splits that into individual reactions, reactants, products, how many of each are produced/destroyed in each reaction, and rate coefficients. (The rate coefficient is separated from the reaction with the ':' character.) That's all done very messily in ChemicalReactionsBase. All of that information is very general and doesn't depend on the mesh, variable types, (Nodal/Scalar)Kernels, etc at all.

[lindsayad]

Hmm. @cpgr do you do reaction parsing with any custom syntax in the chemical_reactions module? I'm thinking about how we can help Moose downstream applications the most here. I'm wondering whether it makes any sense to port the parser capability of @keniley1 into the chemical_reactions module. Even unary, binary, ternary type reaction objects should realistically belong in the chemical_reactions module.

[cpgr]

I think the regex parser in chemical reactions actions are similar to what is in crane. It too reads the reactions as a string, then adds all the appropriate objects.