[pbachant]

As the title says, I am attempting to mesh the turbineSiting tutorial, but leaving out the terrain. Essentially I want snappy to refine inside the turbine boxes and that's it, but it's crashing. All I've done is commented out the parameters related to the terrain. I have a previous case that did a similar thing and that is failing now too, where it worked fine in 2.2.2. Any ideas?

[wyldckat]

Hi Pete,

A few questions:

1. Which OpenFOAM version are you using now, with which you get this problem?
2. Can you share the test case ready to be used?
3. How much RAM is available for this case?
4. Are you meshing in parallel?
5. Did you modify the tutorial case for the OpenFOAM version you're now using or are you using the one from 2.2.2?

Best regards,
Bruno

[pbachant]

Hey Bruno,

1. I'm using 2.3.0. Similar cases worked nicely in 2.2.2.
2. Here's the case on GitHub.
3. 4 GB right now
4. Yes
5. Yes, I modified the 2.3.0 tutorial.

Thanks,

[wyldckat]

Hi Pete,

Looks like you've stumbled upon a bug in OpenFOAM 2.3. I've tested with 2.3.0 and the latest 2.3.x. Both are unable to handle this case.

At first I thought the problem was due to insufficient refinement for making the search system able to find the turbine locations, but increasing the resolution and sizes of the search boxes did nothing.
Therefore, this does look like a bug!

Feel free to report this on the bug tracker and provide them with a good description of how to reproduce the problem, along with the test case you've shared in the previous post! The bug tracker is this one: http://www.openfoam.org/mantisbt/

Best regards,
Bruno

[pbachant]

Thanks Bruno. I submitted a bug report.

[pbachant]

So, my bug report was closed as being a user support issue, which is probably my fault for how I phrased it. I have trouble using analytic refinementRegions in other cases as well, which makes me think it really is a bug, or a fundamental change in how these are set up in the sHMDict. Anyway, I will keep hammering away and see if I can figure it out.

[wyldckat]

Hi Pete,

It's possible that they dropped a feature or that they modified a particular feature, namely the one where no STL files are necessary. Check the features indicated on the release notes: http://www.openfoam.org/version2.3.0/snappyHexMesh.php
One particular detail that might be the reason for this sudden problem is this:

stopping execution of the mesher between each stage of the meshing process, i.e. castellated, snapping, layer addition, now produces the same mesh as completing all stages in one execution.

If I had the time to try and figure this out, I would start with a simpler case, where it would be easier to have more control over how the meshing regions are defined. Because the "turbineSiting" one is using UTM coordinates, which (for example) makes it terribly complicated to figure out if "4000m" is too much or too little to the left or right of the current location

Good luck! Best regards,
Bruno

[pbachant]

Bruno,

After rummaging through the source code and finding exactly where the process was failing, I did end up getting a simpler case to work, by using two new options in the snappyHexMeshDict:

    // Optional: do not remove cells likely to give snapping problems
    handleSnapProblems false;

    // Optional: switch off topological test for cells to-be-squashed
    //           and use geometric test instead
    useTopologicalSnapDetection false;

I tried these options with turbineSiting and it doesn't crash, though the mesh isn't refining correctly, so topoSet is not adding any cells to the actuatorDisk zones. I'm going to put this on the shelf for now, but if I get it, I will update the case on GitHub.

[wyldckat]

Hi Pete,

Mattijs answered to your bug report today as well. I believe he's referring to the refinement boxes for the regions where the actuator disks will be placed. Since the 2 boxes are almost inside a single cell each, it's not visible by the algorithm that handles cell selection for refinement.

It's what I was referring to on the other post, but the weird detail is that such small boxes had worked for you in the past with 2.2.x...

If and when I get a chance, I'll try to look into this as well. This kind of refinement also comes in handy, from time to time, so it's best to catch it sooner than later.

Best regards,
Bruno

[pbachant]

I saw that, and went back and checked again with 2.2.x. It didn't crash, but it also seems it wasn't refined, and the cellSets and cellZones were not created, so I think I was wrong about that part.

Revisiting the tutorial, I see that next to the STL is refined up to level 2, which is why there are enough cells in that searchableBox, but when the STL is removed, those regions are not refined.

I went back to my case and refined the blockMesh by a factor of 2 and things worked. I also found that the "useTopologicalSnapDetection false;" option is no longer necessary.

Looks like it was my fault after all!

[wyldckat]

Thanks for sharing! That saves me some trial-and-error time

By the way, the filter "Extract Cells by Region" gives a more realistic view of the mesh ... well, at least if we also use the VTKPolyhedron feature (aka "do not decompose polyhedrons") in the ".OpenFOAM" (or ".foam") entry.

[pbachant]

Thanks for the tip, and thanks a lot for helping me with this. You rule!

[leonardo.oliveira]

Hello Bruno,

I have a problem with the tubineSiting tutorial (openFoam 2.3.0):

I can run the tutorial without problem, but the actuation disks, those made by the topoSetDict and fvOption, doesn't appear! The mesh is refined in the place they are suppose to be, but they are no there!

I run the tutorial without any modifications, using the Allrun script.

So I want to know if I'm missing something, if they are supposed to be there or not...

Thanks in advance.

[wyldckat]

Hi Leonardo,

Sorry for the late reply. I've had this post of yours also on my to-do list and had a quick a look into this as well.
If my guess is correct, this was a bug that is already fixed in OpenFOAM 2.3.1. Therefore, please try the latest OpenFOAM 2.3.1.

Best regards,
Bruno

[Nick D]

Hi everyone,

I have come across the same problem as Leonardo mentioned above. I have also tuned the fvOPtions, snappyHexMeshDict and topoSetDict files, but no luck so far although ./Allrun script runs fine. Has anyone successfully managed to visualize the actuator disks with OF 2.3.1 version? Your help or any feedback would be deeply appreciated on the issue. Thank you in advance!

Best regards,

Nick

[vatavuk]

Hi Leonardo and Nick,
I didn't run this tutorial but it seems to me that the intention is not put a real turbine there, just a rotational momentum source in the equations that is called actuator disk. So there is no physical actuator disk, just a numerical term that is supposed to produce the same rotational effect as the turbine does. Ok?
Best regards,
Paulo

[Nick D]

Hi Paulo,

Thank you for your reply. I agree with what you are saying but the issue was different. The problem was that I could not visualize the Actuator disks on ParaView, meaning the meshed areas representing the disks. I have now solved the issue, as my problem was that I was selecting a mesh area partly out of the domain. Thanks for you feedback though!

Cheers,

Nick

[sharonyue]

Originally Posted by Nick D

Hi everyone,

I have come across the same problem as Leonardo mentioned above. I have also tuned the fvOPtions, snappyHexMeshDict and topoSetDict files, but no luck so far although ./Allrun script runs fine. Has anyone successfully managed to visualize the actuator disks with OF 2.3.1 version? Your help or any feedback would be deeply appreciated on the issue. Thank you in advance!

Best regards,

Nick

Hi,

Why dont u select "include zones" in the properties panel in paraFoam. then u can select these two cellzones in mesh part.

To bo notice that u must use paraFoam instead of paraview to visualize it.

Best,

[Nick D]

Hi Sharonyue,

Problem has been solved already! Thank you for your reply though!

Best regards,

Nick