Tupek/test quasi static checkpoint #1183
Conversation
tupek2
force-pushed
the
tupek/test-quasi-static-checkpoint
branch
3 times, most recently
from
442e66c to
8d98cb6
Compare
| @@ -346,7 +343,8 @@ class HeatTransfer<order, dim, Parameters<parameter_space...>, std::integer_sequ | |||
| } else { | |||
| // Step the time integrator | |||
| // Note that the ODE solver handles the essential boundary condition application itself | |||
| ode_.Step(temperature_, time_, dt); | |||
| double time_tmp = time_; | |||
| ode_.Step(temperature_, time_tmp, dt); | |||
There was a problem hiding this comment.
why do you make a copy of time_ before passing to ode_?
There was a problem hiding this comment.
time_ is already passed to the constructor of the time integrator. It is already incremented there. This value would also be incremented. I want to make sure the incrementing wasnt happening twice.
There was a problem hiding this comment.
Can you put a comment of why you are doing this here and below?
|
are you planning to add the test with a |
tupek2
force-pushed
the
tupek/test-quasi-static-checkpoint
branch
from
79117d3 to
4daaea7
Compare
added |
|
Update- Irvin pulled the latest changes from this branch into his lido build and his problem has correct sensitivities and a working inverse problem with time dependent b.c.s and time dependent QoI. Thanks for all the help @tupek2! |
tupek2
added
WIP
tupek2
force-pushed
the
tupek/test-quasi-static-checkpoint
branch
from
e7f4006 to
c39ce0b
Compare
| @@ -1352,9 +1354,21 @@ class SolidMechanics<order, dim, Parameters<parameter_space...>, std::integer_se | |||
| mfem::HypreParVector adjoint_essential(displacement_adjoint_load_); | |||
| adjoint_essential = 0.0; | |||
|
|
|||
| SLIC_ERROR_ROOT_IF(cycle_ <= min_cycle_, | |||
| "Maximum number of adjoint timesteps exceeded! The number of adjoint timesteps must equal the " | |||
| "number of forward timesteps"); | |||
There was a problem hiding this comment.
it might be helpful here to mention to users that this message can be caused by two backwards passes attempted without a forward pass or a clearAdjointStates() in between
tupek2
force-pushed
the
tupek/test-quasi-static-checkpoint
branch
from
1321cee to
cb1d924
Compare
| @@ -57,7 +57,7 @@ double BasePhysics::minTime() const { return min_time_; } | |||
|
|
|||
| int BasePhysics::minCycle() const { return min_cycle_; } | |||
|
|
|||
| std::vector<double> BasePhysics::timesteps() const { return timesteps_; } | |||
| const std::vector<double>& BasePhysics::timesteps() const { return timesteps_; } | |||
| } | ||
|
|
||
| double BasePhysics::getCheckpointedTimestep(int cycle) const | ||
| { | ||
| SLIC_ERROR_ROOT_IF(cycle < 0, axom::fmt::format("Negative cycle number requested for physics module {}.", name_)); | ||
| SLIC_ERROR_ROOT_IF(cycle > max_cycle_, | ||
| SLIC_ERROR_ROOT_IF(cycle > static_cast<int>(timesteps_.size()), |
There was a problem hiding this comment.
Thanks for making this error check consistent with the message but should we have a check that we don't go over max_cycle_?
…ng times, also quasi-static was not fetching its state at all.
… complicated things.
…ed to be some consistency between initial and boundary conditions in the dynamic cases.
…f time. Also fix divide by zeros in output.
tupek2
force-pushed
the
tupek/test-quasi-static-checkpoint
branch
from
cb1d924 to
def2e91
Compare
|
/style |
The checkpointing was not being done for quasi-static problems. Now, it is written a bit more generically with a bit more responsibility on base_physics and loops over states so that it will work for any physics and dynamic or quasi-static. In addition, we were not decrementing the time correctly, so any time dependent load was not being accounted for in the reverse pass correctly. This tries to clear up some of the logic and naming, and fix these know failing situations. Tests were added to check time varying loads and quasi-static evolution.
Additional things in this: remove ode_time_point_, as it was very confusingly intertwined with time_. If there is a case to keep both, we can undo this. Also, the checkpoint to disk capability is a bit subtle. Now it is always writing to disk. If the user externally also writes state to disk, it will mess up the checkpointing. I think we can considered deleting the writing to disk checkpointing altogether at some point. For now, it is fairly hard to use.