Quote:
thanks for your answer! I have being reading all over the forum without luck... as you can see in the image, the patches are superposed correctly. at least visually, did you meant another thing? there are more image in my original post if necessary https://i.ibb.co/pwHvVSB/fig2.png |
I don't know much about this type of use of the AMI interface but you could check whether it is like I said by trying the ACMI: https://openfoam.org/release/2-3-0/non-conforming-ami/
|
Quote:
I found at least a partial solution for my issue and made it work. the problem is comming from the feature snapping. I was using a quarter of the geometry (that had two symmetry planes) as the input mesh for the snappy. and when I was doing this the features were perfectly detected, but that brought some problems.I tryied another workflow where I introduce a bigger surface mesh than my real volume and "cut it" with my background mesh therefore the features detected were less (as the ones in the cut will not be detected by surfaceFeatureExtract). this solved my issue. it is not a perfect solution but at least it works.... I will post this and an image ilustrating it in my thread if you want to have a look (so anyone that finish in that thread has an answer) |
Error when creating AMI patches propeller
2 Attachment(s)
Hi folks,
I've been running propeller simulations over the last months, and I had been using snappyHexMesh for meshing the propeller geometry and simulation domain before jumping into cfMesh. My simulation structure is completely based on the pimpleFoam propeller tutorial, except that I modified it to run my geometry in compressible steady-state (rhoSimpleFoam) and using MRF technique. SHM meshes were never as refined as they should be, specially at the leading-edge and near the blade tips. As reported in this thread: [snappyHexMesh] Rough leading-edge and trailing-edge after snapping, I spent around 2 months trying to improve the mesh, which I actually did, however not sufficiently as I wanted. SHM fails to refine the surface after a certain surface refinement level and also fails to add boundary layers properly to the surface. After researching for alternatives I came across cfMesh through this video: How to create your first mesh with cfMesh - tutorial by József Nagy that helped me a lot with the introduction to the mesher. It is a much simpler, more intuitive, increadibly fast, and requires fewer configurations compared to SHM. It really surprised me. I have started meshing with it and the very first mesh I came out with was better than any mesh I had done before with SHM. Not only the surface refinement was excelent, but it succesfully added layers on the whole propeller/airfoil surface. It also executed the mesh in less than a minute, when compared to 10-30 minutes of SHM. I found cfMesh really great, but I'm having difficulties to integrate the mesh to my simulation structure and to dealing with some AMI patches, which I'm going to further detail next. My domain is composed by: - propellerTip: are the prop blades - propellerSpinner: the prop spinner - innerCylinderSmall: the "moving" domain - outerCylinder: an outer cylinder that contains the other patches as well as the farfield upstream and downstream of the propeller https://i.imgur.com/Dk7HAJK.png snappyHexMesh The meshing process that I was using was: create a blockMesh wrapping the whole domain; extract stl file surface with surfaceFeatureExtract, mesh with snappyHexMesh;configure the boundary, inlet and outlet face sets; and finally create AMI, inlet and outlet patches.cfMesh Images from the differences of SHM and cfMesh meshes. Left SHM, right cfMesh |
Hi Gabriel,
I am facing the same problem. I am trying to setup a case for rhoPimpleFoam to analyse the flow around a propeller. Like you, I used the snappyHexMesh without success. It just wont work. Then I turned to cfMesh which gave a good mesh. But I am facing issues with the AMI interface. Per my understanding, when using SHM it will create a faceZone for the innerCylinder patch and a cellZone for the region it encloses (in our case the rotating region). But it will not separate the mesh into two regions (which is what AMI needs). Using the faceZone / the slave patches created by SHM we can use createBaffles / createPatch to separate the mesh into two regions and define AMIs. In cfMesh, since there are two meshes (rotating and stationary), merging them together creates the two regions AMI needs. All that's left to do is to define AMI with createPatch or edit the boundary file like wyldckat suggested in this post. And I was able to create AMI patches without any issues. But the problem comes when I run the case. I get the following warning every time the solver tries to create weights for the AMI. I just couldn't figure this out. Code:
AMI: Creating addressing and weights between 376 source faces and 87808 target faces It will be very helpful if someone could shed some light on this issue I am facing. It seems the face normals are wrong, but I can't figure out how to resolve it. Regards, MRK |
Quote:
|
Anyone resolve this problem?
|
Hi gabrielfelix,
Did you manage to fix your problem? I hope to learn from you. Also, your files can't be downloaded. Quote:
|
Btw,
I have read thru all the pages here. I need to rotate my elevator on a plane using AMI. I followed the propeller and annularThermalMixer tutorials. Steady state worked well. However, rotating the elevator gave 0 weight error after a while of running. I went back to start from the propeller tutorial, slowly modifying step by step to debug for errors. The final objective is to get to my rotating elevator problem. In my case, the elevator is orientated in a sideway pointing down orientation. The simulation works well even when I change my domain size and replace the propeller for the elevator to match my problem. However, I found that once I rotate the orientation such that the axis is (0 1 1), the simulation becomes unstable. It seems that reducing the initial time step from 1e-5 to 1e-6 and decreasing the CFL from 1 to 0.5 helps. Simulation runs till 0.8s before it suddenly crashes. Still not sure why. Any other suggestion? Has anyone tried the new NCC in OF v10? The simulation diverges in its own propeller implementation and I can't get it to work as there's segmentation error at the last step. Thanks! |
Some updates to my problem. It seems that generating a new grid can help mitigate some problems. Using lowWeightCorrection = 0.2 also helps.
|
Btw, for those AMI experts out there, supposed I have a propeller and I am trying to use AMI to simulate its rotation. I create an additional AMI cylinder over the propeller.
Supposed I have a wall body next to the propeller. If my AMI cylinder intersects the wall body, is it ok? In other words, are we allowed in OpenFOAM to let the AMI clyinder and wall body overlap one another? Will it give numerical error? I just tried a similar simulation using moveDynamicMesh and I found that my grid is giving a lot of problem with stuffs like negative volume, incorrect face. I wonder if it's due the cylinder wall body intersection... |
Quote:
Source and target faces should SEE each other. Increase the size of one of the source/target, so that target/source can see it in full. |
Propeller cfMesh
The idea is to make two meshes AMI and domain.
The AMI mesh should contain AMI.stl and rotor.stl. You should join both surfaces then mesh with meshdict and remember to name AMI_inside(patch) and rotor(wall). Now you mesh the domain. It should contain AMI.stl and any other static surfaces. Join those surfaces and generate the bounding box of the domain. Now mesh with meshdict and remember to include the AMI_outside(patch). Now use mergeMesh to put the AMI inside the domain. Use checkMesh to create the sets, remove the broken surfaces from the sets, and use setsToZones to create the region0 (domain) and region1 (AMI). Use now createPatch to set the AMIs. The biggest problem is that the created AMIs are decoupled. This breaks the weights and the simulation. It is similar to when you try to make one explicitly and the other implicitly in SHM. If I solve this problem I will update this answer properly. |
Hello guys, I finally found a solution to the problem and managed to mesh the propeller case with cfMesh succesfully. I posted the detailed solution in this thread.
[Guide] How to mesh a propeller domain using cfMesh - AMI patch Case files are also available. |
Hi gabrielfelix,
Thanks for the guide. It's going to be very useful. |
Hi all,
I've been having error and divergence issues using AMI with faceAreaWeightAMI and faceAreaWeightAMI2D. There's also spikes in the forces. When I changed to nearestFaceAMI, my solution converges and the spikes are much lesser now. So it may be worth trying for those having problems like me. |
Quote:
I suggest that you also give a try to NCC (available from OpenFOAM 10+) which is the next generation of AMI. |
Quote:
|
mass loss issue
Hello all,
I looked through the forum but could't find a solution to my AMI problem: I am solving diffusion-like scalar transport equations and face significant mass loss. In a simplified sketch, the mesh looks like this: https://i.postimg.cc/vTv2cQgD/Screen...-13-133216.jpg With an inlet and an outlet (z-coordinate) and two periodic directions (x, y). I managed to run several geometries with the cyclicAMI bc. I just figured that I loose 10-30% of mass until the end of the simulation. I believe this is caused by the slightly different sizes (~3%) and non-conformal meshes of the periodics because mass conservation works with zeroGradient bcs. The boundary file looks like this: Code:
periodic_11 Has anyone solved this issue?? So far I played with the settings without success. I tried the cyclicPeriodicAMI but it throws a sigSegv error which I don't understand: Code:
#0 Foam::error::printStack(Foam::Ostream&) at ??:? Any help is appreciated! :) |
All times are GMT -4. The time now is 12:03. |