#1259 Rebase #1276
Merged
#1259 Rebase #1276
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of storing a bool, time_evolving now caches the time order of the variable. Thus, a new time_evolving() method was added to indicate the order of the variable. The old API is now deprecated and assumes first order for backward compatibility.
For the moment, we're just calling DiffPhysics::time_evolving(), but the plan is to then update the UnsteadySolvers to allow specification of first order and second order variables. Since the DiffSystem owns the TimeSolver, we need the hook there. We want to register the time order at this point so that when init() is called in the TimeSolver, it can do the right thing for the particular UnsteadySolver implementation.
I kept them in separate sets because it will make the algorithms easier (I think...) for dealing with the case of both first and second order variables in each of the particular time stepping implementations.
Now, if the TimeSolver is an UnsteadySolver, DiffSystem::time_evolving() notifies the UnsteadySolver of the time order of each variable.
We're getting to the point to be able to add second order in time variables to first order solvers. So, not just second order time solvers will need accels, but potentially first order solvers with second order variables. Even though we won't necessarily use all of them, we still at least make space for them.
This will add auxillary "dot_"+<var_name> variables to the System for second order (in time) variables.
This provides an interface for the user to extract the "dot" variable corresponding to a second order variable. The second order variable would've been added by the user while the "dot" variable would've been added by the FirstOrderUnsteadySolver. For SecondOrderUnsteadySolvers, there is not dot variable, but the interface allows for consistency with the FirstOrderUnsteadySolver while using a SecondOrderUnsteadySolver.
Helper function for FirstOrderUnsteadySolver class that will prepare the acceleration data in the DiffContext. In this case, it's just the "velocity" of the TimeSolver-introduced first-order variable corresponding to the user-added second-order variable.
This method will handle computing the residual and Jacobian (if requested) for the "velocity" equations corresponding to the TimeSolver-added "velocity" variables.
Update Euler(2)Solver to now deal with second order variables if they've been added to the TimeSolver.
This is in preparation for adding testing of the new extended API to allow second order problems to use first order solvers
This is for testing second order problems that are written in a style of first order problems. That style should be compatible with both FirstOrderUnsteadySolver and SecondOrderUnsteadySolver classes.
These tests ensure that the new extended API for second order problems with first order time solvers is also valid when using a second order time solver.
Testing the new extended API for solving second order problems using first order time solvers
Enable overriding arguments from the command line, allowing us to run this example in multiple ways without having to chagne the input file. Also have it actually run the steady case as part of run.sh; it was an option in this example program before, but we weren't actually doing it. This restructuring is mainly to start setting up to illustrate how to use a FirstOrderUnsteadySolver for this problem.
This should now support both SecondOrderUnsteadySolvers and FirstOrderUnsteadySolvers
This takes care of adding Dirichlet boundary conditions for the added "dot" variables. Those boundary conditions are just mimicking what what the user set for the second order variable.
Now we're showing how we can use either FirstOrderUnsteadySolver or SecondOrderUnsteadySolver to solve a second order-in-time system (linear elasticity in this case).
In particular, for dealing with second order systems as first order systems.
As discussed with @roystgnr, these things really belong in the DiffSystem. So this moves these things around from the TimeSolver to the DiffSystem. A pleasant side-effect is that this really cleans up the user-facing API in the FEMSystem subclasses, see the changes in fem_system_ex3 in this commit.
For "dot" variables in DiffSystem, their boundary conditions should be the time derivative of the boundary condition for the parent second order variables. Currently, we can't automatically do those derivatives so we error out in those cases. We do handle the constant case (the derivative is just zero), so we do that when we can.
We prefix "_" to private members
BICGSTAB (the default) was nan'ing on the Jacobians for this system using EulerSolver and Euler2Solver (I'm not sure why). GMRES currently doesn't work in Eigen, so all that was left was SPARSELU. That solve time is very reasonable (less than a second), but the assembly time is atrocious, particularly for the EulerSolver and Euler2Solver cases (see libMesh#1268). Note that this originally manifest in --enable-complex, but BICGSTAB is also dying using real-valued calculations as well.
pbauman
force-pushed
the
second-orders-vars-first-order-timesolver-rebase
branch
from
6c4b6b9
to
2148606
Compare
|
Rebased on master while I was at it. |
roystgnr
reviewed
Mar 10, 2017
src/systems/diff_system.C
Outdated
| dbc.f_fem.get()); | ||
| } | ||
| else | ||
| libmesh_error_msg("Could not find valid boundary function!"); |
There was a problem hiding this comment.
Didn't we decide that this was wrong? The best we can do for now is add ZeroFunction DBCs for the dot vars, or scream-and-die if the primal var DBCs are FEM-dependent or time-dependent?
There was a problem hiding this comment.
Yes, and it was fixed in 9edd8ba. Should I squash that fix commit in?
There was a problem hiding this comment.
No, that's fine; I just missed it.
|
👍 when Civet's done. |
|
After merging this, I get a compile error: The CI was happy... is my compiler just dumb? |
|
Maybe it's a C++11 thing that our no-C++11 test doesn't catch. I happen to be configured with |
jwpeterson
added a commit
that referenced
this pull request
Mar 10, 2017
Our "no C++11" continuous integration test apparently allows scoped enumeration declarations, which is technically a C++11 feature. http://en.cppreference.com/w/cpp/language/enum
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Redux of #1259 with several fixes squashed in. This should address all comments from the #1259.