Node/element diameters need to be updated with MoveMesh

[zhang-alvin]

Mandatory Checklist

Please ensure that the following criteria are met:

• Title of pull request describes the changes/features
• Request at least 2 reviewers
• If new files are being added, the files are no larger than 100kB. Post the file sizes.
• Code coverage did not decrease. If this is a bug fix, a test should cover that bug fix. If a new feature is added, a test should be made to cover that feature.
• New features have appropriate documentation strings (readable by sphinx)
• Contributor has read and agreed with CONTRIBUTING.md and has added themselves to CONTRIBUTORS.md

As a general rule of thumb, try to follow PEP8 guidelines.

Description

Referring to one of a few problems described in #1179. This PR is simply to get correctness in place. Later PRs will include tests based on a pseudo-adapted mesh.

Update for simplex meshes only in postStep()

[codecov]

Codecov Report

Merging #1182 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #1182   +/-   ##
=======================================
  Coverage   50.70%   50.70%           
=======================================
  Files         541      541           
  Lines      109380   109390   +10     
=======================================
+ Hits        55456    55466   +10     
  Misses      53924    53924           

Impacted Files	Coverage Δ
proteus/mprans/MoveMesh.py	86.35% <100.00%> (+0.23%)	⬆️
proteus/tests/test_boundaryconditions.py	97.33% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c878cdc...9a1ec42. Read the comment docs.

[cekees]

Looks good. Not suggesting this idea for this PR, but I think it would be nice to sit down one day and review/discuss our mesh API in light of our current workflows for a) initial mesh generation b) mesh motion (r-adaptivity), and c) h-adaptivity. Seems like we could probably make these stages more general to allow for some variations in the future, like quad/hex meshes, mixed cell types, etc.

[zhang-alvin]

Looks good. Not suggesting this idea for this PR, but I think it would be nice to sit down one day and review/discuss our mesh API in light of our current workflows for a) initial mesh generation b) mesh motion (r-adaptivity), and c) h-adaptivity. Seems like we could probably make these stages more general to allow for some variations in the future, like quad/hex meshes, mixed cell types, etc.

Yes. In this scenario, maybe we can have an update mesh function that's an abstract function of the Mesh object.