Issues with mesquite port to OF2.3

[tonyladd]

Sandeep

I have been getting familiarized with your port of mesquite to OpenFOAM-2.3.0. At present I am just working with mesquite although I intend to try topological changes later.

I am stuck at several points. One I think is a bug; the others may be my lack of understanding. I have been working from some examples (circCylinder3d and circCylinder3dHex) both of which run fine in serial mode and look like the results from foam-extend-3.0. My own geometry is slightly different - 2D (single hex domain) with symmetry plane or cyclic boundaries on the sides. You can see the cases here:

https://drive.google.com/folderview?id=0B6owJMU2ccxDVGZLZHhuUGtPWm8&usp=sharing

The dynamic mesh dict was taken from circCylinder3dHex. The issues are:

1) With a cyclic patch (stefancyc.zip) the points go totally haywire on the first iteration. 2) With a symmetryPlane it runs OK but it does not move the points along the edges between two patches. I think this is the same in the test cases where edge points are not moved either as far as I can see. But in cases such as mine the edge points need to move as well. It seems from the documentation that mesquite can do this but I don't know how to work the interface in OpenFOAM. It is the same in foam-extend-3.0. Any hints. 3) I noticed that the circCylinder3dHex example crashes in parallel (its fine in serial mode). The error is Unknown type for cell: 6 :: 6(24 25 26 1883 2117 20)[1] Unknown type for cell: 224 :: 6(649 650 651 2098 2147 627)[0] #0 [1] #0 Foam::error ::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at ??:? This case runs in foam-extend-3.0

Thanks

Tony

[smenon]

Hello Tony,

A few comments: 1) I noticed only today that cyclics have been upgraded for recent OpenFOAM versions, where both halves reside on separate patches. I haven't updated the mesquiteMotionSolver to handle this yet. It probably won't be too much extra work, but will take a bit of time. 2) What you're looking for is a slip boundary condition, which I haven't implemented in a robust way yet. I'll look into this when I have some time. 3) I'm aware of this issue, and I'm looking at possible solutions. Perhaps you could try the "standardCellTypes yes;" option and see if that works for now. Hopefully, I can implement a more general solution soon.

[tonyladd]

Sandeep

Thanks for the quick reply. I guessed that cyclic was to do with the different numberings. It goes wrong 1/2 way along the patch, which was a bit of a giveaway

How is a slip boundary condition different from a slip patch. Is it the question of the edge motion? We need to be able to specify mobile edges (defined as the common line between two patch fields?) so the points can relax along the edge.

The "standardCellTypes yes;" option worked! :)

We appreciate the usefulness of the port to OpenFOAM. We have found OF has fewer problems that foam-extend (not surprisingly) but the lack of topological change is a significant limitation. I am unclear why ESI does not implement dynamicTopoFvMesh, particularly since you have done almost all the work for them!

I want to get started with dynamicTopoFvMesh, using one of the standard solvers (while the mesquite issues get resolved). Can I use it with a 2D mesh. I would rather not triangulate the cells except on the top and bottom ("empty") faces. Can I make topological changes on such a mesh. Do you have a 2D case I could look at?

Regards

Tony

On 12/08/2014 12:06 PM, Sandeep Menon wrote:

Hello Tony,

A few comments: 1) I noticed only today that cyclics have been upgraded for recent OpenFOAM versions, where both halves reside on separate patches. I haven't updated the mesquiteMotionSolver to handle this yet. It probably won't be too much extra work, but will take a bit of time. 2) What you're looking for is a slip boundary condition, which I haven't implemented in a robust way yet. I'll look into this when I have some time. 3) I'm aware of this issue, and I'm looking at possible solutions. Perhaps you could try the "standardCellTypes yes;" option and see if that works for now. Hopefully, I can implement a more general solution soon.

— Reply to this email directly or view it on GitHub https://github.com/smenon/dynamicTopoFvMesh/issues/12#issuecomment-66148365.

Tony Ladd

Chemical Engineering Department University of Florida Gainesville, Florida 32611-6005 USA

Email: tladd-"(AT)"-che.ufl.edu Web http://ladd.che.ufl.edu

Tel: (352)-392-6509 FAX: (352)-392-9514

[smenon]

Hello Tony,

I've done a partial re-write of mesquiteMotionSolver (in the SurfaceSmoothingRewrite branch), and now your "slip" requirement works. I still don't have parallel support yet, but I'll work on that at some point. I've also made a few modifications to upgrade cyclics to the new OpenFOAM format.

Let me know if it works.

Thanks, Sandeep

[tonyladd]

Sandeep

Thanks for taking the time to work on this. I will check this out as soon as I get a chance.

Best

Tony

On 03/17/2015 04:25 PM, Sandeep Menon wrote:

Hello Tony,

I've done a partial re-write of mesquiteMotionSolver (in the SurfaceSmoothingRewrite branch), and now your "slip" requirement works. I still don't have parallel support yet, but I'll work on that at some point. I've also made a few modifications to upgrade cyclics to the new OpenFOAM format.

Let me know if it works.

Thanks, Sandeep

— Reply to this email directly or view it on GitHub https://github.com/smenon/dynamicTopoFvMesh/issues/12#issuecomment-82582888.

Tony Ladd

Chemical Engineering Department University of Florida Gainesville, Florida 32611-6005 USA

Email: tladd-"(AT)"-che.ufl.edu Web http://ladd.che.ufl.edu

Tel: (352)-392-6509 FAX: (352)-392-9514

[tonyladd]

Sandeep

I have tried the simplest cases that were causing problems. Happily they now work fine - both the sliding edges and the cyclic patch. Thank-you for putting the time in to help us.

However it seems that it has a problem relaxing the points if the surface is not flat. The attached case only uses moveDynamicMesh but it goes horribly wrong if I try to relax the curved surface (int2ext). If I make it flat (blockMeshDIct.Flat) its fine.

The relaxation along the cyclic and empty patches is also perfect, but they are flat as well.

In a presentation on Mesquite I saw that it preserves the initial grading of a mesh without additional constraints (or so it said) but when I input a graded mesh it is restored to uniform immediately. I am sure there is a way to make it keep the grading but I am rather lost with many aspects of the dynamicMeshDict for mesquite. I have read Kyle's write up on "Use of dynamicTopoFvMesh class" but it was not very detailed about the options for mesquite. Is there another place to look.

Regards

Tony

On 03/17/2015 04:25 PM, Sandeep Menon wrote:

Hello Tony,

I've done a partial re-write of mesquiteMotionSolver (in the SurfaceSmoothingRewrite branch), and now your "slip" requirement works. I still don't have parallel support yet, but I'll work on that at some point. I've also made a few modifications to upgrade cyclics to the new OpenFOAM format.

Let me know if it works.

Thanks, Sandeep

— Reply to this email directly or view it on GitHub https://github.com/smenon/dynamicTopoFvMesh/issues/12#issuecomment-82582888.

Tony Ladd

Chemical Engineering Department University of Florida Gainesville, Florida 32611-6005 USA

Email: tladd-"(AT)"-che.ufl.edu Webhttp://ladd.che.ufl.edu

Tel: (352)-392-6509 FAX: (352)-392-9514

[smenon]

Hello Tony,

Unfortunately, I don't see your attachment. You might have to share it via google drive, or e-mail it to me directly.

Sandeep

[tonyladd]

Sandeep

The zip file is on my google drive - stefanTest.zip

https://drive.google.com/folderview?id=0B6owJMU2ccxDVGZLZHhuUGtPWm8&usp=sharing

[smenon]

Tony,

I spent a little time on your case, and tried to play around with the edge-constant settings to see if it helped, but it wasn't of much use. In your curved surface scenario, I would recommend having only the "Y1" and "Y2" patches in the slipPatches list. Since the "int2ext" surface is faceted, it wouldn't be too clear what geometry the smoother is meant to conform to. Are you anticipating the "int2ext" to deform as well?

Any chance you could try this with tetrahedral meshes in 3D using similar settings?

[tonyladd]

Sandeep

Thanks for checking into it. The patch int2ext is deforming in response to a concentration gradient. The movie stefanM.ogv at

https://drive.google.com/drive/#folders/0B6owJMU2ccxDVGZLZHhuUGtPWm8

shows a typical calculation. There are two regions separated by a slightly perturbed flat boundary. I solve for Darcy flow in each region with two different permeabilities (Laplace equations) using regionCouplePatch to match the pressure and normal velocity across the boundary. Then I solve a convection-diffusion equation in the inner region and move the boundary in proportion to the local concentration gradient.

The version in the movie uses mesquite, but I have to relax the vertexes along the int2ext myself. Its easy to stay on the piecewise polynomial surface in this case. Do you have any idea why mesquite goes so badly wrong unless the boundary is flat. I thought it could relax an arbitrary surface mesh.

I can try with a 3D tetrahedral mesh in the future; I am still on a learning curve here. I am a bit busy with classes until the semester ends.

I was wondering if you had plans for further development of the openfoam-mesquite interface. We need general surface relaxation algorithms and official OF does not seem to have them, apart from your library. We had a number of problems with foam-extend and so we switched to the official version. My postdoc (who does all the C++ coding) favors the official version, based on his experiences. He has written some surface relaxation algorithms (for 2.3.x) using Laplace smoothing and various forms of projection. It works but it is not very general, so we were hoping mesquite would be a better long term solution. But the surface relaxation has me concerned and you also said there were problems with parallelization. Do you see any chance of you addressing these issues or does someone else need to pick up where you left off.

Best

Tony

On 03/24/2015 03:53 PM, Sandeep Menon wrote:

Tony,

I spent a little time on your case, and tried to play around with the edge-constant settings to see if it helped, but it wasn't of much use. In your curved surface scenario, I would recommend having only the "Y1" and "Y2" patches in the slipPatches list. Since the "int2ext" surface is faceted, it wouldn't be too clear what geometry the smoother is meant to conform to. Are you anticipating the "int2ext" to deform as well?

Any chance you could try this with tetrahedral meshes in 3D using similar settings?

— Reply to this email directly or view it on GitHub https://github.com/smenon/dynamicTopoFvMesh/issues/12#issuecomment-85667348.

Tony Ladd

Chemical Engineering Department University of Florida Gainesville, Florida 32611-6005 USA

Email: tladd-"(AT)"-che.ufl.edu Web http://ladd.che.ufl.edu

Tel: (352)-392-6509 FAX: (352)-392-9514

[smenon]

Tony,

Firstly, I need to clarify here. Although it's called "mesquiteMotionSolver", actual calls to Mesquite are only made in 3D scenarios. Mesquite cannot optimize mesh vertices on complicated surfaces; only volumetric meshes. All surface points are held as fixed, while Mesquite optimizes on internal vertices.

For a 2D mesh like the ones you've given me so far, a spring-analogy laplacian solver is used on all surfaces (since there are no "internal vertices" for a 2D mesh, there's nothing that Mesquite can do anyway).

In a 3D scenario, all "slip" surfaces are updated first using the same spring-analogy laplacian - this includes relaxing along curved surfaces, where points move on a locally tangential plane. Naturally, if there is significant curvature, you would want to perform several sweeps with small local changes such that the original curvature is maintained. Once this is done, the surfaces are "fixed", and mesquite is then invoked to optimize the interior vertices.

The trouble is, you can only deform your mesh to a certain degree before skewness destroys your simulation, and you'll have to remesh at some point. This is why I recommend remeshing (using dynamicTopoFvMesh) with triangle / tetrahedral meshes along with smoothing methods. With a quad / hexahedral mesh, you can't really remesh locally (at least, this library doesn't).

The parallelization issues have been addressed in recent commits, and I'm occasionally available to resolve bug-fixes.

Keep me posted, Sandeep

[tonyladd]

Sandeep

Thanks for the clarification - that is really helpful. I did not understand that Mesquite cannot relax a surface mesh.

Can you explain then why the spring model is not able to relax the curved boundary. Is it because of the 2D switch? Or the quadrilateral faces?

I realize I need to switch to a triangular mesh - I was just trying to see how far I could get without remeshing. I will get to that as soon as I can.

Great news that the parallelization is fixed. We have a number of other problems which need to move a surface mesh.

Thanks again for your work.

Best

Tony

On 03/27/2015 05:54 PM, Sandeep Menon wrote:

Tony,

Firstly, I need to clarify here. Although it's called "mesquiteMotionSolver", actual calls to Mesquite are only made in 3D scenarios. Mesquite cannot optimize mesh vertices on complicated surfaces; only volumetric meshes. All surface points are held as fixed, while Mesquite optimizes on internal vertices.

For a 2D mesh like the ones you've given me so far, a spring-analogy laplacian solver is used on all surfaces (since there are no "internal vertices" for a 2D mesh, there's nothing that Mesquite can do anyway).

In a 3D scenario, all "slip" surfaces are updated first using the same spring-analogy laplacian - this includes relaxing along curved surfaces, where points move on a locally tangential plane. Naturally, if there is significant curvature, you would want to perform several sweeps with small local changes such that the original curvature is maintained. Once this is done, the surfaces are "fixed", and mesquite is then invoked to optimize the interior vertices.

The trouble is, you can only deform your mesh to a certain degree before skewness destroys your simulation, and you'll have to remesh at some point. This is why I recommend remeshing (using dynamicTopoFvMesh) with triangle / tetrahedral meshes along with smoothing methods. With a quad / hexahedral mesh, you can't really remesh locally (at least, this library doesn't).

The parallelization issues have been addressed in recent commits, and I'm occasionally available to resolve bug-fixes.

Keep me posted, Sandeep

— Reply to this email directly or view it on GitHub https://github.com/smenon/dynamicTopoFvMesh/issues/12#issuecomment-87102912.

Tony Ladd

Chemical Engineering Department University of Florida Gainesville, Florida 32611-6005 USA

Email: tladd-"(AT)"-che.ufl.edu Web http://ladd.che.ufl.edu

Tel: (352)-392-6509 FAX: (352)-392-9514

[smenon]

Hello Tony,

The problem in your case was that triple-points (i.e., points where 3 patches converge) needed to be fixed as a reference point for the laplacian, and I've addressed this issue in commit b93d3320c41014db2bebc6cf5bc6a5db9f832e81

This resolves the curved boundary issue, and now you can relax on all surfaces and get the expected result. So, something like this:

slipPatches
{
    int2ext;
    Y1;
    Y2;
}

It still doesn't fully respect the refinement towards the "int2ext" boundary, but you can play around with the edgeConstant_ field to specify a variable stiffness for each edge. If you specify a "nonUniformEdgeConstant" entry under mesquiteOptions, you'll see the available options:

    "magLength",
    "invLength",
    "magSqrLength",
    "invSqrLength",
    "constant",
    "disabled"

They probably need to be tweaked on a per-edge basis, and I leave it up to you to decide what works best. This turned out to be an interesting endeavor, so thanks for reporting it. You can re-open this issue if you find any other problems.

Thanks, Sandeep