Load a variable or aux variable from Exodus file

365 views
Skip to first unread message

Jack Galloway

unread,
Nov 17, 2015, 2:25:24 PM11/17/15
to moose-users
I'm trying to read an aux variable (fission_rate) that exists on the exodus file into a problem I want to run.  I'm doing this in Bison actually, but it seems I need assistance from Moose knowledgeable folks for tracking my problem.  I have "distribution = serial" in the mesh block, and:

[AuxVariables]
  [./density]
    order = CONSTANT
    family = MONOMIAL
  [../]

  [./fission_rate]
    order = FIRST
    family = LAGRANGE
    initial_from_file_var = fission_rate
    #initial_from_file_timestep = 0
  [../]
[]

then in the kernels section have:
  [./volumetric_power]
    type = NeutronHeatSource
    variable = T
    fission_rate = fission_rate
  [../]

However, the original layout of the fission distribution gets morhped into something completely different (i.e. the nodal values are completely different), however they have the right scale, as in the max value is the same (see the legends).  The attached pictures from Paraview should better illustrate what I'm saying.  fission_rate_before_bison shows the fission rate after I have written it to the Exodus file, but before running Bison.  fission_rate_in_bison obviously shows the values after trying to load the data as shown above, where the nice layout is now a scrambled mess, but notice the scales are still the same.  I load the data into the Exodus file with the exodus.py utility that comes with the SEACAS tools distribution, and have verified the power distribution is as expected prior (hence the picture attached).  

I assumed this was the correct approach for importing the variable from this link, but if there is a different/easier way to pull the data in, I'm not pinned to any specific way yet.  I attached the input deck in completion if useful.  Lastly, if the mesh file is desired I can send that too, although it's 30MB so I didn't include it right away.  

Thanks for the help,
Jack Galloway
fission_rate_before_bison.PNG
fission_rate_in_bison.PNG
input_deck.i

Cody Permann

unread,
Nov 17, 2015, 2:44:06 PM11/17/15
to moose-users
When using this "short cut" syntax we are copying solution values directly so your mesh in your new simulation must exactly match the mesh in the old simulation. Also make sure that your variable type matches (nodal -> nodal), (elemental -> elemental). Finally make sure you aren't using any adaptivity, if you are then you have to use a different approach. Otherwise, If everything is the same, this should work just fine.

If however your meshes don't match, the other way of reading in a solution for the new simulation is to use the SolutionFunction or SolutionUserObject (SolutionAux) objects to read in and project your solution onto your new mesh.

Cody

--
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/77192413-4431-47a1-b286-c6b88275d4b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jack Galloway

unread,
Nov 17, 2015, 3:05:43 PM11/17/15
to moose-users
Does this method still work if I'm not restarting?  I'm creating a file in Cubit, then inserting a power distribution into the cubit generated exodus file (hence the fission_rate_before_bison image), then loading all of this into Bison.  It's NOT a case where I run Bison, then update the values and re-run it, thus there is no "old simulation".  I did make sure the variable types matched, and got errors when I shoved constant monomial instead of first lagrange as a sanity check.  Although I could run a dummy Bison simulation first then over-write the power values, it seemed that writing it onto the mesh prior to running Bison would be cleaner ... assuming it works.

Cody Permann

unread,
Nov 17, 2015, 3:39:20 PM11/17/15
to moose...@googlegroups.com
On Tue, Nov 17, 2015 at 1:05 PM Jack Galloway <jackdg...@gmail.com> wrote:
Does this method still work if I'm not restarting?  I'm creating a file in Cubit, then inserting a power distribution into the cubit generated exodus file

Ah, I see. This is something I haven't done before so it might depend on how Cubit is storing the data in the exodus file. We've run into problems before with the extra maps that Cubit 14+ creates. Which version of Cubit are you using? 

Normally we assume that the solution is listed in the same order as the nodes and elements. Cubit however creates an intermediate map for things like nodesets and sidesets so I wonder if the same thing is happening here for the solution? If so, that could explain the problem, we may have to read and honor that map if it exists. Could you provide us with the cubit journal file or perhaps your input mesh so we could take a closer look?
 
(hence the fission_rate_before_bison image), then loading all of this into Bison.  It's NOT a case where I run Bison, then update the values and re-run it, thus there is no "old simulation".  I did make sure the variable types matched, and got errors when I shoved constant monomial instead of first lagrange as a sanity check.  Although I could run a dummy Bison simulation first then over-write the power values, it seemed that writing it onto the mesh prior to running Bison would be cleaner ... assuming it works.

If you can't get it to work, I'm not so sure our other objects would work either without additional work to handle this map (if that is indeed the issue).  As a workaround you might consider just setting up an initial condition to set the values instead of reading them from the file. It looks like you basically have two subdomains so creating an initial condition to set the fission rate.

Cody
 

Benjamin Spencer

unread,
Nov 17, 2015, 3:56:36 PM11/17/15
to moose-users
The Exodus node and element numbering maps definitely get ignored by MOOSE, which I would guess is the source of this problem.

 I'm pretty sure we've had the discussion about the maps before somewhere on this list, and there's probably a ticket for it somewhere.  We'd love to get things sorted out so that the maps get honored.

-Ben

Jack Galloway

unread,
Nov 17, 2015, 3:59:45 PM11/17/15
to moose-users
Ok, sounds like we're on to something.  I'm running Cubit 15.0.  I can provide both journal and mesh.  I think you want the mesh file in particular since the journal file doesn't create the fission_rate (it's really power, I've named it poorly) variable on the mesh and I post-process it.  The mesh file is 30MB, what's the best way to get that over?  Creating an initial condition wouldn't work for the full desired usage of the capability.  I'm currently running a simplified problem for troubleshooting, but I'll eventually want axially/radially varying entries dependent on user fidelity of the code providing the power profile.  Bottom line, I think it will get more complicated than initial conditions will allow.

I attached the journal file here, but you'll need the full mesh file with the fission_rate added to it.  I tried attaching it here, but it bombed, presumably because of file size.  Let me know the best route, and thanks for the help.
no_air_med_plus.jou

Cody Permann

unread,
Nov 17, 2015, 4:07:35 PM11/17/15
to moose-users
Any chance that you can replicate with a much smaller mesh? My guess is that this problem will show up with even a few elements. If not, we can probably look at the full size mesh.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/1cfd2397-f6f0-4ab5-9ea3-4f1dd8484ff1%40googlegroups.com.

Wang (Non-US), Yaqi

unread,
Nov 17, 2015, 4:17:13 PM11/17/15
to moose-users
We met this issue before, see Issue #3198, and it should have been fixed... I remembered we sent John few small mesh files for testing. Hopefully this helps.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAK06EuV56ax6_nuyoKrUeJRpfr3bVU%3D%3D%2ByS%3DvU33P%3DGhkFWLeA%40mail.gmail.com.

Jack Galloway

unread,
Nov 17, 2015, 4:24:49 PM11/17/15
to moose-users
Yeah, much smarter solution.  Slow on the uptake here sorry.  Attached is test.e, the Cubit file with "fission_rate" added, but not loaded into Bison yet.  test_out.e is after loading into Bison and things getting clobbered.  The input file used is essentially the same one included earlier (different mesh file name, but the same otherwise). 

Thanks, Jack
test.e

Wang (Non-US), Yaqi

unread,
Nov 17, 2015, 4:26:01 PM11/17/15
to moose-users
FYI, Javi raised this question on the user list with a title "Paraview ElementID vs Libmesh ElementID".

Gleicher, Frederick N

unread,
Nov 17, 2015, 6:01:41 PM11/17/15
to moose...@googlegroups.com

Jack,

running your problem with solution function I get:

Error reading nodal variable values!

[Error reading nodal variable values!

[Error reading nodal variable values!

[18] ../src/mesh/exodusII_io_helper.C, line Error reading nodal variable values!

[19] ../src/mesh/exodusII_io_helper.C, line Error reading nodal variable values!

[21] ../src/mesh/exodusII_io_helper.C, line 794, compiled Oct 29 2015 at Error reading nodal variable values!

[22] ../src/mesh/exodusII_io_helper.C, line 794, compiled Oct 29 2015 at 09:25:29




looking into the LIBMESH code: 

  // Call the Exodus API to read the nodal variable values

  ex_err = exII::ex_get_nodal_var(ex_id,

                                  time_step,

                                  var_index+1,

                                  num_nodes,

                                  &nodal_var_values[0]);

  EX_CHECK_ERR(ex_err, "Error reading nodal variable values!");

}



My guess is that for either solution function or the initial read you will probably need to have a fission_rate for the entire domain and all nodes not just a piece of it (fuel), at least that is my guess without looking into an ncdump of the test.e file. I suspect, and Cody or Ben might comment, that when you load from the intial_from_file_var their is no domain restriction check really for the matching of those nodes ? and thus it reads in "whatever". But that is just a guess...Also I have done this sort of thing using elemental aux variables where it appears domain restricted. You could try to write the power density as an elemental value and read it via solution function.

-Rick-


I assumed this was the correct approach for importing the variable from this link, but if there is a different/easier way to pull the data in, I'm not pinned to any specific way yet.  I attached the input deck in completion if useful.  Lastly, if the mesh file is desired I can send that too, although it's 30MB so I didn't include it right away.  

Thanks for the help,
Jack Galloway

--
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.

--
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.

--
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.

--
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.

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



--

------------------------
Frederick Gleicher
Reactor Physics Design & Analysis

Derek Gaston

unread,
Nov 17, 2015, 6:05:27 PM11/17/15
to moose...@googlegroups.com
Are you sure you can't define this in an InitialCondition?  What, in particular, does Cubit have that lets you define it there?

Having Cubit be part of your workflow is really going to be a bummer.

Derek

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

Jack Galloway

unread,
Nov 17, 2015, 6:39:07 PM11/17/15
to moose-users
Derek and Rick,

Thanks for the comments.  

First to Rick.  I actually specify a value for every node in the problem, not just the fuel.  There is some heating that we're interested in coming from more than just fission, so I'm capturing everything power wise that is going on in the domain and grabbing the power for that.  I then update every node with either the power, or 0 if the node isn't in the domain (occurs for a very very small fraction of nodes and is expected), so that I specify a value for every node.  I have some checks to make sure I am writing "num_nodes" number of values back to the Exodus file.

To Derek.  I only run Cubit initially to create the mesh.  I then run a power calculation in an external code to get powers I'm looking for, then write them back to the exodus file (the first pretty picture), whereupon after that I'm going to want to iterate back and forth and Cubit won't come into play (unless by Cubit you also meant directly accessing the exodus mesh).  In my flow I run the power calculation first to update Bison with the correct power profile to then calculate temperatures, swelling etc... and I'll then update the neutronics code.  Thus, at the risk of being repetitive, my flow is: 

(1) Cubit for mesh, 
(2) Neutronic/photon power calculation, 
(3) Write nodal powers to Exodus mesh based on calculation (using exodus.py from seacas tools)
(4) Run Bison, reading powers from exodus mesh
(5) Iterate 2-4 updating powers to Bison, displacements and temperatures from Bison

It's step, (between 3 and 4?) where things are going haywire.  Hopefully this gives some clarity.  

Thanks to all.

Benjamin Spencer

unread,
Nov 17, 2015, 6:54:48 PM11/17/15
to moose-users
As a workaround, you should be able to delete the node and element maps from your exodus file before you put the power information on it.  To do that, you can run ncdump and direct the output to a text file, edit the text file to remove the maps, and run ncgen to convert it back to exodus.  You have to be careful to edit the file correctly, but I've done that many times to modify meshes.

-Ben

Cody Permann

unread,
Nov 18, 2015, 9:35:06 AM11/18/15
to moose...@googlegroups.com
On Tue, Nov 17, 2015 at 4:39 PM Jack Galloway <jackdg...@gmail.com> wrote:
Derek and Rick,

Thanks for the comments.  

First to Rick.  I actually specify a value for every node in the problem, not just the fuel.  There is some heating that we're interested in coming from more than just fission, so I'm capturing everything power wise that is going on in the domain and grabbing the power for that.  I then update every node with either the power, or 0 if the node isn't in the domain (occurs for a very very small fraction of nodes and is expected), so that I specify a value for every node.  I have some checks to make sure I am writing "num_nodes" number of values back to the Exodus file.

To Derek.  I only run Cubit initially to create the mesh.  I then run a power calculation in an external code to get powers I'm looking for, then write them back to the exodus file (the first pretty picture), whereupon after that I'm going to want to iterate back and forth and Cubit won't come into play (unless by Cubit you also meant directly accessing the exodus mesh).  In my flow I run the power calculation first to update Bison with the correct power profile to then calculate temperatures, swelling etc... and I'll then update the neutronics code.  Thus, at the risk of being repetitive, my flow is: 

(1) Cubit for mesh, 
(2) Neutronic/photon power calculation, 
(3) Write nodal powers to Exodus mesh based on calculation (using exodus.py from seacas tools)

I don't see any reason you can't capture this step in an Initial Condition. If you can extract the data to write it back to Cubit, then you can certain extract the data to write it back to an InitialCondition. I can point you to a few examples where we read data files and then transfer that information to the initial condition. These can be arbitrarily complex. Additionally you can easily apply the IC to a single domain so getting those values into the fuel elements should be straight forward. Off the top of my head you might want to look at these two classes to see what you can do:

This is the IC that uses a UserObject to retrieve data:

This is the UO that reads data from a file. You could read it direct in the "InitialCondition::initialSetup()" routine if you wanted, but we use this UO for other parts of the simulation as well.

Cody
 

Daniel Schwen

unread,
Nov 18, 2015, 10:26:57 AM11/18/15
to moose...@googlegroups.com

Jack, you are iterating with an external code? And you exchange the data by writing exodus files to disk and reading them back in? Do you have any way of modifying the external code? This sounds like a usecase for multiapps and transfers. That would allow you to do all iterations within one run.


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

Derek Gaston

unread,
Nov 18, 2015, 10:52:49 AM11/18/15
to moose...@googlegroups.com
I agree with Daniel that you should look into using MultiApps and Transfers.

One thing you may not have thought of yet is that BISON is _stateful_.  What I mean is that BISON cannot simply just be fed a new power profile and then you get it's response to that.  BISON has _history_ that builds up over time (burnup dependent properties, plasticity, etc.).

So, just feeding BISON a different initial condition for power and running one step of it and then going back to your other external code isn't going to get the job done.  You need to have a continuous BISON run and feed it power profiles all along the way from your external code.

That's what MultiApps and Transfers are for.

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPxoKqf2s-kJX6zNLC-9zFmKjWab7RCdExb1e4pp%2BSsirxz9Fw%40mail.gmail.com.

Derek Gaston

unread,
Nov 18, 2015, 10:53:27 AM11/18/15
to moose...@googlegroups.com
BTW: None of this obviates the issue at hand: we should figure out why we can't read an initial condition from an Exodus file generated in another code and fix it ;-)

Jack Galloway

unread,
Nov 19, 2015, 8:41:35 AM11/19/15
to moose-users
A little delayed on the response here.  Quick responses for brevity.  

(1) Modifying the code's not something I'm interested unless it's a 100% must must must (and luckily it's not ... at least yet).
(2) The way I'm iterating back and forth, for the needs I currently have is ok.  Keeping in mind the stateful aspects as I move forward, but for the needs we have first, this will work fine.
(3) Working with Ben, he cleared me up on some misunderstanding of the purpose/usage of the node and element maps in Exodus.  I added the following to my exodus read/write (I am using exodus.py) and got the right placement.  I also agree it'd be nice to handle the Exodus maps as they come, instead of having to sequence them in time:

    exo = exodus.exodus(input_file,'a')

    num_nodes = exo.num_nodes()

    num_elems = exo.num_elems()

    node_map = range(1,num_nodes+1)

    elem_map = range(1,num_elems+1)

    exo.put_node_id_map(node_map)

    exo.put_elem_id_map(elem_map)


Thanks for the help to all.
...
Reply all
Reply to author
Forward
0 new messages