[dancfd]

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:

--> FOAM FATAL IO ERROR: 
keyword solver is undefined in dictionary "/home/daniel/OpenFOAM/daniel-2.1.1/run/cases/mccroskey1982/o-grid/mixerVesselAMI2D_sonicDyMFoam/constant/dynamicMeshDict"

I do not understand why a solver is required in dynamicMeshDict for this case. mixerVesselAMI2D uses

dynamicFvMesh   solidBodyMotionFvMesh;

unlike other pimpleDyMFoam cases that use other dynamicFvMeshes; therefore I do not understand why a solver needs to be specified in the compressible but not incompressible moving mesh solver.

Could anyone suggest how I could fix this?

Thanks,

Dan

[wyldckat]

Greetings Daniel,

I'm feeling poetic... so I'll paraphrase a well known expression:

And the code shall set you free!

OK, so the core reason why the "dynamicMeshDict" has to be configured differently is because the solvers themselves are different when handling dynamic meshes:

• pimpleDyMFoam relies on "createDynamicFvMesh.H" for creating a dynamic mesh:
  • https://github.com/OpenFOAM/OpenFOAM...eDyMFoam.C#L49
  • https://github.com/OpenFOAM/OpenFOAM...ynamicFvMesh.H
• sonicDyMFoam relies on a motion solver, coded directly into the main solver: https://github.com/OpenFOAM/OpenFOAM...cDyMFoam.C#L52

The solution... well, the quick fix is to add the missing "solver" entry. A quick search lead me to moveMesh which also relies on the "motionSolver" class: https://github.com/OpenFOAM/OpenFOAM...moveMesh.C#L46
Looking at the tutorials for mesh motion only: https://github.com/OpenFOAM/OpenFOAM...oveDynamicMesh - you'll find these two examples:

• https://github.com/OpenFOAM/OpenFOAM...ynamicMeshDict
• https://github.com/OpenFOAM/OpenFOAM...ynamicMeshDict

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

[dancfd]

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

[wyldckat]

Hi Daniel,

Originally Posted by dancfd

Any idea why there would be two ways to handle dynamic meshes? I cannot conceive of a link between dynamic mesh handling and compressibility.

There are various ways of handling dynamic meshes. AFAIK, it can go from a dynamic refinement depending on the evolution of a field, to the full-on AMI.

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 : 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:

Transient solver for trans-sonic/supersonic, laminar flow of a compressible gas with mesh motion.

Compressible, but only laminar flow! This seems to be the key reason why it only uses mesh motion...

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

[dancfd]

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

[ADGlassby]

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

[wyldckat]

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:

1. Simulate up to the point where the valves have barely not yet closed/opened, which might imply that you need to make the time step as smallest/necessary and as possible near the point of closing/opening.
2. Then use a new case with the mesh in place without/with the aforementioned crack, respectively.
3. Use mapFields to interpolate the results from the last simulation time snapshot to the new mesh.
4. Then happily continue simulating the rest of the moving process, until you hit the same issue of open/close

But I've never done this myself, so I have no clue if it will work or not


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

[ADGlassby]

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

[wyldckat]

Hi Andrew,

A few notes:

• The only tutorial I can remember that works by pressure difference is this "incompressible/pimpleFoam/TJunction".
• Mesh resolution in the right places is highly important. A few examples:
  • http://www.cfd-online.com/Forums/ope...tml#post451688 - post #6
  • Strange Results at Tank Outlet with InterFoam post #17
• One suggestion is that you do a local study of the zone where the flow is becoming constrained, by modelling with a 2D model of one side of a cross-section of the valve. This way you can study the level of mesh refinement you need and see what forces and speeds are in play here.

Best regards,
Bruno

[ADGlassby]

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

[ADGlassby]

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

[wyldckat]

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

[ADGlassby]

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

[ADGlassby]

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

[ADGlassby]

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

[wyldckat]

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:

Originally Posted by ADGlassby

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.

I think that OpenFOAM can only do "consider choked velocity" if:

1. You use a solver that has abilities to simulate near sonic speeds.
2. You use a turbulence model that can encompass similar situations.

Originally Posted by ADGlassby

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).

That's one of the reasons why I wrote this on post #9:

Originally Posted by wyldckat

• One suggestion is that you do a local study of the zone where the flow is becoming constrained, by modelling with a 2D model of one side of a cross-section of the valve. This way you can study the level of mesh refinement you need and see what forces and speeds are in play here.

It's a lot easier to generate a 2D mesh near the valve using blockMesh or snappyHexMesh. And you can even have the dynamic mesh part working!
If you prefer using GUIs, try:

• SwiftBlock - http://openfoamwiki.net/index.php/Contrib/SwiftBlock
• SwiftSnap - http://openfoamwiki.net/index.php/Contrib/SwiftSnap

For more information on snappyHexMesh: http://openfoamwiki.net/index.php/SnappyHexMesh

Originally Posted by ADGlassby

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.

Tetrahedral meshes are useful for this kind of mesh motion, depending on the dynamic mesh library being used, but should used with a lot of care. Basically because tetrahedral meshes are bad for CFD

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...

Originally Posted by ADGlassby

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.

My experience on this is extremely limited, but my educated guess is that you should primarily use experimental data and/or data you trust. One simple example would be to use the polynomial equations that you can find on thermodynamic-related books.

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

Best regards,
Bruno

[ADGlassby]

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

[wyldckat]

Hi Andrew,

Originally Posted by ADGlassby

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??

Well, the idea I was trying to convey is that you can more easily create a similar 2D model using blockMesh, but probably not an accurate one. The objective is to have a proof of concept.
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

[wyldckat]

Hi Andrew,

Originally Posted by ADGlassby

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

I finally managed to look at the model. This reminds me of this post of mine: http://www.cfd-online.com/Forums/ope...tml#post451688 post #6 - if you look at the images on that post, you'll see how bad tetrahedral cells can be for CFD! And mesh-wise, it's very similar to your case!

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:

1. First you need a good mesh for CFD. You might want to start with a simpler valve geometry first, to make it easier to implement with blockMesh.
2. Then you can start worrying about the solver.
3. And only then you can finally worry about mesh motion...

By the way: have a look into the tutorial case "incompressible/pimpleDyMFoam/movingCone". It uses the "wedge" feature of OpenFOAM, which can help you simplify even further your experimental case set-up.

Best regards,
Bruno

[ADGlassby]

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