{"action":"created","issue":{"url":"https://api.github.com/repos/idaholab/moose/issues/4638","labels_url":"https://api.github.com/repos/idaholab/moose/issues/4638/labels{/name}","comments_url":"https://api.github.com/repos/idaholab/moose/issues/4638/comments","events_url":"https://api.github.com/repos/idaholab/moose/issues/4638/events","html_url":"https://github.com/idaholab/moose/pull/4638","id":56437539,"number":4638,"title":"Integration branch (Uniform refine earlier)","user":{"login":"permcody","id":3036960,"avatar_url":"https://avatars.githubusercontent.com/u/3036960?v=3","gravatar_id":"","url":"https://api.github.com/users/permcody","html_url":"https://github.com/permcody","followers_url":"https://api.github.com/users/permcody/followers","following_url":"https://api.github.com/users/permcody/following{/other_user}","gists_url":"https://api.github.com/users/permcody/gists{/gist_id}","starred_url":"https://api.github.com/users/permcody/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/permcody/subscriptions","organizations_url":"https://api.github.com/users/permcody/orgs","repos_url":"https://api.github.com/users/permcody/repos","events_url":"https://api.github.com/users/permcody/events{/privacy}","received_events_url":"https://api.github.com/users/permcody/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":21,"created_at":"2015-02-03T21:09:22Z","updated_at":"2015-02-05T17:59:21Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/idaholab/moose/pulls/4638","html_url":"https://github.com/idaholab/moose/pull/4638","diff_url":"https://github.com/idaholab/moose/pull/4638.diff","patch_url":"https://github.com/idaholab/moose/pull/4638.patch"},"body":"This PR moves the uniform refinement steps up into the mesh setup stage. The original code path remains for the case where restart and uniform refinements are both needed. \r\n\r\nImportant note: The definition of what uniform_refinement means has changed for oversampled meshes. Previously that number assumed how many refinements you wanted from the original mesh, now we have defined it to mean the number of refinements to apply after the mesh has been setup which included the initial uniform refinement steps.\r\n\r\nIncludes a small bug fix for setting _current_task when executing Actions individually. "},"comment":{"url":"https://api.github.com/repos/idaholab/moose/issues/comments/73094070","html_url":"https://github.com/idaholab/moose/pull/4638#issuecomment-73094070","issue_url":"https://api.github.com/repos/idaholab/moose/issues/4638","id":73094070,"user":{"login":"jwpeterson","id":1775907,"avatar_url":"https://avatars.githubusercontent.com/u/1775907?v=3","gravatar_id":"","url":"https://api.github.com/users/jwpeterson","html_url":"https://github.com/jwpeterson","followers_url":"https://api.github.com/users/jwpeterson/followers","following_url":"https://api.github.com/users/jwpeterson/following{/other_user}","gists_url":"https://api.github.com/users/jwpeterson/gists{/gist_id}","starred_url":"https://api.github.com/users/jwpeterson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jwpeterson/subscriptions","organizations_url":"https://api.github.com/users/jwpeterson/orgs","repos_url":"https://api.github.com/users/jwpeterson/repos","events_url":"https://api.github.com/users/jwpeterson/events{/privacy}","received_events_url":"https://api.github.com/users/jwpeterson/received_events","type":"User","site_admin":false},"created_at":"2015-02-05T17:59:21Z","updated_at":"2015-02-05T17:59:21Z","body":"On Thu, Feb 5, 2015 at 10:44 AM, Cody Permann <notifications@github.com>\nwrote:\n\n> @roystgnr <https://github.com/roystgnr> and @jwpeterson\n> <https://github.com/jwpeterson> - @friedmud <https://github.com/friedmud>\n> discovered that the issue had to do with our use of\n> MeshBase::skip_partitioning(true) so I started messing around with that. We\n> have this turned off because of #4532\n> <https://github.com/idaholab/moose/issues/4532>. It turns out that we are\n> apparently calling that method \"too late\" but we have always called it\n> rather late.\n>\n> I hardcoded the skip partitioning call right after the uniform refinement\n> calls and this test case ran. The problem is that we only want to disable\n> partitioning for the very specific case spelled out in #4532\n> <https://github.com/idaholab/moose/issues/4532>. Now that we are doing\n> these refinements first I don't have all of the information available to\n> make that decision so I'm at a point where I'm trying to understand the\n> specific issue of why this doesn't work to figure out the right place.\n>\n> Current MOOSE workflow looks like this (simplified):\n> 1. build or read mesh\n> 2. prepare\n> 3. modify mesh (optional)\n> 4. prepare again (if mesh was modified)\n> 5. setup the rest of MOOSE\n> 6. skip partitioning if applicable (#4532\n> <https://github.com/idaholab/moose/issues/4532>)\n> 6. start running simulation\n> 7. build coarsening and refinement maps using mesh and mesh refinement\n> utilities\n> 8. uniform refine\n>\n> This PR moves step 8 to step 3.5 which breaks due to the skip partitioning\n> in 6. I already mentioned that If I hard code 6 at 3.6 it fixes this case.\n> What I don't understand is why this is issue. Clearly we are getting away\n> with preparing the mesh in 2 and 4 without the skip partitioning flag now.\n>\nIn a different attempt to fix the issue I attempted to add yet another\n> mesh.prepare() call at 6.1 which did not change anything.\n>\nI'm failing to understand why the partitioning appears to get hosed when\n> moving around the refinement even after calling prepare yet again. Any\n> insight would be helpful.\n>\nI'm not sure I understood all that, but what I think you are saying is that\nuniform refining *before* preparing the mesh (while skipping partitioning)\nbreaks stateful material properties in MOOSE, while uniform refining after\nlater does not?\n\n-- \nJohn\n"}}