{"action":"created","issue":{"url":"https://api.github.com/repos/libMesh/libmesh/issues/1259","repository_url":"https://api.github.com/repos/libMesh/libmesh","labels_url":"https://api.github.com/repos/libMesh/libmesh/issues/1259/labels{/name}","comments_url":"https://api.github.com/repos/libMesh/libmesh/issues/1259/comments","events_url":"https://api.github.com/repos/libMesh/libmesh/issues/1259/events","html_url":"https://github.com/libMesh/libmesh/pull/1259","id":210899158,"number":1259,"title":"Extend FirstOrderUnsteadySolvers to Support Second Order Variables","user":{"login":"pbauman","id":3051555,"avatar_url":"https://avatars0.githubusercontent.com/u/3051555?v=3","gravatar_id":"","url":"https://api.github.com/users/pbauman","html_url":"https://github.com/pbauman","followers_url":"https://api.github.com/users/pbauman/followers","following_url":"https://api.github.com/users/pbauman/following{/other_user}","gists_url":"https://api.github.com/users/pbauman/gists{/gist_id}","starred_url":"https://api.github.com/users/pbauman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pbauman/subscriptions","organizations_url":"https://api.github.com/users/pbauman/orgs","repos_url":"https://api.github.com/users/pbauman/repos","events_url":"https://api.github.com/users/pbauman/events{/privacy}","received_events_url":"https://api.github.com/users/pbauman/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":15,"created_at":"2017-02-28T20:51:33Z","updated_at":"2017-03-09T17:25:30Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/libMesh/libmesh/pulls/1259","html_url":"https://github.com/libMesh/libmesh/pull/1259","diff_url":"https://github.com/libMesh/libmesh/pull/1259.diff","patch_url":"https://github.com/libMesh/libmesh/pull/1259.patch"},"body":"This PR extends the capabilities of `FirstOrderUnsteadySolver`s to support second variables as well. This is done by adding new variables to the `FEMSystem` that correspond to the \"velocities\" of the second order variables. That is, instead of `M(u)\\ddot{u} + C(u)\\dot{u} + F(u) = 0`, the user can treat the system as `M(u)\\dot{v} + C(u)v + F(u)` and the `FirstOrderUnsteadySolver` will deal with the equations `\\dot{u} = v`. Ultimately, this was not as seamless to existing `FEMSystem` subclasses as I was hoping, but we at least still achieve an API such that the user can support either  `FirstOrderUnsteadySolver` or `SecondOrderUnsteadySolver` without changing their code once they adhere to the paradigm I elaborate on below. I'll preface that `fem_system_ex3` was updated as part of this PR to illustrate this paradigm (see e380d4b).\r\n\r\nFirst changes require the user to tell us whether their `time_evolving` variable is first order or second order. I've added a new `time_evolving` override and deprecated the old version (which defaults to 1 for backward compatibility). \r\n\r\nInternal to the  `FirstOrderUnsteadySolver` and subclasses, I've added functionality to deal with assembling the `\\dot{u} =v` equations and the underlying infrastructure, including adding the `v` equations to the `FEMSystem`, setting the boundary conditions for `v`, etc. The resulting changes to `EulerSolver` and `Euler2Solver` were pretty minimal: we need to prepare `accel` data in the `FEMContext` so the user can use the `*_accel` methods in their code to preserve compability between ` FirstOrderUnsteadySolver` classes and  `SecondOrderUnsteadySolver` classes and then call `damping` functions and assemble the `\\dot{u} = v` equations. (See commit \t2040d79 for the specific changes to those classes, supporting infrastructure was in previous commits in this PR.)\r\n\r\nFrom the user perspective in the `FEMSystem` subclass, if they want their second order in time problem to be solved as a first order in time problem, they'll need to make the following changes:\r\n\r\n1. Use the new `time_evolving` API to specify second order variables\r\n2. For the steady parts of the residual, they'll need to test if the `TimeSolver` is steady or not and, if not, they'll need to use the `UnsteadySolver::get_second_order_dot_var` method to extract the \"velocity\" variable index (v in the notation above) corresponding to their second order variable (u in the notation above). This is required also in the unsteady parts of the residual, e.g. `FEMSystem::mass_residual`, but obviously the user doesn't need to check if they have a steady time solver or not. Note that if the `TimeSolver` is actually second order, the velocity index returned is just the second order variable index (u) - this is how we get compatibility between the two `TimeSolver` types.\r\n3. Assemble into the velocity part of the residual corresponding to the velocity index the user got in step 2. Similarly, assemble into the appropriate blocks of the Jacobian.\r\n\r\nThere should be no other changes required from the user perspective in the `FEMSystem` class itself. Existing second order `FEMSystem` programs would also need to adjust projecting the initial velocity, if they are specifying it, based on the `TimeSolver` type (i.e. instead of calling `SecondOrderUnsteadySolver::project_initial_rate`, they'll just project onto the \"dot\" variables in the projection functor); also wouldn't need to compute initial acceleration.\r\n\r\nAgain, I was hoping the user wouldn't have to change their element assembly routines to gain this capability, but I don't see any other way. If they don't desire these features and only want to use `SecondOrderUnsteadySolver` types, then they don't need to change anything. But if anyone (like me) wants to FSI with `FEMSystem` and use existing `FirstOrderUnsteadySolver` types, they'll need to do this.\r\n\r\nFeedback particularly welcome on the documentation. I've tried to be verbose in the code and the example, but obviously if there are still confusing points, we should make it clearer in the documentation."},"comment":{"url":"https://api.github.com/repos/libMesh/libmesh/issues/comments/285419681","html_url":"https://github.com/libMesh/libmesh/pull/1259#issuecomment-285419681","issue_url":"https://api.github.com/repos/libMesh/libmesh/issues/1259","id":285419681,"user":{"login":"pbauman","id":3051555,"avatar_url":"https://avatars0.githubusercontent.com/u/3051555?v=3","gravatar_id":"","url":"https://api.github.com/users/pbauman","html_url":"https://github.com/pbauman","followers_url":"https://api.github.com/users/pbauman/followers","following_url":"https://api.github.com/users/pbauman/following{/other_user}","gists_url":"https://api.github.com/users/pbauman/gists{/gist_id}","starred_url":"https://api.github.com/users/pbauman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pbauman/subscriptions","organizations_url":"https://api.github.com/users/pbauman/orgs","repos_url":"https://api.github.com/users/pbauman/repos","events_url":"https://api.github.com/users/pbauman/events{/privacy}","received_events_url":"https://api.github.com/users/pbauman/received_events","type":"User","site_admin":false},"created_at":"2017-03-09T17:25:30Z","updated_at":"2017-03-09T17:25:30Z","body":"Sorry, I got slammed. I'll finish this out now (I have an interruption at 1). in addition to testing the complex/ifdef thing, I need to address @roystgnr's comment about keeping the input file around and overriding via the command line. Shouldn't take too long.\r\n\r\nAnd yes, I would love for this to go into v1.2."}}
{"actor":{"display_login":"pbauman"}}