View Issue Details

IDProjectCategoryView StatusLast Update
0000539OpenFOAM[All Projects] Bugpublic2012-05-28 15:56
Reporterattesz86Assigned Touser2 
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionno change required 
PlatformRed Hat LinuxOSOtherOS Version(please specify)
Product Version 
Fixed in Version 
Summary0000539: AMI patch target weight reaches 0 and the simulation stops
DescriptionHello,

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.
TagsNo tags attached.

Activities

attesz86

2012-05-22 09:43

reporter  

AMIproblem.tar.gz (80,687 bytes)

user2

2012-05-22 10:05

  ~0001330

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.

attesz86

2012-05-22 10:24

reporter  

script-openfoam.e873 (3,484 bytes)

attesz86

2012-05-22 10:29

reporter   ~0001332

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.

user2

2012-05-23 09:44

  ~0001333

Can you create/attach a small test case that reproduces the error?

attesz86

2012-05-23 09:54

reporter   ~0001334

Last edited: 2012-05-23 09:57

View 2 revisions

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

attesz86

2012-05-23 15:18

reporter   ~0001335

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.

attesz86

2012-05-23 15:46

reporter   ~0001336

Last edited: 2012-05-23 19:49

View 3 revisions

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.

user2

2012-05-28 09:20

  ~0001339

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.

attesz86

2012-05-28 09:27

reporter   ~0001340

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.

user2

2012-05-28 09:53

  ~0001341

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.

attesz86

2012-05-28 10:45

reporter   ~0001342

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?

user2

2012-05-28 15:56

  ~0001343

This is in the pipeline; however, we are looking for sponsorship to extend the current AMI functionality

Issue History

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 user2 Priority high => normal
2012-05-22 10:05 user2 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 user2 Note Added: 0001333
2012-05-23 09:54 attesz86 Note Added: 0001334
2012-05-23 09:57 attesz86 Note Edited: 0001334 View Revisions
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 View Revisions
2012-05-23 19:49 attesz86 Note Edited: 0001336 View Revisions
2012-05-28 09:20 user2 Note Added: 0001339
2012-05-28 09:27 attesz86 Note Added: 0001340
2012-05-28 09:53 user2 Note Added: 0001341
2012-05-28 10:45 attesz86 Note Added: 0001342
2012-05-28 15:56 user2 Note Added: 0001343
2012-05-28 15:56 user2 Status new => resolved
2012-05-28 15:56 user2 Resolution open => no change required
2012-05-28 15:56 user2 Assigned To => user2