Added a few comments regarding recent bugfixes

src/decompositionMethods/decomposeReconstruct/decomposeTools/finiteVolume/decomposeMesh.C

@@ -470,10 +470,12 @@ void Foam::domainDecomposition::decomposeMesh(const bool filterEmptyPatches)
                 // list of neigbhour (for master proc or owner for slave proc)
                 // cells. We'll sort the list of neighbouring cells and use the
                 // indices to add the patch faces in the correct order later
-                // on. There's probably a million other ways to write this in a
-                // better way, but I can't figure them out at the moment.
-                // VV, 16/Feb/2019.
-                Map<Pair<dynamicLabelList> > faceCellToNbrFaceCells(fc.size()/10);
+                // on. VV, 16/Feb/2019.
+                Map<Pair<dynamicLabelList> > faceCellToNbrFaceCells
+                (
+                    // Reasonable size estimate (minimum = 10)
+                    max(10, fc.size()/10)
+                );
 
                 forAll (fc, patchFaceI)
                 {

src/dynamicMesh/dynamicMesh/polyTopoChange/polyTopoChanger/polyTopoChangerChangeMesh.C

@@ -2490,12 +2490,15 @@ Foam::autoPtr<Foam::mapPolyMesh> Foam::polyTopoChanger::changeMesh()
             topoChangeRequest()()
         );
 
+        // Mesh data needs to be updated before the update of polyMeshModifiers
+        // because polyMeshModifiers might need all the new polyMesh data (see
+        // below for further comments). VV, 19/Feb/2019
         mesh_.updateMesh(topoChangeMap());
 
         // Bugfix: call to polyTopoChanger::update must happen after
         // polyMesh::updateMesh where all the relevant mesh bits for parallel
         // comms are updated. First noticed when the syncying of pointLevel in
-        // refinement::updateMesh was syncying properly. VV, 19/Feb/2019
+        // refinement::updateMesh was not syncying properly. VV, 19/Feb/2019
         update(topoChangeMap());
 
         // Increment the morph index