View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000539 | OpenFOAM | Bug | public | 2012-05-22 09:43 | 2012-05-28 15:56 |
| Reporter | attesz86 | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Platform | Red Hat Linux | OS | Other | OS Version | (please specify) |
| Summary | 0000539: AMI patch target weight reaches 0 and the simulation stops | ||||
| Description | Hello, I have a low speed fan simulation with two AMIs separating the rotor domain from the inlet a stator part. The mesh is fully tetrahedral. The simulations run well until a certain point, where the patch target weight on one of the AMIs reaches 0. Until that point, the weight value continuously decreases. If I use a huge timestep, the solver can "jump over" that point, but it stops again in a certain time. The simulation works well with commercial code, so I suppose it's not the problem of the mesh. I already tried to play with matchTolerance, without success. I attach the important files. Unfortunately I can't attach the mesh. Please let me know if you need more information. Thank you, best regards. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
What is the error message when the run aborts? When running in parallel, the min AMI weights can drop below 1 since there can be partial overlap between processor patches. Also, your log shows that you are generally not solving momentum - try reducing the solver tolerance to ensure that the solver is doing some work. |
|
|
|
|
|
Error message uploaded. Yes, but the weight drops significantly down to 0.001 and then to 0 and crashes. I tried reducing solver tolerances already. Since I'm using very small timestep, the solver reaches the tolerance in the first timesteps, then only the pressure is solved. But could it be the cause of the problem? Also see http://www.cfd-online.com/Forums/openfoam-solving/95697-problem-using-ami.html where they have the same problem. |
|
|
Can you create/attach a small test case that reproduces the error? |
|
|
I'll try to make it in my very limited time. But until that my procedure: I created the mesh in ICEM CFD, it's fully tetrahedral. I extruded prism layers with first layers of about 0.001mm. I have the AMIs slicing the domain to 3 parts, therefore I have quadratic elements on the AMI but also triangular ones. Otherwise the two sides of the AMIs are of the same surface mesh. I'm following the propeller tutorial anyway to use pimpleDyMFoam. If you explain me how to find out which AMI has 0 weight (since in the log there are no names) and how to export the mesh on AMIs at the position where it blows up, I can attach that mesh if it's enough. Edit: is it possible to get this error cause of the decomposition method? I'm using scotch, do you want me to try other methods to see if blows up too? Best, Attila |
|
|
Hi, checkMesh results: Checking geometry... Overall domain bounding box (-0.2500000119 0.03000000142 -0.2300000109) (0.2500000119 0.8680624192 0.3700000176) Mesh (non-empty, non-wedge) directions (1 1 1) Mesh (non-empty) directions (1 1 1) Boundary openness (3.31476653e-17 5.842468646e-16 -9.590438521e-17) OK. Max cell openness = 1.185462881e-14 OK. Max aspect ratio = 433.2441293 OK. Minumum face area = 1.519735443e-10. Maximum face area = 0.0009468803734. Face area magnitudes OK. Min volume = 2.102166609e-14. Max volume = 9.265504503e-06. Total volume = 0.1471417476. Cell volumes OK. Mesh non-orthogonality Max: 87.19615969 average: 19.65877148 *Number of severely non-orthogonal faces: 29123. Non-orthogonality check OK. <<Writing 29123 non-orthogonal faces to set nonOrthoFaces Face pyramids OK. ***Max skewness = 6.95619783, 1311 highly skew faces detected which may impair the quality of the results <<Writing 1311 skew faces to set skewFaces Coupled point location match (average 0) OK. ***Error in face tets: 16 faces with low quality or negative volume decomposition tets. <<Writing 16 faces with low quality or negative volume decomposition tets to set lowQualityTetFaces *Edges too small, min/max edge length = 6.307009418e-07 0.05663996797, number too small: 72 <<Writing 72 points on short edges to set shortEdges <<Writing 116946 near (closer than 1.145577878e-06 apart) points to set nearPoints All angles in faces OK. Face flatness (1 = flat, 0 = butterfly) : average = 0.9939644235 min = 0.8368489174 All face flatness OK. Cell determinant (wellposedness) : minimum: 3.31876733e-08 average: 1.047310694 ***Cells with small determinant found, number of cells: 835123 <<Writing 835123 under-determined cells to set underdeterminedCells Concave cell check OK. Failed 3 mesh checks. Indeed the mesh has low quality elements, but the my case is working for a 20deg rotation, then crashes. |
|
|
Hi, I've just run the simulation using an other decomp. method, still crashes. When it crashes, I increase the timestep by 2 order of magnitude. Therefore the mesh "jumps over" the problematic point and doesn't stop at least in the next some timesteps, where the weight becomes again 0. I hope it helps. This feature is very important for me, I'll do my best to help you. |
|
|
Thanks for the test case - I'll take a look Looking at your mesh report - the mesh is very poor One particular concern is the negative face tets, which will cause the AMI algorithm to fail if they appear on the AMI patches. |
|
|
Yes it's true, but I've checked and the quality on the AMI patches is fine. The poor elements appear in narrow regions what I couldn't avoid so far. Anyway, the current testcase has better mesh and it stops as well. |
|
|
The problem relates to the aspect ratio of your prism layers in the near-wall region. For example, the inner edges of the AMI_INROT[12] patches are not circular, but faceted due to the spatial discretisation. As the mesh rotates, the inner patch faces of one side of the AMI can become completely uncovered (zero area overlap) In this case, you may have better success if you reduce the aspect ratio of these faces, either by increasing the height of the near-wall cells, or increasing the azimuthal resolution. |
|
|
Thank you. It's a bit complicated to avoid since I have to respect yplus as well as the computational limits. Don't you plan to make it more robust by avoiding this problem somehow? For example placing wall on the uncovered faces to avoid crashing of the solver at least? |
|
|
This is in the pipeline; however, we are looking for sponsorship to extend the current AMI functionality |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-05-22 09:43 | attesz86 | New Issue | |
| 2012-05-22 09:43 | attesz86 | File Added: AMIproblem.tar.gz | |
| 2012-05-22 10:00 |
|
Priority | high => normal |
| 2012-05-22 10:05 |
|
Note Added: 0001330 | |
| 2012-05-22 10:24 | attesz86 | File Added: script-openfoam.e873 | |
| 2012-05-22 10:29 | attesz86 | Note Added: 0001332 | |
| 2012-05-23 09:44 |
|
Note Added: 0001333 | |
| 2012-05-23 09:54 | attesz86 | Note Added: 0001334 | |
| 2012-05-23 09:57 | attesz86 | Note Edited: 0001334 | |
| 2012-05-23 15:18 | attesz86 | Note Added: 0001335 | |
| 2012-05-23 15:46 | attesz86 | Note Added: 0001336 | |
| 2012-05-23 15:53 | attesz86 | Note Edited: 0001336 | |
| 2012-05-23 19:49 | attesz86 | Note Edited: 0001336 | |
| 2012-05-28 09:20 |
|
Note Added: 0001339 | |
| 2012-05-28 09:27 | attesz86 | Note Added: 0001340 | |
| 2012-05-28 09:53 |
|
Note Added: 0001341 | |
| 2012-05-28 10:45 | attesz86 | Note Added: 0001342 | |
| 2012-05-28 15:56 |
|
Note Added: 0001343 | |
| 2012-05-28 15:56 |
|
Status | new => resolved |
| 2012-05-28 15:56 |
|
Resolution | open => no change required |
| 2012-05-28 15:56 |
|
Assigned To | => user2 |
