ParsedAux with material properties

[Jesse Carter]

Hi all -

I want to essentially do a ParsedAux AuxKernel to compare the relative contributions of the different terms in my PDE's and those terms contain material properties. The terms may look something like mat_prop_1*var_1*var_2 (could be nonlinear) or grad(mat_prop_2*grad(var_3)) (diffusion).

Is there a way to use the ParsedAux kernel or something like it where the parsed function can directly use material properties?

Alternatively I could make AuxVariables using the Material*Aux kernels and use those as args in the ParsedAux (right?), but that would require making an AuxVariable for each material property, and an AuxKernel for every term in the PDE. That may be a lot of work for a large system.

Can anyone suggest some guidance as to how to proceed? Are there any hazards associated with this idea? Just a thought, but if a material property depends on some non-linear variable, then creating a monomial as an intermediate to hold that material property might not be the best idea since the integral of the product of two functions is not the same as the product of the of the integrals of the functions by themselves (the integral in this case is for computing the average value over the element for the monomial).

Looking forward to your thoughts. Thanks.

   - Jesse

[Daniel Schwen]

Hey Jesse,

Take a look at ParsedMaterial and just use 'outputs = exodus' in the material block. ParsedMaterial can couple in MaterialProperties I wrote it for this purpose and use it all the time for similar purposes.

Daniel

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/d03593cd-25ce-48fa-83bf-1e1e529bd3c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Derek Gaston]

Are you ultimately looking for something like the norm of the difference between terms in your equation?

If so... just make a Postprocessor that couples in all of the variables and materials and computes it directly.  That will be the most accurate... and there's no reason to beat around the bush trying to do things in the input file when you can just write a bit of code to get it done correctly.

I would recommend inheriting from ElementIntegralVariablePostprocessor ( https://github.com/idaholab/moose/blob/devel/framework/include/postprocessors/ElementIntegralVariablePostprocessor.h ) and overriding computeQpIntegral() to compute whatever it is you want to compute.

Look at ElementL2Norm or ElementL2Error as examples.

Derek

--

[Derek Gaston]

If you are looking for an AuxKernel that computes the difference between terms per element and produces an Auxiliary field then just make an AuxKernel that operates on an Elemental AuxVariable that couples in all the right stuff and computes the value you want.

Derek

[Daniel Schwen]

Nah, I'm not convinced. We are not "beating around the bush" here, but using a modular solution. What if knowing the postprocessor norm is not enough because he needs to dig into the spatially resolved data to figure out which elements of his simulation contribute most to the norm. You are better off having the difference computation in a material class then and just use a stock PP.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAFfxPjp4KBNN7bMOMNdOtR%3DgzQdF%3Dm6Zc5JOSEZDseM8nNJTpQ%40mail.gmail.com.

[Derek Gaston]

That's what an AuxKernel is for.

A Material shouldn't be doing non-Material calculations.

Separation of responsibilities.

An object should have one (and only one) purpose.

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPxoKqfeQjisU3XfTE9gm%3DHxmPJB1bVELD3XeFZVDpDnq_bNLg%40mail.gmail.com.

[Daniel Schwen]

Yeah, I agree. It would be trivial to allow ParsedAux to couple to material properties. I'll put in an issue.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAFfxPjqQBw00rDGsJFJs0MRWLovb5jUxb5GdOr6iEuhV%2Bp6aNQ%40mail.gmail.com.

[Derek Gaston]

No: We don't need more Parsed stuff!

MOOSE was designed to make it easy to write code.  JUST WRITE CODE!

The entire Aux system was designed to exactly what Jesse was asking for.

In 5 minutes he could couple to everything he needs and compute exactly what he's looking for.

We need to quit suggesting that everyone writes whole applications in their input files and pushes and pulls fields around Materials, AuxVariables, Postprocessors, Functions, Control Logic, etc. when they could just write 10 lines of code and do what they need to!

Functions are NOT supposed to use quadrature point data.  That is not their purpose (they are Functions of x,y,z and time).

The correct solution here is to write an AuxKernel.

Jesse: If you need any pointers on creating AuxKernels or if something isn't clear, pleas let us know.

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPxoKqcjAqUWVXghizhPp9dOiLi5BLxjSRjsBehqmw911oLpAw%40mail.gmail.com.

[Jesse Carter]

I was looking at things in terms of coding efficiency, as in, how much do I have to type to get this to work?

The Postprocessor gives me an idea of what term is dominating overall on a domain-average sense, while the AuxVariable would tell me where. Both are useful.

If I were to do these things manually, without some sort of "Parsed" kernel, I would need to make a different kernel or postprocessor for each term. That involves copying an existing one (who's going to write one from scratch), including both the source (.C) and header (.h) file. Change the code of the necessary function, then change parameters, constructor, and associated edits to the header file. Then change the object names in both files manually or some creative sed command, register the postprocessor... . And that's just for one term of many. I would be faster I think to just type out the functions I want to compute in the input file using some "Parsed" kernel, then view that directly or pass it to the postprocessor.

I'll give the ParsedMaterial a look. I didn't see it because it was the phase field module and I'm not doing phase field.

[Derek Gaston]

Hmmm - maybe I'm misunderstanding what you're after then.

Are you wanting to look at the relative sizes of the residual contributions produced by Kernels?

If so... then you want to use the 'save_in' feature of Kernels.  It lets you actually save the residual contributions from Kernels directly into AuxiliaryVariables so they can be inspected.  Multiple Kernels can contribute to the same field (the contributions are added) and a single Kernel can contribute to multiple fields.

This gives you the ability to not have duplicate code - but look at the relative sizes of the contributions from individual terms.

Here is an example:

https://github.com/idaholab/moose/blob/devel/test/tests/misc/save_in/save_in_test.i

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/2b659f18-1746-45d2-bab9-1604c1440a28%40googlegroups.com.

[Daniel Schwen]

MOOSE was designed to make it easy to write code.  JUST WRITE CODE!

Real life experience has shown us that using parsed materials in phase field has made it easier for users to rapidly develop new models.

 

Functions are NOT supposed to use quadrature point data.  That is not their purpose (they are Functions of x,y,z and time).

We are not talking about (parsed) MooseFunctions here, for those you'd be right. But materials and parsed materials are _absolutely_ supposed to be evaluated at QPs. 

The correct solution here is to write an AuxKernel.

The users have choices here. If the users want to do a quick one off test, I'd suggest a parsed material or aux kernel every time! If it is going to be a heavy use thing then writing code will be a better solution if only because it keeps the input file cleaner (performance improvements will be negligible).

[Derek Gaston]

On Tue, Sep 1, 2015 at 5:25 PM Daniel Schwen <dan...@schwen.de> wrote:

Real life experience has shown us that using parsed materials in phase field has made it easier for users to rapidly develop new models.

That has more to do with the ability to do automatic differentiation than anything else.  Which, granted, automatic differentiation is AWESOME so I totally undestand.  If we had the ability to do it in code though... then I would suggest that every time.  Sadly, we do not... so using "Parsed" stuff is currently a better way to do phase field.

Jesse: I hijacked your thread here.  Let us know if you need anything further I'll try to restrain from getting on a soap box ;-)

Derek

[Daniel Schwen]

granted, automatic differentiation is AWESOME so I totally undestand.  If we had the ability to do it in code though... then I would suggest that every time.  Sadly, we do not... so using "Parsed" stuff is currently a better way to do phase field.

One last reply: We _do_ have a way to do this in code: ExpressionBuilder. Check out moose/modules/phase_field/include/materials/MathEBFreeEnergy.h for example. 

We have _way_ more complex examples in MARMOT, where we implemented full page walls of equations from papers. Those would have been _very_ messy to plug into input files.

Daniel

[Jesse Carter]

What I'm after is evaluating and comparing the magnitude of the terms in the PDE. So if I had du/dt = A + B + C, and something similar for dv/dt, and A, B, and C were nonlinear terms which included material properties (maybe A=mat_prop1*u*v, and so on), then after converting over to the weak form and solving, it is important for me to go back and see not only which term dominates and where, but to see what the actual value of that term is (is it 1 or 100?).

To do this I created 3 kernels for A, B, and C, provided they aren't already included in moose, then perhaps D and E or the dv/dt equation. We're up to 5 kernels. Maybe I'm wrong but the contributions of each these kernels to the residual is not the same in magnitude as the value of the original term itself - though they are probably proportional, given a uniform mesh etc. So if I wanted to see what A through E look like, that's 5 AuxKernels I have to make. That's 10 files I have to create/edit: 5 x .C files, 5 x .h files and the then main App.C file to register them all. Compare that to just typing out the terms I want into some "Parsed" kernel in the input file. Well it would be 5 Parsed kernels but all the edits are confined to one file.

[Daniel Schwen]

An even sweeter approach would be to use DerivativeParsedMaterial for A through E and create a generic kernel that pulls in A through E and the automatically generated derivatives to compute residuals and Jacobian entries! That is basically what we do in phase field.
Daniel

--

You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/6539fe7f-e018-47e7-b4dd-c9a91f70c3da%40googlegroups.com.

[Derek Gaston]

Now you're just screwing with me ;-)

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPxoKqd_Rm%2Bt4jovyoHK6iJSagFskB4jSsxWep%2BFxYgA3yp%2BSg%40mail.gmail.com.

[Jesse Carter]

So what do you do if you're *not* in phase field? :)

[Roma Gurung]

I am so happy to read a very useful discussion by the MOOSE experts. 

Recently, I am trying to write two material properties Diffusivity(coefficient D in Diffusion term) and Electrical Resistivity (coefficient rho in Advection term) as a function of Temperature. So, i need to couple concentration(c) of convection diffusion equation with temperature variable(T) of  transient heat conduction equation with Joule heating (Heat Source). Learning from the phase field model about Parsed Material and Derivative Parsed Material(http://mooseframework.org/wiki/PhysicsModules/PhaseField/DevelopingModels/FunctionMaterials/), i think i can describe D(T) and rho(T) using Derivative Parsed Material. 

To do this we have to make sure that the following should be made sure in Makefile of our application:

ALL_MODULES := yes

or exclusively,

PHASE_FIELD := yes

In effect, we are using the function/material library of Phase Field Module in the coupled set of convection-diffusion and transient conduction equations.

I am grateful to MOOSE team for the wonderful design in MOOSE framework software.

Yours Sincerely,

Anil Kunwar 

[Roma Gurung]

If we have exclusively mentioned PHASE_FIELD := yes in the Makefile, this module App should also be registered in the Appname/src/base/MyApp.C as

# include "PhaseFIeldApp.h"

...

and so on...

replacing 

ModulesApp ..

with 

PhaseFieldApp...

and other associated modules names.

Yours Sincerely,

Anil Kunwar

[Cody Permann]

Anil,

I'm not sure if this is a question or a feature request/bug report. Did you figure out the right changes in your Makefile and App file? I agree this isn't the best design since it does require the user to make two corresponding changes in order to change the module. It's trickier than you think since we need this to work on staticly linked systems. If we only had to worry about dynamic linking, I'd have a much better system in place.

Cody

Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/4df426cf-57f4-43e9-8974-8284beec26eb%40googlegroups.com.

[Roma Gurung]

Hi Cody,

I was not writing a question nor a feature request/bug report. I was just making an illustration on the use of the available features within MOOSE framework. For example, if someone is not working on Phase Field module, and wants to used the Parsed Material or Derivative Parsed Material library of Phase Field Module, then in this condition, the knowledge that these codes libraries exist in Phase Field Module is quite helpful. Those libraries can be used in the syntax of MOOSE input file without the prior knowledge of Phase Field Method.

As an example, if the makefile of application is like this:

https://github.com/anilkunwar/danphe/blob/master/Makefile

i,e, ALL_Modules := yes,

the Parsed Material or Derivative Parsed Material libraries can be accessed directly. 

If it is like this, 

https://github.com/SudiptaBiswas/Crow/blob/master/Makefile,

then a similar registration style has to be made in src/base/MyApp.C for each individually specified modules of MOOSE

https://github.com/SudiptaBiswas/Crow/blob/master/src/base/CrowApp.C

I wrote the things in order to illustrate how we can access the libraries of some modules , which may have the Physics implementation while we are working in some other modules.

What exactly do you mean by static linking and dynamic linking?

Yours Sincerely,

Anil Kunwar

[Cody Permann]

Rather than give you a synopsis on the mailing list. I'll just point you to a hit on the differences:

http://stackoverflow.com/questions/1993390/static-linking-vs-dynamic-linking

Basically as a framework, we need to support both modes of operation for maximum portability.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/46931e52-3277-41a7-8ea4-589323faae63%40googlegroups.com.