{"action":"opened","issue":{"url":"https://api.github.com/repos/libMesh/libmesh/issues/2106","repository_url":"https://api.github.com/repos/libMesh/libmesh","labels_url":"https://api.github.com/repos/libMesh/libmesh/issues/2106/labels{/name}","comments_url":"https://api.github.com/repos/libMesh/libmesh/issues/2106/comments","events_url":"https://api.github.com/repos/libMesh/libmesh/issues/2106/events","html_url":"https://github.com/libMesh/libmesh/issues/2106","id":434997198,"node_id":"MDU6SXNzdWU0MzQ5OTcxOTg=","number":2106,"title":"EquationSystems::write() with overlapping nodes","user":{"login":"ajamar1","id":44416933,"node_id":"MDQ6VXNlcjQ0NDE2OTMz","avatar_url":"https://avatars2.githubusercontent.com/u/44416933?v=4","gravatar_id":"","url":"https://api.github.com/users/ajamar1","html_url":"https://github.com/ajamar1","followers_url":"https://api.github.com/users/ajamar1/followers","following_url":"https://api.github.com/users/ajamar1/following{/other_user}","gists_url":"https://api.github.com/users/ajamar1/gists{/gist_id}","starred_url":"https://api.github.com/users/ajamar1/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ajamar1/subscriptions","organizations_url":"https://api.github.com/users/ajamar1/orgs","repos_url":"https://api.github.com/users/ajamar1/repos","events_url":"https://api.github.com/users/ajamar1/events{/privacy}","received_events_url":"https://api.github.com/users/ajamar1/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2019-04-18T23:29:40Z","updated_at":"2019-04-18T23:29:40Z","closed_at":null,"author_association":"NONE","body":"Hello,\r\n\r\nI will certainly attempt to follow this up with a small example if necessary, but I thought I'd describe the issue first in case the problem was obvious.\r\n\r\nWe run problems where a mesh has co-located nodes, such that adjacent elements visually interface, but topologically they do not.  For the example drawn below for two quads, nodes B and 0 would have the exact same coordinates, but they are indeed two different nodes in the mesh with their own DoFs.  Same goes for C and 3.  Hence, elements E1 and E2 are not actually neighbors since they don't share nodes. Further, E1 and E2 are in different subdomains with subdomain restricted variables, which are different from each other (that nugget may just be a red herring).\r\n\r\nA---------B  0---------1\r\n|      E1       |   |        E2    |\r\n|                 |   |                |\r\nD---------C 3---------2\r\n\r\nIn 3D (cannot yet confirm if this is a problem in 2D too), when writing a restart file via EquationSystems::write() and subsequently reading it with EquationSystems::read(), we are seeing that the DoFs for node 0 and 3 will get the values for nodes B and C respectively.  I am curious if \r\n\r\nMeshTools::Private::globally_renumber_nodes_end_elements() --> MeshCommunication().assign_global_indices() --> ComputeHilbertKeys() --> get_dofobject_key() --> get_hilbert_coords() \r\n\r\nlogic thread cannot differentiate two nodes at the same location from each other thereby, jumbling up the solution vector values in the restart file.\r\n\r\nThanks for the consideration.  Let me know if I need to create an example.\r\n\r\nAdam"}}
{"actor":{"display_login":"ajamar1"}}