Dimensionless Space and Time

[WebPilot]

... Wave propagation. Figure out duct dimensions from the data you now have, Forrest.

Your drawing appears to be of a tube open on both ends. The drawing I
have posted is useless for your case.

-fde

[WebPilot]

If one is interested in wave interaction details at later periods of time, then more
lines in the original expansion wave fan need to be drawn and allowed to develop. As
one can see from inspection of the diagram, things are getting sparse after Tau = 4.0.

However, one important fact is clearly illustrated - the shock wave approaches the
open end, which is now an area of subsonic inflow. It is reflected as an
expansion fan at point 46.

At point 46, the inflow 'jumps' from -0.3430 to -0.2030.



-fde

[sam]

Just to prove that my code (NUDiS) can be used to solve this problem too...
The code is different (better?) than UFLOW because it can model a proper closed end boundary condition.
Sam

[WebPilot]

Sam,

I was wondering if you were going to join the 'fun'.

Yes, approximating a closed boundary condition was one of the things that bothered me
about Uflow - among others.

Your code produces output in dimensionless parameters? Or did you non-dimensionalize
after a run with numbers?

We have a small timing discrepancy where the pressure discontinuity appears? - my point
31.

What method of solution are you using?

Regardless, pretty work.

-fde

PS Will your code plot out velocity vs. dimensionless time at the open end?
I'd like to see that plot.

After reading the user's document, I was able to answer some
of these questions myself. Results forthcoming.

[pezman]

You can get code for a Riemann solver here:
http://www.physics.buffalo.edu/phy411-5 ... tml#topic7

.. along with notes that will help w/ understanding.

If you look in "shocktube.cpp", you'll see that a modeling a closed boundary condition is almost trivial.

I have been playing around w/ the code in my spare time and I get mysterious underflow problems -- so it was easy to compile but not so easy to get working (thus far).

[WebPilot]

Cool site. If I passed that course which this problem is just a part of, I
would have flunked everything else, since I wouldn't have had any extra
time for other studies.

Keep plugging away pezman - you'll do it.

-----



I, too, got NUDiS to solve this problem.

I had to use a text editor that was able to move 'columns' of data about between different
output files for plotting purposes. At least the output data is in ASCII. The editor I used
came from an operating system called 'PC-DOS version 6'.

NUDiS requires #'s to work, so if you want to plot dimensionless time, Tau, you have to
multiply the program's 'time.dat' file by the suitable parameters to make it dimensionless
and then plot it out.

The documentation for 'Output frequency' in 'inputs.dat' needs a little more clarification.

In 'geom.dat ', I assume the Duct diameter and Wall thickness, are expressed in meters.

I don't like the idea of entering 256 columns of data for input. I would prefer 256 ROWS
since it would be so much easier to enter data and keep track of where I am.

Now, this may read like I am bad mouthing the code, and I am not.

It can model a closed end which Uflow cannot. I can test the code's number crunching
abilities by testing it say, with this problem, but more importantly, a shock tube.

The more interesting of the 2 graphs is this one. I posted my earlier not knowing what
exactly is was supposed to look like. There indeed seems to be a discontinuity in the
flow velocity around my point, 46 (around Tau = 4.5). The initial amplitude is 0.7 not the
0.8 I computed ... hmmm.



-fde

[mk]

Very interesting, again. Too bad I actually don't know too much about that stuff.

A general questions: The initial fan existance is the result of the assumtion dp happening not instantly, but in dt, right? Thus these fan lines are just for complexicity reduction of plotting numerous graphs equaling a plane, correct?

[sam]

Forrest,
I suspect that the discrepancy in the velocity plot is because my open-end boundary condition is different to yours. I think I'm right in saying that you have been assuming that the static pressure stays constant at one atmosphere at all times at the open boundary. This is the usual "open-end boundary" assumption, and is used in UFLOW too.
NUDiS makes a different assumption: The static pressure is held constant during outflow only. During inflow the static pressure is allowed to reduce from the atmospheric value. Physically, this models a separated jet during outflow, and reversible sink flow during inflow. Its a more correct interpretation of what actually happens at a pulsejet exhaust/inlet, but only really becomes significant at relatively high flow velocities.
NUDiS is capable of simulating shock tube problems. You can compare the results with an exact Riemann solver for accuracy. As with all numerical simulations, the accuracy will reduce as the shock strength increases.
I'm sorry you don't particularly like the way that data is input. This method of data entry is very convenient for me, and I'm not really prepared to go changing this now. Mike E. is working on a frontend interface for the code which should alleviate any problems you may be having, if all goes well.
Sam

PS. The 'output frequency' basically tells the software how often you want to dump a solution to file. It has to be an integer >=1. e.g. If you set it to 50 then it dumps a solution every 50 timesteps.

[pezman]

One way to model a closed end in UFLOW is to make a "mirror image" of the structure being tested. Initial conditions must also be a "mirror image" about the center point (i.e. they match in terms of pressure and temperature, and must be opposite in terms of initial flow speed). This requirement of matching P, T and opposing flow speeds applies to the ICs at the open ends of the tube as well.

Then, just run the simulation and discard all data to the left of the "mirror" point.

[WebPilot]

Hey Marten,

Wie Geht's?

Probably the simplest explanation I can give for what is going on initially is that as soon
as the 'frangible' diaphragm is broken, flow comes out. Right? Well, the wave cannot be
one of compression, because it would 'push' the flow back in. This wave is propagating to
the left and 'pulling' the air out, thus, it must be an expansion wave.

A centered expansion wave is created by an 'instantaneous' decrease of pressure
at some point of the duct.

As far as why it is a 'fan' is because, it is a continuous 'array' of expansion waves originating
at some point. I have chosen the 'head' and 'tail' and a few in between. There are many
more in between.

Fröhliches Weihnachten!

-fde

-----

I suspect that the discrepancy in the velocity plot is because my open-end boundary
condition is different to yours. I think I'm right in saying that you have been assuming that
the static pressure stays constant at one atmosphere at all times at the open boundary. This
is the usual "open-end boundary" assumption, and is used in UFLOW too.

Nope. I am not assuming that. See graph.

NUDiS makes a different assumption: The static pressure is held constant during outflow
only.

Well, at points 0 and 6, there is outflow. By your admission, the
static pressure should be atmospheric. Yours, Larry's and my plots all
agree on the pressure vs time. Something else is amiss, here for
velocity vs tau.

Hey pezman or Larry, can Uflow do an exit velocity vs. Tau plot at Xi=1.0?

I'm sorry you don't particularly like the way that data is input. This method of data entry is very convenient for me, and I'm not really prepared to go changing this now. Mike E. is working on a frontend interface for the code which should alleviate any problems you may be having, if all goes well.

Well, it's just a matter of preference. Don't take it personally. Mike E.'s front end is based
on Excel and macros. I know he's doing a wonderful job, but don't think everyone has Excel
on their machines. I do, but am not too excited about Excel's graphics capabilities. I may
have to write some utilities.

PS. The 'output frequency' basically tells the software how often you want to dump a solution to file. It has to be an integer >=1. e.g. If you set it to 50 then it dumps a solution every 50 timesteps.

Forgive my ignorance, but how do you 'compute' the time step during the data input stage?

Cheers,

-fde

[WebPilot]

Yep, it's a 'filler' or 'stub' meant to keep you interested until I get the correct
graphic up. I see it was a good choice and it's working. he he he

-fde

[sam]

[quote]Forgive my ignorance, but how do you 'compute' the time step during the data input stage?[/quote]

The timestep is calculated by a stability crtierion (or CFL criterion as its usually called). You can't really work it out before hand, and the program calculates it as it goes along.

Its given by C * dx / max(a+u)

where C is the CFL number (I think its set as 0.5 in 'inputs.dat')
dx is the cell length (= duct length / number of cells)
a is the sonic velocity
u is the particle velocity


Not sure why the velocity should be different. I'll have to think about that for a bit longer...

[sam]

fde,
I've just checked my solution to the problem and I too get an initial outflow Mach Number of 0.8, as your Method of Characteristic solution suggests. I'm not sure where you went wrong... maybe you weren't normalising the velocity by the correct speed of sound?
sam

[pezman]

I managed to get my 1D Euler prototype working -- not perfectly, but not bad.

Here is an animation of a shock tube simulation. The left half of the tube has air whose density is "3" and whose pressure is "3", while the right half has air that is at a density of "1" and a pressure of "1".

All of the units are essentially dimensionless. I'll need to do some test problems to get the simulator to accept real-world physical units and set up problems using practical terms (e.g. specifying initial conditions in terms of presure and temperature).


Once that is done, I'll add some code to put an automation wrapper around it, so that Excel, VB etc. can be used to set up simulations. That should make it easier to set up PJ-style simulations (e.g. you can heat the fluid every cycle).

I'm also hoping to be able to set the simulation up so that you can have multiple boindary conditions at a point (e.g. to simulate the two rear-facint tubes of a Chinese valveless).

At any rate, here's the animation -- my apologies for its hugeness.

Note: it takes about 10 seconds before the animation actually starts moving.

[WebPilot]

As you can see, the pressures at the open end determined by the 2
methods are comparable - virtually exact for outflow.

The timestep is calculated by a stability criterion (or CFL criterion as its
usually called) ...

Ah, the ol' Courant-Friedrichs-Lewy stability criterion, I should have
known.

I've just checked my solution to the problem and I too get an initial
outflow Mach Number of 0.8, as your Method of Characteristic solution
suggests. I'm not sure where you went wrong... maybe you weren't
normalising the velocity by the correct speed of sound?
sam

It's cool that your model matches my MOC analysis. It's not so cool I
can't get my model using your code to do so, too - although I am close
with it.

Well, I might have used the wrong speed of sound for non-dimensionalizing
the flow velocity. I used 347.2 m/sec (the speed of sound in air at 300°K).

Why not POST your model's data files?

-fde