questionable behaviour with blockMesh and paraview

tutorials/basic/potentialFoam/cylinder, or tutorials/basic/potentialFoam/pitzDaily

• Allrun
• paraFoam -block
• polyMesh contents are erased!

@andy @Prashant

This is rather intriguing to me... I've tested tutorials/basic/potentialFoam/pitzDaily with OpenFOAM-dev back to 4.x, 3.0.x and 2.4.x (edit: and 2.3.x) and all exhibit the same behaviour.

By Bruno Santos on 2016-12-14T22:44:44 (imported from GitLab project)

Meaning the same good or bad behaviour?

Meaning that it was possibly done so by design... although after a quick search, I couldn't find where it does the disappearing act, in order to try and use the OpenFOAM-history repository to get some more historic reasoning behind this implementation.

I can only guess that this was designed this way, to avoid getting ambiguous results from another instance of a normal session with paraFoam that was showing another mesh. Furthermore, it was possibly conceived that a button for running blockMesh internally would be helpful to get a final render, but never got implemented... but the removal of the old mesh was implemented nonetheless with that intent.

But still... I'm intrigued as to how this wasn't spotted any time sooner... perhaps people run blockMesh manually after modifying the dict?

By Bruno Santos on 2016-12-14T23:44:37 (imported from GitLab project)

I guess I should have been more specific with the question (instead of using good/bad). Do you observe removal of polyMesh/*when invoking the blockMesh viewer in paraview?

Using OpenFOAM-dev (relatively recent build) and the blockMesh viewer within ParaView, whenever I click on the Refresh button, the files are deleted. Furthermore, I get the following output on the command line whenever I click on that button:

No non-planar block faces defined
Creating topology blocks
Creating topology patches

Creating block mesh topology

Check topology

	Basic statistics
		Number of internal faces : 18
		Number of boundary faces : 42
		Number of defined boundary faces : 42
		Number of undefined boundary faces : 0
	Checking patch -> block consistency

Creating block offsets
Creating merge list .

I have the indistinct feeling that this is done by libblockMesh when it starts generating the mesh, so that it doesn't pick up any past files when setting up the mesh in memory. I have the vague idea that several years ago the boundary file was re-used by blockMesh, so maybe this is an inheritance from that?

By Bruno Santos on 2016-12-15T00:13:59 (imported from GitLab project)

The root cause is that blockMesh is creating a polyMesh from a cellShapeList - the corresponding polyMesh constructor calls removeFiles(instance()) - see polyMeshFromShapeMesh.C. I think the side-effect within the viewer is really quite undesirable, but you are right: why wasn't it noticed before?

Reassigned to @mark

Wow, OK, it's because it's constructing a new mesh. The comment above it even states:

// Remove all of the old mesh files if they exist
removeFiles(instance());

It makes some sense that it cleans up when generating a new mesh... a quick workaround would be to change the instance to be something more ethereal...

---

Checking the history repository, this was already being used when the git repo was started with 1.5.x... checking my git repo with the releases from 1.1 to 1.5, it was defined in src/OpenFOAM/meshes/polyMesh/createPolyMesh.C instead, but the same thing was done, i.e. remove files on construction. In OpenFOAM 1.1 it used to be:

    // Remove all of the old mesh files if they exist
    removeFiles(db().path());

As for why no-one noticed: It's not explained in neither the User Guides (Foundation or Plus), which means that this reduces considerably the number of people who could stumble on this :(

By Bruno Santos on 2016-12-15T23:45:00 (imported from GitLab project)

Mentioned in commit 2e047d184a8f149a9dfc436c60e1eb2d398f5555

Status changed to closed

See related followup #348 (closed)