is refinement level stored in and read from an Exodus file?

[Jesse Carter]

Let's say I'm reading in an Exodus file from a previous simulation on which some mesh adaptivity (refinement) was performed. Let's also say that my current simulation has a max_h_level set and performs further mesh refinement. Will MOOSE recognize the refinement levels in the read-in mesh and adhere to my max_h_level, or does the read-in mesh have essentially a 0-level refinement everywhere? If the latter is true, is there a way to pass the refinement information along?

Thanks.

[Derek Gaston]

No - you can't "restart" using adapted Exodus meshes at all.  Even though they look "ok" adapted Exodus meshes are actually "broken".  We output them in a way that looks good in our Postprocessing tools but we have to flatten the hierarchy so things aren't actually connected properly.  If you were to try to use it it would look like there are "holes" in your simulation.

To restart with adaptivity you need to be writing out XDA files using "xda = true" in your Output block.  A better idea is actually to write out real checkpoint files using "checkpoint = true" and use "real" restart.

You can read more about "real" restart here: http://mooseframework.org/wiki/Restart/

Let us know if you have any questions.

Derek

On Mon, Jan 11, 2016 at 10:51 AM Jesse Carter <jesse....@gmail.com> wrote:

Let's say I'm reading in an Exodus file from a previous simulation on which some mesh adaptivity (refinement) was performed. Let's also say that my current simulation has a max_h_level set and performs further mesh refinement. Will MOOSE recognize the refinement levels in the read-in mesh and adhere to my max_h_level, or does the read-in mesh have essentially a 0-level refinement everywhere? If the latter is true, is there a way to pass the refinement information along?

Thanks.

--
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/835a50ee-0028-4546-9c68-ff9b947a4da3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jesse Carter]

Thanks, Derek. I think the "real" restart with checkpoints should work.

Some follow-up questions:
1)   Is there a way to use the "LATEST" mesh like one can use the "LATEST" solution? I didn't see that specifically mentioned in the recent blog post. (http://mooseframework.org/blog/retrieving-the-latest-value-of-something/)

2)   How do I go about reading a previous solution into a SolutionUserObject with this method using mesh adaptivity? Usually, with no adaptivity, I would just read in the exodus file but does that work for adaptive meshes? I guess I'm asking which file I would point the SolutionUserObject to when doing mesh adaptivity AND checkpointing.

[Jesse Carter]

Regarding 1) above: It appears the answer is "yes" but currently, loading a checkpoint mesh using "file = file_base_cp/LATEST" does not work for me. In fact, I just ran the test suite and restart/restart.test_2 failed. The error message basically says it cannot find the file. However, if I manually give it the 000x_mesh.cpr file, it does work. Additionally, other tests which use "LATEST" in the Problem block DO work fine because they either explicitly specify a file name or use a GeneratedMesh.

I haven't updated the MOOSE source since before Christmas, and I realize that is the probably the first step, but I find it weird that 'LATEST' works in one context but not the other. Any ideas?

[Cody Permann]

Jesse,

I didn't implement the "LATEST" keyword for the mesh section. It should be easy to add, but just hasn't been requested before and I guess I didn't think about it when I was adding that in other places in the framework. If you look at the restart.test_2 example. It does indeed load the latest solution as you already pointed out, but it explicitly gives the name of the mesh file. Yeah, I see the discontinuity there.

I'm a little unclear if the restart.test_2 is failing for you unchanged or not. It certainly should not fail if you haven't changed the input file, if it is, then we need to look into that. Please clarify this point for me.

I'll add a ticket for loading the LATEST mesh too.

Cody

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/bd00da00-3bbb-40cf-bcb1-222a33380943%40googlegroups.com.

[Jesse Carter]

Whoops, the modification date on that file is yesterday. I must have modified the file (and forgot about it) instead of making my own copy. Rookie mistake.

But hey, at least now I know what's implemented and what's not. And I would be grateful if that change made it in there.

   - Jesse

[Jesse Carter]

Cody, I see you opened the issue. Thanks for doing that.

Back to my other question... When using adaptive meshing, what kind of file do I need to read in to a SolutionUserObject? I've been using Exodus files (with no mesh adaptivity) but Derek has me doubting that will work adaptive meshes.

   - Jesse

[Cody Permann]

Right, use either "xda" or "xdr" files.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/6d8ed558-ab72-4c16-9a60-ba9d206fc4d4%40googlegroups.com.

[Jesse Carter]

Do I need to put in a line in my Output block for the xda or xdr file, or will the xdr file work that is included in the checkpoint files? Actually, there's a .xdr and .xdr.0000 file.

[Cody Permann]

Sorry checkpoint files are valid too. You don't need to explicitly list "xda" in our Outputs block.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/c05628f4-a295-4e21-a766-fab80b801cfb%40googlegroups.com.