Closed gforney closed 7 years ago
Simpler test cases.
Single (large) periodic particle. Constant viscosity. Particle going in straight or
at an angle. Shows different results for angled and straight cases.
Original issue reported on code.google.com by Topi.Sikanen
on 2013-02-08 21:44:19
Here are results with particle force only. So it seems to me the issue is not with
the particle force term. That looks as good as it can get on a Cartesian mesh. I
will now go through and see if any of the other terms create more problems than the
others.
Original issue reported on code.google.com by randy.mcdermott
on 2013-02-11 14:37:09
Here is particle force plus vorticity (advective) term.
Original issue reported on code.google.com by randy.mcdermott
on 2013-02-11 14:49:05
Topi,
These cases are strange---they take a long time to initialize... just for a single
particle. Anyone have ideas why?
Original issue reported on code.google.com by randy.mcdermott
on 2013-02-11 15:04:27
Mie scattering
Original issue reported on code.google.com by mcgratta
on 2013-02-11 15:06:38
Here are the results with just the viscous term and the particle force. So, the culprit
is the vorticity term. Now I'll see if I can keep this symmetric for longer. These
cases have NOISE=T at the moment.
Original issue reported on code.google.com by randy.mcdermott
on 2013-02-11 15:12:00
Made a bit more progress here. One issue is that the simple cases (single*) that Topi
posted in fact are not the same problem. One way to get identical problems is to use
2 particles for the "straight" case. New input files are attached. These are the
same problem.
Next, the PARTICLE_CFL was not implemented such at the initial time step would be chosen
correctly. It used the time step as calculated after the particles had been moved.
So I clean this up, and now you don't have to set some ridiculously small initial
time step, you just say what you want the particle CFL to be and the correct time step
is chosen.
When these two problems are compared now, I see very similar results. Below are the
patterns from 0.5 and 1.0 (end) seconds in the run. Even the destabilization happens
at around the same time.
Let me push up this code and then let's Topi and I see what the original cases look
like.
Original issue reported on code.google.com by randy.mcdermott
on 2013-02-11 19:11:32
Excellent work. Once you have this pushed up, I am going to run one of my particle jet
cases to see if this changes anything.
Original issue reported on code.google.com by ben.trettel
on 2013-02-11 19:20:32
This didn't solve the problems with the angle/ striaght sprays.
Attached is two cases with slightly larger computational domain.
First two figures show the spray front reaching distance of 2.5 meters from the nozzle
at t=0.173 seconds for the straight case and t=0.202 seconds for the angled case. The
second two pictures show velocity slices at the middle of the spray. Clearly the angled
jet goes turbulent/unstable almost immeadiately while the straight jet remains, well,
straight.
The attached cases run kind of slow, so these are not the best possible test cases.
The jet instability/turbulence can be seen on smaller computational domains, but the
slowing down of the particle front can not be seen until about 1.5 meters - 2 meters
from the nozzle. This is probably the distance it takes for the particles to become
tracers and thus from there on the diffeences in the spray front propagation are caused
by the differences in the jet gas velocities.
So, back to the drawing board.....
Original issue reported on code.google.com by Topi.Sikanen
on 2013-02-12 20:04:14
Have you all looked at the pressure field for these cases? I started looking at the
particle jet case for which I have an exact solution. The exact solution has a constant
homogeneous pressure field. FDS maintains this approximately (within 1e-2 Pa, which
is tiny). This case does not exhibit the orientation dependence. Possibly the orientation
dependence is due to the pressure, and it will not appear with an essentially homogeneous
pressure field.
Original issue reported on code.google.com by ben.trettel
on 2013-02-12 20:52:16
I'll look into it.
Original issue reported on code.google.com by Topi.Sikanen
on 2013-02-12 20:53:41
What is the status of this issue?
Original issue reported on code.google.com by mcgratta
on 2014-09-07 14:34:57
Needs work. Would have been good to get Ben on it, but he has other priorities now.
Original issue reported on code.google.com by randy.mcdermott
on 2014-09-07 16:50:27
Quals are over now, but I have a backlog of other work to do. If you all think it would
be a good use of my time, I can look into this again soon. As I recall, I came to the
conclusion that adding additional refinement near sprinklers probably is necessary
to resolve this issue. Not entirely sure, though.
Original issue reported on code.google.com by ben.trettel
on 2014-09-11 20:36:40
Ben,
You should focus on the embedded mesh work until your PhD is finished.
R
Original issue reported on code.google.com by randy.mcdermott
on 2014-09-12 15:16:33
This issue is missing original attachments from GoogleCode. I'm closing, and if the original poster wants to pursue, start a new issue.
Original issue reported on code.google.com by
Topi.Sikanen
on 2012-10-31 22:05:53