|
[Sponsors] |
July 26, 2016, 23:46 |
|
#261 |
New Member
Dasein
Join Date: Mar 2015
Posts: 21
Rep Power: 11 |
Hi Louis,
Thank you for the response. Yes I did try changing the rotation of the fan and the wind direction seemed to change. The problem was though that as the solution was converging, the downward flow was getting lost and the turbulent flow developed has an upward flow pattern. The only thing I believe I can blame atm is boundary conditions and/or model. Most of the cases are small square rooms with a fan in the middle, an open window (fixedValue velocity, always quite low, <0.2m/s), and an open door (as a typical outlet). I was wondering if the problem is this set up or the window being close to the fan. For this reason I tried an 'external case' where I have a blockmesh blowing wind towards the room, which now has no boundary surfaces for window or door, is modeled as an open room. Same pattern again unfortunately, with the initially downward flow getting lost as the solution converges. Additionally, wind speeds below the fan are much lower than expected. Is rotation and direction really tied to the type of geometry of the fan or is it a convention of OF? I haven't been able to clarify that yet. I imagine it's the first if we want validity. Is it perhaps the size of my MRF zone? It is atm quite small, located around the fan. I show in some studies MRF zones extending to almost 2m length. Finally, I was also looking about this but nothing clear on the site. Is it possible to model an open window in openfoam, with no 'outlet' boundary? I went through the posts about outflow, but they are all seemed to start with it as a problem to fix. Also, most of them are focused on outlets that appear to have inflow. My case is the opposite, I want to enable outflow on an inlet. Is that possible? Sorry if I diverged from the subject a bit, hope this helps to understand my case. Edit: Added pressure and velocity vector plots on a cross section parallel to the wind flow, under the fan. Also forgot to mention this is CCW direction (- rad/s in MRF properties). Edit2: Added two velocity plots. They are from both cases (CW and CCW rotation) at a very early stage (only 100 iterations). Still, you can clearly see I think that CW is producing the required pattern, which relates well to the shape of the fan geometry. Problem is that pattern is lost as solution converges. I am at a loss. After making the whole MRF work, this seems like a silly issue to have. Still, it invalidates all my previous work Kind regards, Theodore. |
|
July 27, 2016, 04:11 |
|
#262 |
Senior Member
|
Hi Theodore,
My experience is limited to GGI/AMI interfaces, so I can't comment on the MRF. As for the outlet that allows incoming flow, I think you can use the inletOutlet boundary condition for the inlet as well. See section "5.2.3.1 The inlet/outlet condition" of http://cfd.direct/openfoam/user-guide/boundaries/ Finally, for the imposed rotation direction convention, I doubt there is one as OpenFOAM solves the flow using finite volumes and I don't see where this would come in. That said, my knowledge on the subject is limited and hopefully someone else may add useful comments. Regards, -Louis |
|
July 28, 2016, 03:21 |
Comparison of both directions under an "open" inlet boundary condition
|
#263 |
New Member
Dasein
Join Date: Mar 2015
Posts: 21
Rep Power: 11 |
Hello Louis,
Thank you very much for your input. I have started testing the inletOutlet condition with fairly similar results. The latest simulations have been with only an open window, that is only an inletOutlet and without any kind of outlet boundary condition. The simulation works which means the inletOutlet implementation is (physically) correct, so thank you for that. Unfortunately, I still get the same weird patterns. To be fair, I'm on a desperate clock here and most of my tests are around 500 to 750 iterations which I can understand is FAR from being converged. Still there should be a semblance of a downward pattern even at this early stage should it not? I am attaching screenshots from both CCW and CW orientations. The fan design should allow for downward flow for the CW orientation but both of them look kind of horrid tbh. CW is even more of an 'upward' flow than the CCW. I am also attaching my case setup (minus the geometry due to file size), since I know that this is probably a physics set up issue and not really a rotation issue. Hoping someone has any insights for me. If not, I hope the set up helps people design and perform MRF simulations. That would provide more knowledge for all of us in the long run. The command sequence would be smth like: blockMesh snappyHexMesh topoSet simpleFoam Kind regards, Theodore. |
|
August 14, 2016, 09:54 |
periodic simulation
|
#264 | |
New Member
amin talezade
Join Date: Apr 2012
Posts: 7
Rep Power: 14 |
Quote:
I have a question about your above statement : "AMI Connections are not allowed to be of different sizes and have non-overlap regions" I am trying to simulate the propeller tutorial periodically. the two AMI connections in blade zone and the stationary zone moves besides each other and the the min value in the AMI patch target goes to zero and causes error like this: Code:
Courant Number mean: 0.00113213 max: 0.683572 deltaT = 5e-06 Time = 0.00013 solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.00013 transformation: ((0 0 0) (0.999947 (0 0.0102698 0))) AMI: Creating addressing and weights between 2467 source faces and 2367 target faces AMI: Patch source sum(weights) min/max/average = 0.635783, 1.00003, 0.997899 AMI: Patch target sum(weights) min/max/average = 0.785625, 1.0004, 0.999555 AMI: Creating addressing and weights between 6477 source faces and 6477 target faces AMI: Patch source sum(weights) min/max/average = 0.999997, 1, 1 AMI: Patch target sum(weights) min/max/average = 0.999997, 1, 1 AMI: Creating addressing and weights between 6328 source faces and 6984 target faces AMI: Patch source sum(weights) min/max/average = 0, 1.02797, 0.990961 AMI: Patch target sum(weights) min/max/average = :confused::confused:0.00514256, 1.00165, 0.988335 PIMPLE: iteration 1 smoothSolver: Solving for Ux, Initial residual = 4.24196e-06, Final residual = 1.23042e-08, No Iterations 1 smoothSolver: Solving for Uy, Initial residual = 5.83482e-06, Final residual = 1.76498e-08, No Iterations 1 smoothSolver: Solving for Uz, Initial residual = 9.60301e-05, Final residual = 2.06976e-07, No Iterations 1 #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigFpe::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) at ??:? #4 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator/<Foam::fvPatchField, Foam::volMesh>(Foam::dimensioned<double> const&, Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) at ??:? #5 ? at ??:? #6 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #7 ? at ??:? Floating point exception (core dumped) how can I fix the problem? and finally what do you mean by "1:1 geometry"? does it means that each cyclic AMI should contain only one face? my cyclicAMI faces are 3 as depicted below. Best Regard |
||
August 15, 2016, 08:23 |
|
#265 |
Member
|
I think that the Arbitrary Coupled Mesh Interface (ACMI) would be a better B.C. for such cases.
|
|
February 16, 2017, 08:36 |
problem with AMI
|
#266 |
New Member
Andrea Mala
Join Date: Nov 2016
Posts: 7
Rep Power: 10 |
Hi all,
it is the first time that I write, but I follow you a few months. Thanks to your previous post, I was able to adapt the propeller tutorial to my case of a fan of an industrial oven (I used SHM propellerTip.obj replacing the file with a propeller STL files and varying parameters such as epsilon, k , nu, Maxco). The simulation converges and everything seems to be good. At this point, I tried to replicate the same case using an external meshing (Hexpress of Numeca) instead of SHM. First street, I built two meshes (external hollow cylinder and a small cylinder inside) and I used mergeMeshes and createPatch following your advice (I've also tried it with createBaffles) to create AMI1 and AMI2. When I start the simulations, however, I have weights problems (I think because the two interfaces have a different number of faces and align bad. Unfortunately I was not able to overcome this problem by using directly Hexpress (any advice on this point is appreciated). Second road, I built a mesh with inside the fan and I used topoSet and createBaffles (as done in the propeller tutorial editing these files) to create AMI1 and AMI2. In this case, I get interfaces with the same number of faces that are well aligned in terms of weight. The simulation, however, diverges immediately. Opening the geometry with paraview, known that AMI1 and AMI2 not have a cylindrical contour, but are constituted by a "step" cells (which is not the case using SHM). This leads me to think it is due to the fact of not having a "guide" cylinder inside the mesh (as innerCylinderSmall for SHM). So, third street, I built a single mesh with the small cylinder inside and the fan. But if at this point I try to create AMI1 and AMI2 with topoSet (as in the propeller tutorial, building a cylinder with cellToCylinder the same size as the one inside the mesh) the faceZone (amiCylinderFace) is empty. I kindly ask you tips or ideas on how to proceed, because these roads do not seem to work. Thank you. Andrea |
|
February 18, 2017, 10:52 |
|
#267 |
Senior Member
|
Hi Andrea and welcome to the forum,
To me it seems your problem is rather linked to the mesher you use. Perhaps you should seek support from them ? Best Regards, -Louis |
|
December 20, 2017, 10:18 |
Problem with mesh when using AMI
|
#268 |
New Member
Maria
Join Date: Feb 2017
Posts: 25
Rep Power: 9 |
Hi, Louis.
I am having troubles with mesh generation using SnappyHexMesh. I am simulating a wind turbine in a wind tunnel with the use of a CAD model of the turbine and AMI. So far I have managed to get the AMI weights to around 1 which was accomplished by using the faceType Baffles; as mentioned earlier in this thread. However, both checkAMI and checkMesh does not like til mesh and I get 5 failed checks. This happens with and without the turbine, so I guess the problem is with the AMI somehow. My snappyHexMeshDict looks as follows: Code:
castellatedMesh true; snap true; addLayers false; geometry { refinementCylinder1 { type searchableCylinder; point1 (-0.4 0 0); point2 (9 0 0); radius 0.8; } T1.stlb { type triSurfaceMesh; name T1; } innerCylinderSmall_tight.stl { type triSurfaceMesh; name innerCylinderSmall; } }; castellatedMeshControls { // Refinement parameters // ~~~~~~~~~~~~~~~~~~~~~ maxLocalCells 100000; maxGlobalCells 2000000; minRefinementCells 0; maxLoadUnbalance 0.10; nCellsBetweenLevels 3; // Explicit feature edge refinement // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ features ( { file "innerCylinderSmall_tight.eMesh"; level 5; } { file "T1.eMesh"; level 6; } ); // Surface based refinement // ~~~~~~~~~~~~~~~~~~~~~~~~ refinementSurfaces { innerCylinderSmall { level (5 5); faceType baffle; cellZone innerCylinderSmall; faceZone innerCylinderSmall; cellZoneInside inside; } T1 { level (5 7); } } resolveFeatureAngle 30; // Region-wise refinement // ~~~~~~~~~~~~~~~~~~~~~~ refinementRegions { refinementCylinder1 { mode distance; //inside; levels (1E15 4); } innerCylinderSmall { mode inside; levels ((1E15 5)); } } // Mesh selection // ~~~~~~~~~~~~~~ locationInMesh (-1.3 0 0); allowFreeStandingZoneFaces false; } // Settings for the snapping. snapControls { nSmoothPatch 3; tolerance 1.0; // nSolveIter 300; nRelaxIter 10; // Feature snapping nFeatureSnapIter 25; implicitFeatureSnap true; //false; explicitFeatureSnap false; //true; multiRegionFeatureSnap false; detectNearSurfacesSnap true; } // Settings for the layer addition. addLayersControls { relativeSizes true; // Per final patch (so not geometry!) the layer information layers { } expansionRatio 1.0; finalLayerThickness 0.3; minThickness 0.1; nGrow 0; // Advanced settings featureAngle 30; nRelaxIter 3; nSmoothSurfaceNormals 1; nSmoothNormals 3; nSmoothThickness 10; maxFaceThicknessRatio 0.5; maxThicknessToMedialRatio 0.3; minMedianAxisAngle 90; nBufferCellsNoExtrude 0; nLayerIter 50; } // Generic mesh quality settings. At any undoable phase these determine // where to undo. meshQualityControls { maxNonOrtho 65; maxBoundarySkewness 20; maxInternalSkewness 4; maxConcave 80; //70; minVol 1e-13; //1e-16; minTetQuality -1; // 1e-30; minArea -1; //1e-13; minTwist 0.01; //0.025; minDeterminant 0.001; //0.002; minFaceWeight 0.05; //0.02; minVolRatio 0.01; minTriangleTwist -1; // Advanced nSmoothScale 4; errorReduction 0.75; relaxed { //- Maximum non-orthogonality allowed. Set to 180 to disable. maxNonOrtho 75; //95; } } mergeTolerance 1e-6; // ************************************************************************* // Code:
Time = 0.08 PIMPLE: iteration 1 PIMPLE: iteration 2 Point usage OK. Upper triangular ordering OK. Topological cell zip-up check OK. Face vertices OK. Number of identical duplicate faces (baffle faces): 384982 <<Number of duplicate (not baffle) faces found: 7. This might indicate a problem. <<Number of faces with non-consecutive shared points: 7. This might indicate a problem. Mesh topology OK. Boundary openness (-1.1520507e-16 -5.2876705e-16 -1.2753255e-15) OK. ***High aspect ratio cells found, Max aspect ratio: 9.4997529e+96, number of cells 90035 Minimum face area = 7.8491957e-10. Maximum face area = 0.0097616627. Face area magnitudes OK. ***Zero or negative cell volume detected. Minimum negative volume: -1.7082009e-06, Number of negative volume cells: 89799 Mesh non-orthogonality Max: 179.9898 average: 22.450004 *Number of severely non-orthogonal (> 70 degrees) faces: 473027. ***Number of non-orthogonality errors: 233232. ***Error in face pyramids: 671138 faces are incorrectly oriented. ***Max skewness = 3518830.2, 452361 highly skew faces detected which may impair the quality of the results Failed 5 mesh geometry checks. Failed 1 mesh checks. Calculating AMI weights between owner patch: AMI1 and neighbour patch: AMI2 AMI: Creating addressing and weights between 384982 source faces and 384982 target faces AMI: Patch source sum(weights) min/max/average = 1, 4.9054261, 1.0000555 AMI: Patch target sum(weights) min/max/average = 1, 3.1922214, 1.0000484 ExecutionTime = 791.42 s ClockTime = 792 s Kind regards, Maria |
|
December 20, 2017, 12:24 |
|
#269 |
Senior Member
|
Hi Maria,
It seems that the mesh has unacceptable non-orthogonality and skewness: did snappyHexMesh properly complete? Did it stop because it reached the maximum number of cells? If you can post your snappyHexMesh log it could give some hints. Kind regards, -Louis |
|
December 20, 2017, 13:04 |
|
#270 |
New Member
Maria
Join Date: Feb 2017
Posts: 25
Rep Power: 9 |
Thank you for such a quick reply!
SnappyHexMesh runs to the end stating "Finished meshing without any errors". However, it does not run without troubles, and the following message is displayed a lot: Code:
--> FOAM Warning : From function void Foam::snappySnapDriver::calcNearestFace(Foam::label, const indirectPrimitivePatch&, const scalarField&, Foam::vectorField&, Foam::vectorField&, Foam::labelList&, Foam::vectorField&) const in file snappyHexMeshDriver/snappySnapDriverFeature.C at line 333 Did not find surface near face centre (0.032849473 0.36393482 0.35608885) The end of snappyHexMeshDict says: Code:
Checking final mesh ... Checking faces in error : non-orthogonality > 65 degrees : 0 faces with face pyramid volume < 1e-13 : 0 faces with face-decomposition tet quality < -1 : 0 faces with concavity > 80 degrees : 0 faces with skewness > 4 (internal) or 20 (boundary) : 0 faces with interpolation weights (0..1) < 0.05 : 0 faces with volume ratio of neighbour cells < 0.01 : 0 faces with face twist < 0.01 : 0 faces on cells with determinant < 0.001 : 0 Finished meshing without any errors Finished meshing in = 9636.33 s. End |
|
December 20, 2017, 13:12 |
|
#271 |
New Member
Maria
Join Date: Feb 2017
Posts: 25
Rep Power: 9 |
This is what appears at the first time something looks odd in log.snappyHexMesh
Code:
Morph iteration 0 ----------------- Calculating patchDisplacement as distance to nearest surface point ... --> FOAM Warning : From function static Foam::vectorField Foam::snappySnapDriver::calcNearestSurface(const Foam::meshRefinement&, const scalarField&, const indirectPrimitivePatch&, Foam::pointField&, Foam::vectorField&) in file snappyHexMeshDriver/snappySnapDriver.C at line 1638 For point:111 coordinate:(0.0017006904 -0.038190952 0.046531304) did not find any surface within:0.00077963914 metre. Code:
--> FOAM Warning : From function void Foam::snappySnapDriver::calcNearestFace(Foam::label, const indirectPrimitivePatch&, const scalarField&, Foam::vectorField&, Foam::vectorField&, Foam::labelList&, Foam::vectorField&) const in file snappyHexMeshDriver/snappySnapDriverFeature.C at line 397 Did not find surface near face centre (-0.0048429234 -0.0028452753 -0.057680117) Attraction: linear : max:(-0.0017834549 -0.00135829 -0.0018018673) avg:(-1.1809928e-05 -9.9177178e-07 -3.4400299e-06) feature : max:(-0.00015530245 -0.0042471306 -0.00019065496) avg:(-1.2218327e-05 -4.0699936e-07 -3.7050001e-06) Feature analysis : total master points:576407 attraction to : feature point : 55 feature edge : 15418 nearest surface : 560934 rest : 0 |
|
December 21, 2017, 04:16 |
|
#272 |
Senior Member
|
Hi Maria,
I have two further suggestions: - try to do a much coarser mesh and see what happens (reduce all or most levels by 2 for example); do the same error messages appear? -- doing so will allow you to perform a "debugging" much faster -- maybe the snappy log will also be easy to post here ;-) - do all the problems of the non-ortho, skewed, and not-found faces also occur with a) the coarser mesh and b) as mesh without baffles or without the actual cylinder interfaces ? Hope this helps, -Louis |
|
December 22, 2017, 08:29 |
|
#273 |
New Member
Maria
Join Date: Feb 2017
Posts: 25
Rep Power: 9 |
Thank you for your advice, Louis!
I have now tried to have a coarser mesh, and it does get all the same five geometry failures. The only odd thing I get out of the snappyHexMesh log is that it says: Code:
--> FOAM Warning : Displacement (-1.4793118e-06 -4.3506502e-05 5.1446667e-05) at mesh point 747934 coord (0.0027575758 -0.040337193 0.048917823) points through the surrounding patch faces Smoothing displacement ... When I try running meshing without the AMI cylinder and only the turbine I get the same warning as above. Here, checkMesh only reports errors with skewness. I have added the snappyHexMesh log and the moveDynamicMesh log in the attached folder. There is also added the case files without the turbine - the design is not mine to share. Kind regards, Maria |
|
December 22, 2017, 11:21 |
|
#274 |
Senior Member
|
How coarse is the baffle? The innerCycl...stl cell sizes are, I think, much too small. Is the baffle much coarser? Otherwise, trying making is coarser.
I'm not sure if this "Displacement points through the surrounding patch faces" warning you point out is something to worry about, I would say no but I cannot guarantee it is not causing some weird mesh rearrangement, perhaps someone else can pitch in... I've had a quick look at your files, one idea that comes to mind is that you could have an imposed movement not compatible with the mesh. It's easy to check, just run checkMesh before moveDynamicMesh -checkAMI in your script... If the mesh at time 0 is fine, then the imposed movement is not and you can probably see how using paraview and running moveDynamicMesh with a very small timestep... Also, this line "cp -rf 0.orig 0" should go before doing moveDynamicMesh and checkMesh. You can also test the results of using a 10x or 100x larger "matchTolerance 0.0001;" in your createPatchDict file and increase "maxNonOrtho 65;" to 75 in snappyHexMesh... Hope this helps, otherwise write again but keep in mind I will not be checking during the vacations. -Louis |
|
January 2, 2018, 08:37 |
|
#275 |
New Member
Maria
Join Date: Feb 2017
Posts: 25
Rep Power: 9 |
Thank you, Louis.
You were right, there is something wrong happening when the mesh is rotated. I have been trying different things over the holiday and I can't make the "faceType baffles;" work - it creates a distorted mesh when rotated where there is no sliding interface between the stationary and rotating mesh, see added pictures. When having the a solid body with rotatingMotion dynamicmesh I can make progress when using "faceType boundary;" such as in the Propeller tutorial. This markes only high skewness for the mesh check which occurs at the tail edge of the turbine. However, now I am back at having a few faces with zero weight for the AMI. I am trying to solve this problem with using "lowWeightCorrection 0.2" in the "CreatePatchDict" for the AMI. There are only a few faces, ~5, that have low weights, the average is close to 1. This takes quite a long time to test, so I will report back whether or not it works to just exclude the few zero-weighted cells. I have followed your tip of having coarser innerCylinderSmall for the AMI, this helped to get fewer cells with low weights. And I have increased the "matchTollerance" to 0.01 and "maxNonOrtho" to 75 as you suggested. Have you made a simulation work with AMI defined as baffles or boundary before that is somewhat similar to mine? Just curious if it is just my case setup that does not work with baffles or not. Thank you for your input, do you have more ideas? Happy New Year! - Maria |
|
January 8, 2018, 09:05 |
|
#276 |
Senior Member
|
Hi Maria and happy new year,
If your mesh deforms instead of "sliding" it probably means that the zones you are defining as rotating using the AMI algorithm do not correspond to the cylinders you created with snappyHexMesh. Yes, I have done both 2D and 3D simulations with AMI/baffles and such deformations usually occur to me when I misplace the center of rotation or use an offset cylindrical zone with respect to the mesh's cyclinder. Do keep in mind that defining the mesh as baffle in snappyHexMesh is not obligatory, it just tells the mesher to create an interface, but alternatively you can do it manually afterwards if snappy doesn't create the two faces itself (inner AMI and outer AMI). At this point, if even with a coarser mesh testing is slow, I would recommended doing it with a 2D mesh first, and once you have a case moving properly switch to a really coarse 3D mesh because to test mesh motion it doesn't really matter how fine is the mesh.. To avoid changing mesher I think you could force snappyHexMesh to make a 2D mesh by feeding it a thin 1-cell thick mesh and removing the propellers... Hope this helps, let me know. -Louis |
|
January 12, 2018, 06:48 |
|
#277 |
New Member
Maria
Join Date: Feb 2017
Posts: 25
Rep Power: 9 |
Thank you, Louis!
You were right, my cylinder was a little offset, so by correcting the location helped a little. However, it didn't do the full job, but I went back some pages in the forum and saw your previous post about using mergeOrSplitBaffles -split and that helped! Now the mesh is sliding and the AMI weights are quite good. There are some very few cells with low weigts so I still use lowWeightCorrection 0.2. Again, thank you for all your input and help! I appreciate it - Maria |
|
April 22, 2018, 11:18 |
|
#278 |
Member
Bashar
Join Date: Jul 2015
Posts: 74
Rep Power: 11 |
Hi,
I am facing an issues in my oprnFoam 5x case. I am using cyclicAMI for interfaces inside my mesh. I decompose the case and run it perfectly without any issues. I need to reconstruct the case, however when I use reconstruct command I get the following error: Code:
Reconstructing fields for mesh region0 Time = 30.00003 Reconstructing FV fields Reconstructing volScalarFields nut AMI: Creating addressing and weights between 1538 source faces and 1642 target faces --> FOAM FATAL ERROR: Unable to set source and target faces From function void Foam::faceAreaWeightAMI<SourcePatch, TargetPatch>::setNextFaces(Foam::label&, Foam::label&, Foam::label&, const boolList&, Foam::labelList&, const Foam::DynamicList<long int>&, bool) const [with SourcePatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; TargetPatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; Foam::label = long int; Foam::boolList = Foam::List<bool>; Foam::labelList = Foam::List<long int>] in file lnInclude/faceAreaWeightAMI.C at line 287. FOAM aborting #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::error::abort() at ??:? #2 Foam::faceAreaWeightAMI<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::calcAddressing(Foam::List<Foam::DynamicList<long, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<double, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<long, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<double, 0u, 2u, 1u> >&, long, long) at ??:? #3 Foam::faceAreaWeightAMI<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::calculate(Foam::List<Foam::List<long> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<long> >&, Foam::List<Foam::List<double> >&, long, long) at ??:? #4 Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::update(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) at ??:? #5 Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::constructFromSurface(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::autoPtr<Foam::searchableSurface> const&) at ??:? #6 Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::AMIInterpolation(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::autoPtr<Foam::searchableSurface> const&, Foam::faceAreaIntersect::triangulationMode const&, bool, Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolationMethod const&, double, bool) at ??:? #7 Foam::cyclicAMIPolyPatch::resetAMI(Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolationMethod const&) const at ??:? #8 Foam::cyclicAMIPolyPatch::AMI() const at ??:? #9 Foam::cyclicAMIPolyPatch::applyLowWeightCorrection() const at ??:? #10 Foam::cyclicAMIFvPatch::makeWeights(Foam::Field<double>&) const at ??:? #11 Foam::surfaceInterpolation::makeWeights() const at ??:? #12 Foam::surfaceInterpolation::weights() const at ??:? #13 Foam::fvPatch::weights() const at ??:? #14 Foam::coupledFvPatchField<double>::evaluate(Foam::UPstream::commsTypes) at ??:? #15 Foam::cyclicFvPatchField<double>::cyclicFvPatchField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:? #16 Foam::fvPatchField<double>::adddictionaryConstructorToTable<Foam::cyclicFvPatchField<double> >::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:? #17 Foam::fvPatchField<double>::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:? #18 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::Boundary::readField(Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:? #19 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readFields(Foam::dictionary const&) at ??:? #20 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readFields() at ??:? #21 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&) at ??:? #22 ? at ??:? #23 ? at ??:? #24 ? at ??:? #25 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #26 ? at ??:? Aborted (core dumped) My creratePatch sample is : Code:
FoamFile { version 2.0; format ascii; class dictionary; object createPatchDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // // This application/dictionary controls: // - optional: create new patches from boundary faces (either given as // a set of patches or as a faceSet) // - always: order faces on coupled patches such that they are opposite. This // is done for all coupled faces, not just for any patches created. // - optional: synchronise points on coupled patches. // - always: remove zero-sized (non-coupled) patches (that were not added) // 1. Create cyclic: // - specify where the faces should come from // - specify the type of cyclic. If a rotational specify the rotationAxis // and centre to make matching easier // - always create both halves in one invocation with correct 'neighbourPatch' // setting. // - optionally pointSync true to guarantee points to line up. // 2. Correct incorrect cyclic: // This will usually fail upon loading: // "face 0 area does not match neighbour 2 by 0.0100005%" // " -- possible face ordering problem." // - in polyMesh/boundary file: // - loosen matchTolerance of all cyclics to get case to load // - or change patch type from 'cyclic' to 'patch' // and regenerate cyclic as above // Do a synchronisation of coupled points after creation of any patches. // Note: this does not work with points that are on multiple coupled patches // with transformations (i.e. cyclics). pointSync false; // Patches to create. patches ( { // Name of new patch name cycAMI_1; // Dictionary to construct new patch from patchInfo { type cyclicAMI; neighbourPatch cycAMI_2; // Optional: explicitly set transformation tensor. // Used when matching and synchronising points. //transform rotational; //rotationAxis (1 0 0); //rotationCentre (0 0 0); transform coincidentFullMatch; // separationVector (1 0 0); // Optional non-default tolerance to be able to define cyclics // on bad meshes //matchTolerance 1E-2; } // How to construct: either from 'patches' or 'set' constructFrom patches; // If constructFrom = patches : names of patches. Wildcards allowed. patches (d_l); // If constructFrom = set : name of faceSet //set f0; } { // Name of new patch name cycAMI_2; // Dictionary to construct new patch from patchInfo { type cyclicAMI; neighbourPatch cycAMI_1; // Optional: explicitly set transformation tensor. // Used when matching and synchronising points. //transform rotational; //rotationAxis (1 0 0); //rotationCentre (0 0 0); transform coincidentFullMatch; // separationVector (1 0 0); } // How to construct: either from 'patches' or 'set' constructFrom patches; // If constructFrom = patches : names of patches. Wildcards allowed. patches (d_s); // If constructFrom = set : name of faceSet //set f0; } /* { // Name of new patch name cyc_1; // Dictionary to construct new patch from patchInfo { type cyclic; neighbourPatch cyc_2; // Optional: explicitly set transformation tensor. // Used when matching and synchronising points. //transform rotational; //rotationAxis (1 0 0); //rotationCentre (0 0 0); // transform translational; // separationVector (1 0 0); // Optional non-default tolerance to be able to define cyclics // on bad meshes //matchTolerance 1E-2; } // How to construct: either from 'patches' or 'set' constructFrom patches; // If constructFrom = patches : names of patches. Wildcards allowed. patches (symmetry1); // If constructFrom = set : name of faceSet //set f0; } { // Name of new patch name cyc_2; // Dictionary to construct new patch from patchInfo { type cyclic; neighbourPatch cyc_1; // Optional: explicitly set transformation tensor. // Used when matching and synchronising points. //transform rotational; //rotationAxis (1 0 0); //rotationCentre (0 0 0); // transform translational; // separationVector (1 0 0); } // How to construct: either from 'patches' or 'set' constructFrom patches; // If constructFrom = patches : names of patches. Wildcards allowed. patches (symmetry2); // If constructFrom = set : name of faceSet //set f0; } { // Name of new patch name symmetry2; // Dictionary to construct new patch from patchInfo { type patch; //neighbourPatch cyc_half1; // Optional: explicitly set transformation tensor. // Used when matching and synchronising points. // transform rotational; //rotationAxis (1 0 0); // rotationCentre (0 0 0); // transform translational; // separationVector (1 0 0); // Optional non-default tolerance to be able to define cyclics // on bad meshes //matchTolerance 1E-2; } // How to construct: either from 'patches' or 'set' constructFrom patches; // If constructFrom = patches : names of patches. Wildcards allowed. patches (FaceGroup17 FaceGroup8); // If constructFrom = set : name of faceSet //set f0; } */ ); // ************************************************************************* // Any adivce will be really apprciated , unfortunatlly its very computationally expensive simulation sine its LES and I need to reconstruct the case . Thanks Bashar |
|
May 18, 2021, 04:05 |
|
#279 |
Senior Member
Franco
Join Date: Nov 2019
Location: Compiègne, France
Posts: 129
Rep Power: 7 |
Hello everybody,
I am seeking help with the cyclicAMI boundary condition, I am meshing a geometry with snappy and after this step, I create my cyclicAMI patches with the createPatch function. my issue seems to comme from the difference in number of faces between the inlet and outlet patches see error: Code:
Calculating AMI weights between owner patch: InletAMI and neighbour patch: OutletAMI AMI: Creating addressing and weights between 31721 source faces and 31730 target faces [0] [0] [0] --> FOAM FATAL ERROR: (openfoam-2012) [0] Unable to set target face for source face 31714 [0] [0] From virtual bool Foam::faceAreaWeightAMI::setNextFaces(Foam::label&, Foam::label&, Foam::label&, const Foam::bitSet&, Foam::labelList&, const Foam::DynamicList<int>&, bool) const [0] in file AMIInterpolation/AMIInterpolation/faceAreaWeightAMI/faceAreaWeightAMI.C at line 347. [0] FOAM parallel run aborting |
|
May 18, 2021, 04:13 |
|
#280 |
Senior Member
|
Having different number of cells on the two neighboring patches is not an issue.
It sounds like you have one cell face that doesn't find any neighbor, that's an issue. There are some parameters to ignore this type of issue or you can verify visually that all faces properly match with one or more neighbors |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
UDF compiling problem | Wouter | Fluent UDF and Scheme Programming | 6 | June 6, 2012 05:43 |
Gambit - meshing over airfoil wrapping (?) problem | JFDC | FLUENT | 1 | July 11, 2011 06:59 |
natural convection problem for a CHT problem | Se-Hee | CFX | 2 | June 10, 2007 07:29 |
Adiabatic and Rotating wall (Convection problem) | ParodDav | CFX | 5 | April 29, 2007 20:13 |
Is this problem well posed? | Thomas P. Abraham | Main CFD Forum | 5 | September 8, 1999 15:52 |