butterfly cfd outdoor 3d error: cannot find file poitns in directory polymesh in times 0 down to constant.

Cannot find file points in directory polymesh in times 0 down to constant.

what does this mean? The model file is from sketch up, and it is not all closed brep so I converted it to a mesh before place input into Buttefly_Create Butterfly Geometry.

The resulting mesh however, has many naked edges. Does the geometry need to have 0 naked edges?

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Mostapha Sadeghipour Roudsari on April 17, 2017 at 6:45am

Naked edges will result in generating unnecessary meshes in the areas that does not necessarily important for your study. It's always easier to debug if you don't run the case in parallel. What happens when you try to run the solution not in parallel?

Permalink Reply by yj on April 19, 2017 at 12:12pm

Thank you for reply, I simplied the case a lot and tried only cfd on only a part of the project but somehow the forces are not interacting with the building volumens at all.

Also tried not running cfd in parallel but doesn't seem to solve the case. Attaching files, checked the case study is within the bounding box.

3dm file

https://drive.google.com/open?id=0B8u1qSty0juhaURCMmQ0czdYeVk

gh file

https://drive.google.com/open?id=0B8u1qSty0juhNE5Dc3JOVlY5SG8

Permalink Reply by Theodoros Galanos on April 18, 2017 at 3:44am

OF is letting you know that the points file, one of the files created by blockMesh by default, is not in your constant folder. Usually that would mean your blockMesh either failed or was not run successfully.

In this case I feel that what is happening is the case is trying to run in parallel without being decomposed (smh). At least that is what the "rm: cannot remove `proc*': No such file or directory" indicates in the error log.

Echoing mostapha try running it without decomposing and see if that works. If it does, clean the case and start the process again, step by step, while taking a look at the folders generated inside your case folder.

Kind regards,

Theodore.

Permalink Reply by yj on April 19, 2017 at 12:26pm

Hi Theodoros thank you for your feedback. I don't quite understand the term decomposed so much, but I guess it is something like a prep for parallel analysis. blockmesh component does work, but snappyhexmesh does not seem to work...

Permalink Reply by Theodoros Galanos on April 19, 2017 at 6:28pm

Decomposition happens from the decomposepar component, which breaks the case to multiple pieces and sends each piece to each core/processor. In you case, the error seems to suggest that the decomposition wasn't done or hadn't been done before you run the case.

I will take a look at your file in a bit and let you know what I find.

Edit: I just realized that you have a complex ground surface. This is usually problematic but can be handled with. A usual problem is that the area below the landscape (if it's closed properly) is not included in the mesh as it is outside of the locationInMesh region. However, the inlet, outlet, and sides usually span above and below the geometry. I feel that if you open the meshed case in paraview you would see an inlet, outlet, and side geometries that go below your landscape. I can confirm once i open the file.

Kind regards,

Theodore.

Permalink Reply by Theodoros Galanos on April 20, 2017 at 3:46am

Hi Chung,

I have to say I would suggest you start with simpler studies when getting into CFD. It is also recommended to try simple states of the same study first, then moving to more complicated designs. There were a few issues with your case. I will try to list them, hoping that this can also be helpful to you but also other users in the forum.

1. The Rhino model contained a lot of open polysurfaces. This is a big enemy of meshing and CFD. The way meshing works is that every single open area, that can be reached from your locationInMesh with a polyline, will be included in meshing. Some of your lanscape volumes were open. I have rectified this in the .gh file attached and now they should be ok to mesh.

2. It is strongly suggested to rotate the geometry and not the incoming wind when creating the wind tunnel. This might as well have been the reason for meshing awkwardly, although can't be sure. I have rotated the geometry by 45 degrees to allow your original wind to have a Y+ direction.

3. I could see a decomposition component in your case study although I cannot be sure if this could be the reason of your problems. It was not connected to anything, but perhaps it might have been the culprit for the paralle issues you were having. I have disabled the component so the case would run in single processor, but you can freely enable it and your case will be run in parallel (4 cores).

4. Your post-processing surfaces have large parts inside the building volumes and under the landscape (if included). You will probably get some issues with visualizing some probes, although this will not affect your study in any way. I recommend to only pass probes that you know to be sure will be inside the mesh to OF.

5. If you decide to include the landscape (I have it disabled in the attached .gh file) I strongly recommend to allow for more cells than 2m. 10m would be a good start imo for this case.

6. I did not check, as it will not make your case break, but your grading was a bit imbalanced at first glance. Try and keep some balance, especially in the X-direction, and make sure to visualize the blockMesh and make sure you achieved what you had in mind.

I did not actually run the case btw, I leave that to you. I believe it will run without problems, although I cannot be sure it will not diverge (this is something that is very educational for you to deal with).

Good luck!

Theodore.

Attachments: