Re: Restart in MOOSE

[Permann, Cody J]

Hello Dina, 

I'm sending this to the mailing list since there's a lot to cover here. We've cleaned up the restart system quite a bit since July and we support several ways of restarting from a solution so you might want to think about your simulation and pick the best one.

1. First if your mesh is exactly the same on your second simulation, you can simply read values in from your solution file right onto the mesh. No interpolation or projection. This is our oldest version of restart but it is useful for several restart cases.

2. We also support a SolutionUserObject/SolutionUserAux restart capability. This is similar to #1 but this version projects the simulation onto a different mesh.

3. Finally we have a "recover" version of restart which is where your simulation can pickup right where it left off and continue.  Using the checkpoint files, one can continue a simulation or start a new simulation using data in the checkpoint files.

We need to create better documentation for all of these cases so for now, the best way to learn, is to find an example, and work from there. Here are a few of the folders you might look at in the test directory (under test/tests):

restart

auxkernels/solutionaux

Finally you can control the number of checkpoint files written. You simply need to create a checkpoint subblock underneath the Outputs section of your input file instead of using the shortcut option of checkpoint=true.  See 

outputs/checkpoint.

As you can see there is a lot to digest here.  Please try some of these out and let us know if you have more questions.

Cody

On Thu, Aug 21, 2014 at 6:02 PM, Dina V Yuryev <dyu...@mit.edu> wrote:

Hi Cody,

You may or may not remember from the July MOOSE workshop, but I asked you some questions on restarting from an existing solution. I'm trying to implement this restart, but am having some problems. 

In particular, I solve for a field c (specifically, my phase field calculated by Cahn-Hilliard). Then, I want to take my solution for c and multiply it by some factor. I have successfully implemented this by using an aux kernel to calculate my modified field c_aux. Then, I would like to take the c_aux field and set it as the initial condition of my c field in a subsequent simulation.

In my initial input file, I generate checkpoint files by setting 'checkpoint = true' in the outputs block (By the way, is there any way to set how many checkpoints are made? I only need the last time step, and I've been generating 2 checkpoint files by default. Setting num_checkpoint_files = 1 as specified by the faq on the wiki just gives me a warning that this parameter was unused). Then in a new input file, in my variables block under initial conditions for c i specify:

initial_from_file_var = c_aux

initial_from_file_timestep = 5

In my outputs block I specify:

restart_file_base = out_cp/0005

This doesn't work. I get a warning saying restart_file_base is unused and MOOSE can't calculate a first step. It seems weird to me that I would need to specify the time step in the variables block when I also specify which time step in the output block.

I would appreciate any insight you could give me on this.

Thank you,

Dina

[Jesse Carter]

Sorry to revive an old thread, but I'm trying to do the exact same thing and it seems like Cody's suggestion 1 would work for me, but it does not.

I have some linear Lagrange (nodal, right?) variable and I'm tweaking it a bit through an Aux variable. I'm actually multiplying by some spatially-dependent value, but it is still on the same mesh. I try to read in the "tweaked" Aux variable as an initial condition using initial_from_file_var but I get an error that the 'Variable [name] does not exist in this system'. I know it is there because I can open up the solution from the previous run in Paraview and see it. I'm guessing this has to do with the fact that it's an Aux variable and not a "real" variable or whatever. Indeed setting the initial condition to the original variable works fine.

So is it possible to read in an Aux variable as an initial condition through the initial_from_file_var line or should I be using checkpoint files to do this?

Thanks.

[Cody Permann]

There was a bug identified a few months back that prevented a variable by a different name from providing a solution to another variable but that was fixed promptly after it was identified. You should be able to restart a normal variable from an auxiliary solution provided they are compatible in type (i.e. your Aux Variable should be nodal if you plan to use it's solution for a nodal basis like Lagrange.

See the following test for an example:

moose/test/tests/restart/restart_diffusion/restart_diffusion_transient_new_name.i

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/6e48b4a6-a8d3-44a3-b4fa-5dd9d10257ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jesse Carter]

So what you're saying is *if* i had the most recent source code (and not something from December), I probably would not have run in to this problem in the first place. I'll have to let my admin know!

After poking around some more, I'm wondering if the same could be accomplished using a SolutionUserObject and a custom Initial Condition that calls directValue() and adds it to a custom Function I have currently have set up as an AuxKernel. After all, I'm only using the last time step as an initial condition and so it is a bit of a waste to compute the AuxKernel at every timestep. I could put something at the top like if (_t >= end_time) but there would still be many unnecessary calls to the AuxKernel. As long as I stick to linear Lagrange elements, I should be fine.

Does that sound reasonable?

Thanks for your help.

[Cody Permann]

On Tue, May 26, 2015 at 1:13 PM Jesse Carter <jesse....@gmail.com> wrote:

So what you're saying is *if* i had the most recent source code (and not something from December), I probably would not have run in to this problem in the first place. I'll have to let my admin know!

Yes, MOOSE gets updates nearly every day so it helps to stay up to date. Having a fairly static stack is find (MPI, PETSc, Hypre) but you probably should consider installing MOOSE in your home directory so you can update it and libMesh regularly.

 

After poking around some more, I'm wondering if the same could be accomplished using a SolutionUserObject and a custom Initial Condition that calls directValue() and adds it to a custom Function I have currently have set up as an AuxKernel. After all, I'm only using the last time step as an initial condition and so it is a bit of a waste to compute the AuxKernel at every timestep. I could put something at the top like if (_t >= end_time) but there would still be many unnecessary calls to the AuxKernel. As long as I stick to linear Lagrange elements, I should be fine.

You could certainly use a SolutionUserObject and Function if you wish but that may be more complicated than just using the built in capability if you just need the nodal values from a previous simulation. Also you can control how often an AuxKernel is executed you can execute it once at the initial step (not quite what you need) or you can execute just once a timestep which is usually not too expensive. At some point we may add the capability to execute just once at the end. We have the capability now but just haven't implemented that capability throughout the framework.

Cody

 

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/26b4b64f-dbea-4dc4-8fae-18975ab589ca%40googlegroups.com.

[Andrew....@csiro.au]

Jesse, if it doesn’t work when you’ve updated MOOSE, could you please tell us?  I use that feature quite a lot and need it to be bug free.

 

a

 

Ph: +61 7 3327 4497.  Fax: +61 7 3327 4666
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069 
 

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

[Jesse Carter]

Will do.

In the meantime I was able to bring in the aux variable solution using a SolutionUserObject and used that to create a SolutionFunction which I used as the initial condition. It's pretty much the same as in test/tests/functions/solution_function/solution_function_test.i. I have the aux kernel set to execute_on = timestep (based on Cody's suggestion) to save a little time. In the end I intend to perform this read/compute/write/read many times over so every bit of time savings helps.

[Derek Gaston]

If you just need to execute it in the beginning to set the initial condition... then just set "execute_on = initial"

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/11c6002d-c4ea-440e-8ed2-0a7b40c382f8%40googlegroups.com.

[Jesse Carter]

Got MOOSE updated today and everything works as intended.

Thanks for all your help.