Import data onto MOOSE generated mesh

370 views
Skip to first unread message

Mausolff, Alexander J

unread,
Jul 6, 2016, 4:14:14 PM7/6/16
to moose...@googlegroups.com
I am wondering what the best way to import external data on to a mesh generated by MOOSE.

For instance if I have some material information and a temperature I want associated with each node.

Thanks,

--
Zander J. Mausolff
INL Intern
Graduate Researcher from UF

Derek Gaston

unread,
Jul 6, 2016, 5:06:46 PM7/6/16
to moose...@googlegroups.com
Lots of options.  Depends on how your data is stored.  I'm going to assume that you can read your data file and query it at any x,y,z point...

1.  For Materials you can just read your external data file directly into custom Material and query your data using _q_points (which are the x,y,z positions MOOSE currently needs Material values at).

2.  For "field data" (like tempteratures) you will want to add an nodal Auxiliary variable and then create a custom AuxKernel that reads your data file and query's it at the _current_node (which contains the x,y,z position at which MOOSE is currently asking the AuxKernel for a value).

3.  A more advanced option for the Material is to read your data into a custom GeneralUserObject and provide an interface for querying it.  You would then use getUserObject() in a custom Material to get that GeneralUserObject and then you can call functions on it to get at the data from computeQpProperties().

4.  A more advanced option for "field data" is to write a custom Function that reads in your data and presents it to MOOSE as a Function that can be queried by any object at x,y,z and time.  You can actually then use FunctionAux to project that data into an AuxiliaryField if you want... or other objects can simply use getFunction() to get the Function and directly query its values.

There are even more options... really depends on how the data is stored and what type of data it is....

Derek

--
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 https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CANEQK5T5OKCwPnQ1VKGBd8iuFux%2BB4UUqL3d1K6vz-E1d215OA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Mausolff, Alexander J

unread,
Jul 7, 2016, 9:42:25 AM7/7/16
to moose...@googlegroups.com
I believe options 1 and or 2 will suffice.  
Would the best place to look for examples be under /moose/test/tests/transfers or /userobjects ?

Thanks!


For more options, visit https://groups.google.com/d/optout.

Derek Gaston

unread,
Jul 7, 2016, 10:38:56 AM7/7/16
to moose...@googlegroups.com
Transfers are not for this purpose. They are for moving data between MultiApps (which is a whole MOOSE thing for embedded solved... think multiscale).

Just look at the documentation / examples for creating Materials / Functions and using UserObjects. It should be clear how you can write your own data load routine and query your data at the right spots in those interfaces.

Maybe someone else can point out some code that's in a similar direction (maybe some of the image processing code?)

Derek

Mausolff, Alexander J

unread,
Jul 11, 2016, 7:48:41 PM7/11/16
to moose...@googlegroups.com
I am having trouble finding the image processing source code.. Is that handy somewhere?



For more options, visit https://groups.google.com/d/optout.

Cody Permann

unread,
Jul 12, 2016, 10:21:49 AM7/12/16
to moose...@googlegroups.com
The source is here: https://github.com/idaholab/moose/blob/devel/framework/src/utils/ImageSampler.C
but you probably don't really want to read through all that. Take a look at the usage instead through the test suite: https://github.com/idaholab/moose/tree/devel/test/tests/functions/image_function

Cody



Mausolff, Alexander J

unread,
Jul 14, 2016, 11:43:57 AM7/14/16
to moose...@googlegroups.com
One of Derek's suggestions was:

" 1.  For Materials you can just read your external data file directly into custom Material and query your data using _q_points (which are the x,y,z positions MOOSE currently needs Material values at). "

I am able to read in my data fine. The data is stored as follows (x, y, material_prop 1, material_prop 2, temperature, power density) in an array that I can query. 
The (x,y) coordinates amount to the nodal locations.

I tried to query the _q_points at the [_qp] position and compare that to the (x,y) coordinates. (* this is a simple cartesian 2D set of points)
But now realize that this is incorrect as the quadrature points are different than the nodal positions.

Should I be querying the nodal positions and assigning a material property to a _qp point?  If so whats the best way to get the nodal position corresponding to a _qp point.
Or are there better methods?

Thanks,



For more options, visit https://groups.google.com/d/optout.

Mausolff, Alexander J

unread,
Jul 14, 2016, 11:52:34 AM7/14/16
to moose...@googlegroups.com
Is there any problem with processing all of the data including "materials" like I would the field data as described in Derek's suggestion #2?
It seems I can query nodal positions easy in this manner, which corresponds well to how my data is laid out.  

" 2.For "field data" (like tempteratures) you will want to add an nodal Auxiliary variable and then create a custom AuxKernel that reads your data file and query's it at the _current_node (which contains the x,y,z position at which MOOSE is currently asking the AuxKernel for a value) "

The material data I need from my input file is the thermal conductivity for a simple 2D heat conduction problem.

Wang, Yaqi

unread,
Jul 14, 2016, 11:54:45 AM7/14/16
to moose-users
Why not load your data into nodal variables, i.e. variables in type of LAGRANGE? You can make a new IC for the data loading, query will happen in IC::compute(). Then MOOSE will do the interpolation for you on the quadrature point when needed plus you do not need to query on the fly.

Derek Gaston

unread,
Jul 14, 2016, 1:47:57 PM7/14/16
to moose-users
Why do you want your data at the nodal positions?  If it's going to be used as a material property then you want to query it at quadrature points in a Material.

Can you tell us what you're trying to do?  _What_ is the data and what is it going to be used for?

Derek

Mausolff, Alexander J

unread,
Jul 14, 2016, 2:26:11 PM7/14/16
to moose...@googlegroups.com
I tried something along the lines of what Yaqi suggested and it seems to work for importing temperature. 

The situation is I am trying to couple an external code with MOOSE.  For now MOOSE is just solving a heat conduction problem with the power density as a heat source.  
 I have this external code outputting a series of nodal positions in 2D and for each 2D position a corresponding, power density, thermal conductivity, and temperature.
The idea is MOOSE will calculate the new temperature and write that back out for the external code.  

The data doesn't necessarily have to be at the nodal positions but I am not sure how else to map from the external data to points on the MOOSE mesh.
My approach at the moment is to iterate over my data until the (x,y) data matches the current nodal point.  Then assign that point the required data.

 



For more options, visit https://groups.google.com/d/optout.

Derek Gaston

unread,
Jul 14, 2016, 2:36:18 PM7/14/16
to moose...@googlegroups.com
Power density and thermal conductivity should be accessed at _quadrature points_ in MOOSE.

I would evaluate them at quadrature points within a Material and then feed those values as material properties called power_density and thermal_conductivity to Kernels.

The HeatConduction Kernel from the heat_conduction module will automatically pick up the thermal_conductivity material property.

You will need to write a custom Kernel to use the power_density material property and apply it as a source term.

In the long run... you may want to look into wrapping your external application up in a custom MultiApp and writing custom Transfers to move the data back and forth.  But that's something to consider much later...

Derek

Mausolff, Alexander J

unread,
Jul 14, 2016, 3:25:53 PM7/14/16
to moose...@googlegroups.com
This does not seem to address how I can associate the external data with the data in MOOSE.
I am creating a mesh w/in MOOSE that has the same number of nodal points and coordinates as the one in my external solver. Then mapping the data between them. The relationship between the two is the nodal positions in (x,y).

Say I'm at some _qp , how is it going to know what values  to get from the external data? 

How do I associate an (x,y) point from my data to a quadrature point within MOOSE?


For more options, visit https://groups.google.com/d/optout.

Derek Gaston

unread,
Jul 14, 2016, 4:20:50 PM7/14/16
to moose...@googlegroups.com
I assumed you had some sort of interpolation scheme for your data so you could query it at any x,y,z,t.  You would read your data in in the Material and then evaluate it at _q_points during computeMaterialProperties().

Let me be clear:

1.  Create a new Material by inheriting from Material
2.  Code C++ in that Material to read in your external data
3.  Code C++ in that Material to evaluate your data at any x,y,z,t position.
4.  Create a function called evaluateThermalConductivity() that takes a Point and returns the thermal conductivity by evaluating your data at that point.
5.  Create a function called evaluatePowerDensity() that takes a Point and returns the power density at that point
6.  Use declareMaterialProperty() in your Material to declare a property named "thermal_conductivity" and another named "power_density"
7.  Code computeMaterialProperties() to call evaluateThermalConductivity() and evaluatePowerDensity()... passing in _q_point[_qp] as the Point and assign those values to thermal_conductivity and power_density
8.  Use the HeatConduction Kernel from the heat_conduction module
9.  Create a new Kernel called PowerDensitySource that uses getMaterialProperty("power_density") to get the power density from the Material and applies it as a source term in your PDE (usually it will be something like _test[_i][_qp] * _power_density ).
10. ...
11. Profit!

Once you have that working you can think about possibly moving steps 2, 3, 4 into a GeneralUserObject to hold the data instead of a Material.  That will give you more flexibility on how the data can be used (and use less memory).  But get it working like the above first.

Derek

Mausolff, Alexander J

unread,
Jul 14, 2016, 5:11:19 PM7/14/16
to moose...@googlegroups.com
Ah!!  Somehow the interpolation scheme phrasing made everything clear.  I do not.  But that should something I can whip up.

That makes a lot of sense. I wish I could skip right to the profit stage.  Though there wouldn't be much fun in that.

Thanks!!



For more options, visit https://groups.google.com/d/optout.

Derek Gaston

unread,
Jul 14, 2016, 5:55:12 PM7/14/16
to moose...@googlegroups.com
Ok - no need to create your own interpolation scheme.  I didn't know if you already had one.  For now, you can start simple and just find the nearest datapoint to the x,y,z being passed in... and use that value.

Will this data be changing with time - or is it static?

Derek

Mausolff, Alexander J

unread,
Jul 14, 2016, 6:15:02 PM7/14/16
to moose...@googlegroups.com
yep thats what I just did!

So the entire problem will be changing in time.  But on the MOOSE end I am only looking at steady state solutions.  Something I need to think about in the future.
I'll illustrate by providing some background.

The basic problem is time dependent transport of neutrons. (what follows is over simplified but makes the point) 
This external code is calculating the power density based on the fissions generated in the problem at each time step. 
I am using MOOSE to find how much the temperature will increase based on that calculated power density.
So MOOSE calculates a new temperature and that is fed back into the external code to change the cross sections for the next time step.
Some kind of convergence criteria in-between, but still working on that.. 

This repeats until the problem is done.

So the data is kind of changing in time.  It seems on the MOOSE side it can be thought of as a series of stationary solutions.  







For more options, visit https://groups.google.com/d/optout.

Mausolff, Alexander J

unread,
Jul 15, 2016, 1:23:16 PM7/15/16
to moose...@googlegroups.com
I am using the Heat Conduction kernel from the module.  I see it already has a HeatSource kernel as well.
I need to make a modified HeatSource kernel to get the Power Density value at each point.
So I need to make the heat conduction kernel within the module "aware" of my new HeatSource kernel.  

What is the best way to do that?  It seems I don't want to modify any of the source code within the module...

Thanks!

Cody Permann

unread,
Jul 15, 2016, 1:34:43 PM7/15/16
to moose...@googlegroups.com
The general model is that you start your own application and you use what you can from MOOSE and the modules and you "extend" existing kernels to start solving new physics. If your modifications are generic or widely used by the community, we'll accept them as contributions, otherwise your specializations should remain in your individual application.

Take a look at the "Create an app" page: 

Cody

Wang, Yaqi

unread,
Jul 15, 2016, 2:03:19 PM7/15/16
to moose-users
One kernel is not aware of any other kernels. Kernels are just pieces of a weak form for a particular PDE. If you power density is already a variable, you can use 'CoupledForce' to couple it into the equation in your input file. HeatSource is badly coded and should be removed. It is doing the exactly same thing as BodyForce.

Mausolff, Alexander J

unread,
Jul 15, 2016, 2:53:47 PM7/15/16
to moose...@googlegroups.com
Ah okay.  That is more clear.  I was a little confused on how HeatSource worked.


For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages