CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   CFX (http://www.cfd-online.com/Forums/cfx/)
-   -   CFX Piston Motion (CEL) (http://www.cfd-online.com/Forums/cfx/21672-cfx-piston-motion-cel.html)

 Dante October 4, 2005 19:34

CFX Piston Motion (CEL)

Can anybody help me to write down a CEL to define a piston motion with moving grid?

 Robin October 5, 2005 13:27

Re: CFX Piston Motion (CEL)

How about A/2*(1+sin(omega*t)) Assuming your piston starts at the bottom position and A is equal to the sweep distance. Omega should be the frequency in radians per second (i.e. omeaga=2*pi*f, where f is the frequency).

The mesh distortion will be less if you start the piston in the middle position, in which case you should use A/2*sin(omega*t).

Regards, Robin

 Glenn Horrocks October 5, 2005 18:27

Re: CFX Piston Motion (CEL)

Hi,

Actually Robin, for piston motion mesh deformation with the current model available in CFX5 you have to start the piston at top dead centre. You then define the piston motion relative to the TDC position.

If you start anywhere else, when you get to TDC later in the stroke you often get elements turning inside out.

Regards, Glenn Horrocks

 mohammedammeen May 28, 2012 04:40

Quote:
 Originally Posted by Glenn Horrocks ;73382 Hi, Actually Robin, for piston motion mesh deformation with the current model available in CFX5 you have to start the piston at top dead centre. You then define the piston motion relative to the TDC position. If you start anywhere else, when you get to TDC later in the stroke you often get elements turning inside out. Regards, Glenn Horrocks
please help me in do the motion meshing in a hydrolic cylinder with grade 45 oil

 ghorrocks May 28, 2012 06:08

Your question is just about exactly the example of how not to ask a question on the forum in the FAQ: http://www.cfd-online.com/Wiki/Ansys...ible_answer.3F

 alpha754293 May 30, 2012 03:32

Quote:
 Originally Posted by Glenn Horrocks ;73382 Hi, Actually Robin, for piston motion mesh deformation with the current model available in CFX5 you have to start the piston at top dead centre. You then define the piston motion relative to the TDC position. If you start anywhere else, when you get to TDC later in the stroke you often get elements turning inside out. Regards, Glenn Horrocks
That's not entirely true. It depends on how you mesh it.

I'm actually doing a piston motion sim right now starting from BDC, but I've separated my volume/piston chamber into three separate domains - top, bottom, and middle.

Top is stationary. The whole bottom moves (i.e. all of the walls get exactly the same piston motion CEL assignment) along with the interface between the bottom and mid. The side walls of the mid are unspecified motion.

And I've also meshed the middle using PURE hexas only. (Which you can create by meshing either the top or the bottom interface, and then dragging the elements down (or up).)

So to say that you HAVE to stop from TDC isn't entirely true.

It depends on your problem and it also depends on how you think about your problem. There are many ways to skin the cat.

*edit*
Since this is about CFX and not the mesher/meshing -- the meshing aspect is treated separately only for the purposes of this forum. In reality, it goes hand-in-hand because it took me the greater part of a weekend just to get the mesh working correctly. (Tried a bunch of different meshers and schemes, and finally found one that worked - at least for me, for this purpose.)

Quote:
 Originally Posted by mohammedammeen (Post 363398) please help me in do the motion meshing in a hydrolic cylinder with grade 45 oil
The fluid shouldn't matter too much. As long as you have the material defined and you have all of the properties you need for it.

The piston motion itself is actually quite simple.

x = r/2 * sin(2*pi*f*t/1 [s])+r/2

where r is your stroke length and f is your frequency.

It's a simple crank motion. You should be able to resolve that with high school trig.

 ghorrocks May 30, 2012 07:21

Quote:
 That's not entirely true.
It was entirely true at the time I wrote that post 7 years ago. Since then ANSYS has improved the mesh smoothing algorithm and the problem has improved. In the old version even a perfect hex mesh would get mangled by TDC.

Quote:
 The piston motion itself is actually quite simple.
Your equation does not include the high frequency harmonics from the conrod. For the "correct" equation see page 292 of my thesis: http://hdl.handle.net/2100/248. I put correct in inverted commas because it is the ideal motion and does not include conrod/crank stretching, slop in the journal bearings and all that sort of stuff. If you think this is insignificantly small the engine I was working on showed signs the piston was just hitting the head when it was meant to have 0.7mm clearance.

 alpha754293 May 30, 2012 07:46

Quote:
 Originally Posted by ghorrocks (Post 363804) It was entirely true at the time I wrote that post 7 years ago. Since then ANSYS has improved the mesh smoothing algorithm and the problem has improved. In the old version even a perfect hex mesh would get mangled by TDC. Your equation does not include the high frequency harmonics from the conrod. For the "correct" equation see page 292 of my thesis: http://hdl.handle.net/2100/248. I put correct in inverted commas because it is the ideal motion and does not include conrod/crank stretching, slop in the journal bearings and all that sort of stuff. If you think this is insignificantly small the engine I was working on showed signs the piston was just hitting the head when it was meant to have 0.7mm clearance.
In my experience, it depends on what you're using to generate the mesh.

With Ansys Workbench and even ICEM CFD, what's supposed to be a perfect hexa mesh isn't because it doesn't always map it properly/perfectly between the top and the bottom surfaces.

I actually ended up using GAMBIT for that (using Cooper scheme) and that worked beautifully.

You can probably also use other meshing/grid generation programs like Gridgen, ANSA, or Hypermesh to do the perfect drag.

Even today, CFX mesher and ICEM CFD has issues with that. If you do the drag (or use Cooper scheme) such that when you look at it from the top view, you shouldn't see any shadows or any other lines (meaning that all of the elements line up on top of each other).

Then there should be no reason why it won't work from BDC.

If you do it from TDC, you either have to write the script for CFX for dynamic remeshing (which is sometimes otherwise referred to as cell growth/death), or you might end up with element stretching, which is good for the piston motion, but bad for being fine enough to resolve your flow variables. So...it depends. (And actually, the optimization between what's good for motion but fine enough for resolving your solution variables is quite difficult since they are on opposing ends of the requirements spectrum).

And you can always make the piston motion super complicated.

If you really wanted to, you can solve for the piston motion as a 7th order chaotic probability density function by integrating the Monte Carlo solution.

The OP and the second person that asked for help gave no mention of speed, so the inclusion of high frequency harmonics is an assumption, but not necessarily a specific statement of requirement.

Conrod stretching is a function of the mechanics and dynamics (and not because of CFX).

Slop of any kind, from any location, including all other manufacturing tolerances, and GD&T, and production/build variations are elements of their respective fields, and again, not because of CFX.

If you take GD&T into consideration, you end up with a PDF. (Typically Gaussian PDF, but a PDF nonetheless).

If you take production/build variations, that's statistical (deterministic by design, but chaotic results).

Slop is really the result of the two.

Conrod stretching can be simulated using FSI. Or just explicit dynamics/nonlinear FEA. (If I were to have to actually solve that, I'd probably be using LS-DYNA for it. It'd be overkill since I only really need to solve the momentum equations, but it's embedded into the energy solver of LS-DYNA, but you'd definitely be able to solve for the stretching/compression throughout, as a function of engine speed.)

But again, that's not really a CFX problem.

Add to that that you pretty much will always have some kind of variation in rotational speed, depending on the type of drive, so just trying to figure out what the lower case delta term is going to be is probably someone's dissertation.

I'm not sure if you can even set CFX up to solve over a sweep of variables. You MIGHT be able to do it with iSight so you can at least generate a RSO/RSM with all those runs. I hope you have a personal mini cluster, cuz you'll probably need it to get through all of those runs.

 ghorrocks May 30, 2012 08:33

Thanks for the essay :)

I think you missed my point about the mesh motion. In previous version of CFX, even a perfect mesh would get contorted and fold because the smoothing algorithm was not ideal. This is because the mesh smoothing used a function which you did not have much control over and even though mesh elements started in line they did not stay that way. This has been improved in recent versions. My original post is 7 years old and that was back in the days when mesh motion was new to CFX.

Your comments about piston motion are correct. The equation I referenced is simply an algebraic equation which includes the conrod effect on the piston. It is hardly any more difficult to implement than a sinusoidal function and is much more accurate. Of course it still ignores all the higher order things like slop and stretch, but at least the ideal motion is captured exactly.

 alpha754293 May 30, 2012 09:44

Quote:
 Originally Posted by ghorrocks (Post 363830) Thanks for the essay :) I think you missed my point about the mesh motion. In previous version of CFX, even a perfect mesh would get contorted and fold because the smoothing algorithm was not ideal. This is because the mesh smoothing used a function which you did not have much control over and even though mesh elements started in line they did not stay that way. This has been improved in recent versions. My original post is 7 years old and that was back in the days when mesh motion was new to CFX. Your comments about piston motion are correct. The equation I referenced is simply an algebraic equation which includes the conrod effect on the piston. It is hardly any more difficult to implement than a sinusoidal function and is much more accurate. Of course it still ignores all the higher order things like slop and stretch, but at least the ideal motion is captured exactly.
Well, you made a reference to your dissertation.

And I think that you might have missed how I said that it STILL does that/the same thing (even with Ansys 13).

Like I said, GAMBIT doesn't do that. I don't think that there's any smoothing that's done, although I could be mistaken on that (but as far as I know, if you have a straight cylinder, and you're using Cooper scheme, there's no smoothing done afterwards).

That's why I also said that if you look at it from the top view, you shouldn't see any shadows or any other lines because it's literally just a straight extrusion of your surface mesh along the length of the cylinder (z-axis in cartesian/cylindrical coordinates).

If you create the mesh in Ansys Workbench or even in ICEM CFD, and if you look at it from the top view and don't see a perfect extrusion, then the probability that there will be problems is a little bit higher.

Also, I've noticed/found (even with the current versions of the software) that even though you specify hexa, there are some elements on the inside that I don't think are necessarily pure hexas. I dunno. (SOMETHING has to get distorted such that the surface mesh on the top surface doesn't match what you get on the bottom surface) -- I'm not entirely sure what it is, or what causes it, but it's there. And that will cause problems (as I've discovered over the weekend) if you start from BDC.

But with the mesh that I'm using now, built with GAMBIT, I have no problems with it. (Again, that's GAMBIT, not CFX). Like I also said, I'm sure that you could probably do it with Gridgen, ANSA, or Hypermesh or whatever other grid/mesh/pre-processor you feel comfortable with. It's a meshing problem that's tightly integrated with the CFX problem.

And I'm pretty sure that even 7 years ago, GAMBIT was still around, and that you should still have been able to do the same thing. (I don't think that Cooper scheme has changed in 7 years. ;))

Heck, I'm pretty sure that Hypermesh and Gridgen were around 7 years ago as well. And if you REALLY needed it, you could have passed it through NASTRAN (if you must) before ultimately landing in CFX. (Although I've never actually tried that, but I don't see why it wouldn't work if you have pure CHEXA8 elements.)

I think that the problem really is program independent. If you have a perfect extrusion, there's no reason why it shouldn't work. If there's some kind of twist or distortion between your top and bottom faces, I think that's where your problem is going to arise. Or at least that's one of the first indicators that you might potentially run into problems with the mesh. (Course, why ICEM CFD doesnt' seem to be capable of doing Cooper scheme - I don't really know why...because you'd think that it'd be rather "basic".) But suffice to say that the logic and the thinking doesn't change with time or with programs so long as you can get what you want and it does what you ask it to do; out of it.

Like I said - the OP didn't ask or specify the parameters for the CEL. I think that the simplest sine motion is the easiest to relate to, visualize, and understand. But you can ALWAYS make it more complicated as the formula you gave - the derivation isn't always necessarily intuitive (though correct/accurate).

Course, that depends that you know something about the conrod and the piston (mass and inertial properties), which, being in CFD, isn't always necessarily a given. It also depends on the application, but in my little bit of experience, it seems like that development is ALWAYS in parallel, which means that the CEL you come up with using the initial inertial properties of the piston and conrod may or may not be what you'll end up with in the end. As to how much that'll impact your end application - well that depends.

I think that given the details provided by the OPs in this request/question - one can't necessarily assume that it's going to be high frequency (especially with grade 45 oil; although it may be possible, but that's going to be quite harsh cyclic/fatigue loading. Poor conrod. Poor drive unit!) At least I can't necessarily assume it's high frequency or have slop (or the scope and magnitude of slop) or any of the other stuff that I had already talked about.

Do they matter? Yes. But in the absence of the information provided for it, I can only really answer the basic question which is what's the CEL expression or help him write the CEL expression for piston motion. (Which can be derived with just high school trig.)

*edit*
Sorry it took so long. Getting ready for a PDT...

 ghorrocks May 30, 2012 19:17

Quote:
 Well, you made a reference to your dissertation.
Ha ha - touche! :)

For the record back when I was doing IC modelling I generated the cylinder mesh initially in Patran (thank god that is no longer the pre processor for CFX, it was horrid) and later in ICEM. In both cases the cylinder mesh was generated by an extrusion so the nodes were perfectly aligned with the piston motion. In CFX 4 the piston motion was easily implemented as you directly specified the new location of each node, but in CFX5 I was forced to generate a very high density mesh at TDC and stretch it to avoid mesh folding. These days you have better control over it and can also link in remeshing steps.

 alpha754293 May 31, 2012 01:09

Quote:
 Originally Posted by ghorrocks (Post 363932) Ha ha - touche! :) For the record back when I was doing IC modelling I generated the cylinder mesh initially in Patran (thank god that is no longer the pre processor for CFX, it was horrid) and later in ICEM. In both cases the cylinder mesh was generated by an extrusion so the nodes were perfectly aligned with the piston motion. In CFX 4 the piston motion was easily implemented as you directly specified the new location of each node, but in CFX5 I was forced to generate a very high density mesh at TDC and stretch it to avoid mesh folding. These days you have better control over it and can also link in remeshing steps.
I started directly with Ansys 10 and I think it was already called Ansys CFX 10 at the time (at least in terms of CFX). I initially started with the Ansys Workbench CFX Mesher and then moved to ICEM CFD 10 as well.

But even back then, I was also starting from TDC like yourself. I think that I might have tried once or twice doing it from BDC using tetras, and of course, I invariably would end up with negative volume elements, even when I manually meshed partial steps for it to interpolate the results from the previous timestep, compress to the next timestep; and did it piecewise like that. I think that I got like 67% of the way throught the compression before it would have the negative volume and bomb out.

Course, now I know that was the dumb way of doing things.

Here is my latest sim based on the meshing that I described - tetras on the top of the clearance volume, tetras on the first later of the bottom (top of the piston) and hexas in the middle.

This is technically a direct injection sim, although the actual engine is port fuel injected. (I don't have the ports modelled here). I'm still trying to figure out how to do the valve motion here so that CFX will play nice.

Unfortunately, with simplified models, I can do the same thing where I put hexas above and below the valve and then just tie it all with domain interfaces.

But with real geometry from a real engine, it doesn't quite lend itself that easily/readily to that. Or if I CAN do it, the remaining geometry does get quite a lot more complicated.

And that I still haven't quite figured out what to do with the flow discontinuity when the valve completely closes. (Now...THAT is a tough mesh problem...) I haven't been able to provide the rationale for if multi-domain or dynamic remeshing would even work in this case. So, I dunno. I'm still thinking through the problem first before doing anything about it.

 ghorrocks May 31, 2012 06:07

The normal way of doing valve motion is to move the valves until they are almost shut, but still open with mesh elements in the gap, but small enough that the flow is pretty low. Then you just snap it shut in a remeshing step. Is that what you are thinking for valve shutting/opening?

I was lucky in my work as I had a rotating valve (not poppet valves) and that is modelled very nicely with a TRS in a rotating frame of reference.

 alpha754293 May 31, 2012 08:47

Quote:
 Originally Posted by ghorrocks (Post 364007) The normal way of doing valve motion is to move the valves until they are almost shut, but still open with mesh elements in the gap, but small enough that the flow is pretty low. Then you just snap it shut in a remeshing step. Is that what you are thinking for valve shutting/opening? I was lucky in my work as I had a rotating valve (not poppet valves) and that is modelled very nicely with a TRS in a rotating frame of reference.
Either that or the other way that I'm thinking is let the hexa mesh deform.

The "problem" that I'm thinking of/facing is that with the real engine geometry, the way that the valve is - only the inside surfaces (based on the negative cavity) will move, while the outside surfaces remain stationary.

So it's either set the mesh motion on the inside surfaces only while the outsides are station, which means that there'll be mesh distortion or I remesh each step. (Much smaller distortions).

I dunno yet. I'll have to play around with it.

Even still, like I said, putting hexas around the real valves is difficult because they're all on it's own LCS.

 All times are GMT -4. The time now is 19:01.