Greetings Vincent,
261 rad/s is in fact 2492.37 RPM... but still, this isn't the problem. The sign for "omega" seems correct as well. This is still a lot of guessing work you're asking from us here. My guess is that you've only let the propeller run for something like 0.5 or 2 seconds, which is far from enough to allow for the fluid flow to be fully developed and that would explain why you're seeing around 4 times as much force needed to displace the fluid. If you can at least provide the files "controlDict", "U" and "p" (or "p_rgh", I'm not sure), it might make our lives easier in helping you diagnosing this problem. Best regards, Bruno |
3 Attachment(s)
Hey Bruno
Thanks for reply. I join the "p", "U" and "controlDict" file. Indeed, I perform my case during only 0.2s and may be it's not enough. I'm going to perform a new calculation. Best regards. Vincent |
Hi Vincent,
In 0.2s at 2500RPM your propeller would do: 2500 / 60 * 0.2 = 8.3(3) rotations. I can understand why you would think this is enough for incompressible flow, but my guess is that at least a run of 2-5 seconds might be necessary. But there is something that makes me more concerned about, in the "controlDict" file: Code:
maxCo 2; Last but not least: what values did you define in the "constant/transportProperties" dictionary file? Best regards, Bruno |
1 Attachment(s)
Hi Bruno
Many thanks for your help and sorry for my late answer. I'm beginner with pimpleDyMFoam and propeller case. I was too optimistic and I believed 0.2s was enough. For the maxCo, I just take the same than in propeller tutorial. I join my transportProperties file. But now, I reduced this and perform a new calculation with 2s. Best regards |
Hi Vincent,
Thanks for providing the "transportProperties" file. Notes:
Best regards, Bruno |
Problems with AMI and non-planar surfaces
2 Attachment(s)
Dears,
even if in a previous post I suggested the use of cyclicAMI, I had some problems especially when I tried to use them in the case of non planar patches. Generally, in order to model the steady state performances of propellers, I used to model only a "triangular slice" of the computational domain and apply, with success, periodic boundary conditions with AMI. This is a rather straightforward way to reduce the computational effort but especially in the case of very skewed propellers (it means propeller blades with an exagerated "babana" shape) it is possible that the triangular slice of the domain cuts two subsequent blades, causing some problems in the develpment of the boundary layers (if the mesh is calculated using snappyHexMesh) in correspondence of the intersection of the blade with the periodic patch. So I try to use "curved domains" (I used this kind of shapes routinely with StarCCM+, for instance) as that proposed in the figure. Unfortunately, even if the mesh generated with snappy is apparently ok, when I try to create the cyclicAMI (forcin rotationAxis and center of rotation) I had this error: Code:
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // I moved to cfMesh with exactly the same kind of problem. On the other hand, if as suggested for rotational interfaces, I include also the rotationAngle option in the createPatch dict the error is: Code:
stefano@stefano:~/OpenFOAM/stefano-2.3.0/KCS/KP505_snappy$ createPatch I' pretty sure the problem is in the mesh. When I import exactly the same domain but meshed with StarCCM+ for instance, AMI works perfectly with uniform min, max and average weights equal to 1, due to the fact that StarCCM+ is able to produce conformal matching interfaces. Do you have any suggestion in order to use snappy of cfMesh with this kind of computational domains/curved interfaces? Many thanks, Stefano |
Quick answer - @Stefano: I strongly suggest that you upgrade to OpenFOAM 2.3.1 or 2.3.x, because that crash looks like a familiar bug to me...
If you had provided a test case, I could have tested this just now with the various versions of OpenFOAM I have installed. |
Dear Bruno, thank you for your quick suggestion. I will try as soon as possible to upgrade to OF2.3.1 and test my geometry.
For those who would like to test it by their own (Bruno, you are welcome :) !), you can find the complete test case (for naval architects it is the well-known case of the KCS ship) following this dropbox link: https://dl.dropboxusercontent.com/u/..._curved.tar.gz thank you again for any suggestion! Stefano Quote:
|
1 Attachment(s)
Hi Stefano,
The case you had provided had a damaged "createPatchDict". I've looked at your case, by running with OpenFOAM 2.3.x. And after finishing meshing it, I think you're asking too much from OpenFOAM's "cyclicAMI" matching algorithm. As far as I can figure out, the curves you have between each level are extremely hard to match to each other. Attached is an image that overlaps the result from the "Int_1" patch over the "Int_2" patch, done by applying the Transform filter to one of them with 72 degree rotation over X. As you can see in the image, you're asking for too much from the matching algorithm for those particular large radius curves, which got meshed a bit poorly :( Best regards, Bruno |
Dear Bruno, thank you again for your extermely rapid answer and the effort you put to solve my case.. and sorry for the damaged file
Me too I believe that the mesh on the interfaces is too coarse. The snappyhexmesh dict is one of those I used in order to understand the reasons of the problem. Among them I have solutions with very very fine meshes on th einterfaces and I checked, only qualitatively, in paraview the matching between the interfaces. In any case I never had AMI. I also used differnt cuurved domains withouth success. I can understand the difficulties in the matching algorithm: sometimes I had "bad point" errors, also in the case of planar interfaces (it happens when the propeller blade, due to skew, is cut by the interface and I have portion of differnt blades in the domain, feature curves are not properly treated or the boundary layer not correctly extruded). These are the reasons to use a curved domain, to completely include one single blade in the computational domain. What sounds strange to me is the warning and the subsequent error of "different bounding box". Do snappy alters so much the original patches to avoid any matching? The same kind of errors happens when I completely change the meshing approche and I use cfMesh. In this case, with very coarse meshes (not useful for computations :-(), the matching is succesfull but with weights very very low. Thank you again, Have a nice (half)weekend, Bests, Stefano Quote:
|
Hi Stefano,
I believe that the big differences in the bounding boxes is actually due to the algorithm not being able to properly ascertain how the patch was rotated. There are a few details that come to mind:
Bruno |
Dear Bruno,
thank you again for your quick and always exaustive answer.. I will try blockMesh with polyline and extBlockMesh in order to try to cope the problems with the interface. I already tested something similar to "MakeAxialMesh" buut i encountered lot of problems with very "non-cubic" cells to be snapped on STLs. Bests, Stefano Quote:
|
1 Attachment(s)
Hi All,
Stefano, I am currently in a pretty much identical situation - I'm creating a wedge grid for a marine propeller with AMI cyclic conditions. I've encountered (unsurprisingly) the same problem as you, except I am using structured grids. I've ran a few tests on a simple setup and arrived at the conclusion Bruno has given - I was trying to exploit the flexibility of the AMI too much with my patches being too different, see attached picture. I have previously tried to use snappy for something similar but found the meshes it gave me of very poor quality when the underlying blockMesh grid had high aspect ratios (which are inevitable in this context I think). If you can't get snappy to work then perhaps tetrahedrals will do the job for you? (e.g. http://engits.eu/en/engrid ) Best of luck anyhow (to you and to me :) ), A |
1 Attachment(s)
Dear Bruno, dear Artur,
Finally I have time to answer and show my succesfull results! Following the suggestions by Bruno, I've found that the only way to work with "curved" domain is to have the domain and "high quality" boundaries by blockMesh, that is the only way to avoid snappy change their shape (excpet by increasing the number of cells) ... modifications by snappy are the cause of the warnings, the "sorce and target" error and so on... Unfortunately I was not lucky with extBlockMesh (for my geometry the smoothing stops at the first iiteration.. on the forum also other users had this problem but a clear solution has not yet been poste) and I have to built entirely the domain using block, polilines and splines. In this way interfaces match correctly (with all weights close to 1) but cells are a bit to non-orthogonal (and non cubic) especially (but fortunately) far from the place where the propeller has to be snapped. I tried to use extBlock only as a smoother to improve the quality of the cells.. also in this case without success... So the only drawbak of this procedure is the quality of lots of cells far from the propeller, that require loosening of the quality factor for snappyHexMesh. However results, also in terms of predicted forces, are satisfactory, as you can see from the figure. So, thank you to all who contributes to these successfull results.. of course any suggetsion to improve the quality of the base mesh is welcome! |
Hi,
Great to see you've made progress, the mesh looks really good I must say. Quote:
A |
I mean that I have to built the entire curved domain including the interfaces directly using blockmesh. My previous tentatives were to build a regular block with blockmesh and then to snap the curved interfaces using snappy.
Actually I use snappy only to snap the blade and the hub. Inlet,outlet, interfaces and so on are previously defined with blockMesh... |
OK, I see. That makes sense since like this you have nearly perfectly matching cyclics, so you could probably get away even with the cyclic and not even amiCyclic type.
Thanks a lot for sharing this, I definitely have to try your method this week :) All the best, A |
Dear Artur,
unfortunately in my case I have to use AMI due to the fact that the blade is non symmetric, so snappyHexMesh refinements act differently on the two interfaces (for instance the blade leading edge is closer to the right interface than the blade trailing edge to the left interface). However until you work only with refinements (no prism layer i tersecting the interfaces) AMI weight are close to 1 anyway. The only issue is the higher non-ortogonality of the cells far from the axis of the domain... Bests, Stefano |
1 Attachment(s)
Hi,
I see, well at least AMI works for you :) I've found the same problem with highly non-orthogonal cells far away from the axis of rotation. Since that's a constraint on the domain shape rather than a mesh generation issue I personally don't think much can be done about it. Maybe you could deform the mesh there somehow using blockMesh to get something like this: Attachment 37889 I don't think this will be easy to do though. A |
definitely not easy...
I hope extBlockMesh may help, but till now no success...! |
All times are GMT -4. The time now is 18:22. |