View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002678 | OpenFOAM | Contribution | public | 2017-08-25 09:03 | 2017-10-20 11:39 |
Reporter | Shorty | Assigned To | henry | ||
Priority | low | Severity | feature | Reproducibility | have not tried |
Status | closed | Resolution | suspended | ||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 16.04 |
Product Version | dev | ||||
Summary | 0002678: New features | developments on 'openComfort' and 'flattenPatch' | ||||
Description | Hi all, the last weeks I developed a few new things for OpenFOAM. However, I am not sure if this would be interesting for you or not. a) openComfort -------------- It is a library that allows a thermal comfort analyzes based on EN ISO 7730. It could be included to the postProcess application. But I think this is a too special library to add to the source code. b) flattenPatch --------------- After meshing with sHM I have e.g. symmetryPlanes, inlets etc. not aligned in one plane. For a flowRateInletVelocity or a surfaceNormal... inlet this is really a very bad thing (although for symmetryPlanes). Right now the patches only can be flatten orthogonal to the x-, y- and z-plane while setting the corresponding coordinate. However, for random patches, I was thinking to generate the average normal vector and flatten the patch based on that (as second option). If this would be interesting, I can extend it, or if you have other suggestions. If both are not of interest, I let them as they are and go on in the 2D refinement library. Tobi | ||||
Tags | flattenPatch | ||||
|
a) openComfort Have you already released this for people to test and provide feedback? b) flattenPatch If you flatten patches generated by snappyHexMesh do you find that corner cells which do not match the patch plane and/or corners become very poor quality or even negative volume? Do you include a constraint to ensure that the snappyHexMesh cell quality specifications are maintained? Given the possibility that this flattening might distort cells to the point that the simulation fails wouldn't it be better to use "symmetry" rather than "symmetryPlane" at least if the resulting mesh is very poor quality? > I was thinking to generate the average normal vector Given that the average normal would not be correct in the cases you want to fix it would be better if the correct patch orientation is specified either as a command line option or a dictionary entry. |
|
a) OpenComfort I released it today in the night. It is new and people can test it now (waiting for feedback) b) flattenPatch Till now I did never get a negative or poor quality cell for snappyHexMesh meshes. Maybe you are right if the corners cannot be mapped by snappyHexMesh. I will check it, I have some cases at home in which I can check it but for my geometries I used right now, I did not have any problems. A mesh check can be included. The first shot could be like as follows: undo all changes if mesh quality is worse than before. > Specify normal vector That is not a big deal and can be add to the tool. |
|
> wouldn't it be better to use "symmetry" rather than "symmetryPlane" at least if the resulting mesh is very poor quality? Yes, I agree. However, for solid mechanics (solidDisplacementFoam + extention) I realized that the symmetry is worse than symmetryPlane. Thats why I made that utility. |
|
Waiting for updated patch. |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-08-25 09:03 | Shorty | New Issue | |
2017-08-25 09:03 | Shorty | Tag Attached: flattenPatch | |
2017-08-25 10:03 | henry | Note Added: 0008632 | |
2017-08-25 10:25 | Shorty | Note Added: 0008634 | |
2017-08-25 10:28 | Shorty | Note Added: 0008635 | |
2017-09-02 10:09 | wyldckat | Summary | New features | developments => New features | developments on 'openComfort' and 'flattenPatch' |
2017-10-20 11:39 | henry | Assigned To | => henry |
2017-10-20 11:39 | henry | Status | new => closed |
2017-10-20 11:39 | henry | Resolution | open => suspended |
2017-10-20 11:39 | henry | Note Added: 0008901 |