SonicDyMFoam: DynamicMeshDict Solver?
Hello all,
I am trying to implement the tutorial mixerVesselAMI2D in sonicDyMFoam (it is normally in pimpleDyMFoam). When I try to run the case, I get the following error: Code:
--> FOAM FATAL IO ERROR: Code:
dynamicFvMesh solidBodyMotionFvMesh; Could anyone suggest how I could fix this? Thanks, Dan |
Greetings Daniel,
I'm feeling poetic... so I'll paraphrase a well known expression: Quote:
OK, so the core reason why the "dynamicMeshDict" has to be configured differently is because the solvers themselves are different when handling dynamic meshes:
Looking at the tutorials for mesh motion only: https://github.com/OpenFOAM/OpenFOAM...oveDynamicMesh - you'll find these two examples:
Now the real problem is... will sonicDyMFoam perform the way you want it to, since it uses dynamic meshes differently? Unfortunately, that I do not know the answer :( Best regards, Bruno |
Hello Bruno,
Thanks for the quick and thorough response! I will dig into the code to identify the differences, though at first glance I think my best bet would be to make sonicDyMFoam handle dynamic meshes like pimpleDyMFoam. Any idea why there would be two ways to handle dynamic meshes? I cannot conceive of a link between dynamic mesh handling and compressibility. Thanks, Dan |
Hi Daniel,
Quote:
But when it comes to sonicDyMFoam, I wouldn't be surprised that the real issue is that the code was not upgraded... ... OK, so I went back in time and stopped at OpenFOAM 1.5.x. Back then, it was actually named sonicFoamAutoMotion :D: http://repo.or.cz/w/OpenFOAM-1.5.x.g...amAutoMotion.C If I understand things correctly, this solver only takes into account motions in the mesh. It does not handle flux corrections, refinements or AMI. Just plain old-simple mesh motions are supported. And as the header on the solver states: Quote:
If you have a look into the tutorial "incompressible/pimpleDyMFoam/movingCone", this one seems to be easily adapted for working with sonicDyMFoam... although it'll require some adjustments in order to throw the fluid into a supersonic laminar flow... although with a symmetry place in the correct place, you can easily do it! Best regards, Bruno |
Thanks again, Bruno! I will try the other method of displacement - it is not as directly applicable as that used by mixerVessel, but it may still do the job.
Regards, Dan |
Bruno,
Sorry to hijack this thread.... I've managed to get my AMI mesh moving but I'm finding that the model crashes when the valve begins to close. I have been trying to figure out why and have been experimenting. The model, you might remember, is DP driven and I have been trying to use rhoPimpleFoam since the DP drive is quite large, over 1e7 Pascals. I have concluded that I should be using sonicDymFoam, this is why I'm on this thread! If I am moving the valve walls would this be movingTopology rather than movingMesh? If sonicDyMFoam can only handle movingMesh does this mean I can't implement the valve closure using this numerical Solver? If this is the case how am I going to get rhoPimpleDyMFoam to solve as the valve nears closure (or begins to crack open which is ACTUALLY what I'm trying to model). Your opinion would be gratefully received as always. Best Regards Andrew |
Greetings Andrew,
A few more details about how the mesh is behaving where the valve is opening/closing would be helpful to further understand what's in play here. In addition, knowing what kind of mesh you are using could be helpful as well, namely if it is purely tetrahedral mesh or polyhedral or mixed cell types. I vaguely remember reading on this topic here on the forum, where this kind of simulation is rather complicated to perform, specially when the closure means that the mesh will have to be cut or stitched together. Ah, here we go: http://www.cfd-online.com/Forums/ope...tml#post406801 post #9 Well, that post was written before OpenFOAM 2.2 was released, but I think AMI hasn't improved so much yet. The information related to AMI was: http://www.openfoam.org/version2.2.0...conditions.php - I honestly haven't figured out what they mean by "fixedJump" :( Some time ago there were some tutorials for engineFoam, which one would think that should have valves in it, but I've never looked into it properly. Now, without a solution in sight, my best bet would be to:
Oh, as for your question about sonicDyMFoam and topology: dynamic mesh solvers are allegedly meant to be able to handle dynamic motion of meshes, including topology changes, as long as the "constant/dynamicMeshDict" provides the correct libraries and settings. Of course the problem is to know which library can handle this kind of thing :( Best regards, Bruno |
Bruno,
Thanks for the your response! In answer to your questions, my mesh is purely tetrahedral, I used Salome to develop the mesh and it seems pretty good, I found that trying to make a structured hexahedral mesh was REALLY difficult since I was getting oddball cell shapes that neither Salome liked or checkMesh for that matter. I think that my problem is that rather large pressure differential across the model, 1.6e7 down to 1e5 Pascals. I initially thought that this was producing large velocities that the solver, rhoPimpleDyMFoam, was unable to cope with but looking closer these velocities are around 300 - 750 m/s which I'm pretty sure can be dealt with by rhoPimplDyMFoam. I have tried different ways of initialising the model and I have found that the model really blows up when I set my initial conditions for inlet and outlet pressure as 1e7 and 1e5 Pascals, which to me being an Engineer, seems pretty obvious. If I set the outlet initial condition to be lets say 10000 Pascals less than the inlet then the model seems to pick up and run but the almost closed condition still blows up. I have hit upon trying to use rhoSimpleFoam to get a steady state condition that I can then start the moving model off with but I find that the big pressure differential causes problems again. At the moment I have initialised the steady state with NO pressure differential, I have set BOTH inlet and outlet to 1e7 Pascals. Obviously rhoSimpleFoam is ecstatic about this and the model reaches steady state! Unfortunately I'm not sure how to take the steady state model and make it transient. I'm not sure how I would reset the outlet boundary condition pressure to 1e5 Pascals to get the drive working again. I'm going to try running the model from valve fully open to valve fully closed and see exactly where the failure occurs. I will then repost to the forum. I'll go and have a look at the links you posted about the sliding interfaces. I might be able to avoid this true sliding interface by accepting a small amount of leakage past the valve, ie having some mesh between the valve body and the walls which I suppose would get around the sliding interface problem. I just wonder how small a gap I can have between the valve and AMI interface before things get out of shape. Regards Andrew |
Hi Andrew,
A few notes:
Bruno |
Hi Bruno,
Thanks for your pointers I am just browsing through them at the moment. While I was browsing I thought I would try a slightly different approach. This approach was taken by one of the OpenCFD trainers at the start of the year when I attended the OpenFoam course in London. This was a basic model with no moving mesh or topology and the inlet pressure was "bled in" from atmospheric up to 1.6e7 Pascals. The model used sonicFoam but I played with it and managed to get it working with pimpleFoam and rhoPimpleFoam so I know these solvers CAN model the final flow regime. What I have done is moved the mesh using moveDynamicMesh until the valve is fully open then copied the points file from my final time step back into the constant/polyMesh directory then started the simulation with the internal pressure set to 1e5 Pascals and the inlet pressure increasing over time using a table function in the BC file, I have set the rotating Motion to 0 deg/sec to fix the valve in position. I have found that the model crashes when the inlet pressure reaches about 2e5 Pascals which is odd because the geometry is essentially the same as the test case from the start of the year. But I can see that the MESH has changed!! I have noted that the time steps, which I have allowed to be adjusted, are about 1e-7 seconds and the model crashes quickly, after only a couple of iterations, if I try to set the initial timestep to anything greater than 1e-5 seconds. Could this be a geometry/mesh issue? The original test model was made with a structured Hex mesh whereas this model is a tetrahedral unstructured mesh which I have tried to refine around the AMI interface and around the valve / downstream restriction orifice. I have used Salome to generate the mesh since I found that sHM couldn't formulate a mesh that I considered usable and the geometry is a little too complex for me to generate a blockMesh input file. The link below is to a zip of the model, the final step before running the case. I wonder if you could run this and let me know your thoughts? https://www.dropbox.com/s/bmbx13k4lsg2rng/model.zip Since I am accepting some leakage past the valve I believe that this ISNT, now, a sliding face problem since I have a continous mesh around both sides of the AMI interface. Would you consider this to be correct thinking? Hope you can point me in the right direction! Thanks Andrew |
Hi Bruno,
I thought I would just give a brief update on where I have got to. I'm still running the model with the FIXED mesh at the moment, ie no moving valve body. The model still crashes :-( I had noticed that with a 1e5 Pascal outlet pressure boundary condition the solver was beginning to calculate negative pressures which I guess I should have seen, considering the venturi effect across an orifice results in a dip in pressure BELOW the downstream pressure prior to recovering to the downstream pressure! My current position is that I have refined the mesh quite substantially since I had thought the the flow pattern at the walls looked a little rough and I thought this might be causing localised upsets. I have also increased the outlet pressure BC to 2e5 pascals which seems to remove the dip into the negative pressure. This final (current) crash seems to show that the rhoMax/rhoMix reporting is little odd. rhoMin seems to have flat lined at the minimum allowed value (0.5) supplied in the fvSolution file. This seems to happen a couple of reporting steps before the crash. up until this point the rhoMin is being calculated at about 0.7-0.8 which is about right for the fluid I am modelling with. To investigate this I have reduced the allowable Courant number from 0.9 to 0.4 and reduced the time reporting steps to get a closer step resolution in paraFoam. If I am having physical property problems would I be better using something other than this: thermoType { type hePsiThermo; mixture pureMixture; transport sutherland; thermo hConst; equationOfState perfectGas; specie specie; // energy sensibleInternalEnergy; energy sensibleEnthalpy; } Would I get better control if I were to use perhaps a polynomial correlation, like JANAF or something?, and change from perfect gas? Not sure how I would implement this though ? Would appreciate your direction here? Andrew |
Hi Andrew,
I'm glad you've been moving forward with this! I haven't managed to look into this myself, which is why I didn't give you any feedback :(. I haven't managed yet to read your posts carefully, but I'll try to look into them and to do some experiments with the case this coming weekend, specially because I'm interested in these kinds of simulation cases. Best regards, Bruno |
Bruno,
Thanks for your comments..... one thing has occurred to me tonight. I have approached this problem from a couple of different directions, the starting point at 2e5 Pascals and 1e6 Pascals, with the outlet BC pressure set at 2e5 Pascals. The pressure, I see, is falling to around 2e4 Pascals. When I declare rhoMin as 0.5 in fvSolutions what pressure will this refer to? if it is one of the BC pressures then the solver must be trying to EXTRAPOLATE the rho value and getting silly numbers and then fixing at 0.5 which I am suspecting will cause instabilities in the solution. Do you have any thoughts about this? how can I prevent the solve extrapolating, or coming up with a unmoving value? If I can provide a tabular input for pressure Vs density I think this might solve my problem ?? Regards Andrew |
Hi Bruno,
I wonder if you can answer this one from your experience?? Does OpenFoam consider choked velocity? I'm seeing velocities well in excess of sonic in the downstream (or the orifice) pipework. In my experience choked velocity in pipework is a natural limit at Mach 1. I'm using rhoPimpleDymFoam (also rhoPimpleFoam this morning!) but I'm sure that I have seen the same with sonicFoam. The model is still crashing with a rhoMin going to the minimum allowed by fvSolution immediately after the last stable time reporting step. :-( Regards Andrew |
Bruno,
I'm beginning to think I am having mesh problems. I might go back to a basic geometry with no movement and try to get it working. Like I said the OpenCFD tutor produced a model that worked happily with little refinement with sonicFoam, pimpleFoam and rhoPimpleFoam. The mesh was no where near as fine as the mesh I have produced and there were no crashes, even when I ran the model with full inlet pressure (1.6e7) and minimum outlet pressure (1e5). It's frustrating but I think this is best since I am using Salome for mesh production and the tutor used blockMesh so I need to establish that Salome can create a mesh that will work for this geometry. I'll keep updating this thread with my progress. I would still appreciate your guidance on the different thermoPhysicalProperties methods, ie replacement for perfectGas and JANAF or other polynomial/tabular property methods, as I would like to run my final model as close to the "real" thing as I possibly can, I have compositional data from a process simulator that can provide physical properties that differ from those I am using at present. Regards Andrew |
Hi Andrew,
I'll try to answer now a few of the quickest answers, the others I'll try to do in a few hours from now: Quote:
Quote:
Quote:
If you prefer using GUIs, try:
Quote:
You can try using polyDualMesh, but it's not a silver bullet: http://openfoamwiki.net/index.php/PolyDualMesh It essentially is able to create the dual of the tetrahedral mesh, which is a polyhedral mesh. Problem is that polyhedral meshes can be very tricky to use on dynamic meshes... Quote:
In the lack of such, use JANAF, since is scientific/engineering data (I think), ready to be used. But you have to be careful with the temperature limitations that these tables. As for during development, perfect gas should be ... perfect for development of the base case :D Best regards, Bruno |
Bruno,
Thanks for the FURTHER responses :-) I'll have a look at the SwiftBlock, that looks interesting and might give me a fighting chance of getting a mesh to work properly! As far at 2D is concerned, I am working in 2D because I didn't see the value in doing 3D for this problem, since the model would potentially have >>1e6 cells and I don't want to tie my laptop up for too long in one go! I'm going to, also, try structured Hex mesh again since unstructured, as you say could also be adding to my problems. I have avoided using blockmesh for my geometry stating that it is too complex. What is your opinion here am I being to hard on blockMesh? Is it possible to do this geometry using blockMesh given the annulus around the valve etc?? I'll update after my next step! Regards Andrew |
Hi Andrew,
Quote:
I haven't used SwiftBlock yet, so I don't know what are the limitations, but in theory you should be able to draw each mesh block. I didn't manage to look into this yesterday, but I'll try to at least look today at the case you shared. Best regards, Bruno |
1 Attachment(s)
Hi Andrew,
Quote:
Attached is an image that clearly indicates that using the tetrahedral cells are very bad news near the walls. Unfortunately, using polyDualMesh only made things a lot worse. I've got a question: what on Earth is that ring? Is the valve actually a sphere inside a flexible-wall tube? But still... it's very confusing, specially since there is mesh inside the "sphere"... As for the case itself, it does need to have a proper mesh. Tetrahedral mesh is simply not going to cut it, as you can see from the attached image. You could try adding a prismatic boundary layer to the walls and inlet/outlet, but it won't fix everything. You could try using enGrid, which is able to generate prismatic boundary cells, along with using a tetrahedral mesh inside the domain, but enGrid is a bit tricky to use... As for mesh motion, this clearly looks like a mesh that needs to collapse cells... otherwise the cells will become very small when the valve continues to advance to the constriction. Either way, the conclusion is simple:
Best regards, Bruno |
Hi Bruno,
Sorry , didn't see your post come in, must look at my settings! https://dl.dropboxusercontent.com/u/...%20Diagram.jpg The link above might explain what my geometry is actually trying to achieve, rather than me writing a load of words just now. But the basics are that the valve is a moving ball with a single straight through port. The ball rotates on a shaft from closed to open (and the other way :-) ) All this model is steel. I have simplified the geometry to just show the ball and the "envelope" of the valve body (this is all rigid) I think that should explain the mesh within the valve. I'm looking at structured Hex meshing with blockMesh since I am a little suspicious of conversion from an external mesh type to internal OpenFoam type. I just want to rule this out. I'll keep posting my progress! Regards Andrew |
All times are GMT -4. The time now is 17:02. |